Investigation: cancellation before the money moves

A cancellation investigation starts when the sender asks for a payment to be stopped before it is credited to the beneficiary, and the request is sent as camt.056, and the difference from a recall is that the money has not yet reached the beneficiary, so the bank that holds it can stop it without asking the beneficiary. The cancellation window is short: it opens when the payment is sent and closes when the payment is credited, and a cancellation that arrives after the credit is not a cancellation, it is a recall, and it needs the beneficiary agreement. The skill is to act inside the window, and the investigation is about whether the window is still open. Source: ISO 20022 camt.056 and camt.029 definitions; SWIFT CBPR+ usage guidelines; EPC SCT Rulebook 2025. Why cancellation exists is that a payment can be instructed in error, and the error is often discovered minutes after the instruction, when the payment is still in transit. A corporate treasurer may instruct EUR 90,000 to the wrong supplier, realise it at once, and ask the bank to stop it, and if the bank can stop it before it is credited, the money never leaves the bank, and there is no recovery to pursue. Without cancellation, the only remedy would be a recall, which needs the beneficiary agreement, and the wrong supplier may not agree, so the money would be lost. Cancellation is therefore the cheapest remedy, and it is also the most time-sensitive, because the window is measured in hours, not days. The parties are the debtor bank, which sends the cancellation, the intermediary banks, which must stop forwarding the payment, and the creditor bank, which must stop crediting it. The beneficiary is not a party, because the money has not reached them, and their agreement is not needed. The messages are camt.056 for the cancellation request, camt.029 for the resolution, which states whether the cancellation was accepted or rejected, and pacs.004 for the return of funds if the payment had already been received by the creditor bank but not yet credited. In the legacy MT world the request was MT192, and the answer was MT196, and those names are still used in older case files. How a cancellation runs is shown by a worked example. A company in Dublin instructs EUR 90,000 to a supplier in Warsaw on Monday at 09:00, realises at 09:20 that the supplier name is wrong, and asks its bank to cancel it. The Dublin bank sends camt.056 at 09:30 to its correspondent, which confirms at 10:00 that it has not yet forwarded the payment, and stops it. The Dublin bank sends camt.056 to the next bank at 10:15, which confirms at 10:45 that it has received the payment but has not credited the beneficiary, and returns it by pacs.004 at 11:00. If the same request had arrived at 14:00, after the credit, it would have been a recall, and the outcome would have depended on the beneficiary. On success the payment is stopped, the funds are returned, and the case closes with the cancellation confirmed and the root cause recorded. On failure the cancellation arrives after the credit, and the camt.029 rejects it with a reason code stating the payment is already credited, and the sender must then send a recall, which needs the beneficiary agreement, and the recovery becomes slower and less certain. The most expensive failure is a cancellation that is sent but never acted on, because a bank in the chain did not read it, and the payment is credited anyway, and then the sender has both a failed cancellation and a recall to pursue, and the bank must explain why the cancellation was ignored. The data in a camt.056 cancellation is the original payment identification, the UETR, the amount, the reason for the cancellation, and the requester identification. The reason is the field that matters, because a cancellation for a wrong beneficiary, a duplicate or a fraud is handled with different urgency, and a cancellation for fraud must be acted on immediately, while a cancellation for a wrong amount can wait for the next processing window. A BA must specify the cancellation reasons, the window, the camt.056 flow, the camt.029 resolution, and the conversion to a recall when the window has closed, because a cancellation that is rejected as too late, with no recall offered, leaves the customer with nothing. Edge cases show the depth. A cancellation for a payment that is held for compliance screening must be handled by the compliance team, because the payment cannot be stopped by operations while compliance holds it, and the two teams must coordinate. A cancellation for an instant payment is almost impossible, because the payment is credited in seconds, so the window is seconds, not hours, and the bank must tell the customer that an instant payment cannot be cancelled, only recalled, and the recall needs the beneficiary agreement. A cancellation that is sent twice must be deduplicated, or the second cancellation will be treated as a new request and will confuse the case file. The effect on the bank is a cancellation queue that must be worked in minutes, not hours, because the window is short, and a manager who can see how many cancellations are open and how old they are. The effect on the customer is the difference between money that never left and money that must be recovered, and the difference is usually the speed of the request. The effect on operations is a process that must run around the clock for instant payments, because a cancellation requested at 22:00 for an instant payment is already too late, and the customer must be told so immediately. What a BA, PO or SME must understand is that cancellation is a stop before credit, recall is a request after credit, and the window between them is the whole topic. The requirement must name the window, the camt.056 flow, the camt.029 resolution, the conversion to recall, and the customer message for each outcome. The test is to send one cancellation for a payment in transit, track it hop by hop, and state whether it was stopped or whether the window had closed, because if the window cannot be stated, the process is not designed. Further reading: ISO 20022 camt.056 and camt.029; EPC SCT Rulebook 2025; SWIFT CBPR+ usage guidelines. Last reviewed 7 November 2026.