A global macro hedge fund wants to map the relationships between 5,000 corporate entities, their supply chain dependencies, executive board overlaps, regulatory filing cross-references, and counterparty exposures to identify systemic contagion risks. A data architect proposes replacing the current relational database with a knowledge graph. Which specific capability of knowledge graphs makes them architecturally superior to a relational database for this use case?

Contagion risk mapping requires answering questions like: 'Which of our portfolio companies share a common critical supplier that also has counterparty exposure to a distressed bank?' In a relational database, answering this requires JOINing across multiple tables — entities, relationships, supply chains, counterparties — and the query complexity grows factorially with each additional relationship hop. At 5,000 entities with multiple relationship types, these queries become maintenance nightmares and often perform so poorly they are impractical for real-time analysis. Knowledge graphs, implemented in systems like Neo4j or Amazon Neptune using property graph or RDF models, natively represent entities as nodes and relationships as edges with properties. Cypher queries (Neo4j's query language) can traverse three or four relationship hops — entity → supplier → counterparty → regulator — in a single, readable statement that executes orders of magnitude faster than equivalent SQL JOINs on large datasets. This is the core architectural insight: relationships are first-class citizens in a graph, not afterthoughts represented as foreign keys. The correct capability is therefore native multi-hop entity relationship modeling, because it reveals indirect contagion paths — such as a supplier's supplier's counterparty exposure — without the prohibitively complex, performance-degrading JOIN chains required in a relational schema. In investment research applications, knowledge graphs power use cases including FactSet's entity linking system, Refinitiv's ownership graph, and Bloomberg's supply chain risk module. Executive board overlap detection — identifying when the same individual sits on boards of two portfolio companies — is a single pattern-matching query in a graph versus a self-JOIN on a relational director table. Supply chain dependency mapping and counterparty network analysis follow the same pattern. The compressed binary storage claim is wrong because graphs do not inherently store all data in a compressed binary format that reduces storage costs compared with relational databases, and storage economy is not the architectural advantage needed here. The automatic FINRA and SEC-compliant regulatory reporting claim is wrong because regulatory reports still require transformation, validation, and reporting logic; they are not generated automatically from entity relationship data without additional transformation logic. The built-in field-level encryption claim is wrong because encryption and SOC 2 Type II compliance controls belong to separate infrastructure, security, and governance layers, independent of whether the database is relational or graph-based. The correct answer isolates the one capability genuinely unique to graph databases: traversal-efficient relationship modeling at depth.