Articles / Learning brief
Reversals, returns, recalls, and cancellations
Your notes
In simple terms / 01
What this means in plain language
A consolidated view of undoing a payment: rejects before settlement, returns and reversals after it, and recall requests that ask the receiving side to send funds back. Each has a different trigger, message, and outcome.
Once a payment has been sent, several different mechanisms can undo it, and they are not interchangeable. Before the money settles, a bank can reject an instruction it cannot process. After settlement, a return sends the money back because the receiving side could not apply it, while a reversal is the sending side correcting its own mistake, such as a duplicate. A recall is a polite request: the sender asks the receiving bank to give the money back, and the receiving bank chooses whether to agree. A cancellation stops an instruction that has not yet completed. The key difference is who starts the process and whether the funds return automatically. Rejects, returns, and reversals move money without asking; recalls depend on cooperation and, once funds have reached a customer, on that customer agreeing. Knowing which tool applies avoids sending the wrong message and waiting for a result that will never come.
Complete lesson / 02
Understand the full idea, step by step
Everyone who has sent a payment has felt the small jolt of doubt a second after: wrong account? wrong amount? sent twice? What can actually be done next depends entirely on one thing — whether the money has settled yet. That single line splits the whole family of "undo" mechanisms in two.
The dividing line: before or after settlement
Before value settles, a wrong payment can be stopped in place — nothing has moved, so there is nothing to send back. After value settles, the money genuinely sits somewhere else, and undoing it means a fresh movement of value in the opposite direction, or a request to whoever now holds it. Every mechanism in this family is really an answer to one question: has settlement happened yet? Get that straight and the rest follows.
Reject
A reject is the earliest undo: a bank or clearing system receives an instruction it cannot process — a missing mandatory field, a non-existent account, a control that flagged it — and refuses it before value moves. In ISO 20022 (the international messaging standard) a reject is commonly carried in a pacs.002 payment status report with a negative status. No money settles, and nothing needs to be sent back. A closely related cancellation withdraws an instruction that is submitted but not yet completed — a single transaction or a whole batch still sitting in a queue.
Return — value sent back by the receiving side after settlement, in a pacs.004
Once money has settled, a return sends it back. It is initiated by the receiving side when it cannot apply the credit — a closed account, an invalid account number, a beneficiary refusing the funds. In ISO 20022 it is carried in the pacs.004 message: the original amount, minus any agreed charges, flows back to the sender with a reason code explaining why. A return is the receiving bank saying "I could not keep this."
ISO 20022 — ILLUSTRATIVE, NON-PRODUCTION
A pacs.004 return. Notice RtrdIntrBkSttlmAmt — the amount being sent back between the banks — and a reason code in RtrRsnInf (here AC04, a closed account). The return is itself a fresh interbank movement, not an erasure of the first.
| Mechanism | When | Who starts it | Message |
|---|---|---|---|
| Reject | Before settlement | Bank or clearing system that cannot process it | pacs.002 (negative status) |
| Return | After settlement | The receiving side (cannot apply the credit) | pacs.004 |
| Reversal | After settlement | The original sender (its own error) | pacs.007 |
| Recall / cancellation request | After settlement | The sender, asking the receiver to send funds back | camt.056, answered by camt.029 |
Recall (cancellation request) — a request asking the receiving side to return settled funds — not a right to reclaim them
When the sending bank made no processing error but the payment is still wrong — the customer typed the wrong beneficiary, or was defrauded — the funds legitimately belong, for now, to whoever received them. The sender cannot pull them back; it can only ask. In ISO 20022 this is a camt.056, a request to cancel a payment, answered by a camt.029, the resolution of investigation. The receiving bank must contact its own customer and seek agreement to return the money.
WHAT IF — The beneficiary has already spent the funds, or declines to return them
What happens: The recall fails: the camt.029 comes back negative. No value returns, because the money was neither the sender's to take nor the receiving bank's to seize.
How it is handled: Kabir and Maya's teams treat recalls as time-critical, especially in fraud cases — funds that have moved onward are far harder to retrieve. They act fast, document the request and the resolution, and follow the scheme's procedure, while being honest with the customer that a positive outcome is never guaranteed.
COMMON CONFUSION
“Sending a recall (camt.056) gets your money back — it is a refund button for a payment sent to the wrong place.”
A recall is a request, not a refund. The receiving bank must ask its customer to agree, and if the customer has spent the funds or refuses, the camt.029 is negative and nothing returns. Contrast this with a reversal, where the sending bank corrects its own error and the funds return without needing the beneficiary's consent — because there the sender, not the beneficiary, is the one saying the payment should not have happened.
STRICTLY SPEAKING
Strictly speaking, a reversal (pacs.007) is the mirror of a return: the original sender initiates it to correct its own mistake — a duplicate or a wrong amount released in a batch, exactly Maya's case — and because the sending institution accepts the payment should not have happened, the funds return without asking the beneficiary. In the Single Euro Payments Area (SEPA), these sit within defined recall and R-transaction procedures with set timeframes — often a limited business-day window for the originating bank to raise a recall. The exact rules, windows, and reason codes vary by scheme and jurisdiction, so confirm the rulebook for the rail in question.
FOR NOW, REMEMBER
- The whole family splits on one question: has settlement happened yet?
- Before settlement: a reject (pacs.002 negative) or a cancellation stops the payment in place — nothing to send back.
- After settlement, value returns as a fresh movement: a return (pacs.004) from the receiving side, or a reversal (pacs.007) from the original sender correcting its own error.
- A recall (camt.056, answered by camt.029) is only a request — it depends on the beneficiary's cooperation and can come back negative.
TRY IT YOURSELF
Maya confirms Bank Alfa released a supplier payment twice by its own batch error, and the money has already settled. Which mechanism fits, and why?
You now know the exception messages by name and trigger. The topic behind them goes deeper into the pacs family itself — how these interbank messages are structured, chained, and answered across a payment's life.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
Rejects happen before settlement; returns and reversals happen after it.
- 02
A reversal corrects the sender's own error, while a return comes from the receiving side.
- 03
A recall is a request the receiving bank can decline, not an automatic refund.
Practical use cases / 04
Where you would use this
An operations analyst chooses a return when an account is closed and cannot receive the credit.
A payments team sends a reversal after discovering a duplicate batch was released twice.
A fraud investigator raises a recall to ask a receiving bank to freeze and return misdirected funds.
Worked example / 05
Put the idea into a real situation
Illustrative example: a fictional bank, Meridian Trust, releases a EUR 8,400.00 credit transfer twice by mistake. For the duplicate, it sends a reversal because the error is its own, and the receiving bank returns the EUR 8,400.00 automatically within two business days. Separately, a customer reports a EUR 2,750.00 payment sent to the wrong beneficiary; here Meridian Trust can only send a recall request, and the receiving bank must contact its customer, who is under no obligation to agree.
Evidence & review / 07
Evidence & review
ISO 20022 exception messaging generally; recall and R-transaction timeframes and reason codes are scheme- and jurisdiction-specific (SEPA shown as an example).
What this brief simplifies: Groups a broad exception family into four clear cases and does not enumerate every reason code or scheme-specific timing parameter, which vary and change over time.
Sources for this brief3
- Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pacs.002, pacs.004, pacs.007, camt.056, camt.029
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
- Scheme-specific rule2025 version 1.1 (EPC125-05)
2025 SEPA Credit Transfer rulebook ↗ — European Payments Council · Recall and R-transaction procedures
Version 1.1 replaced version 1.0 at publication on 5 October 2025 and is stated to remain in effect up to 21 November 2027. It moves the date from which the unstructured address format is no longer permitted to 15 November 2026.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.