Every BES operations team eventually finds them. Two participant records, different sözleşme numbers, same underlying human. Maybe the TC kimlik was entered wrong in 2014 and corrected in 2019. Maybe a woman's soyadı changed after marriage and the transfer-in from another pension company created a fresh record instead of matching the existing one. Maybe the participant themselves opened a second contract because they forgot about the first.
The engineer looks at this and sees a data quality problem. There is a merge queue somewhere, probably reviewed weekly, and someone eventually presses a button that consolidates the two into one. The MDM system logs it. Everyone moves on.
This is wrong. Not technically wrong — legally wrong. And the difference matters when EGM asks you to reconstruct what happened.
What a merge actually rewrites
When you collapse two EGM identities into one, you are not deduplicating rows. You are retroactively asserting that every regulatory event previously attributed to Identity A and Identity B was in fact a single participant's history. That assertion touches:
- Devlet katkısı entitlements. The 25% state contribution is calculated per participant, with annual and lifetime caps. Two identities may have independently accrued state contribution on parallel contributions. Merging them can push the combined participant over caps that were never triggered when they were separate — or reveal that the state overpaid.
- Vesting clocks for state contribution. The 3/6/10-year staircase (15%/35%/60%/100%) runs from the participant's system entry date. If Identity A entered BES in 2013 and Identity B in 2020, the merged participant's vesting position is not obvious and not automatic.
- Stopaj calculations on exit. Withholding tax on ayrılma depends on holding period and exit reason. Two contracts with different start dates produce different withholding when merged versus kept separate.
- Every EGM submission that cited either identity. Monthly katılımcı reports, state contribution requests, transfer notifications — all of them referenced identity keys that you are now claiming were the same person all along.
A merge is a statement to the regulator: everything we previously told you about these two people was actually about one person. That is not a data operation. That is a legal filing.
The three flavors of duplicate, and why they're not the same
Treating all duplicates identically is the first mistake. In practice there are three distinct scenarios and each has different legal weight:
1. Data entry correction (TC kimlik typo, name misspelling at onboarding). The two identities were never legitimate. One is a ghost. Here the merge is closer to a correction, but you still have to unwind any devlet katkısı that was requested under the ghost identity, because those requests were made under a TC that doesn't exist or belongs to someone else.
2. Legitimate identity change (soyadı değişikliği, TC re-issue). Both identities were valid at the time they existed. The participant genuinely had two names in two periods. The merge is not a correction — it is a continuity assertion. Regulatory history under the old name remains valid; you are linking, not overwriting.
3. Genuine dual enrollment (transfer-in collision, second contract). The participant actually had two active BES contracts simultaneously. This is not a duplicate in the data sense at all. Merging them may be legally impossible without unwinding contributions, because two contracts means two separate legal relationships that both accrued rights.
A deduplication queue that doesn't distinguish these will produce a legally identical audit trail for three legally different events. That is the finding waiting to happen.
What a defensible merge protocol looks like
At minimum, before any two identities are collapsed, the following must exist as a record — not in a ticket, not in a Jira comment, but in a system the auditor can read three years later:
- The evidence. Nüfus cüzdanı copy, marriage certificate, EGM correspondence, participant declaration. Whatever established that Identity A and Identity B are the same person.
- The classification. Which of the three flavors above. This determines everything downstream.
- The pre-merge snapshot. Full state of both identities immediately before merge: contribution history, devlet katkısı balance, vesting position, fund allocations, every regulatory reference number that touched either identity.
- The reconciliation. What changes in devlet katkısı entitlement, if any. What is being reported to EGM as a correction. What stopaj recalculation applies.
- The authorization. Not a data steward. A compliance sign-off with a name attached, because this is a legal act.
- The forward reference. Every future report that touches this participant needs to know a merge occurred, because reconstruction of pre-merge periods will reference identities that no longer exist as active records.
Almost no BES pipeline I have seen implements this end-to-end. Most implement steps 1 and 6 and call it done. The middle steps live in someone's email.
The audit scenario nobody prepares for
EGM audit, three years after a merge. Auditor asks: reconstruct the devlet katkısı balance of participant X as of Q2 2022. In 2022 that participant existed as two identities. Your current system shows one participant with a merged history. The auditor is not asking about now. The auditor is asking what you reported in 2022, and whether it was correct at the time.
If you cannot produce the pre-merge state of both identities, with the same numbers you reported to EGM at the time, you cannot answer the question. If your merge process overwrote the historical records instead of preserving them alongside the merged view, the audit trail is gone.
This is why merges have to be additive, not destructive. The old identities should remain queryable in their pre-merge state forever. The merge is a new fact layered on top, not a rewrite of the past.
The uncomfortable conclusion
Most BES data platforms were built by teams who treated participant identity as a data problem to be solved with better matching algorithms and a review queue. Fuzzy matching on name and date of birth, TC kimlik as the strong key, human review for edge cases. That architecture is fine for a CRM. It is not fine for a pension system where every identity assertion has tax consequences and every merge is a statement to the state.
If your BES pipeline can merge two participants without producing a document a lawyer would sign, you don't have a deduplication system. You have a liability generator with a nice UI.