SEPA - SCT / Learning brief
SEPA Credit Transfer – Recall Flow
Your notes
In simple terms / 01
What this means in plain language
Explains how an earlier SEPA transfer may be recalled and distinguishes unsettled, positively answered, and negatively answered recall paths.
A SEPA Credit Transfer recall is a request to recover an earlier payment after the originator side identifies a valid reason to seek its return. It is not an automatic reversal. The request follows the payment route toward the beneficiary PSP, which checks the payment state and applicable scheme conditions. An unsettled instruction may follow a different cancellation path, while a settled payment needs a response from the receiving side. The outcome can be positive, negative, or unresolved, so operations teams must track both the request and its answer.
Complete lesson / 02
Understand the full idea, step by step
Imagine paying a supplier, then noticing the same invoice went out twice. The second payment is perfectly valid — it settled, the money reached the beneficiary. You did not make an error the banks could catch; you changed your mind about a payment that already worked. Getting that money back is not a reversal you can command. It is a recall: a polite, formal request that the other side is free to refuse.
The recall at a glance
- Original payment
- SCT, EUR 6,300.00, settled and credited
- Who asks
- The originator's side — Bank Alfa, for Asha Traders
- Reason
- Duplicate payment (DUPL)
- Request message
- camt.056 cancellation request
- Whose consent is needed
- The beneficiary's — the supplier at Nordbank
- If accepted
- A return (pacs.004) sends the money back
Recall — a request from the payer's side to get a completed payment back
A recall is initiated by the originator's side asking for an earlier, already-completed transfer to be sent back — typically for a duplicate, an obvious technical error, or suspected fraud. In SEPA it is carried by the camt.056 cancellation request. The essential word is *request*: unlike a return, which the beneficiary's bank starts because it cannot apply a credit, a recall reaches into a payment that worked, so it needs the beneficiary's agreement.
A request, not a reversal — consent is not guaranteed
Once money is credited to the supplier, it is the supplier's money, sitting in the supplier's account at Nordbank. No amount of messaging lets Bank Alfa or Nordbank simply take it back. Nordbank receives the camt.056, and it must check with the beneficiary and confirm the funds are available before agreeing. If the supplier consents, Nordbank sends the money back as a return. If the supplier refuses — or the funds are gone — the recall is declined, and Asha Traders is left to pursue the matter another way. A recall opens a case; it does not promise an outcome.
How a recall travels
- CUSTOMER
Asha Traders spots the duplicate and asks Bank Alfa to recover the second EUR 6,300.00 payment.
- INSTRUCTION
Bank Alfa prepares a camt.056 cancellation request, quoting the original payment's references and the reason DUPL.
- MESSAGE
The camt.056 travels to Nordbank through the established route. It asks; it moves no money.
- VALIDATION
Nordbank checks the payment state, the reason, and whether the funds are still available — and asks the supplier for consent.
- SETTLEMENT
If the supplier agrees, Nordbank returns the money with a pacs.004, which settles back to Bank Alfa; Bank Alfa re-credits Asha Traders.
- NOTIFICATION
If consent is refused or funds are gone, Nordbank declines; Bank Alfa records the outcome and explains it honestly.
Read the steps as text
- 01MessageThe debtor initiates the transferDebtor (payer) → Bank Alfa (debtor agent) · pain.001
The customer instructs their bank to pay. A corporate typically sends a pain.001 file; a retail customer uses a banking channel that creates the same instruction internally.
- 02ProcessingBank Alfa validates the instructionBank Alfa (debtor agent)
The debtor agent checks the format, the IBAN, available funds, and runs compliance screening before accepting the instruction for execution.
Screening checkpoint: Debtor-agent transaction screening — Names and remittance data are screened against sanctions lists before the payment goes interbank.
- 03PostingThe debtor's account is debitedBank Alfa (debtor agent)
Once accepted, Bank Alfa books the debit. The customer's money has left their account, but no money has yet moved between banks.
- DR Debtor's current account at Bank Alfa — EUR 12,500.00
- 04MessageBank Alfa submits the interbank transferBank Alfa (debtor agent) → Clearing & settlement mechanism · pacs.008
The debtor agent converts the customer instruction into an interbank pacs.008 and submits it to the clearing and settlement mechanism.
- 05Clearing obligationThe CSM calculates positionsClearing & settlement mechanism
The CSM validates the message and includes it in a clearing cycle. Each participant's obligations are calculated — this creates who-owes-whom, not yet a movement of money.
Clearing produces obligations. The banks do not have their money yet — that only happens at settlement.
- 06SettlementPositions settle in central bank moneyBank Alfa (debtor agent) → Nordbank (creditor agent)
The calculated positions settle across the banks' settlement accounts at the central bank. Only now has money finally moved between Bank Alfa and Nordbank.
- DR Bank Alfa settlement account — EUR 12,500.00
- CR Nordbank settlement account — EUR 12,500.00
- 07MessageThe CSM delivers the transfer to NordbankClearing & settlement mechanism → Nordbank (creditor agent) · pacs.008
The creditor agent receives the pacs.008 with full payment details so it can credit the right account.
- 08ProcessingNordbank validates and screens the incoming paymentNordbank (creditor agent)
The creditor agent checks that the account exists and can be credited, and runs its own sanctions screening on the incoming payment.
Screening checkpoint: Creditor-agent inbound screening — The receiving bank screens independently — it cannot rely on the sender's screening alone.
- 09PostingThe creditor's account is creditedNordbank (creditor agent)
Nordbank credits the beneficiary. The transfer is complete end to end: customer debited, banks settled, beneficiary credited.
- CR Creditor's current account at Nordbank — EUR 12,500.00
- 10 · EXCEPTION PATHProcessingBank Alfa detects the duplicateBank Alfa (debtor agent)
Reconciliation or a customer complaint surfaces the duplicate. A recall is a request, not a right — the money is in someone else's account now.
- 11 · EXCEPTION PATHMessageBank Alfa requests a recallBank Alfa (debtor agent) → Clearing & settlement mechanism · camt.056
A camt.056 cancellation request references the original pacs.008 and carries the duplicate reason code.
- 12 · EXCEPTION PATHMessageThe recall reaches NordbankClearing & settlement mechanism → Nordbank (creditor agent) · camt.056
The CSM routes the recall request to the creditor agent for a decision.
- 13 · EXCEPTION PATHProcessingNordbank reviews the recallNordbank (creditor agent)
The creditor agent checks the claim and, per the scheme's rules, may need the beneficiary's consent before taking money back. A refused recall is answered with a camt.029 instead.
- 14 · EXCEPTION PATHMessageNordbank answers positively with a returnNordbank (creditor agent) → Clearing & settlement mechanism · pacs.004
In this scenario the recall is accepted: the funds travel back as a pacs.004 referencing the recall.
- 15 · EXCEPTION PATHSettlementThe recalled funds settle backNordbank (creditor agent) → Bank Alfa (debtor agent)
The positive recall answer is settled like any return.
- DR Nordbank settlement account — EUR 12,500.00
- CR Bank Alfa settlement account — EUR 12,500.00
- OUTCOME
- Funds
- Recovered to Bank Alfa and re-credited to the duplicate's source account.
- Settlement
- Original settlement stood; the recall was answered by a separately settled return.
- Who acts next
- Bank Alfa (debtor agent) — Bank Alfa fixes the duplicate-detection gap that let the second instruction through.
ISO 20022 — ILLUSTRATIVE, NON-PRODUCTION
The camt.056 is a request, not a movement. Assgnr and Assgne name the bank asking and the bank being asked; the Undrlyg block quotes the original payment (OrgnlEndToEndId, OrgnlTxId, OrgnlIntrBkSttlmAmt); and CxlRsnInf/Rsn/Cd gives DUPL. Nothing here obliges Nordbank to comply — it identifies the payment and states the ground for asking.
WHAT IF — The supplier refuses consent, or has already spent the funds
What happens: The recall is declined. No money returns. The original payment stands as a valid, completed transfer.
How it is handled: Nordbank answers negatively with a reason. Maya at Bank Alfa closes the recall case with that outcome recorded, tells Asha Traders plainly that recovery was not possible through the scheme, and does not resend the same request hoping for a different answer. Any further recovery becomes a commercial or legal matter between the two businesses.
COMMON CONFUSION
“Sending a recall means the money is on its way back.”
A recall only opens a request. The money comes back only if the beneficiary consents and the funds are available. Telling a customer "recovered" the moment a recall is sent is one of the most dangerous mistakes in payment operations — the honest status is "requested, awaiting the other side".
STRICTLY SPEAKING
Strictly speaking, which reasons justify a recall, the window in which one may be sent, and the message a beneficiary bank uses to answer are all set by the scheme rulebook and can vary by rulebook version. Fraud-related recalls in particular follow specific handling. Read the current rulebook rather than assuming a fixed window or reason set.
FOR NOW, REMEMBER
- A recall is the originator's side asking for a completed, credited payment back — often a duplicate, error, or fraud.
- It is carried by a camt.056 and is a request, not a reversal: the beneficiary's consent is required and not guaranteed.
- If accepted, the money comes back as a return (pacs.004); if refused, the original payment stands.
- Never tell a customer funds are recovered when only a recall has been sent — the honest status is "requested".
TRY IT YOURSELF
Asha Traders asks Bank Alfa to recover a duplicate EUR 6,300.00 payment that already settled and was credited to the supplier. Bank Alfa has just sent the camt.056. What should the customer be told right now?
Reject, return, and recall all rely on status messages travelling back and forth. But there are two very different kinds of "yes" and "no" in a payment: one about whether a message was even accepted, another about whether the payment itself was. Untangling them is next.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
A recall asks for funds back; it does not guarantee recovery.
- 02
The payment state determines which operational path applies.
- 03
Both the request and final response need traceable references.
Practical use cases / 04
Where you would use this
A bank operations analyst traces a duplicate SCT from the original instruction through the recall response.
A payment-engine designer adds case states for pending, accepted, and refused recall outcomes.
A service agent explains to a customer why a submitted recall cannot promise an immediate refund.
Worked example / 05
Put the idea into a real situation
Suppose a customer reports that the same invoice was paid twice. The originator PSP verifies the duplicate, locates the original transfer reference, and sends a recall request along the established route. The beneficiary PSP reviews the case and returns its decision. If accepted, a return movement can follow; if refused, the originator receives the reason and updates the customer. This simplified example omits scheme-specific eligibility checks and local case-handling rules.
Operational sequence / 06
Follow the message and decision path
This compact sequence is a learning model. Exact routing and rulebook behavior can vary by scheme, participant, and implementation.
Read the steps as text
- 01MessageThe debtor initiates the transferDebtor (payer) → Bank Alfa (debtor agent) · pain.001
The customer instructs their bank to pay. A corporate typically sends a pain.001 file; a retail customer uses a banking channel that creates the same instruction internally.
- 02ProcessingBank Alfa validates the instructionBank Alfa (debtor agent)
The debtor agent checks the format, the IBAN, available funds, and runs compliance screening before accepting the instruction for execution.
Screening checkpoint: Debtor-agent transaction screening — Names and remittance data are screened against sanctions lists before the payment goes interbank.
- 03PostingThe debtor's account is debitedBank Alfa (debtor agent)
Once accepted, Bank Alfa books the debit. The customer's money has left their account, but no money has yet moved between banks.
- DR Debtor's current account at Bank Alfa — EUR 12,500.00
- 04MessageBank Alfa submits the interbank transferBank Alfa (debtor agent) → Clearing & settlement mechanism · pacs.008
The debtor agent converts the customer instruction into an interbank pacs.008 and submits it to the clearing and settlement mechanism.
- 05Clearing obligationThe CSM calculates positionsClearing & settlement mechanism
The CSM validates the message and includes it in a clearing cycle. Each participant's obligations are calculated — this creates who-owes-whom, not yet a movement of money.
Clearing produces obligations. The banks do not have their money yet — that only happens at settlement.
- 06SettlementPositions settle in central bank moneyBank Alfa (debtor agent) → Nordbank (creditor agent)
The calculated positions settle across the banks' settlement accounts at the central bank. Only now has money finally moved between Bank Alfa and Nordbank.
- DR Bank Alfa settlement account — EUR 12,500.00
- CR Nordbank settlement account — EUR 12,500.00
- 07MessageThe CSM delivers the transfer to NordbankClearing & settlement mechanism → Nordbank (creditor agent) · pacs.008
The creditor agent receives the pacs.008 with full payment details so it can credit the right account.
- 08ProcessingNordbank validates and screens the incoming paymentNordbank (creditor agent)
The creditor agent checks that the account exists and can be credited, and runs its own sanctions screening on the incoming payment.
Screening checkpoint: Creditor-agent inbound screening — The receiving bank screens independently — it cannot rely on the sender's screening alone.
- 09PostingThe creditor's account is creditedNordbank (creditor agent)
Nordbank credits the beneficiary. The transfer is complete end to end: customer debited, banks settled, beneficiary credited.
- CR Creditor's current account at Nordbank — EUR 12,500.00
- 10 · EXCEPTION PATHProcessingBank Alfa detects the duplicateBank Alfa (debtor agent)
Reconciliation or a customer complaint surfaces the duplicate. A recall is a request, not a right — the money is in someone else's account now.
- 11 · EXCEPTION PATHMessageBank Alfa requests a recallBank Alfa (debtor agent) → Clearing & settlement mechanism · camt.056
A camt.056 cancellation request references the original pacs.008 and carries the duplicate reason code.
- 12 · EXCEPTION PATHMessageThe recall reaches NordbankClearing & settlement mechanism → Nordbank (creditor agent) · camt.056
The CSM routes the recall request to the creditor agent for a decision.
- 13 · EXCEPTION PATHProcessingNordbank reviews the recallNordbank (creditor agent)
The creditor agent checks the claim and, per the scheme's rules, may need the beneficiary's consent before taking money back. A refused recall is answered with a camt.029 instead.
- 14 · EXCEPTION PATHMessageNordbank answers positively with a returnNordbank (creditor agent) → Clearing & settlement mechanism · pacs.004
In this scenario the recall is accepted: the funds travel back as a pacs.004 referencing the recall.
- 15 · EXCEPTION PATHSettlementThe recalled funds settle backNordbank (creditor agent) → Bank Alfa (debtor agent)
The positive recall answer is settled like any return.
- DR Nordbank settlement account — EUR 12,500.00
- CR Bank Alfa settlement account — EUR 12,500.00
- OUTCOME
- Funds
- Recovered to Bank Alfa and re-credited to the duplicate's source account.
- Settlement
- Original settlement stood; the recall was answered by a separately settled return.
- Who acts next
- Bank Alfa (debtor agent) — Bank Alfa fixes the duplicate-detection gap that let the second instruction through.
Evidence & review / 07
Evidence & review
SEPA Credit Transfer (SCT) scheme in the euro area; camt.056 recall requests and pacs.004 returns.
What this brief simplifies: A single duplicate-payment scenario. Eligible recall reasons, timeframes, fraud-specific handling, and the beneficiary bank's response message follow the current EPC rulebook; identifiers are illustrative.
Sources for this brief4
- Scheme-specific rule2025 version 1.1 (EPC125-05)
2025 SEPA Credit Transfer rulebook ↗ — European Payments Council · Recall procedure and beneficiary consent
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.
- Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · camt.056 FIToFI payment cancellation request; pacs.004 payment return
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
- Official requirement
ISO 20022 External code sets ↗ — ISO 20022 Registration Authority · Cancellation reason codes (e.g. DUPL)
Updated quarterly (end of February, May, August, and November) in XLSX, XSD, and JSON formats; always check the latest published version for valid codes.
- 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.