On 9 April 2026 European payment service providers (PSPs) face the next hard deadline in the calendar of the Instant Payments Regulation (IPR, Regulation (EU) 2024/886). By that date they must submit, for the first time, a harmonised report on their use of SEPA Instant Credit Transfer (SCT Inst) and on compliance with price and access parity to their national competent authority. What sounds like a technical formality actually opens a new supervisory chapter: after the ability to transact in real time, supervisors will now measure how well institutions actually do it.

A second countdown is running in parallel. From 22 November 2026 the SWIFT network will no longer accept unstructured postal addresses in Cross-Border Payments and Reporting Plus (CBPR+) messages. At a minimum, town and country must be transmitted in structured fields. Given that roughly 65 per cent of payment messages still rely on free-text address fields, this is not a formal act – it is a quiet deadline that can translate into outright payment failures in the international business for unprepared institutions.

Both dates hit PSPs at a point when their projects are transitioning from go-live mode into business-as-usual. The operational scars have not yet healed, and the supervisor is already setting up the next obstacle.

At a glance

9 April 2026: First harmonised IPR report submitted by PSPs to the national competent authority – XBRL-CSV format, European Banking Authority (EBA) taxonomy

22 November 2026: SWIFT network rejects unstructured addresses in CBPR+ payments (pacs.008, MT 103 migration)

Status quo: Approximately 65 per cent of cross-border payment messages still use unstructured address fields

IPR investment: Between EUR 1 million and EUR 3 million per European bank for infrastructure upgrades (EY estimate)

Legal basis: Regulation (EU) 2024/886 (IPR), EBA Implementing Technical Standards for SEPA reporting, SWIFT HVPS+/CBPR+ guidelines

The road to 9 April 2026

What was required so far – and what institutions have actually delivered

The IPR has been in force since 8 April 2024. Its effects materialise in phases. Since 9 January 2025 all PSPs in the euro area have been required to receive SCT Inst transfers. On 9 October 2025 three core obligations took effect simultaneously: the send obligation, price parity between classic SEPA and the instant variant, and the mandatory Verification of Payee (VoP) mechanism. For non-euro PSPs inside the EU, the equivalent deadline extends to 9 July 2027.

Figures published by Deutsche Bundesbank show how quickly the business-as-usual volume is growing. Real-time transfer volume in Germany rose 37 per cent in 2023 to 337 million transactions. At the European level, the share of SCT Inst within all SEPA credit transfers reached around 17.8 per cent in the first quarter of 2024. Before the regulation, roughly 70 per cent of European PSPs already participated voluntarily in the SCT Inst scheme; participation is now universal. Growth potential is therefore not hypothetical – it is already observable.

What the reporting obligation actually requires

The European Banking Authority (EBA) has issued Implementing Technical Standards (ITS) that specify the detail. Reporting follows an XBRL-CSV format based on a defined taxonomy, with strict validation rules and harmonised templates. The content splits into three data blocks.

First, PSPs must report volume and value data for SEPA credit transfers, split between classic SCT and the instant variant, both domestically and within the EU, with time series over the reporting period. Second, fees must be disclosed transparently at both national and cross-border level, with an explicit view on price parity as required by Article 5b of the regulation. Third – and this is where the operational pressure kicks in – institutions must report their rejection rates for instant credit transfers, with particular attention to transactions blocked due to sanctions screening or other compliance checks.

The reporting obligation is not a regulatory ornament. It is the instrument through which supervisors can verify, for the first time, whether institutions' compliance promises are kept in practice.

That last data category is politically sensitive. PSPs are obliged to screen their customer bases against sanctions lists "without delay" – but the IPR explicitly prohibits live screening of individual transactions. In practice most institutions still screen at transaction level to mitigate legal risk. The outcome is well documented: more than half of the banks in one industry survey reported false-positive increases of 30 to 50 per cent since the start of IPR implementation. These rejections now feed directly into the supervisory reporting format – and therefore potentially into the radar of the Federal Financial Supervisory Authority (Bundesanstalt für Finanzdienstleistungsaufsicht, BaFin) and the European Central Bank (ECB).

Why the reporting is harder than it looks

Underestimated supervisory reporting tends to follow a familiar pattern: the data exists, but not at the required granularity, not in the required format, not over the required time series. Many PSPs have so far managed their instant-payments volumes in separate systems without harmonising them with classic SEPA data. Sanctions rejections are typically captured in compliance tools that are not linked to the supervisory reporting stack. Fee data sit in product systems, not in reporting aggregates.

