SEPA Return and Reject Codes: The R-Transaction Reference

A reference map of every material SEPA R-transaction type and reason code, covering all four schemes — SCT, SCT Inst, SDD Core, SDD B2B — with scheme applicability, timing windows, and operator action guidance. For a searchable, code-by-code version of the tables below, see the SEPA return-code lookup tool. For background on how the four SEPA schemes work — mandate lifecycle, submission deadlines, SCT Inst mandatory rollout — see SEPA Credit Transfer, Instant, and Direct Debit: Operator Guide. For how direct debit compares to ACH, Bacs, and eGIRO see Direct Debit Payments Explained.

Find a reason code

Have a code? Open the SEPA return-code lookup ↗

01SCTCredit transfer

Reject / Return. Recall and RFRO are separate recovery requests.

02SCT InstInstant credit transfer

Reject / Recall / RFRO. No ordinary Return procedure.

03SDD CoreDirect debit

Authorised-debit refund request: within eight weeks after account debit.

Unauthorised claim: separate 13-month limit and PSP examination.

04SDD B2BBusiness direct debit

No authorised-debit scheme refund right. Return is a separate procedure.

Mandate-related claims and other legal or contractual recourse remain distinct.

Selected distinctions only. A recovery request does not guarantee recovery. Check the original PSP record before retrying.

Sources: EPC SCT, SCT Inst, SDD Core, SDD B2B. Scope checked 27 October 2026.

Use the searchable SEPA return-code lookup if you have a code from a PSP or bank. Check the payment scheme and R-transaction type before deciding whether to retry; the same code can appear in different scheme contexts.

The lookup now has a labelled scheme choice and conditional guidance for RR04, MS03 and AM04. Select “Not sure” if the scheme is missing from the PSP record; ask for the scheme name and the actual R-transaction event rather than inferring them from the code. For example, AM04 in SDD Core is an insufficient-funds Return, while AM04 in SCT Inst is a negative Recall/RFRO response about beneficiary funds. Neither code selection establishes a universal deadline or permission to retry. The pilot cites EPC173-14 v8.1, EPC135-18 v6.1 and EPC059-18 v7.1 beside the applicable contexts; all existing codes remain in the HTML reference without JavaScript.

• AG01 — debit forbidden on the account: in SDD Core and B2B, EPC guidance includes a regulatory restriction on debiting the account. It is not proof of insufficient funds; ask the payer for another eligible account or payment method. A B2B collection sent to a consumer account has a separate code, AC13.
• RR03 — missing creditor name or address: check the creditor details and the applicable scheme. The current EPC SDD and SCT guidance permits Reject or Return, while SCT Inst uses RR03 for a Reject. An invalid or no-longer-allowed address format is one possible use case, not a universal address ban; the 2026 guidance removed an obsolete unstructured-address end-date reference.
• RR04 — regulatory reason: appears in SCT, SCT Inst and SDD guidance, but the permitted transaction types differ. RR04 alone does not identify a sanctions or AML finding. Preserve the original reference and ask the PSP what it can disclose and whether remediation is permitted.
• MS03 — reason not specified by the agent: applies in all four schemes, with different events: SDD and SCT Reject/Return; SCT Inst Reject. It does not reveal which underlying reason was withheld or whether retry is safe. Ask the PSP what can be disclosed and remedied before retrying.

The scheme-by-scheme explanation below covers why a code and a transaction type must be read together; the lookup pages provide the individual code records.

Worked case: RR04 on an SCT Inst attempt

Suppose a fictional payment ticket says SCT Inst · Reject · RR04 and a colleague asks whether to retry the transfer or report a sanctions hit. Read the three fields together before taking either step:

