Request to Pay (RTP) – Eine weitere Revolution im Zahlungsverkehr?

Laut Bitkom nutzten 70 % der Bundesbürger im Jahr 2019 Online-Banking für die Erledigung ihrer Bankengeschäfte. Nimmt man an, dass diese Menschen eine Rechnung online begleichen wollen, müssten sie alle notwendigen Daten mühsam aus der Rechnungsaufstellung suchen oder im schlimmsten Fall aus dem beigelegten Überweisungsschein (fehleranfällig) abtippen. In den letzten Jahren wurden zwar diverse Lösungen von den Banken entwickelt, wie das Auslesen eines QR-Codes auf der Rechnung oder das Abfotografieren beziehungsweise Einscannen über eine Banking-App. Doch diese Funktionen werden meist nur in den Smartphone-Apps der Banken angeboten und betrachten nur die Seite des Zahlers. Zusätzlich decken sie nicht alle Aspekte ab, wie beispielsweise die termingerechte Bezahlung oder die korrekte Zuordnung auf der Seite des Gläubigers. Alle diese Herausforderungen sollen von der elektronischen Zahlungsanforderung Request to Pay abgedeckt werden.

„to Request“ und „to Pay“

Request to Pay (RTP) enthält, wie der Name schon verrät, prozessual zwei Teile: to request und to pay. Bei Request, wie die elektronische Zahlungsanforderung international genannt wird, handelt es sich um ein Nachrichtenverfahren für die strukturierten und abgestimmten Übermittlungen aller notwendigen Daten einer Rechnung an den Zahlungspflichtigen. Pay bezeichnet die dahinterstehende Zahlungsabwicklung. Dabei kann als Zahlungsinstrument SEPA Instant Payment oder SEPA Überweisung in Frage kommen.

Die Regelwerke geben nicht die Nutzung einer bestimmten Zahlungsart vor, empfohlen wird jedoch SEPA Instant Payment, also die Echtzeitüberweisung. Alle Beteiligten sind sich einig, dass die Wahl von SEPA Instant Payments den Bekanntheitsgrad des Verfahrens und die Durchdringung in den Markt ein Stück vorantreiben würde.

Was sagt der Markt? Welche Initiativen gibt es bereits?

Request to Pay als Initiative kommt aus Großbritannien und an der Marktreaktion kann man schon jetzt erkennen: Es hat das Potenzial, eine weltweite Lösung zu werden. Dementsprechend haben auch die Regulatoren ein großes Interesse daran, hierfür ein gutes Schema, Format- und Produktlösungen zu definieren.

Den Anfang hat die EBA-Clearing in Zusammenarbeit mit 27 Zahlungsdienstleistern (Payment Service Provider) aus elf europäischen Ländern gemacht. Im zweiten Quartal 2020 hat sie die Guidelines veröffentlicht sowie eine entsprechende Infrastruktur und ein Schema für Request to Pay (mit der Abkürzung R2P) definiert.

Das EPC folgte mit der europäischen Standarisierung des Verfahrens, dessen Regelwerk SEPA-Request-to-Pay (SRTP oder nur RTP) im November 2020 veröffentlicht wurde und am 15. Juni 2021 in Kraft getreten ist. Die Teilnahme ist allerdings, wie bei Instant Payments, freiwillig.

Eine weitere Initiative kommt von der SWIFT-Seite. SWIFT plant ebenfalls, eine Lösung dazu zu definieren und Request to Pay aus der europäischen Ebene hervorzuheben.

Wie kann man sich RTP vorstellen? Wie funktioniert es?

Die Zahlungsaufforderung wird immer vom Zahlungsempfänger (beispielsweise ein Online-Händler) initiiert. Die Aufforderung (Request) kann sowohl ein Ablaufdatum mit Ablaufzeit als auch ein gewünschtes Ausführungsdatum beinhalten. In der Nachricht kann auch eine Rechnungsreferenz hinterlegt werden, damit der Zahlungseingang automatisch den Rechnungsposten zugeordnet wird.

Der Empfänger (beispielsweise ein Käufer) erhält innerhalb von wenigen Sekunden die Zahlungsanforderung. Nach Erhalt der Nachricht hat der Zahler die folgenden Möglichkeiten, auf die Aufforderung zu reagieren:

• Jetzt annehmen
• Später annehmen
• Jetzt bezahlen
• Später bezahlen
• Vollständig ablehnen

