Returns: the money comes back

A return happens when a payment has been sent and the funds have moved, but the receiving bank cannot credit the beneficiary and sends the money back. The most common reasons are that the beneficiary account is closed, that the account number does not match the name, that the beneficiary bank cannot identify the account, or that the beneficiary has instructed the bank to refuse the payment. The receiving bank sends a return message, using a pacs.004 payment return in ISO 20022, which carries the original reference, the UETR, the amount returned, and the reason code. The funds travel back through the chain, and each bank in the chain must process the return and pass it on, until the funds reach the sending bank, which credits the sender's account. The reason codes for a return are the same catalogue as for a reject, and the analyst must know them. AC01 means incorrect account number. AC04 means closed account. AC06 means blocked account. MD07 means end customer deceased. AG01 means transaction forbidden. AM05 means duplication, which means the payment was sent twice and the second one is being returned. BE05 means unrecognised beneficiary. Each code is carried in the pacs.004 in the Rsn element, and the system must translate the code into plain language for the customer. A return with reason code AC04, closed account, means the beneficiary must give a new account number. A return with reason code AM05, duplication, means the sender should check whether the payment was sent twice and should not resend it. Returns take time, because the funds must travel back through the same chain they came through, and each bank adds its processing time. A payment that took two days to go out can take two to five days to come back, and the customer must be told that the return is in progress and when it is expected. The amount returned may be less than the amount sent, because banks in the chain may deduct their charges from the return, and because a currency conversion on the way back may use a different rate. The analyst must design the return handling to match the return to the original payment by UETR, to calculate the amount actually returned, to identify any deduction, and to notify the customer with the amount and the reason. Take a worked example. A customer sends USD 10,000 with SHA charges. The sending bank charges USD 25, the correspondent charges USD 25, and the beneficiary bank charges USD 15, so the beneficiary should receive USD 9,960. But the beneficiary account is closed, so the beneficiary bank returns USD 9,960. The correspondent bank deducts USD 25 from the return, so the sending bank receives USD 9,935. The sending bank deducts its own USD 25 return fee, so the customer receives USD 9,910 back. The customer sent USD 10,025 and receives back USD 9,910, a loss of USD 115. The customer who sent USD 10,000 and receives USD 9,910 back needs to know why USD 115 is missing, and the answer must be in the notification, not discovered by the customer when they check their balance. Returns also create a reconciliation task, because the sending bank must match the returned funds to the original payment and to the customer account. If the return arrives with a different reference, or if the amount is different, the reconciliation team must investigate and allocate the funds manually. The analyst must specify the matching rules, the handling of partial returns, and the escalation for returns that cannot be matched. A return that sits unallocated in a suspense account is a customer whose money is missing, and the longer it sits, the angrier the customer becomes. The return process is therefore not just an operations task. It is a customer service task, and the analyst must treat it as one. A partial return is a specific case that the analyst must design for. Sometimes the beneficiary bank returns only part of the payment, for example because part of the amount was already credited or because the beneficiary has instructed a partial refusal. The pacs.004 carries the amount returned, which may be less than the original amount, and the system must record the partial return, must update the payment status to partially returned, and must tell the customer how much was returned and how much is still outstanding. The customer must then decide whether to accept the partial return or to pursue the remainder, and the analyst must ensure that the system does not treat a partial return as a full return, because that would close the payment incorrectly. The return handling must also cover the case where the return is for a payment that was already recalled or investigated. If a recall is in progress and the payment is returned, the recall should be closed, because the funds have come back through the return. If an investigation is in progress and the payment is returned, the investigation should be updated with the return information and closed. The system must link the return, the recall and the investigation by UETR, so that operations sees a single view of the payment and its exceptions, not three separate items. A payment with a return, a recall and an investigation that are not linked is a payment that will be handled three times by three different people, and the customer will receive three different answers. The timeline for a return should be communicated clearly. The beneficiary bank should send the return within one business day of identifying the problem. The funds should travel back through the chain within three to five business days. The sending bank should credit the customer within one business day of receiving the funds. The total time from the original payment to the customer receiving the returned funds can therefore be five to ten business days, and the customer must be told that at the start. A customer who is told five to ten days and receives the funds in seven days is satisfied. A customer who is told two days and receives the funds in seven days is angry. The timeline is part of the product, and the analyst must set it honestly.