Was haben die PSD2 mit dem Open Banking Ansatz (PSD2), SEPA Instant Credit Transfer, SEPA request to pay (SRTP) mit der Möglichkeit, Zahlungen aktiv anzufordern sowie SEPA Proxy Lockup gemeinsam? Dies und mehr sind Ideen, die die Europäische Union (EU) vorantreibt. Wir behalten den Überblick und so will auch in Teil 2 eine Einordnung und Einschätzung geben.
1. SEPA request to pay (SRTP)
SEPA Request to Pay (SRTP) ist ein Scheme, welcher von der Europäischen Zentralbank entwickelt wurde, um den Zahlungsverkehr innerhalb der Europäischen Union zu vereinfachen. Die Idee besteht darin, dass Unternehmen und Privatpersonen Zahlungsaufforderungen an Empfänger innerhalb der EU schicken. Empfängt ein Zahlender einen SRTP von einem Zahlungsempfänger, so muss er diesen lediglich freigeben und löst damit eine Überweisung aus. Die Rechnungsverwaltung kann dadurch deutlich erleichtert werden, der Prozess würde mehr Kontrolle über Ausgaben schaffen und gleichzeitig den Gesamtprozess ohne Unterbrechungen digitalisieren.
Aktuelle Situation SRTP
Grundsätzlich ist SRTP genauso wie Open Banking ein reiner Kommunikationsdienst, ohne dass jedoch ein Zahlungsdienst dahintersteht. Das bedeutet, dass dadurch nur der Informationsaustausch zwischen Zahlungsgeber und Zahlungsempfänger organisiert wird, nicht jedoch die Bezahlung selbst. Einem Händler ist allerdings nicht geholfen, wenn ein Kunde eine Zahlung zwar freigibt, diese jedoch nicht fließt. Um also eine Zahlung mit dem gewünschten „Sofort“-Effekt zu in Gang zu bringen, könnte meines Erachtens SCTinst verwendet werden.
Die Vermutung liegt nahe, dass die EU mit dieser Kombination einen komplett eigenen unabhängigen Scheme aus der Taufe heben möchte. Denn mit SRTP stünde der Kommunikationsdienst bereit und SCTInst könnte der Paymentdienst sein, der auf den SEPA Rails die Zahlungsabwicklung near real time ausführt.
SRTP vs. Girocode
Der Gedanke hinter SRTP ist schlüssig: Sofern kein SEPA Mandat vorliegt, muss der Endkunde Zahldaten aus einer Rechnung manuell in sein Banking Portal übernehmen oder den Zwischenschritt via Girocode gehen. Das ist ein aufgedruckter QR-Code auf der Rechnung, der alle relevanten Transaktions- und Empfängerdaten beinhaltet. Der Zahlende muss den Code nur noch scannen und sämtliche Rechnungsdetails werden in seiner Bankenapp ausgefüllt und müssen nur noch freigegeben werden.
Leider wird der Girocode nur auf vergleichsweise wenigen Rechnungen zur Verfügung gestellt. Bei SRTP ist der Gedanke fast identisch zum Girocode, nur die Rolle des Auslösers verschiebt sich. War es im zuvor skizzierten Fall noch der Endkunde, der sich aktiv darum kümmern muss, eine Zahlung in Gang zu bringen, schafft SRTP die Möglichkeit, diesen Schritt auf den Zahlungsempfänger zu übertragen. Wer aus welchem Grund auch immer Geld haben möchte, kann eben diese Zahlungsanfrage abschicken, worauf sie zeitnah beim Endkunden in der Bankenapp auftaucht. Dieser hat dadurch sämtliche offenen Forderungen auf einen Blick zur Verfügung und muss sie lediglich zur finalen Zahlung freigeben.
SRTP ermöglicht direkte Kommunikation
Sowohl SRTP als auch das oben genannten Open Banking sind Kommunikationsdienste. Ein wesentlicher Unterschied zwischen den beiden ist, dass die Endkunden im Open Banking vor allem Apps von Händlern oder anderen 3rd Parties nutzen, um über diese auf Bankinformationen zuzugreifen bzw. Zahlungen auszulösen. Bei SRTP hingegen ist der Scheme so aufgebaut, dass Endkunden direkt in der Banking-App die Freigabe der Zahlung vornehmen können und auch nur dort die Mehrwertservices (wie z.B. die Ablage der Rechnung an der jeweiligen Buchung) angeboten werden sollen. Auch ein dem BNPL (buy now pay later) ähnliches Angebot ist geplant, sodass der Zahlende entscheiden kann, ob er die Zahlung unmittelbar oder verzögert leisten möchte.
Herausforderungen SRTP
Analog der oben beschriebenen Schemes gilt auch für SRTP, dass es noch keine ausreichende Akzeptanzinfrastruktur bei den Händlern gibt. Kassen müssten z.B. einen standardisierten QR-Code r anzeigen, der von Banking Apps ausgelesen werden kann (oder umgekehrt, die App produziert den Code und die Kasse scannt ihn). Ob und in welchem Umfang sich SRTP durchsetzen wird, wird sich sicherlich mit dadurch entscheiden, welche Regelungen die EU vorgibt und wie bindend die Zahlungsannahme via SRTP sein wird.
Aufseiten der Endkunden sollte die Akzeptanz eine geringe Hürde darstellen, da die Marktdurchdringung per se sehr hoch ist, schlicht, weil fast jeder zahlungsmündige Bürger ein Bankkonto besitzt und mittels der Banking Apps ein zentrales Frontend damit bereits vorhanden wäre. Vielmehr wird es auf die Banken ankommen, wenn es darum geht, den SRTP Standard in ihre Systeme einzubinden, um diese Kommunikation zw. Händler und Endkunden zu ermöglichen, mit anschließender Zahlungsauslösung. Da es (im Gegensatz zu SCTInst) jedoch noch nicht verpflichtend ist, läuft die SRTP-Integration (wohlwollend ausgedrückt) schleppend an.
Ein wichtiger Punkt wird sein, wie wird das Thema Betrugsprävention bei SRTP gelöst. Denn jeder der in der Lage ist Zahlungsaufforderung auszulösen, kann dies berechtigt bzw. unberechtigt tun. Und noch komplizierter wird es sich gestalten, wenn es keiner IBAN vom Endkunden mehr bedarf, sondern nur noch der E-Mailadresse oder der Telefonnumer, um den Endkunden bei seiner Hausbank via SRTP zu erreichen.
News SRTP
Eine Neuigkeit, die ins Auge sticht und Hoffnung macht: Die DZ Bank, eine der größten Banken Deutschlands, startet einen bankenneutralen SRTP-Piloten mit einem geplanten Go-Live noch in diesem Jahr. Inhaber von Unternehmenskonten der Banken sollen ihre Rechnungen bald über SRTP stellen und empfangen können.
Einschätzung
SRTP ist ein potenter Ansatz und löst einige Probleme im Rechnungsgeschäft aus dem Stand: Das fehleranfällige Abtippen von IBAN oder Verwendungszweck entfällt, Rechnungen werden der entsprechenden Abbuchung automatisch und dauerhaft zugeordnet, und es gibt kein wild hereinfliegendes Abbuchen mehr wie bei der regulären Lastschrift. Die finale Freigabe liegt bei SEPA request to pay immer in der Hand des Zahlungspflichtigen.
Doch für die Banken bedeutet es, dass sie eine für den Endkunden ansprechende, zuverlässige und leicht bedienbare Payment UX (also eine Bedienoberfläche) zur Verfügung stellen müssen. Es muss die Frage erlaubt sein: Sind unsere Finanzinstitute, von denen sich doch einige immer noch schwer tun mit ihrem Weg in die Digitalisierung, dazu in der Lage?
Die Banken sind für mich die große Unbekannte in der Gleichung: Werden sie das Potential, das ihnen SRTP bietet, nutzen (wollen)? Ich selbst bin beispielsweise aufgrund meiner persönlichen Präferenzen keine direkte Zahlungsinteraktion mit meinen Banken mehr gewohnt und sicherlich stehe ich damit nicht allein da. Die Banken bekommen mit SRTP die einmalige Chance, wieder stärker in den Fokus der Endkunden zu rücken.
2. SEPA Proxy Lockup (SPL)
Einen ganz anderen Ansatz, um sich des Problems mit den viel zu langen und umständlichen IBANs anzunehmen, verfolgt der SEPA Proxy Lockup (SPL) Scheme.
Aktuelle Situation SPL
SPL ist eine Idee für einen Service, die aus 2016 stammt, damals revolutionär war und heute im europäischen Zahlungsraum überfällig ist. Im Gegensatz zu Paypal, wo die Zahlungsinformationen (credit card credentials oder IBAN für SEPA-Mandat) in der APP hinterlegt werden, referenziert bei SPL ein Alias (z.B. Handynummer und/oder Emailadresse) auf eine dahinter liegende IBAN. SPL ist also ein reiner Kommunikationsdienst, der einen Zahlungsscheme benötigt und beispielsweise auf SCTInst aufsetzen könnte. Der Zahlungsgeber sendet an seine teilnehmende Debitoren-Bank die Anfrage, Geld an eine dedizierte Telefonnummer bzw. E-Mail-Adresse versenden zu wollen. Ist der Debitor Bank der Empfänger (mit dem Alias) bekannt, könnte bereits ein SCTinst ausgelöst werden. Wenn nicht, geht die Anfrage an einen SEPA Proxy Look-up Provider, der die Anfrage an infrage kommende Creditor-Banken weitergibt und das Ergebnis zurückmeldet. Damit könnte zu guter Letzt nun eine SCTInst Zahlung angestoßen werden.
Herausforderungen SPL
Es soll bei SPL einen zentralen Punkt geben (SPL – SEPA Look up Proxy Provider), der die Anfragen und Antworten verarbeitet. Dies wird allem Anschein nach keine Organisation der EU übernehmen, sondern ein privates Unternehmen. Inwieweit das in die aktuelle Zeit passt hinsichtlich des Datenschutzes und der Datensicherheit ist fraglich.
Eine weitere Herausforderung ist – wieder einmal – die Akzeptanz der Nutzer. Der SPL-Ansatz wird nur funktionieren, wenn sich die Endkunden in großer Zahl zu dem Service anmelden. Ebenso müssen sich die Banken bzw. PSPs, die einen solchen Service anbieten wollen, in signifikanter Anzahl in das zentrale SPL-System integrieren. Doch aktuell bietet es nur einen Mehrwert für die Endkunden (ausschließlich P2P „Endkunde zu Endkunde“ Zahlungen), so wird das Interesse der Banken an der Umsetzung überschaubar bleiben.
Beim regulären Retail Payment (zwischen Endkunden und Händler) gibt es keine Probleme mit der Verwendung von IBANs und somit kann SPL kaum einen Mehrwert bieten. Die einzige Ausnahme bildet eine althergebrachte Rechnungszahlung, bei der die IBAN nicht automatisch ausgelesen werden kann (etwa durch ein Abfotografieren, aus der Banking-App oder durch das Auslesen eines QR-Codes). Das ist der einzig interessante Anwendungsfall im B2C Geschäft. Diese Nische sollte in Summe zu klein sein, sodass wir außer der EU (die sich im Sinne ihrer Bürger für P2P einsetzt) keinen wirklichen Sponsor für dieses Thema haben.
News SPL
Vor zwei Wochen gab es ein Ereignis, das darauf hinweist, dass der SPL Scheme keine wirkliche Zukunft mehr hat. An dieser Stelle seien die Stichworte EPI und iDEAL-Übernahme genannt. Dies wird ausführlich im vierten Teil dieser Artikelserie behandelt.
Einschätzung
Der SPL-Ansatz scheint mir für einen IBAN-Alias eindeutig zu komplex. Stand alone sehe ich dafür kaum eine Chance. Vielleicht gibt es Weiterentwicklungen im Open Banking bzw. SRTP, die dann die Telefonnummer oder eine Email-Adresse als Alias für eine IBAN bzw. ein Konto zuzulassen. So könnte die Idee hinter SPL in den jeweiligen Schemes weitergeführt werden.
In diesem Zusammenhang auch interessant:
