Ist der Anfang von Open-Banking das Ende von Multibanking wie wir es in Deutschland kennen?

Ja, wir leben in Deutschland seit den Anfängen des Internets wohl in einer nahezu perfekten Welt des Open-Banking. Und wie im Zahlungsverkehr schon mehrfach erlebt, kommen durch europäische Regelungen neue Zeiten auf uns zu. In Sachen Open-Banking sind wir sowas wie der perfekte Nukleus – aber aus deutschen 100% auf der einen und 0% bei vielen europäischen Partnern, werden oft 50%. Und diese 50% fühlen sich im Vergleich zu vorher nun mal anders an.

Die europäische Open-Banking-Entwicklung und -Harmonisierung hat viele Vorteile und führt mittelfristig zu:

• mehr Sicherheit und Klarheit für alle Marktteilnehmer
• in der Folge hoffentlich zu mehr Vertrauen bei Usern
• zu neuen Schnittstellen und Standards
• und damit zu einer höheren Verlässlichkeit in Summe

Vorne dran statt nur dabei

Wie erwähnt kommen wir in Deutsch-land aber eben aus der (fast perfekten) Open-Banking-Welt – entstanden aus BTX und HBCI. Zur Erinnerung: Online-Banking war einer der Gründe für den Weg ins Internet bei vielen Deutschen. AOL und T-Online sei Dank. Verbunden war diese sehr technisch getriebene Offenheit der Banken mit einer großen gelebten Realität in, zugegeben, rechtlichen Grauzonen.

An die Lösungen, die in diesen Grauzonen über die Jahre entstanden, haben sich viele Kunden gewöhnt und auf Basis derer sind eine Reihe Unter-nehmen und Geschäftsmodelle entstanden, wie sie einmalig in Europa waren und sind. Damit war Deutschland eigentlich „vorne dran“, statt „nur dabei“.

