In syndicated lending, some lenders can receive material non-public information and some cannot. Here's how the public/private side framework works, where it breaks, and how to enforce it in a data room.
Here's a scenario that keeps loan market compliance officers up at night. A large asset manager participates in a syndicated loan to a public company. The credit analyst on the deal receives the borrower's internal projections, which show next quarter tracking well below street consensus. Down the hall, the same firm's high-yield desk trades that company's bonds.
If information flows from the analyst to the desk, that's trading on material non-public information. The regulatory, legal, and reputational consequences are severe. And the loan market's answer to this problem, the public side / private side framework, runs to a surprising degree through data room mechanics.
If you're a borrower, arranger, or lender touching syndicated credit, here's how the framework works and what your data room actually has to enforce.
Syndicated lending has always operated on information that securities markets would classify as MNPI. Lenders routinely receive:
For a private borrower with no traded securities, this is fine; there's nothing to trade. The problem arises when the borrower has public equity, public bonds, or even a broadly traded loan, and when lending institutions also run trading operations. That describes most of the modern loan market: banks with securities desks, asset managers running both loan funds and bond funds, hedge funds active across the capital structure.
The market's solution is to let each institution, and each individual, choose a side.
Private-side participants receive the full information package: projections, non-public financials, amendment discussions. In exchange, their institution must have information barriers preventing that MNPI from reaching anyone who trades the borrower's securities, and the individuals themselves are typically restricted from trading decisions on that name.
Public-side participants receive only information that is public or that the borrower has designated as containing no MNPI. They can hold the loan and vote their position, but they work from a deliberately limited file. Because they hold no MNPI, their institution's trading desks stay unrestricted.
The choice is real and consequential. Many CLO managers and loan funds deliberately run public-side to preserve trading flexibility across their platform. Bank lending groups usually run private-side behind formal walls.
| Information | Public Side | Private Side |
|---|---|---|
| Public-side information memorandum | Yes | Yes |
| Historical audited financials (public co.) | Yes | Yes |
| Term sheet and pricing | Yes | Yes |
| Management projections and budget | No | Yes |
| Monthly management accounts | No | Yes |
| Covenant compliance certificates | Usually no | Yes |
| Amendment discussions with detail | Sanitized version | Yes |
| Bank meeting (full version) | Public version only | Yes |
Borrowers and arrangers therefore produce two versions of key documents: a public-side IM scrubbed of MNPI (with the borrower certifying the scrub) and a private-side IM with everything. Same for lender presentations, and often for amendment materials.
The framework fails in predictable places, and almost all of them are information-handling failures rather than bad intent:
The misdirected upload. A quarterly projection update posted to the folder both sides can see. This is the most common incident, and it's purely a data room permissions failure.
The Q&A leak. A private-side lender asks a question that embeds MNPI ("does the covenant step-down assume the Q3 restructuring charge?"), and the answer gets broadcast to the full group including public-side users.
Search bleed. A public-side user searches the room, and result snippets expose text from private-side documents they can't open. Half a sentence of a projection can be MNPI.
The side-switcher. An analyst provisioned private-side moves to a trading role, but their access lingers. Every day of lingering access is audit exposure.
Cleansing failures. When a deal ends or information goes stale, private-side participants may be "cleansed" via a public announcement that releases the MNPI. Tracking who was cleansed of what, and when, gets sloppy fast without systematic records.
Notice the pattern: the wall is only as good as the system enforcing it. In practice, that system is the data room.
A generic VDR with two folders labeled "Public" and "Private" is not an information wall. Purpose-built platforms enforce the framework at five levels:
Each user declares public-side or private-side status on first access, typically via a click-through designation that is timestamped and logged. That declaration is your evidence, years later, of what an individual was entitled to see.
Private-side content must be invisible to public-side users, not merely restricted: absent from their index, their search results, their notifications, and their Q&A threads. If a public-side user can see that a document called "FY2027 Board Budget v3" exists, you have already communicated information.
Q&A must run in side-aware channels. Private-side questions and answers broadcast only to private-side participants; anything released to the public side goes through explicit arranger review. The agent's triage role, described in our walkthrough of the loan syndication process, doubles as the MNPI checkpoint.
When a user or institution changes side, trades out of the position, or leaves the deal, access must terminate immediately with a logged timestamp. Secondary loan trading makes this routine, not exceptional: an active name can see several transfers a quarter.
When a regulator or internal compliance team asks "could this person have seen the projections before that trade?", the answer must be a report, not a reconstruction. Per-user, per-document access logs with timestamps, retained for years, are the whole ballgame.
Platform capability varies widely here. Our guide to the best data room for debt financing and loan syndication compares providers on wall enforcement specifically; among established options, Intralinks has the longest history with syndicated loan workflows, and iDeals offers the granular group permissioning that side segregation requires at scale.
Decide early whether you need a public side at all. A private company with no traded debt can run a single private-side process and skip the entire apparatus. The moment you have public securities or expect CLO participation, build the wall from day one; retrofitting mid-syndication is miserable.
Scrub and certify the public IM properly. The borrower, not the arranger, certifies that public-side materials contain no MNPI. Have counsel review the scrub. Optimistic labeling of projections as "illustrative" does not de-MNPI them.
Name a wall owner. One person on the arranger team owns side designations, upload reviews for the public folders, and the cleansing log. Diffuse responsibility is how misdirected uploads happen.
Review Q&A answers for side, not just content. Every broadcast answer needs two checks: is it accurate, and which side can receive it.
Audit access quarterly post-close. The reporting phase is where discipline decays: a compliance certificate is MNPI too, and the room distributing it for 5 years needs the same wall as the room that syndicated the deal.
The public/private side framework lets a market built on private information coexist with securities laws built on disclosure symmetry. It works only when the mechanics work: logged side declarations, structurally segregated content, walled Q&A, immediate revocations, and audit trails that answer questions years later.
Those mechanics live in your data room. Choose a platform that enforces the wall by design, assign a human owner, and treat every upload to the public side as a disclosure decision, because legally, that's what it is.
Les VDR gerent vos documents les plus sensibles. Voici ce qui peut reellement mal se passer, quelles menaces sont surestimees, et comment les fournisseurs serieux se protegent contre les attaques du monde reel.
La conformite reglementaire n'est pas optionnelle, mais comprendre ce dont vous avez vraiment besoin est plus difficile que cela ne devrait l'etre. Voici une lecture pratique de GDPR, HIPAA et SOC 2 pour les utilisateurs de data rooms.
Les equipes enterprise de securite exigent le Single Sign-On pour chaque application cloud. Ces VDR prennent en charge SSO et Okta afin que l'IT puisse gerer l'acces, imposer la MFA et conserver une piste d'audit propre.
A quoi ressemblera le partage securise de documents en 2030 ? Nous explorons les technologies emergentes, du stockage decentralise aux zero-knowledge proofs et au scoring des risques par IA, en separant l'innovation reelle de la speculation.