Entity resolution connects records that refer to the same real-world person, organisation or object. Its value is not the number of records matched; it is the quality of the decisions made after the match. In banking, a mistaken link can distort exposure, create an unwarranted suspicion or send a customer through an unnecessary review. A missed link can hide a relationship that matters.
This report combines three historical studies into a single framework, refreshed with current GLEIF context. Private identities are removed. Unmatched price references and commissioned return claims are excluded from the current comparison.
Resolution, master data and graph investigation are different
A resolution engine evaluates whether records represent the same entity. A master-data platform establishes governed records, stewardship and distribution across systems. A graph-investigation platform helps users explore relationships and patterns. An integrated decision platform may combine all three with workflow and analytics.
These products overlap, but their centre of gravity matters. An embeddable resolution engine may be ideal when the institution already has its own data platform and investigation tools. A master-data platform may be preferable when the main problem is inconsistent customer records across business systems. A graph platform may be valuable when analysts need to investigate networks rather than simply deduplicate a database.
Distinguish identity resolution, master data and graph investigation
| Capability | Primary question | Evidence of success |
|---|---|---|
| Entity resolution | Which records refer to the same entity? | Precision, recall and explainable links |
| Master-data management | Which attributes should systems use? | Governed records, stewardship and distribution |
| Graph investigation | Which relationships matter to this case? | Useful context, traceable paths and analyst outcomes |
| Decision orchestration | What action follows the evidence? | Controlled workflow and reproducible decisions |
Matching is probabilistic and contextual
Exact identifiers can be strong evidence, but they are not always complete or reliable. Names change, addresses are shared, dates are entered incorrectly and corporate structures evolve. A good engine combines evidence while preserving uncertainty.
False merges and false splits have different costs. Merging two unrelated customers can contaminate risk assessments and expose information across a boundary. Splitting one customer into several identities can understate exposure or hide connected activity. The threshold should reflect the use case rather than one universal target.
Context matters. A shared office address is weaker evidence for corporate identity than a verified registration identifier. A common surname carries different information from an unusual combination of attributes. The system should explain which evidence contributed to a link and support correction when the evidence changes.
Resolution should also be reversible. If a link is later found to be wrong, the institution needs to separate the records and identify affected decisions. A permanent merge that destroys source provenance makes correction much harder.
Figure 01 · Conceptual framework
From fragmented records to governed identity
The golden record is not the whole truth
A master record is a governed view assembled for a purpose. It should not erase the original records or the differences between them. One source may hold a legal name, another a trading name and another a historical address. All can be relevant.
Attribute selection needs rules: which source is authoritative for which field, how conflicts are handled and when a value becomes stale. Stewardship is the operating process that applies those rules and resolves exceptions. Without it, a master-data platform can become a more expensive repository of unresolved disagreement.
Time is important. Ownership, directorship and address relationships change. A present-day graph should not be projected backwards without evidence. Investigations and historical exposure analysis may require the relationship as it existed at a particular date.
Graph context can improve financial-crime and risk work
A transaction can appear ordinary in isolation while forming part of a suspicious network. Shared beneficiaries, directors, addresses, devices or counterparties may reveal relationships that a row-based review misses. Entity resolution provides the identity foundation; graph analysis makes the connections usable.
The benefit is conditional on data quality and investigative discipline. Dense graphs can create impressive visualisations without establishing relevant evidence. A link should have a type, source, confidence and time period. Analysts need to distinguish direct ownership from a weak shared attribute.
The source studies also discussed applications outside financial crime: client intelligence, credit exposure, trade finance, operations and data preparation for AI. These uses share an identity foundation but should not automatically share all data or permissions. A valid analytical link does not create an unrestricted right to use the underlying information.
Evaluate on the buyer’s difficult data
A supplier demonstration built on clean records can overstate performance. Use representative multilingual names, missing fields, legacy identifiers, changing legal structures and duplicated records. Include difficult negatives that look similar but must remain separate.
Create a labelled evaluation set with documented review. Preserve a holdout population so tuning does not simply memorise acceptance examples. Measure both false merges and false splits, and assess their consequences in the intended workflow.
Performance should also include incremental updates. A platform may resolve a static batch well but struggle when records arrive continuously or relationships change. Test how new evidence affects prior links, how exceptions are assigned and how downstream systems receive corrections.
Explainability should be operational. An analyst needs a concise reason for a match, access to supporting evidence and a controlled way to challenge it. A technical score with no interpretable basis may be insufficient for a regulated decision.
Figure 02 · Qualitative comparison
Identity layers should remain distinct
| Approach or concept | What it contributes | What still matters |
|---|---|---|
| Entity resolution | Links records referring to the same entity | Matching remains contextual and uncertain |
| Master data | Maintains an authoritative operational record | A golden record does not erase source disagreement |
| Graph investigation | Explores relationships and surrounding context | A connection does not by itself establish wrongdoing |
Integration often dominates the economics
Historical programme estimates retain their original scope and qualifications
| Aspect | Retained observation |
|---|---|
| proof of concept | The source’s June 2026 planning ranges included roughly USD 200,000–1 million for a proof of concept, |
| production domain | USD 2–5 million or more for a production domain |
| multi-region or multi-business deployment | and USD 10–25 million or more for multi-region or multi-business deployment. |
| Wider transformations | Wider transformations could exceed USD 25 million. |
These are order-of-magnitude programme estimates with broad scope variation.
They include more than a matching engine: data ingestion, identity mapping, stewardship, graph design, validation, access controls, workflow integration and operating change. A small software component can sit inside a large transformation because the institution’s data and process problems are extensive.
Costs that remain after the identity platform is built
| Cost area | Why it persists after the initial build |
|---|---|
| Source integration | New systems and changing schemas require maintenance |
| Data quality | New errors and conflicting records continue to arrive |
| Stewardship | Ambiguous identities need accountable review |
| Compute and storage | Graph size, history and query patterns change |
| Validation | New data and model versions can alter match behaviour |
| Workflow integration | Decisions and corrections must reach operating systems |
The business case should identify which duplicated activity disappears and which new responsibilities remain. A platform can improve control and service without producing an immediate reduction in staff expenditure.
Compare a controlled service perimeter
The inherited USD 141,000-per-core and USD 35,000-per-core references and sponsored 228% ROI claim are omitted from the current comparison. Without matched units, dates, scope, minimums and counterfactual costs, those figures create false precision. Obtain equivalent offers and compare the complete cost of data preparation, resolution, stewardship, integration and correction.
A 2026 primary example of the emphasis on governed data is GLEIF’s January account of its data-quality programme. It describes ongoing quality reporting and AI-assisted legal-form checks, alongside plans for stronger interoperability. This supports the direction of travel toward verifiable identity infrastructure; it is not evidence of a particular bank’s matching accuracy or commercial return.
Use a synthetic acceptance example to separate errors: if 1,000 predicted links contain 980 correct matches, precision is 98%. If the test set contains 1,200 true matches, recall is 980/1,200, or 81.7%. High precision can coexist with many missed relationships. The appropriate threshold depends on the cost of false merges and false splits in the decision being supported, and must be measured on representative labelled evidence.
Figure 03 · Conceptual framework
Should two records be merged?
How the parts connect
- Candidate identity linkPath AStrong consistent evidence
- Candidate identity linkPath BAmbiguous or conflicting evidence
- Strong consistent evidenceReviewStewarded identity record
- Ambiguous or conflicting evidenceReviewStewarded identity record
A layered architecture can preserve choice
The historical studies favoured separating identity resolution, master-data governance and investigation where the institution’s architecture justified it. This can reduce dependence on a single broad platform and let each layer improve independently. It also introduces interfaces and shared accountability that must be managed.
An integrated platform can be preferable when the organisation lacks the capacity to operate several components or when common workflow materially reduces complexity. The decision should follow the target operating model. “Best of breed” is not a benefit if no team owns the integration.
Preserve source identifiers and an exportable relationship model. If the resolution engine changes, the institution should still understand how records were linked and which decisions used those links. Exit planning is particularly important when the platform becomes the default identity layer for many downstream systems.
AI-ready data is an outcome, not a label
Generative models and automated agents need consistent entities to retrieve the correct information and act on the correct account or organisation. Entity resolution can therefore support AI adoption. But attaching an AI feature to a data platform does not resolve poor provenance, unclear permissions or conflicting attributes.
The practical sequence is to establish identity, governance and access controls before granting automated tools consequential authority. A fluent answer about the wrong customer is still wrong. A graph that reveals a relationship should not automatically authorise an action affecting that relationship.
Evaluate the downstream task as well as the matching engine. If the proposed benefit is faster onboarding, measure completed onboarding and rework. If it is better investigations, measure evidence quality and accepted case outcomes. This connects data intelligence to the reason the institution is buying it.
Stewardship should have a service model
Assign a queue and decision authority for contested matches, conflicting attributes and stale records. Reviewers need access to source evidence and a clear rule for what they can change. A correction should propagate to the systems that depend on the identity, with an audit record showing what changed and why.
Measure unresolved exceptions, recurrence and downstream impact. If the same source repeatedly creates bad matches, the appropriate response may be an upstream data correction rather than more manual review. If a match rule generates a disproportionate number of contested links, investigate its behaviour by population. These operating measures make the identity layer governable after the initial proof of concept and connect model performance to the quality of real decisions.
The decision
Downstream consumers should receive correction events as well as new identities; otherwise a repaired master record can leave old errors active elsewhere.
The strong identity platform makes uncertainty visible, preserves source evidence and supports correction. It provides a dependable foundation for master data, investigation and controlled automation. The weak approach treats entity resolution as an isolated matching score or buys a broad platform before defining the workflow.
A governed layered stack is therefore the preferred starting point for evaluation, with integration justified by actual operating needs. The buyer should know which records are linked, why they are linked, who can challenge the link and what decisions depend on it. That is the point at which data matching becomes institutional intelligence.
Primary sources checked for this edition
- GLEIF — Data-quality reporting and AI legal-form checks described in 2026 programme. Source date: 2026-01-08. https://www.gleif.org/en/newsroom/blog/strategic-trends-in-data-quality-from-ai-innovation-to-scalable-trust-in-2026
