Instant payments reporting — building the IPR return

The Instant Payments Regulation return is unusual in one respect that makes it much harder than it looks: it asks for history. A new reporting obligation that begins with a backfill of prior years cannot be met by instrumenting the payment flow going forward — the data has to be reconstructed from records that were never kept for this purpose. That single feature is why firms that treated it as a standard new-return project ran late.

1. What the return collects

The IPR return is built around a set of structured tables covering charges and instant-payment provision, submitted on the European template with national implementation on top. Its purpose is comparative: it lets authorities test whether the Regulation’s charge-equality and reachability requirements are being met in practice, market by market.

2. The backfill is the project

The historical element is where the effort concentrates, and it has three distinct problems:

• The data exists but not in this shape. Charge and volume data lives in billing and payment systems organised by product and customer, not by the categories the return uses.
• Definitions changed inside the period. Product names, fee structures and system boundaries moved over several years, so a single query across the whole window will not produce comparable figures.
• Nobody owns the history. The people who understand a fee structure from three years ago may have left, and the documentation is commercial rather than regulatory.

The approach that works is to build the return backwards from the most recent period, where the data and the knowledge are best, and to treat each earlier period as a separate exercise with its own documented assumptions. Attempting a single query across the whole window produces one number with unknown comparability; period-by-period produces a series with documented breaks, which is what a supervisor can actually use.

3. National variation on a European template

The template is European; the collection is national. In practice that means the same content arrives through different channels with different deadlines and different additional checks in each market — the pattern that recurs across every statistical collection in this cluster.

Two practical consequences. Build one dataset to the European specification and treat each national submission as a rendering of it. And confirm per market whether the national authority adds items beyond the template, because those are the ones absent from any vendor tooling.

4. Where the data comes from

The charge rows are the hard ones because a charge is rarely a single field. Bundled pricing, negotiated tariffs, promotional waivers and package inclusions all mean the amount a customer effectively paid for a payment is a derivation rather than a lookup — and the derivation has to be consistent across the whole series, including the reconstructed part.

5. A worked case

Facts: a provider assembles the return from its current billing configuration, applied retrospectively to historical volumes.

What goes wrong: the current tariff is applied to periods in which a different tariff was in force. The volumes are right and the charges are wrong, and the error is invisible in the output because both figures are individually plausible.

What the practitioner does: sources each period’s charges from the configuration in force in that period, documents where the configuration cannot be recovered and what was assumed instead, and files with the limitation disclosed rather than silently. A disclosed reconstruction with stated assumptions is a controlled outcome; a silent one that later proves wrong is a misstatement across several years at once.

Going forward, the durable fix is to persist the applied charge per payment as a field rather than deriving it from configuration — which turns every future period into an extract instead of a reconstruction.

FAQ

Related: The IPR return · Verification of Payee · Building a reporting pipeline