A regulator sends a letter. It references a specific line in a specific submission from Q3 of the previous year. The question is narrow, almost surgical: why does this figure differ from the aggregate reported in another return, or how was this exposure classified given a rule that was clarified six months later.
The answer, on paper, is usually a paragraph. Sometimes a single sentence. The work behind that paragraph is where firms discover what they actually built.
The Output Was Never the Hard Part
Most regulatory pipelines in Turkish banks and insurance companies were engineered for one thing: producing the submission on time, in the correct format, passing the validation rules of the receiving system. That is a real engineering achievement and I do not want to minimize it. XBRL taxonomies change, EGM sigorta bilgi formatları evolve, BDDK adds new fields, and the pipeline keeps delivering.
But ask the same pipeline to answer a question about itself eighteen months later and it goes silent.
- The source tables have been updated thousands of times since the submission.
- The reference data — customer segmentation, product classification, risk weights — has been revised, sometimes silently.
- The business rules encoded in stored procedures or Informatica mappings have been changed to fix bugs or accommodate new regulations.
- The pipeline code itself has moved forward three or four releases.
- The person who wrote the original logic has moved to another team or another company.
None of these changes were wrong. They were correct responses to a moving environment. The problem is that the environment moved without leaving footprints.
What a Regulator Inquiry Actually Requires
When EGM or BDDK asks a targeted question, answering it defensibly requires four things reconstructed to a specific point in time:
- The exact input data that fed the submission — not today's version of those tables, not a backup that is close enough, but the rows and values that existed on the extraction date.
- The pipeline version that transformed that data — including which stored procedures, which mapping versions, which lookup tables.
- The business rules and parameters active at that moment — thresholds, classification hierarchies, exclusion lists, currency conversion sources.
- The manual interventions that occurred — the override on record 47,382 that the operations team applied because a customer's TCKN had a legacy formatting issue.
Most firms can produce one of these four with confidence. Some can produce two. Very few can produce all four for a submission made a year ago.
The Concrete Example
A life insurance company receives a question about the reserve calculation for a specific product cohort in a submission from fifteen months earlier. The regulator wants to understand why the reserve moved by a particular amount between two consecutive quarters.
The answer is knowable. The actuarial team reruns the calculation and produces a number. But the number does not match the submitted figure by a small amount — perhaps 0.3 percent. Now the real work begins:
- Was the mortality table updated between then and now? Yes, in month eight.
- Was the discount curve source changed? Yes, the vendor feed was migrated in month eleven.
- Was the policy status snapshot logic modified? A defect was fixed in month six that had been silently misclassifying paid-up policies.
- Did the extraction cutoff time shift? The batch window was moved by ninety minutes to accommodate a different upstream system.
Each of these is defensible on its own. Together, they mean the company cannot reproduce its own reported figure without an archaeological expedition through Git history, DBA change logs, and email threads.
The answer to the regulator will be written. It will be correct. But it will take three weeks of senior analyst time to justify a figure that was generated automatically in twenty minutes.
What Should Have Been Preserved
The fix is not more storage. Firms already store terabytes. The fix is preserving the right things with the submission itself:
- Immutable snapshots of input data at extraction time, keyed to the submission ID, retained for the full regulatory retention period.
- Versioned business rules and reference data, with the version identifier stamped onto every submission artifact.
- Pipeline code hashes recorded alongside outputs, so the exact transformation logic can be retrieved without depending on Git branches that may have been rewritten.
- A manual intervention log that records every override, its justification, its author, and its timestamp, linked to the affected records.
- A reconciliation trail that shows, for each reported figure, the aggregation path from source rows to submitted value.
None of this is technically difficult. It is architecturally unfashionable because it adds cost and complexity to a pipeline whose visible job is to produce an output. The invisible job — proving the output later — is what most designs neglect.
The Contrarian Point
Data teams tend to measure themselves on delivery. Submissions filed, deadlines met, validation errors resolved. These are the wrong metrics if you also care about defensibility. A pipeline that produces the correct submission but cannot reconstruct its own reasoning is a liability disguised as an asset.
The firms that handle regulator inquiries best are not the ones with the fastest pipelines. They are the ones that treated every submission as a legal artifact from the moment it was produced, and built preservation into the pipeline rather than bolting audit onto the outside.
The question from EGM or BDDK is never really about the answer. It is about whether you can still see what you saw on the day you answered the first time. Most firms cannot. That is the problem worth solving before the next letter arrives.