SEPA return reason codes explained: AC01, MS03, RR04, and more

Plain-English meaning and recovery steps for every SEPA return code you're likely to see. AC01, MS03, RR04 and 10 more, ordered by how often they appear in support queues.

Last updated: 26 May 2026A SEPA return reason code is the four-character label a European bank attaches to a payment it sends back. The codes are defined by the European Payments Council (EPC) in the SEPA Credit Transfer (SCT) and SEPA Direct Debit (SDD) rulebooks, and every participating bank across the 36 SEPA countries uses the same set.You got one because the payment couldn't be completed: wrong account, closed account, blocked transaction, compliance flag, or one of a dozen other reasons defined in the rulebooks.This page covers 13 codes, ordered by how often they're searched – AC01 first.

Key takeaways

SEPA return codes are universal across SEPA countries. Same four-character code, same meaning, regardless of which bank returned the payment.
The codes fall into four groups: customer-data errors (AC, BE, RC), account-state issues (AC04, AC06, AG01), payment-type mismatches (PY01), and regulatory/compliance returns (RR series, MS02, MS03).
AC01 (incorrect IBAN), MS03 (no reason given by receiving bank), and RR04 (regulatory) drive the bulk of support load at Narvi.
RR04 should never be retried without compliance review. The underlying trigger may be a sanctions match.
MD06 is unique to SDD Core: it's the debtor's unconditional 8-week refund right, with no equivalent under SDD B2B.

What Are SEPA Reason Codes?

SEPA Reason Codes are standardized indicators used by banks and payment institutions when:

a SEPA Credit Transfer cannot be processed,
a SEPA Instant payment fails,
a Direct Debit (SDD Core/B2B) is returned or refused.

Each code corresponds to a specific issue - invalid IBAN, insufficient funds, blocked account, missing mandate, duplication, and dozens of others.This standardization ensures that all European banks speak the same error language.

1. SEPA Credit Transfer (SCT) — EPC Reason Codes

These codes appear when a SEPA Credit Transfer is rejected, returned, or fails during processing.

Code	EPC Description
AC01	Incorrect account number format (invalid or non-existing IBAN).
AC03	Invalid creditor account number.
AC04	Account closed.
AC06	Account blocked/frozen.
AG01	Transaction forbidden by the debtor agent.
AG02	Invalid bank operation code or invalid file format.
AM04	Insufficient funds.
AM05	Duplicate payment.
AM09	Wrong amount.
ARDT	Transaction already returned (negative response to recall).
BE04	Missing or invalid creditor address (where legally required).
CNOR	Creditor bank not registered/unknown BIC.
DNOR	Debtor bank not registered for SEPA.
DUPL	Duplicate transaction.
FF01	Invalid file format or structural error in the message.
FOCR	Following cancellation request (positive recall).
FRAD	Fraud — recall initiated due to suspected fraud.
LEGL	Legal decision preventing execution.
MS02	Not specified by debtor (customer-driven rejection).
MS03	Not specified by agent (bank-driven rejection; reason withheld).
NOAS	No answer from customer.
NOOR	Original transaction not received.
RC01	Bank identifier incorrect (BIC invalid or missing).
RR01	Missing debtor account or identification (regulatory).
RR02	Missing debtor name or address (regulatory).
RR03	Missing creditor name or address (regulatory).
RR04	Regulatory reason (AML, sanctions, KYC, etc.).
TECH	Technical error in processing.
TM01	Cut-off time exceeded.

2. SEPA Instant Credit Transfer (SCT Inst) - EPC Reason Codes

Instant payments follow the same code structure, but the EPC adds specific instant-processing codes.

Code	EPC Description
AB05	Timeout at creditor agent.
AB06	Timeout at instructed agent.
AB07	Agent offline (unspecified).
AB08	Creditor agent offline.
AB09	Error at creditor agent.
AB10	Error at instructed agent.
AC01	Invalid account number (IBAN).
AC03	Invalid creditor account.
AC04	Account closed.
AC06	Blocked account.
AG01	Transaction forbidden.
AG02	Invalid transaction code/file structure.
AG09	Payment not received by creditor agent.
AG10	Agent suspended from instant scheme.
AG11	Creditor agent suspended from instant scheme.
AM02	Amount exceeds allowed instant transfer limit.
AM04	Insufficient funds.
AM05	Duplicate payment.
AM09	Wrong amount.
AM23	Amount exceeds settlement limit.
ARDT	Already returned.
BE04	Missing/invalid creditor address.
CNOR	Creditor bank not reachable in SCT Inst.
CUST	Cancellation requested by customer.
DNOR	Debtor bank not reachable in SCT Inst.
DUPL	Duplicate instruction.
FF01	File formatting error.
FOCR	Following cancellation/recall request.
FRAD	Fraud — recall initiated.
LEGL	Legal reason.
MD07	Creditor deceased.
MS02	Reject — unspecified debtor reason.
MS03	Reject — unspecified agent reason.
NOAS	No answer from customer.
NOOR	Original transaction not received.
RC01	Invalid or missing BIC.
RR01–RR04	Regulatory requirements not met (missing KYC fields).
TECH	Technical problem.
TM01	Cut-off or timing rule violation.

