Harmonised ISO 20022 Data Requirements: The 2027 Alignment Window

ByRegReportingDesk

On 26 February 2026 the Committee on Payments and Market Infrastructures (CPMI) published an updated set of harmonised ISO 20022 data requirements for enhancing cross-border payments, replacing the report it delivered to the G20 in October 2023. The document and technical annex recommend that payment system operators and participants align their ISO 20022 usage guidelines with the harmonisation requirements before the end of 2027. The CPMI expressly states that implementation is voluntary; end-2027 is therefore an industry alignment target, not a regulatory deadline. The timing follows the end of the Swift MT/ISO 20022 coexistence period on 22 November 2025.

The harmonised ISO 20022 data requirements sit inside the G20 Roadmap for Enhancing Cross-border Payments and target its four objectives of faster, cheaper, more accessible and more transparent payments. They cover a core set of nine ISO 20022 messages used in the interbank space, twelve general requirements on how those messages carry data, and detailed data models set out in a separate technical annex. What they do is describe how the industry should use ISO 20022 consistently so that a payment can move end to end without the truncation and re-keying that fragmented message practice still produces.

The first thing to settle is status. The CPMI states plainly that these requirements are not, and should not be regarded as, regulatory requirements. Non-conformance would not, by itself, result in a payment being rejected. That distinction changes how an operations team should scope the work: the CPMI requirements are voluntary market-practice guidance, while binding obligations arise from the applicable legal, regulatory or payment-scheme framework. Revised FATF Recommendation 16 is an international standard for jurisdictions to implement rather than a directly binding PSP rule, while the EPC address-format requirements are payment-scheme rules for the covered EPC message flows. The overlap with binding obligations makes the scope of each requirement operationally important.

Related reading: G20 Cross-Border Payments Targets 2027

The dates a payment operations team should mark

Deadline urgency is the reason this topic matters, so the operative calendar comes first. These are the dates that govern the alignment work and the binding obligations that run beside it.

  • 26 February 2026: the CPMI publishes the updated harmonised ISO 20022 data requirements and the technical annex data models.
  • 22 November 2025: the Swift MT and ISO 20022 coexistence period ends, the point the requirements take as the baseline for message design.
  • End of 2027: the CPMI recommends payment system operators and participants align their ISO 20022 usage guidelines with the requirements, and commits to maintain the requirements at least until this date.
  • 15 November 2026: the currently effective EPC payment scheme rulebooks schedule the end of unstructured addresses for covered messages; following Swift’s 27 August extension of its own structured-address migration timetable, firms should monitor EPC communications for any corresponding timetable change before acting on the Swift postponement.
  • 18 June 2025: the FATF publishes its revised Recommendation 16 on payment transparency, which the CPMI data model is built to support.
  • End of 2030: the date by which FATF expects countries to be ready to implement the revised Recommendation 16 changes.

The end-2027 date is a recommendation from a standard-setter, not a statute. The end-2030 FATF date is an implementation horizon for an international standard: FATF expects countries to be ready to implement the changes by then, while binding firm-level obligations depend on implementation through the applicable jurisdictional framework. Keeping those two apart in a project plan distinguishes a voluntary data-quality target from an applicable compliance obligation.

Why the CPMI reopened a report it published in 2023

The original harmonisation requirements were developed by a joint task force of ISO 20022 experts from the CPMI and the industry Payments Market Practice Group (PMPG), and went to the G20 in October 2023. Three developments since then prompted the refresh. Payment systems kept migrating to ISO 20022, so the requirements needed to reflect the world after the MT coexistence period had closed. Market participants asked for clarification on points where the 2023 text left room for interpretation. And the CPMI moved the detailed data models into a standalone technical annex, so they can be updated in line with the ISO 20022 yearly release schedule without reopening the whole report.

Governance changed too. In 2025 the CPMI established the Harmonisation Panel for ISO 20022, a panel drawn from the global ISO 20022 market practice groups, to review the requirements, encourage adoption, and keep the data models from going stale against evolving practice. A separate Payments Interoperability and Extension (PIE) industry task force tracks how market infrastructures are aligning, publishing its own reports on ISO 20022 harmonisation. For an operations team, the practical read is that the requirements are now a maintained artifact with a named owner, so the field-level detail in the annex can be updated with each ISO 20022 release and kept current.

