Estimated reading time: 14 minutes

ISO 20022 and Trade

If you have heard of ISO 20022 you may be wondering what it is and what impact it may have, particularly on business to business trade.  The financial services industry is rapidly moving to this standard and numerous ISO 20022 programmes are in-flight across SWIFT, banks, clearing houses and software vendors.  Your next AP, AR or treasury system will likely have ISO 20022 messages built in. Within trade finance, as with other types of finance, it will impact the flow of transactions and ultimately bring significant benefits.  The degree of impact and realisation of benefits will vary depending on various factors including geography, domestic or cross-border trade, currencies etc. It will also be impacted by the adoption and maturity of ISO 20022 by the various market infrastructures and other parties in the end to end chain.  The intention is clear though, as with the shipping container, ISO 20022 aims to be ubiquitous and the de facto standard for all types of financial transactions.

Further background reading is available through the freely available ISO for Dummies book.  A downloadable version can be requested here.

Purpose of ISO

ISO 20022 offers great potential benefits for global trade finance due to, amongst other reasons, the significant amount of transactional and remittance data passing between the many parties and the likely involvement of procurement/eCatalog, ERP or treasury management systems at the buyer and supplier ends of the chain.

ISO 20022 supports much richer, structured data within each message which allows more efficient batching of invoices into fewer payments and more efficient reconciliation by all parties.

For this article we’ll look at several key aspects and benefits of ISO 20022 applicable to both domestic and cross-border trade:

• Key message types:
  • Trade Services & Trade Services Initiation
  • Payments –
    • Payment Initiation Message (Buyer to Bank/Finance Provider)
    • Payment Status Message (Bank/Finance Provider to Buyer)
  • Reporting & Reconciliation –
    • Cash Management Message (Bank Statement and Credit/Debit Report)
    • Remittance Advice Message (Buyer to Supplier)
• Process efficiency:
  • Software vendor support for ISO 20022
  • Richer, Structured Invoice Data – Extended Remittance Information (ERI)

Useful Information

We’ll refer to specific message types – there are more than 400 of them covering all aspects of financial services – so it may be worth understanding the naming convention and usage rules governing them.

ISO Message Naming Convention

Many of the messages have evolved and improved and there are now multiple versions.  When browsing and using the message types, it is important to ensure the correct message variant and version is being considered.  The 4-part naming convention can be seen at Figure 1. In this example:

• Message Type:  the business domain/group such as Payments Initiation (pain)
• Message Sub-Type:  the sub-type, such as 001, 002 etc.  For payment initiation, 001 is the payment initiation message itself and 002 is the reciprocal payment status message returned.
• Variant:  usually this will be 001 but some messages/markets use variations, such as pain.001.003.03 which is a SEPA specific variant occasionally used in Germany and Austria.  Variants are usually a sub-set of the original message, with fewer fields for simplicity however the original message can be used.  Generally, the use of variants is rare and discouraged as it effectively creates a “local” standard.
• Message Version:  as ISO 20022 has been developing since the early 2000s, most messages have been incrementally enhanced.  The most frequently used messages can have multiple versions. It is therefore important to ensure the correct version is being used, which is not necessarily the latest version (see Common Global Implementation – CGI). 

Common Global Implementation – Market Practice (CGI-MP)

With multiple versions of the most used messages, interoperability and backwards compatibility can be problematic.  Further, corporates and banks do not want to be constantly upgrading systems for new versions unless necessary, particularly at a stage when standardisation and stability are needed to encourage wider adoption.

To solve this and other usage issues, a global initiative was formed to coordinate banks, corporates, vendors etc, around a specific version for key message types and usage rules.  This group is called the Common Global Implementation by Market Practice (CGI-MP).  The scope of the messages under the guidelines of CGI-MP can be seen at Figure 2 and the current versions of each at Figure 3.  It is important to note that the latest versions of the messages are not the ones adopted by CGI-MP.  Whilst the latest version of a payment initiation message is version 9 (pain.001.001.09), CGI-MP supports version 3 (pain.001.001.03).  You may wonder if this really matters – how different are these versions? Well, in some cases the differences are minor, in others more significant.  For example, version 3 supports rich, structured remittance data (let’s call it invoice data) per payment but version 9 also supports invoice line details per invoice.

Importantly, ERP and treasury systems, if they support ISO 20022, will likely support the CGI-MP versions, as will banks / financing partners.  We’ll discuss ERP systems in more detail later.

Key Message Types

ISO 20022 covers more than 400 message types spanning many aspects of financial services.  Some are specific to a particular industry body, others more generic and more widely accepted.  Messages are grouped into business domains and groups such as Trade Services (message prefix tsrv), Cash Management (prefix camt), Securities Trade (prefix setr) and Payments Initiation (prefix pain).  Beyond the message formats themselves, ISO 20022 sets out the usage and business process flows, between the various actors in business scenarios.