The XBRL-CSV requirement sharpens the picture. Institutions that have relied on established frameworks such as COREP or FinRep for supervisory reporting must build a dedicated taxonomy, dedicated validation rules and a dedicated data pipeline for the IPR report. The EBA deliberately pushed the enforcement start into 2026 – partly because many institutions were not on track with implementation. That buffer is now running out.

The second workstream: structured addresses under ISO 20022

What expires on 22 November 2026

The global migration of cross-border payments to the ISO 20022 standard has been running in coexistence mode since March 2023: banks may still send payments in the legacy MT format, and the SWIFT network translates them into ISO 20022 via CBPR+. Coexistence ends in November 2026 – and with it the acceptance of unstructured address fields.

SWIFT has defined what "structured" means in precise terms. In the fields for debtor, creditor and their respective agents, at a minimum Town Name and Country must be transmitted in dedicated tags. For most payment messages – notably pacs.008, pacs.009 and camt.056 – this becomes mandatory at the deadline. The exceptions cover internal reporting messages such as admi.024, camt.025, camt.052, camt.053, camt.054 and camt.060 – in other words statements and technical confirmations, not payment orders.

Why 65 per cent are still not ready

The operational reality is sobering. SWIFT reports that approximately 65 per cent of all payment messages routed through the network still contain unstructured addresses. The causes are structural. In many core banking systems the address of debtor or creditor is a free-text field populated from a Customer Relationship Management (CRM) database or a legacy system. Machine-readable decomposition into street, number, town, postcode and country requires either clean master data at the source or parsing logic in the payments gateway. Both are often absent in German institutions.

From an anti-money-laundering perspective, addresses are not decoration. They are the primary attribute used to identify counterparties unambiguously.

SWIFT itself has responded and now offers an open-source solution based on Natural Language Processing (NLP) that converts unstructured addresses into structured fields automatically – the "Swift AI Address Structuring Model". The tool is free but only patches the problem selectively. For banks without clean master data it remains a downstream correction, not a solution to the root cause. Institutions that only start enforcing structured addresses in the third or fourth quarter of 2026 risk faulty or rejected payments in January 2027 – in a business line where reputational damage translates directly into customer churn.

The quiet connection between both deadlines

From a supervisory perspective, IPR reporting and ISO 20022 migration are two unrelated topics. Operationally, the link is tighter than it appears. Both initiatives force PSPs to structure their payments data, to standardise it and to keep it consistent across systems. Both presuppose file formats and taxonomies that have so far existed as silos in many institutions. And both elevate manual rework driven by data-quality issues to the dominant cost driver.

Whoever takes the reporting obligation seriously immediately runs into the address data that sanctions screening relies on. Whoever takes the ISO 20022 migration seriously must eventually feed those structured payments data into the supervisory report too. Institutions that treat both themes as separate projects lose synergies and pay twice for data-quality work. Institutions that integrate them build, as a by-product, the foundation for what is coming anyway: end-to-end structured payments data that will also be needed for Payment Services Directive 3 (PSD3), Open Finance and the digital euro scenario.

Who is affected – an overview

Function Key impact from reporting and ISO 20022
Regulatory reporting New EBA XBRL-CSV taxonomy; dedicated data pipelines, validation rules and control processes alongside COREP and FinRep
Compliance / AFC Rejection data from sanctions screening must be converted into reportable aggregates; false-positive rates become visible to supervisors
Payments ISO 20022 address fields mandatory in pacs.008 and follow-on messages; end-to-end consistency across every correspondent bank
Core banking / CRM Address data model moves from free text to structured fields; mass remediation of existing customer records
Operations Exception handling for rejected payments; monitoring of processing rates inside the 10-second window
IT / gateway Parsing logic for legacy addresses or adoption of the SWIFT AI Address Structuring Model; API integration into CBPR+
Pricing / product Price parity between SCT and SCT Inst reportable; hidden surcharges become verifiable to supervisors
Customer communication VoP outcomes (match, close match, no match) to be communicated transparently; complaint handling processes need adjustment

Recommendation: a four-point plan for payment service providers

The urgency of both deadlines is frequently underestimated because the visible core obligations of the IPR are already behind the institutions. Yet reporting quality and address structure are the very dimensions on which supervisors will measure operational maturity from now on. For the period up to the end of 2026, a focused approach is called for.

1. Consolidate and test the reporting pipeline

