Erwartung trifft auf Realität: PSD2 Schnittstellen sind weiterhin nicht marktreif

PSD2/XS2A – schon alles gut? Offenbar nicht. Es gibt Baustellen. Banking API-Anbieter FinTecSystems führt Schnittstellen-Tests durch. IT Finanzmagazin hat das Labor nördlich von Frankfurt (Linden) besucht und gebeten, den aktuellen Status zu ermitteln. Nüchtern zusammengefasst: Es hakt. Zum Teil ganz fürchterlich – und das trotz Marktbewährungsphase …

von Hannes Rogall, Chief Operating Officer, FinTecSystems

Noch vor zwei oder drei Jahren waren einige Marktteilnehmer ganz euphorisch, was die Ergebnisse und die technischen Umsetzungen der PSD2-Regulierung angingen: Schnittstellen machen Bankdaten für Dritte zugänglich und es sollte klare Regeln geben, was diese Schnittstellen leisten müssen. Als regulierter Drittanbieter (TPP im Sinne der PSD2) haben wir nun festgestellt, dass noch viel Energie aufgebracht werden muss auf dem Weg zu funktionierenden PSD2-Schnittstellen.

Aktuell ist es de facto unmöglich, an stabile und funktionsfähige PSD2-Schnittstellen zu gelangen. Derzeit wird bei FinTecSystems kein einziger Online-Kredit über eine PSD2-Schnittstelle zur Entscheidung gebracht, es ist schlicht nicht möglich. Daher kann es aktuell keine Ausnahmegenehmigung vom „Fallback“ geben.

Baustelle Datenparität – PSD2-Schnittstellen müssen Informationsgehalt aus dem Onlinebanking stellen

Fakt ist, dass die PSD2-Regulierung beziehungsweise die EBA RTS den kontoführenden Instituten vorschreiben, dass das Onlinebanking den Informations- und Funktionsumfang der jeweiligen PSD2-Schnittstelle vorgibt. Wir nennen das Datenparität. Die PSD2 ist in ihrer Grundüberlegung in diesem Punkt bestechend klar: Warum sollte eine Bank mit einer neuen Schnittstelle die eigenen Kunden schlechter stellen, als diese es aus dem bewährten Onlinebanking kennen? Status quo nach vielen Tests ist allerdings: Vorgemerkte Umsätze, Disporahmen oder Umsatz-Zeiträume werden über die PSD2-Schnittstelle nicht übertragen. Damit liefern die Banken-Schnittstellen eben nicht dieselben Daten aus dem Onlinebanking. Doch eine professionelle Online-Kreditentscheidung ist ohne Berücksichtigung des Disporahmens oder des tatsächlichen Kontostands (abzüglich der vorgemerkten Umsätze) einfach nicht möglich. Diese Haltung können wir nicht nachvollziehen und widerspricht definitiv der PSD2 und den EBA RTS. Unter Artikel 36 der RTS heißt es unmissverständlich:

(1) Die kontoführenden Zahlungsdienstleister halten jede der folgenden Anforderungen ein: a) Sie stellen den Kontoinformationsdienstleistern dieselben Informationen von bezeichneten Zahlungskonten und damit in Zusammenhang stehenden Zahlungsvorgängen bereit, die auch dem Zahlungsdienstnutzer bereitgestellt werden, wenn er den Zugang zu Kontoinformationen direkt anfordert, sofern diese Informationen keine sensiblen Zahlungsdaten enthalten.”

Solange die Datenparität nicht gewährleistet ist, werden der Zugang über die Verbraucher-Schnittstellen (HBCI, FinTS und das Online-Banking) die einzigen EBA RTS-konformen Methoden sein, die die PSD2-Anforderungen wirklich erfüllen. Wir betonen, dass wir als TPP natürlich ein Interesse haben, dass die Banken-Schnittstellen dieselbe Performance liefern wie die Verbraucher-Schnittstellen, doch wir kämpfen aktuell wirklich um jede Information.

Status Quo nach umfangreichen Tests: Bislang bietet keine einzige Schnittstelle der Banken die vollständige Datenparität.”

Baustelle SCA: Multi User Consent – Von der Berlin Group (bewusst) nicht berücksichtigt

Endkunden können über PSD2-Schnittstellen nur eine Personal Finance Management-App nutzen, in der sie ihre Konten einbinden, um Umsätze zu sehen, Umbuchen vorzunehmen und sich Kontostände anzeigen zu lassen. Probleme gibt es, wenn sie ihr Konto beziehungsweise ihre Konten dann bei einem weiteren Dienst eingeben, zum Beispiel einem Online-Buchhaltungsportal oder einem digitalen Kontowechselservice. In diesem Fall dann überschreibt jeder weitere Dienst die jeweils anderen Zugriffsberechtigungen („Consent“) über die Zweifaktor-Authentifizierung (2FA). Das Multi User Consent Management-Problem wurde bisher kaum thematisiert und es mutet an, als wäre es bewusst herbeigeführt worden. Was bedeutet das Mulit User Consent Management-Problem genau?

