All Round the Houses

The Pain Points of the New ISO 20022 Structured Address Block

With Version 9 XML on the horizon, it is time to question the logic of mandating corporates to de-merge data only for banks to merge it again in the validation process. Here, we ask for your feedback to measure the potential impact of this update.

As part of the original ISO 20022 XML V3 design team back in 2009, its pleasing to note that this payment message has become the de facto standard in the corporate to bank space over the past 12 years. This success has largely been down to the collaborative work within the Common Global Implementation – Market Practice (CGI-MP) group. As a founding member of this collaborative industry group, it defined a series of implementation guidelines that established common principles aimed at removing some of the friction that existed around the corporate-to-bank integration space. The strength of this group was in the breadth and depth of collaboration, with representation from the banks, software vendors, consultants, payments associations, SWIFT and, most importantly, the corporate community.

However, there is now change in the air, with the much talked-about SWIFT MT to MX migration within the interbank payments messaging space. What this means is that 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, which is currently scheduled to take place from November 2022 to November 2025, that is introducing a requirement to adopt the Version 9 XML payment message (pain.001.001.09). The adoption of this version builds on the first major market infrastructure (TARGET2) to adopt the 2019 ISO standards release, which at the time was the latest version.

What does this actually mean?

While SWIFT is starting this migration to the 2019 version XML messages, it will ultimately become a much broader industry implementation. There is one very important point for corporates to be aware of as part of this forthcoming industry migration – the move towards explicit usage of the structured address block. This requirement has been driven by the Committee for Payment Market Infrastructures (CPMI), which is a sub-committee of the Bank for International Settlements (BIS).

But structured data is a good thing – right?

One of CPMI’s primary objectives is to improve cross-border payments globally, with standardisation and data quality being key to enable efficient end-to-end process including the due anti-financial crime (AFC) diligence on the flight of a payment (such as sanction and embargo screening, anti-money laundering and [AML] and counter-terrorist financing [CTF]).

The SWIFT Board advisory group – the Payment Market Practice Group (PMPG), which comprises various banks representing their community, agreed with CPMI back 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, to support the coexistence phase between MT and MX and to provide sufficient time for global industry to prepare for the change, structured address will be mandated by November 2025 only (with the sunset of some MT messages). Importantly, address attributes must be provided in the dedicated elements and not merged. From November 2025, incorrect formatting of the structured address can result in the rejection of a payment instruction.

The benefits of a full structured address

The ISO 20022 XML message was designed to support rich and highly structured data – the payment message has more than 940 separate fields. The address block provides a clear example of the comprehensive data fields available to uniquely identify each specific data point, without any ambiguity. Indeed, SWIFT has been at the forefront of payment message standards since the 1970s and fully supports the benefits of a full structured address.

Furthermore, with the increasing cognitive capabilities on the horizon, structured data will help everyone harness the power of the data analytics technologies. This will enable faster and more informed insights and better business decisions.

What are the considerations?

The devil is always in the detail and to understand the ‘potentially’ significant impact to the corporate community, we need to consider a fairly typical use case. Let’s consider a hypothetical vendor address: Phoenix House, 18 High Street. Today, the majority of corporates will set up this address in the first address line of their master data record as a merged value. Furthermore, and importantly, when they pass this information in the payment message, the merged value is contained in the street name tag of the XML payment message. And the bank will process without any problems.

However, with the above approach to the structured address, this actually represents three separate data points:

The PMPG, in its support of the CPMI objectives around the structured address, is stating that where provided, these three specific data points must go in the correct associated XML tag. As such, the key consideration for the corporate community is that they will not be allowed to be merge this information. The risk is that payments will ultimately be rejected where the above data is merged.  

What is the potential corporate impact?

Based on the experience of working with many varied corporates on the implementation of ISO XML, the potential impact of implementing XML Version 9 could be significant. Why? Because corporates will need to undertake an exercise to update and reformat their address information. In essence, they will need to separate the three data points in the above example and place them in the correct data field. This concern has been echoed by the corporates within the CGI-MP group and outside as well.

As a Treasury Process expert at a Global FMCG manufacturer explains: “Related to the type of the change, this in itself is not that complex (it can be done in a weekly drop), however due to the high number of company codes (800-plus) would make the change very complex because of the testing scope which should be performed. In terms of implementation this is definitely something which would take more than three months.”

There is also a consideration around the underlying system capabilities as a large number of enterprise resource planning (ERP) and treasury management (TM) systems do not currently contain a separate building name, building number and street name field. This becomes a system vendor dependency that will potentially form part of any critical path.  

Peter Klein, Chief Product Officer, FinLync, comments: “Structuring something like seemingly innocuous address fields may seem like the right thing to do, and likely is in a vacuum, but in the context of a highly integrated ERP [enterprise resource planner] environment, this can manifest as a highly complex undertaking and, in some client specific cases, may be even insurmountable. Keeping an unstructured approach makes it far easier from a global delivery perspective, especially when handling system dependencies for country address layouts and local languages.”

One final important consideration

It is always important to consider the full end-to-end process of any change. While there are clearly many benefits associated with structured data, including more timely and accurate data processing, we do need to consider the validation within the banking community. Structured address data will definitely help with earlier highlighted AFC obligation and this is important. However, if we purely consider the discussion around the first line of the address, – when they receive the de-merged data, the building name, the building number and the street name, they will then merge these values in order to perform the data validation exercise.

So, with this industry change that is coming, the corporate community is being asked to de-merge the first line of the address, for the banks to re-merge these data points for validation.

There are clearly pros and cons to this industry change and the objective of this article is to raise awareness within the corporate community and seek urgent feedback on whether this change will have a significant impact on current data set-ups. By participating in the snap poll below, you will provide increased visibility on the potential impact – data that will help with much-needed follow-up discussions.