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.
- Klingt super, der Teufel steckt aber im Detail. Nahezu jede Berlin-Group-Implementierung bei einer Bank ist individuell.
- 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.
Lasst uns sehen was in den kommenden Wochen und Monaten noch im Sinne der Kunden passiert. Mittel- bis langfristig ich bin zutiefst überzeugt, dass der Weg von Open-Banking nicht aufzuhalten sein wird, auch wenn der eine oder andere Use-Case eine kurzfristige Delle erleben wird.
„Der Weg des Open-Banking wird nicht aufzuhalten sein.“
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.
4 Kommentare
Schau mal hier
https://paymentandbanking.com/psd2-fakten/
Es geht um Software die lokal installiert ist und in der der Client / die lokale Software direkt mit der bank ohne einen Server kommuniziert.
Versteht kein Mensch wirklich der kein Techiker ist, aber ist ein bisschen eine Lex Bestandslosungen wie starmoney etc
Hallo André – sehr interessanter Artikel. Mittlerweile ist es September und in der Tat machen Multibanking-Apps wie Numbrs (aber auch die bankeigenen Apps) jetzt wirklich keinen Spaß mehr. In der derzeitigen Umsetzung ist die Regelung für den Kunden ein echter Rückschritt. Meiner Meinung nach sind zusätzliche Sicherheitsmechanismen ohnehin wenig sinnvoll, solange wie die Banktransaktion und ihre Autorisierung auf dem selben Gerät ablaufen – da hätte man sich den zweiten Schritt genau genommen auch sparen können. Aber bei Kundenbeschwerden werden sich die Banken nun alle darauf zurückziehen, dass es ja eine gesetzliche Regelung der bösen Bürokraten in Brüssel ist und sich weiter ganz bequem keine Gedanken um eine bessere Nutzererfahrung machen… Traurig.
Was hat sich eigentlich jetzt wirklich geändert? Ich habe Konten bei einer Sparkasse und einer Volksbank und nutze sowohl das Internetbanking, deren Apps und auch eine Finanzsoftware (FINTS).
Im Internetbanking muss ich nur dann eine TAN eingeben, wenn ich Umsätze haben will die älter als 90 Tage sind. Dafür habe ich aber eigentlich ja aber auch meine Finanzsoftware. In der App und in der Finanzsoftware werde ich künftig alle 90 Tage einmal eine zusätzliche TAN benötigen. Das waren die Unterschiede zum bisherigen Stand.
Hallo Andre,
sehr aufschlussreicher Artikel. Vielen Dank dafür.
Eine Frage: Du schreibst im letzten Absatz „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“. Was ist mit Offline FAT Clients gemeint? Wer fällt darunter? Antwort gerne auch per Verweis auf einen Link zum nachlesen.
Danke und vG
Leo