Diese Historie hat zur Folge, dass wir die neue, heranziehende Welt mit dem IST vergleichen können. Wir haben bereits Anfang April (https://paymentandbanking.com/banken-und-apis-eine-neue-liebe/) und auch in einem Podcast (https://paymentandbanking.com/status-der-psd2-rts/) schon einmal einen Spot darauf geworfen und wollen es hier noch einmal tun, da sich gerade mehr Tatsachen herauskristallisieren und die möglichen Folgen für den Markt klarer werden.

PSD2, API, SCA

Dabei sind es verschiedene Themen, auf die ich gern jeweils kurz schauen und die möglichen Folgen klar machen möchte:

• neue Standards für PSD2 APIs wie die Berlin Group
  • Klingt super, der Teufel steckt aber im Detail. Nahezu jede Berlin-Group-Implementierung bei einer Bank ist individuell.
    • Geheilt hätte dies werden können, in dem von Anfang an eine „discovery API“ verpflichtend spezifiziert worden wäre, über die TPPs in der Lage sind, den bei der Bank umgesetzten Standard zu erkennen und dynamisch darauf zu reagieren.
  • Die aktuellen Sandbox-Umgebungen (seit 14.3) sind – Stand heute – zudem nur bedingt für die Integration nutzbar.
    • Daher werden die drei Monate zwischen Juni (Marktbewährungsphase) und September (go live) ein ziemlicher Wahnsinn für viele Marktteilnehmer sein.

• SCA – Strong Customer Authentication
  • Diese drei Buchstaben klingen so harmlos, sind aber wohl eine der größten Herausforderungen im Vergleich zum IST-Zustand.
  • Bisher konnten in sogenannten On-Going-Use-Cases die Zugangsdaten zum Konto gespeichert werden und damit ein automatischer Kontoabgleich erfolgen.
  • Die PSD2 fordert nun auch für den Kontozugriff einen sogenannten SCA – dies kann eine TAN, ein Finger-Print etc. sein. Bisher gingen viele im Markt davon aus, dass dieser SCA für den Kontozugang vom Kunden auf Wunsch nur alle 90 Tage erneuert werden muss und dann im Auftrag des Kunden im Anschluss 90 Tage automatisch auf das Konto zugegriffen werden kann. Diese mögliche Ausnahme vom SCA, die in der PSD2 explizit als Lösung vorgesehen ist, wird aber aktuell wohl von keiner relevanten Bank unterstützt.
  • Dies hat zur Folge, dass bei Konto- oder Umsatzabfragen eines jeden Kontos – neben der PIN – der jeweilige passende zweite Faktor eingegeben werden muss. Egal ob in der Banking-App oder in der Buchhaltungssoftware.
  • Ein Beispiel gefällig:
    • In der Buchhaltungssoftware eines kleinen Betriebs sind die zwei Geschäftskonten hinterlegt. Bisher konnte der Buchhalter die Umsätze der Konten einfach einsehen, da die Software diese automatisch zweimal aktualisiert.
    • In der neuen Welt muss der Umsatzabruf vom Chef freigegeben werden
      • für Konto 1 mit einer Photo-TAN
      • für Konto 2 mit einer Mobile-TAN

Redirect-Flows

• Redirect- Flows
  • Neben den Banken-APIs hat die PSD2 mindestens noch eine weitere Folge: Sogenannte Dritte (TPPs) müssen sich bei ihrer nationalen Finanzaufsicht beaufsichtigen lassen und initial eine Registrierung bzw. einen Lizenzantrag stellen.
  • Diese “Lizenz” ist mit einer Menge initialem und dauerhaftem Aufwand versehen. Einer der Gründe ist, dass TPPs in der PSD2-Welt mit den sensiblen Zugangsdaten der Bank-Kunden arbeiten dürfen und müssen.
  • Dieser Punkt wird aber in vielen Use-Cases gar nicht einschlägig, da Banken im Rahmen ihrer APIs vorgeben können, wie TPPs auf die Bank zugreifen. Eine Möglichkeit ist der sogenannte Redirect Flow – in diesen Fällen sucht der Nutzer beim TPP seine Bank aus und wird dann – ähnlich wie bei PayPal – auf Seiten der Bank geleitet und gibt dort die sensiblen Daten ein.
  • Grundsätzlich keine schlechte Idee im Sinne des Vertrauens, allerdings wird es eine Reihe an bestehenden TPP-Use-Cases vor echte UX-Herausforderungen stellen, wenn die eigenen User-Flows unterbrochen werden von “Umwegen” zur Bank. Vor allem mobile Apps dürften hier Probleme bekommen. Eine Erinnerung an 3D-Secure wird wach, da der Anbieter des Redirect Flows keinen echten Anspruch an einer guten Lösung hat.

Kleinere Datentiefe, kleinere Breite

• IBAN Eingabe
  • In der Zukunft werden einzelne Institute bei der Kontoeinrichtung neben den bekannten Online-Banking-Zugangsdaten ergänzend vom Kunden seine IBAN abfragen.
  • Hintergrund ist, dass bislang häufig mehr als ein Konto “hinter” einem Online-Zugang liegt. In der Zukunft soll so sichergestellt werden, dass wirklich nur das eine Konto übermittelt wird.
• Datentiefe, Breite, 90 Tage, Namen
  • Die IBAN-Eingabe macht es schon klar: Die Datentiefe und Breite ist in der PSD2 Welt gegenüber dem IST deutlich kleiner. Über die neuen APIs werden nur noch Zahlungskonten (also vor allem Girokonten) bereitgestellt und zudem ist die Historie der Daten auf 90 Tage beschränkt. Der heute nicht unübliche Zugriff auf das Gesamtengagement des letzten Jahres wird so einfach nicht mehr möglich sein.
  • Auch das heute oft genutzte Datenfeld “Name des Kontoinhabers” ist in der neuen Welt keine automatische Pflicht mehr, sondern nach EBA Guidelines ein Use-Case abhängiges Feld. Dies führt aktuell zu einer Menge Diskussionen. (Update)

In Summe also eine Menge an Veränderungen, vor allem für bestehende und etablierte Lösungen.

Man kann hier wohl keinem einen Vorwurf machen, sollte sich aber auch über die Folgen bewusst sein. Klar ist:

• Im Gesetz ist nahezu alles geregelt und es wären schon heute smarte Lösungen möglich.
• Banken versuchen die PSD-Ressourcen schonend und gleichzeitig konsistent in allen “Kanälen” umzusetzen.
• Dass die Veränderung des IST und für eine Menge Kunden zu weniger smarten Lösungen führt, wird aber erst einmal die Folge sein.

Ausgenommen: einige Bestandsprodukte

Man kann die Hoffnung haben, dass sich im Laufe der Zeit noch Änderungen auf allen Seiten im Sinne des Kunden ergeben. So sehe ich unter anderem eine große Chance für neutrale SCA-Anbieter, auf die sich alle Banken einigen können (Verimi etc.) und so ein harmonischer Zugriff auf verschiedene Konten möglich sein kann.

P.S.:

Fast schon absurd wird es allerdings, wenn man sich anschaut wie ein kleiner Teil von Bestandsprodukten von den tiefgreifenden Veränderungen verschont werden soll. Sogenannte Offline- oder FAT-Clients sollen nicht Teil der PSD2-Regulierung sein und stehen daher weder unter der Aufsicht der Behörden, noch können sie auf die PSD2-APIs zugreifen. Als Folge wird diesen Lösungen wohl auch weiter der bewährte Weg via HBCI / FinTS möglich sein (so Banken diesen Weg nicht schließen), den die PSD2-regulierten Anbieter allerdings nicht mehr wählen können. Ob ein normaler User diesen Unterschied verstehen wird, bezweifle ich sehr. Folge kann sein, dass die eine Banking-App eine PSD2-Lizenz braucht (Online-Serverkomponenten im Einsatz), während andere Apps diese Lizenz nicht brauchen. In Summe wird es auf jeden Fall so sein, dass die bankeigenen Apps gestärkt werden und der Anspruch den Markt zu fördern, eher zum Gegenteil führt.