(English version following soon) In 6 Monaten sind PSD2 APIs Realität: Developer sind jetzt unsere Hoffnung!

sechs Monate bis RTS angewendet werden müssen

Ab heute sind es nur noch sechs (!) Monate bis zum 14. September 2019. Der Tag an dem die Regulatory Technical Standards (RTS) der europäischen Bankenaufsicht (EBA) zur Strong Customer Authentication (SCA) und zur Kommunikation zwischen Banken und Drittdienstleistern unter der PSD2 angewendet werden müssen. Ein Schwerpunkt der anhaltenden Diskussionen des Marktes bilden die bis dahin zu erwartenden PSD2 Schnittstellen. Im Februar durfte ich mit vielen Marktvertretern an einem Workshop der BaFin zum Status teilnehmen. Meine wesentliche Erkenntnis: Wir müssen die letzten offenen Punkte nun vom Konferenztisch in die Köpfe der Developer verlagern.

Was heute am 14. März 2019 passiert bzw. passieren müsste

Wenn man als Bank ab dem 14. September 2019 vom Angebot eines Fallback-Zugangs befreit sein möchte, muss gemäß der RTS-Fristen heute die Schnittstellen-Dokumentation veröffentlicht sowie die Testumgebung für Funktionstests bereitgestellt werden. Für uns als Drittdienstleister geschieht dies leider nicht nachschlagbar in einem EU-weiten EBA Register. Jede Bank wird dies auf ihre Weise – mehr oder weniger innovativ  – auf ihrer Webseite tun. Erste Schnittstellen sind seit Anfang 2019 live und wir wurden bereits um entsprechendes Testing gebeten. Die Masse wird nun folgen.

Reden hilft, aber nur Handeln wird uns erlösen

Der Austausch zwischen Banken und Drittdienstleistern ist historisch bedingt immer noch schwierig. Augenscheinlich hat sich der Markt durchmischt. Seit 2016 bieten nach und nach auch Banken Zahlungsauslöse- und Kontoinformationsdienste (ZAD/KID) an. Sie greifen dabei sogar auf die technische Kompetenz der klassischen Drittdienstleister zurück. Ende 2018 öffnete sich dann auch die paneuropäische Marktstandard-Initiative NextGenPSD2 (Berlin Group) für die breite Kompetenz der Drittdienstleister. Im Advisory Board der Initiative ist seither auch figo aktiv.

Leider wird heute allerdings keine offizielle Referenzimplementierung zu NextGenPSD2 veröffentlicht, die es ermöglicht hätte, generelle Funktionstests zu zentralisieren. Beim erwähnten BaFin Workshop stellte die Initiative die erfolgreiche Reichweite ihres API-Standard vor. Die deutschen Marktführer-Banken berichteten entsprechend dem Standard zu folgen, aber gleichzeitig teilten sie auch den Umsetzungsstand ihrer individuellen Sandboxes, Test- und Go-Live-Pläne. Unterstützen soll in der somit diversen API Testing-Welt das Framework eines Nebenarms der NextGenPSD2 Initiative, mit dem Integrationstests vereinheitlicht bzw. automatisiert möglich sein sollen.

Die echten Drittdienstleister werden hinsichtlich der Tests sehr zielorientiert vorgehen und Doppelaufwände vermeiden, wenn Sandboxes eher als Feigenblatt-Compliance angeboten werden und mit den echten Schnittstellen noch wenig zu tun haben. Ab dem 14. Juni 2019 sind Letztere für die Go-Live bzw. zunächst dreimonatige Marktbewährungsphase zu erwarten. Banken wiederum müssen für eine Befreiung vom Fallback nachweisen, dass ihre Schnittstelle zur Zufriedenheit der Drittdienstleister getestet wurde.

