Is a Wrong Customer Match a Reportable GDPR Incident, and What Must a Bank Document?

TL;DR: A wrong customer match is not automatically a GDPR-reportable breach, but it meets GDPR’s own definition of a personal data breach more often than teams assume: one person’s financial data sitting inside another person’s record is usually both an integrity breach and a confidentiality breach at once. The risk assessment decides whether it is reportable. The rule that created the merge, who accessed it, and the steward’s reasoning decide whether that assessment can be defended.

Book a Demo · Try Tilores Studio (Free)

On this page

1. Why is a wrong merge different from a missed match?
2. Is a wrong customer match a personal data breach under GDPR?
3. What does “explainable” have to mean when a regulator asks why two records merged?
4. How does a human-in-the-loop review change what gets documented?
5. Where does Tilores fit into this?
6. What should a bank keep on file after a wrong-match review?
7. Frequently asked questions
8. Sources

A bank’s entity resolution programme is usually funded and measured as a data quality project: fewer duplicate records, a cleaner 360 view, less manual reconciliation. A wrong merge tends to get filed under the same heading as a missed one, an accuracy metric to improve next quarter.

That framing holds for a missed match. It does not hold for a wrong one. When two different customers are merged into a single entity, one person’s balance, address or risk flag sits for a period inside a record the bank discloses, screens and acts on as someone else’s. GDPR already has a name and a test for that kind of event, and it is worth knowing both before the first wrong merge reaches a steward’s queue, not after.

Why is a wrong merge different from a missed match?

A missed match leaves two records of the same person unconnected. The bank undercounts its own customer, perhaps repeats a request for information it already holds. The error costs money, but the data describing each person stays attached to that person.

A wrong match does something else. It takes two different people and treats them, for a period, as one. Every field in the merged entity, an address, an income figure, a flag from a prior case, now sits inside a record that is partly about someone else. Anyone who queries that entity, a credit decision, a servicing call, a data subject access request, is acting on a mixture of two people’s personal data, attributed to only one of them.

The consequence is sharper inside financial-crime screening. A wrong merge that pulls a sanctions hit, a politically exposed person flag or adverse media onto the wrong customer’s file misattributes a risk classification to someone who never earned it. OpenSanctions’ politically exposed persons dataset alone covers roughly 1.96 million entities, including about 717,580 individual PEP targets, screening results a bank must keep accurate for the right person, not a near-duplicate of them.

We were built inside a German consumer credit bureau operating under GDPR, where a wrong match meant a fine, not a missed opportunity. Precision in entity resolution is not a feature competing with recall on a scorecard; it is a privacy control, assessed the way a bank assesses any other control that keeps one customer’s data where it belongs.

Is a wrong customer match a personal data breach under GDPR?

Article 4(12) of the UK GDPR defines a personal data breach as “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed,” with the same operative wording in the EU GDPR. Nothing in that definition requires an attacker, a lost laptop or a hack. An internal process that alters data, or that puts one person’s data in front of the wrong recipient by accident, is already inside its scope.

The European Data Protection Board’s Guidelines 9/2022 group every breach into three types, and one incident can be more than one at once: a “confidentiality breach” where data is disclosed to or accessed by someone unauthorised, an “integrity breach” where data is altered without authorisation, and an “availability breach” where data is lost or destroyed. A wrong customer merge is usually the first two together. The record has been altered to contain facts that are not true of the person it is filed under, which is the integrity breach. Every system, person and automated decision that reads the merged entity during the error window is shown another customer’s data under the wrong account, which is the confidentiality breach.

Breach type (EDPB Guidelines 9/2022)	GDPR’s own wording	How a wrong customer merge triggers it
Confidentiality breach	Unauthorised or accidental disclosure of, or access to, personal data	Every query, screen or decision that reads the merged entity during the error window surfaces one customer’s data under the other customer’s identity
Integrity breach	Unauthorised or accidental alteration of personal data	The merged record now contains facts, address, income, a risk flag, payment history, that are not true of the person it is filed under
Availability breach	Accidental or unauthorised loss of access to, or destruction of, personal data	Not the usual pattern for a wrong merge, though an unmerge performed without preserving both originals could create this risk separately

The integrity half of that breach lines up with a separate GDPR duty. Article 5(1)(d) requires personal data to be “accurate and, where necessary, kept up to date,” with inaccurate data “erased or rectified without delay.” A wrong merge breaches that principle the moment it happens, independently of whatever the Article 33 risk test later decides about reporting it. Article 16 gives the affected customer the same duty from their side: a right to have inaccurate personal data corrected without undue delay. The ICO’s guidance on the right to rectification puts a working deadline on that duty, one calendar month, extendable to three for a complex or high-volume request. For a wrong merge, the unmerge is not a courtesy sitting outside the compliance process. It satisfies the accuracy principle and the rectification right in the same action.