1. Record available: the scheme is SCT Inst, the exception is a Reject, and the reason is RR04. Under EPC059-18 v7.1, RR04 is a Reject reason for a regulatory reason other than the missing details covered by RR01–RR03. Preserve the bank's original payment reference and rejection record for the investigation.
2. Question it answers: this attempt was rejected; it is not evidence that an SCT Inst payment was settled and later returned. The code identifies a reason category, not the particular regulatory trigger.
3. What remains unproven: the ticket alone does not establish a sanctions or AML finding, who or what was flagged, or whether a corrected instruction would be accepted. The EPC lists AML, embargo and counter-terrorism-financing hits as potential causes, not as diagnoses of every RR04.
4. Next check: ask the originating PSP what it can disclose about the rejection, whether any data can be corrected, and whether resubmission is permitted. Keep automatic retries paused until that answer is clear. If the status or scheme in the ticket is uncertain, confirm the original bank record before treating it as this case.

This is an illustrative decision path, not a real transaction or a universal bank workflow. An SDD Core RR04 case has different permitted R-transaction types; check its scheme and exception before reusing the same decision. The RR04 code lookup shows the scheme-specific code record.

Hypothetical SDD Core refund

A fictional payer authorised an SDD Core collection and asks their bank for a refund three weeks after the account was debited. This is a debit-refund question, not the rejected SCT Inst transfer above. Under the SDD Core rulebook, the payer can request a refund of an authorised collection within eight weeks of the debit date. The MD06 lookup explains the refund-requested-by-end-customer reason.

For the creditor, match the bank's refund record to the original collection and mandate before updating the receivable. A refund does not by itself decide whether the underlying invoice remains payable, and it is not permission to collect again automatically. An unauthorised-debit claim follows a different examination path; SDD B2B does not offer this authorised-collection refund right. Confirm the scheme and debit date before applying the eight-week rule.

R-transaction types by scheme

Read the scheme before the event. The table groups the main exception procedures across schemes; it is not a list of procedures available in every scheme. Recall and RFRO are separate recovery requests, and a successful original settlement does not guarantee that either request will recover funds.

Reject vs Return: A Reject occurs before inter-PSP settlement; a Return occurs after inter-PSP settlement. Settlement between banks is not the same event as a credit to the beneficiary’s account. Reconcile the original payment and exception record before concluding what happened to the customer’s balance.

SCT Return: whole amount, but only before crediting. For SCT specifically, the rulebook guarantees that both a Reject and a Return move back the Original Amount of the Credit Transfer Instruction — no shortfall, no fee deducted in transit. It also marks a boundary that's easy to miss: a Return "must not be used in cases where the Beneficiary's account has already been credited and the Beneficiary wishes to return the funds. Instead, the procedure of initiating a new SEPA Credit Transfer applies." Once the beneficiary's account has actually been credited, sending the money back voluntarily is a new SCT in its own right — a fresh payment with its own reference and its own settlement, not an R-transaction. That distinction matters for reconciliation: a genuine Return identifies the original transfer by "the original reference of the Originator PSP", together with a record of the original transfer's data "sufficient to provide an audit trail" — the mechanism that lets a bank match returned funds back to what caused them. A beneficiary-initiated "send it back" payment carries none of that built-in linkage; matching it to the original transaction is manual reconciliation work, not something the R-transaction format does for you.

Refusal vs Reject: Refusal describes the debtor’s instruction not to pay a collection. When the bank handles it before inter-PSP settlement it generates a Reject; handling after settlement generates a Return. A Reject can therefore follow a debtor instruction as well as a technical or bank-side problem.

Recall and RFRO apply to SCT and SCT Inst only. They are not R-transaction types for SDD. See the Recall and RFRO section below for the two procedures and their reason codes.

Reversal applies to SDD Core and SDD B2B only. It is the creditor-initiated post-settlement cancellation of a direct debit collection. The SCT scheme does not define a Reversal R-transaction; the equivalent recovery mechanism for SCT is the Recall/RFRO procedure.

Scheme applicability matrix

R-transaction timing and deadlines

Sources: EPC SDD Core and B2B Rulebooks 2025 v1.2 (EPC016-06 / EPC222-07), and EPC Clarification Paper EPC131-17 v3.1. Account debit, inter-PSP settlement and receipt of a recovery request are different reference dates; do not substitute one for another.

