Every pension data engineer I know has the same scar. They built a pipeline that handled full surrenders cleanly — contributions in, state contribution added, returns calculated, stopaj applied, policy closed, file archived. Then someone processed a partial withdrawal and three months of EGM reconciliation reports went sideways.
The asymmetry is structural, not accidental. Understanding why takes you straight to the heart of what makes pension data different from almost every other financial domain.
Full Surrender: A Clean Cut
When a participant fully surrenders a BES policy, the calculation is brutal but bounded:
- Take all contributions ever made
- Apply the appropriate state contribution vesting percentage based on tenure (60%, 70%, 100%)
- Calculate accumulated returns on participant contributions
- Calculate accumulated returns on state contributions
- Apply stopaj rates against the return components (15%, 10%, or 5% depending on exit conditions)
- Pay out, close the policy, send the final notification to EGM
The policy is dead. Its history is frozen. Whatever you reported yesterday is what you reported. If you need to amend it, you do so with a clearly identified correction record against a closed entity. Auditors love this. Pipelines love this. The policy ID will never again appear in a daily delta file with new contribution activity.
Full surrenders are expensive in money and cheap in data.
Partial Withdrawal: A Wound That Keeps Bleeding
Now consider a partial surrender or a systematic withdrawal plan (SWP, or programlı geri ödeme in the BES context that mirrors it). The policy stays open. The participant takes out a portion. Tomorrow, contributions may resume. Next month, another partial withdrawal lands. Eighteen months later, someone requests a tenure-based recalculation.
Here is where every pipeline assumption breaks.
The contribution stack gets retroactively reshaped. Stopaj in Turkey is calculated against returns, not principal. To determine the return component of a partial withdrawal, you have to decide which contributions are being withdrawn. FIFO? LIFO? Pro-rata across the whole stack? Pro-rata is the regulated answer, which means every partial withdrawal mathematically touches every contribution record back to policy inception. Your "settled" contribution from 2017 is no longer settled — its remaining notional just changed.
State contribution vesting becomes path-dependent. A participant with seven years of tenure who takes a partial withdrawal doesn't just trigger a one-time vesting calculation. The remaining state contribution balance now has a different effective cost basis, and the next partial withdrawal will land against a balance that already had vesting math applied to part of it. Your pipeline now needs to carry forward not just balances but the vesting state of every contribution tranche.
EGM reporting becomes a moving target. You already reported the policy's contribution history. You already reported the state contribution accruals. A partial withdrawal forces you to re-emit corrections against records EGM considered closed for the period. If your downstream actuarial systems consumed those records and built reserves on top, those reserves are now wrong too.
What Actually Breaks in the Pipeline
In the systems I have seen, four specific failures show up repeatedly:
-
Idempotency assumptions collapse. Pipelines built on "process each contribution once, mark it settled" cannot handle a partial withdrawal that needs to revisit settled contributions. Teams end up writing parallel reversal-and-rebooking flows that double the code surface.
-
The reporting period boundary becomes meaningless. Monthly EGM submissions assume a closed window. Partial withdrawals processed in March that affect February's reported contribution stack force amendment files, and amendment files have their own failure modes that nobody tests.
-
Reconciliation drift compounds silently. The general ledger sees the cash leaving today. The policy administration system reshapes balances as of the withdrawal effective date. The data warehouse, fed by both, shows balances that match neither. Three months later, finance asks why the BES liability number moved by 0.4% and no one can trace it.
-
SWPs multiply the problem by N. A systematic withdrawal plan is not one event. It is a recurring scheduled partial withdrawal, each instance independently triggering pro-rata reshaping. If you built your partial-withdrawal logic as an exception path rather than a first-class flow, an SWP enrollment turns that exception path into the hot path.
What Works
The pattern I have seen succeed treats the contribution stack as an immutable event log with a separately materialized balance view, not as a mutable balance table.
- Every contribution, every withdrawal, every vesting event is an append-only record with an effective date and a recorded date
- Balances are derived, not stored — or stored only as cached projections clearly marked as derived
- Partial withdrawals emit allocation records that explicitly reference which contribution tranches they drew against, by what rule, at what time
- EGM amendment generation reads the event log between two dates rather than diffing two balance snapshots
This is more expensive on day one. It is dramatically cheaper the first time legal asks you to reconstruct exactly what a policy looked like on a specific date eighteen months ago, or the first time an SWP enrollment doesn't crash your reconciliation.
The Deeper Lesson
Finance teams talk about partial withdrawals as a product feature. Data teams should talk about them as a fundamental change in pipeline semantics. Full surrender is a transaction. Partial withdrawal is a retroactive restatement disguised as a transaction.
If your pension pipeline was designed by people who only thought about contributions in and full surrenders out, you do not have a pipeline. You have a prototype that has not yet met its first SWP enrollment.