Entity resolution for corporate-family links needs evidence, not just matching

Entity resolution is easy to under-specify when the real question is corporate-family exposure. Matching “Acme Limited” to “ACME LTD” is one job. Deciding whether a small supplier, a holding company and a listed parent sit in the same group is another job, because the correct answer may not appear in either company name.

A recent public benchmark made that distinction hard to ignore. It tested supplier-parent links drawn from federal award records and found that links with no visible name overlap were often lost before scoring. For KYB, credit and procurement teams, the weak point is not only the matcher; it is the candidate set the matcher is allowed to see.

A duplicate match asks whether two records refer to the same legal entity. A corporate-family link asks whether different entities are connected through ownership or control. Those are not interchangeable. A branch record, a subsidiary, a contracting vehicle and a parent can all be valid records, each with its own identifier and filing history.

The common failure is to collapse the records too early. If a system turns a subsidiary into the parent’s golden record, it can misstate who signed a contract, who files accounts and which registry record supports the decision. Keep the supplier identity intact, then add group context as a separate relationship.

• Resolve the contracting party first, using jurisdiction and registration identifiers where available.
• Attach parent or subsidiary links as relationships, not replacements for the legal entity.
• Store whether the relationship came from a registry, filing, customer assertion or modelled inference.

Many entity resolution systems compare names, addresses, domains, phone numbers and other attributes, then assign a score. That helps with messy records, but it does not solve invisible relationships. A procurement system may see “Blue Aerospace LLC” and “Heico Corp” with no shared token, while the relationship sits in a filing or award-registration field outside the two records being compared.

That means the first design question is retrieval: which sources are searched before scoring begins? For example, SAM.gov registration data uses legal business name, physical address and a Unique Entity ID, while federal spending data exposes recipient and award endpoints. SEC subsidiary exhibits can add another view for listed parents, but they can omit non-significant subsidiaries under the rule.

Build the workflow as four gates. First, resolve the exact legal entity. Second, retrieve candidate relationships from identifiers, filings, award data and other permitted sources. Third, score the candidate relationship using attributes and evidence quality. Fourth, decide whether to accept, reject or route for review.

This pattern also fits a company data api integration. CompanyProof, for example, separates company identity, shareholders, group structures, financials and source context where the relevant module and jurisdiction support them. The integration decision is to preserve the boundary between observed facts and relationship confidence rather than hiding both inside one match label.

• Pass: the identifier and relationship evidence agree, and the source scope is current enough for the decision.
• Review: the company matches, but the parent link is asserted, old, partial or from a source with known omissions.
• Reject: the only evidence is loose name similarity or a parent name copied from an unrelated record.

A useful audit trail should show what was matched, what was merely associated and what remained unproven. Log the supplier’s legal name, registration number, jurisdiction, procurement identifier and the selected parent candidate. Then log the source, retrieval time, source date where supplied and the reason the relationship was accepted or challenged.

This is especially important for ongoing supplier due diligence. Parent relationships can change through acquisitions, restructurings, spinouts or simple filing updates. A stale link can distort sanctions screening, concentration limits, conflict checks and credit exposure, even when the supplier’s own legal identity is still correct.

Most search results for company matching and entity resolution explain how to deduplicate or create a golden record. The harder enterprise question is different: how do you prove a relationship when the two names do not look related? The answer is to make relationship retrieval a first-class workflow, not a back-office exception.

Teams should test their pipeline with three strata: identical or near-identical names, shared distinctive tokens and no visible name overlap. If the last group is missing from evaluation, aggregate accuracy can look healthy while the risk cases vanish. Start with documented fields, source scope and review thresholds before tuning another similarity model.

Consider a hypothetical manufacturer buying components from Northbridge Components Limited. Its purchasing system contains a second record called Northbridge Components Ltd and a third called Meridian Industrial Holdings. The first two might describe the same legal entity. The third could be a parent, an unrelated business or an outdated association. The purchasing team should answer those questions separately. Similar spelling is a reason to investigate a duplicate; it does not establish that a holding company owns the supplier. Equally, a different name is not a reason to exclude a potential parent from the investigation.

Start with the supplier record that actually appears on the contract. Record its jurisdiction and registration number, then compare those identifiers with the second record. If they identify the same entity, propose a controlled duplicate merge while preserving purchase history and original identifiers. If the identifiers differ, retain both records and investigate why. A shared address may reflect a group office, a service provider or a coincidence. It is useful context, but the workflow should not turn it into an ownership conclusion without additional evidence.

