Handling exceptions well: a practical playbook

The best exception handling starts before the exception happens, with validation at payment capture, with clear customer instructions, and with a payment flow that prevents the most common errors. The next layer is detection. The system should detect a reject, a return, a recall or an investigation automatically, should match it to the original payment by UETR, and should alert the operations team without waiting for the customer to complain. The third layer is triage. The operations team should classify the exception by type, by reason code, and by urgency, and should assign it to the right person with the right information. A payment that is a salary and is three days late is more urgent than a payment that is a supplier invoice and is one day late, and the triage must reflect that. The fourth layer is resolution. The team should follow a documented process for each type of exception, should contact the right bank, and should record every action. The fifth layer is communication. The customer should be told what happened, what is being done, and when to expect an update, in plain language and at regular intervals. The playbook must therefore have five parts: prevention, detection, triage, resolution, and communication, and the analyst must design all five, not just the resolution. A playbook that only covers resolution is a playbook that will be used too late, after the customer has already complained. The playbook must also include the tools the team needs. The team needs access to the gpi tracker, to the SWIFT message archive, to the correspondent account statements, and to the customer record, all from one screen, so that they do not have to search five systems to answer one question. The team needs template messages for the common scenarios, so that the customer communication is consistent and accurate. The team needs escalation rules, so that an exception that is not resolved in five days goes to a senior manager, and an exception that is not resolved in fifteen days goes to the head of operations. The team needs a report that shows the exception rate by reason, by corridor, by bank and by customer, so that the analyst can find the patterns and fix the root causes. For a reject, the runbook says: match the pacs.002 to the original payment by UETR, update the status to rejected, credit the customer the full amount debited, notify the customer with the reason in plain language, and offer the resend flow with the original details pre filled. For a return, the runbook says: match the pacs.004 by UETR, calculate the amount returned and the deductions, credit the customer, notify the customer with the amount and the reason, and check whether the customer wants to resend. For an investigation, the runbook says: log the query, trace the payment by UETR, contact the bank that holds it, and update the customer every two business days. The analyst should also design the metrics that show whether the playbook is working. The exception rate, the percentage of payments that become exceptions, should be measured by reason code, by corridor, and by customer. The average resolution time should be measured by exception type. The percentage of exceptions resolved within the service level should be measured. The customer satisfaction score for exception handling should be measured separately from the score for normal payments, because a customer who has had an exception handled well is often more loyal than a customer who has never had an exception. The analyst should review these metrics every month, should identify the top three causes of exceptions, and should propose fixes for them. A customer who has a payment exception and is kept informed, is given a clear timeline, and receives the money or a clear explanation, will stay with the bank. A customer who has a payment exception and hears nothing for a week, is given conflicting information by different people, and is charged a fee without explanation, will leave. The analyst must therefore design the exception handling from the customer's point of view, not from the bank's point of view. The question is not what is easiest for the operations team, but what is best for the customer who is waiting for money. That is the standard that this chapter, and this whole part of the course, has been building towards, and it is the standard that a good payments BA holds themselves to in every project. The analyst should close the loop on every exception by recording the root cause and the fix. If the root cause was a wrong account number, the fix might be to add confirmation of payee. If the root cause was a missing originator address, the fix might be to make the address field mandatory. If the root cause was a system error, the fix might be to correct the message generation. The exception report should therefore have a root cause field and a fix field, and the analyst should review the report every month and check that the fixes have been implemented. An exception that is resolved but not learned from is an exception that will happen again, and the analyst who prevents the next exception is worth more than the analyst who resolves the current one. A practical starting point for a new analyst is to take the last month of exceptions, classify each one by type and reason code, and find the top three causes. Then, for each cause, propose one fix, one test, and one measure. That exercise, repeated every month, will reduce the exception rate steadily, will improve the customer experience, and will give the analyst a record of improvements that can be shown to management. Exception handling is not just about fixing problems. It is about learning from them, and the analyst who learns fastest is the analyst who delivers the most value.