Exception Queues

A payment lands in an exception queue when an automated check cannot be resolved by the system alone. Common causes include a missing beneficiary account number, an invalid SWIFT code, a sanctions screening hit that needs human judgement, an amount that exceeds the customer daily limit, or a currency that the bank does not support for that corridor. A payment of 75,000 euros to a company in Turkey might be held because the beneficiary bank identifier is one character short. A payment of 500,000 dollars might be held because the customer name matches a name on a sanctions list, even though the match is only partial. In each case the hub parks the payment rather than guessing, because guessing with real money is never acceptable. Manual repair screens are the tools analysts use to fix these payments. A typical screen shows the full payment instruction on the left, the error message in the middle, and the actions available on the right. The analyst can correct a field, such as fixing a transposed digit in an account number, and the system revalidates the payment immediately. The analyst can also add a note explaining the repair, attach supporting documents, or escalate the payment to a senior colleague. Every change is logged with the analyst name, the time, and the old and new values, so the repair can be audited later. Some screens also show the customer history, so the analyst can see whether the same beneficiary has been paid before and what details were used then. Straight-through processing rates are a key performance measure for a payments operation. A retail bank processing 2 million payments a day might achieve 98 percent straight-through processing, meaning 40,000 payments still need manual handling every day. A corporate bank handling complex cross-border payments might achieve 92 percent, because corporate payments carry more free-text fields and more unusual currencies. Banks improve the rate by fixing the most common errors at source, for example by validating account numbers in the online banking screen before the customer submits the payment, or by building reference data that auto-completes beneficiary bank details from the SWIFT code. Each percentage point of improvement can save dozens of analyst hours a day. A day in the life of an operations analyst starts with the exception queue dashboard. The analyst sees the total number of stuck payments, and picks the oldest and highest value items first. A payment of 1.2 million pounds that has been stuck for three hours takes priority over a payment of 200 pounds stuck for ten minutes. The analyst opens the payment, reads the error, checks the source documents or the customer instruction, and decides whether to repair, return, or escalate. A repaired payment goes back into the automated flow. A payment that cannot be repaired, for example because the beneficiary bank does not exist, is returned to the customer with a clear explanation. The analyst also spots patterns, such as ten payments from the same company failing for the same reason, and raises the issue so the root cause can be fixed. Exception handling also has strict controls, because a repair screen gives an analyst the power to change a payment. Most banks require two people to approve a repair above a threshold, often 100,000 pounds or the local equivalent. A repair that changes the beneficiary account number always needs a second checker, because that is the change most likely to send money to the wrong person. Analysts cannot repair their own payments, and they cannot release a payment that a sanctions screening has flagged without approval from the compliance team. These controls slow the work down, but they exist because a single wrong repair can cost the bank far more than the time saved.