SEPA R-Transaktionen verstehen: Ein technischer Leitfaden für Payment Engineers

---

„Die Zahlung wurde zurückgegeben." Im SEPA-Kontext kann dieser Satz vier verschiedene Dinge bedeuten. Jedes hat einen anderen Auslöser, eine andere PSD2-Frist, einen anderen Settlement-Lifecycle und eine andere Behandlung im Ledger. Die meisten Implementierungen behandeln sie als ein einzelnes „Storno"-Event mit einem angehängten Reason Code. Das führt zu fehlerhaftem Haltefrist-Management, verpassten PSD2-Fristen und Reconciliation-Diskrepanzen, die Wochen nach dem Vorfall auftauchen.

SEPA R-Transaktionen sind nicht ein Konzept. Es sind vier.

Vier Typen, nicht einer

Die Unterscheidung ist nicht akademisch. Sie bestimmt, was das System mit dem Geld tun muss, wann es das tun muss und wie der Ledger-Eintrag aussieht.

Ein Reject ist aus Sicht des Begünstigten still. Die Zahlung wurde nie abgewickelt. Die Bank des Zahlers hat sie vor Settlement abgelehnt (falsche IBAN, geschlossenes Konto, gesperrtes Konto). Das System des Begünstigten muss es möglicherweise nicht einmal wissen, es sei denn, es hat die erwartete eingehende Zahlung verfolgt.

Ein Return ist eine Stornierung innerhalb der Haltefrist. Das Geld wurde abgewickelt (dem Konto des Begünstigten im Clearing-System gutgeschrieben), aber während der Haltefrist sendet die Bank des Zahlers einen Return. Das Ledger des Begünstigten muss die Gutschrift stornieren. Die Mittel wechseln von SETTLED_PENDING zurück zum Zahler.

Ein Refund geschieht nach Ablauf der Haltefrist und die Mittel sind SETTLED_AVAILABLE. Der Begünstigte hat das Geld. Der Zahler bestreitet, innerhalb von 8 Wochen für SEPA Core Lastschrift (PSD2 Art. 76), ohne Einspruchsrecht für B2B. Ein Refund ist keine Stornierung des Originaleintrags. Es ist eine neue, separate Belastung gegen den Begünstigten. Der Originaleintrag bleibt im Ledger, unverändert und immutable.

Ein Reversal wird vom Auftraggeber (nicht von der Bank des Zahlers) über einen camt.056-Stornierungsantrag initiiert. Das geschieht typischerweise, wenn der Auftraggeber ein Duplikat oder einen Fehler nach Settlement entdeckt. In der deutschen Buchführung ist dies eine Stornobuchung, ein Korrektureintrag, der das Original über einen correction_of-Fremdschlüssel referenziert. Der Originaleintrag bleibt. Der Korrektureintrag trägt denselben Betrag mit umgekehrtem Vorzeichen.

Haltefristen und Settlement-Lifecycle

Zwischen Settlement und Verfügbarkeit durchlaufen Mittel eine Haltefrist. Die Dauer hängt vom Schema ab:

„Geschäftstage" sind nicht „Kalendertage." TARGET2 hat seinen eigenen Feiertagskalender: Wochenenden, Neujahr, Karfreitag, Ostermontag, 1. Mai, Weihnachten, 26. Dezember. Deutsche Feiertage, die keine TARGET2-Feiertage sind, zählen nicht. Spanische Feiertage, die keine TARGET2-Feiertage sind, zählen nicht. Die Geschäftstage-Berechnung muss den TARGET2-Kalender verwenden, nicht einen nationalen Kalender.

Während der Haltefrist sind Mittel im Status SETTLED_PENDING. Der Saldo des Begünstigten zeigt die Gutschrift, aber die Mittel sind nicht für Abhebung oder weitere Überweisung verfügbar. Nach Ablauf der Haltefrist wechseln Mittel zu SETTLED_AVAILABLE. Returns sind nicht mehr möglich (aber Refunds schon, für Core DD).

ISO Reason Codes steuern die Logik

pacs.004 (Payment Return) trägt ein ReasonCode-Feld aus der ExternalStatusReason1Code-Aufzählung. Das ist kein Freitext. Es ist eine geschlossene Menge, definiert durch ISO 20022 und eingeschränkt durch EPC-Rulebooks.

Der Reason Code bestimmt den R-Transaction-Typ. Der Typ bestimmt die Settlement-Aktion. Die Aktion bestimmt die PSD2-Frist. Die Kette ist deterministisch.

Die Klassifikationsfunktion:

classify(reason_code, within_holding_period) → R-Transaction-Typ

  if pre_settlement(reason_code):     → REJECT
  if within_holding_period:           → RETURN
  if originator_initiated(reason_code): → REVERSAL
  else:                               → REFUND

Wenn diese Klassifikation direkt auf dem ISO Reason Code implementiert ist, ohne Zwischen-Mapping-Tabelle, ist die Verarbeitung deterministisch. Ein neuer Reason Code in einer zukünftigen EPC-Rulebook-Version erfordert das Hinzufügen einer Enum-Variante. Der Compiler identifiziert jeden Handler, der ihn nicht abdeckt. Keine Mapping-Tabelle zu aktualisieren. Kein Deployment zu synchronisieren.

Implementierungsarchitektur

Drei Verantwortlichkeiten, drei Services. Jeder besitzt ein Anliegen.

