Every pension company in Turkey has skeletons in its data warehouse. Rounding conventions that drifted over a decade. Contribution allocation logic that was patched three CTOs ago. Suspense accounts that nobody wants to touch because the person who understood them retired in 2017. As long as the company runs alone, these skeletons stay in the closet — the daily EGM reconciliation absorbs the noise, auditors sign off, life continues.
Then the acquisition closes. And on day one of the combined entity, the regulator does not care that there were ever two companies. EGM expects a single, coherent, historically consistent submission — as if the merged book had always been under one roof. That is when the skeletons walk out together, at the same time, and start comparing notes.
The Regulator's Fiction Versus the Data's Reality
EGM, SEDDK, and the Hazine treat the surviving entity as legally continuous. That is a clean legal fiction. It is not a data fiction.
In practice, you are holding:
- Two policy numbering schemes with overlapping ranges
- Two chart-of-accounts mappings to the same regulatory line items
- Two interpretations of what constitutes a "paid contribution" on a partial-month cancellation
- Two versions of state contribution (devlet katkısı) reconciliation history, each with its own drift against EGM's authoritative record
- Two customer master files where the same TCKN exists as two different customers with different KYC vintages
The regulator will accept exactly one answer per field per participant per day. You have two. Sometimes you have three, because the acquired company itself was the product of an earlier merger nobody fully finished cleaning up.
Where the First EGM Submission Breaks
The first post-consolidation EGM file is where theory meets the loading process. The failures cluster in predictable places:
State contribution history. Company A calculated devlet katkısı on gross contribution before entry fees. Company B calculated it after. Both were defensible under earlier circulars. EGM has a single running total per TCKN going back to 2013. Reconciling the two histories against the regulator's ledger is not a mapping exercise — it is an archaeology project, and every discrepancy becomes a manual case.
Vesting and hak kazanma dates. If the acquired book used a different interpretation of when the 10-year clock starts (contract date vs. first contribution date vs. first cleared contribution date), you now have participants whose vesting status flips depending on which system you believe. Pick wrong and you either pay out early or trigger a customer complaint that ends up at SEDDK.
Fund allocation on in-flight transactions. Any contribution in transit at the merger cut-off has a source-system allocation logic and a target-system allocation logic. The unit prices differ. The T+2 settlement rules differ. Someone has to decide, per transaction, which regime applies — and document it well enough to survive an audit three years later.
Suspense and askı accounts. Every pension company has a suspense book: contributions that came in without a clean policy match, refunds that never cleared, corrections that were parked "temporarily." Both companies had one. Now you have a combined suspense that is larger than either standalone book and belongs to nobody organizationally.
The Problems Both Pipelines Were Hiding
The uncomfortable truth of any pension merger: the data problems you discover are not created by the merger. They existed. The merger just forces them into the same reporting line.
Before consolidation, each company's daily EGM reconciliation had a tolerance. Small breaks got absorbed into a rolling correction. The pipeline "worked" because it was allowed to be approximately right, and because the humans running it knew which numbers to trust and which to override. That institutional knowledge does not merge. It sits in two different operations teams, half of which will not be at the combined company in six months.
When you combine the books, tolerances stack. A 0.02% drift in Company A and a 0.03% drift in Company B do not average out — they compound, because they are drifts in different directions on different subsets of participants. The first combined submission produces reconciliation breaks that neither team has ever seen at that scale, and neither team has the context to explain.
What Actually Has to Happen
There is no clean solution. There are only disciplined ones.
- Freeze both source systems in read-only replicas before cutover. You will need to answer regulator questions about pre-merger states for years. The replicas are your only defensible truth.
- Reconcile against EGM's history, not against each other. The regulator's record is the tie-breaker. Any internal reconciliation that does not resolve to the EGM authoritative ledger is theater.
- Build a per-participant provenance field. Every record in the combined system should carry which legacy company it originated in and which mapping rule set was applied. This is what saves you when a customer complaint lands 18 months later.
- Do not migrate the suspense book. Resolve it first. Bringing an unresolved askı hesabı into a combined system is how you inherit somebody else's audit finding.
- Accept that the first three EGM submissions will require manual case management. Staff for it. Budget for it. The teams that pretend automation will handle it end up with SEDDK correspondence.
The Real Cost
The deal model assumes integration takes 12 to 18 months. The data reality is that the regulatory reporting stops being fragile at around month 30, and the last legacy-driven customer complaints resolve somewhere in year four. Anyone who has actually run a pension consolidation in Turkey knows this. Anyone selling one prefers not to mention it.
The merger closes on a signature. The data merger closes when the last participant with a pre-consolidation contribution passes their vesting date under a rule set that both legacy systems agree on. That day is further away than the integration plan says.