Regulatory reporting set-up: what the decision maker looks at
The decision maker looks at whether your reporting set-up produces complete, timely, and traceable records — not at how the underlying business operates. Reviewers check data lineage, sign-off ownership, and escalation paths before granting or renewing supervisory comfort. A gap in any of these three areas usually triggers a request for remediation rather than a refusal.
What changes once the file moves from build to review
Before submission, a weak link in the pipeline is an internal note. After submission, the same gap becomes a formal finding with a deadline attached to it. In practice, I have seen files stall exactly at this point: the pipeline works, but nobody can show who signed off the test run.
Once a report is filed, the clock on any query starts running from the authority's side, not yours. Silence on your end after that point reads as delay, even if the underlying figure was correct.
What to prepare
Prepare the file in this order. Skipping a step does not shorten the process — it moves the gap further down the chain, where it is harder to close.
- Map every reporting obligation your licence category triggers, and assign one internal owner per feed. Owner: compliance lead.
- Build the data pipeline from source systems to the report template, and document each transformation. Owner: engineering, with compliance sign-off.
- Run a dry submission and record every manual override made along the way. Owner: the designated tester.
- Have the sign-off chain approve the dry run in writing, with a date on the approval. Owner: senior compliance officer.
- Submit the live report and log any authority feedback separately from the submission file. Owner: reporting owner.
- Schedule the next periodic review before the current file closes. Owner: compliance lead.
The dry-run file mirrors the evidence pack used in a different type of control review — see Internal audit of controls step by step for the document list used in that context.
| Stage | What the decision maker checks | Typical evidence |
|---|---|---|
| Data mapping | Coverage of every trigger event under the licence | Register of reporting obligations |
| Pipeline build | Traceability from source system to submitted figure | Data lineage diagram |
| Dry run | Consistency between test output and expected output | Signed test log |
| Sign-off | Independent review before submission | Approval memo with a date |
| Live submission | Timeliness against the internal deadline | Submission receipt with timestamp |
| Post-submission | Closure of any authority query | Correspondence log |
Who decides and how long it takes
Within a licensed entity, the case officer handling ongoing supervision reviews the reporting file as part of a recurring cycle, not as a one-off gate. The reviewer does not read the whole pipeline every time; they sample the weakest point from the previous cycle first.
How long the review takes depends less on the size of the business and more on whether the sign-off chain was tested before submission. A tested chain moves through review quickly. An untested one generates a query, and the query resets the clock.
Where paths diverge
If you already report under another licence category, reuse the existing pipeline structure and remap only the fields that differ. Building a new pipeline from scratch when one already exists is the most common source of delay at this stage.
If this is a first authorisation, build the pipeline before you submit the application, not after approval. A reviewer who sees a pipeline that exists only on paper treats the whole file as untested.
Where several findings compete for attention after a review, decide the order of remediation the same way a register decides between competing claims — the earlier gap gets resolved first. The underlying logic, applied in a different register, is set out in Seniority and priority claims step by step.
If the person who owns the reporting pipeline leaves before hand-over is complete, treat the gap the same way an ownership gap is treated when a project loses its original owner — see AI products and models — when a founder leaves for how that gap is documented rather than guessed at.
What this page does not cover
This page describes the procedure and the evidence a decision maker expects. It does not set out the specific data fields required for any one reporting class, the exact filing deadline attached to a given trigger event, or any fee. Those details sit with the authority's own published templates, not with this file.
Where the reporting obligation concerns a token and the underlying right behind it is not yet registered, the pipeline question changes shape before it starts. That situation is handled separately, not on this page.
Verified
Checked against the authorisation team's own working file and the supervisory expectations published by the relevant national competent authority, last reviewed on the date this page was issued. No case-specific figures are quoted here; where a figure is not on file, this page describes the mechanism instead of the number.
A related process, where the decision maker also checks the evidence chain rather than the substance of a claim, is covered in Complaint handling procedure step by step.
If your reporting set-up must also cover a token whose underlying right is not yet registered, start with When the token refers to an unregistered right before you build the pipeline.
FAQ
How long does regulatory reporting set-up take in practice?
Duration depends on how many source systems feed the report and whether the sign-off chain has already been tested. A single-source pipeline with a tested chain moves through review faster than a multi-source pipeline built from scratch.
Which documents are needed to start?
A register of every reporting obligation triggered by the licence, a data lineage diagram, and a named owner for each feed. Without these three, the reviewer has nothing concrete to check the submission against.
What happens if the other side does not respond?
If a data-supplying counterparty does not confirm figures in time, document the gap and the date of the request rather than estimating the number. A documented gap reads as a manageable finding; an undocumented estimate reads as an error.