Every few years the regulator publishes a fresh set of stress scenarios for BES and life insurance portfolios. Actuaries model them, risk committees review the output, a PDF gets signed, and everyone moves on. The scenarios themselves are reasonable — sharp equity drawdowns, currency shocks, mass surrender assumptions, interest rate dislocations. What nobody tests is whether the data pipeline underneath the actuarial engine can survive the same conditions on the day they occur.
This is not a theoretical gap. I have watched pipelines built for BES reporting over the last decade, and almost all of them share the same original sin: they were designed against a steady-state assumption that a real stress event immediately breaks.
What the stress test actually tests
The regulatory exercise validates the model. It answers: given these market moves and these behavioral assumptions, does the fund remain solvent, does the company maintain capital adequacy, are participant obligations coverable?
What it does not answer:
- Can the NAV calculation pipeline close end-of-day when three custodians are sending revised prices at 23:00 instead of 18:00?
- Can the participant record system handle a 40x spike in withdrawal requests without deadlocking against the daily allocation job?
- Can the regulatory submission pipeline generate the E-Devlet and EGM files on time when the underlying tables are being rewritten by emergency corrections?
- Can reconciliation between the fund accounting system and the custodian tolerate a T+1 that has become T+3 because settlement queues backed up?
The actuarial model assumes clean inputs at the reporting boundary. The pipeline assumes normal-day volumes, normal-day timing, and normal-day data quality. A stress event violates both, simultaneously.
The assumptions that get baked in at inception
When a BES pipeline is built, the architect makes decisions that never get revisited. A few I have seen repeatedly in Turkish operations:
Batch windows sized for the median day. The overnight allocation job finishes at 04:30 on a typical day. On a day where fund switches spike 20x — which is exactly what a fund collapse produces — that job runs until 11:00 and blocks the morning NAV publication. The regulator does not care why the NAV is late.
Single-threaded price ingestion. Prices come from a handful of sources in a fixed sequence. When one source is delayed because their own systems are under stress, the entire chain waits. Nobody built a fallback because in ten years of operation, the primary never failed for more than an hour.
Withdrawal workflows assuming manual review capacity. Compliance and operations teams are sized for baseline volume. Mass surrender scenarios in the actuarial model assume the money goes out; the pipeline assumes a human approves each unusual request. Those two assumptions cannot both be true.
Reconciliation tolerances calibrated to quiet markets. A 5 bps tolerance on custodian vs. book NAV is fine when daily moves are 30 bps. When the underlying moves 8%, that same 5 bps tolerance triggers thousands of breaks, and the ops team spends the day chasing noise instead of catching the one real error.
Submission files generated from live tables. The EGM submission is often built by querying production at a specific cutoff. If corrections are still flowing in — and during stress they always are — the file either misses them or captures a partially-corrected state. Neither is defensible.
Why nobody has caught this
Three reasons.
First, the regulator asks for actuarial stress results, not operational stress results. There is no line in the submission that says "and here is proof your pipeline can produce this output under the scenario conditions." So it never gets built.
Second, IT and actuarial live in separate governance structures. The actuary trusts the number they receive. The pipeline team trusts the requirements they were given. Neither owns the joint failure mode.
Third, the last real stress event in Turkish pensions that exercised all these systems simultaneously was long enough ago that most of the current pipelines did not exist yet. The 2018 currency episode was painful but did not trigger mass BES withdrawal. Nobody has seen the full combination live.
What a real pipeline stress test looks like
If I were designing one — and this is what I actually recommend to clients — it has four components:
-
Replay historical worst days at 10x volume. Take the worst operational day of the last five years, multiply transaction volume by ten, and run it through a copy of the current pipeline. Measure wall-clock time to NAV, to reconciliation close, to submission file generation.
-
Inject delayed and corrupted inputs. Custodian file arrives 6 hours late. Price file has 3% of instruments missing. Participant system returns duplicates for 0.5% of records. Does the pipeline degrade gracefully or does it stop?
-
Simulate concurrent regulatory deadline and operational crisis. The EGM submission is due at 10:00. At 08:00, a fund correction requires reprocessing three days of allocations. What does the pipeline produce at 10:00?
-
Test the human interfaces under load. Ops dashboards, exception queues, approval workflows. A pipeline that technically survives but produces 40,000 exceptions no human can triage has failed.
The uncomfortable conclusion
Most BES pipelines in the Turkish market would fail a properly designed operational stress test. Not because the engineers were incompetent, but because the requirements never included the scenarios that matter. The actuarial stress test gives false comfort: the model is fine, therefore the system is fine. The model is fine. The system, on the day it matters, will not be.
The fix is not a bigger data platform or a cloud migration. It is a specific, unglamorous exercise: take the same scenarios the actuaries model, and run them against the pipeline instead of the balance sheet. The results are informative, and rarely flattering.