Background

The financial services industry is rapidly moving to the ISO 20022 standard. Numerous ISO 20022 programmes are in-flight across SWIFT, banks, clearing houses and software vendors. Much is discussed about global standardization, syntax independence, uniformity across business processes, increased interoperability and the associated straight-through processing (STP) improvements along with cost reductions. Within the payments’ domain, specific benefits such as richer remittance data and better reconciliation are welcome and much needed however, amongst the excitement, banks are already making mistakes in their adoption.

This white paper will specifically focus on how some banks are breaking the integrity of the EndToEndId in their efforts to prevent duplicate payments.

Scenario

Many of the example payment process flows in ISO 20022 white papers are relatively straightforward with minimal counterparties; a Debtor, Debtor’s Agent, Creditor’s Agent and Creditor. They depict a payment flow between Debtor and Creditor and are usually intentionally simple to make their case.

In this white paper we’ll dive deeper into SWIFT for Corporates, beyond the strategy and into practical implementation, and look at a supply chain finance scenario including a Payment Services Provider (PSP), sometimes referred to in ISO 20022 lexicon as a payment factory.

This study uses the following scenario/use case:

1. In Figure 1 above, 3 large corporations (buyers 1, 2 and 3) each make USD purchases from their respective US suppliers for which they receive an invoice. In the ISO 20022 lexicon the buyers will become the Ultimate Debtors and the suppliers the Creditors.

• Each Accounts Payables department processes the invoice and, using their ERP or Finance system, executes a weekly payment run for USD invoices, generating the payment instruction output. Given they are all using cloud ERP systems, which supports ISO 20022 out-of-the-box, the payment instructions are PAIN.001.001.03s. 
• Each system inserts a payment ID for each payment – the EndToEndId – which is unique within the scope of that buyer and their given supplier. For this example, the payment ID for buyer 1’s payment is 2020/05/0001. This representing the year, week number and incrementing counter.
• Each buyer sends their payment instruction for execution and will receive back the relevant status report, debit/credit notifications and account statements, all carrying the EndToEndId.

 2. All 3 buyers are clients of the Payment Services Provider (PSP) and this is where they send their PAIN.001.001.03s for execution. The PSP will pay-on-behalf-of (POBO) the buyers, providing additional value such as accelerated supplier payment, working capital optimisation, etc. The buyers will settle their debt to the PSP later depending on their commercial terms.

