Every BES data warehouse I've reviewed in the last decade has the same blind spot. The pipelines assume continuity. Tables get updated in place, corrections overwrite prior states, reconciliation logs live in the same database as the operational data they reconcile, and the assumption is that if a regulator or auditor asks a question next Tuesday, someone from operations will be there to log in and explain what happened.
That assumption breaks the moment insolvency enters the picture.
When a pension company fails and Güvence Hesabı steps in for BES participant protection, the guarantee fund doesn't ask the failed company to explain its data. It takes the data. And it takes it under legal conditions where accuracy is not a best-effort metric — it's the basis on which participants get paid or don't.
What Güvence Hesabı Actually Needs
The obligation isn't "send us a database dump." The obligation is to hand over a point-in-time reconstruction of every participant's position that is:
- Legally defensible — every katılımcı balance must be traceable to specific contribution events, fund unit allocations, state contribution (devlet katkısı) accruals, and deductions, with timestamps that hold up in court
- Reconstructable without the source systems — because during liquidation, those systems may be frozen, partially available, or under the control of a court-appointed trustee
- Consistent across every reporting artifact — the number given to Güvence Hesabı must match what was reported to EGM, what appeared on the participant's last statement, and what sits in the fund custodian's records
- Reproducible on demand — six months after the transfer, if a participant disputes their payout, you need to prove exactly what the state of their account was on the trigger date
Most pipelines cannot do any of this cleanly.
Where Existing BES Architectures Fail
Here is what I typically find in production:
Overwrite-based correction logic. When a contribution is misallocated and later corrected, the correction updates the row. The prior incorrect state is gone, or it lives in a change-log table that was never designed to be a legal record. Try explaining to a guarantee fund auditor why the balance on 15 March differs between the participant statement mailed on 20 March and the reconstruction produced from the warehouse today.
Fund unit price snapshots that aren't really snapshots. Daily NAV is stored, but the allocation logic that translates a contribution into units purchased depends on business rules that live in application code, not in the data. When the code changes — a rounding rule, a cutoff time, a fee treatment — the historical reconstruction silently drifts.
Devlet katkısı state stored as current status only. Vesting schedules, hak ediş oranları, previous exit deductions — these are often computed on read, not stored as immutable events. If the computation logic is unavailable at the moment Güvence Hesabı needs the data, the numbers cannot be regenerated.
Reconciliation logs coupled to operational systems. The reconciliation between the pension company's records and the portföy yönetim şirketi lives in the same SQL Server that just got seized. Nobody thought to replicate it somewhere the guarantee fund could reach.
What The Architecture Actually Needs
This is where BES data engineering diverges from ordinary financial reporting. You are not building for the happy path where you get to answer questions later. You are building for the case where you are gone and the data has to speak for itself.
Event-sourced participant ledgers. Every contribution, allocation, fee deduction, transfer, devlet katkısı accrual, and exit must be an immutable event with a business timestamp and a system timestamp. Balances are derived, never stored as truth. This is not a preference — it's the only way to reconstruct a position at an arbitrary past date after the systems are dark.
Business rules versioned as data. The fee schedule, the vesting curve, the state contribution calculation, the cutoff rules — all of it needs to be stored in tables with effective-from and effective-to dates, not in code. If the code is gone, the rules must still be executable against the event stream.
Independent, regulator-reachable archives. Daily immutable exports of the participant ledger, business rule tables, NAV history, and reconciliation status to storage the guarantee fund can access without going through the failed company's infrastructure. WORM storage, external custodian, or a regulator-mandated location — depends on the current EGM guidance, but the principle is that the archive survives the company.
Reconciliation as a first-class artifact. The daily three-way reconciliation between pension company records, portföy yönetim şirketi records, and takasbank/custodian records is not an internal control document. It's evidence. It needs to be exported, signed, and stored with the same rigor as the ledger itself.
The Test Nobody Runs
Here is the exercise I recommend to every BES data lead: assume your operational systems are unavailable starting tomorrow morning. You have only what has been exported to external archives as of tonight. Can you produce, for any given participant, their exact position as of any date in the last ten years, with full traceability to the underlying events and business rules?
If the answer involves "we'd need to log into" or "someone from IT would have to," the architecture has failed the insolvency test.
The uncomfortable truth is that most BES pipelines were designed by people optimizing for daily operations and monthly regulatory reports. Insolvency reporting is a different problem. It has different consistency requirements, different availability requirements, and a different definition of "correct."
Practical Starting Points
If you're responsible for a BES data platform and this post is making you uncomfortable, start here:
- Inventory every calculation that produces a participant-facing number and determine whether it can be re-executed against historical events without the current application stack
- Identify every table that gets updated in place and design an event-sourced replacement, even if migration takes two years
- Establish a daily external export of the participant ledger to storage outside your primary infrastructure, and test the restore quarterly with someone who has never seen the system
- Version your business rules as data, with the same change control you apply to financial models
- Treat the reconciliation output as a regulatory artifact, not an operational log
Güvence Hesabı protection exists because participants deserve certainty even when their pension company doesn't survive. The data architecture behind that protection deserves the same seriousness. Right now, in most shops, it doesn't have it.