A hierarchy is a graph, which is why your MDM tool struggles with it
Counterparty ownership, instrument identifier crosswalks, and product families are all relationship problems, and relational master data tools model them as tables of parent keys. TopQuadrant holds them as a graph: traversable to the ultimate parent, reconciled to LEI and FIGI, and published back into the systems that need them.
Trusted to govern the data behind the world's most regulated decisions.
Customer 360 fails when it is built as a reporting view
The pattern repeats: a unified customer view is assembled on top of still-siloed core banking, CRM, lending, and risk systems. It demos well and it does not hold in production, because nothing writes the resolved entity back and nothing governs the survivorship rules. Governing the entities and hierarchies themselves, then publishing outward, is the version that lasts.
Active Legal Entity Identifiers as of Q1 2026, growing roughly 3.4% a quarter, which your counterparty master has to reconcile against continuously.
SWIFT CBPR+ milestone retiring MT101 coexistence and mandating structured or hybrid postal addresses, ending fully unstructured address fields.
Connectors publishing governed entities and hierarchies back into operational and analytical systems.
Counterparty hierarchies
Traverse to the ultimate parent in one query
Ownership structures are modelled as relationships with effective dates and provenance, so aggregate exposure, single-obligor limits, and connected-party checks run against the real structure rather than a flattened snapshot.
- Full traversal. Ultimate parent, every subsidiary, and every intermediate level, in one pass.
- Effective-dated structure. Query the hierarchy as it stood at any past date.
- Multiple hierarchy types. Legal, beneficial, and risk-aggregation hierarchies held alongside each other.
Identifier crosswalks
Hold LEI, ISIN, CUSIP, and FIGI without picking a fight
Different reports and different regulators want different identifiers, and the question of which is authoritative for which submission is now itself a live regulatory topic. Carry all of them, cross-mapped, with provenance recording which is authoritative where.
- Multi-identifier records. One governed entity or instrument, all its identifiers, cross-mapped.
- Authority recorded. Which identifier is authoritative for which report, held as governed data.
- External reconciliation. Continuous checks against GLEIF and other external registries.
Entity resolution
Fix the match instead of the threshold
Screening false positives are usually an entity resolution problem wearing a model risk costume. Governed entities with resolved aliases, addresses, and identifiers give screening a clean input, so tuning the matching threshold stops being the only lever available.
- Governed survivorship. Resolution rules are governed assets with owners, not code in a pipeline.
- Alias and variant handling. Former names, transliterations, and address variants attached to one entity.
- Structured addresses. Parse legacy unstructured address strings into the structured form ISO 20022 requires.
Publication to operational systems
Write the resolved record back
A governed entity that exists only in the governance tool has not solved anything. Publish resolved entities, hierarchies, and product masters into core banking, CRM, screening, and the warehouse, so the operational systems and the reports agree.
- Push to operational systems. Governed records land where the work happens.
- Warehouse and catalog sync. Snowflake, Databricks, Collibra, and Informatica read the same governed values.
- Change propagation. An update to a hierarchy reaches every consumer, with a record of when.