A regulator sends a letter about a BES submission from Q3 of last year. Specifically, they want to understand why a particular exposure was classified the way it was. Your team pulls the archived output — the number matches what was filed. Good. Then they ask the harder question: show us the rule your pipeline was applying that day.
This is where most firms discover they have a problem they didn't know they had.
The Gap Between Code Versioning and Rule Versioning
Every serious finance or insurance IT organization has Git. Every pipeline lives in a repository, every commit is traceable, every deployment is tagged. That part is solved.
What is almost never solved: the interpretation layer between the regulation and the code. Consider a BDDK reporting pipeline that classifies a loan as restructured. The classification depends on:
- A threshold value someone decided on in a meeting
- A CASE statement that encodes a specific reading of a circular
- A mapping table maintained by the reporting team in Excel
- A patch applied three months ago because internal audit flagged an edge case
- A silent correction someone made when a colleague pointed out the SQL was double-counting collateral
Git tracks the code change. It does not tell you why the threshold was 90 days instead of 91, which version of the circular the team was reading, or what the reporting officer's interpretation was on the day the filing went out.
Why the Output Alone Is Not a Defense
Regulators in Turkey — BDDK, SPK, SEDDK — increasingly ask reconstruction questions rather than accepting the archived filing as evidence. "Show us your logic" is not the same as "show us your output." I have seen firms present a beautifully archived XBRL package, only to fail when asked to demonstrate that the classification engine at time T applied rule interpretation X.
The failure mode is predictable:
- Pipeline runs, produces output, output is archived.
- Bug is discovered two weeks later. Fix is deployed. No one flags this as a regulatory-logic change because "it was just a bug."
- Six months later, another edge case surfaces. Someone rewrites the classification module for clarity. Behavior is equivalent for current data but subtly different for historical data.
- Fourteen months later, regulator asks about a specific record. You run the current pipeline against the archived input. The output is different. Now you have to explain why — and you cannot, because no one wrote down which interpretation applied when.
What Firms Actually Have
In most banks and insurers I have worked with, the reality is:
- Source control for code: yes, mature, disciplined.
- Version control for reference data (mapping tables, thresholds, product hierarchies): usually a shared drive, occasionally a database with no history, rarely a proper SCD Type 2.
- Version control for rule interpretation (the why behind a CASE statement): almost never exists as a first-class artifact.
- Linking a filing to a specific bundle of code + reference data + interpretation: essentially nonexistent.
That last point is where findings are born. When the regulator asks, you cannot say "this filing was produced by pipeline version 4.2.1, using mapping table snapshot dated 2023-08-14, applying interpretation memo INT-2023-07 regarding the treatment of restructured SME loans." You can only say "here is the code that runs today."
What a Real Reconstruction Package Looks Like
A defensible submission should be reproducible from a single manifest that captures:
- The exact Git SHA of the pipeline code that produced the filing
- Snapshots of every reference table used, with the row-level state at run time
- The parameter values (thresholds, dates, cutoffs) resolved at execution
- A link to the interpretation document justifying any non-obvious rule encoding
- The input data hash, so you can prove you ran against the same records
- The output hash, so you can prove the archived XBRL was not tampered with
Most of this is achievable with existing tooling. What is missing in most shops is the interpretation document linkage — treating the regulatory reading itself as a versioned artifact, reviewed by compliance, and referenced from the pipeline metadata.
Concrete Steps That Work
From implementations I have seen work:
- Freeze reference data with SCD Type 2 semantics. Every mapping change gets an effective-from and effective-to. Pipeline queries the state as-of the reporting date, not "current."
- Store interpretation memos in the same repo as the code. Every non-trivial CASE, every threshold, every classification tree has a comment referencing an interpretation document ID. The document is versioned. Compliance signs off on changes.
- Generate a run manifest for every submission. JSON file, archived with the output, containing every hash and version pointer needed to reconstruct.
- Ban silent corrections. A "bug fix" that changes classification behavior is a rule change. It goes through the same review as any other regulatory logic change. If the fix would have changed prior filings, that is a disclosure question, not an engineering question.
- Test reconstruction quarterly. Pick a random past filing. Reconstruct it from the manifest. If you cannot, you have found the gap before the regulator does.
The Uncomfortable Part
Most firms will not do this until forced. The reason is organizational: reference data is maintained by reporting teams, code is maintained by IT, interpretations are maintained by compliance, and no one owns the intersection. The manifest requires all three groups to agree that their outputs are linked artifacts, not independent workstreams.
Until that ownership question is settled, the version control problem is not a technical problem. It is a governance problem wearing a technical costume. And every quarter that passes without fixing it, another fourteen-month clock starts ticking on filings you will not be able to reconstruct.