Bei der BaFin war ich eingeladen, um darzustellen, wie figo als Drittdienstleister die Umstellungsphase beurteilt. Aus Erfahrung wissen wir, welchen Unterschied es macht, eine gute oder schlechte Dritt-API anzubinden, was es bedeutet, eine Datenintegration fortlaufend zu betreiben und für unsere Partner nutzbar zu machen – und nicht zuletzt auch, wie unsere eigene Verfügbarkeit und Performance durch die falsche Nutzung unserer API beeinflusst wird. Als erster regulierter ZAD/KID-Anbieter in Deutschland ist uns darüber hinaus bewusst, was es heisst, IT-Systeme BaFin-konform zu betreiben.  

Wie wichtig der Austausch zwischen Banken und Drittdienstleistern wie uns ist, drängt sich also automatisch auf. Und die Unsicherheit, die uns alle mit Blick auf das nächste halbe Jahr umtreibt, sollte zusätzlich verbindend wirken. Banken sorgen sich, die Anforderungen zum API-Angebot inhaltlich und fristgerecht einhalten zu können, während Drittdienstleister die Qualität und vor allem auch Inkonsistenzen der zwingend zu nutzenden APIs fürchten.

Die nächsten Monate werden – sogar unter idealsten Bedingungen – komplex

Inkonsistente APIs bzw. deren Individualbetrieb bedeuten unnötige Mehraufwände für uns alle – für Banken, Drittdienstleister und die BaFin, die deren PSD2-Compliance beurteilen soll. Angemessen auf die PSD2 vorbereitete IT-Budgets und Ressourcen der EBA hätten dem Markt aktuelle und künftige Schmerzen ersparen können. In Hinblick auf Supervisory Tech müssen wir in Europa dringend aufholen, z.B. durch eine beim Regulator angesiedelte zentralisierte Datensammlung für das Stress-Testing und Monitoring der PSD2 APIs.  

Warum ist es nun auch den Standard-Initiativen trotz aller Bemühungen nicht gelungen, unsere Sorgen über Inkonsistenzen im Aufbau der APIs zu verhindern? War nicht genau das deren erklärtes Ziel? Nun, zunächst weil es allein mindestens sechs Initiativen in Europa gibt. Und wenn der paneuropäische NextGenPSD2 nun wiederum mit guter Intention verspricht, anderen nationalen Standards nicht zu widersprechen, kannibalisiert er leider gleichzeitig sein Ziel.

Denn im Ergebnis besteht für Drittdienstleister weiterhin eine immense Komplexität, selbst wenn alle EU-Banken dem freiwilligen NextGenPSD2 entsprechen würden. Beschäftigt man sich mit der NextGenPSD2-Spezifikation, konkretisiert sich, dass künftig viele optionale Spezifika per Bank-Schnittstelle gemanagt werden müssen. Denn jede einzelne Bank entscheidet zwischen:

  • sechs möglichen SCA-Verfahren (Embedded, Redirect, Decoupled, Mischformen)
  • drei Arten des Consent-Management (global, bank offered, detailed)
  • Bank- bzw. Nutzer-individuellen 2. Faktoren (mTAN, Flicker Tan, QRCode, etc.)
  • risikobasierten Umfängen der 2-Faktor-Ausnahmen.

Die Umsetzung auf Einzelbank-Ebene wirkt sich dabei nicht nur immens auf die Backends der Drittdienstleister aus, sondern vor allem auch auf die Frontends der künftigen Zahlungsdienst-Angebote. Jede mögliche SCA Sonderlocke muss durch verschiedene User Flows abgedeckt werden. Schließlich kommt die Komplexität also auch beim Nutzer an. Wenn man dies nur für Multibanking-Lösungen zu Ende denkt, könnten die beschriebenen Inkonsistenzen den künftigen Erfolg dieses Features extrem gefährden. Dies dürfte auch den Digital-Abteilungen der Banken, die ZAD/KID Features betreiben gerade nach und nach bewusst werden.