SDD B2B Return versus refund. The three Inter-PSP Business Day limit is the deadline for Return settlement after collection settlement. It is not limited to technical faults. Separately, the scheme gives no debtor-requested refund right for an authorized B2B collection. Mandate-related unauthorized claims and other legal or contractual recourse must not be collapsed into a universal three-day irrevocability promise.

SCT recall and RFRO response obligation. Once a Recall or RFRO (camt.056) is received, the beneficiary bank has 15 banking business days to respond. If no response arrives within that window, the lack of response constitutes a breach of the SCT rulebook. The Recall and RFRO section below covers both procedures and their reason codes.

Reason code reference: SDD

The tables below follow the EPC's current scheme-specific guidance: EPC173-14 v8.1 (SDD), EPC135-18 v6.1 (SCT), and EPC059-18 v7.1 (SCT Inst), published 30 September 2026. These editions removed an obsolete unstructured-address end date from RR02/RR03; they did not introduce a new RR04 rule. A shared code name does not make every R-transaction type available in every scheme.

Account codes (AC)

AC04 note: Where national law restricts disclosure of a closed-account reason, the EPC SDD guidance allows the bank to substitute MS03. An MS03 does not itself establish that the account is closed. See the MS03 section below.

Amount and funds codes (AM)

AM04 note: The EPC SDD guidance also allows MS03 to substitute for AM04 where national law restricts disclosure. Do not infer insufficient funds from an MS03 alone.

Mandate codes (MD)

MD01 is the highest-signal mandate failure code. It means the debtor's bank checked and could not match the mandate data in the collection message to a valid registered mandate. For SDD B2B, where mandates are pre-registered at the debtor's bank, MD01 is particularly definitive — the bank explicitly verified and rejected.

MD06 is SDD Core only. It appears on the pacs.004 refund message and carries the 8-week window. There is no MD06 equivalent in SDD B2B. B2B mandate-related claims and inquiries are separate from the SDD Core authorized-refund route; ask the PSP which procedure applies.

Agent and format codes (AG / FF)

BE05 (incorrect Creditor Identifier) also appears in the EPC guidance as an agent-category reject, but is listed under party identification rather than the AG/FF grouping in ISO 20022 external code sets. It means the Creditor ID in the message does not match a registered creditor — a common failure in new SDD program setup.

Regulatory codes (RR)

RR01–RR04 identify regulatory reasons rather than an ordinary account or mandate error. For SDD, EPC173-14 v8.1 lists RR04 for a Reject or Return and directs the creditor to contact its PSP. An RR04 does not prove a sanctions hit, an AML finding, or misconduct by the debtor. Pause automatic retries, retain the payment reference and ask the PSP which action is permitted. SCT guidance mentions a potential AML, embargo or counter-terrorism-financing hit, but that is a possible root cause, not a diagnosis from the code alone. SCT Inst guidance uses RR04 for a Reject; do not infer a post-settlement Return from this code in SCT Inst.

RR02 and RR03: The current guidance includes an address format that is invalid or no longer allowed among possible use cases. The EPC delayed the planned 15 November 2026 end date for unstructured addresses and removed that date from its 30 September guidance. Do not reject a collection solely because that superseded date was once printed in an older edition. Check the currently applicable scheme implementation guidelines and which address fields are required for the particular transaction.

Debtor refusal and unspecified codes (MS / SL)

The MS03 masking point

MS03 leaves the underlying reason unspecified. EPC173-14 v8.1 permits its use in place of AC04, AM04, MD07 or RR01–RR04 where national law restricts disclosure. The code itself cannot tell you which reason was masked, whether the bank applied another internal control, or whether resubmission is safe. The current EPC guidance does not name a fixed list of affected countries or rank the possible hidden reasons by frequency.

