R-transactions: reject, return, recall

IN ONE LINE

An everyday analogy: three different things can interrupt a delivery.

The sorting office can refuse the parcel before it ever goes out — wrong address format, van already full: that is a reject, and nothing has really happened yet.

The recipient's post office can accept it and then send it straight back — nobody by that name here: that is a return, and the parcel makes a real journey home.

Or, days later, the sender can ring up and ask for the parcel back — I sent it twice by mistake: that is a recall, and here the recipient's side gets a say, because the parcel is already theirs.

SEPA gives each of these its own message, its own rules, and its own deadlines — together they are the R-transactions.

WHAT IT ACTUALLY IS

R-transactions are the SCT scheme's exception procedures, and the three to know are separated by one question: has settlement happened yet? A reject stops the payment before settlement — the CSM or the beneficiary bank refuses it, a negative pacs.002 travels back, and the money never moved between the banks.

A return happens after settlement: the beneficiary bank received the funds but cannot or will not credit them — the account is closed, for instance — so it sends the money back with a pacs.004.

A recall is different in kind: nothing was wrong with the payment itself, but the originator's bank wants it back — duplicate, technical error, fraud — so it sends a camt.056 request.

The beneficiary bank answers with either a pacs.004 returning the funds or a camt.029 refusing.

A recall is a request, never a guarantee.

HOW IT WORKS

Operations teams treat the three families very differently because the funds are in different places.

After a reject, the originator was usually never debited, or is re-credited promptly — a data-quality fix and resubmission problem.

After a return, real money came back: it must be matched to the original payment, the customer re-credited, and the reason code — drawn from the ISO 20022 external code sets — recorded, because recurring reasons point at broken reference data.

A recall opens a case that can stay open for days: the beneficiary bank may need its customer's consent before debiting an account that was legitimately credited, and the answer may be no.

Teams never promise that recalled funds will come back, and never close a recall case just because the request was sent.

In SCT Inst the same logic applies at higher speed: rejects arrive within the timeout window, in seconds.

THE WORDS

R-transaction

Any SEPA exception whose name starts with R — reject, return, recall, and related flows that refuse, reverse, or reclaim a payment.

Reject

An exception in which a payment is refused before settlement, so it never reaches the beneficiary's account.

Return

An exception in which a settled payment is sent back by the beneficiary's bank, with a reason code, as a new settlement movement.

Recall

A request by the sending side to get a settled payment back — the receiving side investigates and may agree or refuse.

READ FIRST

• The SCT lifecycle

CONNECTED TO

• FLOW SEPA Credit Transfer
• FLOW SEPA Instant Credit Transfer
• pacs.002 pacs.002 — FI to FI Payment Status Report
• pacs.004 pacs.004 — Payment Return
• camt.056 camt.056 — FI to FI Payment Cancellation Request
• camt.029 camt.029 — Resolution of Investigation
• CHECKPOINT SEPA exceptions checkpoint
• COMPARE Reject vs return vs recall
• EXCEPTION LAB The account is closed: a returned SCT
• EXCEPTION LAB Paid twice: recalling a duplicate SCT
• EXCEPTION LAB The beneficiary bank says no: an instant payment rejected in seconds
• EXCEPTION LAB We want it back, they say no: a refused SCT Inst recall

SOURCES

• 2025 SEPA Credit Transfer rulebook — European Payments Council
• 2025 SEPA Instant Credit Transfer rulebook — European Payments Council
• Clarification paper on SEPA Credit Transfer and SEPA Instant Credit Transfer rulebooks — European Payments Council
• Payments Signal editorial teaching models — Payments Signal