Now investigate Meridian as a separate relationship candidate. Suppose an available filing identifies Meridian as the immediate parent, while an older supplier questionnaire names a different holding company. Keep both observations and their dates. Ask whether the filing describes a direct ownership relationship, a consolidated reporting group or another connection. Record the relationship that the evidence actually supports. A direct parent is not automatically the ultimate parent, and neither label establishes the identity of a natural-person beneficial owner. If the chain continues through another entity, create another investigation step.

The resulting record should show the resolved supplier, the proposed parent, the relationship type and the review outcome. A reviewer must be able to accept the supplier identity while leaving the parent relationship unresolved. That distinction lets procurement continue an appropriate onboarding step without silently treating a partial group structure as complete. If the missing relationship is essential to the proposed decision, hold that decision until the evidence is sufficient. The point is to make uncertainty actionable at the individual fact level, with a named owner and a clear next check.

An evaluation should begin with a reviewed set of known relationships. Divide it into cases with obvious name overlap, partial overlap and no useful name overlap. Keep incorrect candidate relationships in the evaluation as well, because a system that links everything can appear successful if only recall is measured. Record which known relationships entered the candidate set, which were accepted and which were missed. These are different stages of failure. A relationship that never reaches the scorer cannot be recovered by changing the scoring threshold.

The first interactive graph below isolates that problem. Its inputs describe a hypothetical evaluation containing 1,000 true relationships. Candidate retrieval determines how many of those relationships reach the next stage. Conditional acceptance determines how many retrieved true relationships the next stage correctly accepts. With 70 per cent retrieval and 90 per cent conditional acceptance, the workflow recovers 630 relationships and misses 370. Raising conditional acceptance to 95 per cent recovers 665. Raising retrieval to 90 per cent while keeping conditional acceptance at 90 per cent recovers 810. These are calculations from the selected assumptions, not measured results for CompanyProof or any provider.

Use the graph to ask where an improvement programme should focus. If evidence retrieval is excluding whole classes of subsidiaries, another round of name-score tuning may have little effect. If retrieval is broad but wrong relationships pass, the priority may be evidence requirements or review controls. Precision must be measured separately: divide correctly accepted relationships by all accepted relationships, including wrong ones. The graph does not estimate precision, because its hypothetical population contains only true relationships. Do not interpret its recovery percentage as accuracy or as a recommended acceptance threshold.

For a real evaluation, freeze the input records and record the version of the rules being assessed. Have a reviewer establish the expected answer without seeing the proposed model result where practical. Separate development examples from the final evaluation set. Report performance by jurisdiction, relationship type and name-overlap group, alongside an unresolved category. When the evidence does not establish a relationship, preserve that uncertainty in the expected answer. Forcing every ambiguous case into a yes-or-no label can make the evaluation less reliable than the workflow it is supposed to assess.

Manual review is an operating cost that should be designed into the workflow. Before accepting a vendor demonstration, define the number of incoming cases, the proportion expected to require review and the time needed to resolve an exception. Ask which evidence will be presented to the reviewer and which additional checks they will need to perform. A queue containing only company names and a confidence score leaves the reviewer to reconstruct the investigation. A queue containing identifiers, relationship evidence, conflicting observations and timestamps offers a clearer starting point.

The second interactive graph calculates review hours from three editable assumptions: monthly cases, the percentage sent for review and minutes per reviewed case. At 5,000 cases, a 15 per cent review rate and eight minutes per case, the workload is 100 hours. The graph compares that selected rate with rates five percentage points lower and higher, bounded between zero and 100 per cent. It does not predict how a change in threshold will affect accuracy. A lower review rate can reflect better evidence, a less cautious policy or missed exceptions; the workload calculation cannot tell you which.

Use the result to discuss capacity with the team that owns the queue. Decide how urgent cases are prioritised, who can resolve a conflicting parent link and what happens when evidence remains unavailable. Measure review time from actual cases before using it for staffing decisions. Keep queue age separate from hands-on review time, since waiting for an external document can dominate elapsed time. If the queue grows, investigate the reason rather than automatically lowering the review threshold. Repeated failures in one jurisdiction may call for a different retrieval step or a narrower supported decision.

Finally, define the events that reopen a previously accepted relationship. A new filing, a conflicting customer update or evidence of a restructuring should prompt a targeted check of the affected link. Preserve the earlier decision and its supporting observations, then create a new outcome with its own time and reviewer or rule version. Downstream users need to know whether the legal entity changed, the parent relationship changed or only the available evidence changed. Those outcomes require different actions. A useful first deployment therefore combines identity resolution, relationship investigation, a review queue and a controlled way to revisit decisions as information changes.