Klassifikationsservice: Empfängt eingehende pacs.004, extrahiert den Reason Code, klassifiziert in Reject/Return/Refund/Reversal basierend auf dem Code und dem Haltefrist-Status der Originalüberweisung.

Settlement-Service: Führt basierend auf dem klassifizierten Typ die korrekte Ledger-Operation aus:

• Reject: Keine Ledger-Aktion (die Originalüberweisung wurde nie abgewickelt).
• Return: Ausstehendes Settlement stornieren. Übergang von SETTLED_PENDING zu RETURNED.
• Refund: Neue Belastungsüberweisung gegen den Begünstigten erstellen. Der Originaleintrag bleibt unberührt.
• Reversal: Korrektureintrag (Stornobuchung) mit correction_of-Referenz auf die Originalüberweisung erstellen.

Audit-Service: Protokolliert jede R-Transaktion mit: Typ, Reason Code, Originalüberweisungs-Referenz (aufgelöst über transfer_id → EndToEndId → external_id, Fallback-Kette), PSD2-Frist und DORA-Event-ID.

Die Originalüberweisung wird über drei Lookup-Pfade aufgelöst:

1. Direkte transfer_id (wenn die R-Transaktion sie trägt)
2. EndToEndId-Matching (die ISO End-to-End-Referenz)
3. External_id-Matching (die Referenz der Bank)

Die Fallback-Kette behandelt die Realität, dass nicht alle pacs.004-Nachrichten alle Referenzfelder tragen. Manche Banken befüllen EndToEndId. Manche verwenden ihre eigene externe Referenz. Das System muss alle drei behandeln.

Die Stornobuchung (Korrekturbuchung)

Das deutsche Handelsrecht (HGB §239) fordert, dass Korrekturen an Ledger-Einträgen als neue Einträge aufgezeichnet werden. Niemals als Modifikationen des Originals. Niemals als Löschungen.

Ein Reversal ist nicht DELETE FROM transfers WHERE id = original_id. Es ist:

INSERT INTO transfers (
  debit_account_id,   -- ursprüngliches Gutschriftskonto (Richtung umgekehrt)
  credit_account_id,  -- ursprüngliches Belastungskonto (Richtung umgekehrt)
  amount,             -- gleicher Betrag wie Original
  correction_of,      -- FK → Originalüberweisung
  code,               -- Stornierungscode
  ...
)

Der Originaleintrag bleibt im Ledger. Immutable. Der Korrektureintrag referenziert ihn. Ein Auditor sieht beides: die Originalbuchung und ihre Korrektur, verknüpft durch Fremdschlüssel. Der Ledger-Saldo spiegelt den Nettoeffekt wider. Der Audit-Trail zeigt die vollständige Historie.

Das ist keine deutsche Eigenheit. Es ist solide Buchhaltungspraxis, übernommen von jedem System, das Immutabilität ernst nimmt. Wenn das Ledger Modifikationen an historischen Einträgen erlaubt, ist der Audit-Trail unzuverlässig. Wenn Korrekturen neue Einträge sind, die das Original referenzieren, ist der Trail vollständig und manipulationssicher.

Was in der Praxis schiefgeht

Drei häufige Implementierungsfehler:

1. Alle R-Transaktionen als Stornierungen behandeln. Ein Refund ist keine Stornierung. Eine Stornierung macht den Originaleintrag rückgängig (Korrekturbuchung). Ein Refund ist ein neuer Anspruch, der eine neue Belastung erzeugt. Die Verwechslung führt zu fehlerhaften Ledger-Einträgen und fehlerhaften Saldoberechnungen.

2. Kalendertage für Haltefristen verwenden. SEPA-Haltefristen werden in TARGET2-Geschäftstagen gezählt. Eine Zahlung, die am Mittwoch vor einem TARGET2-Feiertag am Donnerstag abgewickelt wird: Die Haltefrist zählt den Donnerstag nicht. Die Verwendung von Kalendertagen bedeutet, Mittel zu früh freizugeben (regulatorisches Risiko) oder zu spät (Liquiditätskosten).

3. Die B2B-vs.-Core-Unterscheidung ignorieren. SEPA Lastschrift B2B hat eine 2-Tage-Haltefrist und kein Erstattungsrecht (der Zahler hat keinen Art.-76-Anspruch). SEPA Core hat eine 5-Tage-Haltefrist und ein 8-Wochen-Erstattungsfenster. Wenn das System Core-Regeln auf B2B-Transaktionen anwendet, hält es Mittel zu lange. Wenn es B2B-Regeln auf Core-Transaktionen anwendet, hält es zu wenig, und ist Returns ausgesetzt, die es nicht decken kann.

---

Weiterlesen: Payments, Zahlungsorchestration | Connectivity, Financial Rails

---

Quellen:

• European Payments Council: EPC016-06 (SEPA Core Direct Debit Rulebook, v2024.1)
• European Payments Council: EPC222-07 (SEPA B2B Direct Debit Rulebook)
• PSD2, Richtlinie 2015/2366, Art. 71 (Unautorisierte Transaktionen), Art. 76 (Erstattungsrechte für Lastschriften)
• HGB §239, Handelsgesetzbuch, Anforderungen an die Korrektur von Buchungseinträgen
• EZB TARGET2-Kalender (https://www.ecb.europa.eu/paym/target/target2/profuse/calendar/html/index.en.html)
• ISO 20022 ExternalStatusReason1Code, pacs.004.001.11 Reason-Code-Aufzählung