Anyone who has built a BES data pipeline in Türkiye knows the setup: SEDDK issues the regulation, EGM enforces the submission. On paper this is a clean separation of concerns. In practice, it is the single biggest source of silent data-quality failures I have seen in this industry.
The assumption most teams start with is that if you comply with the SEDDK genelge, EGM will accept your file. That assumption is wrong, and the cost of discovering it is measured in rejected batches, manual corrections, and reconciliation reports that nobody wants to sign.
Where the Two Frameworks Drift Apart
SEDDK publishes the rules — field definitions, calculation methodologies, contribution thresholds, state contribution eligibility criteria, transfer procedures. EGM implements the validation layer that actually accepts or rejects your XML submissions. Between those two layers sit three recurring gaps:
- Effective date mismatches. A SEDDK genelge takes effect on a stated date. EGM's validator may enforce the new rule days, weeks, or occasionally months later. During that window, files that are technically compliant with the new regulation get rejected, and files following the old rule pass through.
- Interpretation divergence. SEDDK writes prose. EGM writes schemas. When the prose is ambiguous — and it often is around edge cases like partial-year state contribution calculations or mid-period plan changes — EGM picks one interpretation and encodes it. That interpretation is not always the one your legal team read.
- Undocumented tolerances. EGM's validator has quiet tolerances that are not written anywhere: rounding behaviors on kesinti calculations, acceptable delta thresholds on aggregate reconciliation, field-length quirks that differ from the published spec.
A Concrete Example
A few years back, a change in state contribution (devlet katkısı) eligibility rules came through. The SEDDK circular was clear about the new calculation. We updated the pipeline, ran regression tests against our own logic, everything matched.
EGM rejected the batch. The reason: their validator was still applying the previous month's eligibility window to a specific participant segment — likely a phased rollout on their side. We had two choices: roll back our logic and be non-compliant with SEDDK, or hold the batch and miss the submission deadline.
We ended up with a third option, which is the one that eventually became architecture: submit under the interpretation EGM enforces today, log the divergence, and carry the SEDDK-correct value in a shadow field for later reconciliation.
Treating Regulatory Authority as a Versioned Input
After enough of these incidents, the only architecture that stops bleeding is one that stops treating "the regulation" as a single source. You have to model two authorities, each with their own effective timeline:
seddk_rule_version— what the regulation says, effective from date Xegm_validator_version— what the validator actually enforces, effective from date Y (usually observed empirically, not documented)
Every calculated field in the pipeline gets tagged with both. When they diverge, the pipeline produces two values: the submission value (EGM-accepted) and the compliance value (SEDDK-correct). Reconciliation happens against the compliance value. Submission happens with the accepted value.
This sounds like overengineering until the first audit where SEDDK asks why your submitted numbers do not match the current regulation, and you can show a timestamped record proving the validator was rejecting the correct value on that date.
What This Looks Like in Practice
A few architectural rules that have earned their keep:
- Never hardcode a regulatory date. Every threshold, every rate, every eligibility window lives in a table keyed by effective date and authority. Two authorities, two columns.
- Log every validator rejection with the exact payload. Not the summary — the payload. Six months later, when EGM claims a rule was always enforced that way, you need the receipts.
- Build a divergence dashboard. For every submission cycle, show how many records were computed one way for EGM and another way for SEDDK compliance reporting. The number should trend to zero over time. When it spikes, something changed upstream and nobody told you.
- Version your XSD assumptions. EGM's schemas evolve. Keep old ones. Reproducing a two-year-old submission for an audit is not optional, and the current schema will not validate the historical file.
- Separate the compliance model from the submission model. These are two different things. Conflating them is what causes the pipeline rewrites every time regulation shifts.
The Uncomfortable Part
The uncomfortable truth is that in a two-authority regime, "correct" is not a single value. It is a pair of values that happen to agree most of the time. Pipelines built on the assumption of a single truth will keep breaking, and the breakage will always look like a data quality problem when it is actually an architectural one.
The teams that stop firefighting are the ones that accept this and design for it. Regulatory authority is not a constant. It is a temporally scoped, versioned input — and once you treat it that way, most of the recurring pain in BES pipelines simply stops recurring.