SEPA - SCT / Learning brief
SEPA Credit Transfer – Reject Flow
Your notes
In simple terms / 01
What this means in plain language
Describes who can reject an SCT before inter-PSP settlement, why rejection occurs, and how status travels back to the originator.
A rejection stops a SEPA Credit Transfer before inter-PSP settlement. It can arise when a participant or clearing mechanism detects a problem such as invalid data, an unsupported route, or a failed control. The rejecting party sends status information back toward the originator, using references that connect the decision to the original instruction. Because funds have not completed settlement, the operational treatment differs from a post-settlement return. Good handling means presenting a useful reason, releasing or correcting any customer-side reservation, and preventing the same faulty instruction from being resent unchanged.
Complete lesson / 02
Understand the full idea, step by step
You send a transfer, and within the hour it is back — the app says the payment did not go through, and your balance is untouched. Nothing was lost, nothing arrived at the other side. What happened is called a reject, and it is the tidiest way a payment can fail: caught before any money moved between banks.
The reject at a glance
- Scheme
- SEPA Credit Transfer (SCT)
- Payer
- Asha Traders — account at Bank Alfa
- Payee bank
- Nordbank (creditor agent)
- Amount
- EUR 8,750.00
- Outcome
- Rejected before interbank settlement
- Status message
- pacs.002 with transaction status RJCT
Reject — a negative status that stops a payment before the banks settle it
A reject is a payment that is refused before interbank settlement. Because settlement never happened, no money moved between Bank Alfa and Nordbank, so nothing has to be sent back — the payment is simply stopped and a negative status returns to the sender. In the SEPA scheme, rejects and their siblings (returns, recalls) are grouped together as R-transactions: the exception paths that describe a payment not completing the plain happy way.
Where a reject can be caught — and who sends it
A reject can be raised at more than one point. Bank Alfa, the debtor agent, may refuse its own customer's instruction at validation — bad account data, a failed control, or not enough money to cover it — in which case the customer is told and nothing ever goes interbank. Or the instruction may travel on, and the clearing system or Nordbank refuses it before settlement: then a status message travels back along the route to Bank Alfa. The rule that ties every case together is the timing: a reject is any refusal that lands before the money settles. Who sends it depends only on who first sees the blocker.
A reject caught before settlement
- INSTRUCTION
Asha Traders instructs Bank Alfa to pay EUR 8,750.00 to the supplier at Nordbank, and Bank Alfa accepts the instruction for execution.
- MESSAGE
Bank Alfa submits an interbank pacs.008 toward the clearing system, which will pass it to Nordbank. Information moves; no money has settled yet.
- VALIDATION
Before the banks settle, the receiving side finds a blocker it cannot process — for example, the beneficiary account cannot be credited. It refuses the payment.
- NOTIFICATION
A pacs.002 carrying transaction status RJCT and a reason code travels back to Bank Alfa, tied to the original instruction by its identifiers.
- CUSTOMER
Bank Alfa releases any hold, leaves Asha Traders' balance whole, and reports the failure in plain terms — the payment did not complete.
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.
- 03 · EXCEPTION PATHProcessingBank Alfa refuses the instructionBank Alfa (debtor agent)
Validation fails on available funds. Because nothing has gone interbank yet, this is the cheapest possible failure point — nothing needs to be unwound.
- 04 · EXCEPTION PATHMessageThe debtor receives a rejection statusBank Alfa (debtor agent) → Debtor (payer) · pain.002
A pain.002 status report tells the customer the instruction was rejected and carries a reason code so the failure can be fixed.
- OUTCOME
- Funds
- Never left the debtor's account — no debit was booked.
- Settlement
- No interbank clearing or settlement occurred.
- Who acts next
- Bank Alfa (debtor agent) — The debtor funds the account or amends the instruction and resubmits.
ISO 20022 — ILLUSTRATIVE, NON-PRODUCTION
A pacs.002 payment status report carries the verdict, not money. Notice TxSts is RJCT, the Rsn/Cd gives a reason code (here AC01, incorrect account number — a validation failure caught before settlement), and the OrgnlEndToEndId and OrgnlTxId fields point back to the exact original payment. The receiving bank sends this; Bank Alfa matches it to Asha Traders' instruction by those references.
COMMON CONFUSION
“A reject means the money went out and came back to me.”
In a reject, the money never settled between the banks in the first place — there is nothing to come back. That is what separates a reject from a return, which you will meet next: a return is money travelling back after it had already settled. Same customer complaint ("my payment failed"), two very different journeys underneath.
STRICTLY SPEAKING
Strictly speaking, the reason codes carried in a reject come from the ISO 20022 external code list, and which failures can be rejected before settlement versus must be handled as a return afterwards depends on the scheme rulebook and the clearing system in use. A practitioner reads the code, but also checks whether settlement had occurred before deciding the payment truly stopped clean.
FOR NOW, REMEMBER
- A reject stops a SEPA Credit Transfer before interbank settlement, so no money moved and nothing has to be sent back.
- It can be raised by the sending bank at validation, or by the clearing system or receiving bank before settlement.
- The verdict travels as a pacs.002 with status RJCT and a reason code, tied to the original by its identifiers.
- Reject is not the same as return: return is money coming back after settlement already happened.
TRY IT YOURSELF
Bank Alfa receives a pacs.002 with status RJCT for Asha Traders' EUR 8,750.00 payment, and its own records show the interbank settlement for that payment never took place. What is the accurate next step to tell the customer?
A reject is the clean case — caught before the money settled. But what if the payment had already settled and reached the beneficiary's bank when the problem was found? That needs a different message travelling the reverse route: the return.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
A reject occurs before inter-PSP settlement completes.
- 02
Status references must identify the affected instruction clearly.
- 03
Actionable reasons help repair data and avoid repeated failures.
Practical use cases / 04
Where you would use this
A clearing operations team investigates a batch of SCTs rejected for an unsupported participant route.
A channel designer converts technical rejection details into a clear customer-facing status.
A QA analyst tests whether rejected items release reserved funds and retain audit evidence.
Worked example / 05
Put the idea into a real situation
A customer submits a transfer with destination details that fail a required validation at the clearing stage. The payment is not settled. A negative status travels back using the original reference, and the originator PSP marks the instruction as rejected. Its channel shows a plain-language explanation and allows corrected details to be entered. This example is intentionally simplified; the rejecting party, message choice, and repair options depend on the actual scheme and bank design.
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.
- 03 · EXCEPTION PATHProcessingBank Alfa refuses the instructionBank Alfa (debtor agent)
Validation fails on available funds. Because nothing has gone interbank yet, this is the cheapest possible failure point — nothing needs to be unwound.
- 04 · EXCEPTION PATHMessageThe debtor receives a rejection statusBank Alfa (debtor agent) → Debtor (payer) · pain.002
A pain.002 status report tells the customer the instruction was rejected and carries a reason code so the failure can be fixed.
- OUTCOME
- Funds
- Never left the debtor's account — no debit was booked.
- Settlement
- No interbank clearing or settlement occurred.
- Who acts next
- Bank Alfa (debtor agent) — The debtor funds the account or amends the instruction and resubmits.
Evidence & review / 07
Evidence & review
SEPA Credit Transfer (SCT) scheme in the euro area; reason codes per the ISO 20022 external code set.
What this brief simplifies: Uses a single fictional scenario and one reject point. Real rejects can arise at several stages and carry many reason codes; exact eligibility and code semantics follow the current EPC rulebook and the clearing system in use. Message identifiers are illustrative.
Sources for this brief4
- Scheme-specific rule2025 version 1.1 (EPC125-05)
2025 SEPA Credit Transfer rulebook ↗ — European Payments Council · R-transactions: reject handling and reason codes
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 External code sets ↗ — ISO 20022 Registration Authority · Payment status (RJCT) and rejection reason codes
Updated quarterly (end of February, May, August, and November) in XLSX, XSD, and JSON formats; always check the latest published version for valid codes.
- Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pacs.002 FIToFI payment status report
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
- 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.