Last Updated on November 6, 2026
Entity resolution for KYC is used to identify records across onboarding, account, CRM and other systems that refer to the same customer, organization or related party. It standardizes identity data, compares multiple attributes, scores possible relationships and links approved records into a traceable entity view. This gives customer due diligence processes more complete data for verification, risk assessment, screening and ongoing review.
KYC and CDD checks may operate correctly while still producing incomplete results if one real customer exists under several names, identifiers, or system records. To solve this problem, entity resolution connects identity evidence such as common misspellings or transliterations, contact information, and other similar details across sources without treating every similar record as a confirmed match. To confirm a match, the potential records undergo strict checks to ensure that matches are not being assigned incorrectly.
It supports the customer-data layer of KYC and CDD. It does not verify identity documents, provide sanctions or PEP lists, determine customer risk, monitor transactions or make compliance decisions.
Key Takeaways
- Entity resolution connects fragmented records that refer to the same customer, organization or related party.
- It supports KYC and customer due diligence by creating a more complete, traceable identity view across source systems.
- Reliable resolution combines data standardization, multi-attribute matching, confidence thresholds and human review.
- Individuals, legal entities and beneficial owners require different attributes and matching rules.
- Entity resolution improves the customer data supplied to KYC processes but does not replace identity verification, screening, risk assessment or compliance decisions.
What Does Entity Resolution Mean in KYC and CDD?
Entity resolution in KYC and customer due diligence is the process of determining which records across different systems refer to the same individual, organization or related party. It standardizes identity data, compares multiple attributes, scores possible matches, groups approved records and preserves links to their original sources.
For example, an onboarding platform may hold “Mohammed A. Rahman,” while a CRM contains “Mohamed Rahman” and an account system uses a customer number without the same name format. Entity resolution evaluates the combined evidence to determine whether these records may represent one customer.
A complete entity resolution process can include:
- Profiling identity data across source systems.
- Standardizing names, addresses, dates and identifiers.
- Generating plausible record pairs for comparison.
- Applying exact, fuzzy, phonetic and other matching methods.
- Calculating match scores from multiple attributes.
- Routing uncertain relationships for human review.
- Grouping approved records into a unified entity profile.
- Retaining source lineage and the evidence behind each relationship.
FATF Recommendation 10 describes customer due diligence as identifying and verifying the customer and beneficial owner, understanding the purpose and intended nature of the relationship, and conducting ongoing due diligence. Entity resolution can support the data needed for these activities, but it does not perform or approve them.
Source: FATF Recommendations
Entity resolution is one component of the wider KYC and CDD environment:
| Capability | Primary role |
| Entity resolution | Connects fragmented records that may represent the same real-world entity |
| Identity verification | Checks whether the customer’s claimed identity is supported by reliable evidence |
| Screening | Compares customers and related parties with authorized sanctions, PEP or other reference data |
| Risk assessment | Evaluates customer, geographic, product and relationship risk factors |
| Customer due diligence | Brings identification, verification, relationship information, risk assessment and ongoing review together |
Entity resolution does not determine whether a customer has
Identity verification is a separate function from entity resolution. NIST describes identity proofing as collecting and evaluating evidence that reliably identifies an applicant at an appropriate identity-assurance level. Entity resolution instead determines whether records held across systems may refer to that same identity.
Source: NIST SP 800-63A-4: Identity Proofing and Enrollment
Why Fragmented Customer Identities Create CDD Problems
A fragmented identity exists when records belonging to one customer or organization remain separated across systems, products or business units. CDD processes may then evaluate each record independently, leaving teams without a complete view of the customer, their accounts, related parties or previously collected information.
Incomplete Customer Profiles
One system may contain the customer’s verified address while another holds an updated legal name or identifier. If these records are not connected, reviewers may work from incomplete or outdated information even when the institution already holds the missing data elsewhere.
Duplicate Onboarding and Review Work
An existing customer may appear to be a new applicant when onboarding records cannot be connected with historical accounts. Separate records can also be sent through periodic reviews independently, creating duplicated outreach and inconsistent decisions.
Inconsistent Screening Inputs
Name, address and identifier variations across customer records can produce different screening results for the same person or organization. Resolving those records creates a more consistent identity profile for authorized screening systems.
Fragmented Risk Context
Accounts, products and relationships may be assessed separately when they are attached to different customer identifiers. Connecting the records helps authorized risk processes evaluate the available relationship information at the entity level.
Missed Relationships Between Parties
An individual may appear as a customer in one system and as a director, signatory or beneficial owner in another. Without cross-system resolution, those roles may remain disconnected from the relevant legal entity.
Updates Applied to Only One Record
A corrected address, new legal name or updated identifier may be added to one source while duplicate records remain unchanged. Downstream systems can then continue using conflicting versions of the same customer data.
These problems are not caused solely by the matching engine or CDD process. They often begin with the condition of the underlying records. Improving customer data quality throughout KYC helps ensure that identity verification, screening, risk assessment and ongoing review receive more complete and consistent customer information.
How Does the Entity-Resolution Workflow Support KYC and CDD?
An entity-resolution workflow turns fragmented source records into a connected, explainable entity view. It profiles and standardizes identity data, generates plausible record comparisons, evaluates evidence across multiple attributes, routes uncertain relationships for review and groups approved records without losing their original source lineage.
1. Define the Entity and Use Case
Specify whether the workflow will resolve individuals, legal entities, beneficial owners or other related parties. Also define whether the output will support onboarding, customer due diligence, screening-data preparation, periodic review or another authorized process.
2. Profile the Source Systems
Measure completeness, uniqueness, formats and value patterns across onboarding, account, CRM and legacy systems. This reveals which attributes can support resolution and where missing or inconsistent data may weaken the results.
3. Standardize Identity Attributes
Normalize names, addresses, dates, telephone numbers, organization suffixes and identifiers into comparable formats. Preserve the original values so reviewers can trace every standardized value back to its source.
4. Generate Candidate Comparisons
Use exact identifiers, blocking rules or other filters to identify plausible record pairs. Candidate generation reduces unnecessary comparisons while ensuring that relevant variations are not excluded too early.
5. Compare Multiple Attributes
Apply appropriate matching methods to names, dates of birth, addresses, registration details and other available attributes. Record linkage is especially important when records come from different systems and do not share one dependable identifier.
6. Score and Classify Relationships
Combine the available evidence into a match score or rule-based decision. Results can be separated into likely matches, likely non-matches and uncertain relationships requiring human review.
7. Review Ambiguous Results
Reviewers should see the original values, standardized values, field-level similarities, applied rules and source systems. Decisions should be recorded so matching thresholds can be evaluated and improved.
8. Group Approved Records
Approved matches can be grouped into an entity cluster representing one customer, organization or related party. Every source record should remain linked to the cluster rather than being silently overwritten.
9. Apply Survivorship Rules
Where a unified profile is required, controlled rules determine which source contributes each retained value. For example, the workflow may preserve a verified identifier from the system of record and the most recently validated address.
10. Deliver and Monitor the Entity View
Resolved records can be supplied to authorized KYC, screening, risk or customer-data systems through batch processes or APIs. Teams should monitor match quality, review volume and changes in source data so rules and thresholds remain appropriate.
Resolving Individuals, Legal Entities and Beneficial Owners
KYC entity resolution must distinguish between people, organizations and the relationships connecting them. Each entity type uses different identifying attributes and presents different matching challenges. Applying one universal rule set can create false matches, missed relationships or entity profiles that combine records belonging to different parties.
| Entity type | Useful identity attributes | Common resolution challenges |
| Individuals | Name, date of birth, address, telephone number, email and verified identifiers | Nicknames, aliases, transliteration, shared names, name changes and incomplete records |
| Legal entities | Registered name, trading name, registration number, jurisdiction, registered address and legal form | Abbreviations, translated names, subsidiaries, reused trading names and changing legal suffixes |
| Beneficial owners and related parties | Individual or entity attributes plus ownership, control, director or signatory relationships | Indirect ownership, duplicated parties, outdated relationships and inconsistent source records |
Resolving Individual Customers
Individual resolution compares identity evidence across customer and account records. Names alone are rarely sufficient because several people may share a name, while one person may appear under different spellings, aliases or scripts.
Dates of birth, addresses, contact details and verified identifiers can strengthen or contradict a possible relationship. KYC name matching explains how spelling variations, transliteration and thresholds should be handled without treating a similar name as confirmed identity.
Resolving Legal Entities
Legal-entity resolution must account for registered names, trading names, legal suffixes, translated names, registration numbers and jurisdictions. Two records with similar company names may represent separate organizations, while one organization may operate through several names or source-system records.
Resolution should preserve the difference between a duplicate record, a branch, a subsidiary and a separate legal entity. These relationships should not be collapsed simply because their names or addresses overlap.
Connecting Beneficial Owners and Related Parties
Beneficial-owner resolution involves both entity matching and relationship matching. The person or organization must first be resolved across source systems, and the ownership or control relationship must then be linked to the appropriate legal entity.
FATF’s beneficial-ownership guidance emphasizes access to adequate, accurate and up-to-date information about the true owners of legal persons. Entity resolution can organize and connect beneficial-owner records already available to the institution, but it cannot compensate for ownership information that has not been collected or verified.
Source: FATF Guidance on Beneficial Ownership of Legal Persons
An entity graph can represent customers, organizations and related parties as separate nodes connected by documented relationships. This helps teams examine how records are connected without incorrectly merging the parties into one entity.
Entity resolution can connect and organize ownership information already available to the institution. It does not independently discover, verify or determine beneficial ownership.
Matching Techniques and Identity Evidence in KYC Entity Resolution
KYC entity resolution combines several matching techniques because different attributes provide different kinds of identity evidence. Exact identifiers can strongly support a relationship when reliable, while names and addresses often require similarity-based comparison. The final decision should consider supporting, conflicting and missing evidence across multiple fields.
| Technique | Example KYC application | Limitation |
| Exact matching | Comparing standardized customer, registration or verified identity numbers | Incorrect, reused or differently formatted identifiers can mislead the result |
| Fuzzy matching | Detecting spelling and character variations in names or addresses | Similarity alone does not establish identity |
| Phonetic matching | Finding differently spelled names with similar pronunciation | Effectiveness varies across languages and naming conventions |
| Token-based matching | Comparing reordered personal-name or organization-name components | Common words and legal suffixes provide weak evidence |
| Transliteration-aware matching | Comparing names represented in different scripts | Several valid transliterations may exist for the same name |
| Date and numeric matching | Comparing dates of birth, incorporation dates or number-based attributes | Partial or incorrectly entered values require controlled tolerances |
| Multi-attribute matching | Combining name, address, date and identifier evidence | Results depend on attribute completeness, reliability and appropriate weighting |
| Relationship matching | Connecting directors, signatories or owners with legal entities | A shared attribute does not independently prove the relationship |
Fuzzy matching is useful for generating and scoring possible relationships, but it should not operate as the sole decision rule. A strong name similarity may still represent different people, while a genuine relationship may contain a weak name score because of transliteration or data-entry differences.
Strong, Supporting and Weak Evidence
Identity attributes should contribute according to their reliability and context:
- Strong evidence may include a dependable verified identifier or registration number.
- Supporting evidence may include a compatible date of birth, address, telephone number or jurisdiction.
- Weak evidence may include a common surname, shared address or generic organization term.
- Conflicting evidence may include incompatible dates, jurisdictions or identifiers.
- Missing evidence should remain unknown rather than being treated as agreement.
Match Scores Are Not Proof of Identity
A match score expresses how strongly the configured data and rules support a possible relationship. It does not represent a universal probability that two records belong to the same entity.
Teams should document how each field contributes to the result, how conflicting evidence is handled and which thresholds lead to acceptance, rejection or human review. Different entity types and CDD use cases may require separate matching configurations.
False Matches, Missed Matches and Human Review
Entity resolution must control two different errors: false matches that incorrectly combine separate entities and missed matches that leave one entity fragmented across records. Changing a match threshold usually affects both, so teams should evaluate the tradeoff using representative customer data rather than optimizing for one overall accuracy figure.
| Error type | What happens | Possible CDD impact |
| False match or false merge | Records belonging to different entities are linked or clustered together | Information from separate customers may be combined into one profile |
| Missed match or false split | Records belonging to one entity remain separate | Accounts, relationships or previously collected information may remain fragmented |
Use Separate Decision Ranges
A practical workflow separates results into three ranges:
- Likely match: Evidence is strong enough for the approved automated action.
- Review required: Evidence is plausible but insufficient for an automatic decision.
- Likely non-match: Evidence does not meet the defined relationship criteria.
The organization should determine the thresholds and permitted actions for each range according to the entity type, data quality and intended CDD use case.
Give Reviewers the Underlying Evidence
A match score alone is not sufficient for human review. Reviewers should be able to examine:
- Original and standardized field values
- Field-level similarity results
- Supporting and conflicting attributes
- Applied rules, weights and thresholds
- Source systems and record identifiers
- Existing cluster members and relationships
- Previous review decisions, where appropriate
The reviewer’s decision and rationale should be recorded so that the entity relationship can be traced, challenged or reassessed later.
Test with Representative Records
Testing should include clear matches, difficult genuine matches and similar-looking records that belong to different entities. The evaluation set should also represent common names, incomplete attributes, multilingual data, transliteration, shared addresses and every important source system.
Useful measures include precision, recall, false-match volume, missed-match volume and the percentage of results sent for review. Review workload should be measured separately from processing speed because a configuration can run quickly while producing an impractical number of uncertain cases.
Reassess Decisions When Data Changes
Entity relationships may need to be re-evaluated when new identifiers, updated customer information or additional source systems become available. Resolution should therefore support controlled reprocessing and versioned decisions rather than treating every match as permanent.
Entity Resolution Across the Customer Due Diligence Lifecycle
Entity resolution can support CDD from initial onboarding through periodic review and customer-data remediation. Its contribution is to connect records, attributes and relationships into a more complete entity view. The identity verification, screening, risk assessment and monitoring decisions remain with the institution’s authorized systems and teams.
| CDD stage | How entity resolution contributes | What it does not determine |
| Customer onboarding | Checks whether an applicant may already exist under another record, account or identifier | Whether the applicant’s identity has been successfully verified |
| Initial due diligence | Connects available customer, organization and related-party data across systems | The customer’s final risk classification or acceptance |
| Screening preparation | Standardizes and consolidates identity attributes supplied to screening systems | Whether a screening candidate is sanctioned, politically exposed or otherwise relevant |
| Relationship analysis | Links individuals, organizations, accounts and documented ownership or control relationships | Whether an undocumented relationship exists or creates compliance risk |
| Ongoing review | Applies updated identity information across connected records and identifies changed relationships | Whether an event requires escalation or investigation |
| Periodic review | Provides a consolidated profile and highlights conflicting or incomplete source data | The review frequency, required evidence or final CDD decision |
| Customer remediation | Identifies duplicates, fragmented identities and records requiring correction or completion | Whether the remediated customer satisfies regulatory requirements |
| Customer exit and historical lookup | Helps locate related historical records and prevent the same entity from being treated as entirely new | Whether a relationship should be declined, restricted or reopened |
Onboarding and Existing-Customer Detection
A new application can be compared with existing customer and account records before another profile is created. This helps identify returning customers, duplicate applications or records created under alternative spellings and identifiers.
Screening-Data Preparation
Resolved entity profiles provide standardized names and supporting attributes to authorized screening systems. AML data matching can then identify possible similarities with approved reference sources for further evaluation.
Periodic Review and Change Management
When a customer changes a name, address or legal structure, entity resolution helps associate the update with the correct records across connected systems. It can also reveal conflicting values or related records that require review.
Customer-Data Remediation
Entity resolution can identify fragmented identities across an existing customer population before or during a remediation exercise. The detailed profiling, cleansing, prioritization and review process should be covered in the separate KYC Remediation: Cleaning and Resolving Existing Customer Records guide.
Entity resolution should therefore be treated as reusable customer-data infrastructure across the CDD lifecycle—not as a one-time matching exercise performed only during onboarding.
Explainability, Lineage and Governance Requirements
KYC entity resolution should make every proposed and approved relationship traceable to its source data, matching configuration and review decision. Teams need to understand why records were linked, which values were retained and how the result changed over time. A match score without supporting evidence is not sufficient for governed CDD use.
Explainable Match Evidence
For every candidate relationship, users should be able to examine:
- Which attributes were compared
- The original and standardized values
- The matching technique applied to each field
- Field-level similarity scores or rule outcomes
- Supporting, conflicting and missing evidence
- The threshold or rule that produced the classification
This allows reviewers to distinguish a strong multi-attribute relationship from a candidate generated primarily by a similar name.
Source Lineage
Every value in a resolved entity profile should remain connected to its originating system and record identifier. Lineage should show whether a value came from onboarding, CRM, an account system or another approved source and whether it was standardized, reviewed or selected through a survivorship rule.
FATF’s Digital Identity Guidance notes that digital records may need to preserve the identity evidence used, its source, the date or time and the means of accessing it. Although entity-resolution records serve a different technical purpose, the same traceability principle supports reviewable customer-identity decisions.
Source: FATF Guidance on Digital Identity
Versioned Configurations and Decisions
Matching rules, weights, thresholds and standardization logic should be versioned. If a configuration changes, teams should be able to identify which entity relationships were created under the previous version and determine whether reprocessing is required.
Human-review decisions should record the reviewer, timestamp, outcome and rationale according to the organization’s governance procedures.
Reversible Entity Relationships
Incorrect links must be correctable. The platform should support separating records that were mistakenly grouped without deleting their original values or source history. Downstream systems should also receive controlled updates when an entity relationship changes.
Access and Change Controls
Permissions should distinguish between users who configure matching, review candidates, approve merges and consume resolved data. Production changes should follow an approval process appropriate to the organization’s data-governance and security requirements.
Data Retention and Purpose
Resolved profiles may combine personal information from several systems. Organizations should define which data can be used, how long match evidence and review decisions are retained and which downstream processes may receive the results.
Explainability and lineage do not prove that an entity relationship is correct. They make the evidence, configuration and decision process available for review, testing and governance.
How DataMatch Enterprise Supports KYC Entity Resolution
DataMatch Enterprise helps organizations profile, standardize, match and resolve customer and organization records across multiple sources. It can support the customer-data layer used by KYC and CDD processes without replacing identity verification, screening, risk assessment or case-management systems.
Profile Identity Data Across Sources
Teams can examine source datasets for missing values, inconsistent formats, duplicates and unusual patterns before configuring entity-resolution rules. This helps identify which attributes are sufficiently complete and reliable for matching.
Standardize Names, Addresses and Identifiers
DataMatch Enterprise can parse, cleanse and standardize identity attributes before comparison. Original source values can remain available alongside transformed values so teams can inspect how the data was prepared.
Configure Multi-Attribute Matching
Users can combine exact, fuzzy, phonetic, numeric and other matching methods across fields such as names, addresses, dates and identifiers. Rules, weights and thresholds can be adjusted for different entity types and source-data conditions.
Review and Resolve Candidate Relationships
The visual interface allows users to inspect match results and determine how records should be handled. Uncertain candidates can be reviewed rather than being forced into an automatic match or non-match decision.
Create Entity Clusters and Consolidated Profiles
Approved relationships can group records belonging to the same customer or organization. Survivorship rules can select retained values while preserving links to the contributing source records.
Explore Relationships with Entity Graphs
Entity Graphs can display records and their connections visually, helping users examine how customer, organization and related-party data is linked. A graph shows the relationships established from available data; it does not independently verify ownership or compliance relevance.
Integrate with Existing Data Workflows
The browser-based platform provides a visual interface for data and review teams, while the REST API supports repeatable matching within downstream applications and data pipelines. DataMatch Enterprise also remains available through established Windows desktop and server deployments.
Deploy Within Enterprise Infrastructure
The web platform supports Docker-based Linux deployment across on-premises and cloud environments. Organizations can select an architecture aligned with their security, infrastructure and governance requirements.
Data Ladder has published the configuration and test conditions behind its 10-million-record benchmark so technical evaluators can review the reported processing results in context.
DataMatch Enterprise resolves and prepares customer data used by KYC and CDD workflows. It does not verify identity documents, provide sanctions or PEP data, calculate customer risk, monitor transactions or make compliance decisions.
KYC Entity-Resolution Implementation Checklist
Before implementing entity resolution within a KYC or CDD environment, confirm that the organization has defined the intended use, available evidence, decision controls and downstream responsibilities.
Scope and Ownership
- Define whether the workflow will resolve individuals, legal entities, beneficial owners or multiple entity types.
- Identify the specific CDD stages and downstream systems that will consume the results.
- Assign owners for source-data quality, matching configuration, candidate review and production approval.
- Document which actions may be automated and which require human authorization.
Source Data
- Inventory the onboarding, account, CRM, legacy and approved external sources involved.
- Profile important attributes for completeness, consistency, uniqueness and validity.
- Identify which system is authoritative for each field where possible.
- Preserve source identifiers and original values throughout processing.
Matching Configuration
- Use separate rules where individual, organization and relationship resolution require different evidence.
- Combine names with supporting attributes rather than relying on name similarity alone.
- Define how missing, common and conflicting values affect the decision.
- Establish distinct thresholds for likely matches, likely non-matches and review cases.
Testing and Human Review
- Build a representative labelled dataset containing genuine matches and difficult non-matches.
- Measure precision, recall, false matches, missed matches and review volume.
- Confirm that reviewers can inspect field-level evidence, source lineage and existing cluster relationships.
- Record decisions and provide a controlled method for reversing incorrect links.
Integration and Governance
- Determine whether outputs will be delivered through batch processing, an API or both.
- Define how corrected entity relationships propagate to downstream systems.
- Apply appropriate access, security, retention and change controls.
- Version matching rules, thresholds, software releases and review procedures.
- Reassess the workflow when source systems, customer populations or identity attributes change.
A production decision should be based on performance against the organization’s representative data and operational requirements—not a vendor’s general accuracy claim or a demonstration using only clean records.
Build a More Complete Customer View for KYC and CDD
KYC and customer due diligence depend on knowing which records, accounts and documented relationships belong to the same real-world customer or organization. When identities remain fragmented across systems, downstream processes may work from incomplete or inconsistent information.
Entity resolution creates a more complete and traceable data foundation by standardizing identity attributes, comparing evidence across records, reviewing uncertain relationships and grouping approved matches without losing source lineage.
DataMatch Enterprise supports this process through data profiling, cleansing, configurable matching, entity clustering, survivorship, Entity Graphs and integration through a REST API. The resulting entity view can support authorized KYC and CDD systems while leaving verification, screening, risk and compliance decisions with the appropriate teams.
Request a DataMatch Enterprise demo to evaluate entity resolution using representative customer data, entity types and deployment requirements.
Frequently Asked Questions
Can entity resolution work without a shared customer identifier?
Yes. Entity resolution can compare names, addresses, dates of birth, contact details, registration information and other attributes when a common identifier is unavailable. The strength of the result depends on the completeness, reliability and distinctiveness of the available evidence.
What is the difference between entity resolution and customer deduplication?
Customer deduplication identifies duplicate records, usually within a defined dataset. Entity resolution can also connect related records across systems, group them into entity clusters, preserve source lineage and represent relationships between customers, organizations and related parties.
Should KYC entity resolution be fully automated?
Clear relationships may be processed automatically when approved rules and thresholds are satisfied. Ambiguous or consequential relationships should enter a review range where authorized users can inspect the evidence. The appropriate level of automation depends on the data, entity type and intended use.
How often should customer entities be resolved again?
Entities should be reassessed when relevant customer information changes, new source systems are added, matching rules are updated or the institution’s review process requires refreshed data. Resolution can also run as a scheduled batch process or within an event-driven workflow.
Can entity resolution identify beneficial owners?
Entity resolution can connect beneficial-owner information already held across approved records and link the resolved party with the relevant legal entity. It does not independently discover, verify or determine beneficial ownership when the underlying relationship data is unavailable.
Can DataMatch Enterprise replace a KYC or CDD platform?
No. DataMatch Enterprise profiles, standardizes, matches, deduplicates and resolves customer data used by KYC and CDD workflows. It does not verify identity documents, supply sanctions or PEP data, calculate customer risk, monitor transactions or manage compliance cases.
