ISO 20022: 2009 to 2019 Upgrade Considerations

Introduction

Here’s the scenario: your company is accepting payment instructions from clients via the channel of choice. It could be file transfer, API, Swift FileAct etc. The key factor is, not so long ago, you upgraded the client payment instruction format to ISO 20022, based on a pain.001.001.03 (payment initiation). That version, from 2009, has been extant for many years, is supported out-of-the-box by most ERP/TMS systems and is CGI-MP compliant. Your interface format is up to date, with a flexible, data-rich ISO 20022 message capability and your clients have all integrated. All is well.

Now here comes the 2019 version, the pain.001.001.09. If you are sending payment messages into certain schemes, such as SEPA Credit Transfer, according to the 2023 rulebook, you will need (at some point) to upgrade to the pain.001.001.09. Interbank messaging is aligned around 2019 (e.g. pacs.008.001.08) and for seamless data interoperability, other groups and practices will now align – CGI-MP is moving to this version and has published their UGs (see CGI-MP on MyStandards).

As interbank is migrating to ISO 20022 to support cross-border payments and cash management businesses from March 2023, CGI-MP message versions and guidelines are also updated [to 2019] to align with the interbank usage.

• CGI-MP WG1 User Handbook – Feb 2023 Update

Whilst you may have scheme or practice rules dictating this change, do your clients have needs that will be met by the upgrade? Changing the format of a client interface and the data they may need to provide is usually disruptive, not something you want to do often or without a detailed upgrade schedule, test and client communications plan. For the upgrade to 2019, in many use cases the client benefit may not be immediate or obvious, rather this is a foundation upgrade, with the potential for future benefits, such as e-remittance or alias capabilities. So, do you need to update your client payment format to 2019, what are the key considerations and what are some of the challenges and impacts?

Upgrade Approach

Unlike some of the earlier ISO 20022 message versions, 2009 to 2019 is largely backwards compatible, certainly for the pain.001. If contemplating your own upgrade, a practical option would be to follow the proven co-existence approach, via a 2-phase upgrade plan:

1. Interim Translation: Retain a client facing format based on pain.001.001.03 and map payments internally to 2019 (pain.001.001.09 or pacs.008.001.08 etc) before sending on.
2. Long-Term Native: In parallel and over time, build the pain.001.001.09 client facing format and migrate clients as and when ready.

The 2019 version is designed to support enhanced data. It is the origination and use of this data which needs careful planning to ensure it can be included in the flow as quickly as possible. A phased migration relies on understanding the enhanced data differences and whether you or your clients will benefit from this data, where the data will be originated and how to build it into your upgrade plan and product roadmap. Generally:

• If enhanced data is originated by your client, such as a corporate accounts payable department or an intermediary payment services provider, the interim translation approach will continue to limit the acceptance of this data, for example, there is no LEI field in a pain.001.001.03 so if originated by your client, it cannot be received. Other means of accepting the data will be required.
• Alternatively, if enhanced data can be derived, such as looking up the LEI or structured address from client reference data, the interim translation approach will work. You can derive the enhanced data and insert in into the onward pain.001.001.09 assuming of course, your master reference data has already been updated to support this. By implication, the updating of reference data is a likely a pre-requisite of any upgrade plan and may well be the most complex and time-consuming workstream.

Key Differences

2019 version sees changes to several existing data elements and, most importantly, several new elements. The following pictures, with pain.001.001.03 on the left and pain.001.001.09 on the right, illustrate the major, high-level differences in the base specification.

Supplementary Data

A supplementary data element has been added to the Customer Credit Transfer Initiation level and to each payment (Credit Transfer Transaction Information level). Usage guidelines (UGs) are rules designed to restrict the usage from the base specification. They specify a subset of the available base data and, in certain cases, business rules (cross-field rules) to be adhered to. By contrast, supplementary data is designed to expand the message beyond the base specification. Supplementary data is not widely used in the payments’ domain and beyond the scope of this article. It is unlikely to impact your upgrade and can be ignored. For more information on supplementary data and to see one of the few usages, go to the SCRIPS UG for camt.050.

Group Header

The only significant changes in the Group Header are those related to the postal address, organisation identification and contact details of the parties or agents. All 3 of these elements have new fields to support enhanced data and will be covered later in this article as they are reusable elements and apply to all parties and agents in the message.

Payment Information

On the debtor side, payment information element, there are a number of subtle changes, some of which are:

• Service Level. The service level can now have multiple occurrences rather than the single occurrence permitted in the pain.001.001.03. This allows a client to specify which of the available rules should be applied to the payment, specifically it can be used to select a wider range of payment product options but is more a future enhancement, once those product offerings are available, rather than something which will impact any migration.
• Requested Execution Date. This changes from only an ISODate to either an ISODate or ISODateTime. This feature aligns with the growing real-time payments and liquidity capabilities across the globe, where a future dated execution date can now be an exact time. For most use cases, there will be no client impact and can remain unchanged as an ISODate in the interim phase. Internally, for the interim solution, a remapping to ../ReqdExctnDt/Dt will be required.

