Supervisory reporting — the anatomy of a return
A supervisory return is not a document — it is the output of a specification, and the specification changes on a published cycle. Understanding that is the difference between a reporting function that plans and one that reacts. Every return has the same anatomy: a legal obligation, a framework release that renders it machine-readable, a reference date, a remittance date, and a set of validation rules that decide whether the file is accepted at all.
1. The five parts
| Part | What it fixes |
|---|---|
| The obligation | Who must report, what, and how often — set in a regulation or directive and its implementing standards |
| The framework release | The machine-readable rendering: the data point model, the taxonomy and the templates |
| The reference date | The date the data describes |
| The remittance date | The date the file is due |
| The validation rules | The tests the file must pass to be accepted |
Only the first is law in the ordinary sense. The other four are technical artefacts published on a schedule — and they are where most of a reporting team’s year actually goes.
2. Two families, often confused
Prudential reporting exists so a supervisor can assess whether an individual institution is safe: capital, liquidity, large exposures, financial information. Statistical reporting exists so a central bank can measure the economy and run monetary policy. They differ in purpose, in legal base, in who collects them, and — most practically — in their tolerance for approximation.
Both families increasingly share the same infrastructure, which is why the integration work is worth doing once: a single, well-modelled source of exposure and counterparty data can feed several returns even where the definitions differ, provided the differences are modelled explicitly rather than patched at the end.
3. What a framework release actually contains
A release is a package, not a document. For the European Banking Authority’s frameworks it comprises the data point model — a structured representation of the data identifying the business concepts, their relations and the validation rules — the XBRL taxonomy expressing that model in a technical format, the validation rules, and annotated templates that consolidate the regulatory text with the templates and instructions for that version.
Releases are numbered sequentially, and each specifies module-level applicability dates rather than one date for the whole package. That is the planning detail that matters: a single release can change one module from one quarter and another from a later one, so “we are on version X” is not a complete answer to “what applies to this submission”.
FAQ
Is supervisory reporting the same as statistical reporting?
No. They have different purposes, legal bases and collecting authorities, and they define common-sounding concepts differently. Many firms owe both.
Why does the framework version matter?
Because it fixes the taxonomy, the templates and the validation rules for a submission. Applicability is set per module, so different parts of one release can start on different dates.
Where does most reporting effort actually go?
Into mapping source data to the model, and into keeping that mapping current across releases — not into producing the file, which is the last and cheapest step.
Related: The data point model · XBRL taxonomies · Validation rules
