Reason Codes

Synonyme: Rückgabecode, Rückgabegrund, Return Code, R-Transaktionscode

Kurzdefinition

Reason Codes sind standardisierte vierstellige Schlüssel, mit denen ein Zahlungsdienstleister im SEPA-Zahlungsverkehr begründet, warum eine Zahlung nicht wie beauftragt ausgeführt, zurückgegeben oder zurückgerufen wurde. Sie sind das maschinenlesbare Gegenstück zum Klartext-Rückgabegrund und Grundlage jeder automatisierten Rückläuferverarbeitung.

Reason Codes stammen nicht aus dem SEPA-Regelwerk selbst, sondern aus den ISO 20022 External Code Sets. Das European Payments Council (EPC) wählt daraus je Verfahren eine zulässige Teilmenge aus und legt fest, welcher Code in welcher R-Transaktion und von welcher Partei verwendet werden darf. Nationale Clearing-Regelwerke (z.B. in Deutschland die Verfahrensregeln der Bundesbank für den SEPA-Clearer(opens in new tab)) können zusätzliche Prüfungen und Codes ergänzen.

Wichtig für die Praxis: Ein Reason Code sagt was passiert ist, nicht wer es verschuldet hat und nicht, ob eine Wiedervorlage sinnvoll ist. Diese Bewertung ist immer Auslegungsleistung des verarbeitenden Systems.

Wo Reason Codes auftreten

Ein und derselbe Code kann in mehreren Nachrichten gültig sein, aber nicht in allen. MD06 etwa ist ausschließlich im Refund zulässig, FF01 ausschließlich im Reject.

Systematik der R-Transaktionen

Die wichtigsten Codes

SEPA-Lastschrift (SDD Core und B2B)

SEPA-Überweisung (SCT)

Für die SCT Inquiry (Claim of Non-Receipt, Value Date Correction) gilt ein eigener Codesatz: ACNR, ACVA, MODI als positive, ARJT, CVAA, RJNR, RJVA, RNPR, NOOR als negative Antworten.

SEPA-Echtzeitüberweisung (SCT Inst) – zusätzliche Codes

Für SCT Inst gilt grundsätzlich derselbe Codesatz wie für SCT, ergänzt um Codes für die zeitkritische Verarbeitung. Diese sind der Kern jeder Instant-Payments-Fehleranalyse:

Die AB-Reihe ist der wichtigste Unterschied zur klassischen SCT. Sie entsteht aus dem Timing-Modell des Verfahrens und ist im Monitoring gesondert auszuwerten: Häufungen deuten auf Erreichbarkeitsprobleme eines Gegeninstituts hin, nicht auf Datenfehler.

Zu beachten: Mit dem Wegfall des Scheme-Höchstbetrags ist AM23 als institutsindividuelles Limit deutlich praxisrelevanter geworden.

Recall, Request for Recall by the Originator und Antwortcodes

Recall durch die Bank des Zahlers (camt.056) – zulässige Gründe:

Request for Recall by the Originator (RFRO) – vom Kunden veranlasst:

Antwort auf Recall/RFRO (camt.029):

FOCR ist der einzige positive Antwortcode und erzeugt die tatsächliche Rückzahlung. Alle übrigen sind Ablehnungen und lösen keinen Zahlungsfluss aus – eine in Rückläufer-Auswertungen häufig übersehene Unterscheidung.

Abgrenzung: Verification of Payee

VoP-Ergebnisse sind keine Reason Codes, werden aber in der Praxis regelmäßig damit vermischt. Sie entstehen vor der Zahlungsauslösung, nicht danach, und sind kein Bestandteil der R-Transaktionen.

Das VoP Scheme kennt bei der Kombination Kontonummer + Name vier Ergebnisse:

• Match – Übereinstimmung
• Close Match – annähernde Übereinstimmung; der korrekte Name wird dem Zahler angezeigt
• No Match – keine Übereinstimmung
• Verification check not possible – Prüfung nicht durchführbar, z. B. weil das Konto beim antwortenden PSP nicht geführt wird oder der Dienst nicht verfügbar ist

Bei der Kombination Kontonummer + Identifikationscode entfällt Close Match. Die technischen Reason Codes hinter „not possible“ sind nicht im Rulebook, sondern in den Inter-PSP API Specifications spezifiziert.

Praktische Konsequenz: Eine negative VoP-Antwort verhindert die Zahlung nicht – sie erzeugt eine Warnung, die der Zahler übergehen kann. Ein Reason Code hingegen dokumentiert eine bereits gescheiterte oder rückabgewickelte Zahlung.

Praxishinweise

MS02 und MS03 sind keine Fehlercodes. Sie bedeuten lediglich, dass kein Grund mitgeteilt wurde. Ein hoher Anteil dieser Codes im Rückläuferbestand ist ein Qualitätsproblem der Gegenseite und erlaubt keine automatisierte Folgeentscheidung.

AC01 und AC04 sauber trennen. AC01 kann auf einen Erfassungsfehler hindeuten und rechtfertigt eine Datenkorrektur; AC04 bedeutet endgültig kein Konto. Wiedervorlagelogiken, die beide gleich behandeln, erzeugen vermeidbare Folgerückläufer und Entgelte.

AM04 ist der einzige klassische Retry-Fall. Wiedervorlagen bei allen anderen Codes sind fast immer wirtschaftlich negativ.

MD01 und MD06 unterscheiden sich in der Frist, nicht im Ergebnis. MD06 ist der autorisierte Widerspruch binnen acht Wochen, MD01 der Widerspruch mangels Mandat binnen 13 Monaten – mit deutlich weitergehender Beweislast für den Zahlungsempfänger.

Codelisten haben Versionsstände. Die ISO 20022 External Code Sets werden regelmäßig aktualisiert; EPC-Guidance und Bundesbank-Verfahrensregeln folgen den jährlichen Release-Terminen der Schemes. Eine im System hinterlegte Codeliste ohne Versionierung und Pflegeprozess veraltet zuverlässig.

Nationale Ergänzungen beachten. Der SEPA-Clearer der Bundesbank verwendet zusätzliche Prüf- und Ablehnungscodes, die nicht im EPC-Regelwerk stehen. Systeme, die ausschließlich gegen die EPC-Guidance implementiert sind, laufen bei diesen Codes in den Default-Zweig.

Quellen und Pflegestand

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!

Redaktioneller Hinweis: Der Beitrag bildet den Stand August 2026 ab. Zu prüfen bei der nächsten Aktualisierung: Auswirkungen der Umstellung auf strukturierte Adressen zum 22. November 2026 auf BE04 und die RR-Reihe.