• Proxy. The updated CashAccount38 element has a Proxy element, to cater for an alias/proxy identifier as an alternative assumed name for the account. This is a reusable component so occurs in every instance of an account not just debtor. The use of aliases for sending payments is growing rapidly, particularly in peer-to-peer transactions. India’s UPI and Brazil’s PIX are topical examples and SEPA is planning its own alias capability. If the proxy is something needed as part of the interim upgrade phase, you should consider updating your reference data source to derive alias names to work around the absence of this in the pain.001.001.03.

Credit Transfer Transaction Information

Keys changes in payment element include:

• UETR. The Unique End-to-End Transaction Reference is a new addition. This mirrors the inclusion of the UETR in the Swift MT standards release from 2021 (i.e. MT 103 Block 3 Field 121). The UETR is an important identifier in the payment chain and many market infrastructures and messaging services mandate its use (Swift CBPR+, SCRIPS). For both an interim and long-term solution, it can be generated and populated in the pain.001.001.09 if required. The origination of this by the ultimate debtor or debtor, such as a corporate, is not yet common practice given the EndToEndId usually serves their needs (see a previous article on EndToEndId for more details on this) and Swift gpi tracking, if used, can be presented from the point of the debtor agent processing the payment. If a Swift corporate requires full gpi tracking, they will generate the UETR and would need the long-term solution to be in place in order to pass in the pain.001.001.09.

• Postal Address. One of the most significant changes is the enhancement to the postal address. This applies to every occurrence, whether for a party (such as Ultimate Debtor in the picture below) or agent. The PostalAddress24 complex element has 6 additional fields, allowing a more granular structured address, to ultimately negate the use of unstructured Address Line fields. Certain scheme UGs already restrict or forbid the use of the unstructured Address Line fields. In the interim phase it is important to begin the journey to fully structured addresses – the minimum should be shaping your clients’ use of the pain.001.001.03, ensuring Town Name and Country are populated and avoid the use of Address Lines. See this earlier articleon structured addresses for more information.

• Legal Entity Identifier (LEI) & BIC. The 2019 version adds the LEI to the data model. The LEI is a unique identifier for an organisation. It does not apply to private individuals, hence is found in the OrganisationIdentification29 complex element. Further details on LEIs can be found at the Global LEI Foundation (GLEIF) questions and answers. Also available from GLEIF is a suite of APIs endpoints supporting functions such as LEI search and lookups. Finally, it is worth noting the subtle change of the BICOrBEI to AnyBIC. See the regular expressions below for the differences to be incorporated into any validation logic.

2019 AnyBIC Format:

<xs:pattern value="[A-Z0-9]{4,4}[A-Z]{2,2}[A-Z0-9]{2,2}([A-Z0-9]{3,3}){0,1}"/>

2009 BICOrBEI Format:

<xs:pattern value="[A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}"/>

• Structured Remittance Information. The repeating Structured Remittance Information complex element is not new. It offers the promise of significant improvement, particularly in B2B use cases, and I have covered this in a previous article. The previous version offered a rich set of data and whilst it is important, in equal measure, it has been unsupported by interbank schemes. The new version (StructuredRemittanceInformation16) includes several new data fields, the most important of which is the repeating complex element, Line Details (DocumentLineInformation1). This permits full granularity of each payment as shown in the 3-level data hierarchy image below: payment -> related document (e.g. invoice) -> line details. For your upgrade, unless your use cases require line details, the existing data fields will likely meet your customer needs and the focus should remain on the expansion of interbank schemes which support structured remittance information.

Usage Guidelines & Market Practice

This article has focussed on the changes to the base specification rather than business rule changes (usage guidelines) for market practice groups or schemes. It is these that will require detailed analysis and upgrade resources, for example, CGI-MP sets out detailed business use of the regulatory reporting data, such as regulatory reporting indicator applied to DEBT or CRDT side, use of purpose of payment codes (see external code sets) under RgltryRptg not Purp, use of Tax ID (TXID) for the party under Othr/Id, etc.

Regarding Structured Remittance Information, the most important development is not the addition of the fields mentioned above, rather the increasing support for accepting this data by interbank schemes. This support, however, remains varied. Swift CBPR+ support up to to 9000 characters (excluding tags), Payments Canada’s Lynx follows this approach whilst the AFT scheme supports up to 100,000 occurrences of StructuredRemittanceInformation16, Nordic Payments Council supports 999 occurrences. Meanwhile, SEPA also support up to 999 occurrences but only via an Additional Optional Service (AOS) which has limited participation. The continued expansion of support for structured remittance information (and making it mandatory for participants) remains a high priority.

Summary

The 2009 to 2019 upgrade is preparation for the use of enhanced data and to realise the benefits this will provide. Backwards compatibility and a co-existence (2 phase) approach allows the upgrade to minimise impact to client interfaces, but the major benefits will only be achieved once the native 2019 enhanced data elements are in place and utilised (and supported by FMIs and scheme rules).

Notes:

1. This article refers to the base message specifications not any specific usage guideline (UG) adopted by a particular scheme or group.
2. It focusses on the pain.001 only, agnostic of relay usage, and ignores other messages, such as pain.002.001.10. This is intentionally simplistic; please contact me if you require advice on status or other messages/flows.
3. ISO 20022 is syntax agnostic. I may refer to xml and xsd but only for examples and to illustrate the data model. Other syntax, such as JSON, are equally valid.