Four hierarchies wearing the same name
Two teams pull the parent of the same subsidiary from the same warehouse and get different answers. Nobody is wrong. One team wanted the entity that legally owns the shares; the other wanted the entity that consolidates the financials; a third would have wanted the entity whose credit stands behind the obligation; and the sales team's hierarchy is a rollup of who signs which contract, which corresponds to nothing in company law at all. All four are called the corporate hierarchy, and only one of them is right for any given question.
This is the first thing to fix, and it is free. Before writing any code, name the hierarchies you need, define each one in a sentence a lawyer would accept, and give them separate columns. Then the disagreement stops being a data quality problem and becomes what it always was: two correct answers to two different questions.
You are probably here because
- An examiner or an auditor asked how you determine ultimate ownership, and the answer is a purchased field
- Aggregate exposure to one group is a number nobody quite believes
- A screening hit landed on a subsidiary and nobody could say who stood above it
- You are paying for a hierarchy feed and want to know what it can and cannot tell you
The four-hierarchy section is the vocabulary. The arithmetic section is where most implementations are quietly wrong. The measurement section is what turns this from an opinion into a number you can show someone.
Which hierarchy answers which question
The four are genuinely different structures, not different views of one structure. They have different edges, different thresholds, and different sources.
| Hierarchy | Edge means | Answers |
|---|---|---|
| Legal ownership | A holds shares or membership interests in B, with a percentage | Sanctions ownership tests, beneficial ownership, control questions |
| Accounting consolidation | B's results are consolidated into A's financial statements | Who reports the revenue; which financials describe this entity |
| Credit and risk | A is the entity whose balance sheet supports B, or the group at which exposure is aggregated | Single-counterparty limits, group exposure, guarantees |
| Commercial or operating | B is managed under A, or contracts through A | Account planning, pricing tiers, support entitlement |
Two structural facts cut across all four. A branch is not a separate legal entity — it is the same company operating in another place, so it cannot have an owner distinct from the company. And an ultimate parent may not exist. Ownership can end in a natural person, in a trust, in a state, in a widely held listed company with no controlling shareholder, in a cooperative, or in a cycle where two entities own each other. A schema that requires every entity to have exactly one ultimate parent will invent one, and the invention will be silent.
Where the edges come from
There is no single register of world ownership. There are perhaps a dozen useful sources, each authoritative for a narrow slice and misleading outside it. The skill is knowing which slice.
Company registries. The national or state registry is authoritative for existence, legal name, registration number and status. Beyond that they vary enormously: some publish shareholders, most do not, and many expose only the current state, which means the history is destroyed on every update unless you snapshot it yourself. If a registry matters to you, start capturing daily snapshots today, because the past you did not capture is not recoverable later at any price.
Beneficial ownership registers. The United Kingdom's register of people with significant control publishes controllers above banded thresholds as free bulk data, and is one of the better sources in the world. In the European Union, access to national beneficial ownership registers narrowed after a 2022 Court of Justice judgment struck down the provision requiring general public access, and the rules have varied by member state since. Check each jurisdiction against its own current guidance rather than against a summary; this is an area where a two-year-old blog post will be confidently wrong.
Securities filings. For listed issuers, filings are the strongest ownership evidence available anywhere: annual report subsidiary exhibits, large-holder beneficial ownership filings above a percentage threshold, and prospectuses. Read the instructions, though. In the United States, the subsidiary exhibit to an annual report permits the registrant to omit subsidiaries that would not be significant considered in the aggregate, so the list is a floor rather than a census.
The Legal Entity Identifier. A twenty-character code under an ISO standard, published as open data, with reference data on the entity and a separate relationship layer recording direct and ultimate accounting consolidating parents. Two things to know: the relationship layer is accounting consolidation, not legal ownership, so it answers hierarchy two and not hierarchy one; and entities may file a documented reason for not reporting a parent, which is a legitimate record and not a gap. Coverage is good in regulated finance and thin everywhere else.
Government contracting registers. In the United States, entity registration for federal awards carries a unique entity identifier and asks registrants to report immediate and highest-level owners. It is narrow — only entities that register — and self-reported, but it is free, current, and directly useful if your counterparties sell to the government.
Commercial hierarchy vendors. Broad coverage, real research behind it, a proprietary identifier, and a global ultimate concept that is theirs rather than a legal one. Useful as a candidate generator and a coverage backstop. Not something to cite to an examiner as your basis for a determination, because you cannot show the evidence.
Ownership arithmetic is not addition
This is where implementations go quietly wrong, and the errors are invisible until someone checks a specific case by hand.
Indirect ownership multiplies along a path and sums across paths. If A owns 60 percent of B and B owns 60 percent of C, A's indirect economic interest in C is 36 percent. If A also owns 20 percent of C directly, the total is 56 percent. Every path from A to C has to be enumerated and combined, which is why this cannot be done with a parent pointer and a loop.
Control is a different edge from ownership. A 30 percent economic stake can carry majority voting rights under a dual-class structure, a shareholder agreement, a golden share, or a right to appoint the board. Ownership percentage and control are separate attributes and belong in separate columns. Systems that store one number and label it ownership will get control questions wrong in both directions.
The threshold and the aggregation rule come from the regime, not from the data. This is the point most worth internalizing. United States sanctions guidance treats an entity as blocked when blocked persons own it fifty percent or more in the aggregate, directly or indirectly — so two blocked owners at 30 and 25 percent combine. Customer due diligence rules for covered US financial institutions have historically worked from a twenty-five percent equity prong plus a separate control prong, applied per individual. Different thresholds, different aggregation, different question. One column cannot serve both, and a system that hard-codes a single number will be wrong for whichever regime it was not built for. Confirm the current text of any rule before you implement it; these move.
Cycles are real. Cross-shareholdings exist and a naive upward walk will loop forever or return whichever node it happened to stop at. Traversal must be cycle-aware, depth-bounded, and must be able to return the honest answer that no single ultimate owner exists.
Time is the hardest column
Ownership is a fact with a date, learned on a different date. Both dates matter and most schemas store neither.
Model every edge with two intervals. Valid time is the period the relationship actually held. Transaction time is the period your system believed it. That is the bitemporal pattern, and here it is not academic: an examiner asking why you cleared a payment in March is asking what the hierarchy looked like in March, using what you knew in March. Without transaction time, the only available answer is what you believe today, which is not responsive.
The practical consequences are small if you design for them and painful if you retrofit. Store the source, the source document, the as-of date and the retrieval date on every edge. Never update an edge in place; supersede it. Store absence explicitly — “the registry showed no shareholder record on this date” is information, and it is different from never having looked.
Then treat corporate events as first-class. A rename preserves identity; a merger does not, and the surviving entity inherits obligations but not necessarily the same identifiers. A redomiciliation changes jurisdiction and often the registration number while the business continues. If these arrive as attribute updates rather than as events, your history will show a company that has always been called whatever it is called now, which quietly breaks every backward-looking question.
How much of an ownership question a source can answer — our read
Our judgment of how far each source gets you on a legal ownership question, not a survey. Registries score low because most of them do not publish shareholders at all.
Two resolution problems, and only one is about names
Everyone arrives expecting a name matching problem. Half of it is, and that half is the easier half.
Entity resolution asks whether two records describe the same legal entity. The strongest evidence is a jurisdiction-scoped registration number, and where you have one the problem is nearly solved. Where you do not, normalize legal form suffixes across languages, strip and separately retain punctuation and diacritics, block on cheap keys such as normalized name tokens plus country, and score candidates on name similarity, address, incorporation date and officer overlap. Names alone are weak evidence: identical company names in different states are routine, and a large group will have twenty entities whose names differ by one word.
Relationship resolution asks which claim about an edge is true when sources disagree, and it is the part people skip. Sources disagree constantly — one says 100 percent, one says 51 percent, one is two years stale, one is describing the consolidation parent while another describes the shareholder.
Resolve it with per-attribute precedence rather than per-record precedence. A registry may be authoritative for legal name and status while a securities filing is authoritative for ownership percentage and a vendor is authoritative for nothing but valuable for suggesting where to look. Write the precedence down as configuration, apply it deterministically, and keep every losing claim attached to the edge with its source. When somebody asks why the system says 51 percent, the answer should be a query rather than an investigation.
Two rules make this survivable. Keep merges reversible — store the cluster decision as data with its evidence, never by overwriting the records, because you will be wrong about some of them and unmerging a destructive merge is a data recovery project. And make unresolved a valid state. A queue of two hundred genuinely ambiguous entities reviewed by a human is a functioning system. Two hundred confident wrong answers is not, and it looks better on every dashboard.
You probably do not need a graph database
Ownership is a graph, so the instinct is to buy a graph database. Usually you do not need one, and the honest version of this article says so.
At the scale most firms operate — hundreds of thousands to a few million entities, with hierarchies rarely deeper than a handful of levels — a recursive query in a mature relational database handles traversal comfortably, and you get transactions, bitemporal tables, ordinary reporting tools and staff who already know the language. The dominant cost in this work is source acquisition, resolution quality and review workflow. None of that gets easier with a different storage engine.
A graph store earns its place when variable-length path search is the product rather than a report — interactive exploration over a dense graph, shortest-path questions between arbitrary nodes, pattern queries over relationship shapes. If that describes what you are building, use one. If you are computing an ultimate parent nightly and joining it to exposure, materialize a table with the resolved parent, the full path, the method and the confidence, and refresh it nightly. It is faster to query, easier to audit, and trivially explainable to a reviewer.
Measuring whether the hierarchy is right
Almost nobody does this, which is why almost nobody can say how good their hierarchy is. It is not hard.
Build a gold set. Draw a random sample of entities — a few hundred is enough to be informative, stratified so that private, foreign and complex groups are represented rather than swamped by simple domestic ones. Have an analyst establish the true hierarchy from primary documents and record the evidence. This costs real hours once and pays for years.
Then measure three things separately, because they fail differently. Edge precision and recall: of the ownership edges the system asserts, how many are right, and of the true edges, how many did it find. Ultimate parent accuracy: how often the resolved top of the tree matches the adjudicated one. Honest unknowns: how often the system says it does not know, which should be a healthy nonzero number and should be reported rather than hidden.
The defect this exposes more than any other is the conflation of no parent found with no parent exists. A standalone company and a subsidiary whose registry does not publish shareholders look identical in a schema with one nullable parent column. One is a fact and the other is a gap, and treating the gap as a fact understates group exposure and misses sanctions ownership. Two columns, always: the parent, and the basis on which you concluded there is none.
Re-measure quarterly against the same gold set, refreshed for real corporate events. A hierarchy is a perishable asset, and the number that matters is not how good it was at launch.
The mistakes we see
- One parent column serving four different hierarchies, so two teams get two answers and both are right
- No parent found stored as no parent exists, which silently understates group exposure
- A single ownership percentage with no separate representation of control
- Indirect ownership computed by walking up instead of enumerating and combining paths
- A hard-coded threshold that answers one regulatory regime and is wrong for the other
- Edges updated in place, so last quarter's hierarchy cannot be reconstructed
- Renames and mergers applied as attribute updates rather than as dated events
- Purchased hierarchy fields cited as determinations, with no traceable evidence behind them
- No gold set, so nobody can state the accuracy of the thing everything else depends on
If you are starting this week
- Name the hierarchies you need and define each in one sentence
- Give ownership and control separate columns
- Store valid time and transaction time on every edge
- Record source, document, as-of date and retrieval date on every edge
- Snapshot current-state registries daily, starting now
- Make thresholds and aggregation rules configuration, not code
- Make traversal cycle-aware and depth-bounded
- Distinguish no parent found from no parent exists, in two columns
- Keep merges reversible and unresolved a valid state
- Build a stratified gold set and re-measure quarterly
Bottom line
Corporate hierarchy resolution is not primarily a graph algorithms problem. It is a problem of naming the question precisely, sourcing edges from documents you can point at, doing arithmetic that matches the regime you are answering to, and keeping enough history to reconstruct what you believed on the day you acted. Buy data for coverage, by all means. Keep the evidence, the dates and the reasoning on your own side of the line, because that is the part somebody will eventually ask you to show.
Frequently asked questions
You can buy coverage, and it is often worth it. What you cannot buy is defensibility: a vendor's global ultimate is their research product, and when someone asks for the basis of a determination, “the file said so” is not an answer. The workable pattern is to use purchased hierarchy as a candidate generator and a completeness check, then attach your own evidence for the entities where the answer carries consequences.
It depends entirely on which question you are asking, which is the whole point. Sanctions ownership tests, customer due diligence rules, accounting consolidation and credit aggregation use different thresholds and different aggregation logic, and they are set by regulators rather than by your data model. Keep the thresholds in configuration, keep the raw percentages and control facts in the data, and confirm the current rule text at its source before implementing it.
Deep enough to answer the question, with the depth stated. For a sanctions ownership test you generally follow paths until the aggregate crosses the threshold or the path terminates, which can be many levels. For credit aggregation, the group boundary is usually a policy decision rather than a graph one. Whatever you choose, bound the traversal, record the depth reached, and flag entities where the search hit the bound rather than a real terminus — those are exactly the ones a reviewer should see.
Yes. Every external identifier is scoped to somebody else's universe, and you will need to attach records that have none. Mint an internal identifier that is stable across renames and never reused, then map external identifiers to it many-to-one with dates. The mapping table is where corporate events, vendor reassignments and your own merge decisions live, and it is worth more over time than any single source.
More often than people expect. If you have a few thousand counterparties concentrated in one or two jurisdictions, two analysts with the free registries, a spreadsheet with dated evidence and a review queue will beat a purchased hierarchy on the entities that matter. The engineering becomes worth it when volume, jurisdictional spread or refresh frequency makes manual review impossible — not before.