In a TMI article in April 2021[1], Mark Sutton, Senior Manager, Corporate Treasury Adviser, Zanders, questioned the banking industry’s logic of requiring 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. Last March[2], he provided an update on the industry discussions. This article completes the trilogy with a final eye-opening update on the likely outcome if a pragmatic approach is not adopted with financial XML messaging.
The story so far
SWIFT will finally start its MT to MX migration within the interbank payments messaging space in March this year. This will see SWIFT move from traditional MT-based messages onto ISO 20022 XML messages. Arguably the most important point for corporates to be aware of is the move towards explicit use of the structured address block.
While it was initially unclear who was actually driving this change, a full structured address does deliver material benefits in terms of AML/compliance validation when compared with the current fully unstructured model. However, there are some significant impacts for the global corporate community, if the full structured address becomes mandatory as part of the SWIFT migration.
The SWIFT PMPG[3] (Payment Market Practice Group) has advised that their dialogue with the in-country real-time gross settlement (RTGS) operators (the Federal Reserve, the European Central Bank and the Bank of England [BoE]) all plan to mandate the full structured address with the SWIFT ISO migration. Furthermore, the BoE confirmed in its December 2020 policy statement that there were strong benefits for requiring addresses to be in a fully structured format to remain aligned with international market practice. Nevertheless, today, the only international market practice around the first line of the address is to use an unstructured option due to the significant complexity that exists globally around this address line 1.
In March 2021, despite serious concerns being raised by the Common Global Implementation - Market Practice Group[4] (CGI-MP) around the proposed full structured address, the SWIFT PMPG advised that the plan was to reject non-compliant cross-border payment messages from November 2025. This strong position was again communicated during the September CGI-MP plenary session, which the SWIFT PMPG attended.
Finally, SWIFT has also separately advised that there is a stake in the ground to remove the unstructured address elements from both the debtor and creditor address blocks by 2025. While this has not been formally agreed within the industry, this position clearly highlights the aspirations within SWIFT.
Current challenges and outstanding questions
What we have are multiple issues that are all interconnected and need to be addressed if the industry is to achieve its stated objective of a full structured address. Let’s consider the various challenges and associated impacts that currently exist as the industry embarks on the journey towards a mandatory full structured address.
1. Is this a quick and simple change?
The results of the 2021 online TMI poll highlighted that 70% of respondents 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. Furthermore, 52% of these respondents 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, we spoke to two major corporates to gain a better sense of their concerns. Both provided a high-level estimate of the development effort required for them to adapt to the new standard: €500,000. While corporates will always find the money to support a compliance change – even during a recession – this does look like a high-impact change.
2. Does the new XML message support the full structured address?
From recent industry discussions, and recognising the ISO expert group is now looking specifically at the composition of the existing structured address block, it is being acknowledged that the proposed XML Version 9 message (pain.001.001.09 customer credit transfer) cannot support the known complexity that exists around the first line of the address. The following example of a new industrial estate in Malaysia highlights both the complexity and the current gaps within the existing design.
Company Name Level 1 Tower 2 Avenue 3 Horizon Bangsar South City No.2 Jalan Kerinchi 12345 Kuala Lumpur
The current message design does not support the Malaysian country-level requirement of multiple street names, which clearly apply within an industrial estate model and would be set up as part of the master data. Apartment (or Suite) has also been identified as a gap that will now be incorporated into the next message version scheduled for release later this year.
Focusing on the corporate impact, each one of these data points would need to be provided in a separate dedicated field and this would also include separating the street number from the street name as these must not be merged under the proposed new mandatory rules.
3. Do the ERP and TMS vendors currently support a complex full structured address?
While we have not researched every ERP and TMS system, if you compare the current structured address points including field length in the XML Version 9 message with the master data records currently available in the ERP and TMS systems, you will see gaps in terms of the fields that are supported and the actual field length. This is understandable given current market practice is to use at least the first line of the unstructured address option to support the complexity of the first line of the address.
This means ERP and TMS software vendors will need to update the current address logic to fully align with the ISO standard for payments – but this software development cannot logically start until the ISO address block has been updated to avoid the need for multiple software upgrades. From a corporate perspective, they will not be able to comply with the full structured address requirements until software providers have completed their upgrades. This means there will be potentially a significant time lag between the industry making the full structured address mandatory and corporates being able to fully comply. Reasonable time must be factored in because software upgrades take time and money.
4. Do the SWIFT PMPG industry guidelines help address these issues?
While industry-level implementation guidelines are always a positive step, from the industry conversations at the end of last year, this appears to have contributed to some of the confusion and possible misunderstanding within the banking community. The guidelines have primarily focused on the more simple mainstream address structures for which the current address structure is fine. By correctly including the more complex local country address options, it will quickly highlight the gaps that exist, which means compliance by the November 2025 deadline looks unrealistic at this stage.
The guidelines also include examples that allow the merging of data points – an example being HK where Block C, 350 Greenview Gdn is merged into the building name tag. Furthermore, the French community address structure guidelines permit the merging of the building number and street name – so we are already seeing inconsistencies around the agreed guidelines. Examples like these merely add to the current levels of confusion within the industry.
5. Have the payment regulators mandated the requirement for the full structured address?
At this stage, there is still no evidence that any of the in-country payments regulators have actually requested a full structured address. And given the challenges highlighted above around supporting a full structured address, could the industry achieve a much stronger level of validation through enforcement of the use of the Legal Entity Identifier (LEI).
The LEI is a unique global identifier for legal entities participating in financial transactions with the sole purpose of identifying the legal entities on a globally accessible database. This logic could be expanded to also include a national ID, which would then address the requirement for individual identification. The question here is: does this alternative (and possibly more pragmatic) approach represent a better fit than merely trying to fit a Western European address structure on to a global scale that creates a number of knock-on problems? Time will tell.
6. Is there enough time to achieve compliance by November 2025?
We must consider the above challenges that need to be addressed first, before full compliance can logically be considered. Industry discussions are still continuing and the next ISO maintenance release is November 2023. If we factor in time for banks to adopt this new version (XML Version 13), time for software vendors to develop the new full structured address including field length and, finally, for the corporates to then implement this latest software upgrade and test with their banking partners, then the November 2025 timeline looks unrealistic at the moment.
The real impact on corporate treasury
If you are a corporate making cross-border payments or if you are making domestic RTGS payments in one of the countries where the market infrastructure is already planning to mandate the use of the full structured address, you will be impacted. The size of the impact will depend on the number of systems you are running, the number of banking partners and the number of countries in which you are currently making payments.
What this industry change means is that from November 2025, you will need to provide all your address data points in the correct and dedicated XML field. Today, most corporates merge at least the first line of an address due to the complexities that exist at a regional and global level.
The knock-on effects for cash management banks
This appears to be another area of confusion and potential misunderstanding within the cash management banking community as it’s the banks that will need to validate the payment messages and ensure compliance. And this is exactly the same model that applies in the US and Canada today where inbound cross-border payments to the US and Canada must have the city, state, and zip code or the payment will be rejected by either the originating or beneficiary banking partner.
But the impact on the cash management banking community goes much wider than just the requirement to ensure full compliance. The banks typically offer their own proprietary banking file formats for corporates to make payments. These formats typically support only a limited full structured address, with unstructured being the common approach for the first line of the address. These bank proprietary formats will need to be upgraded. But a possible consequence of this industry initiative is that these formats might now become obsolete, as corporates take the decision to migrate to the de facto global financial messaging standard – ISO 20022 XML in order to standardise and simplify the corporate to bank messaging space.
The final major impact on banks is the multi-billion-dollar cost of supporting the associated corporate testing around the full structured address. This is global because it relates to all cross-border payments across all countries plus the domestic RTGS dimension. This single change around the mandated requirement for a full structured address will have a significant impact on the banking community as well.
Alternative solutions
Given the impact of this requirement, this might provide the opportunity for the fintech community to step up and step in with solutions that could potentially marginalise some players. The fintech industry is challenging the accepted norm across the full financial industry, and is increasingly focused on the infrastructure and data flows that support cross-border business.
Marcus Treacher, Board Member, RTGS.global, (https://rtgs.global) believes “as fintechs apply machine learning and artificial intelligence to the problem, they are solving for address ambiguity faster than the traditional players can agree and roll-out their address standard upgrades. They are also challenging the value of physical addresses to commercial transactions, relegating company addresses to meta-data associated with an LEI, or a Google Maps location. The risk to the industry is that a push to refine XML address information wastes money, causes problems for corporate with ‘non-standard’ address and ultimately proves quixotic as fintech solves these problems in new ways”.
Next steps for treasurers
The above provides some perspective around the challenges and impacts of this industry change, which is not currently being driven by the regulators. The benefits of proceeding from an AML/compliance perspective should really be weighed against the costs to the various stakeholders, in addition to the alternative opportunities that could also include simply allowing unstructured for the first line of the address and full structured for the logical city, region, country and post code. The extreme challenge is with structuring the highly complex first line of the address.
The next steps are now down to the corporate community at large. The first could be to discuss with your banking partners to understand the potential impact of this change, including whether they will protect you from any change by providing solutions that will automatically de-merge an unstructured address. This will provide relevant visibility to you as a corporate.
In parallel, the corporate community should review their current system landscape and master data set-up specifically around the address information. This will provide greater visibility around the potential impact and, importantly, financial cost of this change.