Operational treatment: Retain the collection reference, ask the PSP what it can disclose and whether the underlying problem can be remedied, and pause automated retries until that is clear. If the customer independently confirms the account is closed, update the mandate status; do not infer closure from MS03 alone.

That paragraph concerns SDD. MS03 also appears in SCT as Reject/Return (EPC135-18 v6.1, p14) and SCT Inst as Reject (EPC059-18 v7.1, p16). Their MS03 rows cover national-law limits on AC04 or RR01–RR04 disclosure; separate MD07 rows also allow an MS03 alternative. Do not infer the hidden reason. In SCT, MS03 cannot replace RR04 in a negative Claim Non-Receipt inquiry response (v6.1, p18).

Reason code reference: SCT and SCT Inst

SCT and SCT Inst share many reason codes, but the permitted R-transaction type can differ. The current EPC guidance is EPC135-18 v6.1 for SCT and EPC059-18 v7.1 for SCT Inst, both published 30 September 2026.

For SCT, same-day is the norm rather than a hard ceiling: the rulebook requires Reject messages to be "transmitted on a same day basis" and, at the latest, "on the next Banking Business Day." Model retry and escalation logic on the outer limit, not the norm.

Account and format codes

The table below makes the SCT Inst context explicit, following EPC059-18 v7.1. Do not copy these uses into SCT or SDD without checking that scheme’s guidance.

SCT Inst-specific codes

AM02 on older messages: The 2025 SCT Inst inter-PSP and customer-to-PSP implementation guidelines removed AM02 from their negative-confirmation reason-code lists. If an older or provider-specific message still shows AM02, confirm its message layer and applicable rulebook with the PSP; do not interpret it as a current inter-PSP SCT Inst reject or as AM23. User-selected daily or per-transaction limits remain possible under Article 5a(6), but that fact does not restore AM02 to the current scheme code set.

Correction, 13 October 2026: the earlier AM02 entry incorrectly applied a package-size rule to transaction limits and presented AM02 as a current SCT Inst reject. The current implementation guidelines remove AM02; the current EPC guidance uses AM23 for an inter-PSP settlement-limit rejection. The cited Form3 link also no longer resolves.

These SCT Inst AB/AG entries describe Rejects, not ordinary post-settlement Returns. A time-out label is not proof that a new attempt is safe: preserve the original reference and obtain the PSP’s status confirmation before resubmitting. AG09 concerns a status investigation whose original payment was not received; AG10/AG11 can require a different route or beneficiary PSP, rather than a brief wait. For the failure-state handling and escalation path, see the SCT Inst rejection and timeout runbook.

Regulatory codes (shared SCT/SDD)

RR01–RR04 also appear in SCT and SCT Inst guidance, but the permitted transaction types differ. The current editions remove the superseded unstructured-address end date from RR02/RR03. Check the scheme-specific reason and R-transaction type rather than treating SDD, SCT and SCT Inst as identical.

SCT Recall and RFRO: two recovery procedures

Recovery of a sent SCT or SCT Inst is handled through two distinct procedures, both using camt.056 (Cancellation Request) and camt.029 (Resolution of Investigation). They differ in who initiates them, which reason codes they use, and how long the window is.

Does the money come back whole? Not always — and this is the real operational gap between a Return and a Recall. A Return, as above, is capped at the Original Amount; nothing is skimmed off it. A Recall carries no such guarantee: "The amount transferred back can differ from the Original Amount of the SEPA Credit Transfer Transaction. The Beneficiary PSP may decide to charge a fee to the Originator PSP". The two procedures are also initiated by different parties in different directions — a Return is sent by the beneficiary's bank without the originator asking for anything, while a Recall (or RFRO) is the originator's bank asking the beneficiary's bank to send funds back voluntarily. That second dynamic is exactly why the beneficiary's bank can charge for it: it's being asked to unwind an already-completed transfer, not correcting one that never should have credited in the first place. Model this in any recovery workflow — a successful Recall response is not automatically a full-value one.

Beneficiary response deadline (both procedures): 15 banking business days from receipt of the camt.056. Non-response within this window constitutes a rulebook breach.