• The PSP holds a USD nostro account with their given bank in the US (see #3). All their USD payments to US beneficiaries flow through this single account. The PSP is now the Debtor and their US bank is the Debtor’s Agent.
• The PSP service will likely offer each buyer the ability to apply error prevention rules including duplicate payment checks. These rules will ensure payments are unique within the scope of that buyer and of its all suppliers or more likely, for each individual supplier. Configurable validation for duplicate payments at the PSP means it is not needed at the Debtor Agent.
• The PSP may process the payment instructions it receives in real-time or in batch. For the latter, the PSP will send a single, batched PAIN.001.001.03 to its bank containing all three payments. The key point though is the payments from the 3 buyers will be debited from the same nostro account.
• The PSP will send the relevant status reports, debit/credit notifications and account statements to each buyer for automated reconciliation. These will be for the buyers’ account with the PSP, not the nostro account. Depending on the capability of the PSP, it may be able to send remittance information directly to the suppliers to allow automated Accounts Receivable reconciliation (unnecessary in this case as US Nacha[1] offers enhanced remittance data via Corporate Trade Exchange (CTX)).
• On receipt of the status reports (PAIN.002.001.03) from the PSP, the buyers now switch their liability from the Creditors to the PSP.

 3.      The bank of the PSP (Debtor Agent) receives the PAIN.001.001.03 containing the 3 USD payments to be debited from the given account to the 3 Creditors.

• The bank applies configurable duplication validation, checking for duplicate payments over a given timeframe – in this case a rolling 32-day period. If the payments pass this validation, the bank sends the payments as interbank messages (either PACS but in this case as NACHA CTX – note the interoperability guidelines for NACHA/ISO 20022) for clearing and settlement. Ultimately, the Creditors will receive the funds along with remittance data.
• The bank sends the relevant status reports, debit/credit notifications and account statements, related to the nostro account, to the PSP for their account reconciliation.

Importance and Scope of the EndToEndId

Within ISO 20022 business processes, the importance and scope of the EndToEndId must be clear. The EndToEndId is a data field of maximum 35 characters[2] for each payment. It is defined as:

EndToEndId

Unique identification, as assigned by the initiating party, to unambiguously identify the transaction. This identification is passed on, unchanged, throughout the entire end-to-end chain

Let’s dispel a myth. The EndToEndId will not, most likely, be universally unique and may only “unambiguously identify the transaction” within a limited scope – between the end-to-end parties, i.e. the buyer and the supplier. In corporate Accounts Payable departments, invoices from a supplier are often batched into single payments, hence the benefit ISO 20022 brings in supporting enhanced remittance data. A batched payment will likely be assigned an EndToEndId by the ERP/AP system however, for the use case where invoices are not batched – one invoice generates one payment – or where sophisticated ERP systems are not available, it is relatively common for the supplier’s invoice number to be used as the payment EndToEndId. This can increase the likelihood of duplicate EndToEndIds.

In the earlier example of an EndToEndId – 2020/05/001 (year, week number, counter) – it is easy to see how this convention could be used by multiple suppliers to number their invoices.  

“The EndToEndId will not, most likely, be universally unique…”

These are all perfectly valid scenarios and highlights the very limited scope to which “uniqueness” should be viewed.

Problem

In the scenario here, all 3 payments should process successfully. The problem occurs if/when the Debtor Agent enforces duplicate payment validation checks based on the value of the EndToEndId. If a payment is received from any of the 3 buyers with the same EndToEndId as a previous payment, within the 32-day period, the later payment will be rejected as a duplicate. It matters not that the payments have different Ultimate Debtors, Creditors and most likely different instructed amounts. The payment will be rejected. The Debtor Agent is implicitly applying a much wider scope to the “uniqueness” of the EndToEndId than of the intended scope between buyer and supplier.

The likelihood of this happening may be remote however, if the PSP has thousands or tens of thousands of buyers, all transacting through this USD nostro account, it becomes much more likely, particularly if supplier invoice numbers are used as EndToEndIds by the buyer(s).

“There is significant impact from using the EndToEndId to validate for duplicate payments…”

Impact

There is significant impact from using the EndToEndId to validate for duplicate payments or without taking other factors into account. 

The PSP could take a short-term, reactionary and risk-based approach; continue with the current process and deal with instances of rejected payments as they occur by amending the EndToEndId and resubmitting. This approach may be favourable to PSPs with a small client base and where, after analysis of their historical payments, they assess a low probability of duplicate EndToEndIds. 

Alternatively, a proactive and systemic approach could be adopted by the PSP by programmatically inserting their own “unique” EndToEndId and overwriting that of the buyer. This approach, drastic as it may seem, would likely be preferable for those with a large client base and a higher risk of duplicate values.

Whichever approach, the effect may be wide-ranging:

• Delayed payments, particularly if submitting close to currency cut-off deadlines and resubmissions cannot be made in time.
• Putting supplier and buyer relationships at risk if payments are delayed.
• Amending the EndToEndId breaks the reconciliation integrity of the payment. All related ISO 20022 messages sent back to the buyer would carry the amended, meaningless value. The buyer’s reconciliation processes, which may rely on their EndToEndId, would break.
• Most PSPs encourage payment queries to be handled directly between the supplier and buyer; the supplier may not even be aware the PSP is involved. Amending the EndToEndId means the supplier and buyer have different references for the same payment and identification becomes more difficult.
• STP efficiency decreases and manual exception/handling costs increase for all parties.

Root Cause

The root cause in this scenario is the Debtor Agent using the EndToEndId alone to validate for duplicate payments. Any party in the processing chain doing similar would have the same effect. The EndToEndId is not designed to be used for this purpose and must be passed on, unchanged throughout the entire end-to-end chain (see extract[3] Figure 2).

The reasons for using the EndToEndId will be varied, from a simple misunderstanding of ISO 20022 to constraints imposed by legacy processes, formats and technology/systems. Most likely a combination of these and one of the reasons why the adoption of ISO 20022 is complex and phased for many companies.

Solution

Given the EndToEndId must not be used for duplicate validation, several solutions can be applied however the majority require changes by multiple parties at various points in the processing chain.

If the bank does not change its practice, as unpalatable as it may be, the PSP can change bank, choosing one that correctly applies ISO 20022 or at least allows configurable duplicate payment validation logic. However, assuming this is not a consideration, other options may be:

• The bank should not apply duplicate validation based on the received PAIN.001.001.03.
• If duplicate validation remains, it should switch from validating the EndToEndId to the InstrId. This field is rarely populated by the Ultimate Debtor so the PSP should insert this, ensuring it is “unique” for all payments passing through the nostro account. As shown in Figure 2, the description of the InstrId shows this is the intention. It is an optional field and the bank will need to cater for this.
• If the bank continues to use the EndToEndId, it should enhance its logic to reduce the scope to that between the Ultimate Debtor and Creditor. It should include additional data values from the transaction such as Creditor ID, required execution date, instructed amount.

“In the case there are technical limitations to pass on multiple references, the end-to-end identification must be passed on throughout the entire end-to-end chain.”

• Any solution should ensure the EndToEndId takes precedence over other references should there be a technical limitation on the number of references that can be mapped and passed on (see the extract at Figure 3). 

• Notably, it is the interbank PACS message that contains a field to ensure uniqueness for the payment for a given period. This is the TxId (see the extract at Figure 4).

Summary

Whilst many white papers focus on the importance of ISO 20022 or having a strategy for implementation, this white paper tries to highlight that, beyond the strategy, the devil is definitely in the detail. In this case, regardless of how payments are validated for duplicates, ensuring the integrity of the EndToEndId, between the Ultimate Debtor and Creditor, is paramount.

Ultimately ISO 20022 implementation can be complex and may need a fundamental deep dive into many processes and systems. If you need further advice or support for your ISO 20022 programme, get in touch.

Health Warning

This white paper references the CGI-MP[4] versions of ISO 20022 messages and acknowledges there are many variations on supply chain finance scenarios/use cases within the end-to-end processing chain. It does not intend to be a definitive guide, nor does it intend to single out any particular bank, or banks in general, for current errors in ISO 20022 payment processing. 

The issues and scenarios described here are real examples, encountered in the course of processing payments whilst ISO 20022 implementation programmes are in-flight with the various stakeholders in the processing chain.

[1] See https://www.nacha.org/content/iso-20022 for more information on ISO 20022 integration.

[2] Interoperability with clearing systems, such as US Nacha, means 35 characters may not be supported.

[3] Message Definition Report: Payments – Maintenance 2009, September 2009

[4] https://www.swift.com/standards/market-practice/common-global-implementation