That classification is a fact for the bank’s own assessment, not a verdict that every wrong merge must be reported. Article 33(1) sets a risk-based test: the supervisory authority must be told “without undue delay and, where feasible, not later than 72 hours after having become aware” of the breach, unless it is “unlikely to result in a risk to the rights and freedoms of natural persons.” The Information Commissioner’s Office is explicit from the other side: “You do not need to report every breach to the ICO”, only the ones where the risk comes out as likely. The European Data Protection Board’s Guidelines 01/2021 on breach-notification examples make the same point concrete outside banking: a retailer that mixed up two customers’ packing bills, so each received the other’s name, address and order, judged the resulting breach low risk because only two people were affected and no special category data was involved, not because a mix-up is automatically harmless. A merge caught and reversed before any decision used the mixed data carries a different risk than one that reached a credit decision or a letter sent to the wrong address. The documentation has to show which happened. Each case turns on its own facts, and it is a bank’s own data protection officer or legal counsel, not a general rule, who decides the specific case.

What does “explainable” have to mean when a regulator asks why two records merged?

“Model confidence 0.91, threshold 0.90” answers a different question than the one a regulator, or a data subject access request, actually asks. It restates that the system decided to merge. It does not say why. A number beside a threshold is not something a compliance officer can put in a breach assessment, because it does not say which fields agreed, which disagreed, or which rule fired.

The documentation that answers “why were these two records merged” has to point at the rule, not the score. Our earlier piece on confidence bands and audit trails covers the score side; what matters for a breach assessment sits underneath it. Every link in our entity graph is stored as an edge between two records plus the identifier of the rule that created it, so the rule is part of the data itself, not a separate log that can drift out of sync. Rule changes are versioned, so a bank can show a regulator which rule version was active when a past merge happened, not only why today’s merge happened.

Consistency rules add a layer a score cannot show. An entity-level invariant, a date of birth that has to agree across every record, blocks a match however strong the other evidence is. Two records with a 92% name match and a shared address still will not merge if the dates of birth disagree, because the invariant is checked first. A regulator reading a complaint about a wrong merge, or a missed one, can see that specific rule, not only a percentage.

How does a human-in-the-loop review change what gets documented?

Banks describe the same requirement independently of each other: automatic merge above a confidence threshold, automatic rejection below a lower one, and a steward reviewing everything between, with every decision logged and reversible. That middle band is where most of the documentation work for a wrong-merge review happens, because a person, not a rule, made the final call.

A worked example: two records score 0.71, below the 0.85 auto-merge threshold and above the 0.55 auto-reject threshold. Surname and address agree once normalised. One record is missing a date of birth, so the consistency check can neither confirm nor block the match on that field. The two records’ email addresses were created eleven years apart. A steward decides to merge, keep separate, or escalate, and that decision, with its stated reasoning, is what a bank needs on file, not only the score that queued the pair.

Reversibility matters as much as the original decision. Merge, unmerge and deletion are first-class operations in our model: an entity can split back apart, and resubmitting a record under the same source identifier updates it in place instead of creating a second, ambiguous copy. A bank that can show a merge was caught and reversed inside its own stewardship window has a different document to hand a regulator than one that discovers the error only after a downstream decision used the mixed record.

A proposed match moves through auto-merge, steward-review or auto-reject bands before either outcome is documented for a breach assessment.

Where does Tilores fit into this?

We are the matching engine and the audit trail underneath this decision, not a GDPR compliance service and not legal advice. What we provide: every query, export and deletion against resolved data is logged, so a bank can reconstruct who saw a merged entity and when; each merge is attached to the rule that created it, not a bare score; and merges, unmerges and rule changes are versioned, so the state of the matching logic at the time of a past decision can be reproduced, not reconstructed from memory.

What a bank still has to do itself: run its own Article 33 risk assessment on each wrong merge, decide whether it meets the “high risk” bar in Article 34 for notifying the customer directly, and keep the documentation inside its own records-management process. We do not make that legal judgement, and a bank should not treat a vendor’s audit log as a substitute for its own compliance sign-off.

The fair comparison is with what a bank would otherwise build or buy to get the same documentation.

Approach	How it explains a merge to a regulator	What the bank still owns
In-house matcher built on existing tooling	Usually a similarity score and the fields compared; rarely a stored rule identifier or a versioned rule history	Building and maintaining the audit trail, the consistency-rule logic and the steward queue from the ground up
Machine-learning matching on a general data platform	A model confidence figure, which restates the decision; tracing a specific merge back through model internals happens after the fact	A separate audit, consistency-rule and reversibility layer, built apart from the matching model itself
Full master data management suite	Often strong on governance workflow, but priced and scoped for a size of programme most banks running one matching problem do not need	A licence and implementation sized for a larger platform than the matching problem alone requires
Tilores	Rule ID on every edge, versioned rule changes, logged queries and exports, reversible merge and unmerge	The bank’s own Article 33 and Article 34 risk assessment and regulatory sign-off; we document the mechanism, the bank owns the legal conclusion

