Zahlungen10 Min. Lesezeit

ISO 20022 und die neue Schnittstelle des Geldes: Was TradFi-DeFi-Konvergenz für Payment-Orchestrierung bedeutet

TradFi-DeFi-Konvergenz bricht auf der Settlement-Ebene, nicht auf der Datenebene. SEPA Credit Transfers settleln über deferred net settlement mit T+1-Finalität, bestätigt durch ein Clearing und Settlement Mechanism. On-Chain-Transaktionen settleln über atomic gross settlement mit Finalität, bestimmt durch Block-Confirmation-Depth. Das sind nicht nur unterschiedliche Geschwindigkeiten. Es sind unterschiedliche Annahmen über Finalität, Reversibilität und Recovery, die eine Payment-Orchestrierungsschicht explizit auflösen muss, bevor sie entweder Modell korrekt handhaben kann.

ISO 20022 bietet eine gemeinsame Datensprache für beide Welten. Die Nachrichtenstruktur, die einen pacs.008 SEPA Credit Transfer trägt, kann mit Erweiterungen eine On-Chain-Transfer-Anweisung tragen. Die BankTransactionCode-Taxonomie klassifiziert traditionelle Zahlungstypen; der Standard wird erweitert, um tokenisierte Asset-Bewegungen abzudecken. Datenformat ist ein gelöstes Problem. Das Orchestrierungsmodell ist es nicht.

Zwei Settlement-Modelle, zwei Finalitätsannahmen

Deferred net settlement arbeitet, indem es während des Tages ausgleichende Verpflichtungen über Teilnehmer akkumuliert und sie zu definierten Clearing-Fenstern nettiert. Ein pacs.008, der um 09:00 eingereicht wird, mag erst beim 14:00-Clearing-Zyklus settlen. Während dieses Fensters ist die Zahlung ein Anspruch, kein settled Transfer. Der Anspruch kann abgelehnt werden (pacs.002 negative Bestätigung), zurückgerufen werden (camt.056 Stornierungsantrag) oder nach Settlement zurückgegeben werden (pacs.004 R-Transaktion). Finalität ist erst nach Schließung des Clearing-Fensters unwiderruflich.

Die Orchestrierungsschicht muss diesen Lebenszyklus verfolgen. Eine Zahlung, die eingereicht, aber nicht gesettelt wurde, befindet sich in einem bekannten Zwischenzustand: SUBMITTED_TO_CLEARING. Eine Zahlung, die gesettelt ist, ist SETTLED. Eine Zahlung, die zurückgegeben wurde, ist RETURNED. Das Ledger muss diese Zustände unterschiedlich behandeln: den Debit erst als final markieren, wenn das Settlement bestätigt ist, weil das R-Transaktions-Fenster noch offen ist.

On-Chain-Settlement ist atomar und final bei Bestätigung. Wenn eine Transaktion in einem bestätigten Block auf einer deterministischen Chain enthalten ist, ist sie gesettelt. Es gibt keinen Intermediär. Es gibt kein Clearing-Fenster. Es gibt keinen Mechanismus, sie durch einen strukturierten R-Transaktionsprozess zu reversieren. Nur der Ursprünger kann eine neue kompensierende Transaktion initiieren, die im Ledger als separater Eintrag erscheint, nicht als Reversal der Originaltransaktion.

Die Finalitätsannahme ist nicht nur graduell verschieden, sondern grundsätzlich. TradFi-Settlement-Finalität ist ein rechtliches Konstrukt: das Clearing-Agreement, die Regeln des Zahlungsschemas und die anwendbare Regulierung (PSD2 Art. 80-81 über Settlement-Finalität) definieren, wann eine Zahlung unwiderruflich ist. On-Chain-Settlement-Finalität ist ein mathematisches Konstrukt: sie ist die Wahrscheinlichkeit, dass der Block, der die Transaktion enthält, aus der kanonischen Chain reorganisiert wird. Für praktische Zwecke ist Finalität nach einer definierten Anzahl von Block-Bestätigungen erreicht, aber diese Zahl variiert nach Chain, Blockzeit und dem Risikoappetit der Institution.

