Why Did These Two Bank Customer Records Merge? The Audit Evidence a Reviewer Needs

TL;DR: Two bank customer records should merge only when the evidence shows they belong to the same person or organisation under the bank’s policy. A reviewer needs the original inputs, normalisation history, field-level evidence, matching method, decision route and a tested way to reverse a wrong merge.

Book a Demo to test whether your merge evidence survives review, or Try Tilores Studio (Free) to reproduce a case file on your own data.

On this page

1. What should a reviewer be able to reconstruct?
2. Why is a match score not enough?
3. What belongs in the case-level evidence packet?
4. How should a bank build the evidence packet?
5. How can Tilores expose the underlying evidence?
6. How should the merge connect to screening decisions?
7. What should happen when someone challenges the merge?
8. FAQ
9. Can your team explain one challenged merge end to end?
10. Sources

A merged customer record can affect screening, service and risk decisions long after the matching job has finished. When a reviewer asks why two records became one entity, a score alone cannot show the inputs, policy and human actions that made the result defensible.

The evidence needs to travel with the decision. Source lineage, normalisation, field-level agreements and conflicts, the matching method and any subsequent correction all matter when the bank has to reconstruct one case. That record also keeps entity resolution distinct from the sanctions, PEP and adverse-media checks that may use the resolved identity downstream.

What should a reviewer be able to reconstruct?

A reviewer should be able to start with the two disputed source records and independently follow the path to the resolved customer. That path should show what the bank knew at the decision time, which evidence connected the records, which evidence conflicted, which policy accepted the result and what happened downstream.

This is a lineage problem as much as a matching problem. The Basel Committee describes data lineage as the traceability of data from its origin to its final use and says it is important for confirming data quality. For entity resolution, the final use is not merely the merged profile. It includes every customer, risk, screening or service decision that consumed that profile.

Accuracy also needs a challenge route. The ICO’s accuracy guidance says organisations must ensure that the source and status of personal data is clear and carefully consider challenges to accuracy. A bank should therefore preserve the source records and the correction history instead of overwriting the past with an unexplained current state.

That kind of traceability already has a regulatory description. The ICO’s guidance on explaining AI-assisted decisions asks organisations how they have made design and implementation processes traceable and auditable across the entire project. A bank’s merge evidence should meet the same test: a reviewer should be able to walk that trail directly, not accept a summary written after the fact.

The practical test is simple: could a reviewer answer both “why were these records linked?” and “why was that link allowed to affect this workflow?” The first question concerns evidence. The second concerns governance. A defensible case file needs both.

Why is a match score not enough?

A score compresses evidence. It does not show which fields agreed, which values were normalised, which contradiction was tolerated or whether the same score would have produced a different outcome in a higher-risk workflow.

Two records might share a date of birth and a normalised address while disagreeing on surname. Another pair might share a strong customer identifier but carry an old telephone number. A reviewer needs those facts separately. One aggregate number cannot explain the difference between them.

The evidence should also distinguish the matching method. Deterministic, fuzzy and probabilistic matching methods answer different questions and must not be collapsed into one label. Deterministic evidence may show exact agreement on a governed identifier. Fuzzy evidence may show similarity between name or address strings. Probabilistic evidence may combine several partial signals into a weighted conclusion. The case file should name the method that contributed, the configuration version it used and the result it produced.

Fuzzy accuracy depends on configuration, not on the method label alone. The UK’s Office for National Statistics reports that its own address-matching service matched more than 97% of input addresses to the correct reference address, a result produced by that service’s own comparison rules and synonym list. A bank’s case file should record the configuration that produced its result rather than assume fuzzy matching performs the same way everywhere.

If a human approved, rejected or corrected the outcome, the reviewer needs that decision as a separate event. Human judgment should not be hidden inside the machine score. The NIST AI Risk Management Framework says processes for human oversight should be defined, assessed and documented. The same discipline is useful whenever a scoring or model-assisted component influences a bank’s resolution policy.

What belongs in the case-level evidence packet?

The packet should be compact enough for one reviewer to use, but complete enough that another reviewer can reproduce the explanation without asking the engineering team to rebuild it.

