Recalls: asking for the money back

A recall, also called a payment recall or a request for recall, happens when the sending bank asks the receiving bank to return a payment that has already been credited to the beneficiary, usually because the payment was sent by mistake, was sent to the wrong beneficiary, was sent for the wrong amount, or was sent as a result of fraud. The sending bank sends a recall message, using a SWIFT MT192 request for cancellation or a camt.056 FI to FI payment cancellation request in ISO 20022, which carries the original reference, the UETR, the amount, and the reason for the recall. The recall is a request, not an instruction, and the receiving bank can refuse it. The recall is not guaranteed to succeed, and the analyst must make that clear to the customer. If the beneficiary has already withdrawn the funds, there is nothing to recall, and the sending bank cannot recover the money through the payment system. If the beneficiary disputes the recall, the receiving bank may refuse, and the sender must pursue the matter through legal channels or through negotiation with the beneficiary. If the recall is for fraud, the receiving bank may be able to freeze the account and return the funds, but only if it acts quickly and only if the funds are still there. The time factor is critical. A recall sent within hours has a good chance of success, a recall sent after days has a poor chance, and a recall sent after weeks is usually futile. The recall process has a defined message flow that the analyst should know. The sending bank sends a camt.056 to the receiving bank. The receiving bank investigates, contacts the beneficiary, and responds with a camt.029 resolution of investigation, which says whether the recall is accepted or rejected, and if accepted, how much will be returned. If the recall is accepted, the receiving bank sends a pacs.004 return for the amount, less any charges. If the recall is rejected, the camt.029 carries the reason, for example that the funds have already been withdrawn or that the beneficiary disputes the recall. The sending bank must record the camt.029, update the payment status, and notify the customer of the outcome. Recalls also have a cost, and the question of who pays is part of the design. The sending bank may charge a fee for processing the recall, the receiving bank may charge a fee, and the intermediary banks may charge for handling the recall message. If the recall fails, the customer may have paid the recall fee and still not recovered the money. The analyst must include the recall fee, the timeline, and the likelihood of success in the customer communication, so that the customer can make an informed decision about whether to request a recall. A customer who is told that a recall is free and certain will be disappointed. A customer who is told that a recall costs a fee, takes days, and may not succeed will make a better decision and will trust the bank more. A recall for a duplicate payment, where the same payment was sent twice, is usually straightforward, because the beneficiary can see the duplicate and will usually agree to return it. A recall for a wrong beneficiary, where the payment went to the wrong person, is harder, because the beneficiary may not agree to return it, and the bank cannot take money from an account without the account holder's consent. A recall for fraud, where the payment was the result of a scam, is the most urgent, because the funds must be frozen before they are withdrawn, and the bank must act within hours, not days. A recall for a wrong amount, where the payment was for USD 10,000 but should have been USD 1,000, is usually resolved by returning the excess, if the beneficiary agrees. In SEPA, a recall for a credit transfer must be sent within ten business days of the original payment for duplicate sending or a technical problem, or within 13 months for a fraudulently originated payment, and the receiving bank must respond within fifteen business days. Source: EPC 2025 SEPA Credit Transfer Rulebook, version 1.1, effective 5 October 2025, sections 4.3.2.3 and 4.3.2.4. In the SWIFT system, there is no fixed time limit, but the likelihood of success falls sharply after a few days. In the United Kingdom, the Faster Payments recall process has its own time limits. The analyst must include the time limit in the customer communication, and must ensure that the system does not accept a recall request that is outside the scheme limit without telling the customer that it is unlikely to succeed. A recall requested after the time limit is a recall that will fail, and the customer should be told that before they pay the fee. The analyst must also design for the case where the recall is for a payment that was sent as part of a cover payment. In that case, the recall must be sent to the beneficiary bank, which received the instruction, and the funds leg must be traced separately. If the cover funds have already been delivered, the recall is about the beneficiary credit, not about the cover leg. If the cover funds have not yet arrived, the recall may be able to stop them, which is faster and more certain. The system must therefore link the recall to both the instruction leg and the funds leg, by UETR, and must show operations both legs so that they can decide the best course of action. A customer sends USD 50,000 to the wrong beneficiary because of a copy and paste error in the account number. The customer notices the error within an hour and calls the bank. The receiving bank receives it, contacts the beneficiary, and finds that the funds are still in the account. The beneficiary agrees to the return, the receiving bank sends a pacs.004 for USD 50,000 less a USD 25 charge, and the customer receives USD 49,975 back within two business days. The same recall sent three days later would have found the funds already withdrawn, and the customer would have had to pursue the beneficiary through legal channels, at far greater cost and with no guarantee of success. The difference between the two outcomes is hours, and that is why the recall process must be fast.