Every few years, SEDDK or EGM ships a new reporting framework for BES. The industry treats it as an engineering problem: new schema, new fields, new submission format, new deadline. Teams spin up projects, negotiate with vendors, extend the warehouse, ship it. The regulator accepts the first submission. Everyone moves on.
Then someone runs a historical comparison — maybe an actuarial review, maybe an internal audit, maybe a customer complaint that requires reconstructing a state change from 2019 — and the whole thing falls apart. The old data does not mean what the new framework thinks it means. And nobody wrote down what it actually meant when it was captured.
This is the grandfathering problem, and it is worse in BES than in almost any other regulated pipeline, because the product itself is a multi-decade contract governed by rules that keep shifting underneath it.
The core issue: definitions are not backward compatible
When a new reporting rule redefines a field — say, what counts as an "active participant" or how to classify a state transition between katkı payı arrears and sözleşme askıya alma — you have three bad options:
- Recompute history under the new definition. Cheap, fast, and legally indefensible. You are asserting things about the past that were never true under the rules in force at the time.
- Freeze history under the old definition and apply the new one only going forward. Correct in principle, but produces reports where trend lines are meaningless and where the same participant can appear in two contradictory states across the cutover date.
- Maintain both, in parallel, forever. The honest answer. Also the one nobody budgets for.
Most firms silently pick option one. The new pipeline reads old records through new logic. A sözleşme that was classified one way in 2020 under the old katılım payı rules gets reclassified in the 2024 report because the definition of the state changed. Nobody flags it. The regulator sees consistent numbers. The auditor, if they look carefully, sees a firm rewriting its own legal history.
A concrete example: the devlet katkısı hak ediş calculation
The state contribution vesting schedule has been revised multiple times. Each revision changed which contribution periods count toward which vesting tier, and how partial years are handled at the boundaries.
A participant who joined in 2013, paused contributions in 2016, resumed in 2019, and exited in 2022 has a vesting position that depends on which rule set governed which period. The legally correct answer is a stitched calculation: rule A for 2013–2015, rule B for 2016–2018, rule C onward. The convenient answer — and the one most reporting pipelines actually produce — is to apply the current rule to the entire contribution history, because that is what the current data model expresses.
The two numbers differ. Sometimes by small amounts. Sometimes by enough to change what the participant is owed at exit. And because the pipeline only stores the current-rule interpretation, the original calculation cannot be reproduced without going back to raw transaction logs — which most firms have retained but no longer have the code to interpret.
Why this is not solvable by "better data governance"
The standard consultant answer is: version your schemas, store effective-dated rule definitions, keep a bitemporal model. This is correct advice and I have given it myself. It also does not help you if your pipeline was built in 2013 without any of those things, which describes essentially every BES pipeline in production today.
Retrofitting bitemporality onto a system that was never designed for it is not a migration. It is an archaeology project. You are trying to reconstruct, from surviving artifacts, what a piece of data meant at the moment it was written — often years before the person who wrote it left the company.
The practical constraints:
- Source systems have been replaced, sometimes twice. The original field semantics live in vendor documentation that no longer exists.
- Operasyon teams applied undocumented business rules to handle edge cases. Those rules were correct at the time and are now invisible.
- Regulatory correspondence — the actual letters clarifying how a specific rule should be interpreted — sits in email archives and physical files, not in the data lineage.
- The people who negotiated the original interpretations with SEDDK are retired or at a competitor.
What actually works
I have seen two approaches that hold up under audit. Neither is cheap.
The first is explicit rule-set tagging at the record level. Every historical record carries a marker for which regulatory framework governed its capture. The reporting layer then has to explicitly translate — with documented, reviewable logic — between frameworks. When a new framework arrives, you write the translation rules once, review them with legal and actuarial, and freeze them. Old reports remain reproducible. New reports are defensible because the translation is visible.
The second is acknowledging the discontinuity in the report itself. Some firms — the more careful ones — publish trend data with explicit breaks at regulatory change dates, and footnote the methodology. This is unpopular with management because it makes charts ugly. It is popular with auditors because it is the truth.
The worst approach, and the most common, is the silent retroactive reclassification: run the new logic over old data, publish a smooth trend line, and hope nobody asks. This works until it does not. When it fails, it fails as a regulatory finding, and the finding is not about the data — it is about the firm having misrepresented its own history.
The uncomfortable conclusion
A BES pipeline is not really a data pipeline. It is a legal record of a long-duration contract governed by rules that change faster than the contracts mature. Treating a framework migration as an engineering project — new schema in, old schema out — is the category error that produces most of the compliance problems I see.
Before you build the new pipeline, decide what you are going to say the old data means. Write it down. Get legal to sign it. Then build. The pipeline is the easy part.