Viele RTP-Implementierungen sind architektonisch tot, bevor sie live gehen

Request to Pay (RTP) ist spezifiziert, regulatorisch gedeckt und in Deutschland trotzdem nicht weit verbreitet. Der Grund: Implementierungsteams treffen falsche Architektur­entscheidungen – und bemerken es erst im Produktivbetrieb.

von Bert Schuiling, KIWI Consulting

Die EU-Instant-Payments-Verordnung ist seit Oktober 2025 weitgehend implementiert. Das SEPA-Request-to-Pay-Rulebook (RTP) des European Payment Councils (EPC) liegt seit 2021 vor. Trotzdem produzieren die meisten RTP-Initiativen dasselbe Ergebnis: ein Pilotprojekt mit ISO-20022-Nachrichten, das keiner nutzt.

Der Fehler liegt nicht im Standard. Er liegt in wiederkehrenden Architektur­entscheidungen, die Adoption strukturell erschweren.“

Das SEPA-RTP-Rulebook (EPC014-20) definiert ein 4-Corner-Modell mit Zahlungsempfänger, RTP Service Provider des Zahlungsempfängers, RTP Service Provider des Zahlers und dem Zahler. Nachrichten fließen über einen Inter-RTP-Service-Provider-Layer, der infrastruktur-agnostisch ist. Das Scheme schreibt als Nachrichtenformat nur ISO-20022-XML vor: pain.013, der eigentliche Zahlungsaufruf, und pain.014, die Statusrückmeldung. Delivery-Kanäle, bilaterale Feldnutzung und UX-Layer sind verhandelbar.

Das klingt nach Flexibilität. In der Praxis entsteht daraus Fragmentierung: Jeder Implementierungspartner interpretiert die erlaubten bilateralen Vereinbarungen unterschiedlich. Das Ergebnis sind parallele, inkompatible Lösungen, die den Netzwerkeffekt untergraben, den RTP braucht. Für Produktverantwortliche bedeutet das höhere Integrationskosten, längere Time-to-Market und geringere Merchant-Adoption, weil Händler nicht in mehrere proprietäre Varianten desselben Standards investieren.

Was das Rulebook operational fordert, ist eindeutig: Nachrichten müssen „Instantly“ übertragen werden, „at once, without delay“.“

Der Inter-RTP-Provider-Layer muss dafür jederzeit verfügbar sein: 24 Stunden am Tag, 7 Tage die Woche, 365 Tage im Jahr. Das Zeitfenster, in dem der Zahler auf eine Anforderung reagieren kann (Expiry Date/Time), beträgt standardmäßig maximal drei Monate. Läuft die Frist ab, muss der RTP Service Provider des Zahlers automatisch eine negative Status-Response senden.

Der Mindestdatensatz nach DS-01, dem Schema für den initialen Zahlungsempfänger-seitigen Request, umfasst sieben Pflichtfelder: Identifier des Zahlers, IBAN und Name des Zahlungsempfängers, Betrag, gewünschtes Zahlungsinstrument (z. B. SCT Inst), gewünschter Ausführungszeitpunkt und Expiry Date/Time.“

Daneben existieren rund 25 optionale Felder. Projekte, die das Ziel haben, alle davon im ersten Release zu aktivieren, schaffen Komplexität ohne Mehrwert – und verschieben den Go-live-Termin unnötig.

Das strukturelle Architekturproblem: Synchrones Denken in einem asynchronen Protokoll

RTP ist kein Request-Response-Protokoll. Es ist ein asynchrones Messaging-System mit definiertem State-Machine-Verhalten. Ein verbreitetes Implementierungsmuster wartet synchron auf den pain.014-Status und sieht keinen Mechanismus für den Fall vor, dass diese Antwort ausbleibt. Das Rulebook beschreibt in Prozessschritt PS-01.12 explizit diesen Normalfall: Der Zahlungsempfänger RTP Service Provider kann einen „Request for Status Update“ über DS-14/DS-15 (Datensätze für die Statusabfrage) senden, wenn bis zur Expiry Date/Time keine Rückmeldung eingeht. Das ist kein Randszenario, sondern regulärer Betrieb.
Eine belastbare Implementierungs­architektur braucht deshalb drei Eigenschaften:
1. Event-driven Message Handling statt synchroner Direktaufrufe:
Der Inter-Provider-Layer muss Nachrichten aneinanderreihen (Queue) und asynchron weiterleiten, sonst blockiert jede langsame Gegenpartei den Verarbeitungspfad.
2. Eine explizite State Machine pro RTP-Transaktion mit den Rulebook-definierten Zuständen:
CREATED → ROUTED → CONFIRMED → ACCEPTED / REFUSED / EXPIRED / CANCELLED.
Jeder Zustandsübergang wird durch ein definiertes Ereignis ausgelöst: positive Confirmation (DS-05), Rejection (DS-04), Refusal (DS-07), Request for Cancellation (DS-10/DS-11). Fehlt diese Zustandsverwaltung, sind Retry-Logiken und Timeout-Handling nicht sauber implementierbar.
3. Idempotenz auf allen Message-Endpunkten:
Das Rulebook definiert AT-63, den zusätzlichen eindeutigen Referenzwert des Zahlungsempfänger RTP Service Provider, als verpflichtenden Identifier, der in jedem Folge-Request mitgeführt wird. Er ist der technische Schlüssel zur Deduplizierung. Fehlt er in der Verarbeitungslogik, entstehen inkonsistente Transaktionszustände, die für Endnutzer direkt sichtbar werden. Das beeinträchtigt die Wahrnehmung der Dienstverlässlichkeit.

