The ACT Cash Management Conference in March represented a welcome return to face-to-face events and, given the forthcoming SWIFT MT to MX migration, which starts its three-year adoption roadmap in November 2022 within the interbank payments messaging space, it was no surprise to see this on the agenda.
This migration will see SWIFT migrate from the traditional MT-based messages, initially in the cash management space, onto ISO 20022 XML (MX) messages. It’s this migration that will ultimately ripple through to corporate treasury to also synchronise through the adoption of the XML Version 9 payment message – pain.001.001.09.
Whilst the event recommended that corporate treasury start the dialogue with their banking partners around the impact and options available as part of this MT to MX migration, one key aspect that was not highlighted was around forthcoming mandatory structured address block.
What is different about the ISO 20022 structured address block?
To be honest, the only real change to version 3 message that has become the de-facto standard in corporate to bank financial payment messaging is the addition of the building number tag. However, it’s not so much about the structure of the address block, it’s more about the forthcoming mandatory requirement for corporates to provide a full structured address at some point before November 2025.
Let’s consider a real-life example.
In the UK, we have the following first line of the address: 12 Phoenix House, 18 High Street.
Today, all of this Line 1 address information would be set-up under the address line 1 field available in the Enterprise Resource Planning or Treasury Management System as part of the vendor or customer set-up. When a payment is generated, this first line address information is generally mapped to a corresponding unstructured address line 1 field in the agreed payment file format. In XML terminology, this would all be populated in either the street name or address line 1 tag.
However, with the full structured address requirement, the corporate will need to populate each of the above data points in the correct XML tag and failure to do so, will result in the payment message being rejected by your banking partner for non-compliance. For corporates that are making payments to the USA or Canada at the moment, they will already be familiar with the requirement for full address data and the associated impact of non-compliance. However, this current requirement has less structure given the limitations of the SWIFT MT101 Tag 59 which covers the beneficiary account number, beneficiary account name and beneficiary address.
But with the new fully structured address requirements, there is a snag within the currently available XML structure:
The first challenge
There is no structured tag for the street number. So this presents the first challenge. Before any mandatory validation and potential rejection of payments can happen, there needs to be a further update to the current structured address block. Based on the ISO annual maintenance cycle, a formal change request needs to be submitted by June 2022 latest. If accepted, this will be incorporated into the next version, which will be version 13 (pain.001.001.13) and released as part of the April 2023 ISO standards release.
This type of change request could derail the current MT-MX roadmap as it would force banks to delay implementation until the new version was published as there would be a material difference between the current version being adopted and the proposed version 13 message. Now whilst some within the industry might suggest a workaround by simply merging this data point in another field, that actually goes completely against the initial argument for full structured data, meaning each data point should have its own separate and unique XML tag. If merging of data is now being suggested as a workaround, surely the logical workaround is to simply continue to allow the first line of the address as it is today.
The second challenge
At the moment, the majority if not all of the software vendors globally are not supporting a fully structured address for the address Line 1 compliance. Indeed, from a vendor standpoint, they actually need to exactly mirror the above full structured address including the existing field length. A relevant example is the name field, which would need to now support up to a maximum of 140 characters to avoid the current practice of name extension using the first line of the address. The software vendors upgrades will then need to rolled out to the respective corporate customers which will then need to complete the data clean-up exercise. Can all this realistically be completed by November 2025?
Is this really an issue for corporates?
Last year, Zanders ran a short survey through TMI (just two questions) to get a pulse check on the potential impact:
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.
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.
What is the potential corporate impact of this change?
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.
For such a perceived small change, these numbers are significant and they exclude the associated and required testing element, which will also be significant. The scope of the testing will need to span both company codes and payment methods, which will also involve banking partners – so you will need to plan for weeks of testing.
In summary
What is perceived by some as a minor or acceptable change, forcing the use of the full structured and specifically the line 1 will represent significant impact to a large number of corporates, globally. This potential friction can be significantly reduced by simply ‘fine tuning’ the current thinking and to allow the line 1 address to be provided in a single field – either street name or address line within the current version 9 messaging standard. This would minimise the system level changes as well as the impact on master data cleansing within the corporate community and would still allow for effective screening to be completed.
About the author
Mark Sutton is a senior manager at Zanders and leading their response to ISO 20022 transition. You can contact him at m.sutton@zanders.eu.
