Why does a bank end up knowing the same person as six different customers, and what does it take to give them one identity?

Six records is the designed outcome

Nobody chose this, but nobody prevented it either. The mortgage was written on a mortgage platform bought in one decade, the current account sits on the core banking system, the credit card lives on a card processor with its own customer master, the savings product came with an acquisition, the brokerage account was onboarded by a subsidiary with its own regulatory permissions, and the insurance policy was sold by a distribution partner. Each of those onboarded a person, minted an identifier in its own namespace, and captured the attributes its own product needed. None of them had a reason to ask whether this human already existed elsewhere in the group, and several were legally separate entities at the time.

Then the human helps. The name carries a middle initial in one place and not another, transliterated differently in a third. They moved twice, married and changed surname in two systems out of six, and a branch keyed a date of birth with the day and month transposed. Many markets have no shared national identifier, and where one exists it is often not permitted as a routine key.

Framing this as sloppiness gets you nowhere. Framing it as the predictable result of product-aligned systems, acquisitions and the absence of a group-wide identity authority shows you have seen the real shape of it, and points at the fix: identity becomes a service products consume rather than something each product does for itself.

Matching is a scored decision, and the errors are asymmetric

Deterministic matching on exact attributes gets the easy cases and quietly fails on the rest. The workhorse is scored comparison: standardise and normalise each attribute first — names, addresses to a postal reference, dates — then compare with per-attribute similarity measures and weight each comparison by how much evidence it carries. Two people sharing a surname is nearly no evidence. Two records sharing a rare surname, a date of birth and a current address is a great deal. Blocking keys keep the comparison space tractable so that you are not evaluating every pair in a book of millions.

The output is a score with two thresholds rather than one. Above the upper threshold, auto-merge. Below the lower, leave separate. Between them, a human decides, and that middle band is not a failure of the algorithm — it is where you have deliberately put the cases whose cost of error justifies attention. Households are the classic occupant of that band: a father and son at one address with the same name and a birth date differing by decades are two customers, while the same name and address with dates a day apart is probably one record with a typo.

Get the asymmetry the right way round. A missed match costs you an incomplete view: fragmented exposure, a duplicated mailing, a worse service experience. A wrong match is a data breach, because the merged view shows one customer another person's balances and transactions, and it is a control failure, because you have just told your own systems that two people are one legal person. Tune conservatively and put the doubt in the review queue.

Golden record as a projection, not a rewrite

The tempting design is to pick a winner and overwrite the losers. Resist it. Source systems keep operating on their own records, they are the books of record for their products, and rewriting them destroys the evidence you need to explain how a resolution was reached.

Instead the golden record is a derived view over an entity that groups source records. Survivorship is decided per attribute and by rule, not per record: the address from the system where the customer most recently transacted, the name as verified during the most recent identity check, the tax residency from the source with the strongest evidence. Each attribute in the golden record carries which source supplied it and when, so "why does the group think I live here" is answerable. Because it is derived, it can be recomputed when a source corrects itself, and because the grouping is a separate fact from the attributes, the group can be changed without touching either.

The cross-reference is the durable asset: a stable group identifier plus the set of source-system keys that belong to it, with the score, rule version and decision provenance for each link. Downstream consumers reference the group identifier and can always resolve back to the underlying account in the system that owns it.

Regulatory identity changes the moment you merge

This is the part candidates omit, and it is what the question is really testing. Unifying identity is not only a customer-experience improvement, because several obligations are defined per customer rather than per account.

Exposure aggregates. Two records that were separately inside a lending limit may breach it as one customer, and a large-exposure or connected-party assessment that was correct before the merge is wrong after it. Screening changes: a sanctions or PEP match that was assessed on a thin record must be re-evaluated against the fuller identity, and adverse media that seemed irrelevant may now attach. Risk rating and monitoring change, because the merged behaviour is a different pattern than either half. Consent does not simply union — a marketing permission given in one product's context does not automatically extend to the group, and a withdrawal in one place must not be lost by survivorship rules that prefer the more recent record. Data retention and deletion obligations bind per source relationship, so a closed product's retention clock does not restart because its record was absorbed into a group.

None of that is a reason not to resolve identity. It is a reason for the merge to be an event that other domains subscribe to, so that limits are re-evaluated, screening re-runs and consents are reconciled deliberately rather than as a side effect.

Every merge must be undoable

Because you will be wrong sometimes, unmerge is a first-class operation designed at the same time as merge, not a recovery script written during an incident. That is only possible if the merge never destroyed anything: the source records are intact, the link decisions are individually recorded with their scores, and the golden record is recomputable from the links. Unmerge then becomes removing links and recomputing, plus emitting the reverse event so the domains that reacted to the merge can react to its withdrawal.

Two operational additions make this work in practice. Keep a suspense state so a contested link can be quarantined rather than either accepted or dropped while it is investigated. And measure the resolution itself — link volumes, the size of the review band, reversal rates and clerical override rates — because a matching rule change that silently doubles auto-merges is exactly the change you want to see before the complaints arrive.

Treat merge as a business event with subscribers, not a data-cleanup job: it changes aggregate exposure, screening scope and consent, and it can be wrong. Keeping the sources untouched and the links individually recorded is what makes both the explanation and the reversal possible.