Was Tikkie, Swish und Vipps richtig gemacht haben

Die europäischen Märkte, in denen RTP zum Massenprodukt wurde, haben eine gemeinsame architektonische Entscheidung getroffen: die UX-Schicht konsequent von der Protokollschicht zu entkoppeln.
Tikkie zeigt dem Zahler keinen ISO-20022-Nachrichteninhalt. Er sieht Betrag, Namen, Verwendungszweck und einen Button. Die technische Umsetzung gelingt wie folgt: iDEAL als Payment-Rail, eine Link-basierte Delivery ohne das Öffnen der Banking-App und automatisierte Reconciliation über AT-05 (Feld für den Zahlungsverwendungszweck).

Die Konversionsrate liegt bei 89 Prozent innerhalb von 24 Stunden. Das ist das Ergebnis einer konsequenten Reduktion auf wenige sichtbare Felder.“

Das SEPA-RTP-Rulebook erlaubt genau das. Sektion 1.1 formuliert: „The Payer can directly receive an RTP by the Payee through various environments such as proximity technologies, messaging applications, dedicated APIs.” Link-Delivery, QR-Code und Push-Notification sind im Standard vorgesehen. Die Reihenfolge, in der implementiert wird, entscheidet darüber, wann belastbares Nutzerfeedback eingeht, das die weiteren Architektur­entscheidungen informieren kann.

Fraud als Architekturthema

APP-Fraud (Authorised Push Payment Fraud) ist keine theoretische Gefahr: In Großbritannien beliefen sich die Verluste im ersten Halbjahr 2025 auf 257,5 Millionen Pfund, was einem Anstieg von zwölf Prozent gegenüber dem Vorjahr entspricht.

APP-Fraud macht 41 Prozent aller Betrugsverluste aus. RTP verschiebt das Risikoprofil strukturell: Der Zahler autorisiert aktiv, ein automatisches Rückgaberecht wie bei SEPA Direct Debit gibt es nicht.“

Das Rulebook sieht Reject-Code AT-R3 „Suspicion of fraud“ explizit in der Validierungslogik des RTP Service Provider des Zahlers vor: „Prozessschritt PS-01.05 – die Eingangsvalidierung beim empfangenden Service Provider“. Damit verschiebt sich die Verantwortung für wirksame Präventionsmechanismen in Richtung des empfangenden Service Providers. Echtzeit-Risikomodelle, die vor der Autorisierung greifen, sind keine optionale Erweiterung, sie sind operativer Kern einer produktionsfähigen Implementierung.

Fazit: Wo RTP-Projekte gewonnen oder verloren werden

Die beschriebenen Architekturmuster sind bekannt. Weniger klar ist, wie sie sich in laufenden RTP-Projekten konkret niederschlagen sollten. Vier Entscheidungen haben dabei überproportionalen Einfluss auf Adoptionserfolg und Time-to-Market:
1. Scope von Anfang an begrenzen:
DS-01 hat sieben Pflichtfelder. Das ist der sinnvolle Startpunkt. Felder wie AT-78 (Anhang), AT-90 (Händlerkategorie-Code) oder AT-91 (Flag für positive Empfangsbestätigung) sind valide Erweiterungen für spätere Releases. Wer alles gleichzeitig implementiert, verschiebt den Go-live und produziert eine Spezifikation, die niemand vollständig testet.
2. Den Zahler-Identifier nicht auf IBAN beschränken:
AT-01 erlaubt explizit Alias, Token oder Proxy-Identifier, wenn beide Service Provider das bilateral vereinbaren. Eine Telefonnummer als Zahler-Identifier, wie sie Swish und BLIK nutzen, senkt die Abbruchrate bei der Empfängeridentifikation erheblich und verbessert direkt die Merchant-Adoption.
3. AT-77 (Expiry Date/Time) als UX-Signal behandeln:
„Zahlung bis heute 18:00 Uhr“ ist informativer als ein generischer Fälligkeitshinweis. Das Rulebook gibt das zeitliche Steuerungselement vor. Die UX-Umsetzung entscheidet, ob der Zahler die Anforderung als dringend oder ignorierbar wahrnimmt.
4. Fraud-Scoring in PS-01.05 verankern:
Präventionslogik, die erst nach der Autorisierung ansetzt, ist für RTP strukturell unzureichend. Die Eingangsvalidierung beim Zahler-RTP-Service-Provider ist der architektonisch richtige Ort für Echtzeit-Risikobewertung.

RTP scheitert nicht an fehlenden Standards. Es scheitert an der Reihenfolge: Wer den Backend-Stack vor dem Use Case definiert, baut einen Piloten für die Schublade. Wer hingegen mit den Pflichtfeldern startet, einen Alltagsanwendungsfall wählt und damit Volumen aufbaut, bevor optionale Felder überhaupt diskutiert werden, entwickelt ein Produkt. Der Standard ist bereit. Die Architektur­entscheidungen liegen auf dem Tisch. Was fehlt, ist die Entscheidung, welchen Use Case man zuerst live stellt. Bert Schuiling, KIWI Consulting