Wo sich die Orchestrierungsschicht anpassen muss

Eine Payment-Orchestrierungsschicht, die ausschließlich für SEPA entwickelt wurde, hat fünf eingebaute Annahmen: Settlement ist gebündelt, Finalität kommt von einem Clearing-Netzwerk, R-Transaktionen sind der Reversal-Mechanismus, Zeitlinien werden in Stunden gemessen, und Gegenpartei-Identifikation erfolgt über IBAN. Jede Annahme bricht für On-Chain-Settlement.

Bündelung vs. Atomarität. SEPA-Batch-Submission erfordert das Sammeln von Überweisungen, den Aufbau einer pacs.008-Bulk-Nachricht und die Einreichung innerhalb des Clearing-Fensters. On-Chain-Submission erfordert das Signieren einer Transaktion und deren Broadcast. Die Orchestrierungsschicht muss zwischen diesen Submission-Modellen nach Instrumententyp unterscheiden. Ein einzelnes Orchestrierungsframework, das alle Zahlungseinreichungen als queue-basierte Batch-Submissions behandelt, führt unnötige Latenz für On-Chain-Transfers ein und falsches Lebenszyklus-Management für SEPA-Transfers.

Finalitätsbestätigung. Für SEPA kommt Finalitätsbestätigung als camt.054 Credit Notification oder pacs.002 positive Bestätigung vom Clearing-Netzwerk. Für On-Chain-Transfers erfordert Finalitätsbestätigung das Monitoring der Chain, bis die Zielblocktiefe erreicht ist. Die Orchestrierungsschicht muss Chain-State pollen oder subscriben, ein Mechanismus ohne Analogon in der SEPA-Verarbeitung. Das Timeout-Modell ist ebenfalls unterschiedlich: SEPA hat definierte Clearing-Fenster und explizite Ablehnungsnachrichten. Eine On-Chain-Transaktion, die in angemessener Zeit nicht bestätigt wird, ist nicht abgelehnt; sie ist noch ausstehend, potenziell im Mempool stecken, und erfordert manuellen Eingriff oder Rebroadcast mit höheren Fees.

Reversal-Mechanismus. Wenn eine SEPA-Zahlung nach Settlement reversiert werden muss, ist der Standardmechanismus pacs.004 (Payment Return) oder camt.056 (Cancellation Request), die beide zu einer strukturierten R-Transaktion mit definiertem Reason Code, definiertem Zeitplan und definiertem Ledger-Treatment führen (Korrektureintrag nach HGB §239). Für On-Chain-Transfers ist Reversal eine neue Transaktion: Debit des Empfängers, Credit des Senders, Referenz auf die Originaltransaktion in den Metadaten. Das Reversal ist nicht standardisiert, nicht automatisch klassifiziert und nicht einem schema-definierten Deadline unterworfen. Die Orchestrierungsschicht muss beide Reversal-Modelle mit unterschiedlicher Journaling-Logik behandeln.

Gegenpartei-Identifikation. SEPA verwendet IBAN als primären Kontenidentifier. On-Chain-Transfers verwenden eine kryptografische Adresse (Public-Key-Hash). Eine Orchestrierungsschicht, die beides verarbeitet, muss das Adressenmodell auflösen: ist eine Blockchain-Adresse ein erstklassiger Kontenidentifier, der im Ledger gespeichert wird, oder ist sie eine Eigenschaft eines CDD-Datensatzes des Kunden? Die Antwort beeinflusst Kunden-Deduplizierung, Transaktionsüberwachung und Sanktions-Screening, die alle auf dem IBAN-Modell operieren und für Adress-basierte Identifikation adaptiert werden müssen.

ISO 20022 als Brücke

