Regulatory reporting for EU payment firms — the guide

Regulatory reporting for a payment firm is not one discipline. It is four supervisory relationships, six national frameworks and roughly a dozen distinct trigger types — and the reason it goes wrong is almost never arithmetic. This is the index to everything we have published on it: the returns market by market, how each one is actually constructed, and the practice that keeps a reporting function honest between cycles.

1. Start here

Four concepts do most of the work, and almost every failure traces back to one of them:

• What supervisory reporting is — the five parts of any return, and why prudential and statistical families differ.
• Reference date versus remittance date — the two clocks, and why the framework follows the first.
• The data point model — why a cell is a metric plus its dimensions, and never a position in a grid.
• Validation rules — what they test, what they cannot test, and why they change quarterly.

2. By market

3. Compared across markets

The comparisons are where the pattern becomes visible, and each one answers a question a multi-market firm actually has:

• Account registers — four build patterns, and the two regimes that catch firms with no establishment.
• External-sector reporting — why the ledger, not the payments system, and why unlicensed group entities are in scope.
• AML data returns beyond the SAR — the obligations owed whether or not anything suspicious happened.
• Channels and enrolment — the longest lead time in any first submission.
• Complaints — six regimes, six clocks, and routing by subject matter.
• Beneficial ownership registers — the filing duty, and the separate discrepancy duty at customer scale.
• Home versus host when passporting — four attachment rules, and the one everyone skips.

4. How specific returns are built

These take a named return and cover the construction — population, source, sequencing, controls:

• AnaCredit — the agent structure, the reference period, and the aggregation level that decides the population.
• MiFIR transaction reporting — what counts as a transaction, and the seven required control mechanisms.
• CESOP — counting payees rather than payments.
• The PSD2 fraud return — decided at case creation, not at reporting time.
• CRS — produced in January, determined at onboarding.
• The DORA register — sourced from contracts, not from IT.
• The IPR return — and why a historical backfill is the whole project.
• Own funds and safeguarding — the payments-specific pair.

5. The practice that keeps them right

Nine pages on the discipline, in the order they matter: building the pipeline, mapping to the model, testing before the first submission, reconciling returns, the metrics that predict problems, surviving a framework release, answering a supervisory query, handling a late filing, and governance and sign-off.

Then the two that decide whether any of it holds together over time: sequencing at market entry and scoping a new product. Both address the same failure — the perimeter moving without anyone noticing — from the two directions it moves from.

Two organisational pages sit alongside them. The operating model covers the four capabilities a reporting function needs and why the builder cannot also be the assurance, and outsourcing covers what can move to a provider and the four artefacts that have to stay with you.

6. Three threads that run through everything

Read across the whole cluster and the same three points recur, in every market and every regime:

• The perimeter is not the licence. Obligations attach to residence, to the customer, to activity and to the authorised entity — four different rules. The one that catches firms is the customer-residence limb, because nothing in an authorisation file mentions it and no supervisor writes to tell you.
• Dimensions, not amounts. Every reporting programme is a data-collection programme wearing a reporting label. The amount is available; counterparty residence, sector and instrument class are what the source does not hold.
• Silent failures outnumber loud ones. Late filings announce themselves. Missing populations, stale registers, unmatched acknowledgements and drifting reconciling items do not — and every one of them is detected by a reconciliation rather than by a validation rule.

If a reporting function does one thing beyond producing its returns, it should be the reconciliation between what it reports and what the business actually holds. That single control catches more than the rest of the framework combined.

FAQ

Related: What is supervisory reporting · Prudential vs statistical · The reporting operating model