Entity Resolution and Ownership Graphs: Why Most Mapping Failures Aren’t Data Failures
Most teams debugging a broken ownership graph start by questioning the ownership data. They re-pull the shareholder filing, re-check the percentage, re-read the corporate registry extract. The data is usually fine. The break sits one layer earlier: the system never established that “Acme Corp Ltd” in the UK registry and “ACME CORPORATION LIMITED” in a German shareholder filing are the same legal entity. So the graph silently forks into two nodes instead of one, and every ownership percentage downstream gets attached to the wrong half of a company that never should have been split. This is entity resolution — the unglamorous matching layer underneath every cross-border ownership map — and it fails far more often than the ownership data it’s blamed for.
01The graph isn’t lying. It’s disconnected.
An ownership graph is only as good as the identity layer beneath it. Every node in that graph is supposed to represent one legal entity. Every edge is supposed to represent one ownership relationship between two of those entities, sourced from a registry, a filing, or a disclosure. When the percentages look wrong — a beneficial owner who seems to hold less than they should, a chain that dead-ends where it shouldn’t — the instinct is to audit the ownership data itself.
That instinct is usually misdirected. Entity resolution is the process of deciding whether two records from different sources describe the same real-world entity. Get it wrong and the ownership data was never wrong at all — it was correctly extracted, correctly transcribed, and then attached to a node that shouldn’t exist, because the matching logic upstream failed to recognize that two name strings referred to one company.
A beneficial owner (ultimate beneficial owner, or UBO) is the natural person who ultimately owns or controls an entity — distinct from a legal owner, which can be another company, a trust, or a nominee holding shares on someone else’s behalf. Entity resolution operates one layer below both concepts: before a system can say who owns what, it has to agree on what “what” even is.
02What entity resolution actually is
Entity resolution is not deduplication, and it is not identity resolution in the customer-data sense. Deduplication assumes records already live in one clean schema and just need collapsing. Identity resolution, as marketing and product teams use the term, links behavioral signals — cookies, device IDs, emails — to a single person across sessions. Corporate entity resolution is closer to record linkage across heterogeneous, adversarial, badly standardized sources: registries that don’t share an ID scheme, filings that transliterate names differently, addresses formatted to three different national conventions, all describing entities that sometimes deliberately obscure the fact that they’re the same one.
The task, stated precisely: given two company records from different sources, decide — with a defensible, auditable basis — whether they represent one legal entity or two. Every downstream step in a KYB (know-your-business) workflow depends on getting this right first. Sanctions screening depends on it. Ownership percentage aggregation depends on it. Ultimate beneficial owner identification depends on it, because a UBO calculation that treats one entity as two will systematically understate every indirect stake that runs through it.
03A worked example — illustrative, not a real case
Consider an illustrative example, built for this article and not describing any real company: a UK holding entity appears under three name variants across two jurisdictions’ filings. In the UK companies registry, it is recorded as Acme Corp Ltd, registration number 04582231, registered address 12 Fenwick Road, London. In a German subsidiary’s shareholder filing, the same parent is listed as ACME CORPORATION LIMITED, address written as “Fenwick Road, London GB”. In an Italian registry extract for a third subsidiary, the parent appears as Acme Corp., address transliterated as “12 Fenwick Road, Londra, UK”.
A naive matcher — one that scores similarity on the name string alone — fails here in a predictable way. “Acme Corp Ltd” and “ACME CORPORATION LIMITED” share only the word “Acme” and a legal-form suffix that doesn’t even match token-for-token (“Ltd” vs. “Limited”, “Corp” vs. “Corporation”). Depending on the similarity threshold, the matcher either merges them on a weak signal and hopes, or — more commonly, when thresholds are set conservatively to avoid false merges — treats them as two unrelated entities. “Acme Corp.” adds a third variant with a different truncation and a transliterated city name, compounding the problem.
Correct resolution ignores the name string as a primary signal and works from three harder identifiers instead: the UK registration number 04582231, which appears (in some form) in all three filings; the normalized address, which collapses “12 Fenwick Road, London” and “Fenwick Road, London GB” and “12 Fenwick Road, Londra, UK” into one canonical postal record once city-name transliteration and country-suffix noise are stripped; and cross-registry ID linking, where the German and Italian filings both cite the UK registration number as the parent’s foreign identifier. Only after those three converge does the system treat the name string as confirming evidence, not deciding evidence.
Nothing about the underlying ownership data changed between the two outcomes. The 40% stake and the 35% stake were both correctly extracted in both scenarios. What changed is which node they were attached to — and whether a screening system, an escalation workflow, or a UBO calculation could see that they belonged together.
04Why cross-border resolution is a harder problem than same-registry resolution
Inside a single registry, entity resolution is close to solved. Companies House assigns one registration number per entity and every filing against that entity cites the same number. Matching within that system is closer to a database join than a data-science problem. Cross-border resolution has none of that luxury, and the difficulty compounds across four distinct sub-problems — not one generic “fuzzy matching is hard” problem, but four separate failure modes that each need their own handling.
Name-string and legal-form-suffix divergence
“Ltd”, “Limited”, “GmbH”, “S.r.l.”, “SA”, “Inc.” and “Corp.” are legal-form markers, not brand identity, and a filing clerk in one jurisdiction transcribing a foreign parent’s name has no obligation to preserve the exact form used in the entity’s home registry. The result is that the same entity can appear with its legal suffix spelled out, abbreviated, translated, or dropped entirely, depending on who typed it and where.
Transliteration and script conversion
Names crossing between Latin, Cyrillic, Arabic, or CJK scripts don’t have one canonical romanization. A company name transliterated from Chinese or Arabic into a Latin-script filing can legitimately produce several different, all-correct spellings depending on the romanization standard used, and no amount of edit-distance tuning on the Latin-script strings alone recovers that they’re the same underlying name.
Registration-number format incompatibility
Every jurisdiction has its own registration-number format, length, and check-digit scheme, and most don’t reference each other’s. A UK company number, a German Handelsregister number, and a US state EIN describe the same class of thing — a unique registry identifier — but there is no universal lookup table that maps one to another. Cross-registry linking depends on one filing explicitly citing the other jurisdiction’s number, which happens inconsistently and is exactly the kind of field that gets typed wrong.
Address normalization across postal systems
Street-number-then-name ordering, unit conventions, city-name transliteration, and postal-code formats all vary by country, and the same physical address can be written correctly in half a dozen non-identical ways. Address matching across borders requires normalizing to a common representation before comparison is even meaningful — comparing raw strings produces false negatives on identical addresses and occasional false positives on different buildings on the same well-known street.
None of these four problems is intractable on its own. What makes cross-border resolution categorically harder than same-registry resolution is that all four compound simultaneously, on the same record, with no single field reliable enough to anchor a match by itself.
05Ranking the signals: what to trust when name strings disagree
Not every field carries equal evidentiary weight. A resolution pipeline that treats a name-string match the same as a registration-number match will produce confident, wrong merges. Ranked roughly by reliability, independent of jurisdiction:
| Signal | Reliability | Where it fails |
|---|---|---|
| Registration number | Highest — unique within its issuing registry | No cross-registry standard; only works when a filing explicitly cites the foreign number |
| VAT / tax ID | High — usually one per entity per country | Entities can hold several VAT IDs across tax jurisdictions; not always disclosed |
| Normalized address | Medium-high — strong corroborating signal | Registered-agent addresses are shared by thousands of unrelated entities |
| Director / officer overlap | Medium — useful corroboration, not proof | Shared officers occur across genuinely unrelated group entities and nominee arrangements |
| Name string (normalized) | Low-medium — confirms, rarely decides alone | Legal-form suffixes, transliteration, abbreviation, and unrelated entities sharing a common brand name |
| Raw name string (unnormalized) | Lowest — string similarity only | Everything above, plus formatting noise and punctuation |
06Registration numbers are the strongest signal — and where even they break
A registration number is unique within its issuing registry, immutable for the entity’s lifetime in almost every jurisdiction, and unambiguous in a way no name string can be. That makes it the anchor signal for cross-registry resolution whenever it’s available. But “available” is doing a lot of work in that sentence: a registration number only resolves an entity across borders when a second filing explicitly cites it, and plenty of shareholder disclosures record a foreign parent by name only, with no registry reference at all.
This is the gap that identifier standards like the Legal Entity Identifier (LEI) exist to close. The Global LEI Foundation (GLEIF) maintains a single, jurisdiction-agnostic identifier that any registered entity can obtain, precisely so that two filings in different countries can reference the same code instead of relying on the receiving jurisdiction to correctly transcribe a foreign registration number. Adoption is real but partial: LEI coverage is strong in regulated financial counterparties and thin almost everywhere else, which means for most operating companies, resolution still runs on national registration numbers, VAT IDs, and address matching — the imperfect signals in the table above, not a universal key.
07A confidence score isn’t the same as a correct answer
Every practical resolution system outputs a match score, not a binary truth. The score has to be interpreted against two distinct failure costs, and conflating them is where most tuning mistakes happen.
A false merge treats two different entities as one. In an ownership graph, this collapses two separate companies’ shareholder lists into a single node, understating true ownership concentration for one entity and fabricating it for the other. In sanctions screening, a false merge can clear a genuinely sanctioned entity because its record got blended with an unrelated company’s clean history — or, in the other direction, flag a clean company because it absorbed a sanctioned entity’s record.
A false split treats one entity as two. This is the failure mode in the worked example above: the ownership graph forks, percentages attach to the wrong half, and a UBO calculation that should aggregate an indirect stake across both halves instead sees two unrelated, sub-threshold holdings.
| Variant type | Typical failure | Direction of error |
|---|---|---|
| Legal-form suffix (Ltd/Limited/GmbH) | Similarity score drops below merge threshold | False split |
| Transliteration / script conversion | Romanized forms score as unrelated strings | False split |
| Shared brand name, different entity | High string similarity between unrelated companies | False merge |
| Registered-agent shared address | Thousands of entities share one address string | False merge |
| Abbreviation / truncation | Token overlap too low for automatic match | False split |
Tuning a resolution system toward one failure mode necessarily loosens tolerance for the other. There is no threshold setting that eliminates both; there is only a defensible choice about which error a given workflow can tolerate, made explicitly rather than inherited by default from whatever similarity library shipped with a sensible-looking cutoff.
08Where the damage concentrates: cross-border, multi-layer structures
Resolution failures aren’t evenly distributed across a portfolio. They concentrate exactly where the four cross-border sub-problems from section four compound: multi-layer ownership structures that span registries. In a live sample of 250 companies queried directly on 2026-09-30 — stratified 25 each across the ten countries most represented in Zavia’s index (the US, New Zealand, the UK, the Netherlands, Germany, Italy, Singapore, Spain, France, and Ireland) — 177 companies — 70.8% — carry a real multi-entity ownership structure. Where one exists, average depth is 4.73 layers, 76% run three or more layers, and 62% cross two or more countries.
Methodology note. These figures replace an earlier analysis of a smaller, differently composed 6,210-company snapshot, which reported 26.5% multi-entity prevalence, 3.74-layer average depth, and a 64% cross-border share. The cross-border share held roughly steady (64% then vs. 62% now), but the live sample’s concentration in ten large, internationally active jurisdictions surfaces a higher share of companies with a real multi-entity structure (71% vs. 26.5%) and with any public shareholder disclosure (43% vs. 14%) — a difference in sample composition, not a change in what the underlying registries publish.
That overlap isn’t a coincidence worth treating lightly. The same structural feature that makes a corporate group harder to untangle — multiple jurisdictions, multiple layers, multiple registries each with their own formatting conventions — is the structural feature that breaks name-string matching. A resolution pipeline tuned and tested against domestic, single-registry entity pairs will look accurate in aggregate while failing disproportionately on the minority of structures that carry most of the actual ownership complexity, and most of the compliance risk.
46 of the same 250 companies — 18.4% — yield at least one named natural-person shareholder in the public record. In most of those cases, that person is reached only after correctly resolving at least one intermediate entity in the ownership chain, so an unresolved intermediate breaks the chain before it reaches a name.
Resolution is only as reliable as the identifiers available to anchor it, which is why Zavia connects directly to official company registries in 173 countries rather than aggregating third-party name-matched records: pulling registration numbers, addresses, and filings at the source reduces the number of resolution decisions made on name strings alone, because the stronger signals in the table above are present in the source data from the start.
09Auditing your own resolution pipeline: a procedure
Before trusting an ownership graph, or blaming its data, run these five checks against the resolution layer that built it.
1. Pull ten resolved cross-border matches and check which signal decided each one. If more than a handful resolved on name-string similarity alone, with no registration number, VAT ID, or address corroboration, the pipeline is under-anchored.
2. Check the normalization step for scripts and legal-form suffixes. If the pipeline compares raw, unnormalized strings, transliteration and suffix variance are producing false splits it can’t see.
3. Sample the false-split rate directly, not just the false-merge rate. Most tuning conversations focus on avoiding bad merges, because a bad merge is visible and embarrassing. False splits are invisible by default — they just look like two small, unremarkable holdings instead of one large one.
4. Trace one multi-layer chain end to end and verify every intermediate node against its source registry. A single unresolved intermediate entity breaks the chain from that point outward, regardless of how correct every other node is.
5. Confirm registered-agent and shared-service addresses are excluded from address-based matching. An address shared by thousands of shell entities registered through the same agent is a false-merge risk if treated as a strong signal instead of a neutral one.
10Where automation should stop and a reviewer should start
Not every match belongs to a machine. Three situations warrant routing to a human reviewer rather than an automatic threshold decision, regardless of how confident the score looks.
Group reorganizations and name changes. A holding company that legally renamed itself, merged with a sibling entity, or re-registered in a new jurisdiction produces a filing history that looks, to a matcher, exactly like two unrelated entities followed by a plausible-but-unconfirmed link. Corporate registries record the legal event; a resolution pipeline has to be told to look for it.
Name-only shareholder disclosures with no registry reference. When a filing lists a foreign parent by name alone, with no registration number and no address beyond a city, no amount of normalization manufactures the missing identifier. These cases should surface as unresolved, with a documented reason, rather than get force-matched on name similarity to close out a queue.
Joint ventures and dual-registered entities. Some entities are legitimately registered in more than one jurisdiction under different local requirements, and are not duplicates to be merged — they’re one entity with two registry footprints by design. Treating that as a false split to fix produces the opposite error: conflating a legitimately dual-registered structure with something it isn’t.
11The compliance cost of getting resolution wrong
A resolution failure doesn’t announce itself as a resolution failure. It shows up as a UBO who appears to hold 12% when the real aggregate, once every entity variant is correctly linked, is 38% — crossing a disclosure or escalation threshold that the fragmented view never triggered. It shows up as a sanctioned entity’s clean subsidiary getting flagged because a false merge blended two unrelated companies’ histories. It shows up as an investigator spending hours manually reconciling three registry printouts that a correctly resolved graph would have shown as one node from the start.
None of these failures are visible in isolation. Multi-layered, cross-border ownership structures are already harder to risk-score correctly — a challenge covered in depth in Multi-Layered Corporate Structures: A Risk-Scoring Framework for Escalation Decisions — and every one of those frameworks assumes the entities feeding it were correctly matched in the first place. The same is true of circular ownership analysis: detecting a loop, as described in Circular Ownership Structures: How Companies Use Loops to Hide Beneficial Owners, requires recognizing that entity X at the end of a chain is the same entity X at the start of it. A false split breaks that recognition and hides the loop entirely; the structure looks like a simple chain instead of a circular one, and it stops looking like a red flag.
12Resolution infrastructure isn’t a side project
Teams that build KYB or ownership-mapping products routinely underestimate entity resolution as an afterthought to sourcing the ownership data itself, then discover it consumes as much engineering effort as everything else combined — normalization rules per jurisdiction, blocking strategies that scale to millions of candidate pairs, review queues, and ongoing tuning as registries change their formatting. The tradeoffs mirror a broader question covered in Build vs. Buy: Why Verification Platforms Don’t Build Their Own Registry Data Layer: resolution logic built against a handful of familiar registries rarely generalizes to the formatting conventions of a hundred more, and every new jurisdiction added is a new set of name conventions, address formats, and registration-number schemes to handle correctly, not just a new data source to plug in.
This is also why coverage breadth matters for reasons beyond raw data volume. The Global Ownership Data Index catalogs what’s publicly available registry by registry — and jurisdictions that disclose more shareholder detail, like those covered in EU Beneficial Ownership in 2026 and UK Beneficial Ownership & UBO Data, are exactly the registries most likely to reference foreign parent entities by name, registration number, or both — making them simultaneously the richest source of ownership detail and the highest-volume source of cross-border resolution decisions. More disclosed detail is only useful if the resolution layer beneath it can correctly link every entity that detail refers to; otherwise richer disclosure just produces more, smaller-looking fragments instead of one accurate picture, undermining the very UBO verification process the disclosure was meant to support.
Fix the layer beneath the ownership graph
Zavia connects directly to official company registries in 173 countries, so the identifiers that make resolution reliable — registration numbers, addresses, filings — are there from the source, not reconstructed from name strings after the fact.
13Glossary
14Frequently asked questions
What is entity resolution in the context of KYB and ownership data?
It is the process of determining, using identifiers like registration numbers, addresses, and cross-registry references rather than name strings alone, whether two company records from different sources describe the same legal entity. In KYB (know-your-business) workflows, it is the prerequisite step that every ownership aggregation, sanctions screening, and UBO calculation depends on.
How is entity resolution different from simple deduplication?
Deduplication typically operates on records already in one consistent schema and looks for exact or near-exact duplicates. Entity resolution operates across heterogeneous sources — different registries, different languages, different formatting conventions — where the same entity can legitimately appear in dozens of non-identical forms, and where sources sometimes have an incentive to obscure the connection.
Why does entity resolution matter more for cross-border ownership structures?
Within a single registry, matching is close to a database join because every filing cites the same registration number. Across borders, name-form conventions, transliteration, incompatible registration-number formats, and address-formatting differences compound on the same record, and a live sample of 250 companies (queried 2026-09-30) shows 62% of companies with a real multi-entity ownership structure already cross two or more countries — exactly where these problems concentrate.
What is the difference between a false merge and a false split?
A false merge incorrectly treats two distinct entities as one, which can blend a clean company’s history with a risky one’s. A false split incorrectly treats one entity as two, which fragments ownership percentages across nodes that should be combined and can hide the fact that a combined stake crosses a disclosure threshold.
Which identifiers are most reliable for matching companies across registries?
Registration numbers and VAT or tax IDs are the strongest signals when available, followed by normalized addresses and officer overlap as corroborating evidence. Name strings, even normalized ones, should confirm a match rather than decide one, because legal-form suffixes, transliteration, and shared brand names make name-only matching unreliable on its own.
Does the Legal Entity Identifier (LEI) solve cross-border entity resolution?
Where adopted, an LEI is a strong cross-border anchor because it is jurisdiction-agnostic and issued under a single global standard maintained by GLEIF. Adoption is concentrated in regulated financial counterparties, though, so most operating companies still have to be resolved using national registration numbers, VAT IDs, and address matching rather than a universal identifier.
Can entity resolution be fully automated?
Most high-confidence matches can be, provided the pipeline is anchored on registration numbers and other strong identifiers rather than name similarity. Group reorganizations, name-only shareholder disclosures with no registry reference, and legitimately dual-registered entities are cases that warrant human review rather than an automatic threshold decision, regardless of how confident the similarity score looks.
Why do most ownership-mapping failures turn out to be entity-resolution failures rather than data failures?
Because the ownership percentages themselves are usually extracted correctly from the source filing; what fails is recognizing that two filings, in different formats and possibly different scripts, refer to the same underlying company. When that recognition fails, correct data ends up attached to the wrong node, which looks identical to a data quality problem until the resolution layer is specifically audited.
The disclosure-rate figures referenced throughout this piece come from two companion live-data analyses: How Many Companies Actually Disclose Their Owners? and Legal Form and Ownership Transparency. For what a resolution failure looks like in practice, see Shell Company Red Flags and Sanctions Screening and Beneficial Ownership, both of which depend on matching the right entity before anything else works.
Detecting that an ownership stake changed in the first place is only useful if something keeps checking after onboarding — the operating model for that ongoing re-verification is covered in Perpetual KYC: Why One-Time Verification Isn’t Enough Anymore.
Resolving the right entity is also step one of a full Know Your Business program — see Know Your Business (KYB): What It Actually Is, and How It Differs from KYC for how entity verification feeds the UBO identification, sanctions screening, and ongoing monitoring steps that follow it.
\n
