-

It’s never too early to start preparing for the move to ISO 20022

When we talk about ISO 20022, we often reference “more structured and richer data”, but what does that mean as we get into the detail? Our top discussion points today are Structured Address, Legal Entity Identifiers (LEIs), Purpose of Payment codes (PoP) and what this looks like in practical terms for corporate and Financial Institution (FI) clients.

Structured Addresses:

Put simply, when making a payment, you will need to provide the beneficiary address in a structured format. For clients utilising online payment channels you may notice that the payment input screen has been updated to support the structured address requirements. For high volume users who create and store their payment templates in their ERP or TMS, which in turn interfaces with a banks host-to-host system, you will need to update your payment templates to reflect the structured address requirements.

Now is the time to scope out how many templates you hold and use and to calculate how long making these required changes may take to implement.

LEIs & PoP:

LEIs and PoP codes are already used today in some cross-border payments and as a result, you may already be familiar with them and actively using them within your payments. Both LEIs and PoP codes will become a feature across the Europe payments space, internationally with SWIFT payments and domestically within CHAPS payments. Neither of these enhanced data fields will be mandated at the SWIFT and Euro High Value release in November 2022, however the Bank of England have confirmed that the use of both are actively encouraged from April 2023. From Q2 2024, PoP codes will be mandated for FI to FI CHAPS payments and all property related CHAPS transactions.

Although there are many PoP codes available for use, you may find that your CHAPS payments are only sent for a handful of reasons, so internal awareness and training ahead of time could simplify your operational approach.

Other advantages:

Finally, there are plenty of additional fields that are being made available with the move to ISO 20022, although the exact number will depend on which bank you’re sending the payment to or receiving the payment from. For example, if you decide to pay a different amount to that shown on the invoice, there will be a new field, which can be populated to explain why. You can include a phone number and email address in case the beneficiary has a query, this can be the contact that knows the reason for any adjustment and not just the person processing the payment; and there is a field to capture multiple invoice references that relate to the single payment – potentially reducing the number of payments you need to send, and of course may receive – thus improving your operational efficiencies.

For years, many corporates and FI clients have been asking for more information to be delivered with the payment, increased standardisation and consistency of payment requirements to enhance their payment processing, cash flow forecasting and reconciliation processes.

The payments industry globally is about to deliver on that ask, and as XML is designed to be both human and machine-readable, there are many possibilities. It is plausible that on day one, you will simply know where to look in the structured payment receipt for the information you need, but over time, you could move to full automation, leveraging the capabilities of your ERP or TMS. What is certain is that early preparation will position you well to take advantage of the move to ISO 20022.