ISO 20022 is not a new standard. The international standard for financial messaging has been in active development since the early 2000s, and early adopters in the SEPA credit transfer infrastructure began implementation over a decade ago. What makes the current period distinct is the industry-wide migration timeline: SWIFT's T2/T2S migration in Europe, the Bank of England's CHAPS migration, and the Federal Reserve's FedWire adoption schedule have converged on a window in which the vast majority of high-value payment infrastructure is moving to ISO 20022 message formats simultaneously.
For PSD2 regulatory reporting, this migration has a specific and often underappreciated consequence: the message schemas that underpin quarterly NCA submissions are not static. NCAs are updating their schema requirements to align with ISO 20022 migration milestones. PAIN.001 and PAIN.002 schema versions are advancing. Fields that were optional in prior versions are becoming required. Data elements that did not exist in earlier schema generations are being added to accommodate ISO 20022 message enrichment. Compliance teams that treat their existing report generation templates as durable are building on a foundation that is actively changing beneath them.
What ISO 20022 Migration Actually Changes at the Schema Level
ISO 20022 migration is primarily about message enrichment — the new message formats carry significantly more structured data than the older SWIFT MT messages they replace. For PSD2 reporting, the relevant enrichment points include:
Originator and beneficiary identification. ISO 20022 PAIN.001 allows for richer structured address formats and identification schemes for both originating and beneficiary parties than prior message generations. As NCAs update their schema requirements to align with ISO 20022, they may begin requiring structured identifiers where previously a freeform string was acceptable — or may add new optional fields that, when populated, change how transactions are categorised in the regulatory report.
Purpose codes and category purpose codes. ISO 20022 introduced a richer taxonomy of payment purpose codes (Purp/Cd) and category purpose codes (CtgyPurp/Cd) compared to earlier frameworks. Some NCAs have updated their PSD2 schema requirements to use these purpose codes for transaction categorisation in regulatory reports. Institutions that populated purpose code fields with default or placeholder values in earlier schema generations may find that NCA schema validation now requires values from a specific enumeration.
Charges and charge bearer information. ISO 20022's handling of charges and charge bearer elements (ChrgBr) has evolved across version generations. Schema updates to PAIN.001 have included changes to charge bearer enumeration values and constraints that affect how cross-border transactions are represented.
Remittance information. The structured remittance information fields in ISO 20022 PAIN.001 have been extended across versions, and some NCA schema updates have introduced requirements or constraints on remittance data formats that reflect ISO 20022 migration guidance from EPC (European Payments Council) Rulebook updates.
Version Generation Matters More Than Minor Increments
Within the ISO 20022 message identifier framework, version identifiers follow the pattern <msg-type>.<org>.<gen> — so pain.001.001.09 is the Credit Transfer Initiation message, ISO organisation, generation 9. The generation number is the one that matters most for migration-driven schema changes: a move from generation 9 to generation 11 carries more schema-breaking change potential than a minor revision within a generation.
NCA schema updates triggered by ISO 20022 migration have generally tracked the ISO 20022 generation releases, though with varying degrees of lag. BaFin's schema requirements for MVP submissions, for example, have been updated in response to T2/T2S migration milestones. The FCA's GABRIEL-adjacent schema requirements for UK payment institutions have similarly been updated in response to CHAPS migration phases. Institutions operating under multiple NCAs are likely to find that different NCAs are at different points in their ISO 20022 migration schema adoption, creating a multi-version environment that increases the complexity of a single institution's multi-NCA reporting.
The Downstream Effect on Report Package Generation
For a compliance team that manually generates PSD2 report packages, ISO 20022 migration-driven schema changes create a particularly difficult problem. The changes are not always visible in the version string — an NCA may release a revised XSD under the same version identifier if they consider the change to be a correction rather than a version increment. Detecting these silent updates requires a hash comparison against the stored XSD, not just a version string check.
Once a change is detected, the impact analysis for an ISO 20022 migration-driven schema update is potentially broader than for a minor correction. Changes to required field sets, enumeration values, or data type constraints may require updates to the institution's data extraction process — not just to the XML generation template. If the NCA now requires a structured address in a field where a freeform string was previously accepted, the institution must ensure that its transaction data contains structured address data, or that the report generation process has logic to construct structured addresses from available data.
This is qualitatively different from a correction that merely fixes a constraint typo in the prior schema version. Migration-driven schema updates can require substantive changes to the data pipeline that feeds report generation.
A Scenario: Multi-NCA ISO 20022 Migration Impact
A payment institution with authorisations in Germany and the Netherlands prepares quarterly PSD2 submissions for both BaFin and DNB. In Q4 2024, BaFin released a schema update for its PAIN.001 reporting requirements that incorporated ISO 20022 generation 11 message structures, including a new required OrgnlEndToEndId field for credit transfer transactions above a specified value threshold.
The institution's report generation template had not been updated to populate this field. The BaFin MVP portal rejected the submission with an XSD validation error. Concurrently — and coincidentally — DNB released a schema update for its own PAIN.001 requirements that changed the enumeration for the ChrgBr field in cross-border transaction records, removing an enumeration value that the institution's template had been using as a default.
Both schema changes were migration-related. Neither was detected by the institution's monitoring process, which checked the NCA documentation page for version string changes but not XSD file hash changes. The combined impact — two failed submissions, two concurrent schema updates to apply, two validation and re-submission cycles — consumed approximately six working days across the compliance team over the final two weeks of the submission window.
This scenario is plausible and constructed to illustrate the multi-NCA compounding problem. The institution and specific schema details are synthetic.
What Compliance Teams Should Anticipate Through 2026
ISO 20022 migration is not a one-time event. The major infrastructure migrations (T2, CHAPS, FedWire) represent the largest discrete steps, but the downstream effect on NCA schema requirements will continue to propagate for several years as NCAs update their own reporting frameworks to align with the enriched message structures that migration enables.
We are not suggesting that compliance teams need to become ISO 20022 message format experts. What the migration requires from compliance operations is a recognition that the report generation templates and data extraction configurations that have been stable for several years may now require more frequent review than in prior years. The appropriate posture is to treat the ISO 20022 migration period as a sustained period of elevated schema change risk, not as a discrete event that has now passed.
The EPC publishes its SEPA rulebook update cycle on a predictable annual schedule, and EBA follows with RTS and guideline updates that reflect rulebook changes. Tracking EPC rulebook publications — even for compliance teams whose primary focus is NCA reporting rather than payment infrastructure — provides advance warning of the directions in which NCA schema updates are likely to move.
The SEPA Rulebook Connection
One monitoring source that is underused by PSD2 compliance teams is the European Payments Council's SEPA Credit Transfer and SEPA Direct Debit rulebook publications. The EPC Rulebooks specify the message schemas used in SEPA-area transactions, and NCA PSD2 reporting schema requirements are substantially influenced by these rulebook versions. An EPC rulebook version update that introduces a new optional field or changes an element's cardinality often appears in NCA schema updates one to three quarters later.
Monitoring EPC rulebook publications provides a forward-looking signal about likely NCA schema changes — not a definitive prediction, but a directional indicator that allows compliance teams to anticipate the nature of upcoming changes before the NCA releases its updated XSD. Institutions that track EPC publications as part of their regulatory horizon-scanning are better positioned to absorb NCA schema changes quickly when they arrive.