Und bei all diesen Hürden bewegen wir uns immer noch in einer Traumwelt, weil ich bisher nur die neue Open Banking Zukunft der Zahlungskonten beleuchtet habe. Viele, auch etablierte Bankprodukte, hängen aber zusätzlich vom Zugriff auf Depots, Kreditkarten- oder Sparkonten ab. Durch die PSD2 Umstellungen werden für diese ab September Einschränkungen im Zugriff befürchtet. In Bonn schlossen die Vertreter der Deutschen Kreditwirtschaft dies für registrierte Webdienste zumindest in Hinblick auf HBCI/FinTS aus.

Der HBCI-Zugang bietet heute allerdings auch Zahlungskonten-Funktionen (AZV, Lastschriften, Sammelüberweisung), die nicht zwingend im Online-Banking enthalten sind und somit institutsindividuell ab September tatsächlich wegfallen könnten. Hier heißt es nun also für Drittdienstleister zu vertrauen. Der zwischenzeitlich durch eigene Produkte geschärfte Marktblick der Banken führt hoffentlich zu dahingehend konzeptionierten PSD2 Schnittstellen.

Werden uns Aufsichtsbehörden helfen?

Parallel zur Test- und Go-Live- Phase werden last minute Klarstellungen zu den RTS durch die EBA erwartet, sei es durch die EBA Working Group oder die EBA Q&A. Das Handeln der EBA wirkt dabei leider manchmal zu sehr vom europäischen Markt entfernt. Der UK OpenBanking Standard hat derweil trotz BREXIT und eigenem Markt-Misserfolg noch großen Einfluss auf die Behörde. UK Vertreter umfassen z.B. ein Sechstel der EBA Working Group. Ob dies zu Entscheidungen führt, die den EU Digital Single Market stärken, möge die Zeit beweisen.

Die BaFin hingegen versucht mit ihren Mitteln und in den engen nationalen PSD2 Grenzen den Markt bestmöglich zu unterstützen. Die Phase der API Compliance-Checks wird zeigen, ob die deutsche Behörde die Herausforderungen stemmen kann.Nur ein Beispiel: Sie wird beim Mandatory Redirect im SCA Verfahren bis auf die Ebene der Front-end Texte der Bank prüfen müssen, ob Drittdienstleister benachteiligt werden.

Möge die Macht mit der wachsenden PSD2 Developer Community sein

Statt auf Hilfe der EBA und BaFin allein zu hoffen, sollten wir aber endlich die wichtigsten Menschen in diesem Markt direkt miteinander verbinden. Insbesondere unsere Product Owner und Developer müssen Open Banking Produkte vom Backend bis zum Nutzer-Frontend PSD2-konform umsetzen und innovativ weiterentwickeln können. Ein direkter Austausch in den GitHub/Gitlab- und Slack-Channeln zwischen dem Developer, der eine spezifische Bank API betreut und dem Drittdienstleister-Developer, wäre ein dringend notwendiger Durchbruch für den EU Open Banking Markt.

Bei meiner täglichen Arbeit mit schlauen Köpfen habe ich es häufig erlebt, dass wir Konferenztischtheoretiker in der RTS- und Nutzer-Theorie viel zu oft noch über Probleme streiten, während der Dev oder das DevOps Team längst eine smarte technische Kompromiss-Lösung für uns parat hat. Wichtig dabei ist allerdings auch: Ein Austausch aus Bankmarktsicht darf sich nicht darauf beschränken, dass die technische Lösung von politischen PSD2 Krücken an den API- oder Frontend-Dienstleister ausgelagert werden.

Wenn in den kommenden Monaten PSD2 API Auftritte der Banken entsprechend Product Owner- und Developer-freundlich ausgestaltet sein werden, inkl. üblicher Dev Tool-Angebote und einer sichtbaren Erreichbarkeit der API Entwickler, hätten wir den ersten wichtigen Schritt getan. Von paneuropäischen Open Banking Dev Conventions als Weiterentwicklung des Bankathon träum ich derweil weiter. Wir denken schließlich groß.