By Q3 2026: The first submission on 9 April 2026 has been delivered – but for many institutions it was a patchwork of Excel exports, manual reconciliations and last-minute validations. For the follow-on submissions the pipeline must be stabilised: an end-to-end data flow from payments systems, compliance engines and product databases into a central XBRL-CSV generation layer. Dry runs at least two quarters before the next deadline, including validation against the EBA taxonomy.

2. Actively manage the sanctions rejection rate

Ongoing: Reported false-positive rates of 30 to 50 per cent cannot remain a permanent state. Institutions should tune their screening engines – through fuzzy-matching calibration, context-based rule sets and targeted use of machine learning in pre-hit analysis. Every reduction improves the supervisory picture and lowers the operational cost of rework.

3. Treat the address data programme as a project in its own right

By Q3 2026: The ISO 20022 deadline on 22 November 2026 is not a pure format change but a master-data programme. Address records of existing customers must be systematically converted into structured fields; new customers should only ever be onboarded with structured data. The SWIFT AI Address Structuring Model can serve as a bridge, but it does not replace clean data at the source. Institutions that only start in the third quarter will not reach the deadline without an error rate.

4. Steer both programmes under one governance

From Q2 2026 and ongoing: The reporting obligation and the ISO 20022 migration should run inside the same programme governance. The data quality that feeds the report on sanctions rejections is the same data quality that populates structured addresses in pacs.008. Separate projects duplicate effort, obstruct synergies and generate inconsistent data states. A joint payments data-domain governance is the strategically cleaner path – and it lays the foundation for PSD3 and the digital euro as a by-product.

The next phase of instant payments regulation no longer asks whether institutions can deliver. It measures how cleanly they do it.

Risks and open questions

The next regulatory phase carries three specific risks for payment service providers. First, a data-quality risk: if the inaugural report exposes quiet gaps – for instance inconsistent sanctions rejection data or price parity that cannot be evidenced – targeted supervisory enquiries follow. The answers are expensive because they touch not only the reporting layer but also the underlying compliance architecture.

Second, an ISO 20022 migration risk: institutions that only tackle the transition to structured addresses in the third or fourth quarter of 2026 risk rejected payments, customer complaints and reputational damage in January 2027. Unlike the IPR go-live, there is no European safety net – the SWIFT network simply rejects, irrespective of readiness rates in individual markets.

Third, a supervisory comparability risk: with the harmonised XBRL-CSV report, what used to be estimation becomes direct comparison – BaFin and the EBA can benchmark IPR compliance across institutions directly. Institutions with markedly higher rejection rates or deviating price structures move into the spotlight automatically. The regulatory attention market therefore shifts from implementation to efficiency.

Institutions that tick this phase off as a technical obligation miss what it actually is: the moment at which instant payments regulation transitions from build-out to competition. The next 24 months do not decide on compliance – they decide which institutions run payments in a structured, efficient and data-driven way. And which ones keep running them as a manually patched black box.

Timeline: Instant Payments Regulation and ISO 20022 migration
From the adoption of the IPR to the address deadline – key milestones
April 2024
Regulation (EU) 2024/886 (IPR) enters into force
Legal framework for a universal instant-payments obligation across the euro area is in place.
9 January 2025
Receive obligation for SCT Inst for euro-area PSPs
Every PSP in the euro area must be able to receive real-time credit transfers.
9 October 2025
Send obligation, price parity, Verification of Payee
Three core obligations take effect simultaneously. Removal of the previous EUR 100,000 cap.
9 April 2026
First IPR supervisory report
Harmonised XBRL-CSV reporting under the EBA taxonomy – volumes, fees, rejections.
22 November 2026
ISO 20022: end of unstructured addresses in CBPR+
The SWIFT network only accepts structured or hybrid addresses in pacs.008 and follow-on messages.
9 July 2027
Full IPR application for non-euro EU PSPs
Receive and send obligations as well as VoP apply EU-wide irrespective of currency.
Christian Schablitzki

Christian Schablitzki

Strategy & Management Consultant · Agentic AI expert for financial institutions

More than 20 years in investment banking and derivatives trading, followed by over 10 years advising financial institutions. Currently Partner at Infosys Consulting in Germany. Certified in Google AI, Generative AI Leader (Google Cloud) and IBM RAG and Agentic AI.

LinkedIn profile →
newsletter
the agentic banker

Keep reading – delivered to your inbox every two weeks.

Capital markets insights, regulatory updates and AI trends. Concise, grounded, free of charge.

GDPR-compliant. Unsubscribe anytime.

← Back to overview