This article will focus on payments initiation, cash management and reconciliation but it is worth briefly looking at Trade Services messages.

Listen to TFG’s podcast with SWIFT’s Global Head of ISO 20022, Saqib Sheikh:

Listen now

Trade Services & Trade Services Initiation

There are 2 business domains that have specific trade finance messages and processes – Trade Service Initiation (tsin) and Trade Services (tsrv).  Neither of these domains are under the remit of CGI-MP so interoperability and support between the various parties may need to be negotiated and in certain cases, additional configuration built into their software systems.

Invoice Financing

For invoice finance transactions, the CBI has developed the InvoiceFinancingRequest message (tsin.001.001.01) along with the reciprocal Invoice Financing Request Status and invoice Financing Cancellation Request messages.

In the simplest, direct scenario, the invoice financing request message would usually be generated and sent by the supplier’s finance partner, triggered on receipt of a copy of the invoice to the buyer.  This business flow can be seen at Figure 4.  

The utility of this message is evident from the detail of the data it can carry.  It is designed for bulk requests – many invoice financing requests is a single message.  For each request, the summary of the main data fields can be seen at Figure 5. They include:

• Invoice General Information:  including document type and number and issue date.
• Invoice Totals:  including taxable and tax amounts, adjustment amounts (debit/credit), invoice amount and due amount.
• Multiple Instalment Information
• Financing Rate or Amount
• Supplier and Buyer Information
• Payment Method and Account
• Multiple Referred Documents: include multiple related document data items such as doc type, issuer, number, date and amount.

Demand Guarantees & Letters of Credit

For demand guarantees and standby letters of credit, the SWIFT Trade Services messages are available.  These include UndertakingApplication (tsin.005.001.01), Undertaking Issuance (tsrv.001.001.01) and further advice, notification, amendment, non-extension, termination and demand messages.  

Payments Initiation

One of the most frequently used business domains is Payments and the group of Payments Initiation (pain), specifically the 2 key messages:

• CustomerCreditTransferInitiation (pain.001.001.03) – the payment(s) initiation message.
• CustomerPaymentStatusReport (pain.002.001.03) – the reciprocal payment status message.

These messages are under the remit of CGI-MP and therefore version 3 of both are the most used, widely supported and highly interoperable across markets and infrastructures including the domestic US Nacha clearing system.

Supply Chain Financing / Reverse Factoring

Buyers using a finance partner to fund their accounts payable obligations, whether for working capital benefits, providing accelerated supplier payments or both, will invariably group and approve invoices then generate a payment instruction from their ERP / AP system.  Currently, depending on the currency, market, system and finance partner, this may be in the form of a SWIFT MT103 message, an EDI 820 message, a US ACH message or some other standard or proprietary message – there are lots to choose from. With ISO 20022, the message would be a Customer Credit Transfer Initiation (pain.001.001.03), regardless of currency, market etc.

Having generated and sent this message to the finance partner, be it a bank or other finance provider, they would send back the reciprocal Customer Payment Status Report (pain.002.001.03).  Usually, this would be a real-time status report and would be generated by the finance partner at each stage of the payment workflow. This is depicted at Figure 6 and in this example, whilst the first 2 status messages are real-time, the final one which shows the payment status as ACSP (Accepted Settlement in Process) is driven by a daily settlement batch process by the finance partner.

The status messages directly echo the data contained in the payment initiation messages and can be reconciled automatically by the ERP system.  This provides for an efficient payment workflow and greater STP in the AP/finance department. Often, the final status message, when received by the ERP system, will automatically trigger the relevant ledger postings and shift the debt from the supplier to the finance partner. 

Structured Remittance Information

The Customer Credit Transfer Initiation message supports bulk payments and, one of the most valuable features, each payment can carry recurring structured remittance items, whether invoices, credit notes, purchase orders, bills of lading or a combination.  The high-level data layout of structured remittance items can be seen at Figure 7.  

This provides the ability to batch all invoices for a given currency to a given supplier into a single payment.  The benefits of fewer payments are obvious but significantly, once infrastructures are upgraded to carry the rich remittance data with the payment, the supplier will receive this remittance data in their ISO 20022 bank statement and credit/debit reports allowing their own automated AR reconciliation.

Reporting & Reconciliation

Once a buyer has initiated payments to their suppliers/creditors, containing structured remittance information, and having received the payment status messages back from their bank or finance party, both buyer and supplier will want to reconcile and balance their bank accounts and / or receivables.  ISO 20022 has specific messages for this in both the Cash Management (camt) and Payments Remittance Advice (remt) groups.

Bank Statements & Credit/Debit Notifications