3. SEPA Direct Debit (SDD Core & B2B) - EPC Reason Codes

These apply to both Core and B2B schemes unless marked differently.

Code	EPC Description
AC01	Invalid debtor account number (IBAN).
AC04	Account closed.
AC06	Account blocked.
AC13	Invalid account type for mandate (e.g., B2B mandate on consumer account).
AG01	Direct debit forbidden on this account.
AG02	Invalid transaction code / file structure error.
AM04	Insufficient funds.
AM05	Duplicate collection.
BE05	Unknown initiating party (invalid Creditor Identifier).
CNOR	Creditor bank not registered.
DNOR	Debtor bank not reachable/registered for SDD.
ED05	Settlement failed.
FF01	Invalid file format or malformed message.
MD01	No mandate exists.
MD02	Mandate data invalid or missing.
MD06	Debtor claims refund (authorised but disputed). (Core only)
MD07	Debtor deceased.
MS02	Debtor refuses collection (prior to settlement).
MS03	Bank rejects for unspecified reason.
RC01	Invalid/missing BIC.
RR01	Missing debtor account information (regulatory).
RR02	Missing debtor name/address (regulatory).
RR03	Missing creditor name/address (regulatory).
RR04	Regulatory reason (sanctions, AML, restrictions).
SL01	Service-level restriction by debtor bank (e.g., only whitelist collections allowed).
PY01	Payment cannot be routed (no clearing path).

Why It Matters for Narvi Clients

At Narvi we process SEPA payments for fintechs, high-velocity businesses, and regulated industries. Understanding reason codes enables our clients to:

reduce operational delays,
build smarter automated flows,
provide better customer support,
improve financial predictability.

As your banking and payments partner, we ensure that every SEPA event is logged, explained, and accessible through our platform - so you always know what happened and why.

Official Source Reference (EPC)

All codes in this article are based on the following European Payments Council rulebooks and guidance documents:

EPC SEPA Credit Transfer Rulebook
EPC SEPA Instant Credit Transfer Rulebook
EPC SEPA Direct Debit Core Rulebook
EPC SEPA Direct Debit B2B Rulebook
EPC “Guidance on Reason Codes for SEPA R-Transactions”

These can be accessed at: https://www.europeanpaymentscouncil.eu/document-libraryThis ensures that all definitions provided above match the authoritative EPC standards used across the SEPA zone.

AC01: Incorrect account number

The IBAN you sent is either malformed (wrong length, fails the checksum) or doesn't exist at the destination bank.You'll see this on both SEPA Credit Transfer and SEPA Direct Debit. It's the most common return code Narvi clients encounter, and almost always a data-entry issue at the payer's end.Common causes:

The IBAN was copied with a missing or extra character
The IBAN was retyped from a printed document and a digit got transposed
The recipient gave you a domestic account number instead of the IBAN format
The IBAN belongs to a country code that the receiving bank doesn't support for this transaction type

What to do next: verify the IBAN with the recipient, run it through any standard IBAN validator before re-sending, and re-initiate the payment. The original transaction cannot be recovered: funds return to your account and you start over.If you keep getting AC01 with what looks like a correct IBAN, the bank may have closed it. Try AC03 or AC04 logic first.

MS03: Reason not specified by the receiving bank