Recall (bank-initiated)

The Recall procedure is initiated by the originator bank — not the customer directly. It covers three reason codes:

Initiation window: 10 banking business days from the execution date; FRAD extends to 13 months.

Request for Recall by the Originator (RFRO)

The RFRO is initiated by the customer via their originator bank. It covers situations where the customer sent the payment in error — wrong beneficiary IBAN, wrong amount, or a duplicate the customer identified. The originator bank passes the customer's request to the beneficiary bank via camt.056.

Original-payment eligibility: the original debit date must fall within the 13 months preceding the Originator PSP's receipt of the RFRO. EPC131-17 distinguishes that condition from the inter-PSP initiation timeline, which its section 2.12 table marks as not specified. Confirm the bank's customer submission cut-off.

RFRO vs Recall: The 13-month RFRO window is available for all customer-initiated reasons — not just FRAD. Refusal is not unique to either procedure: the rulebook gives a Recall (including a FRAD Recall) the same negative-response grounds as an RFRO — insufficient funds, a closed account, a legal reason, beneficiary's refusal, no response from the beneficiary within the deadline, funds already returned, or the initial transfer never having been received — so a FRAD Recall can be declined on the same basis as an RFRO, and for CUST/AM09/AC03 the beneficiary can likewise legitimately refuse if funds have already been applied. What actually differs is initiation: a Recall covers three bank-assessed reasons (DUPL, TECH, FRAD) — 10 banking business days for DUPL/TECH, 13 months for FRAD only — while an RFRO has the separate original-debit eligibility condition described above; it is not a promise of 13 months to complete every bank step.

Responses to both Recall and RFRO

Positive response (FOCR): If the beneficiary bank agrees, they send the funds back via pacs.004 with reason code FOCR (Return Following Cancellation Request). FOCR is the only valid reason code for a positive response.

Negative response codes (camt.029): If the beneficiary cannot or will not comply, they send a camt.029 with one of:

• NOOR — transaction not received (funds never arrived)
• ARDT — already returned (funds were already reversed)
• LEGL — legal decision prevents return
• AC04 — account closed (funds cannot be returned from a closed account)

Operator action table

For each code or category, the action required differs. This table covers the most common codes operators encounter in production.

Common failure patterns and reduction strategies

IBAN validation on mandate capture

AC01 (incorrect IBAN) and AC04 (closed account as proxy) are the most preventable codes. An IBAN check at mandate capture — verifying the check digit and country-format validity — eliminates the majority of AC01 failures before the first collection. Most PSPs (Stripe, GoCardless, Adyen) run IBAN validation automatically; direct integrations must implement it explicitly.

From October 2025, the EU's Verification of Payee (VoP) requirement mandates that PSPs check IBAN-to-name matches before executing outbound SCT and SCT Inst. This also reduces first-collection failures where customers accidentally provide an account belonging to someone else. See EU Instant Payments Regulation: The Compliance Timeline for VoP implementation details.

Mandate sequence hygiene

MD01 (no mandate) on recurring SDD collections is almost always a lifecycle management failure. The three common causes: the mandate was cancelled by the customer directly via their bank but the creditor's system was not notified; the SequenceType field was set incorrectly (FRST vs RCUR vs FNAL); or for SDD B2B, the mandate was not pre-registered at the debtor's bank before the first collection attempt.

Reconciling MD01 returns to the specific mandate reference and sequence type in the original message identifies which failure mode applies. A pattern of MD01 at FRST (first collection) typically indicates the pre-registration step was skipped for B2B, or the mandate was not stored correctly. A pattern of MD01 at RCUR typically indicates the customer cancelled at their bank.

Retry strategy for AM04 and MS03

AM04 identifies insufficient funds; it does not itself authorize another collection. Check the mandate, the bank’s re-presentation rules and the customer’s circumstances before deciding whether and when to retry. Do not turn a suggested retry interval or attempt count into a universal scheme rule.

