A figure in a regulatory return you already submitted turns out to be wrong. What happens next, and what should the system have been built to do?

A return is an assertion, and someone signed it

Start from what a submitted return actually is. It is not an export. It is a set of claims the firm has made to its supervisor about its own position at a cut-off, approved by a named person, and it becomes part of a series the supervisor uses to watch trends and to compare you against peers. That last property is why quietly fixing a number is not an option: a corrected figure that appears without explanation shows up as a discontinuity in a trend somebody is looking at, and it damages the thing the whole regime depends on, which is that your numbers can be relied upon.

So the incident response has two tracks running in parallel, and a candidate who covers only one will sound like an engineer who has never been in the room. The technical track quantifies the error, finds every return and period affected, and produces corrected figures with an explanation of the difference. The governance track assesses materiality against the firm's documented criteria, informs the accountable owner, notifies the supervisor — usually before the corrected file arrives rather than with it — and records the whole thing in the issues log with a remediation owner and a date. Firms are generally expected to be candid and prompt about errors, and the tolerance for a self-reported mistake is nothing like the tolerance for one the supervisor found.

Reconciliation is a control with a result, not a comparison

The first requirement anyone states is that the return must tie to the ledger. It is worth being precise about what that means, because "we reconcile" is doing a lot of unexamined work.

A reconciliation control has a defined pair of populations, a stated basis on which they should agree, a tolerance, a recorded result, and an owner for breaks. Between a return and the ledger the basis is almost never one-to-one, and the differences are the interesting part: the return is prepared on a regulatory basis that may classify or value items differently from the accounting basis, it may consolidate a different set of entities, it may use a different cut-off convention, and it will exclude or include items the ledger does not distinguish. Each of those is a legitimate, documented bridge item. What must be true is that every difference between the return total and the ledger total is explained by a named bridge item with its own evidence, and that the residual is zero or inside tolerance.

The value of insisting on an explained bridge is that it converts an unexplained variance into a signal. When the bridge stops reconciling, something changed — a new product booking to an account nobody mapped, a classification rule that stopped firing — and you find out in the run rather than in the examination.

Completeness is the half that hides

Correctness errors announce themselves: a wrong classification produces a figure that looks odd, a broken calculation fails a plausibility check. Completeness errors do not. A return built from nine of ten feeds is internally consistent, reconciles against the nine, and is wrong by whatever the tenth contained.

The control is a manifest declared before the run rather than inferred from it. You state the set of sources expected for this reporting period, each with its own control total or record count supplied by the source itself, and the run refuses to produce a final output unless every expected source is present and each one's independently supplied total matches what was loaded. A late feed then becomes a run that cannot be signed rather than a run that silently omits something. The same principle covers within-source completeness: a source that normally sends a hundred thousand records and sends four hundred should stop the run, not scale a number down.

Restatement as a designed path

Now the part that actually separates answers. Most reporting pipelines are mutable ETL over current-state tables, and they can only ever produce "the figures as they are now". When such a system is asked to restate, the best it can do is regenerate the return from today's data. That regeneration is unusable, for two reasons: it silently absorbs every unrelated change that happened since the original run, and it cannot say what moved. You submit a corrected file whose difference from the original is partly the error you were fixing and partly six other movements, none of which you can name.

What you need instead is three capabilities held together.

The submitted artefact is immutable and stored as submitted — the exact file, its validation receipt, the sign-off, and a full snapshot of the input data set and the logic version that produced it. Second, the run is deterministic and re-executable against pinned inputs, so re-running the original produces the original figures byte for byte. That property is what makes the delta meaningful: you re-run with one thing changed and everything you see is attributable to that change. Third, the output carries per-line lineage, so a moved cell resolves to the contributing records and the rule that placed them there.

A restatement then reads like this, and the explanation is generated rather than written from memory:

Line item	Originally submitted	Restated	Delta	Cause
Exposures to corporates	4,182.6	4,251.9	+69.3	Facilities from one booking entity omitted; feed manifest not enforced
Exposures to retail	1,930.4	1,930.4	0.0	Unaffected
Total	6,113.0	6,182.3	+69.3	As above

Note what this makes possible beyond the correction itself: you can tell the supervisor the cause, the magnitude, the periods affected and that nothing else moved. A restatement whose delta is fully attributed is a controlled event. One that is not is an admission that you do not know what your own pipeline did.

Scope, and the temptation to fix it quietly

Two practical points that strong candidates volunteer. The error probably affects more than one return, because several returns draw on the same population with different cut-offs and different bases, so scoping starts from the data defect and works outwards to every consumer of that data rather than from the return where it was spotted. And the corrected figure may itself change what was reported downstream of the return — internal management information, disclosures, capital calculations — which is a reason the issues log entry belongs to the firm rather than to the reporting team.

The temptation, when an error is small, is to correct it in the next period's opening position and let it wash through. Sometimes that is the sanctioned answer, decided against documented materiality criteria by the person who signs the return. It is never the engineer's decision, and a system that permits it silently — by allowing figures to be adjusted without recording that an adjustment happened — has taken the decision away from the person accountable for it.

Build the pipeline so that re-running an old period reproduces the old numbers exactly, and every restatement becomes a delta you can attribute line by line. Without deterministic replay against pinned inputs, a correction and an unrelated movement are indistinguishable, and you are explaining your figures from memory.