Timelines, costs and who bears them

Every exception has a timeline, and the timeline is set by the rules of the payment system, the agreements between banks, and the law of the countries involved. A reject should be notified to the customer within one business day, because the payment never left the sending bank. A recall should be acknowledged within one business day and resolved within fifteen business days, although the actual recovery depends on whether the funds are still available. An investigation should have a first response within two business days and a resolution within fifteen business days, with regular updates to the customer in between. These timelines are not aspirations, they are the service levels that the bank should commit to, and the analyst must build them into the requirements and into the monitoring. If the sender made an error, such as a wrong account number, the sender bears the cost of the return charges and the recall fee. If the bank made an error, such as sending the payment to the wrong bank, the bank bears the cost and should refund any charges to the customer. If the payment was stopped for a compliance query and the query finds nothing wrong, the cost is usually borne by the sender, because the compliance check is a cost of doing cross border business, although some banks will waive the fee as a goodwill gesture. The analyst must include the cost allocation in the requirements, must ensure that the charges are applied correctly, and must ensure that the customer is told upfront what an exception will cost. A worked example shows how the costs add up. A customer sends USD 10,000 with SHA charges, paying USD 25 to the sending bank. The payment is returned because the beneficiary account is closed. The beneficiary bank returns USD 9,960. The correspondent deducts USD 25. The sending bank receives USD 9,935 and deducts a USD 25 return fee. The customer receives USD 9,910 back, a loss of USD 115 on a payment that never reached the beneficiary. If the customer then resends the payment with the correct account number, they pay another USD 25 plus the spread again. The total cost of the error is USD 140 plus the spread, plus the delay. The analyst who can show the customer this arithmetic before the payment is sent will prevent more errors than any amount of post payment investigation. The analyst must also think about the cost that is not a fee, the cost of the customer's time, the cost of the delayed business, and the cost of the lost trust. A supplier who is paid late may charge a late fee, may refuse to ship the goods, or may refuse to do business again. An employee who is paid late may not be able to pay rent. A company that misses a payment deadline may breach a contract. These costs are real, even though they do not appear on the bank's invoice, and they are the reason why exception handling matters. The analyst who understands the true cost of an exception will prioritise prevention, will design the handling to be fast, and will communicate with the customer honestly about what happened and when it will be fixed. Scheme rules add another layer to the timeline. In SEPA, a credit transfer that is rejected must be notified to the originator within one business day, and a recall must be answered within fifteen business days. In the SWIFT gpi service, a bank must process a payment on the same day and must confirm the credit to the beneficiary, and a failure to do so is a breach of the gpi rules. In the United Kingdom, the Payment Systems Regulator expects banks to handle payment exceptions promptly and to keep the customer informed. The analyst must know which scheme rules apply to each corridor and must build the timelines into the system, with alerts when a deadline is approaching and escalation when a deadline is missed. The analyst should design the timeline monitoring as a system feature, not as a manual process. Every exception should have a due date, calculated from the scheme rules and the bank's own service levels. The system should show the exceptions that are approaching their due date, should alert the operations team, and should escalate automatically when a due date is missed. The report should show the average resolution time by exception type, by reason code, and by corridor, so that the analyst can identify the slow areas and fix them. A bank that does not measure its exception timelines cannot improve them, and a bank that does not improve them will lose customers to banks that do. There is one more cost that the analyst must consider: the cost of a failed exception. If a return is not processed, the funds sit in a suspense account, and the customer does not get their money back. If a recall is not sent in time, the funds are withdrawn and cannot be recovered. If an investigation is not followed up, the payment is lost and the customer must be compensated. Each of these is a failure of the exception process itself, and the analyst must design controls to prevent them. The controls include ageing reports, escalation rules, and a daily review of all open exceptions. The analyst who designs the exception process must also design the controls that ensure the process is followed, because a process without controls is a process that will fail silently. A customer who is surprised by a charge is a customer who will complain, and a complaint about a charge is harder to resolve than the exception itself. The analyst must therefore ensure that the customer is told upfront what an exception will cost, in the payment terms and conditions, on the payment screen, and in the exception notification. The notification should show the original amount, the amount returned, the charges deducted at each step, and the reason for each deduction. That level of transparency is not just good customer service, it is a regulatory requirement in many jurisdictions, and it is the standard that a professional payments operation should meet.