One reading to correct early: the February 2026 report is an overarching data layer that the CBPR+, HVPS+ and IP+ market-practice groups are urged to incorporate into their own guidance. It coordinates them without displacing them. CBPR+, HVPS+ and IP+ remain separate market-practice guidance frameworks for their respective communities. The CPMI urges those groups to incorporate the harmonisation requirements into their guidance rather than treating the harmonisation requirements as a replacement.

What “not a regulatory requirement” actually means for the build

Implementation is voluntary for individual entities and for transmitting cross-border or domestic payments. The CPMI says non-conformance with these requirements would not, by itself, result in a payment being rejected, but such payments are likely to face reduced efficiency and a greater risk of failure or delay. The report does not guarantee that a non-conforming payment will settle, because rejection or failure may arise for other reasons.

That framing makes the work worth front-loading. Because there is no hard cut-off, the temptation is to let the work slip behind items with a supervisor and a penalty attached. Several requirements overlap with obligations that do carry legal force, so coordinated data work can serve both. Structured party data supports the requirements and the FATF transparency standard. A restricted character set can reduce delays and returns, while a common time convention reduces ambiguity in time-sensitive processing. Elements that are voluntary only under the CPMI framework can be sequenced with the wider ISO 20022 data-model work only after applicable network and scheme requirements have been checked. Swift requires UETR for covered payment instructions, while the CPMI notes that extending UETR generation and transmission end to end can still entail cost and effort.

The report also anchors the requirements to a presumed future state, meaning the point after the MT and ISO 20022 coexistence ended. During the coexistence period, usage guidelines allowed compromises such as continued use of unstructured data. The CPMI’s position is that those compromises are no longer needed in the cross-border space, so a firm still leaning on them is carrying temporary workarounds past their expiry.

The core message set: nine ISO 20022 messages in scope

The requirements apply to a defined core set of interbank ISO 20022 messages, listed in Table 1 of the report. Credit transfers use pacs.008 (customer credit transfer), pacs.009 (financial institution credit transfer) and pacs.002 (payment status report). Payment returns use camt.056 (payment cancellation request), camt.029 (payment cancellation response) and pacs.004 (payment return). Payment investigations use pacs.028 (payment status request), camt.110 (investigation request) and camt.111 (investigation response). The set deliberately reaches beyond credit transfers to payment returns and other payment-exception processes.

Requirement 1 asks firms to use the appropriate ISO 20022 message for a specific business function, in line with the scope the standard defines. The concrete failure it targets is worth naming, because it is a real one: instead of implementing pacs.004 for a return payment, some markets send a regular credit transfer such as pacs.009 with proprietary coding bolted on to signal that this is really a return. Any institution operating across those markets then has to decode the actual function from the proprietary coding, work the correct message type would have made unnecessary. Using the message the standard intends removes that guesswork.

A second group of messages informs the harmonised data models without sitting in the core set. These are customer-to-bank initiation messages, including pain.001 (credit transfer initiation), pain.013 and pain.014 (request for payment and its response) and camt.055 (customer-to-bank cancellation request). They are not interbank messages, but the quality of the data a customer supplies at initiation determines how clean the interbank leg can be, so the annex documents harmonised models for them too. For bank-to-customer reporting messages such as camt.052, camt.053 and camt.054, the requirements identify only the data elements that need to be reported to the debtor or creditor for a cross-border payment.

The twelve general requirements, grouped by what they fix

The report proposes twelve general requirements that apply to every message in the core set. It sorts them into three families, and the grouping tells you what each family is trying to buy.

Fundamental requirements (1 to 4)

These set the ground rules for message use. Requirement 1 is the correct-message-for-the-function point above. Requirement 2 asks firms to use ISO 20022 externalised codes over locally defined proprietary codes, so that, for example, the purpose code PENS unambiguously identifies a pension payment to every party in the chain. Requirement 3 restricts the character set to the currently agreed Latin set, lower-case a to z, upper-case A to Z and numerals 0 to 9, complemented by a limited set of special characters allowed under the CBPR+ usage guidelines. Requirement 4 asks for a common time convention, either Universal Time Coordinated or local time with a UTC offset. These requirements primarily standardise message choice, codes, character sets and time conventions; implementation effort varies by requirement.

