Graph use cases by sector: CLOs, secondaries, sponsors, fund finance and SRT

Part 2 built one graph: BDCs connected to borrowers. The same pattern, holders connected to exposures through dated, valued edges, keeps coming back across private credit. Below are five sector-specific versions. For each, we cover the model, the query that justifies it, where the data comes from, and what tends to go wrong. Nothing here relies on a vendor. A Python notebook can prototype any of them.

1. CLO look-through overlap across manager portfolios

Model. Nodes: CLO vehicles, managers, obligors (rolled up to a family), facilities, industries. Edges: manager MANAGES CLO; CLO HOLDS facility (par, price, rating, date); facility ISSUED_BY obligor; obligor IN industry.

Queries. - Obligor overlap between our CLOs and another manager's CLOs (or a set of CLOs whose debt or equity we're evaluating). It's the same pairwise projection as the BDC heat map in part 2. - "Which obligors appear in more than N of the CLOs we own tranches in, and what's our aggregate look-through par?" This is the question for CLO tranche investors, where exposure to one obligor sneaks in through several deals. - Concentration in names rated CCC or below, or trading below a price threshold, across the whole look-through book.

Data. Trustee reports and the manager's own holdings files for your vehicles. For others' vehicles, whatever you're entitled to: investor reports, data vendor feeds. Public BDC and some fund filings cover the private-credit side.

What goes wrong. Obligor naming across trustees is inconsistent, and the same obligor shows up under different facility identifiers. Price and rating fields need an as-of date on the edge, not on the node. Keep the facility-to-obligor mapping as its own reviewed table.

2. Secondaries portfolio overlap

Model. Nodes: target portfolio (fund interests, loan strips, or a continuation-vehicle asset pool), your existing book, underlying companies, sponsors, GPs. Edges: portfolio HOLDS company (value, date); company OWNED_BY sponsor; fund MANAGED_BY GP.

Queries. - How much of the target is already in our book, by count and by value, and with which marks? A gap between the seller's mark and our mark on the same company is useful pricing information. - Concentration after the purchase: top sponsors, top companies, top industries in the combined book. - Second-order overlap: companies in the target that share a sponsor with stressed names we already hold.

Data. The seller's data room, usually a spreadsheet with company names in whatever format the seller uses. Your own portfolio system. Public filings where the target holds BDC-reported positions.

What goes wrong. Time pressure. Secondary processes give you days, not weeks, so entity resolution has to be fast and reviewable. A pre-built crosswalk from past deals pays for itself. Treat matches below a confidence threshold as "unknown," not "no overlap."

3. Sponsor-network contagion

Model. Nodes: sponsors, sponsor funds (by vintage), portfolio companies, lenders, facilities. Edges: fund OWNS company; lender HOLDS facility; company BORROWS facility; sponsor shared operating partners or add-on relationships where you track them.

Queries. - When a sponsor's company defaults or starts an LME, which of our other borrowers share that sponsor, and which fund vintage are they in? Stress tends to cluster by vintage and by sponsor behavior. - How has this sponsor behaved in past workouts: equity injections, amend-and-extends, non-pro-rata transactions? This needs amendment and LME events attached to facilities (see part 3). - Which co-lenders keep showing up next to us with this sponsor? That's the lender group we'd have to coordinate with in a workout.

Data. Your own deal records (sponsor fields are often free text and need cleaning), sponsor websites and press releases for ownership, and court filings and news for LME history. BDC schedules generally don't name sponsors, so sponsor edges have to come from somewhere else.

What goes wrong. Contagion graphs make it tempting to call names "related" on weak links. Keep edge types explicit and weighted. "Same sponsor, same fund" is much stronger than "same sponsor, different fund," and both are far stronger than "shared co-lender."

4. Fund finance: LP concentration

Model. Nodes: funds (borrowers under subscription lines), LPs, LP parent groups, GPs, facilities, lenders. Edges: LP COMMITS_TO fund (commitment, unfunded, date); LP PART_OF parent group; fund BORROWS facility; lender HOLDS facility.

Queries. - Across all the subscription lines we've provided, what's our aggregate exposure to unfunded commitments from one LP group, combining its pension plan, its sovereign affiliate and its feeder vehicles? - For one borrowing base, how concentrated is it once related LPs are rolled up, compared with the GP's reported figures? - For NAV facilities, which underlying portfolio companies appear in several NAV-financed funds we lend to?

Data. Borrowing base certificates and investor lists under each facility (confidentiality terms decide what can be pooled internally). The LEI system carries parent relationships for entities that have LEIs, which helps with institutional LPs. Many feeder and family-office vehicles won't have one.

What goes wrong. LP vehicles are numerous and opaquely named. Group roll-ups need a reviewed parent map. Confidentiality walls may also limit which facility data can be combined. Model access control before you model concentration.

5. SRT reference pools

Model. Nodes: SRT transactions, the originating bank, reference obligations, reference obligors (rolled up), industries and geographies, and investors in the protection tranches. Edges: transaction REFERENCES obligation (notional, date); obligation OWED_BY obligor; investor HOLDS tranche.

Queries. - How much does our exposure to obligors through SRT reference pools overlap with our direct private credit book? Funds that hold both may be taking the same name risk twice. - Across several SRT deals from different banks, which reference obligors (or obligor families) repeat? - Replenishment: how has a pool's composition drifted against its eligibility criteria over time?

Data. Reference pool reports supplied to investors. These are often anonymized or blinded, with obligors identified by code, industry and rating rather than name. In that case the graph works at the attribute level (industry × rating × geography buckets) and the true overlap with a direct book can't be computed. Say so in any output rather than guessing.

What goes wrong. Blinded pools invite false precision. Keep a clear flag on every edge for "named obligor" versus "anonymized bucket," and never merge a bucket into a named entity.

The common pattern

Illustrative structure

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

All five share three components:

1. A reviewed entity layer. Canonical entities, families, and source-name crosswalks with reviewer and date.
2. Dated, valued holding edges. Par, cost, fair value or price, rating, as-of date, source document.
3. Projections. Holder-to-holder overlap, exposure roll-ups by family, sponsor or industry, and path queries for contagion.

LLM agents help with populating the edges (extracting holdings from PDFs, data rooms and trustee reports), proposing entity matches for review, and translating analyst questions into queries. Community-detection and summarization approaches like GraphRAG (Edge et al., 2024) can help with the "what clusters are in this book?" kind of question. The quantitative overlap numbers should come from deterministic queries, not generated text.

Part 5 covers the tooling: build vs buy for graph tools.

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
4. networkx.org ↗ https://networkx.org/

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