FinTecSystems arbeitet als ein “super-TPP”, ein Hub für diverse Kreditinstitute oder TPP, die ihrerseits Kontoinformationen beziehungsweise Zahlungsauslösung PSD2-konform durchführen möchten. Dabei ist es entscheidend, dass wir für jeden unserer angeschlossenen TPP das Consent Management getrennt steuern. Aktuell stoßen wir bei mehreren Berlin-Group-Schnittstellen auf folgendes Hindernis:

1. Wir legen einen recurring consent für den Kontoinhaber (Endkunde / PSU) beim Anbieter A (Bank oder Banking-App) an.
2. Wir legen einen neuen recurring consent für denselben Kontoinhaber beim Anbieter B an.
3. Beim automatisierten Zugriff auf den Abruf der Kontoinformationen an Anbieter A erfolgt die Fehlermeldung: “consent revoked by tpp”.

Offensichtlich wird mit dem zweiten erstellten Consent für Anbieter B der erste Consent für Anbieter A überschrieben, damit wird der erste Consent unwirksam. Hinzu kommt: Setzen wir den “recurringIndicator” auf false, erhalten wir nur eine einzige Abfrage, aber keine komplette Kontoabfrage (Account Information Service / AIS). Die Schnittstellen liefern uns nur Fragmente in diesem Fall zurück. Eine absolut unerklärliche Reaktion.

Im Dokument “NextGenPSD2 XS2A Interoperability Framework – Implementation Guidelines” in chapter 6.4.1.1 (p. 120 – https://www.berlin-group.org/nextgenpsd2-downloads) beschreibt die BerlinGroup explizit dieses Verhalten:

Side Effects

When this Consent Request is a request where the “recurringIndicator” equals true, and if it exists already a former consent for recurring access on account information for the addressed PSU and potentially addressed corporate identification submitted by this TPP, then the former consent automatically expires as soon as the new consent request is authorised by the PSU. There are no expiration side effects foreseen for Consent Requests where the”recurringIndicator” equals false.”

Selbstverständlich ist dieses Vorgehen ein Desaster in der Nutzerführung und der Customer Journey, kein Anwender würde es verstehen, die Leidtragenden sind die App-Anbieter. Den Anbietern wird die schlechte User Experience im Regelfall zuerst angelastet.

Schon jetzt sind die Kommentare und Bewertungen der Multibanking-Apps seit dem 14. September 2019 mehrheitlich negativ.”

Hinzu kommt aber auch noch der Fakt, dass wir dieses Vorgehen definitiv als „Hindernis“ ansehen, und auch hier haben die PSD2 und die EBA RTS eine klare Meinung: TPP dürfen durch die Banken-Schnittstellen nicht diskriminiert werden. Status Quo nach umfangreichen Tests: Aktuell bietet keine Banken-Schnittstelle hindernisfreie Banken-Schnittstellen an.

Fazit: Es kommt Bewegung in einen Markt, der schon lange nicht mehr angebotsinduziert tickt

Marktabschottende Verhaltensweisen waren der Grund, warum es überhaupt zur PSD2-Regulierung gekommen ist. Jetzt gilt es, die Grundideen der PSD2 konzentriert umzusetzen: Wettbewerbsgleichheit für alle Marktteilnehmer und den mündigen Bürger stärken, der im digitalen Zeitalter selbst über die Verwendung seiner Bankdaten entscheiden kann.

Im Falle der PSD2-Schnittstellen steht die Branche erst am Anfang der Umsetzung.”

Wir als TPP testen seit Monaten intensiv die angebotenen Schnittstellen, stehen im permanenten Austausch mit den Banken und vergleichen seit Wochen die Daten, die wir beispielsweise über FinTS oder das Online-Banking erhalten, mit den Daten, die wir über die PSD2-Schnittstellen geliefert bekommen. Es fehlen bei den PSD2-Schnittstellen nach wie vor elementare Informationen, von einer Datenparität sind wir weit entfernt.

Das betrifft leider auch die Schnittstellen der Sparkassen (Finanz Informatik/FI) und der Volks- und Raiffeisenbanken (Fiducia), die die BaFin, im Falle der FI-Schnittstelle, Anfang Januar auf ihrer Website veröffentlicht hat.”

Unserer Meinung nach ist auch diese Schnittstelle nicht in der Marktbewährungsphase, da diese nicht PSD2-konform ist (fehlende Datenparität). Daher darf aus unserer Sicht auch keine Ausnahmegenehmigung erteilt werden. Denn diese Phase beginnt laut EBA RTS erst nach einer Testphase, wenn sich reife Schnittstellen ohne ständige Updates über Monate am Markt bewähren können.Hannes Rogall, Chief Operating Officer, FinTecSystems