SEPA Request-to-Pay
Veröffentlicht am
24.08.2026
Aktualisiert am
24.08.2026
Lesezeit
4 min
Definition
SEPA Request-to-Pay (SRTP) ist das Verfahren, mit dem ein Zahlungsempfänger einen Zahler auffordert, eine Zahlung auszulösen. Der Empfänger schickt eine strukturierte Zahlungsanforderung; der Zahler entscheidet, ob und wann er sie begleicht.
Entscheidend für das Verständnis: SRTP ist kein Zahlungsverfahren. Es bewegt kein Geld, sondern übermittelt eine Nachricht, die einer Zahlung vorausgeht. Die Zahlung selbst erfolgt anschließend als SCT oder als Echtzeitüberweisung (SCT Inst(opens in new tab)). Das EPC führt SRTP deshalb nicht unter seinen Zahlungsverfahren, sondern als eigenständiges Scheme daneben, vergleichbar wie bei Verification of Payee.
Abgrenzung zur Lastschrift
Der Vergleich mit der SDD liegt nahe, führt aber in die Irre. Beide dienen dazu, offene Forderungen einzuziehen, aber die Kontrolle liegt jedoch bei verschiedenen Parteien.
Bei der Lastschrift holt der Gläubiger das Geld aufgrund eines Mandats; der Zahler kann anschließend widersprechen, bei der Basislastschrift bis zu acht Wochen ohne Angabe von Gründen. Bei SRTP bittet der Gläubiger, und der Zahler löst die Zahlung selbst aus. Die daraus entstehende Überweisung ist unwiderruflich.
Für den Gläubiger bedeutet das: kein Mandatsmanagement, keine R-Transaktionen aus Rücklastschriften, dafür aber auch keine Gewissheit, dass gezahlt wird.
Die Varianten der Anforderung
Das Rulebook unterscheidet nach dem Zeitpunkt von Zustimmung und Zahlung drei Grundformen:
| Variante | Bedeutung |
|---|---|
| Accept Now / Pay Now | Der Zahler stimmt sofort zu, die Zahlung wird unmittelbar ausgelöst |
| Accept Now / Pay Later | Der Zahler stimmt sofort zu, die Zahlung erfolgt zum vereinbarten Termin |
| Accept Later / Pay Later | Der Zahler entscheidet später und zahlt später |
Gesteuert wird dies über zwei Zeitangaben in der Anforderung:
- Expiry Date/Time – bis wann der Zahler annehmen oder ablehnen muss. Die Frist kann bis zu drei Monate betragen.
- Requested Execution Date/Time – wann die Zahlung erfolgen soll (vergleiche Due Date).
Aus dieser Kombination ergibt sich die praktische Bandbreite: Von der Sofortzahlung über die Rechnung mit Zahlungsziel bis zur Anforderung, die der Zahler in Ruhe prüfen und terminieren kann.
Rollen und Ablauf
SRTP folgt einem Vier-Parteien-Modell:
1. Payee: Zahlungsempfänger, der die Anforderung stellt
2. Payee’s SRTP Service Provider: dessen Dienstleister/Bank
3. Payer’s SRTP Service Provider: Dienstleister/Bank des Zahlers
4. Payer: der Zahler, der die Anforderung erhält und entscheidet
Bemerkenswert: Die Dienstleister müssen keine Zahlungsdienstleister sein. Anders als bei den Zahlungsverfahren des EPC steht SRTP ausdrücklich auch Nicht-PSPs offen, z.B. Rechnungs- und Softwaredienstleistern.
Für das Auffinden des zuständigen Dienstleisters dient der EPC Directory Service (EDS). Dieselbe Infrastruktur, die auch für die Empfängerprüfung (Verification of Payee(opens in new tab)) genutzt wird.
Der Zahler kann auf drei Weisen reagieren: Positive Response (Annahme), Negative Response (Ablehnung mit einem Grund aus den Reason Codes) oder gar nicht, worauf die Anforderung mit dem Expiry-Zeitpunkt verfällt. Daneben kennt das Scheme den Reject vor der regulären Verarbeitung, die Request for Cancellation durch den Empfänger und die Status Request zur Nachfrage nach dem Bearbeitungsstand.
Nachrichten
Der Austausch zwischen den Dienstleistern ist im Rulebook über Datensätze beschrieben (DS-01 für die Anforderung des Empfängers an seinen Dienstleister, DS-02 für die Strecke zwischen den Dienstleistern, DS-03 für die Darstellung beim Zahler, DS-07 für dessen Antwort und weitere für Stornierung und Statusabfrage).
Technisch liegen dem die ISO-20022-Nachrichten pain.013 und pain.014 zugrunde: die Zahlungsanforderung und der zugehörige Statusbericht.
Entstehung und Stand
Die Initiative geht auf einen Auftrag des Euro Retail Payments Board zurück. Das EPC beauftragte im November 2020 eine Arbeitsgruppe, veröffentlichte das erste Rulebook am 30. November 2020 und setzte es zum 15. Juni 2021 in Kraft.
Zum Stand August 2026 gilt Version 4.0, veröffentlicht am 29. November 2024 und wirksam seit dem 5. Oktober 2025, demselben Tag, an dem auch das SCT-Inst-Rulebook 2025 in Kraft trat. Schwerpunkt der Fassung war die Vereinfachung des Schemes.
Die Verbreitung bleibt allerdings hinter den Erwartungen zurück. Zum Stand November 2025 waren lediglich drei Teilnehmer sowie drei technische Dienstleister im Register veröffentlicht.
Ob SRTP Verbreitung findet, ist mehr als fraglich. Banken mit viel Privatkonten, also den Zahlern, müssen neben der technischen Umsetzung in Kernbankensystem auch die Kommunikation mit ihren Kontoinhabern führen. Diesem Aufwand stehen keine Einkünfte gegenüber, insofern fehlt ihnen der Business Case.
Anwendungsfälle
Viele Firmen (und deren Banken bzw. Dienstleister) sehen bei SRTP viele wundervolle Möglichkeiten zu ihrem Vorteil:
- Elektronische Rechnung – die Anforderung trägt die Rechnungsreferenz mit, was die Zuordnung des Zahlungseingangs erleichtert
- E-Commerce – Bezahlung direkt vom Konto, ohne Kartenstrecke
- Wiederkehrende Forderungen – als Alternative zur Lastschrift, wenn die Kontrolle beim Zahler bleiben soll