The uncomfortable truth about most BES (Bireysel Emeklilik Sistemi) data pipelines is this: they can produce the number, but they cannot prove the number. The submission goes to EGM on time, the aggregate figures reconcile, the regulator accepts the file. Everyone assumes the plumbing is understood. Then one day a specific question arrives — usually about a specific participant, on a specific date, with a specific balance — and the entire chain of assumptions collapses.
I have seen this play out at more than one pension company. The pattern is always the same. The team that built the pipeline three years ago is partially gone. The intermediate tables have been refactored twice. The Informatica or SSIS jobs were rewritten in Python. The reference data lookups now hit a different source. Nobody can reconstruct, with confidence, how a 47.823,14 TL balance on a katılımcı account statement was actually derived from raw contribution records, unit prices, state contribution accruals, and fund conversions.
Lineage Is Not Documentation
Most firms treat data lineage as a documentation problem. They buy a catalog tool, run a scanner, and produce diagrams that show table A feeds table B feeds table C. This satisfies audit checklists. It does not answer the regulator's actual question.
The regulator does not ask "which tables were involved." The regulator asks:
- Why does this participant's fund allocation on 15 Mart differ from the allocation implied by their signed election form?
- Why does the state contribution (devlet katkısı) accrual for this account use a rate that appears to belong to a prior period?
- Why does the aggregate submitted to EGM for fon dağılımı reconcile to the general ledger but not to the sum of individual participant records?
Answering these requires reconstructing transformation logic at the row level, at a point in time, across systems that were designed to expose outputs — not the reasoning that produced them.
Why BES Pipelines Are Structurally Blind
Pension pipelines in Türkiye grew organically over fifteen years of regulatory change. Each new EGM circular or SEDDK requirement was bolted onto the existing structure. The result, in almost every firm I have worked with, contains the same architectural failures:
- Overwritten state. Participant balances are updated in place. The prior value is gone. When someone asks how yesterday's balance became today's balance, the pipeline has to re-derive it from event logs that may or may not still be complete.
- Reference data without effective dating. Fund codes, contribution rates, and state contribution parameters are stored as current values. A calculation done in 2022 cannot be reproduced in 2025 because the parameter row has been updated three times since.
- Transformation logic embedded in stored procedures nobody reads. The actual business rule — how a partial contribution is allocated across funds when the participant has multiple active plans — lives in 400 lines of T-SQL that was last modified by someone who left in 2021.
- Reconciliation at the aggregate level only. Daily controls check that totals match. They do not check that the composition of the total is explainable. A pipeline can pass every reconciliation for years while individual records are quietly wrong.
What the Regulator Actually Wants
When EGM or SEDDK sends a data request, they are not testing whether you have a data catalog. They are testing whether your operational reality matches your submitted reality. The gap between these two is where enforcement lives.
A concrete example: a firm submits monthly fon bazında katılımcı sayısı figures. The number is 128.400. Regulator asks for the participant-level list that produces this count. The list, when generated fresh, contains 128.412. The twelve-account difference is not fraud. It is timing — the submission was generated at 23:47, twelve accounts changed status between then and midnight, and the pipeline does not preserve the exact state that was submitted. There is no snapshot. The firm cannot prove what it submitted was correct at the moment of submission because it cannot reproduce that moment.
This is a lineage failure. It is also an architectural failure. You cannot patch it with documentation.
Lineage as a First-Class Architectural Constraint
The firms that handle regulatory questions well have made specific structural choices, usually after being burned once:
- Immutable event logs as the source of truth. Participant balances are derived, never stored as ground truth. The event log is append-only. Any historical balance can be reconstructed by replaying events up to a point in time.
- Bi-temporal reference data. Every parameter table carries both a business effective date and a system-recorded date. A calculation done last year can be reproduced with the parameters that were in force at that time, as they were known at that time.
- Submission snapshots. Every file sent to EGM is accompanied by a persisted snapshot of the exact record set that produced it, keyed to the submission ID. This is not optional. It is the only way to answer "what did you actually submit" months later.
- Business rules externalized from transformation code. The logic for state contribution calculation, fund switching, and partial withdrawals lives in a rule engine or a well-versioned code artifact — not scattered across stored procedures, ETL steps, and reporting queries.
- Row-level lineage, not table-level. The pipeline records, for each derived value, which input rows and which rule version produced it. This is expensive. It is also the only thing that actually answers regulator questions.
The Cost of Discovering This Late
Every firm I have seen build lineage properly did so after a painful regulatory episode. The pattern is: a specific question arrives, the team spends six weeks trying to reconstruct the answer, the answer is delivered with caveats, the regulator is not fully satisfied, and management finally authorizes the architectural work that should have been done years earlier.
The cost of retrofitting lineage into a mature BES pipeline is roughly ten times the cost of building it in from the start. Not because the technology is expensive — event sourcing and bi-temporal modeling are well-understood — but because you are rewriting critical calculations while they are running in production, under regulatory supervision, with no permission to be wrong during the transition.
What to Do Before the Question Arrives
If you run a BES data pipeline and you have not personally traced a specific participant's balance back through every transformation to the originating contribution, do it this week. Pick one account. Reconstruct the balance. Time yourself. If it takes more than an hour, or if you have to ask three people, or if you end up saying "it should be approximately this," you have a lineage problem that will become a regulatory problem the moment someone asks.
The regulator approved your pipeline based on the outputs you showed them. They did not approve your inability to explain those outputs. That distinction is the entire game.