Quick answer: banks match customer identities by comparing imperfect records and estimating whether two records refer to the same real person or organisation. Exact identifiers can create deterministic matches when they are reliable. Names, addresses and dates often require normalization and fuzzy comparison because spelling, transliteration, ordering, punctuation and data-entry variation create differences that are not identity differences. Probabilistic record-linkage models combine multiple fields and ask how much more likely an observed pattern of agreement would be if two records belonged to the same entity rather than different entities. The final system must manage two opposite errors: false merges, where different people are combined, and false splits, where one person is represented as several customers.

Identity matching is not asking whether two strings are similar. It is asking whether two imperfect records point to the same real-world entity.

Exact reader question and page role

This article answers one banking-computation question: how can a bank resolve duplicate or variant customer records without assuming that matching names imply matching identities? It is not a general-purpose entity-resolution specification, and it does not disclose institution-specific compliance rules, screening thresholds or evasion-sensitive control logic. It focuses on public mathematics: normalization, similarity, probabilistic linkage, error trade-offs and verification.

1. Identity proofing and record matching are related but different

Identity proofing asks whether presented evidence supports a claimed identity. Record matching asks whether two records already in or entering a system refer to the same identity.

NIST SP 800-63A-4, published 1 August 2025, describes identity proofing as the process of collecting and validating evidence so a service can establish confidence in an applicant’s identity. See NIST SP 800-63A-4.

A bank can prove a new customer’s identity successfully and still create a duplicate customer record because an older record uses a different transliteration, old address or abbreviated name. Proofing establishes confidence in the person; resolution establishes continuity across records.

2. The record-linkage problem

Suppose record A contains:

Name: “Mohamad bin Rahman”
Date of birth: 12 March 1984
Address: 18 Example Road
Phone: ending 4821

Record B contains:

Name: “Muhammad B Rahman”
Date of birth: 12 March 1984
Address: 18 Example Rd
Phone: ending 4821

No single text field is identical, yet the combined evidence may strongly suggest one person. Conversely, two records named “John Tan” may be exact name matches while belonging to entirely different people.

The algorithm therefore evaluates joint evidence, not name similarity alone.

3. Deterministic matching: powerful when identifiers are trustworthy

A deterministic rule can be:

If verified identifier X is identical and context is consistent, treat records as the same customer candidate.

Examples can include government-issued identifiers, tax identifiers, institution-issued customer IDs or cryptographically verifiable credentials, depending on jurisdiction and lawful use.

Deterministic matching is transparent and fast. Its weakness is data quality. A mistyped identifier can create a false split; a recycled or incorrectly shared identifier can create a dangerous false merge. “Exact” refers to the database value, not necessarily to reality.

4. Normalization removes irrelevant differences before comparison

Common normalization steps include:

case normalization;
whitespace and punctuation handling;
standardising common address abbreviations;
separating titles or suffixes where appropriate;
Unicode normalization;
consistent date formats;
phone-number country-code normalization;
canonical ordering of multi-part names where culturally appropriate.

The phrase “where appropriate” matters. Aggressive normalization can delete meaningful identity distinctions. For example, name particles, patronymics, compound surnames or order conventions differ across languages and cultures. A global bank cannot assume every name follows one Western first-name/last-name grammar.

5. String similarity measures local textual resemblance

A Levenshtein-style edit distance counts insertions, deletions and substitutions required to transform one string into another. A normalized similarity can be written:

Similarity = 1 − edit_distance(a,b) / max(length(a), length(b)).

Other methods, such as Jaro-Winkler, n-gram overlap or token-based similarity, respond differently to transpositions, prefixes and word order. No metric is universally best.

A bank should therefore test similarity methods on the error patterns that actually occur in its customer records rather than selecting an algorithm because it has a familiar name.

6. Transliteration is a many-to-many mapping problem

Names written in Arabic, Chinese, Cyrillic, Tamil or other scripts can appear in Latin characters through different transliteration systems or personal conventions. One original name can therefore generate several plausible spellings, and one Latin spelling can map back to several originals.