Currently, bank statements are frequently provided in standard data formats in various markets.  Commonly these may be SWIFT MT 940, EDI 822, BAI2, EDIFACT FINSTA or other industry or proprietary standard.  The equivalent in ISO 20022 is the BankToCustomerStatement (camt.053.001.02).  This message is also under the remit of CGI-MP hence version 2 and not the latest version 8.  A bank/finance partner, supporting ISO 20022, should be able to issue these at a determined interval from end of day, end of month etc.  This is a comprehensive statement which can include multiple balances (opening booked, interim booked, closing booked, forward available, etc) and can echo the structured remittance information for each transaction entry if it was passed through the payment system.  The statement message has the same remittance data structure same data structure as the payment initiation message, as can be seen in Figure 8.

Also found in the Cash Management group is another extremely useful CGI-MP governed message, the BankToCustomerDebitCreditNotification (camt.054.001.02).  The frequency of this message and whether real-time (individual transaction notification) or batched (bulk transactions) will be determined by the bank/finance partner.  The message structure though, has the capacity to carry the same rich structured remittance data passed in the payment and available in the statement message.

This common, rich, data structure which is prevalent throughout the various message groups and business processes, it one of the major advantages of ISO 20022 in a corporate trade finance scenario.

Standalone Remittance Advice Message

Accounts Receivable reconciliation is a common pain point for suppliers.  We’ve briefly discussed how ISO 20022 supports rich, structured remittance data within each payment however there are still reasons why this may not be able to pass through the banking system and may need to be sent to the supplier separately.  The addition of the RemittanceAdvice message (remt.001.001.04) to the ISO 20022 family fulfils this need.  This can be generated by any number of parties in the chain, often directly by the buyer when generating the pain.001 message but also by the bank.  This is not under the remit of CGI-MP so who and how this would be generated would need to be mutually agreed with the bank or finance partner.

As a supplier though, with an AR/ERP system capable of accepting ISO 20022 statements and debit/credit notifications, it is relatively straightforward to accept a remit.001 file thereby significantly improving the AR/invoice reconciliation processes.

Process Efficiency

Corporates and banks are always looking to increase their efficiency and STP rates.  The ISO 20022 messages and data structure are specifically designed with this in mind.  It is imperative, however, that the various software systems in use by all parties, are ISO 20022 capable.  Arguably it is more important that the people responsible for those systems are ISO 20022 aware – these systems come with default configurations and additional modules which, if the team isn’t ISO 20022 aware – may not be applied correctly and the potential benefits not fully realised.

ERP / Vendor Systems

Most modern, cloud-based ERP or TMS system now offer ISO 20022 support by default.  If any corporate is considering a system upgrade, such as a move to a cloud offering, ensure this factors in any assessment.  Oracle, SAP, Microsoft, Workday etc all provide ISO 20022 support, some by default, others through additional connectors. The online documentation for Oracle Fusion Financials for example, shows clear and simple support for ISO 20022, for both payments and statements.  It also explains the differences between the CGI-MP and the SEPA sub-set messages – see Figure 9 for the SEPA message and validations and Figure 10 for the super-set CGI message and validations option.

These CGI-MP and SEPA validations, built into the system, ensure the messages created conform to the defined standards and thereby reduce development effort for the system whilst minimising the risk of errors in the payments which would otherwise cause problems elsewhere in the processing chain. 

Richer, Structured Invoice Data – Extended Remittance Information (ERI)

Having discussed the capability and benefits ISO 20022 brings for rich, structured remittance information – often known as Extended Remittance Information (ERI) – there will still be differences and limitations between clearing houses and market infrastructures as they upgrade to ISO 20022.  Individual banks, many hampered by legacy technology, may also support different quantities and types of ERI. Whilst the pain.001 message can support unlimited remittance items,  SWIFT CBPR+ plans to support only support 9,000 characters which will likely equate to 43 – 272 invoice items per payment.  The US Nacha clearing system currently offers a CTX message which can carry 799,920 characters which equates to 2,497 – 12,486 invoice items per payment. It is unclear whether Nacha will continue to support this volume of ERI once it upgrades to ISO 20022, but it is likely to be their design target given the reliance on CTX in US corporate payments.

Given the various limitations, data truncation will still be a risk and collaboration with the bank or finance partner essential.  Further detailed analysis on the various ERI limitations is available from the author but it is vital to understand these limitations in the given business scenarios and configure software systems accordingly.

Summary 

ISO 20022 is gathering pace and will undoubtedly bring profound benefits to financial services.  The ongoing or planned programmes around the world do indicate this will indeed become the ubiquitous standard.  For corporates and trade finance transactions, it will improve many pain points however its impact must not be under-estimated.  It is not just a new message format. It will impact products/services and processes. Having skilled and knowledgeable people available to ease your adoption and fully realise your own benefits will be vital.

About the Author

Dominic Digby has been working in financial services for 20 years through his consultancy, Affinis.  He has implemented ISO 20022 in supply chain scenarios for large corporates in several countries and with payment service provider and its major banks on end-to-end implementation.  He has written several articles on ISO 20022, some available on LinkedIn. For advice and consultancy, he can be contacted at dominic@affinis.co.uk.