Process guidance only. Required fields, formats, cadences and submission channels differ by regulator and change over time — take them from current licence conditions and the regulator's own guidance for each market.
Where reporting actually breaks
It is rarely the query. In practice the failure lands in one of four places, in rough order of how expensive they are to discover late:
| Failure | Discovered when | Cost to fix at that point |
|---|---|---|
| Event never captured | First submission attempt | Highest — the period cannot be reconstructed at all |
| Captured without the needed dimension | First submission attempt | High — partial reconstruction, with caveats you must disclose |
| Definition mismatch | Regulator query or audit | Medium — restatement plus an explanation of the original figure |
| Pipeline overwrites history | When someone asks what was submitted last quarter | Medium, and recurring until the pipeline versions instead of overwriting |
All four are cheap in design and expensive at a deadline. That asymmetry is the argument for treating reporting requirements as acceptance criteria on the product rather than as downstream analytics work.
Lineage: the property that makes a report defensible
A defensible submission can be traced end to end: from the figure, to the transformation, to the dataset, to the captured event, with versions at each hop. Practically that means:
- Immutable event capture — corrections arrive as new records, not edits to old ones.
- Versioned transformations — the code that produced a submitted figure is identifiable months later.
- Snapshotted submissions — what was sent is stored as sent, independent of the live warehouse.
- Definitions in one place — the same metric dictionary the rest of the business uses, so the regulator's number and the board's number differ only where they are supposed to.
The snapshot matters more than it sounds. Without it, "what did we submit?" is answered by re-running a query against data that has since changed — which is not an answer.
Submission as an operation
The reporting pipeline produces a file or an API call; the operation around it is what fails at 4pm on a deadline. Give it the same treatment as any other deadline-bound run:
| Element | What it looks like when it works |
|---|---|
| Owner and backup | Named, with the backup having actually run the process at least once |
| Runbook | Steps, credentials route, validation checks, what to do when validation fails |
| Pre-submission validation | Automated checks against last period, expected ranges and required-field completeness |
| Calendar | Deadlines per market, with lead time for the checks rather than the deadline itself |
| Restatement rule | Written before it is needed: trigger, approver, notification, record |
Change management
Reporting requirements change, and they change on the regulator's schedule rather than the roadmap's. Two habits absorb most of that:
- Treat every requirement as a matrix row with an owner and a last-confirmed date, so a change has somewhere to land.
- Keep the capture layer generous. Recording a dimension you do not currently report is cheap; adding it retroactively is impossible. Within data-minimisation limits, capture the dimensions the product genuinely generates.
That second point has a boundary: generous capture is not a licence to hoard personal data. The test is whether the field is operationally justified, not whether it might one day be interesting.
Continue reading: Decomposing NGR — why the internal and regulatory numbers must share definitions. Certification and go-live — when the first submission deadline actually lands.