If you’re making cross border payments, you’ll be familiar with the term ISO 20022 and what these changes mean for your current financial processes.
As humans we are hard wired to resist change, even if that change is for the better. So, whilst implementing ISO 20022 has been introduced to pave the way for more efficient integration, improved analytics and a more accurate compliance process, many finance professionals are still trying to wrap their head around how SWIFT’s update will affect current day-to-day processes.
In this blog, we will cover the more technical aspects of ISO 20022 to help finance professionals prepare for this change as well as how you can migrate to ISO 20022 in a cost-effective way. We’ll help explain how ISO 20022 provides a logical structure to support financial business processes, and how it’s represented syntactically in an XML format.
ISO 20022 messaging formats
To note, when talking about implementing ISO20022, there are many acronyms used interchangeably: ISO20022, XML, MX, pain, pacs & camt. They all refer to the new message formats which are replacing legacy SWIFT ‘MT’ or Message Type formats.
We’ll then drill down a bit further and focus on bank-to-bank payments and statements for both corporates and non-bank financial institutions (NBFIs).
If you need a reminder on the basics of IS0 20022, See our previous blog: What is ISO 20022? SWIFT’s Financial Messaging Standard Explained article.
ISO 20022 for Corporates – From MT101 to Pain.001
For corporates, the message formats—such as Standard 18 for BACS or MT101 for CHAPS/Faster Payment—are being replaced by the new pain.001 format (version 3). Pain.001 provides several advantages over MT101: bulk file support, potentially lower transaction fees (based on the bank), and a return message which indicates payment status at both file and transaction level. This last feature offers significant value as it serves as an early warning signal of successful or failed payments.
For companies making automated payments to their banks, they’ll need to use the PAIN.001 standard – version 3 specifically – which supports bulk files and single transactions. This could prove more cost effective than using MT101 for most banks as there are no transaction fees associated with bulk files. Additionally, the XML format supports a file level and/or transaction level payment status reports that can act as early warning signals if something has gone wrong with a payment.
What is ISO 20022 and what does it mean for NBFIs?
Financial institutions, such as banks or non-bank financial institutions (NBFIs), are transitioning to XML-based Pacs.008 and Pacs.009 for MT103 and MT202 payments respectively. These messages support bulk messaging and a payment status report with a Pacs.002 (or Pacs.004 if the payment has been settled).
At the same time, traditional statement formats such as MT940 are being replaced with Camt.053, while MT942 intraday statements are being replaced with Camt.052 formats – making it easier for organizations to reconcile their accounts and create a cash position for their finances.
When do the IS0 20022 changes come into effect?
Financial institutions have already begun the transition to the new ISO 20022 message standard, but they were originally scheduled to complete this process between November 2022 and 2025. However, due to an announcement by the Bank of England, banks must now complete their transition to the new format by June 2023.
For most corporates and NBFIs, it is best to confirm a timeline for these changes with their counterparty bank as soon as possible. Some banks may choose to run parallel processes that support both old and new formats until 2025. This deadline allows organizations enough time to make the necessary transitions in their infrastructure so that they can benefit from these modern standards.
See a snippet from our recent event explaining when these changes come into effect.
What would your advice be to any organisation who hasn’t yet considered the impact of the changes in payment and statement format?
For organizations that have yet to consider the implications of the ISO 20022 message standard, it is important to reach out to their banks and confirm the timeline for parallel running and when they will no longer accept legacy MT formats.
Fortunately, many banks, such as HSBC and Barclays, are allowing a period of parallel running until 2025. This gives organizations enough time to create a migration strategy with plenty of contingency towards the cut-off date provided by their banks.
Is it possible to implement ISO 20022 without impacting your back-office systems?
It is possible to implement the new standards without impacting back-office systems, with two primary options. Organizations can choose to update their existing back-office systems to support the new format by making changes such as updating file formats, being able to receive Payment Status Reports (PSRs) and statements in new formats, and changing reconciliations processes. These updates may require four or five finance and IT resources. On the other hand, organizations can use a third-party service or SWIFT’s translation service to convert their MT files into XML documents. However, note that these files must be “enriched” with extra fields for them to be accepted.
Identifying challenges when implementing ISO 20022
We did some recent work with a high street bank which revealed a few key considerations to bear in mind when it comes to ISO 20022. Specifically, the mandatory purpose of payment code must be populated in the pacs message, which was not included in the original MT103 message. Using the AccessPay platform we have been able to enrich the file based on certain conditions to ensure that this field is completed. Additionally, a Legal Entity Identifier field must also be included in the pacs message; it can be added using a database look-up from the Bank of England. This file enrichment process has been hugely beneficial for our customer and saved them from having to make significant changes to their back-office system.
Are there any cost implications for ISO 20022?
The amount of time and cost required to implement the new standards varies greatly depending on the organization and their current connections to their bank or banks.
As a hypothetical scenario, an in-house solution—commonly referred to as ‘DIY’ (when a team of in-house developers are required to build a bespoke solution) may require four or five staff members from IT and ERP teams. Alternatively, organizations can opt for a third-party service, but pricing and support requirements may need to be discussed with them first.
Read more about what we mean by a DIY connection here.
In the case of AccessPay, assuming one bank and one back-office system is involved, it is likely that this would cost about £10,000 as an annual fee; if more complexity is added then this fee will increase accordingly.
If you want to learn more about ISO 20022, we have a 20-minute walk-through with our payment and automation experts. Watch now.
If you have any further questions, you can speak directly with one of our experts today. Get in touch.