Evidence layer	What to preserve	Question it answers
Case identity	Case ID, resolved entity ID, source record IDs, decision time and current status	Which exact merge is under review?
Source lineage	Originating systems, source timestamps, ingestion events and record versions	Where did each value come from?
Transformation history	Original values, normalised values and the transformation rule version	What changed before comparison?
Candidate evidence	Fields compared, agreements, conflicts, missing values and rejected alternatives	Why were these records considered together?
Match evidence	Deterministic rule, fuzzy comparison or probabilistic contribution, plus the resulting confidence signal	Why did the system favour a merge?
Decision policy	Threshold band, exception rule, review requirement and policy version	Why was the evidence sufficient for this workflow?
Human action	Reviewer identity, authority, timestamp, reason code and note	Did a person intervene, and why?
Downstream impact	Systems notified, checks rerun, alerts affected and access granted or withheld	What changed because of the merge?
Correction path	Split procedure, connection restriction, replay plan and correction history	Can the bank repair a wrong decision safely?

A bank reviewer examines conflicting record evidence, can split a proposed entity, and replays downstream checks.

Keep positive and negative evidence together. If two records merged because several attributes agreed, preserve the conflicts too. If a third record was considered but rejected, retain the reason. Without that negative evidence, a reviewer cannot tell whether the system evaluated plausible alternatives or simply returned the first acceptable candidate.

How should a bank build the evidence packet?

1. Step 1: Freeze the case state. Capture the entity, the two source records, their versions and the applicable configuration at the decision time. Do not let a later data refresh silently change the evidence under review.
2. Step 2: Recover the source lineage. List every originating system and ingestion event that supplied a compared value. Label authoritative, historical and user-supplied values according to the bank’s own data policy.
3. Step 3: Replay the normalisation. Show original and normalised values side by side. Record whether case folding, transliteration, telephone formatting, address parsing or another transformation changed the comparison surface.
4. Step 4: Separate the matching methods. Identify each deterministic rule, fuzzy comparison and probabilistic contribution independently. Do not describe fuzzy and probabilistic logic as if they were the same method.
5. Step 5: Apply the decision policy. Bind the evidence to the threshold, exception and review policy that applied to this workflow. A policy version matters because a later calibration may produce a different result from the same records.
6. Step 6: Record human oversight. Preserve the reviewer, authority, timestamp, action and reason. If nobody reviewed the case, state which policy authorised automatic acceptance and which conditions would have routed it to review.
7. Step 7: Trace impact and reversibility. List the downstream systems and decisions that consumed the merged entity. Test how the bank would split the records, prevent an immediate re-merge, replay affected checks and retain a non-misleading correction history.

This sequence makes the evidence reproducible. It also separates three events that are often confused: the system proposed a link, policy accepted the link and a downstream process acted on the resolved customer.

How can Tilores expose the underlying evidence?

Our runtime integration point is the GraphQL API. An entity query can expose the entity identifier, contributing records, edges and an entity score, while search can also return a hit score. Our release notes define score as the overall quality of matches within an entity, while our API reference defines hitScore as how closely a match aligns with the supplied search parameter.

Those signals are inputs to the bank’s evidence packet, not universal approval thresholds. The bank still needs to preserve its configured schema, rule identifiers, policy version, workflow consequence and any human action. A number without that context cannot explain why one merge was accepted while another was escalated.

The graph structure is useful because it keeps the contributing records and the connections between them inspectable. The audit view should translate that technical evidence into a case narrative: record A and record B were compared, these attributes agreed, these attributes conflicted, this rule or score applied and this policy produced the current entity state.

Correction must be part of the design. We can remove records or edges through our GraphQL disassembly operation, but the bank should wrap any split in its own approval, downstream replay and correction-history controls. The objective is not merely to change the graph. It is to leave a reviewer with a complete account of what was changed and why.

How should the merge connect to screening decisions?

The impact check should ask whether the merge changes which aliases, beneficial owners or relationships are sent to sanctions, PEP and adverse media screening. It should also show which screening run consumed the merged state and which list or dataset version that run used.

Calibration is part of the control, not an implementation footnote. The EBA’s restrictive-measures guidance includes technical guidance on choosing the screening system, screening customers and transactions, and calibrating that system. A case file should therefore keep resolution evidence and screening evidence linked but distinct. The resolution decision identifies the subject. The screening process applies its own lists, settings and disposition logic.

