Managing 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) will be 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 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 with 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 the 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.
RequestForDuplicate (camt.033)
CancelCaseAssignment (camt.032)
CustomerPaymentCancellationRequest (camt.055) and FIToFIPaymentCancellationRequest (camt.056)
