Investigation: recall and cancellation

A recall investigation starts when the sender asks for the money back after the payment has been sent, and the request is sent as camt.056, and the answer, camt.029, says whether the return was accepted or rejected, and the whole process depends on the beneficiary agreement, because a payment that has been credited cannot be taken back without the beneficiary consent. Confusing recall and cancellation is the most common mistake in this area, and it wastes the window in which a cancellation would have worked. Source: ISO 20022 camt.056 and camt.029 definitions; SWIFT CBPR+ usage guidelines; EPC SCT Rulebook 2025 on recalls. Why recalls exist is that payments are sometimes sent in error, to the wrong beneficiary, for the wrong amount, or for a payment that should never have been sent, and the sender needs a way to ask for the money back. The recall is a request, not an instruction, because the beneficiary bank cannot debit the beneficiary account without the beneficiary agreement, except in narrow cases such as fraud, where the law allows it. The recall therefore has a timeline: it must be sent quickly, before the beneficiary spends the money, and it must carry a reason, such as duplicate, wrong beneficiary or fraud, because the reason decides how the beneficiary bank handles it, and a recall without a reason will be rejected. The parties are the debtor bank, which sends the recall, the creditor bank, which receives it and asks the beneficiary, the beneficiary, who must agree, and the intermediary banks, which forward the recall. The messages are camt.056 for the recall request, camt.029 for the resolution, which states whether the recall was accepted or rejected, and pacs.004 for the return of funds if the recall is accepted. In the legacy MT world the messages were MT192 for the cancellation request and MT196 for the answer, and a 15-year SME must know both, because the MT messages are still referenced in older case files and in reader discussions. How a recall runs is shown by a worked example. A company in Amsterdam sends EUR 22,500 to the wrong supplier on Monday at 09:00, realises the error at 09:30, and asks its bank to recall it. The bank sends camt.056 at 09:45, naming the original pacs.008, the UETR and the reason, wrong beneficiary. The beneficiary bank receives it at 10:00, asks the beneficiary, who agrees at 11:00, and returns EUR 22,500 by pacs.004 at 11:30. The total elapsed time was two hours, and the money is back the same day, because the recall was sent before the beneficiary spent it. If the same recall had been sent on Friday, after the beneficiary had paid its own supplier, the beneficiary would have refused, and the recovery would have been a commercial negotiation, not a payment message. On success the money is returned, the case closes, and the root cause, usually a wrong beneficiary detail, is recorded, so the payment is not sent to the wrong beneficiary again. On failure the beneficiary refuses, or the recall arrives after the money has been spent, and the camt.029 carries a rejection with a reason code, and the sender must then pursue the money commercially or legally, which can take months and may not succeed. The most expensive failure is a recall for fraud, where the beneficiary is the fraudster, because the fraudster will never agree, and the bank must use the fraud return process, which is a legal process, not a payment message, and the money is often gone before it starts. The data in a camt.056 is the original payment identification, the UETR, the amount, the reason for the recall, and the requester identification. The reason is the field that matters most, because a recall for duplicate, technical error or fraud is handled differently, and the EPC SCT Rulebook sets different time limits for each: a recall for a duplicate or technical error must be sent within 10 banking business days, a recall for fraud within 13 months, and the beneficiary bank has 15 banking business days to answer. A BA must specify the recall reasons the bank supports, the time limits, the customer message for each outcome, and the fallback when the recall is rejected, because a customer who is told only that the recall failed will call the bank. Edge cases show the depth. A cancellation sent after the payment has been credited is not a cancellation, it is a recall, and the bank must convert it, not reject it, or the window will be lost. A recall for a payment that was sent by an instant system is harder, because the payment is final in seconds, and the recall must be sent within minutes, so the recall process for instant payments must be automated, not manual. A recall where the beneficiary bank has already returned the payment by pacs.004 must be closed with the return reference, not kept open, or the case will be worked twice. The effect on the bank is a recall queue with deadlines, and a manager who can see how many recalls are open and how old they are, and which beneficiaries refuse most often. The effect on the customer is the difference between money back the same day and money lost for months, and the difference is usually the speed of the recall, so the bank must act in hours. The effect on operations is a process that must run in hours, not days, because a recall sent on day one succeeds and a recall sent on day five usually fails, and the service level must reflect that. What a BA, PO or SME must understand is that a recall is a request that needs the beneficiary agreement, a cancellation is a stop before credit, and the two must not be confused. The requirement must name the recall reasons, the time limits, the camt.056 and camt.029 flow, the pacs.004 return, and the fallback when the recall is rejected. The test is to send one recall for a wrong beneficiary payment, track it to the beneficiary bank, and state whether it was accepted or rejected and why, because if the reason cannot be stated, the process is not working. Further reading: ISO 20022 camt.056 and camt.029; EPC SCT Rulebook 2025 on recalls; SWIFT CBPR+ usage guidelines. Last reviewed 7 November 2026.