Most pension systems are designed around a single mental model: a participant contributes for years, then retires, then withdraws. Death is treated as an edge case — a variant of termination. In BES (Bireysel Emeklilik Sistemi), that assumption is where the trouble starts.
A death certificate is not a termination event. It is the trigger for a multi-party legal reconstruction that runs concurrently across at least four independent timelines, each with its own authority, its own deadline, and its own idea of what the account balance actually is on any given day. The pipeline that smoothly processed twenty years of monthly contributions is often the one that produces a silent data corruption the week after the notary sends the veraset ilamı.
What Actually Happens When a Death Notification Arrives
From the outside, it looks like a status change: active → deceased. From the inside, four processes start moving at different speeds:
- Beneficiary reconciliation. If the participant filed a beneficiary designation, it must be validated against the veraset ilamı. If they did not, statutory inheritance shares apply and the pension company has to compute them — often across heirs who don't know the account exists yet.
- State contribution (devlet katkısı) clawback evaluation. The 25% state contribution has vesting rules tied to time in system and exit reason. Death is a favorable exit — full vesting is generally preserved — but the calculation still has to be re-run against the death date, not the notification date, and the difference can be months.
- EGM (Emeklilik Gözetim Merkezi) reporting window. EGM expects the death event reported within a defined window, and expects the fund unit valuation to be frozen at a specific reference date. Miss the reference date and every downstream number is wrong.
- Probate timeline (mirasçılık belgesi). This runs on court time, not IT time. It can take weeks or months. During that entire period, the account is neither closable nor fully active.
These four timelines do not align. That is the entire problem.
The Reference Date Trap
Ask a pension pipeline architect what date the account balance should be frozen at, and you will get one of four answers depending on who they last talked to:
- Date of death (from the certificate)
- Date the death was notified to the company
- Date the veraset ilamı was presented
- Date of the actual payout to heirs
All four are wrong for at least one purpose. State contribution vesting typically references date of death. Fund unit valuation for beneficiary payout often references notification date or a T+n rule. EGM reporting has its own reference. And the accounting entry that hits the general ledger uses payout date.
A well-designed pipeline stores all four and knows which one to serve to which consumer. A typical pipeline stores one — usually notification date, because that's when the operator clicked the button — and lets every downstream report silently disagree with every other one.
I have seen an audit where the state contribution report, the beneficiary statement, and the EGM submission for the same deceased participant showed three different account balances. All three were internally correct. The pipeline had no concept that they should be different.
The Beneficiary Data Nobody Maintained
Beneficiary designations are captured at contract signing and then, in most portfolios, never touched again. Twenty years later:
- The named beneficiary is a spouse from a marriage that ended in 2011.
- The named beneficiary is deceased before the participant.
- The designation names a minor child who is now 34 and living in Germany.
- The designation is legally ambiguous because it predates a regulatory clarification on share allocation.
When the participant is alive, none of this matters. The field sits in a table, unread. The moment the death certificate arrives, that field becomes the most legally consequential piece of data in the entire account — and the company discovers it has never been validated, never been refreshed, and in many cases never been parsed into structured form. It's a free-text field in a column called LEHDAR_ACIKLAMA.
The operational cost of this is not the payout dispute. It is the six weeks of manual legal review per case, at scale, when a portfolio starts producing meaningful mortality volume.
What Breaks in the Pipeline
Concrete failure modes I've watched happen or clean up after:
- Contribution posting after death. Employer group BES contributions continue to arrive via the standing collection file for one, two, sometimes three months after the death. The pipeline accepts them because the account status change hasn't propagated to the collection module. Now you have contributions dated after date of death that must be reversed, refunded to the employer, and excluded from the state contribution calculation — but they are already in the unit accounting.
- Fund switch orders executed post-mortem. Automated rebalancing or a pending fund switch order executes against a deceased account because the switch engine reads a cached status flag refreshed nightly.
- Statement generation. The annual statement job runs and mails a statement addressed to the deceased participant to the registered address, where a grieving family opens it. This is not a data problem in the technical sense. It is a data problem in every sense that matters.
- State contribution reversal on the wrong side. The clawback logic, written for early withdrawal, fires on the death event because the exit reason code was mapped incorrectly. The heirs receive the account minus 25% they were legally entitled to.
Every one of these is a pipeline that works correctly for the 99.7% of the portfolio that is alive.
What the Architecture Actually Needs
This is not solved by adding a deceased flag. It is solved by treating the death event as opening a distinct account state — call it in_succession — with its own rules:
- All write operations except reversals and beneficiary settlement are blocked at the domain layer, not the UI layer.
- Multiple reference dates are stored explicitly and served to consumers by purpose, not by default.
- Incoming contributions during the succession state are quarantined, not posted, pending reversal instruction.
- The beneficiary field is re-validated on entry into the state, not assumed correct from twenty years ago.
- EGM reporting, state contribution recalculation, and beneficiary payout run as three separate workflows with three separate SLAs, not as a single "close the account" batch job.
Most importantly: the state should not be exitable by a single operator action. Exiting in_succession requires evidence artifacts — veraset ilamı, beneficiary acceptance, state contribution reconciliation sign-off — attached to the account before the status can move to settled.
The Uncomfortable Part
BES portfolios in Turkey are aging into their first significant mortality cohort. The systems built in 2003–2008 were architected for accumulation. They have never been stress-tested against sustained death volume, only against isolated cases handled by hand.
The operations team knows this. They handle it with spreadsheets, email threads, and institutional memory held by three people who have been there fifteen years. That works until it doesn't — until one of those people leaves, or until case volume crosses the threshold where manual reconciliation stops being feasible.
The death certificate is the most legally fragile moment in a BES account's lifecycle. It deserves to be the most carefully engineered part of the pipeline. In most companies, it is the least.