List currency matters as well. OpenSanctions updates its data regularly to keep sanctions and PEP lists current. If the bank uses that source, its evidence should pin the dataset version or export checksum used for the case. A later list update must not make the historical explanation ambiguous.

For a broader operating pattern, our guide to AML and KYC with real-time entity resolution separates resolution, screening, analyst judgment and the decision trail. That separation is important here: a record merge should never be presented as if it were itself a sanctions or customer-risk decision.

What should happen when someone challenges the merge?

Treat a challenge as a test of the evidence system, not as an exception to hide. Open the preserved case state, reproduce the comparison and establish whether the dispute concerns a source value, a transformation, the matching configuration, the acceptance policy or a later human action.

If the records should not have merged, split them under a controlled change. Record the reason, protect against an immediate repeat of the same incorrect link and identify every downstream process that used the merged state. Screening, customer servicing, fraud controls, reporting and data-subject workflows may each need a different replay or correction response.

Do not erase the fact that the error occurred when that history is necessary to explain previous actions. The current record should be accurate, while the event history should clearly distinguish the original decision, the challenge, the correction and the present state. That gives the reviewer an honest chronology without presenting superseded data as current truth.

Retention timing matters alongside content. The UK’s Money Laundering Regulations require firms to keep customer due diligence documents and transaction records for five years from when a business relationship ends, capped at ten years. A merge’s correction and challenge history should survive at least as long as the underlying due diligence record it explains.

A useful closure record answers four questions: was the merge correct, what changed, which downstream consequences were repaired and what control will reduce recurrence? If any answer is missing, the case is corrected operationally but not closed for audit.

FAQ

Does a high match score prove that two records belong to one customer?

No. A score summarises configured evidence. The reviewer still needs field-level agreements and conflicts, source lineage, the matching method, the applicable policy and any human decision.

Must every bank customer-record merge receive manual review?

That depends on the applicable law, supervisory expectations, use case and bank policy. The bank should document when automatic acceptance is permitted and when ambiguity or consequence requires human review. The case file must show which route applied and why.

Should a regulator receive unrestricted access to all raw customer data?

That depends on the regulator’s lawful powers and the scope of the request. The bank should provide the evidence required for that purpose, applying access, minimisation and confidentiality controls where lawful. The evidence design should make relevant provenance inspectable while retaining the ability to provide raw records when legally required.

What should happen if a merge is wrong?

The bank should split or otherwise correct the entity, prevent an immediate recurrence, replay affected downstream checks and preserve a clear history of the original decision and correction.

How should sanctions, PEP and adverse media checks appear in the packet?

They should appear as downstream checks tied to the resolved entity state, screening configuration, dataset version, timestamp and analyst disposition. They should not be confused with the entity-resolution decision itself.

Can your team explain one challenged merge end to end?

Test the question on a real case. Start with two source records and ask a reviewer to reproduce the merge, its policy basis, its downstream impact and its reversal path without help from the original engineer.

Book a Demo to review the evidence pattern with our team, or Try Tilores Studio (Free) to inspect entity-resolution behaviour on your own data.

Sources

1. Implementation of the Principles for Effective Risk Data Aggregation and Risk Reporting, Basel Committee on Banking Supervision
2. Principle (d): Accuracy, Information Commissioner’s Office
3. Part 1: The Basics of Explaining AI, the Principles to Follow, Information Commissioner’s Office
4. Guidelines on Internal Policies, Procedures and Controls to Ensure the Implementation of Union and National Restrictive Measures, European Banking Authority
5. AI Risk Management Framework Core, National Institute of Standards and Technology
6. Using Data Science for the Address Matching Service, Office for National Statistics
7. The Money Laundering, Terrorist Financing and Transfer of Funds (Information on the Payer) Regulations 2017, Regulation 40, UK Legislation
8. Release Notes, Tilores
9. API Reference, Tilores
10. Downloading the Data and Keeping It Fresh, OpenSanctions
11. Data Privacy Compliance, Tilores
12. AML and KYC With Real-Time Entity Resolution, Tilores