MS03 requires clarification before retry. The debtor confirming an active account does not establish that the undisclosed reason is retriable. Ask the PSP what can be remedied; avoid turning an unspecified code into a closed-account or insufficient-funds diagnosis.

SDD Core refund window management

The 8-week SDD Core refund window is not a dispute mechanism — it requires no justification from the debtor. For subscription operators, this creates a two-month exposure window on every collection. Cash-flow planning should distinguish settled collections from potential refunds; the appropriate accounting treatment needs a separate finance assessment.

Practical mitigation: send clear pre-collection notifications (meeting the 14-day rulebook requirement or the shorter agreed period), ensure cancellation processes work cleanly so customers who want to cancel don't need to exercise the refund right, and track MD06 frequency as a customer satisfaction metric alongside chargeback rates.

B2B mandate pre-registration

The SDD B2B sequence is: (1) obtain mandate, (2) send mandate data to debtor's bank for registration, (3) wait for bank confirmation, (4) initiate first collection. Skipping step 2 and going directly to collection generates MD01 on B2B — the debtor's bank checks registered mandates and finds none. Confirm the bank’s mandate-registration process and first-collection timing during onboarding rather than assuming a universal registration delay.

For recurring payments across rails

SEPA R-transactions interact with broader subscription-billing failure management. For the cross-rail comparison of how retry logic, mandate management, and return codes differ across ACH, Bacs, SEPA SDD, and eGIRO, see Recurring Payments: Rails Compared.

---

Scope note

• Primary sources: EPC scheme rulebooks (SCT, SCT Inst, SDD Core, SDD B2B) and reason-code guidance, plus the ISO 20022 external code sets. Full citations are listed under Sources below.
• Scheme distinctions: exception procedures and reason codes must be read within their specific scheme. The cited primary sources explain the three-banking-day SCT return window, and the Recall (bank-initiated) versus RFRO (customer-initiated) split. The SCT Inst €100,000 scheme cap was removed in the 2025 rulebook alongside the EU Instant Payments Regulation.
• SCT-specific detail added from the 2025 SCT Rulebook (EPC125-05 v1.1): who sends a Return (the beneficiary's PSP, not the debtor's bank — SDD works the other way), the Original Amount guarantee that applies to a Reject and a Return but not to a Recall, the boundary between a Return and a beneficiary-initiated new payment once the account has already been credited, the reference a Return uses to link back to the original transfer, and the outer deadline for a Reject. None of this applies to SCT Inst or SDD — those schemes have their own separate rulebooks and are cited as such throughout this reference.
• Data-protection masking (MS03): current EPC SDD guidance permits substitution for AC04, AM04, MD07 and RR01–RR04 where national law restricts disclosure. It does not establish a universal country list or the masked reason in any individual case.
• SDD timing: the current Core and B2B rulebooks distinguish account-debit refund/claim periods from inter-PSP Return settlement and creditor Reversal deadlines. The tables above retain those different starting points and business-day units.
• Verify with your bank or PSP: exact deadlines, CSM cut-off times, and code applicability vary by rulebook version, bank handling, and PSP implementation.

What changed — 13 October 2026: Added an SCT Inst RR04 worked case that separates the rejection record from an unproven regulatory diagnosis and shows which question to put to the PSP before resubmission. The scheme's reason-code guidance is unchanged.

Related references

• SEPA Credit Transfer, Instant, and Direct Debit: Operator Guide — mandate lifecycle, scheme selection, and SCT Inst mandatory rollout.
• Direct Debit Payments Explained: ACH, SEPA, Bacs, eGIRO — cross-rail return code comparison and mandate mechanics.
• EU Instant Payments Regulation: The Compliance Timeline — VoP implementation, SCT Inst mandate, and address format obligations.
• Recurring Payments: Rails Compared — retry strategy, return window modeling, and subscription billing rail selection.

For term definitions — SEPA, IBAN, direct debit, recurring payment — see the Payments Glossary.