Every BES operator has lived some version of this: a downstream reconciliation flags a discrepancy, someone traces it back three cycles, and now you're looking at a resubmission window with EGM or SEDDK. The engineers want to know how fast they can push the corrected file. That's the wrong first question.
The right first question is: what does this correction say about every prior filing we've made?
The Fix Is Not the Deliverable
I've watched teams treat regulatory resubmissions as an engineering ticket. Identify the bug, patch the transform, backfill the affected records, submit. Clean, closed, ticket resolved. Then two weeks later a letter arrives asking why the participant contribution totals for Q2 no longer tie to what was declared in the katılımcı bildirimi, and whether the firm is now formally amending its position on twelve months of prior reporting.
At that point you're not negotiating a correction. You're defending a narrative you never wrote.
The deliverable in a resubmission is not the corrected file. It is the framing that accompanies it: scope, causation, materiality, and — this is the one that gets skipped — the boundary condition that says this and no further.
What the Regulator Is Actually Deciding
When a supervisor at EGM or SEDDK opens a resubmission request, they are running an internal decision tree that has almost nothing to do with your ETL:
- Is this an isolated event or a symptom?
- Does accepting this correction obligate them to reopen prior periods?
- Does the framing you've provided give them cover internally, or does it create exposure for the people who signed off previously?
- Will this show up in the next denetim as an unresolved item?
If you don't speak to those questions directly, they will infer answers. The inferences are almost always worse than the truth.
The Language Problem
Here is where firms with strong technical teams consistently lose ground. The regulator's internal vocabulary is not the vocabulary of data engineering. "Pipeline defect" translates poorly. "Idempotency violation" translates not at all. What translates is:
- Kapsam — the exact universe of records affected, stated in the regulator's own reporting units, not your table schema.
- Etki — the financial or participant-level impact, quantified in the terms the supervisor will have to explain upward.
- Kök neden — a root cause framed as a control gap, not a technical accident, because control gaps have remediation plans and technical accidents suggest recurrence.
- Sınırlama — the explicit statement that the issue is bounded, with evidence, so the supervisor doesn't have to guess.
A firm that walks into the conversation with these four elements pre-articulated gets a two-week resolution. A firm that walks in with a technical explanation and a corrected file gets a three-month back-and-forth and, often, an expanded scope request.
The Timing Trap
Resubmission windows have a perverse dynamic. The faster you submit the correction, the more the regulator assumes the fix was trivial and therefore the underlying issue was obvious and therefore why wasn't it caught earlier. The slower you submit, the more they assume complexity, which invites scope expansion.
The right cadence is: fast acknowledgment, deliberate framing, submission timed to a pre-agreed scope. I've seen firms burn credibility by pushing a corrected BES file within 48 hours of discovery, only to spend the next quarter explaining why they moved faster than they thought.
Acknowledge in 24 hours. Frame within a week. Submit when the frame is agreed. That sequence protects everyone, including the supervisor on the other side who has their own reporting chain.
Sitting on Both Sides
Having been on both the operator side and the review side of these conversations, the pattern is consistent: the firms that struggle are the ones who believe the file speaks for itself. It never does. The file is evidence. The submission letter is the argument. The pre-submission conversation is the verdict.
The supervisor is not adversarial. They are constrained. They have a queue, a manager, and a set of prior positions they cannot easily contradict. Your job in the pre-submission conversation is to give them a version of events that lets them close the item cleanly without creating new problems in their own file.
If you can do that, the correction goes through. If you can't, the technical fix becomes irrelevant.
What to Build Internally
Most firms have a runbook for pipeline incidents. Very few have a runbook for regulatory resubmissions. The gap costs more than any single ETL defect ever will.
At minimum, before the next resubmission event, have the following ready:
- A standing template for the four-element framing above, in Turkish, reviewed by someone who has actually corresponded with the regulator.
- A pre-identified single point of contact who has the authority to negotiate scope, not just transmit files.
- A materiality threshold agreed with legal and compliance in advance, so the framing conversation isn't happening for the first time under pressure.
- A written boundary statement methodology — how you prove this and no further — because you will be asked, and "we checked" is not an answer.
The correction is the easy part. It always was.