A robust matcher can preserve the original-script value, store transliterations as derived representations, and compare across both where lawful and available. The model should not overwrite the source identity string with a single lossy Romanisation and then treat that version as canonical truth.

7. Probabilistic record linkage combines evidence across fields

Classical probabilistic record linkage asks how likely a pattern of agreements is under two hypotheses:

M: records refer to the same entity;
U: records refer to different entities.

For comparison pattern γ, an evidence weight can be expressed conceptually as:

w(γ) = log[P(γ | M) / P(γ | U)].

An agreement on a rare date-of-birth-plus-address combination may carry more information than agreement on a common surname. A disagreement on a frequently changing phone number may carry less negative weight than disagreement on a verified birth date.

The mathematics forces an important question: how discriminating is this field in the population?

8. Bayesian interpretation

The same idea can be written with odds:

Posterior odds = prior odds × likelihood ratio from observed comparisons.

If duplicate records are rare, the prior probability that two random customers are the same person is low. Strong field agreement is therefore required before merging. If records were pre-blocked because they share a reliable identifier, the prior is much higher.

This explains why similarity scores cannot be interpreted without the candidate-generation process that produced the pair.

9. Blocking keeps the comparison problem computationally possible

If a bank has N customer records, comparing every pair requires approximately N(N−1)/2 comparisons. At tens of millions of records, that is impractical.

Blocking creates candidate groups using broad keys such as phonetic surname families, date components, postcode, verified identifiers or learned embeddings. Only records within plausible candidate blocks receive expensive comparison.

The risk is recall loss: if the true duplicate falls into different blocks, the later matcher never gets a chance to recover it. Blocking therefore has its own validation metrics, separate from match classification.

10. False merge versus false split

The two main identity-resolution errors have different consequences:

Error	Meaning	Possible consequence
False merge	Two different customers are combined	Privacy breach, wrong account linkage, incorrect risk or compliance conclusion
False split	One customer remains as several identities	Fragmented exposure, duplicate onboarding, missed relationship view, inconsistent service

The cost of a false merge is often asymmetric and severe. That is why high-impact automated identity decisions should include conservative controls and human review where uncertainty remains.

11. NIST’s 2025 guidance illustrates the importance of manual review for high-impact false positives

NIST SP 800-63A-4 requires manual review before denying enrollment based solely on a positive result from certain 1:N biometric identification searches used for deduplication or fraud detection. The specific biometric requirements are not a general rule for all banking record linkage, but they express a useful principle: when automated matching can wrongly conflate people and the consequence is significant, an independent human check can be part of the safety design.

The broader lesson is automation should not make uncertainty disappear merely by outputting a score.

12. Customer identification rules define the governance boundary

US Customer Identification Program rules require covered banks to use risk-based procedures that enable them to form a reasonable belief that they know the true identity of customers. In June 2025, US agencies granted optional flexibility allowing covered institutions to obtain certain taxpayer-identification information from a third party rather than directly from the customer, while leaving the underlying identity-verification responsibility intact. See FinCEN, 27 June 2025.

In February 2026, FinCEN also issued exceptive relief from certain repeated beneficial-owner identification and verification requirements when legal-entity customers open additional accounts. See FinCEN, 13 February 2026.

These are legal/governance facts, not matching-algorithm instructions. The mathematical system still needs traceable evidence showing why records were linked or kept separate.

13. Name screening is a related but separate job

Sanctions or watchlist screening can also use fuzzy name matching, but the decision objective is different from customer deduplication. OFAC’s public Sanctions List Search tool, for example, uses fuzzy logic in its name search field to identify potential list matches. See OFAC Sanctions List Search.

A potential list match is not automatically the same person, and a customer-record merge should not be based solely on a screening similarity. Different jobs can use related string mathematics while requiring different evidence, escalation and legal interpretation.

14. Graph evidence can resolve ambiguous pairs

Two records may share a name and date of birth but differ on address. Graph context can add evidence:

