Payments Exceptions Investigations and ISO 20022 Workflows

In an average payments operations department, two to five per cent of all payments, made on any particular day, resulting in an enquiry with value going up to billions of USD. To improve the competitive position of their cash management offerings, financial institutions are putting increasing pressure on their payments operations. While many processing units achieve impressive straight-through processing (STP) rates, it has become clear that the cost of handling each enquiry resulting from payment is multiplied in the total payment cost. 

Managing of exceptions and investigations remains one of the most labour-intensive activities for a financial institution, largely because it blocks increased automation. The reason for this is the widespread use of free-format messages combined with a lack of industry rules. And as these are mostly manual processes, in a best-case scenario, exceptions can consume a minimum of 6 working days to resolve. 


In response to increasing regulatory and competitive pressure, financial institutions are looking at implementing activity-based pricing, and at invoicing their payments services separately from the processing. This approach is designed to generate additional revenue. However, it requires a high level of service, supported by standardised customer reporting. 

With the migration of ISO 20022, Exceptions and Investigations (E&I) has to be completely redefined. 


The fact remains, that improving customer service levels through the fast and efficient resolution of problems is a key differentiating factor for customer retention. 

Image source - SWIFT


Understanding exceptions and investigations


A case is created each time an exception and investigation process is needed. A case is a file that records the progress of the investigation. This file can be paper-based (a physical folder) or electronic (a database table). As the process is internal, the party creates and organises a case file in its own way. The assignment of this case and the exchange of messages between collaborating parties must respect a set of rules, and these steps can either be manual or automated.  


Image - SWIFT

An exception or investigation process starts when a problem occurs in the normal execution of a payment transaction. 


The exception is normally related to problems detected with the processing environment of the case creator, whereas an investigation is related to an issue identified in the payment chain that will lead to the failure of the processing. 


The problem can be one of the following: 


- Payment needs to be cancelled due to a processing error or a decision by the party instructing the payment 
- Payment must be modified due to a processing error or a decision by the party instructing the payment 
- Payment is received but it is incorrect 
- Payment is received but some information is missing, preventing its proper processing 
- An expected payment is not received 
- An entry in the statement cannot be reconciled on the initiating party 

Exception and Investigation processes are covered under 4 standards. 


Claim Non-Receipt 

A claim-non-receipt message is sent when a party that expects a payment does not receive it or when an agent is missing the cover for received payment instruction. 


Unable to Apply 

An unable-to-apply message is sent when insufficient or incorrect information prevents the processing of a payment instruction, for example, the account number is missing or incorrect, the account is closed, the name and account do not match or the final agent is missing. Processing of a payment instruction covers both the execution of the instruction and the reconciliation of the instruction. 


Request for Cancellation
The instructing party requests cancellation of a payment instruction. 


Request for Modification 

The instructing party may request a modification of a payment instruction. It can eventually entail an Additional Payment Information message that may be sent by the account servicing institution to the creditor or beneficiary. 


Here is an explanation of a few workflows. 

Note - Workflows in the links are only for general understanding and illustrations. Refer to SWIFT guidelines and Market Practices Groups. 


ClaimNonReceipt (camt.027)


RequestForDuplicate (camt.033)


CancelCaseAssignment (camt.032)


CustomerPaymentCancellationRequest (camt.055) and FIToFIPaymentCancellationRequest (camt.056)


UnableToApply (camt.026) 


We at Nth Exception collaborate with Banks and Financial Institutions to analyze, solutionize, and optimize cross border payments processes. To complement our services and product we have partnered with companies in the payments space to deliver best in class payment solutions delivered by our partners.