Transparency requirements (5 and 6)

Requirement 5 asks every cross-border payment to carry a unique end-to-end reference, the unique end-to-end transaction reference (UETR), defined under the technical standard RFC 4122 version 4. Because a UETR is generated through a decentralised algorithm, no central authority has to issue it, which is why it scales across the whole payment population. Requirement 6 asks for transparency on amounts, currency conversions and charges: the payment should carry the amount and currency instructed by the payer, any currency conversion applied to it, and any charges deducted by financial institutions along the chain, all carried unchanged end to end except for the interbank settlement amount. The report is careful on scope here, noting in a footnote that the current agent can only see charges already applied upstream, so requirement 6 does not ask the first agent to gather every downstream fee before initiation.

Data structuring requirements (7 to 12)

This is the family that touches the most fields and drives the most build. Requirement 7 asks for unique account identifiers to the extent possible. Requirement 8 asks that all financial institutions be identified through the business identifier code (BIC), defined in ISO 9362, with the legal entity identifier (LEI), defined in ISO 17442, encouraged as a complementary identifier. Requirements 9 and 10 ask that all entities and all persons be identified in a standardised and structured way using the ISO 20022 Party data model. Requirement 11 asks for a common minimum level of structured postal address. Requirement 12 governs remittance information. The sections below take the ones with the sharpest operational edges in turn.

Structured party data: where false positives are made or avoided

Requirements 9, 10 and 11 are the heart of the data-structuring work, and they share one rationale. Legacy messaging combined a name and an address into a single free-format field, which makes automated screening harder and throws off false positives that need manual clearing. Screening a bulked text block against a sanctions or AML list generates hits that a structured field would not. So the requirements ask firms to carry name and address in the explicit structured elements the ISO 20022 Party model provides.

For postal address, the report sets a common minimum of Country and Town Name, and recommends complementing those with Street Name, Building Number and Post Code to the extent possible, since applicable law along the chain may require them. A free-format Address Line remains available for anything that will not fit the structured attributes, but the report positions it as a secondary option. For persons, requirement 10 adds date of birth to the minimum, and where a full date of birth is not available, the year of birth alone is acceptable, though carrying only the year requires a change to the global ISO 20022 message standard.

This is the point where the CPMI’s market-practice recommendation meets a payment-scheme deadline. Under the currently effective 2025 EPC payment scheme rulebooks, the unstructured address format is scheduled to cease from 15 November 2026 for the applicable EPC scheme messages, and unstructured addresses would lead to rejects where those rules apply. Swift extended its own structured-address migration timetable on 27 August 2026; its November 2026 requirement has been postponed to Q1 2027. The EPC payment scheme rules are independent of the Swift timetable; firms bound by EPC scheme rules should continue preparing against 15 November 2026 unless and until the EPC separately announces a change. Monitor EPC communications for the current scheme position before adjusting project plans. Our guide to the SEPA structured-address deadline sets out that obligation in detail. For the EPC messages to which the 15 November 2026 rule applies, firms must ensure that address data are transmitted in structured or hybrid format; merely having structured-address capability does not itself satisfy the scheme requirement. The same data work also supports CPMI requirement 11.

Identifying institutions and accounts: BIC, LEI and the proxy question

Requirement 8 is frequently over-read. It requires financial institutions to be identified through the BIC, which comprises eight or eleven characters, with the eleven-character form used where branch-level identification matters. It encourages the LEI as a complementary identifier to the BIC, without mandating it. The Harmonisation Panel acknowledges that existing market practice and adoption rates require at least the BIC, while regarding the LEI as an additional identifier that brings benefits. Reading requirement 8 as an LEI mandate for every institution overstates it.

Requirement 7 sits alongside this on the account side, asking for a structured account identifier, or a proxy identifier for the account, where one is available, to support straight-through processing and cut misdirected payments. The report expects the impact to be limited because most payments already carry account identifiers; the effort falls on jurisdictions and entities that do not yet use unique account identifiers. For entities such as corporations, the report recommends complementing the name and postal address with a BIC or LEI where the extra information is available through the BIC directory or the GLEIF LEI database. Correct account information reduces returns and misapplied payments, while standardised financial-institution identifiers facilitate validation, routing and screening and can reduce costly late rejections.