Der Zahlungsempfänger erhält von seiner Bank über einen Statusbericht die Information, wie sich der Zahler entschieden hat. Der Statusbericht ist neben der Aufforderung zur Zahlung der zweite Nachrichtentyp, der durch das SRTP-Regelwerk vom EPC definiert wird.

Wie in Abbildung 1 beschrieben, funktioniert das Verfahren nach dem Vier-Parteien-Prinzip.

1. Im ersten Schritt finden die Kommunikation und Identifizierung des Zahlers statt.
2. Der Zahlungsempfänger sendet die RTP-Nachricht an seinen Service Provider.
3. Die RTP-Nachricht wird an das RTP-Provider-Netzwerk gesendet.
4. Der Zahler erhält die RTP-Nachricht.
5. Im letzten Schritt entscheidet der Zahler über die Annahme oder Ablehnung der RTP-Nachricht und sendet sie an den Zahlungsempfänger.

Bei der Betrachtung einer vereinfachten positiven Entscheidung mit sofortiger Annahme wird der Prozess mit der Initiierung und Ausführung einer Echtzeitüberweisung fortgeführt. Die Rechnungsdaten könnten aus der RTP-Nachricht in der jeweiligen eBanking-App übertragen werden, der Kunde kann in seiner gewohnten Art den Zahlungsauftrag überprüfen und, zum Beispiel mittels TAN-Freigabe, ausführen.

Alternativ kann der Zahlungsauftrag mittels eines Proxy Lookup Services initiiert werden. Dazu existiert ebenfalls die Initiative SEPA Proxy Lookup (SPL) des EPCs. Die Übermittlung aller notwendigen Daten würde dann beispielsweise über eine mobile Telefonnummer erfolgen.

Request To Pay wird oft als „Revolutionsprodukt“ im Zahlungsverkehr betitelt. Ist das so?

Ganz klar liegt der Vorteil bei Firmenkunden, E-Commerce und im Online-Geschäft, dieses Verfahren mit der Möglichkeit der Zahlungsanforderung (pain.013) anhand eines Anhangs zu schicken. Dafür bietet sich eine Zusendung der Rechnung an, in der sich alle notwendigen Informationen für die Einreichung der Zahlung bereits digital befinden. Mit der Rückmeldung (pain.014) kann dann gleichzeitig eine Zahlung (SCT/SCTINST) initiiert werden. Dies vereinfacht den Zahlungsprozess für den Zahler. Mit der Rückmeldung bekommt der Zahlungsempfänger die Sicherheit, ob und wann die Rechnung bezahlt wird. Das ist ein wichtiger Bestandteil für das eigene Liquiditätsmanagement.

Auch im Privatkunden-Bereich gibt es Use Cases, die zu wesentlichen Vorteilen führen könnten. Wenn man zukünftig beispielsweise direkt aus einer App nach dem gemeinsamen Mittagessen eine RTP an alle Teilnehmer generieren konnte, würde das wahrscheinlich zu einem ganz anderen Zahlungserlebnis führen, als wir es heute kennen.

Aus Sicht der Banken ist es ein Model, an dem nur der Zahler, die Bank des Zahlers und der Zahlungsempfänger beteiligt sind – ohne die Beteiligung von Drittparteien.

Folgendes könnte aber zu einem kurzfristigen Nachteil führen: Um eine RTP senden zu können, muss der RTP-Empfänger auch RTP-fähig sein. Die Lesson‘s Learned von anderen Europäischen Initiativen, wie etwa die Einführung von SEPA oder Instant Payments ist klar: Das Produkt wird erst von der Masse genutzt, wenn damit auch die große Mehrheit im Markt erreicht werden kann. Eine Verpflichtung der Instant Payments (auch wenn nur die passive Teilnahme), würde hier die frühe Marktpenetration deutlich beschleunigen.

Request to Pay verknüpft die Zahlungsanforderung mit der Zahlung auf eine Art, wie es das am Markt noch nicht gegeben hat. Dazu erhöht sich für jeden Beteiligten die STP-Rate und die Tür zur Digitalisierung öffnet sich weiter, was RTP berechtigt, sich ein zukunftsfähiges Revolutionsprodukt zu nennen. Wir werden von Request to Pay mit der Zeit immer mehr hören und viele Softwarehersteller bieten bereits Lösungen für RTP an. Will die Bank ein Vorreiter im Zahlungsverkehr sein, muss sie das Request to Pay frühzeitig in ihre Roadmap einplanen.