Reason Codes

Synonyms: Return code, reason for return, return code, R-transaction code

Short definition

Reason codes are standardized four-digit keys used by payment service providers in SEPA transactions to explain why a payment was not executed as instructed, or why it was returned or recalled. They serve as the machine-readable counterpart to the plain-text return reason and form the basis for all automated return processing.

Reason codes do not originate from the SEPA rulebooks themselves but from the ISO 20022 External Code Sets. The European Payments Council (EPC) selects a permissible subset for each payment scheme and specifies which codes may be used for specific “R-transactions” and by which parties. National clearing rules (such as the Bundesbank’s procedural rules for the SEPA-Clearer(opens in new tab) in Germany) may supplement these with additional checks and codes.

A key practical point: a reason code indicates what happened, not who was at fault or whether resubmission is advisable. Interpreting this information is always the task of the processing system.

Where reason codes occur

One and the same code can be valid in multiple messages, but not in all of them. For instance, MD06 is permitted only for refunds, while FF01 is permitted only for rejects.

Classification of R-transactions

The most important codes

SEPA Direct Debit (SDD Core and B2B)

SEPA Credit Transfer (SCT)

A separate set of codes applies to the SCT Inquiry (Claim of Non-Receipt, Value Date Correction): ACNR, ACVA, MODI as positive, ARJT, CVAA, RJNR, RJVA, RNPR, NOOR as negative resoponses.

SEPA Instant Credit Transfer (SCT Inst) – additional codes

In principle, the same set of codes applies to SCT Inst as to SCT, supplemented by codes for time-critical processing. These form the core of any instant payment error analysis:

The AB-series represents the key difference compared to the classic SCT. It is derived from the procedure’s timing model and must be evaluated separately during monitoring: clusters indicate accessibility issues at a counterparty institution rather than data errors.

Note: With the elimination of the scheme-wide maximum amount,  AM23 has become significantly more relevant in practice as an institution-specific limit.

Recall, Request for Recall by the Originator and Return codes

Recall by the payer’s bank (camt.056) – permitted reasons:

Request for Recall by the Originator (RFRO) – issued by the customer:

Reply to Recall/RFRO (camt.029):

FOCR is the only positive response code and triggers the actual repayment. All others are rejections and do not initiate a flow of funds—a distinction frequently overlooked in analyses of returned payments.

Differentiation: Verification of Payee

VoP results are not reason codes, although in practice they are frequently conflated with them. They arise prior to payment initiation—not afterwards—and are not part of R-transactions.

The VoP scheme yields four possible results for the combination of account number and name:

• Match – complete accordance
• Close Match – approximate accordance; the correct name is displayed to the payer
• No Match – no accordance
• Verification check not possible – Check cannot be performed, e.g. because the account is not held by the responding PSP or the service is unavailable

The “Close Match” result does not apply to the account number + identification code combination. The technical reason codes underlying the “not possible” status are specified in the Inter-PSP API Specifications rather than the rulebook.

Practical implication: A negative VoP response does not prevent the payment; instead, it generates a warning that the payer can override. A reason code, on the other hand, documents a payment that has already failed or been reversed.

Practical notes

MS02 and MS03 are not error codes; they simply indicate that no reason was provided. A high volume of these codes among returned items points to a quality issue on the counterparty’s side and precludes automated follow-up decisions.

Clearly distinguish between AC01 and AC04. AC01 may indicate a data entry error and justifies data correction, whereas AC04 signifies that the account definitively does not exist. Resubmission logic that treats both codes the same way generates avoidable subsequent returns and fees.

AM04 is the only classic case for a retry. Resubmitting items with any other code is almost always economically disadvantageous.

MD01 and MD06 differ in terms of the timeframe, not the outcome. MD06 represents an authorized dispute raised within eight weeks, while MD01 represents a dispute due to a missing mandate raised within 13 months—entailing a significantly heavier burden of proof for the payee.

Code lists have version numbers. ISO 20022 External Code Sets are updated regularly; EPC guidance and Bundesbank procedural rules align with the schemes’ annual release schedules. A code list stored in a system without versioning and a maintenance process will inevitably become outdated.

Take national extensions into account. The Bundesbank’s SEPA-Clearer uses additional validation and rejection codes not found in the EPC rulebook. Systems implemented solely based on EPC guidance will default to a fallback path when encountering these codes.

Sources and maintenance status

Maßgeblich ist immer die zum Verarbeitungszeitpunkt gültige Fassung. Die EPC-Guidance-Dokumente sind Auslegungshilfen, rechtlich verbindlich sind die jeweiligen Scheme Rulebooks und Implementation Guidelines!

Editorial note: This article reflects the status as of August 2026. To be reviewed during the next update: the impact of the switch to structured addresses on November 22, 2026, on BE04 and the RR series.