Remittance information: the 140 versus 9,000 character split

Requirement 12 is the one most likely to surprise a corporate reconciliation team, because it puts hard numbers on how much remittance data a cross-border payment can carry. The harmonised data models allow remittance information to take one of two forms. It can be a single occurrence of up to 140 characters of unstructured, free-format remittance information. Or it can be multiple occurrences of structured remittance information of up to 9,000 characters, excluding XML tags. Where the information travels separately from the payment, the payment can instead reference it.

The reason the split matters operationally is reconciliation. Proprietary standards often either did not carry structured remittance information at all or capped its size, which forced end customers to match payments to invoices by hand. The CPMI says automated reconciliation by end customers can improve transparency and indirectly reduce cross-border payment costs; the structured remittance option supports that objective. The report flags a caution on the separate-reference route: sending remittance information apart from the payment can itself trigger delays because of the lost transparency, and using hyperlinks may need specific approval from relevant authorities or common market standards to manage the security implications. The pragmatic reading is that structured, carried-with-the-payment remittance data is the target state, and the reference route is a constrained fallback.

How the requirements ride alongside FATF Recommendation 16

A key adjacent international standard is the revised FATF Recommendation 16. It is not, by itself, a directly binding firm-level rule; binding obligations depend on implementation through the applicable jurisdictional framework. The FATF agreed changes to Recommendation 16 at its June 2025 plenary and published the revised standards on 18 June 2025. Under revised Recommendation 16, countries may adopt a de minimis threshold for cross-border payments or value transfers no higher than USD/EUR 1,000. Above the applicable threshold, the standard calls for specified originator and beneficiary information; where the originator and/or beneficiary is a legal person, this includes, where it exists, the connected BIC, LEI or unique official identifier. FATF expects countries to be ready to implement the changes by end-2030. FATF published draft implementation guidance for consultation on 24 June 2026; that consultation closed on 21 August 2026.

The CPMI designed its person and entity data model to be identifier-neutral and aligned with these updated expectations, so that institutions preparing for structured party data under the harmonisation requirements are also building toward the revised FATF Recommendation 16. Prioritising requirements 9 and 10 follows from that alignment: the same structured-data work supports the CPMI’s end-2027 market-practice target and preparation for jurisdiction-specific implementation of revised FATF Recommendation 16 under FATF’s end-2030 implementation timetable. Because FATF Recommendation 16 is an international standard rather than a directly applicable rule, firm-level obligations depend on each jurisdiction’s implementation. FATF permits most requirements on financial institutions to be introduced through law or other enforceable means, so compliance functions need to track the applicable domestic implementation and effective dates jurisdiction by jurisdiction.

Who owns adoption, and how the market is tracking

Alignment requires the whole ecosystem to move together. The report leans on payment system operators and financial institutions to lead, with the existing market-practice groups, CBPR+, HVPS+, IP+ and the Common Global Implementation Market Practice (CGI-MP), urged to fold the harmonisation requirements into their own guidance during the two-year window. The Harmonisation Panel provides the maintenance framework, and the PIE task force continues to engage payment system operators globally on their alignment.

The monitoring data show momentum but uneven progress. By the CPMI’s 2025 cross-border payments monitoring survey, around 19% of the 57 fast payment systems and 13% of the 80 real-time gross settlement systems covered were already aligned with the harmonisation requirements, with a further 12% of fast payment systems and about 25% of RTGS systems planning to align. Regionally, systems in the Middle East and Africa were most likely to implement them. Adoption of the underlying standard is well ahead of alignment with the harmonisation requirements: 79% of both RTGS and fast payment systems had implemented ISO 20022 or held concrete plans to do so by 2027. The gap between adopting ISO 20022 and using it consistently is exactly the gap these requirements exist to close, and it is why the CPMI frames widespread, consistent implementation as the condition for the benefits to appear at all. Migration to ISO 20022 is the easier half of the task, as the parallel ECB T2 extended-hours roadmap and the broader SEPA instant payments framework both show; using the standard the same way everywhere is the harder half.

Frequently Asked Questions

