As ISO 20022 moves into its next phase, unstructured postal addresses will be phased out in favour of hybrid and fully structured formats by November 2026. XMLdation explores how banks and corporates must now work together to ensure files are populated correctly, maintain straight-through processing, and meet evolving CBPR+ requirements
The end of Swift’s co-existence period is a significant marker in the ISO 20022 journey, but for many it represents only the end of the beginning. The true purpose of the migration is to unlock the value of richer, more granular structured data – improving transparency, strengthening compliance checks and enabling higher straight-through processing.
The next step on this path is the retirement of unstructured postal addresses in favour of hybrid and fully structured formats by November 2026. Unlike previous phases, which centred largely on interbank readiness, this transition will also require substantial participation from corporates. Banks must not only update their own systems and support the new fields but also guide – in some cases – tens of thousands of clients to correctly populate address components in their payment initiation files. Without this, rejection rates will rise, and straight-through processing will suffer.
Corporate readiness varies widely. Some already operate in ISO 20022 and need only to adapt how they provide address fields in a new way, some corporate clients may still rely entirely on legacy MT files and are only now beginning their migration.
So, what can banks do to manage testing at scale for both ends of this readiness spectrum?
Starting November 2025, a new postal address format – Hybrid Address – will be introduced in payment file messages. This marks a key step toward enhancing data quality, processing efficiency, and regulatory compliance in payment messages.
The new format is a blend of structured postal address elements, with TownName and Country as the minimum requirements, combined with the old AdrLine element. The older formats, such as pain.001.001.03, support fewer postal address elements than the pain.001.001.09, but both will support the use of hybrid addresses.
Figure 1: MT vs Unstructured, Hybrid and Structured ISO 20022
Hybrid addresses are needed for the transitional period of going from unstructured postal addresses to the fully structured format. In practice, this means replacing the free text, unstructured postal address with a format that uses only structured postal address elements. The transitional period allows the banks and other financial institutions to adjust their payment file messaging systems. As of November 2026, the use of unstructured postal addresses will no longer be permitted (see Figure 2).
Figure 2: Transition period timeline
Currently, we’ve seen customers take different approaches to introducing the hybrid address in their payment messages. Some are applying stricter formatting rules – for example prohibiting duplicate information in the AdrLine when it is already captured in the structured elements. Others are taking a more flexible approach by not restricting the use of AdrLine element,while gradually encouraging the use of structured data.
Regardless of the approach, one common factor remains: to ensure a smooth transition to the new formats, banks need to provide clear guidance to their end corporate clients. Sharing example files is a quick way to highlight the differences between formats – and test tools such as XMLdation’s Payment File Testing product offer an interactive way to share, refine and validate client files to ensure the new formats are applied correctly.
But what does this look like in practice? The screenshots below from XMLdation’s Payment File Testing product show examples of how the tool flags errors and supports corrections, as well as how the CBPR+ 2025 guidelines can be applied correctly.
Example 1:
In the example below, a corporate customer using the XMLdation Payment File Testing product has populated the postal address using an unstructured format. The tool detects the old format, explains how to correct it, and includes a notice that unstructured addresses will not be permitted in the future.
The corporate can then make the necessary corrections and re-validate the message. Below is the final, correctly structured hybrid postal address (with TownName and Country as the minimum requirements):
Example 2:
In this example, the hybrid address includes too many AdrLine elements, and information already present in the structured postal address is duplicated in those lines. While some customers permit this, common guidelines such as CBPR+ do not. Again, the tool flags these errors and provides clear guidance on how to correct them in line with CBPR+.
Below is an example of a correctly structured postal address, as per the CBPR+ guidelines:
Need help testing structured and hybrid addresses? XMLdation’s Payment File Testing product is designed to support banks and corporates through a smooth transition.
Reference: