Financial Services October 10, 2026 · 13 min read

Can Entity Resolution Tell Two Customers With the Same Name Apart? Consistency Rules for Banks

Steven Renwick

CEO, Tilores

Can Entity Resolution Tell Two Customers With the Same Name Apart? Consistency Rules for Banks

TL;DR: Name and address similarity, however strong, is never enough to merge two bank customers. Only an entity-level consistency rule, a field like date of birth or a tax ID that must agree across every record, decides whether two near-identical profiles are the same person or two different people who happen to look alike.

Book a Demo to test a same-name scenario against your own consistency rules, or Try Tilores Studio (Free) to see the check run on your own data.

On this page

What makes two bank records look like the same customer?
Why doesn’t a strong match score settle the question?
What is a consistency rule, and how does it stop a false merge?
How is preventing a false merge different from explaining one that already happened?
Where does Tilores fit into this?
Can your matching configuration tell these two customers apart?
FAQ
Sources

A bank’s onboarding queue holds two applications from the same week. Same first and last name, same postcode, addresses close enough to be the same building. A matching configuration built to catch duplicates would wave this pair through as an obvious link.

Except they might not be the same person. One could be a parent and the other an adult child at the same address, or two unrelated customers who share a common name and a street. A bank that merges them on name and address alone ends up with one profile holding two people’s balances, two credit histories and two risk pictures, and nobody notices until a statement, a credit decision or a sanctions hit lands on the wrong person.

The question that matters for a buyer evaluating entity resolution software is not how high the similarity score climbed. It is which specific rule, if any, stopped the system from merging two different people who looked, on paper, like a near-perfect match.

What makes two bank records look like the same customer?

Two source records look like one person whenever enough fields line up: a name that matches in full or almost in full, an address that is identical or a short distance away, a date written in a different format, overlapping contact details. None of these signals proves identity on its own. Each is evidence, and evidence needs weighing, not simple addition.

The UK’s Joint Money Laundering Steering Group guidance on customer due diligence puts this plainly for a bank’s own onboarding file: a customer’s residential address is central to being satisfied about identity, especially for customers with more common names, because a name and a date of birth are only two of several aspects to weigh.

We keep three matching methods distinct in every configuration, because collapsing them into one label hides how much certainty a result actually carries.

Method	What it checks	What it produces
Deterministic	Exact equality on a governed value, such as a tax identifier or account number	A fixed yes-or-no result, with no ambiguity
Fuzzy	Values that can legitimately vary in form: phonetic similarity, Levenshtein distance for typos, cosine similarity for token overlap, geographic distance between coordinates, temporal distance between dates	A closeness measure between two values, not a confirmation that they are the same
Probabilistic	A statistical model trained on example data, scoring the combined weight of several partial signals	A similarity score that must clear a configured threshold before two records count as a candidate pair

Fellegi and Sunter’s 1969 paper on record linkage framed linking two records as a likelihood-ratio decision between the hypothesis that they match and the hypothesis that they do not, not a single fixed rule applied once. A high similarity score raises that likelihood. It does not settle it, because the same score can describe a true duplicate with messy data or two different people who happen to share a name, an address and a handful of coincidental details.

Why doesn’t a strong match score settle the question?

Outside banking, a regulator has already ruled on this exact failure mode by another name. The CFPB’s November 2021 advisory opinion on name-only matching concluded that matching a consumer report to a person using only first and last name agreement is not a reasonable procedure to assure maximum possible accuracy, because a given name combination can be shared by thousands of people. A bank evaluating entity resolution software carries the identical risk whenever a configuration leans on name and address alone, whatever the vendor calls that step.

Sanctions and watchlist screening runs into the identical ambiguity under a different name. The Wolfsberg Group’s guidance on sanctions screening treats a true-match decision as complex once alphabets, languages, cultures, spelling, abbreviations, acronyms and aliases enter the picture, which is why a screening or matching configuration cannot lean on a name alone.

