Most engineers learn data correction the same way: find the bad row, write the UPDATE, log it, move on. In an e-commerce order table, a CRM contact list, even most banking ledgers outside the core, that is acceptable practice. The audit trail captures what happened, the corrected value flows downstream, and the business continues.
That reflex will destroy you in individual pension.
A participant record in a Turkish BES (Bireysel Emeklilik Sistemi) fund is not a row. It is a legal instrument. The participant's identity fields, contribution schedule, fund allocation choices, entry date, and contract status are all inputs into calculations that the state, the regulator (EGM), and the participant themselves have legal claims against. A correction does not erase the prior state — it creates a new event that must coexist with the original, sourced and timestamped, because the original already produced legal effects downstream.
What a Correction Actually Triggers
Consider a routine case: a participant's entry date is recorded as 15 March instead of 5 March. Ten days. In a CRM, this is noise. In BES, this single correction can cascade into:
- Retroactive state contribution recalculation. The 25% state subsidy (devlet katkısı) is calculated on contributions made within specific windows. Shifting the entry date can change which contributions qualify and at what rate, going back to the contract origin.
- Vesting clock adjustment. State contribution vesting follows a tiered schedule based on years in the system. A ten-day shift can move a participant across a vesting boundary that materialized three years ago.
- EGM reconciliation delta. EGM receives daily participant files. Your corrected record now disagrees with every prior EGM snapshot. That delta has to be explained, not silently absorbed.
- Fund unit recalculation. If contribution dates shift, the unit prices at which contributions were converted shift too. You are now recalculating unit balances retroactively, which means the participant's current balance is wrong until reprocessing completes.
- Tax reporting implications. Withdrawal taxation depends on time in the system. Correcting entry date changes the tax bracket applied to any past partial withdrawals.
One field. Ten days. Months of downstream work if handled wrong.
Why Overwriting Is the Wrong Model
The instinct to UPDATE the field and rerun the pipeline assumes the prior state was never real. In pension, the prior state was extremely real. The state paid subsidies based on it. EGM acknowledged it. The participant may have received statements citing it. Tax may have been calculated on it.
If you overwrite, you have created a system that cannot answer a regulator's question: what did you believe on 12 June 2022, and on what basis did you pay this subsidy? The answer "we believed what we believe now" is not acceptable. It is also not true.
The correct model is bitemporal at minimum:
- Valid time: when the fact was true in the real world (the participant actually entered on 5 March).
- System time: when your system came to believe it (the correction was applied on 18 November).
Every downstream calculation must be reproducible against the state of belief at the time the calculation was originally performed. Your subsidy payment in April was correct given what you knew. Your correction in November is a new event that triggers a new calculation, and the difference between the two is a reconciling item — not a silent rewrite.
The Correction as a Sourced Event
In the systems I have built and maintained, every correction carries:
- A source document reference. Who told us the entry date was wrong? The participant via signed form? A branch keying error caught in audit? A reconciliation break with the contracting employer? Each source has different legal weight and different downstream notification obligations.
- An authorization trail. Corrections to legally binding fields cannot be made by a developer running a script. They require operational authorization, often dual control, and in some cases regulator-facing justification.
- An effective date and a knowledge date. These are not the same. A correction effective from contract origin, known as of today, produces different downstream files than a correction effective from today forward.
- A downstream impact manifest. Before the correction is committed, the system must enumerate what recalculations it triggers: subsidy deltas, EGM file regenerations, statement reissues, tax adjustments. If the impact cannot be enumerated, the correction is not ready to commit.
What This Means for Pipeline Design
Engineers coming from generic data backgrounds want to model the participant as a slowly changing dimension and call it done. SCD Type 2 captures history but does not capture intent. It tells you the row changed; it does not tell you why, on whose authority, against what evidence, with what legal effect.
The participant record in BES needs an event-sourced spine. The current state is a projection. The truth is the sequence of events — contract origination, contribution received, allocation changed, contact updated, entry date corrected, beneficiary added — each immutable, each sourced, each replayable. When EGM asks why the April 2022 subsidy was 847 lira and not 851, you replay April 2022 against the event log as it existed in April 2022. That number reproduces exactly. The November correction is a separate event with its own subsidy delta, paid or clawed back as its own transaction.
This is more expensive to build. It is also the only model that survives a regulator visit, an audit, or a participant lawsuit.
The Practical Test
If you want to know whether your pension data platform is built correctly, ask one question: can you produce the participant's full record as it was believed to be on any past date, and reproduce every subsidy, fund unit calculation, and EGM file that was generated from it?
If the answer requires backup restores, manual reconstruction, or "we can probably get close," the platform was built by someone who thought corrections were fixes. They are not. They are events. And in pension, events do not get to be silent.