Every pension company I've worked with has the same artifact tucked away in a SharePoint folder or a Confluence page nobody has touched since 2019: the original field mapping document. It was written when the BES reporting pipeline was first built, probably by a business analyst who sat with a developer for two weeks and translated the regulatory schema into internal column names. katki_payi_net maps to NetContribution. giris_aidati maps to EntryFee. Signed off, committed, forgotten.
Then five years pass. The product team launches three new plan types. Finance patches the ETL twice to fix a reconciliation issue with automatic enrollment contributions. Somebody changes the tax withholding logic because the regulation clarifying circular came out. A junior developer refactors the staging layer and renames two columns for readability.
None of it makes it back to the mapping document.
The definition rots faster than the code
Code has tests. Code has git blame. Code has a production system that screams when it breaks. Definitions have none of that. When SEDDK or EGM sends a data quality query — and they do, more often than most teams admit publicly — the question is rarely "why is this number wrong." It's "what exactly does this field represent in your submission."
And the honest answer is usually some variation of:
- "It's whatever comes out of the
fn_calculate_net_contributionfunction." - "Ahmet wrote that part, let me check if he still has the spec."
- "We think it excludes state contribution match, but we'd need to trace the SQL."
None of those are answers a regulator accepts. They want a definition, a source, and evidence that the definition has been consistently applied across the reporting period they're auditing.
Where the drift actually happens
In the BES pipelines I've reviewed, drift concentrates in a few predictable places:
Contribution fields. "Net contribution" started as gross contribution minus entry fee. Then the state contribution match was carved out. Then the treatment of automatic enrollment opt-out refunds got clarified. Each change was correct at the time. None updated the field description.
Fund allocation fields. When new fund types were added, the allocation percentage fields kept the same names but started including or excluding certain fund categories depending on the calculation context. The regulatory schema says "equity fund allocation." Your pipeline has three slightly different versions of that concept, one of which is used in the SEDDK submission and two others in internal reports.
Date fields. "Contribution date" is either the date the participant made the payment, the date the money hit the pension account, the date the units were allocated, or the value date used for tax reporting. All four exist. All four are correct in their contexts. Only one belongs in the regulatory submission, and nobody remembers which one the original mapping picked.
Status fields. Participant status codes get extended every time the product catalog grows. The regulator's enumeration is stable. Your internal enumeration is not. The mapping table that translates between them is either a hardcoded CASE statement buried in a view or an Excel file on somebody's desktop.
Why the standard fixes don't work
The usual response is "we need a data catalog" or "let's implement a governance tool." I've watched three of these initiatives run in Turkish financial institutions. Two got abandoned. One survives as a mostly-empty Collibra instance that nobody consults before making changes.
The reason is simple: tools that require humans to manually document fields after the fact will always lose to delivery pressure. The product team needs the new plan type live by end of quarter. Nobody is going to hold up the release because the data dictionary hasn't been updated.
The fix has to be structural, not procedural.
What actually holds up under regulatory scrutiny
A few patterns I've seen work in practice:
Definitions live in the same repo as the transformation code. If NetContribution is calculated in a dbt model or a stored procedure, the definition — in Turkish, in the exact language the regulator uses — sits in a YAML file or a comment block next to the code. Any change to the calculation requires a change to the definition in the same pull request. Reviewers reject PRs that change the logic without touching the definition.
The regulatory schema is version-controlled as a first-class artifact. SEDDK and EGM publish schema updates. Those updates go into a repo, get diffed, and the diff triggers a review of every field that maps to a changed regulatory field. This is boring work. It's also the only way to catch the moment when a regulatory clarification silently invalidates your existing mapping.
Submission snapshots include the definition, not just the data. Every monthly or quarterly submission is archived with the field definitions that were in effect at the time. When the regulator asks about a submission from eighteen months ago, you produce the data and the definition dictionary that was live when the submission was generated. This is the artifact regulators actually accept as evidence.
Reconciliation runs against the definition, not just the value. If "net contribution" is defined as gross minus entry fee minus state match, there's a test that decomposes the submitted value and verifies the components sum correctly. When someone changes the calculation without updating the definition, the test fails. The pipeline doesn't ship.
The uncomfortable part
Most of this work is unglamorous. It doesn't ship features. It doesn't move any dashboard. The business case for it becomes obvious exactly once — the first time a regulator sends a formal data quality inquiry and you have to reconstruct what a field meant three years ago from git history and Slack messages.
By that point, you're not fixing a data problem. You're managing a regulatory relationship, and the answer you give shapes how much scrutiny you get for the next five years.
The teams that handle this well decided, at some earlier point, that the definition is part of the product. The teams that don't are the ones I get called into after the inquiry arrives.