Try the rule-ID and versioning behaviour against your own records in Tilores Studio, free in local mode for up to 100,000 records with no data leaving the machine, before deciding what it changes about your current wrong-merge documentation.

What should a bank keep on file after a wrong-match review?

Whether the final assessment is “notify” or “no action needed,” the same underlying record supports either outcome if it is kept the same way every time.

1. Record the rule, not only the score. Log the rule ID or model version that created the merge, not a similarity figure on its own.
2. Record what matched and what did not. Capture the exact fields that agreed and disagreed, including any consistency-rule invariant that was checked.
3. Record who touched the merged entity. Log who or what accessed the merged entity, and for what purpose, during the window between the wrong merge and its correction.
4. Record the steward’s decision and reasoning. Where the match sat inside a human-review band, not an automatic one, keep the steward’s decision and the stated reason for it.
5. Record the Article 33(1) risk assessment. Write down the likelihood and severity of risk to the affected individuals and the reasoning behind notifying or not notifying.
6. Record the remedial action. Note when the entity was split back apart and confirm both original records were preserved intact.

A bank that keeps this record for every wrong merge, not only the ones a regulator later asks about, turns the Article 33(5) documentation duty into a standing file a compliance team can pull on request, whether the entity sits under the UK GDPR, the EU GDPR, or, for a German-regulated entity, the notification process the BfDI sets out.

Frequently asked questions

Does a missed match count as a GDPR breach the same way a wrong merge does?

No. A missed match leaves two records of the same person unconnected, so the data describing each person stays attached to that person. A wrong merge puts one person’s data inside another person’s record, which is why GDPR’s test for accidental alteration, disclosure or access applies to it differently.

Is every wrong customer match reportable to a data protection regulator?

No. GDPR’s own test is risk-based. Article 33(1) requires notification unless the breach is “unlikely to result in a risk to the rights and freedoms of natural persons”, and the ICO is explicit that organisations do not need to report every breach. A merge caught and reversed before any decision used the mixed data carries a different risk than one that reached a credit decision or a letter sent to the wrong address.

What is the difference between a confidentiality breach and an integrity breach in a wrong-merge case?

A merged record containing facts that are not true of the person it is filed under is an integrity breach, an “unauthorised or accidental alteration” under the EDPB’s definition. Anyone who reads, screens or acts on that merged entity during the error window is also exposed to a confidentiality breach, “unauthorised or accidental disclosure of, or access to” another person’s data. A single wrong merge is usually both at once.

Does Tilores decide whether a wrong merge has to be reported?

No. We provide the audit trail, the rule ID behind each merge, and the reversible merge and unmerge mechanism a bank needs to run its own Article 33 and Article 34 assessment. The risk judgement and the regulatory notification decision stay with the bank’s own data protection function.

What is the fastest way to tell if a merge was high risk under Article 34, not only reportable under Article 33?

Check what the merged record was used for during the error window, not only how it was created. Article 34’s “high risk” bar is about consequences for the individual, a declined application, a wrongly applied risk flag, or a disclosure to a third party, so the steward’s log of who accessed the entity and for what purpose is the evidence that answers this question, not the match score that created the merge.

Sources

1. Tilores Data Compliance and Security, Tilores.
2. Explainable Entity Resolution: Confidence Scores, Match Thresholds and Audit Trails, Tilores.
3. Entity Resolution Proof of Concept: 7 PoC Inputs a Bank Needs in 2026, Tilores.
4. UK GDPR, Article 4: Definitions, legislation.gov.uk.
5. UK GDPR, Article 5: Principles Relating to Processing of Personal Data, legislation.gov.uk.
6. UK GDPR, Article 16: Right to Rectification, legislation.gov.uk.
7. UK GDPR, Article 33: Notification of a Personal Data Breach to the Supervisory Authority, legislation.gov.uk.
8. UK GDPR, Article 34: Communication of a Personal Data Breach to the Data Subject, legislation.gov.uk.
9. Regulation (EU) 2016/679 (General Data Protection Regulation), EUR-Lex.
10. Personal Data Breach Assessment, Information Commissioner’s Office.
11. Right to Rectification, Information Commissioner’s Office.
12. Guidelines 9/2022 on Personal Data Breach Notification Under GDPR, Version 2.0, European Data Protection Board.
13. Guidelines 01/2021 on Examples Regarding Personal Data Breach Notification, Version 2.0, European Data Protection Board.
14. Information on Reporting a Data Protection Breach (Art. 33 DSGVO), Bundesbeauftragter für den Datenschutz und die Informationsfreiheit.
15. Politically Exposed Persons Dataset, OpenSanctions.