If the harmonisation requirements are not mandatory, can a supervisor still expect us to follow them?

The CPMI is explicit that the harmonisation requirements are not regulatory requirements and that non-conformance with them would not itself cause a payment to be rejected. Any binding firm-level obligation must instead be traced to the applicable domestic legal or enforceable framework or to the relevant payment-scheme rules. Revised FATF Recommendation 16 is an international standard requiring jurisdiction-specific implementation, while the EPC payment-scheme rulebooks bind participating PSPs through the scheme framework. Firms should map those obligations independently and address binding data-quality requirements first.

Do the requirements apply to domestic payments?

No. The CPMI states that implementation is not mandatory for domestic payments, and the requirements are framed for the cross-border leg. The report notes that even where proprietary formats are retained for domestic payments, ISO 20022 design practices and the harmonisation requirements can guide the evolution of domestic formats to prevent data truncation when those payments cross a border.

Does requirement 8 mean every institution now needs an LEI?

No. Requirement 8 identifies financial institutions through the BIC and encourages the LEI as a complementary identifier. The Harmonisation Panel acknowledges that current market practice requires at least the BIC and regards the LEI as an additional, complementary identifier without making it a universal requirement.

What happens to remittance information that exceeds 9,000 characters?

The harmonised data models allow structured remittance information of up to 9,000 characters, excluding XML tags, or a single unstructured occurrence of up to 140 characters. Information beyond those limits would need to travel separately from the payment with a reference carried in the message, a route the report flags as prone to delay and, in the case of hyperlinks, potentially subject to specific approval from relevant authorities.

How does a UETR differ from the transaction identification we already send?

The UETR, defined under RFC 4122 version 4, is generated by a decentralised algorithm to be globally unique end to end, giving it the ability to track and reconcile a payment across the whole chain and simplify exception and investigation handling. The transaction identification commonly used does not carry that same uniqueness guarantee across all cross-border payments and all involved entities.

Will upgrading to a new ISO 20022 release force us to rebuild the harmonised data models each year?

Not automatically. ISO 20022 messages are maintained yearly, and whether a new release changes the harmonised data models depends on whether the new elements are relevant to cross-border efficiency and whether best practice has evolved. Each jurisdiction decides whether to upgrade in a given year based on whether it has identified a need and whether the changes can be accommodated while preserving data integrity.

Key Takeaways

  • Align ISO 20022 usage guidelines with the CPMI harmonisation requirements before the end of 2027; the requirements are maintained at least until that date.
  • Read the requirements as voluntary market-practice guidance: non-conformance would not, by itself, cause rejection, but it increases the risk of repair, delay and failure.
  • Scope the work against the nine-message core set: pacs.008, pacs.009, pacs.002, camt.056, camt.029, pacs.004, pacs.028, camt.110 and camt.111.
  • Prioritise structured party data (requirements 9 and 10), because the same fields support preparation for revised FATF Recommendation 16, which FATF expects countries to be ready to implement by end-2030 through their applicable domestic frameworks.
  • Build structured postal address once to support requirement 11 and the covered EPC scheme messages. Continue preparing against 15 November 2026 under the EPC payment scheme rules unless and until the EPC separately announces a timetable change; monitor EPC communications following Swift’s 27 August postponement.
  • Carry remittance information as up to 140 characters unstructured or up to 9,000 characters structured, excluding XML tags, and prefer the carried-with-payment route over a separate reference.
  • Identify institutions by BIC (ISO 9362); the LEI (ISO 17442) is encouraged as a complementary identifier.
  • Carry a unique end-to-end transaction reference (UETR) under RFC 4122 version 4 on every cross-border payment.

Sources and References

What to put in the 2026 project plan

The harmonised ISO 20022 data requirements carry an end-2027 alignment target and the weight of market-practice consensus. Non-conformance with the CPMI requirements would not, by itself, cause a payment to be rejected, but some of the same data fields are also subject to separate legal, regulatory, network or payment-scheme requirements with their own implementation dates. For a payment operations team, the next concrete step is to map current message practice across the nine-message core set against the twelve general requirements, flag every gap that also breaches a binding obligation, and sequence those gaps ahead of the discretionary ones so the same build clears both.

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.

Similar Posts