same verified phone over time;
same jointly held account;
same business ownership relationship;
same validated device or credential history;
consistent address chronology.

Graph evidence should be treated cautiously. Shared household addresses and phone numbers do not prove identity. Family members and corporate officers create legitimate relationship links without being the same entity.

15. Temporal logic prevents impossible merges

Identity data changes through time. People move, change names, replace phone numbers and renew documents. A strong system stores time intervals rather than overwrite history.

For attribute a:

a = value valid over [t_start, t_end].

This allows the system to distinguish “different addresses at different times” from “incompatible addresses claimed at the same time.” Temporal consistency is evidence.

16. The match pipeline

Preserve source records and provenance.
Normalize fields without destroying meaningful distinctions.
Validate high-confidence identifiers where lawful.
Generate candidate pairs with blocking.
Calculate field-level exact and fuzzy comparisons.
Add transliteration and token-order comparisons where appropriate.
Estimate joint match evidence probabilistically or with a validated classifier.
Apply temporal and graph consistency checks.
Separate auto-link, human-review and no-link outcomes according to governed risk.
Record reasons and evidence for each merge/split decision.
Monitor later contradictions.
Unmerge when new evidence shows an earlier merge was wrong.

17. Failure modes

Name-only matching. Common names create false merges.
Exact-ID worship. Typographical or recycled identifiers are treated as infallible.
Over-normalization. Meaningful cultural name structure is deleted.
Transliteration collapse. One Romanised spelling replaces the original script permanently.
Blocking blindness. The classifier is accurate, but true duplicates never enter the candidate set.
Score absolutism. A numeric similarity is treated as proof of identity.
Household merge. Shared address or phone causes family members to be conflated.
No-unmerge architecture. The system cannot reverse a wrong historical identity merge.

18. Counterexamples and falsifiers

Claim: “Exact same name means same customer.” Falsifier: two verified individuals share the same common name but different birth dates and identifiers.

Claim: “Different spelling means different customer.” Falsifier: documentary evidence shows two transliterations represent the same person.

Claim: “A 99% accurate matcher is safe.” Falsifier: false merges cluster in a high-volume demographic or language group, creating unacceptable harm despite high overall accuracy.

19. Diagnostics

What is pairwise precision for auto-merges?
What is recall of known duplicate identities?
What percentage of true duplicates are lost during blocking?
Which fields contribute most to false merges?
How do error rates differ by language/script and geography?
How often are merges later reversed?
Do manual reviewers disagree systematically with the model?
Are “gold standard” labels genuinely verified or merely inherited from old system decisions?

20. Verification and update triggers

maintain independently verified match/non-match test sets;
test blocking recall separately from classifier accuracy;
review performance by language, script and customer type;
sample automatic merges for human audit;
track reversals and downstream identity complaints;
revalidate after onboarding-channel or document changes;
update transliteration logic when new markets or scripts enter the system;
keep a complete audit trail so a wrong merge can be reconstructed and corrected.

Connections across the banking-algorithms lane

Transaction monitoring — depends on correctly linking activity to entities and relationships.
Model validation — matching systems need independent performance and drift checks.
Transaction reconciliation — a related matching problem where records, rather than identities, must be paired correctly.

Research anchors

The deeper mathematical lesson

Identity resolution is inference under noisy observation. Strings are evidence, identifiers are evidence, chronology is evidence and relationships are evidence—but none should be mistaken automatically for the real person. The strongest banking matcher is therefore reversible, probabilistic where uncertainty exists, culturally aware, and measurable in both directions: how often it wrongly joins different people and how often it wrongly separates the same person.

Educational and safety boundary: This article explains public record-linkage mathematics and identity-governance principles. It does not publish bank-specific KYC, sanctions-screening or fraud-control thresholds, and it is not advice for bypassing identity or compliance controls.

Small Group Tutorials

How Banks Match Customer Identities: Deterministic Rules, Fuzzy Similarity, Transliteration, Probabilistic Record Linkage and False Merges