Politically exposed person and adverse media checks inherit the same problem. The Wolfsberg Group’s PEP guidance asks banks to run negative news and adverse media screening on PEP customers and to evaluate every positive hit, and every one of those hits is a name match that someone has to confirm or dismiss. The lists also move: OpenSanctions updates sanctions lists every 4 to 12 hours and PEP and regulatory watchlists daily or weekly, so a same-name decision made once has to hold when the data underneath it changes.

Standard record-linkage practice describes an honest middle ground instead of a single cutoff. A classification with two thresholds puts confident links above the upper threshold, confident non-matches below the lower threshold, and holds everything between the two for a human decision. Our rule engine builds that middle band in directly. Take a configuration pattern we see often: a candidate pair scores 0.71, below an auto-merge threshold of 0.85 and above an auto-reject threshold of 0.55. Surname and address agree after normalisation. Date of birth is missing on one record, so the consistency rule can neither confirm nor block the pair, and the two records’ email addresses are eleven years apart. That combination belongs in front of a steward, not inside an automatic merge, and whichever way the decision goes, it is logged and reversible.

A true duplicate merges, a same-name pair is blocked by a date-of-birth conflict, and an incomplete pair routes to a steward for review.

Getting this wrong is not a data-quality inconvenience. Merging two different customers puts one person’s balance, address history and risk flags inside another person’s profile, which is an unauthorised disclosure of personal data to the wrong party under the ICO’s definition of a personal data breach: a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. The UK GDPR’s accuracy principle exists for the same reason: personal data must be accurate and kept up to date, with inaccurate data erased or rectified without delay. A false merge, however briefly it stands, fails that test for both customers at once, not only the one who notices first.

Newsletter

Enjoying this article? Get the next one in your inbox.

New posts on entity resolution, identity data and AI. No spam, unsubscribe any time.

What is a consistency rule, and how does it stop a false merge?

A match rule asks whether two specific records agree closely enough to link. A consistency rule asks a different question: does the new record agree with every record already attached to the candidate entity on a field that must never conflict? Our consistency rules check the incoming record against every record already inside the entity it would join, not only the closest one. If even a single one of those records disagrees on the governed field, the whole entity is ruled out, however strong the name or address evidence looks elsewhere. When a record would satisfy two entities that disagree with each other on that field, it attaches to the older entity instead of merging them.

For a bank, the natural field for this invariant is one a household rarely shares in full: date of birth or a government tax identifier. Take a bank’s own file. Andreas Müller applied for a card in 2015 from Musterstraße 12 in Frankfurt, born 22 June 1979. His legacy core-banking record, “Andreas Mueller”, carries the same address with no date of birth on file. A 2026 application from “A. Müller-Schmidt” at a new address in Offenbach, his married name, still carries the matching 22 June 1979 birth date. All three belong to one customer. Andrea Müller, a household member at the original Frankfurt address, born 4 November 1983, shares 92 percent of the name string and the same address as those three records. Without a consistency rule, that overlap alone would pass most matching configurations. The date-of-birth consistency rule disagrees, and that single disagreement outranks every other piece of evidence in the case.

This pattern is not unique to banking. A 2022 peer-reviewed evaluation of patient-matching methods in the Journal of the American Medical Informatics Association found the same failure mode in healthcare records: family members who share similar names and other demographic details are a known source of false-positive matches, resolved only with additional referential data.

Step 1: A match rule proposes a candidate link. A new record scores highly enough on name, address or another fuzzy or probabilistic measure to be proposed as a match against an existing entity.
Step 2: The consistency rule reads the governed field everywhere it appears. It checks the proposed record’s date of birth, or whichever field the bank has configured, against that same field on every record already inside the candidate entity, not only the single closest record.
Step 3: Any single disagreement rules out the whole entity. If the incoming record conflicts with even one existing record on that field, the entity is removed as a candidate, regardless of how strong the match score looked.
Step 4: A genuine conflict between two entities resolves to the older one. If the incoming record would otherwise qualify for two entities that disagree with each other on the governed field, it attaches to the older entity, and the rule that decided it is written onto the connection itself.

Every resulting connection in our graph is stored as recordA:recordB:RULE_ID, so a reviewer can see which specific rule produced a given link, not only how confident the system felt about it. A rule change is versioned, and a wrongly formed connection can be removed through our disassembly operation, which can also set a ban that stops the same two records reconnecting by accident.

