I have sat through enough regulatory inquiries to know the pattern. The examiner opens the file, glances at the submitted value, and asks something that sounds procedural but isn't: "Bu rakam nereden geliyor?" Where does this number come from.
The teams I've watched fail at this moment are rarely the ones with wrong numbers. They are the ones who cannot walk the regulator from the policy administration system, through the staging layer, through the transformations, through the reconciliation, to the value on the form. Not in a diagram. Line by line, with timestamps and owners.
The Assumption That Kills You
Most BES and insurance data teams treat regulatory reporting as an output problem. Build the pipeline, hit the deadline, tick the box. The internal KPI is submission accuracy — did the number match what finance closed?
That framing is structurally wrong. Accuracy is table stakes. What EGM and SEDDK are actually testing during an inquiry is whether your organization has evidentiary control over the number. Two different questions:
- Accuracy: Is the value correct?
- Evidentiary control: Can you prove, with artifacts, exactly how the value was produced, who approved each step, and what would have happened if any input had been different?
The first question is answered by a query. The second is answered by architecture, and you cannot retrofit it during an inquiry.
What the Chain of Custody Actually Means
In a BES context, a single contribution figure submitted to EGM might traverse:
- The pension administration system (contract-level records)
- A collections reconciliation against bank files
- A daily NAV calculation from the portfolio management system
- An accrual adjustment in the general ledger
- A reclassification for regulatory taxonomy
- A manual override for a known correction from the prior period
Each hop is a place where the number changes shape. The regulator's inquiry will ask about one of these hops — usually the one you handled with a spreadsheet and an email approval. If your answer is "the operations team sent us the adjusted file," you have already lost credibility.
The Follow-Up Questions Firms Fail
In practice, the questions that expose weak pipelines are the same handful:
- Show me the source record for this aggregate as of the submission date.
- Who approved the reclassification, and what was the business rule reference?
- If the underlying policy was cancelled after submission, how would that flow to the next period?
- Why does the same field reconcile to a different value in the actuarial report submitted last month?
- Provide the version of the transformation logic that ran on the submission date, not the current version.
That last one is where I have seen otherwise competent teams collapse. They deploy dbt or SQL logic continuously, they don't version their transformations against a submission timestamp, and when the regulator asks what code produced the number, they physically cannot reproduce it.
What Structural Preparation Looks Like
The firms that survive inquiries without drama share four practices:
Immutable submission snapshots. Every regulatory submission produces a frozen artifact: source extracts, transformation code version, intermediate tables, final values, and the approval trail. Stored, hashed, retrievable by submission ID. Not "we can rebuild it" — actually stored.
Lineage that a non-technical examiner can follow. Automated column-level lineage is useful internally but useless in a meeting. You need a human-readable chain-of-custody document per report line, generated automatically but written in the language of the business rule, not the SQL.
Manual interventions treated as first-class events. Every override, adjustment, and manual correction logged with a ticket, an approver, a reason code, and a linked business rule. If someone edits a value in Excel before it enters the pipeline, that is a control gap, not an operational reality to be tolerated.
Reconciliation as a product, not a checklist. The reconciliation between the source system, the warehouse, and the submitted value should be a permanent artifact with variance thresholds, exception logs, and sign-off. Not something the team runs the night before submission and throws away.
The Cultural Problem Underneath
Most of this is not a technology problem. The tools to do it well have existed for a decade. The problem is that data teams in Turkish insurance and pension firms are measured on delivery, not on defensibility. Nobody gets promoted for producing an audit-ready pipeline. They get promoted for hitting the deadline with the right number.
Until the internal incentive structure rewards evidentiary control at the same weight as accuracy, the next inquiry will look like the last one: a scramble to reconstruct what should have been continuously documented, and a slow erosion of the regulator's trust that the firm knows what it is doing.
The number was never the point. The regulator assumes you can produce a number. What they want to know is whether you understand your own machinery well enough to be trusted with the next one.