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 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.

The six R-transaction types

R-transactions in SEPA are not a single class of failure. The six types differ in who initiates them, whether settlement has occurred, and what the creditor can do in response. Treating them as interchangeable in reconciliation or retry logic generates compliance violations and customer complaints.

Reject vs Return: Both result in no net credit to the creditor, but their cause and operational response differ. A Reject stops the payment before funds move; no revenue is at risk. A Return reverses funds already credited — the creditor loses settled revenue and must reconcile a post-settlement debit.

Refusal vs Reject: A Refusal is debtor-instructed — the customer has told their bank not to honor this specific collection. A Reject is bank-side, often technical. A pattern of Refusals on the same mandate is a customer relationship signal; a pattern of Rejects on the same creditor is a data quality signal.

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

Source: EPC SDD Core Rulebook 2025 v1.1 (EPC016-06), SDD B2B Rulebook 2025 v1.1 (EPC222-07), and EPC Clarification Paper EPC131-17 v3.1 (April 2025).

SDD B2B irrevocability. Under the SDD B2B scheme rules, an authorized B2B direct debit is typically treated as irrevocable once approximately three business days pass after the debit date without a return. The debtor’s bank cannot initiate a refund on the debtor’s behalf. This is the primary operational reason B2B billing operators prefer SDD B2B over SDD Core for invoice collection: the 8-week uncertainty window does not exist.

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

All codes below are ISO 20022 External Return Reason codes as published in the EPC guidance documents EPC173-14 v8.0 (SDD, November 2024). The v8.0 update added structured address requirements to RR02 and RR03; all other codes are stable across v6.0–v8.0.

Account codes (AC)

AC04 note: In several SEPA countries (Austria, Belgium, Germany, Luxembourg, Netherlands, Slovakia, Slovenia, Switzerland), data protection law prohibits the debtor bank from disclosing that an account is closed. In these jurisdictions, AC04 is replaced by MS03. See the MS03 section below.

Amount and funds codes (AM)

AM04 note: Same data protection masking applies as AC04 in the listed jurisdictions — AM04 may appear as MS03.

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. If a B2B debtor wants to contest a collection, they must do so as an unauthorized claim (no valid mandate) via a different process.

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 are returned immediately where possible. They indicate the collection cannot proceed due to compliance requirements rather than debtor account issues. RR04 in particular may reflect a sanctions hit or an AML flag on either side of the transaction.

RR02 and RR03 in v8.0: The November 2024 update to EPC173-14 extended these codes to cover structured address format violations. From October 2025, the 2025 rulebooks require hybrid or structured address formats — unstructured address format phases out by November 2026. Collections with non-compliant address formats may now return RR02 or RR03 rather than AG02.

Debtor refusal and unspecified codes (MS / SL)

The MS03 masking point

MS03 is the single highest-ambiguity code in SEPA. It means the bank has processed the R-transaction but is not disclosing the reason. There are three distinct causes:

1. Data protection substitution. The EPC guidance (EPC173-14, consistent from v4.0 through v8.0) states that MS03 must be used when national legislation does not permit disclosure of AC04 (closed account), AM04 (insufficient funds), MD07 (deceased), RR01, RR02, RR03, or RR04. The countries identified in EPC guidance as applying these restrictions are Austria, Belgium, Germany, Luxembourg, the Netherlands, Slovakia, Slovenia, and Switzerland. In practice, when you receive MS03 from a debtor bank in these countries, it is most commonly either AC04 or AM04.

2. Bank-side risk control. Some banks use MS03 when their internal fraud or risk scoring has flagged the transaction — beyond what any specific code covers.

3. Genuine unspecified error. A catch-all for edge cases the bank cannot categorize under a more specific code.

Operational treatment: Do not retry MS03 without investigation. Treat it as you would AC04 on first occurrence — check with the customer whether the account is active, and update mandate status if the customer confirms account closure. On repeat MS03 from the same mandate without customer contact, treat as a likely closed/blocked account and pause collections.

Reason code reference: SCT and SCT Inst

SCT and SCT Inst share most reason codes, but SCT Inst adds several codes specific to the 10-second settlement window and the instant scheme infrastructure. The EPC guidance document for SCT R-transactions is EPC135-18 v6.0 (November 2024); for SCT Inst it is EPC059-18 v6.0 (November 2024).

Account and format codes

SCT Inst-specific codes

SCT Inst rejects and returns come back within seconds under normal conditions — the 10-second settlement deadline means there is no “next day” return for timing reasons. The AB and AG codes above are infrastructure codes; they indicate a bank or scheme connectivity issue rather than an account issue. Retry after a brief interval is appropriate for AB/AG codes. For the operational handling — what to do at each failure class, pacs.002 status mechanics, and escalation checklists — see the SCT Inst rejection and timeout runbook.

Regulatory codes (shared SCT/SDD)

RR01–RR04 apply to SCT and SCT Inst with the same meanings as SDD. RR02 and RR03 were updated in v6.0 of the SCT guidance (November 2024) to include structured address format requirements, aligned with the 2025 rulebook address change described above.

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.

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.

Initiation window: Up to 13 months from the execution date for all RFRO reasons.

RFRO vs Recall: The 13-month RFRO window is available for all customer-initiated reasons — not just FRAD. The beneficiary can decline an RFRO (unlike FRAD recall, where refusal carries regulatory and legal risk). For CUST/AM09/AC03, the beneficiary can legitimately refuse if funds have already been applied.

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 (insufficient funds) supports retry — but scheme rules and good practice both impose limits. Retry once 3–5 banking days after the initial failure, typically mid-month for subscription billing aligned to payroll cycles. A second AM04 on the same collection period should trigger customer notification rather than another automated retry. Never retry the same collection more than twice without customer engagement; repeated attempts on a blocked or closed account generate scheme violations.

MS03 requires classification before retry. If the debtor is reachable and confirms the account is active, a single retry is reasonable. If the debtor is unreachable or if prior collections on the same mandate have failed with AM04 or AC04, treat MS03 as a likely closed account and pause rather than retry.

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. Revenue recognition from SDD Core should account for this; finance models that treat SDD Core settlements as final on D+1 overstate confirmed revenue by the amount of expected refunds.

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. The pre-registration lag varies by bank but is typically 1–3 business days. Build this into the onboarding flow rather than treating it as optional.

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.
• Rulebook-backed: the six R-transaction types, scheme applicability, reason-code meanings, 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.
• Data-protection masking (MS03): the substitution of MS03 for AC04, AM04, MD07, and RR01–RR04, and the affected country list, come from EPC SDD reason-code guidance and are consistent across recent rulebook versions.
• Operator/PSP-sourced: the SDD B2B three-business-day return window and the five-business-day Reversal window are drawn from operator and PSP guides where the EPC rulebook PDFs were inaccessible — treat these two figures as indicative.
• Verify with your bank or PSP: exact deadlines, CSM cut-off times, and code applicability vary by rulebook version, bank handling, and PSP implementation.

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.