How is preventing a false merge different from explaining one that already happened?

A separate question, worth keeping apart from this one, is how a reviewer reconstructs and defends a merge that has already taken place: the source lineage, the normalisation history and the human decision behind an entity a bank is now relying on. That is an audit question, and it assumes the merge was correctly formed in the first place.

Calibrating confidence bands for a truly ambiguous case is a related but distinct question again. Our article on confidence scores, match thresholds and audit trails covers how a bank sets its own auto-link, review and auto-reject bands instead of copying a vendor’s default percentages.

A consistency rule sits upstream of both. It decides whether two records are even allowed to become a merge candidate before a score gets computed at all. Getting the invariant right removes an entire category of false merge from the pipeline, instead of relying on a reviewer to catch it after a bad decision has already shipped.

Where does Tilores fit into this?

We treat a consistency rule as a first-class, queryable part of the entity graph, not a filter bolted onto a separate matching step. Entities are graphs; each edge records the rule that created it; consistency rules run before a match forms, not after; and merge, unmerge and split are first-class operations we support if a bank needs to correct a decision later.

Option	How it handles the same-name problem	Where it falls short
A full MDM suite	Consistency and matching sit inside a much larger master-data programme	Usually sized and priced for a big-bang programme, so many banks see it as a first stop and then look for a lighter, focused option
Build the check on an existing data platform	A team hand-codes a similarity model and a rule to compare fields in-house	The invariant has to be built, tested and maintained by the bank, and a probabilistic result alone is harder to explain to a GDPR subject-access request than a named rule
Name-and-address matching alone, with no consistency check	Simplest to configure and fastest to start	The exact pattern the CFPB has already flagged as insufficient for accuracy; it is what lets a 92 percent name match through unchallenged
A matching engine with consistency rules as a graph property (our approach)	The invariant runs before a match forms, and a named rule, not a model’s confidence alone, blocks a false merge	Still needs the bank to pick the right governed field and review the steward-queue cases a configuration cannot resolve alone

If a bank needs only a single one-off clean-up of a legacy file, with no ongoing matching requirement afterwards, a time-boxed project with a data-quality consultancy, or an internal one-time script, can be the more proportionate choice over licensing a persistent matching engine. The case for an engine strengthens once new records keep arriving and the same question has to be answered every day, not once.

Book a Demo to walk through a consistency rule on a case like the one above, or Try Tilores Studio (Free) to configure one on your own sample data.

Can your matching configuration tell these two customers apart?

Before trusting a vendor’s merge decision on a same-name case, check for four things: a named consistency rule on a field the two customers are unlikely to share, a visible middle band that routes ambiguous cases to a person instead of auto-merging them, a record of which specific rule produced each link instead of only a score, and a tested way to split and ban a reconnection if a merge turns out to be wrong.

Book a Demo to run a same-name scenario against your own data, or Try Tilores Studio (Free) to configure a consistency rule yourself.

FAQ

Does a 92 percent name match mean two bank customers are the same person?

No. Name and address similarity, however high the score, is evidence of a possible match, not proof. A consistency rule on a field such as date of birth or a tax identifier can still block the merge if that field disagrees.

What is a consistency rule in entity resolution?

A consistency rule is an entity-level check: it compares a governed field on an incoming record against that same field on every record already inside the candidate entity, and rules out the entity if even one of those records disagrees.

Which fields work best as a banking consistency rule?

Date of birth and a government tax identifier work well because they rarely change and rarely match by coincidence between two different people, even within the same household or at the same address.

What happens when a record’s consistency field is missing?

The rule can neither confirm nor block the pair, so a case with a missing field and a mid-range match score should route to a steward for a logged, reversible decision instead of an automatic merge.

Can a human still intervene before two records merge?

Yes. Auto-merge and auto-reject bands sit above and below a middle review band, and any case inside that band, or any completed merge later found to be wrong, can be corrected through a split operation with a connection ban against reconnecting.

Sources

See what resolved entity data does for your business — and your AI.

Book a Demo → Try Tilores Studio (Free) →