GraphRAG: when 'who owns what' needs deterministic multi-hop traversal

Every portfolio manager has spent an afternoon staring at a Bloomberg DRSK or CRPR screen, walking an indented issuer hierarchy: ultimate parent at the top, intermediate holdcos in the middle, the operating subsidiaries that actually issue the debt at the bottom. That tree is how counterparty look-through has worked for thirty years. It is austere, monospaced, and structurally honest: parent, child, edge, edge type.

GraphRAG is the same tree, made queryable by a language model without giving up the structure. Conventional RAG flattens a corpus into a vector store and asks similarity to do the work; the issuer hierarchy disappears into a soup of paragraphs. GraphRAG does the opposite. It keeps the hierarchy as a first-class object - typed nodes (Issuer, Parent, Subsidiary, Fund, Covenant, LEI) and typed edges (owns, guarantees, holds, defaults_under) - and asks the LLM to enter the graph at the right node and walk a deterministic path from there.

The literacy bridge is exact: a Bloomberg indented hierarchy is a graph laid out as a table. GraphRAG just lifts the table off the page so that 'list every fund of mine exposed to a subsidiary whose parent has a covenant breach' becomes a traversal, not a paragraph-match.

Microsoft Research formalised GraphRAG in 2024 (Edge et al., arXiv:2404.16130). The pipeline has five mechanical stages and none of them is decorative. First, the corpus - prospectuses, KIIDs, factsheets, IC memos, counterparty agreements - is chunked. Second, an LLM extracts typed entities and typed relations from each chunk, producing a node-and-edge list. Third, those nodes are merged and deduplicated into a single graph. Fourth, the Leiden community-detection algorithm (Traag, Waltman, van Eck, 2019) partitions the graph into hierarchical communities - clusters of densely connected nodes, then clusters of clusters. Fifth, each community is summarised recursively, low-level summaries at the bottom and broader summaries at the top.

At query time the system splits into two modes. Local queries ("which of my funds hold debt of Issuer X's subsidiaries?") anchor on a node, traverse a small typed neighbourhood, and return the matching triples. Global queries ("what are the top three concentration risks across the book?") never touch raw text - they map across the community summaries at a chosen hierarchy level and reduce. Vector search is still present, but its job is reduced to entering the graph at the right node; from that node the traversal is deterministic. The retrieval that lands in the LLM context is a small, named, audited subgraph - not a fuzzy paragraph cloud.

All of this runs inside the firm perimeter. The graph store, the embedding index, the community summaries, and the LLM that performs the extraction and the final synthesis all live on infrastructure the firm controls - DORA Art. 28-30 ICT third-party risk register applies, and no prompt or chunk crosses the boundary to a public model provider.

Take the AIFMD Annex IV look-through obligation. The regulator wants to know what your fund is actually exposed to, three hops down from the headline ISIN: the issuer behind the bond, the parent behind the issuer, the sector and the country behind the parent. A flat vector store cannot guarantee that traversal - it returns paragraphs that mention things, not edges that connect them. A typed graph can: three hops are three edge follows, and the resulting subgraph is the answer.

The same shape applies to MiFID II suitability (does this product fit this client's exposure profile, given everything else they hold?), to ESMA look-through for fund-of-funds, and to internal concentration-risk monitoring across counterparties. In every case the question is structural, not textual. GraphRAG is the retrieval pattern that respects the structure.

The operational anchor is that the subgraph returned for any query is itself an audit artefact: a set of typed nodes and edges with provenance back to the source document. The LLM cites the path it walked, not just the documents it touched. Local inference inside the perimeter keeps prompts, completions, and the graph itself out of any external system.

AIFMD Annex IV requires fund managers to report on look-through exposures; ESMA's guidelines on fund-of-funds extend the same logic; MiFID II Article 25 makes the same demand from the suitability angle. All three regimes want the chain of ownership and exposure to be reconstructable on demand. GraphRAG's typed-edge contract delivers that reconstruction as a deterministic walk over a stored object, not as a paragraph search.

The DORA Art. 28-30 framing is the second half of the regulator argument. Because the graph store, the Leiden partitioning, and the LLM that operates over it all sit on infrastructure inside the firm's perimeter, the third-party risk register for this capability is short. No prompt, no chunk, no community summary leaves the boundary. The audit trail is one of the system's outputs, not a feature bolted on afterwards.

Do not render this as a rainbow network ball with undifferentiated nodes and unlabelled edges. That is the fraud-detection demo idiom from Quantexa and Palantir, and PMs will mentally file it under marketing fluff inside three seconds. The graph has a structure - typed nodes, typed edges, hierarchical communities - and the visualisation must show that structure. A hairball erases the entire contribution.

Do not lead with a Cypher screenshot. Cypher is a storage-layer query language; it puts non-engineer buyers off in seconds and signals "this is an IT problem," which is the wrong frame. The buyer cares about the look-through obligation, not the syntax that supports it. Lead with the hierarchy they recognise, then reveal the graph beneath it.

Do not collapse GraphRAG into a flat left-to-right Sankey labelled "GraphRAG." Several vendor decks do this; it hides the graph entirely. The graph IS the method. Finally, do not present community detection as clustering of embeddings - Leiden operates on graph structure, not vector space, and conflating the two misrepresents what the algorithm actually does and why it produces auditable partitions instead of soft k-means blobs.