The receiving bank returned the payment without specifying a reason. The "agent" in the code's official name is the receiving bank itself.This is the second-most-common return code in Narvi's support queue and one of the more frustrating ones: you know the payment failed, but you don't know why. MS03 is the receiving bank's catch-all. They returned the payment but chose not to disclose, often because the underlying reason is internal (account flags, risk controls, sanctions checks they don't want to confirm or deny).Common causes:

Risk-based rejection that the bank doesn't want to detail
Internal account status the bank can't share with third parties
Compliance flag that wasn't elevated to a specific RR-series code
Receiving bank's manual review

What to do next: contact the recipient and ask them to follow up with their bank directly. The receiving bank will sometimes give the account holder a reason they won't give the originator. If the recipient confirms their account is fine, retry once. If it returns MS03 again, you need a different account.

RR04: Regulatory reason

The payment was returned because of a regulatory or compliance issue. RR04 is the regulatory umbrella code under the SEPA rulebooks.You'll see RR04 on both SCT and SDD. It covers a wide range of compliance scenarios and the returning bank is often not allowed to explain further. Treat RR04 as a signal that the payment touched a regulatory checkpoint, not as a single defined error.Common triggers:

Sanctions screening hit on the originator, recipient, or a connected party
AML or counter-terrorism financing alert
Embargo on the destination country
Missing or invalid regulatory reporting information (separate RR codes cover sub-cases: RR05 for invalid regulatory info, RR06 for tax info, RR07 for remittance info)
Restrictions tied to politically exposed persons or restricted entities

What to do next: do not retry the same payment. Contact your payment provider's compliance team with the original payment details. For Narvi clients, the Narvi support and compliance team handles RR04 escalations directly. They can determine whether the issue is correctable (missing data) or whether the payment is blocked outright (sanctions match). Retrying a sanctions-related return without investigation creates further compliance exposure.

MS02: Reason not specified, customer-generated

The payer or the payer's bank cancelled the payment without giving a reason. The "customer" in the code's name refers to the originating side, not the recipient.You're seeing this if you're the recipient. The payment was on its way and then got pulled before completion, with no code attached.Common causes:

Payer cancelled the transfer manually after sending
Payer's bank held the payment for review and let it timeout
Payer realised they sent to the wrong recipient and recalled
Payer's account had insufficient funds at the moment of execution and their bank used MS02 instead of a more specific code

What to do next: contact the payer. They have the information their bank didn't pass along. If you're invoicing, treat MS02 as if the payment never happened and follow your standard chase-up flow.

AC03: Wrong account number, IBAN valid

The IBAN passes the format check and the checksum, but the receiving bank confirms the account doesn't exist at that branch.AC03 is the "looks right, isn't right" code. The structural validation passes, so client-side checks don't catch it. The bank only catches it when the routing engine looks for the actual account.Common causes:

Recipient gave you an IBAN with a typo that still passed the checksum
IBAN was generated for an account that was never activated
Internal restructuring at the receiving bank changed the account numbering
The recipient sent you a placeholder or test IBAN by mistake

What to do next: ask the recipient to confirm their IBAN from their banking app, not from memory or from an old document. Re-initiate with the verified IBAN. The original payment returns to your account.

PY01: Not allowed payment

The payment type isn't allowed on the receiving account or under the chosen scheme.PY01 isn't about the account being broken: the account is fine, it just doesn't accept what you're trying to send.Common causes:

You sent a SEPA Direct Debit to an account flagged as not accepting direct debits
You used SCT Instant to an account that hasn't opted into instant payments
The receiving account is a savings account or non-payment account that doesn't accept incoming SCT
The recipient's bank doesn't support cross-border debits under SDD B2B

What to do next: ask the recipient which payment types their account accepts. Switch to a supported type (standard SCT instead of SCT Instant, or wire instead of direct debit) and re-initiate.

AC04: Closed account

The account existed but has been closed. The receiving bank confirms there's nothing to credit.Common causes:

Recipient closed the account and didn't update their counterparties
Bank closed the account due to inactivity
Bank closed the account as part of an account-holder offboarding
Business closed and the operational account was wound down

What to do next: contact the recipient. They need to give you a current account. Do not retry the same IBAN: it will keep returning. The funds return to you.

AG01: Transaction forbidden

The account is technically active but isn't authorised for this transaction type at this time.AG01 overlaps with PY01 but signals a stronger restriction: the bank is refusing, not just unable. Often points to account-level controls the recipient set or the bank applied.Common causes:

Account is restricted to incoming payments only and you sent a debit
Account is in a frozen state pending verification (different from AC06 outright block)
Recipient set a payment-type filter on the account
Scheme-level rule (e.g. SDD B2B requires a mandate the bank can't find)

What to do next: ask the recipient to confirm their account can receive your payment type. If yes, ask their bank to lift the restriction. Re-initiate once the recipient confirms.

MD06: Refund request by debtor (SDD Core only)

MD06 is an SDD Core code only. The debtor exercised their unconditional 8-week refund right.Under the SEPA Direct Debit Core scheme, any debtor can request a refund within 8 weeks of debit, for any reason, without justification. MD06 is the bank's notification that this happened.Important: this is not a payment failure. The debit succeeded, the debtor changed their mind, and the funds came back. The mandate itself may still be valid for future collections.What to do next: this is a customer-relationship issue, not an operational one. Contact the debtor about the underlying claim. Decide whether to retry the collection or treat it as a dispute. Under SDD B2B there is no comparable refund right: B2B debtors have to dispute via their bank within tight windows.

RC01: Bank identifier incorrect

The BIC supplied with the payment is missing, malformed, or doesn't match the bank that holds the IBAN.Under the current SEPA rules, BIC is optional for SEPA payments within the EEA when a valid IBAN is provided ("IBAN-only"). RC01 typically appears when you supply a BIC and it conflicts with the IBAN, or when you send to a non-EEA destination that still requires BIC.What to do next: remove the BIC from the payment if you're sending within the EEA, or correct it against the recipient's bank details. Re-initiate.

BE04: Missing creditor address

The creditor (the receiving party) needs an address field that wasn't supplied, or the supplied address was incomplete.BE04 applies under SCT, especially for cross-border payments where regulatory reporting requires structured address data. FATF Recommendation 16 updates have made this more common since 2024.What to do next: add the full structured address (street, building number, postal code, town, country) to the creditor block and re-initiate. Free-text address fields are increasingly rejected: use structured fields where your interface allows.

AC06: Blocked account

The account is blocked by the receiving bank. Different from AC04 (closed): the account exists but the bank has placed a hold on it.Common causes include compliance review, court orders, suspected fraud, and account-holder requests. The receiving bank won't usually tell you which.What to do next: contact the recipient. The block is on their side and they have to resolve it with their bank. Do not retry until they confirm the block is lifted.

SCT, SDD Core, and SDD B2B: how the rules differ by scheme

The same code can behave differently depending on which scheme it appears under. The four live schemes:

SCT (SEPA Credit Transfer): a one-off push payment. Once executed, funds move to the recipient and cannot be unilaterally recalled.
SCT Inst (SEPA Instant Credit Transfer): same as SCT, executed in under 10 seconds, available 24/7. Same return codes apply.
SDD Core (SEPA Direct Debit Core): a pull payment, typically for consumer debtors. The 8-week unconditional refund right under MD06 is unique to this scheme. Mandates required.
SDD B2B (SEPA Direct Debit Business to Business): also a pull payment, for business debtors. No 8-week refund right. The debtor's bank verifies the mandate against a registered copy before debiting.

For all four, the return-code vocabulary is the same. The differences sit in which codes can occur on which scheme, the refund rights (MD06 is Core-only), and the mandate handling (SDD B2B has tighter rules).When you're chasing a return, the first thing to identify is which scheme the payment used. That changes the recovery flow.For more on SCT Inst specifically, see What is SEPA Instant.

How Narvi handles SEPA return codes

Narvi Payments Oy is a Finnish-licensed e-money institution (EMI) authorised by the Financial Supervisory Authority of Finland (FIN-FSA), operating across the EEA. When a payment returns to a Narvi IBAN, the return code appears in the dashboard alongside the original payment, with the plain-English meaning shown next to it. You don't have to translate four-letter codes in your head every time something fails.Returns that need investigation – RR-series in particular – are routed to our support and compliance teams and you get a direct contact rather than a ticket queue. If you operate at volume and need return-code data via API, the SEPA Instant solution page and our Banking-as-a-Service and API offering cover what's supported.

Frequently asked questions

The code itself isn't disputable: it's the receiving bank's classification. What you can dispute is the underlying payment, by contacting the recipient and their bank, or in regulatory cases by working with your provider's compliance team.

For SCT, returns can come back within minutes or up to five business days, depending on when the issue is detected. For SDD, returns can arrive up to five interbank business days after settlement, or up to eight weeks for MD06 customer refunds under SDD Core.

AC01 means the IBAN itself is wrong: malformed, fails checksum, or doesn't exist at the receiving bank. AC03 means the IBAN passes the format and checksum check (so it looks valid) but the receiving bank confirms no account matches it. AC01 is usually a typo or a domestic-format mix-up. AC03 is usually a digit transposition that happened to still pass validation.

The originating or receiving bank chose not to disclose. Both codes are valid under the EPC rulebooks even without further detail. You have to ask the counterparty directly.

Yes. The European Payments Council defines the codes in the SCT and SDD rulebooks. Every participating bank in the 36-country SEPA zone uses the same set, which is why a Spanish bank returning a payment to a Finnish bank can communicate the reason cleanly.

For SCT, once the funds are credited to the beneficiary the payment is final and can't be unilaterally returned. The originator has to negotiate a recall request with the beneficiary, who must consent. For SDD Core, MD06 allows the debtor to claim back a credited debit for up to 8 weeks. SDD B2B has no equivalent right.

In the EPC's SCT and SDD rulebooks, published in the document library at europeanpaymentscouncil.eu. Each rulebook lists the return reason codes valid for its scheme, with the formal definitions.

Prepare for your Business Bank AccountSet up your bank account completely online and access SEPA and SWIFT payments immediately.Learn More & Book a Demo