Die Befürchtung vieler FinTechs hat sich bewahrheitet: Die von den Banken bereitgestellten Schnittstellen für den Kontozugriff (XS2A) erfüllen in vielfacher Hinsicht nicht die erforderlichen Kriterien. Die Ergebnisse der ersten Testphase sind ernüchternd und auch die Marktbewährungsphase läuft nicht besser an. Damit gefährden Banken den technologischen Fortschritt, meint Gastautor Stefan Krautkrämer.
Die Ziele der PSD2
Die PSD2 ist als grundlegende Regulierung des europäischen Zahlungsverkehrsmarktes angelegt. Ihr Hauptziel: Den Bankkunden die Hoheit über ihre Kontodaten zu geben und damit den mündigen Bürger im digitalen Zeitalter zu stärken. Weitere Ziele: Ein gesunder, gleichberechtigter Wettbewerb zwischen allen Marktteilnehmern, sinkende Kosten im Zahlungsverkehr sowie mehr Innovationen. Der Kern der PSD2: Regulierte Drittanbieter sollten Zugriff auf die Bankdaten von Nutzern haben, wenn diese explizit der Verwendung zustimmen.
Der Zugriff auf die Bankkonten der Kunden sollte dabei über eine dedizierte Schnittstelle erfolgen. Die technischen Details wurden dabei in den EBA RTS (Regulatory Technical Standards) festgehalten. Während bislang der Zugriff auf Bankkonten über diverse Methoden und Schnittstellen (z.B. Screen Scraping, FinTS etc.) am Markt möglich ist, können Konten nach einer Testphase (mindestens sechs Monate vor Markteinführung) und einer Marktbewährungsphase (mindestens drei Monate Nutzung in breitem Umfang bis zur Markteinführung 14.9.2019) dann nur noch über die dedizierte Schnittstelle und nicht mehr über andere Technologien oder Schnittstellen angesprochen werden.
Alternative Zugriffsmaßnahmen sollten dann nur noch über Notfallmechanismen („Fallback-Lösung“) möglich sein, falls unter anderem die bereitgestellten Schnittstellen nicht reibungslos funktionieren. In diesem Fall muss das kontoführende Institut neben der dedizierte Schnittstelle weiterhin den Zugriff über die schon bisher existierenden Online-Banking-Schnittstellen ermöglichen, so schreibt es Art. 33 Abs. 6 RTS vor.
Banken können Freistellung vom Fallback beantragen
Banken und Kreditinstitute können bei der BaFin eine Freistellung beantragen, wenn sämtliche Kriterien hinsichtlich der Schnittstellen vollständig erfüllt sind. Diese Kriterien sind in den Artikeln 30, 31 und 32 der RTS zusammengefasst. Einige Banken haben laut BaFin bereits eine Freistellung beantragt, da aus Ihrer Sicht die Testphase der Schnittstellen zur völligen Zufriedenheit verläuft. Doch wie ist es aus Sicht eines regulierten Drittanbieters (Third Party Provider/TPP) wirklich um die Qualität der Test-Schnittstellen bestellt? Im folgenden Beitrag teilen wir die Erfahrungen aus der Testphase, die wir bei rund zwei Dutzend Instituten gemacht haben. Damit decken wir rund 80-90 Prozent der Banken in Deutschland ab. Wir haben die fünf größten Probleme sowie ungelösten Fragen mit den aktuell bereitgestellten Schnittstellen zusammengefasst:
1. Kein Kontoinhaber auslesbar
Problem: Wenn man als TPP über die Banken-Schnittstellen eine Liste an Konten abrufen möchte, so fehlt in den meisten Fällen der Name des Kontoinhabers. Das ist für viele innovative Bankprodukte ein Problem. Beispielsweise bei einem Online-Kredit mit digitaler Bonitätsprüfung: Bei einem Kreditantrag steht nicht mehr dabei, wessen Konto überhaupt auf Kreditwürdigkeit überprüft wird. Wenn der Kontoinhaber nicht verifiziert werden kann, ist eine einwandfreie Bonitätsprüfung unmöglich und es wird auf relative einfache Art und Weise Betrug möglich. Es gibt zwar das Feld “Name” beispielsweise bei der Schnittstelle der Berlin Group, die von 78 % der Banken verwendet wird (Erhebung der EZB). Diese wird allerdings von Banken unterschiedlich interpretiert. So wird hier teilweise der Kontoinhaber übergeben, häufig ist das Feld von den meisten Banken allerdings als Kontoname (z.B. „Mega Girokonto Plus”) vorgesehen.
2. Redirect vs. Embedded Anmeldung
Die starke Kundenauthentifizierung (Strong Customer Authentification/SCA) kann je nach Schnittstelle mit mehreren Verfahren durchgeführt werden, zum Beispiel mittels Redirect, Embbeded und Decoupled. Beim Redirect wird der Nutzer wird auf die Authentifikations-Seite der Bank weitergeleitet, bei Decoupled wird der Nutzer für die Authentifizierung zu einer Applikation weitergeleitet und bei Embedded gibt der Nutzer seine Zugangsdaten für die Authentifizierung direkt beim TPP ein.
Problem: Eine Embedded-Anmeldung scheint bei einigen Banken aktuell nur möglich zu sein, wenn man bereits die IBANs der Konten aus dem Account kennt. Man muss nämlich, sofern man Embedded-Anmeldung verwenden möchte, für jede einzelne IBAN angeben, welche Operation ausgeführt werden soll. Viele Produkte von TPP lesen aber immer zuerst die Liste der Konten aus und lassen den Endkunden anschließend das Referenzkonto auswählen. Dieses bewährte Vorgehen würde nach dem jetzigen Modell nur mit einer Anmeldung per Redirect funktionieren. Das wiederum wäre auf jeden Fall eine grobe Unterbrechung der Customer Journey: Der Kunde würde bei jeder Anfrage an sein Online-Banking Konto (z.B. in einer Multibanking-App) über einen Redirect aus der App heraus auf die Website der Bank geleitet werden und gezwungen sein, sich gegenüber seinem Institut zu identifizieren. Dies ist eine Unterbrechung des gewohnten Prozesses und schwächt erfahrungsgemäß die Konversion beziehungsweise den Nutzungsgrad.
3. Kontoinformation und Zahlungsauslösung
Problem: Die bereit gestellten APIs für Kontoinformation und Zahlungsauslösung sind über die jeweilige, spezifische Anfrage getrennt. Wenn also der TPP eine Zustimmung („Consent“) beim kontoführenden Institut anfordert, dann geht das oftmals nur entweder für die Kontoinformation oder die Zahlungsauslösung. Um Zahlungssicherheit gewährleisten zu können, brauchen TPP aber häufig beide Funktionen in einem Zugriff mit Eingabe einer einzigen TAN. Ein kombinierter Zugriff scheint aktuell bei einigen großen deutschen Banken nicht möglich. Auf dieser Basis könnten regulierte TPP wie FinTecSystems keinen Zahlungsauslösedienst anbieten. Wichtig ist ebenfalls eine weitere direkte Folge daraus: Es scheint kein „Hartverbbuchungsmerkmal“ zu geben, so dass eine Zahlung nicht zurückgeholt werden kann. Wenn allerdings bei einer Zahlungsauslösung vorher nicht auch eine automatisierte Abfrage der Umsätze (Kontodeckung!) möglich ist, dann wird es schwierig, Zahlungssicherheit und Betrugsprävention zu gewährleisten.
4. Nicht-Zahlungsverkehrskonten
Ungelöste Frage: Konten, die keine Girokonten sind, tauchen in den PSD2-Schnittstellen nicht auf. An sich in Ordnung, da die PSD2 nur von Zahlungsverkehrskonten schreibt. Allerdings geht die strenge Auslegung der PSD2 hier an der Realität vorbei: Multibanking-Apps vereinen viele Arten von Konten, z.B. Depots, Tagesgeldkonten etc. Diese müssten dann beispielsweise über Screen Scraping abgerufen werden, um auch hier Kontoinformationsdienste anzubieten. Dazu bräuchte es dann ein zweites Mal Login + SCA, da zwei unterschiedliche „Transportwege“ angesprochen werden. Es ist unklar, ob der Zugriff auf Nicht-Zahlungsverkehrskonten über die Online-Banking Schnittstellen in Zukunft gewährleistet ist oder die Banken diesen Zugang sperren. Letzteres würde einen Großteil der bisherigen Kontoinformationsdienste unmöglich machen.
5. Daueraufträge
Ungelöste Frage: Daueraufträge tauchen entweder gar nicht auf oder es erscheinen nur Daueraufträge, die der TPP selbst angelegt hat. Nach Auffassung der Banken dürfen TPP auch nur die Daueraufträge „sehen“, die sie selbst angelegt haben. Damit wären alle Daueraufträge „Eigentum“ des Anlegenden (entweder Bank oder TPP). Ein massiver Bruch der Customer Experience: Es wird einem Nutzer, der beispielsweise seine gesamte Kontosicht in einem Personal Finance Manager-Tool angezeigt haben möchte, nur schwer zu erklären sein, warum dann beispielsweise drei von sieben Daueraufträgen nicht vorhanden sind. Damit wird ein Ziel der PSD2 klar verfehlt: Die reibungslose Nutzung von innovativen Tools für Kontoinformations- und Zahlungsauslösedienste.
Ziele der PSD2 sind gefährdet
Diese fünf Baustellen sind exemplarisch für die erste Runde der Testphase der bereitgestellten Schnittstellen. Aktuell und auch zu Beginn der zweiten Testphase („Produktivtests“) seit 14. Juni setzt sich dieses Bild leider fort. Unter diesen Vorzeichen wäre das durch die PSD2 vorgesehene „Open Banking“ Makulatur und die technologische Entwicklung zurückversetzt in längst überwunden geglaubte Zeiten.
Falls Banken bei der Performanz der Schnittstellen nicht massiv nachbessern und sich in den Dialog mit den TPP setzen, um eine für beide Seiten zufriedenstellende technologische Lösung zu finden, gefährdet das alle Ziele der PSD2: Innovationen würden abgewürgt, der Wettbewerb auf Augenhöhe zwischen Banken und TPP wäre nicht möglich und der Zahlungsverkehr würde weder einfacher, noch sicherer oder günstiger. Das würde das gesamte Ökosystem „FinTech in Europa“ gefährden, einer der wenigen Bereiche der digitalen Wirtschaft, in denen der Kontinent führend beziehungsweise in der gleichen Liga wie Asien und die USA spielt.
Letztlich sind die Bankkunden und Nutzer Digitaler Endgeräte der Treiber der Innovationen. Open Banking ist daher so etwas wie die letzte Chance für die Kreditinstitute: US-Wallet-Systeme sind Online-Marktführer und arbeiten auch Offline bereits daran, Kreditinstitute, z.B. bei der Kreditvergabe, abzulösen. Die PSD2 stellt den Nutzer und seine Bedürfnisse in den Vordergrund, denn die geistigen Mütter und Väter der Regulierung haben verstanden, dass es das “Zeitalter des Kunden” ist – Banken sollten diese Sichtweise schnell übernehmen.
Über den Autor
Stefan Krautkrämer hat mit Dirk Rudolf FinTecSystems 2014 in München gegründet. Vorher hat der studierte Wirtschaftsinformatiker im Gründerteam das Internet-Bezahlverfahren „Sofortüberweisung“ als erster Mitarbeiter mehr als sieben Jahre mit aufgebaut. Zuletzt war Stefan bis zum Verkauf an Klarna AB als COO bei der SOFORT AG tätig. Bei FinTecSystems ist Stefan für Corporate Development und Investor Relations verantwortlich.
Website: www.fintecsystems.com
Twitter: https://twitter.com/fintechq?lang=de
LinkedIn: https://www.linkedin.com/in/stefankrautkraemer/
