Last April [1], Mark Sutton, Senior Manager, Corporate Treasury Advisor, Zanders, questioned the proposed industry logic that would require corporates globally to provide a full structured address as part of the adoption of the new XML Version 9 payments message. The article included an online survey to assess the potential impacts. Today, Zanders shares a status update as well an invitation to join a corporates-only working group that aims to become a single unified voice on a vexing topic.
The SWIFT MT to MX migration starts its three-year adoption plan in November 2022 within the interbank payments messaging space. This means SWIFT will be moving from the traditional MT-based messages, initially in the cash management space, onto ISO 20022 XML messages. It’s this migration that is introducing a requirement to adopt the XML Version 9 payment message – pain.001.001.09.
Arguably the most important point for corporates to be aware of as part of this forthcoming industry migration is the move towards explicit usage of the structured address block.
The TMI poll results – what is the potential impact?
The 2021 online poll comprised two main questions:
1: Do you currently merge the building number, building name, and street name in the first line of the address?
We received 46 responses to the snap poll and 70% confirmed they currently merge the building name, building number, and street name in the same address line field. The key point to note is that the data is not currently separated.
2: What is the impact of this change (High/Medium/Low)
This second question applied only if the respondent answered ‘yes’ to the first question, and this was available to TMI readers only on the website and not on social media platforms such as LinkedIn. This question received 19 responses and 52% highlighted a high impact to change this data, while 26% highlighted a medium impact.
If these numbers are extrapolated, this demonstrates that such a change could be a major issue for corporate clients globally.
So, what does the potential impact look like at corporate level? As part of Zanders’ continued research into this topic, the company spoke to two major corporates in a bid to gain a better sense of their concerns. Both provided a high-level estimate of the development effort required on their sides, thus offering a better sense of the potential reality.
The testing element of this proposed change is also significant because it will be necessary to test across all the company codes and different types of payments, which should be validated with all the banks in scope. Testing with banking partners should not be underestimated because this is typically viewed as a new project, which requires a statement of work and configuration of the test environment. This alone would take weeks to perform and would raise resource challenges for corporates as well as banking partners.
The above provides some perspective around the potential implementation challenges facing corporates. But the impact of this change is not just limited to this sector. Banks typically offer proprietary regional and global file formats that corporate clients use to make payments. The majority of these file formats are flat files (comma separated values and delimited files) that currently do not support a fully structured address logic. As part of this industry initiative around urgent domestic and cross-border payments, banks will have to update these legacy proprietary file formats, in addition to being able to accept the required fully structured address.
Who is driving this change?
While a logical question, it is proving challenging to identify the source. The Committee on Payment Market Infrastructures (CPMI) has merely stated its role in the implementation of the G20 Roadmap to enhance cross-border payments, which is still work in progress. And although one of the building blocks is working on a harmonised XML ISO 20022 version for message formats (including rules for conversion/mapping), they do not appear to be driving this specific industry requirement. Separate discussions with the Bank of England referenced its December 2020 policy statement that concluded there were strong benefits for requiring addresses to be in a fully structured format to remain aligned with international market practice. However today, as the majority of corporates will attest, the first line of the address is typically blended, as the underlying systems do not actually currently support a fully structured address. So, the mystery continues.
What needs to happen?
The following extract from structured address logic available in the XML Version 9 payment message for the first line of the address shows that it does not support all the UK requirements.
Consider the valid example – 12 Phoenix House, 18 High Street. Today, all this Line 1 address information would be populated in the <Street Name> tag. But with the new fully structured address requirements, there is a snag within the current available XML structure:
There is no structured tag for the street number. So logically, before any mandatory validation and rejection of payment message can be implemented for non-compliance of a fully structured Line 1 address, an ISO change request is required to update the address block on the relevant XML messages. Given the standard maintenance cycle, the earliest this change could be implemented would be 2023 and this would be reflected in the pain.001.001.13. Therefore Version 13 will be required.
While this would probably have an adverse impact on the proposed adoption of the Version 9 message, recognising that the required mandate information for RTP functionality is available only in Version 10, tokenisation/proxy is fully supported only in Version 11. Ukraine has already taken the decision to adopt the latest available version for its new clearing system, the wait for Version 13 in 2023 would provide a more resilient, robust message that would better serve the industry requirements.
The second challenge reflects the fact that the majority of software vendors are currently not supporting a fully structured address for the Line 1 compliance. This will require change from the ERP vendors, such as SAP and Oracle in addition to TMS providers such as FIS and Kyriba. Based on the current MT-MX migration timelines, this will need to be completed well ahead of the current November 2025 end date to allow time for the corporate community to manage its changes.
A cause for concern?
The SWIFT Board Advisory Group – the Payments Market Practice Group (PMPG), which comprises various banks representing their communities, agreed with the CPMI in 2010 to support the implementation of the structured customer addresses. The large Real-Time Gross Settlement (RTGS) operators, with the support of the PMPG, are now taking the lead towards mandating structured addresses.
However, the devil is always in the detail and this research has hopefully highlighted some genuine concerns around the current industry proposals. At present, from November 2025, incorrect formatting of the structured address can result in the rejection of a payment instruction.
Next steps
Zanders is proposing forming a corporates-only working group to discuss this issue in further detail with the sole objective of then holding a joint call with the SWIFT PMPG. The purpose of this call would be to provide a united voice from the corporate community around the concerns and major impact of this structured Line 1 address change. Representatives of corporates interested in joining this working group should contact Mark Sutton by email on [email protected].
Mark Sutton
Senior Manager, Corporate Treasury Advisor, Zanders
Recognised as an SME in the shared service centre, emerging technologies, and banking integration space, Mark has over 34 years’ experience gained within cash management from a sales, product, project, and consultancy perspective. Mark also has significant industry experience, gained through his leadership roles in both UN/CEFACT TBG5 and ISO TC68 SC2 and is a founding member of the Common Global Implementation Market Practice Group and part of the original XML version 3 design team back in 2008.
