Why private credit is a graph problem

Most private credit teams run on tables: a portfolio monitoring sheet, a pipeline tracker, a covenant compliance log, a CLO trustee report, an export from the loan admin system. Each one is fine for its own job. The questions that keep a portfolio manager up at night tend to cut across all of them:

• Which of our borrowers share a sponsor with the name that just missed its interest payment?
• If this unitranche lender is stepping back, where else do we sit next to it in a club deal?
• Which of our facilities have a guarantor that is also a borrower somewhere else in the book?
• How many of our CLO's top 20 obligors also sit in the BDCs we're looking at for a secondary?

None of these is a question about one row. Each one asks how rows connect. That is the practical case for a graph.

The objects and the links

Illustrative structure

• Lender / BDC
• Fund / vehicle
• Borrower
• Facility / loan
• Sponsor
• Agent bank
• Amendment
• Filing

A useful private credit graph has a fairly small set of node types:

• Borrower (the legal obligor, often a holdco or bidco under a TopCo/MidCo stack)
• Sponsor (the PE owner, sometimes several in a co-control deal)
• Lender (direct lenders, BDCs, banks, insurance accounts, separately managed accounts)
• Facility (first lien term loan, DDTL, revolver, second lien, HoldCo PIK note)
• Guarantor / credit party (subsidiaries that guarantee or pledge)
• Holder vehicle (CLO, evergreen fund, BDC, SMA, feeder)
• Document event (amendment, waiver, incremental, A&E, LME transaction)
• Industry / geography as reference nodes

The edges carry most of the value: sponsor OWNS borrower, borrower BORROWS facility, lender HOLDS facility (with par, cost, fair value, date), guarantor GUARANTEES facility, amendment MODIFIES facility (effective date, what changed), CLO HOLDS position. Once you model these as first-class links with attributes and dates, "who else is exposed?" turns into a traversal, not a two-day VLOOKUP project.

A relational database can store all of this, and many firms should keep their system of record relational. The graph is a different view: one optimized for multi-hop questions where you don't know the path length in advance. "Sponsor → borrowers → co-lenders → other borrowers those co-lenders hold" is three or four joins with branching. A graph query states that directly.

The entity resolution tax

Before you can traverse anything, you have to agree that two records are the same thing. In private credit, that's the hard part.

Public BDC schedules of investments are a good stress test because they are the closest thing the market has to an open, cross-lender view of loan holdings. The SEC publishes them as structured data (SEC BDC Data Sets). When we first pulled the 6/30/2026 schedules for seven BDCs (after cleaning, 5,867 holdings, each BDC reconciled to its 10-Q; details in part 2), the same borrower showed up under different strings in different filings. From our own matching pass, a few real examples:

• ZenDesk, Zendesk, Zendesk Inc
• Bamboo US BidCo, Bamboo US BidCo LLC, Bamboo US Bidco
• Integrity Marketing Acquisition, Integrity Marketing Group LLC
• Denali Bidco, Denali Bidco Limited, Denali Holdco, Denali Intermediate Holdings, Denali TopCo

The first two are just case and suffix noise. The last two are harder: they are different legal entities in the same capital structure. Whether you merge them depends on the question. For "how many lenders are exposed to this credit," you probably want to roll up to the family. For "which entity is the obligor under this facility and what does the guarantor package look like," merging them destroys the information you need.

Other common sources of mismatch:

• Filer-specific formatting. Some BDCs put the instrument in the identifier ("First lien senior secured loan 2"), some put the industry there, some append affiliate status. Each feed needs its own parser.
• dba names and parentheticals. "Patriot Holdings SCSp (dba Corza Health, Inc.)" has two names that matter.
• Renames and re-domiciles after an M&A, a refinancing into a new bidco, or a restructuring.
• Numbered shells ("15484880 Canada Inc.") that are meaningless without the parent.

Identifiers help when they exist. The Legal Entity Identifier (LEI) gives a global ID with parent relationships, but many private middle-market borrowers don't have one, and BDC schedules don't carry it. In practice teams end up with a mix: identifiers where available, deterministic normalization (strip suffixes, case, punctuation), fuzzy matching with a human review queue, and an explicit "same family, different entity" relationship instead of a forced merge.

The graph helps here too. A match candidate that shares a sponsor, an industry and a co-lender with the existing node is far more likely to be right than a string match alone. Context from neighbors is evidence.

Where it pays off by seat

Deal teams. Pre-screening a new deal: has anyone on our platform lent to this sponsor's other companies, and how did those credits perform? Who are the likely co-lenders, based on who has sat with this sponsor before?

Portfolio management and workout. When a name goes on watchlist, find every facility, every vehicle that holds it, and every guarantor relationship in minutes. When a sponsor has trouble across its fund, see the whole cluster.

CLO managers. Obligor overlap across your own CLOs, and against other managers' public holdings, is a graph projection: CLOs connected through shared obligors.

Secondaries. Pricing a portfolio of LP interests or loan strips means knowing how much of the target is already in your book, under whatever name the seller uses.

Credit research. Amendments and LME transactions are events on a timeline attached to facilities. Linking them to lenders and documents lets you ask "which lender groups have accepted non-pro-rata uptiers before?" (more in part 3).

Where agents fit

LLM agents are useful in two places in this picture, both narrow. First, extraction: reading a credit agreement, an amendment or a 10-Q schedule and proposing nodes and edges (this entity, this facility, this guarantor, this basket). Second, querying: turning an analyst's question into a graph query and explaining the result with links back to source documents. Microsoft's GraphRAG work (Edge et al., 2024) is one documented pattern for combining LLM extraction with a graph index. Notably, that paper uses exact string matching for entity matching and says softer approaches can be added. In credit, entity matching is exactly the step you can't skip.

What agents should not do is decide on their own that two borrowers are the same. Proposed merges should land in a review queue with the evidence attached.

What to do first

1. Pick one question you answer by hand today, such as sponsor exposure across vehicles.
2. Model only the node and edge types that question needs.
3. Build a crosswalk table (source name → canonical entity → family) with a reviewer and a timestamp on every merge.
4. Load it into whatever graph tool you have. A Python notebook with networkx is enough to start (part 5 covers the options).
5. Measure the time saved on that one question before you expand.

The series continues with a worked example on real public data: a cross-lender borrower graph built from BDC holdings.

Sources

1. www.sec.gov ↗ https://www.sec.gov/data-research/sec-markets-data/bdc-data-sets
2. www.gleif.org ↗ https://www.gleif.org/en/about-lei/introducing-the-legal-entity-identifier-lei
3. arxiv.org ↗ https://arxiv.org/abs/2404.16130

Educational content, not investment advice. Figures derived from SEC filings may contain errors: verify against the filing. Found an error? See the corrections log.