Die Erweiterbarkeit von ISO 20022 macht es zur natürlichen Datenbrücke zwischen Settlement-Modellen. Die pacs-Nachrichtentypen (pacs.008 für Credit Transfers, pacs.004 für Returns) werden bereits für SEPA verwendet. Dieselben Nachrichtenstrukturen, mit Local-Instrument-Codes, die das Settlement-Modell identifizieren, können On-Chain-Transfer-Anweisungen tragen.

Die BankTransactionCode-Taxonomie bietet einen Klassifikationsrahmen. PMNT/RCDT/ESCT identifiziert einen eingehenden SEPA Credit Transfer. Ein neuer Code, PMNT/RCDT/TKNZ (tokenisierter eingehender Credit Transfer) oder äquivalent, in Entwicklung in ISO 20022-Erweiterungsarbeitsgruppen, würde einen eingehenden On-Chain-Transfer unter Verwendung derselben Domain/Family/SubFamily-Struktur identifizieren. Die AML-Engine, die Reconciliation-Engine und die Reporting-Pipeline, die bereits BankTransactionCodes konsumieren, können tokenisierte Transfers ohne separaten Code-Pfad verarbeiten, sobald der Code-Satz erweitert ist.

Die 27,5 Milliarden USD in tokenisierten real-world Assets on-chain Q1 2026, um 30% in drei Monaten gestiegen, repräsentieren ein Volumen, das keine Institution manuell durch separate Workflows verarbeiten kann. Der Druck, Token-Transfers in Standard-Zahlungs-Pipelines zu integrieren, ist bereits vorhanden. Der Datenstandard ist bereit. Das Orchestrierungsmodell muss aufholen.

Exactly-Once-Semantik über Settlement-Modelle hinweg

Exactly-Once-Ausführung ist schwerer zu garantieren, wenn die Zahlung Settlement-Modelle kreuzt. Eine hybride Zahlung (On-Chain initiieren, Off-Chain bestätigen, das Netto in Fiat settlen) erzeugt einen mehrstufigen Workflow, bei dem jeder Schritt ein unterschiedliches Idempotenz- und Reversal-Modell hat.

Betrachten: ein Kunde initiiert einen On-Chain-Transfer von EUR 50.000 von seinem tokenisierten Euro-Deposit auf das tokenisierte Konto einer Gegenpartei. Die empfangende Institution möchte Fiat-Settlement. Der Workflow:

Debit des tokenisierten Kontos des Kunden (On-Chain, atomar, unwiderruflich nach Bestätigung)
Fiat Credit Transfer an die Institution der Gegenpartei einreichen (SEPA, gebündelt, reversibel via R-Transaktion)
Settlement-Bestätigung vom Clearing-Netzwerk empfangen
Fiat-Konto der Gegenpartei gutschreiben

Wenn Schritt 2 nach Schritt 1 fehlschlägt, ist die Kompensation kein Reversal von Schritt 1. Es ist eine neue On-Chain-Gutschrift, um Gelder zurückzugeben. Wenn Schritt 3 nach Schritt 2 fehlschlägt, muss die Orchestrierungsschicht entweder auf Settlement-Bestätigung oder eine R-Transaktion warten, dann entsprechend gutschreiben oder belasten. Das Kompensationsmodell erfordert das Tracking des Settlement-Zustands beider Beine unabhängig.

Eine Durable-Execution-Engine journalisiert jeden Schritt vor Ausführung. Wenn die Engine zwischen Schritt 1 und Schritt 2 abstürzt, spielt sie das Journal beim Neustart ab und setzt bei Schritt 2 fort. Wenn Schritt 2 eine R-Transaktion produziert (die SEPA-Zahlung wird zurückgegeben), führt die Engine den Kompensationshandler aus: eine neue On-Chain-Gutschrift an den Ursprünger, aufgezeichnet als Korrektureintrag im Ledger. Die komplette Sequenz, beide Beine, der Fehler und die Kompensation, existiert in einem Journal mit einer Korrelations-ID.

Trade-offs

Die Orchestrierung von Zahlungen mit dualen Modellen führt eine operative Komplexität ein, die rein SEPA-fokussierte Systeme vermeiden.

