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.
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.
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.
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.
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.
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.
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.
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.
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.
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.