Case 01
I had mistaken a shared contact for a shared identity
In 2019 I supported a proposal to merge customer-reference pairs that shared a telephone number. The delivery case promised a simpler party register and fewer apparent duplicates for service colleagues to navigate. As director of information integration, I approved the matching premise before asking for a sufficiently varied review of the relationships behind the contact. That was my error, rather than a defect I could attribute only to the source data.
Rina Zeqvamni challenged the premise using 920 candidate pairs. The review supported a same-person relationship for 610, identified 230 as different people and left eighty unresolved. Common contacts included households and assisted arrangements. The exercise did not establish that every shared contact was unsuitable evidence; it established that this field could not carry the automatic identity conclusion I had attached to it.
The delivery sponsor wanted to retain the merge and repair exceptions later, arguing that a visibly smaller register would help staff immediately. I withdrew the proposed automatic merge before it entered the live customer account. A ₹62 lakh correction and six-week delay put the supported links through controlled stewardship, kept the different-party pairs separate and retained the unresolved group for additional evidence. Source records remained available for examination.
We accepted a less tidy account and continuing work for the eighty unresolved pairs. The 610 supported relationships were findings for the reviewed set, not a declaration that every other link in the insurer was correct. No premium or claim decision was changed through this exercise, and the case does not report an actual customer disclosure.
What changed in my practice was the question asked before a matching rule was approved. I now want an explanation of what a shared attribute could mean in the circumstances of the people using it. A convenient key may describe how to reach someone without establishing who owns the record. The data function must defend that distinction before a delivery commitment makes the shortcut difficult to withdraw.