Fehlermoden-Multiplikation. Jedes Settlement-Modell hat seine eigenen Fehlermodi. Ein System, das beides handhabt, muss beide Sets behandeln: SEPA R-Transaktionen, Clearing-Netzwerk-Ausfälle und Batch-Submission-Fehler auf einer Seite; Mempool-Congestion, Reorg-Risiko, Node-Konnektivitätsprobleme und Adressauflösungsfehler auf der anderen. Das Operations-Team muss für beides trainiert und ausgerüstet sein.

Latenz-Asymmetrie. On-Chain-Settlement für einige Instrumente dauert Sekunden. SEPA-Settlement dauert Stunden. Ein System, das beides als "Zahlung" darstellt, muss den Latenzunterschied explizit an Kunden und an die Downstream-Systeme machen, die von Settlement-Bestätigung abhängen. On-Chain-Settlement als schnelles SEPA-Analogon zu behandeln, das dieselbe erwartete Settlement-Zeit in Downstream-Systemen verwendet, wird falsches Reporting und falsche Kapitalberechnungen produzieren.

Regulatorische Klassifikation. Die rechtliche Klassifikation eines On-Chain-Transfers unterscheidet sich von einem SEPA-Transfer in Weisen, die das anwendbare regulatorische Treatment beeinflussen. Unter MiCAR tragen Transfers von EMTs spezifische AML-Verpflichtungen. Unter PSD2 tragen Fiat-Transfers unterschiedliche Verpflichtungen. Eine Zahlung, die Modelle kreuzt (Fiat rein, Token raus, oder Token rein, Fiat raus), muss für jeden Bein unabhängig korrekt klassifiziert werden. Die Compliance-Pipeline muss composite regulatorische Klassifikation handhaben, nicht eine einzelne Kategorie pro Transaktion.

Fernel Context

Fernels Payment-Orchestrierung verwendet ISO 20022-native Nachrichtenmodelle für SEPA-Zahlungstypen, mit BankTransactionCodes nativ gespeichert statt in proprietäre Codes übersetzt. Die Durable-Execution-Engine journalisiert jeden Zahlungsworkflow-Schritt, einschließlich der Settlement-Lebenszyklus-Zustände SUBMITTED_TO_CLEARING, SETTLED_PENDING und SETTLED_AVAILABLE, vor Ausführung. Die Erweiterung desselben Orchestrierungsmodells auf On-Chain-Settlement erfordert das Hinzufügen eines neuen Settlement-Adapters (Chain-Monitoring, Adressauflösung, Bestätigungs-Tracking) ohne Modifikation der Workflow-Engine oder des Ledgers. Das Journal-Modell ist settlement-modell-agnostisch by design: jeder Schritt trägt seinen eigenen Input/Output-Record unabhängig davon, ob die zugrundeliegende Operation eine SEPA-Einreichung oder ein Chain-Broadcast ist.

Weiterlesen: Payments, Payment-Orchestrierung | ISO 20022: Jenseits der Nachrichtenformat-Konvertierung | SEPA R-Transaktionen verstehen

Quellen:

Money20/20 Europe 2026, The New Intersection of Money: Where TradFi and DeFi Converge, ko-autoriert von Scarlett Sieber et al.
Cambridge Centre for Alternative Finance, Tokenized RWA Q1 2026: 27,5 Mrd. USD on-chain, +30% in 3 Monaten
ISO 20022 pacs.008.001.11 (Credit Transfer), pacs.004.001.11 (Payment Return): Nachrichtenstruktur-Spezifikationen
ISO 20022 BankTransactionCode External Code Sets, Domain/Family/SubFamily-Taxonomie
PSD2, Richtlinie 2015/2366, Art. 80-81 (Settlement-Finalität und Unwiderruflichkeit)
MiCAR, Verordnung (EU) 2023/1114, Art. 83 (AML-Verpflichtungen für tokenisierte Transfer-Instrumente)
EPC SCT Inst Rulebook (v2024.1): SEPA Instant Credit Transfer Settlement-Modell und Timing