Ich schätze Klaus Igel als HBCI/FinTS- und PSD2-Experten sehr, auch weil wir in der Regel einer Meinung sind. Was nicht überrascht, denn unsere Ausgangsinteressen sind ähnlich. Nachdem ich am Pflingstwochenende seinen Finanz-Szene Beitrag zur ING Deutschland las, musste ich ihm allerdings widersprechen. Während Klaus in seinem Beitrag aus technischer Sicht zu dem Schluss kam, dass das, was die deutsche ING in Bezug auf die PSD2-Schnittstelle umsetzt, dem Geist der PSD2 widerspricht, ist die Bank in meiner Wahrnehmung eine der wenigen in Deutschland, die versucht (!) die PSD2 fair, in die Zukunft, über den deutschen Tellerrand hinaus und entwicklerfreundlich zu denken. Was ich damit meine:
Fairness: Die ING schafft ein Level Playing Field, das der Gesetzgeber dem deutschen Markt bis heute schuldet
Gibt es denn tatsächlich einen validen Grund, PSD2-Drittdienstleister und HBCI/FinTS-Dienstleister unterschiedlich zu behandeln? Beide greifen auf Zahlungskonten ihrer Nutzer zu. Während der PSD2-Drittdienstleister sein Anwendungsprogramm (z.B. Buchhaltungs- und Steuer-Tool) über ein Web-Frontend mit Nutzer-Login betreibt und dafür die Zugangs- und Zahlungskonto-Daten des Nutzers auch über eigene Server cached oder speichert, um mit der Bank zu kommunizieren, bietet der FinTS-Dienstleister sein Buchhaltungsprogramm zum Download via App bzw. zur lokalen Installation beim Nutzer an. Im zweiten Fall kommuniziert der Nutzer bzw. seine App ohne dazwischen geschaltete PSD2-Dienstleister-Server direkt mit seiner Bank. Dieser feine Unterschied, also online/ Drittdiensleister-Server vs. App/ lokaler Speicher des Nutzers, begründet heute durch die gesetzliche Grundlagen eine immense Ungleichbehandlung für Dienstleister (Regulierung vs. fehlende Regulierung). Ist das gerechtfertigt?
Die Sicherheit des Web-Frontends und der technischen Kommunikation des regulierten PSD2-Drittdienstleisters kontrollieren EBA, BaFin und Bundesbank. Wer kontrolliert die Sicherheit und Kommunikationswege der lokalen App? Was kann, darf, cached die App? Welche Daten dürfen wie an den FinTS-Dienstleister im Hintergrund weitergeleitet werden? Genügt dem Verbraucherschutz hier das Sicherheitsniveau für sensible Zahlungsdaten – gewährleistet durch den Nutzer, der alle Updates pünktlich installiert und durch die Datenschutz-Einstellungen von Windows, Android oder iOS?
Warum sollte ein Drittanbieter, der für den Weg des geringsten Widerstandes die Gesetzeslücke sucht, das fehlende Level Playing Field nicht ausnutzen? Warum nicht über lokale Apps den klassischen FinTS-Dienstleister-Weg wählen, statt den Aufwand einer BaFin-Regulierung in Kauf zu nehmen? Lassen sich denn Zugangs- und/ oder Transaktionsdaten über das Kleingedruckte nicht im Graubereich dennoch irgendwie beschaffen? Wie werden diese grauen Schafe identifiziert?
Die ING trägt dem Geist der PSD2, d.h. der Datensicherheit und dem Verbraucherschutz sowie der dafür notwendigen Regulierung des Drittdienstleisters, Rechnung, indem sie hier gerade keinen Unterschied mehr für Zahlungskontenzugriffe macht. Sie schafft damit ein transparentes Level Playing Field und lässt keine deutsche HBCI/FinTS-Ausnahme für Zahlungskonten zu.
Zukunftsorientierte Investition in ein entwicklerfreundliches API Angebot statt in die Vergangenheit
Aus Sicht der deutschen Banken ist die Anpassung ihrer HBCI/FinTS-Schnittstelle an PSD2-Vorgaben ein Doppelaufwand zum PSD2-Schnittstellen-Angebot. Wenn die Bank den FinTS-Weg nicht selbst für haus- bzw. konzerneigene App-Angebote nutzt, erklärt sich auch wirtschaftlich nicht, warum Banken mittel- bis langfristig doppelte Kosten für die Zahlungskonten-Bereitstellung via HBCI/FinTS und der PSD2-Schnittstelle in Kauf nehmen sollten. Die Ressourcen sind in der weiteren Verbesserung der PSD2- und Premium-Schnittstellen besser und vor allem in die Zukunft investiert.
Wer nicht glauben mag, dass HBCI/FinTS die Vergangenheit und APIs die Zukunft sind, dem rate ich zu zwei simplen Clicks: Nr. 1 in den nur auf deutsch verfügbaren Web-Auftritt des FinTS-Standards
und Nr. 2 in den EU-weiten und entwicklerfreundlichen ING API Marketplace.
HBCI/FinTS war zu seiner Zeit der notwendige Standard, ohne den wir in Deutschland vielleicht auch keine Vorreiter in Sachen Open Banking geworden wären. Mittel- bis langfristig sind europäisch geprägte PSD2- und Premium-APIs (also über das kostenlose Pflichtangebot hinaus) aber der einzige Weg.
Dies gilt auch mit Blick auf die Transparenz und Verbindlichkeit eines bilateralen Premiumangebots. Um über September hinaus einen FinTS-Zugang zu erhalten, ist es – für PSD2-Drittdienstleister (insb. für Zugriffe auf Nicht-Zahlungskonten) wie FinTS-Dienstleister – notwendig, sein Produkt zu registrieren. Wer darüber entscheidet, ob, wie lange und worauf genau welcher Antragsteller fortan Zugriff erhält, bleibt für diese allerdings intransparent.
Die ING denkt über den deutschen HBCI/FinTS-Tellerrand hinaus
Sich als europäisch geprägte Bank nicht weiter einem traditionellen deutschen HBCI/FinTS-Standard zu unterwerfen, während mit der PSD2 und den RTS ein neuer EU-weiter Standard entsteht, dürfte wenig überraschen. Zwar könnte nun wiederum der europaweite Ansatz einer ING hinterfragt werden, weil sie sich nicht einem PSD2-Marktstandard für Schnittstellenspezifikationen wie dem der Berlin Group unterworfen hat. Aber offen gesagt ist ein Angebot in Anlehnung an internationale Autorisierungsstandards wie OAuth2, das gleichzeitig durch Entwicklerfreundlichkeit glänzt, kein Integrationsmehraufwand im Vergleich zur Anbindung einer der diversen Berlin Group Standard-Ausprägungen.
Das mag verrückt klingen, aber wenn jede einzelne Berlin Group-konforme Bank zwischen sechs möglichen Authentifikationsverfahren, drei Arten des Consent-Management, Bank- bzw. Nutzer-individuellen Zwei-Faktor-Arten und risikobasierten Umfängen der Zwei-Faktor-Ausnahmen entscheidet, bleibt der Standard für Drittdienstleister im Ergebnis ein kaum aufwandschonendes “Minimalstminimum”.
Letztlich erweist es sich aus Drittdienstleistersicht für das Geschäftsmodell dann teilweise sogar als Vorteil, dass die ING-Schnittstelle keinem Berlin Group Standard unterliegt. Der API-Funktionsumfang kann durch die ING flexibel definiert werden, statt sich mit den Berlin Group Kollegen durch formalisierte und politische Change Management Prozesse zu quälen. So wird heute z.B. der Name des Kontoinhabers, der wichtig für viele Geschäftsmodelle ist, über die ING Schnittstelle angeboten – über die Schnittstellen mit Berlin Group Spezifikation hingegen nicht.
Worüber Klaus Igel und ich uns übrigens sehr einig sind: die PSD2/ RTS-Umsetzung und Aufsicht über PSD2-Schnittstellen ist unabhängig von Standards das viel wichtigere Kampfgebiet der nächsten drei Monate. Denn die Umsetzung auf Einzelbank-Ebene wirkt sich nicht nur immens auf die Backends der Drittdienstleister aus, sondern vor allem auch auf die Frontends der Applikationen und somit die Nutzer und Userflows der Angebote. Wenn die PSD2/RTS-Compliance aller PSD2-Schnittstellen nicht transparent und nachhaltig durch die BaFin und andere europäische Aufsichtsbehörden bis September beaufsichtigt und vollzogen wird, sind Drittdienstleister-Geschäftsmodelle existenzbedroht (dazu mehr von mir bereits hier)!
Warum “versucht (!)” die ING Deutschland es nur?
Weil es bisher – auch EU weit gedacht – kaum schon eine Bank perfekt macht. Die wenigsten haben überhaupt Open Banking so umgesetzt, wie es die Marktexperten seit 2016 predigen – also ihren Wettbewerbsvorteil genutzt und ein Premium-API-Modell veröffentlicht (weitere Positivbeispiele sind die Deutsche Bank mit ihrer dbAPI oder die “Developer First API” von bunq).
Und natürlich fallen mir auch Kritikpunkte zur PSD2-Schnittstelle der ING ein. Auch sie hat durch den gewählten Weg zur Umsetzung der starken Kundenauthentifizierung Hürden für PSD2-Drittdienstleister eingebaut, die andere, wie beispielsweise die Oldenburger Landesbank (ja genau – eine Landesbank!), im Sinne der PSD2 vermieden haben. Ohne zu tief in die nerdigen Details einzutauchen: die OLB stellt – in Einhaltung der PSD2 und der RTS – Drittdienstleistern künftig die gleichen Verfahren zur starken Kundenauthentifizierung zur Verfügung, die sie auch für ihre hauseigenen Banking-Apps nutzt, während andere Häuser sich nutzerfreundliche Erleichterungen durch die Akzeptanz bestimmter Faktoren (z.B. Telefon/Device wird einmalig bei der Bank registriert und gilt als zweiter Faktor „Besitz“) bisher nur für ihre eigenen Apps vorbehalten wollen.
Angabegemäß können Drittdienstleistern diese Vorteile aus technischen Gründen nicht zur Verfügung gestellt werden, welche die OLB wiederum aber nicht hindern, die erleichterten Verfahren über einen sogenannten “decoupled flow” auch PSD2-Drittdienstleistern anzubieten. Und ja, bei der Kommunikation an Kontoinhaber hat auch die deutsche ING noch Verbesserungsbedarf. Aber man zeige mir – bitte! – eine deutsche Bank, die es schafft, alle mit der PSD2 verbundenen Änderungen in einer Sprache an Kunden zu kommunizieren, auf die hin Oma und Nerd einhellig nicken.
Über die Autorin:
Cornelia Schwertner Geschäftsführerin, CRO der FinReach GmbH sowie CRO der figo GmBH Cornelia Schwertner war knapp zehn Jahre als Compliance-Beraterin und Geldwäsche-/Anti-Fraud Beauftragte in der klassischen Welt der der Finanzdienstleistungen unterwegs bevor sie 2016 zum Banking Service Provider und Fintech figo GmbH wechselte. Hier begleitet sie die Umsetzungsprozesse der PSD2 aus Marktsicht und leitete das Projekt, welches figo die Zahlungsinstitut-Lizenz brachte. Seit August 2018 steuerte sie in der Rolle des Chief Risk Officer (CRO) sämtliche Fragen zur Regulatory Compliance von figo. Für den geplanten Merge mit der FinReach GmbH wurde sie dort parallel im Frühjahr 2019 zur Geschäftsführerin bestellt. Bereits seit Anfang 2017 ist sie zudem Vorstandsmitglied der European FinTech Alliance, die Interessen von FinTech Unternehmen gegenüber den EU Institutionen vertritt.
7 Kommentare
Zitat von der Webseite der Figo: „Das figo RegShield macht es möglich, Ihren Service – unter bestimmten Voraussetzungen – trotz PSD2 bzw. des nationalen Zahlungsdiensteaufsichtsgesetzes ohne eigene Lizenz oder Registrierung bei der Finanzaufsicht BaFin weiterzuführen.“
Da bestimmt das Geschäftsmodell die Sicht der Dinge. Kein Wunder das es den Banken bisher nicht so recht gelungen ist das dem Bankkunden zu erklären (siehe letzer Absatz des Artikels).
[…] Replik: Warum die eigene PSD2-Welt der deutschen ING die europäische Zukunft ist […]
Wenn auch etwas spät, aber aus gegebenen Anlass eine kurze Kommentierung:
1. Das Problem ist, dass die EBA eben nicht im Geiste der PSD2 die RTS entwickelt hat, sondern einfach nur überfordert war, entsprechende Standards vorzugeben. Dies erkennt man daran, dass es diverse Verschiebungen zu den Veröffentlichungen gab sowie massive Anpassungen aufgrund der öffentlichen Anhörungen mit den Marktteilnehmern. Das Argument der EBA war dann, dass man keinen Industrie-Standard vorgeben will, sondern das diese sich am Markt entwickeln sollen. Dies ist zwar im Grund ein hehres Ziel, führt aber dann nicht im Geiste der PSD2 zu einem europaweiten Level Playing Field, sondern zu dem Chaos, was wir jetzt haben.
2. Viele Banken haben wirklich versucht, die PSD2 wie gefordert umzusetzen. Aber aufgrund der unklaren Vorgaben und der knappen Zeit war es ihnen kaum möglich, dies widerspruchsfrei zu tun. Z.B. war es vielen Banken gar nicht möglich, im Rahmen der Testphase ausreichend Traffic auf ihre Schnittstelle zu bekommen. Schlicht, weil es kaum Dritte Dienstleister gab, die wirklich darauf zugegriffen haben. Viele Banken hatten tatsächlich keine Zugriffe in der Zeit.
3. Auch wenn es von den FinTechs nicht gerne gehört wird, aber es ist nicht Aufgabe der Aufsichtsbehörden, schnell und umfassend dafür zu sorgen, dass es ein passendes Marktumfeld für ihre angebotenen Dienstleistungen gibt. Das wird auch deutlich durch die BaFin, nicht zuletzt durch Felix Hufeld immer wieder, betont. Vielmehr ist es die Aufgabe der Aufsichtsbehörden, ein faires Marktumfeld für die Verbraucher und Unternehmenskunden zu schaffen; unter Berücksichtung von Marktstabilität und Sicherheit.
Und leider jetzt noch einmal Besserwisser-Modus an: die Oldenburgische Landesbank ist keine Landesbank (im Sinne des Drei-Säulen Modells). Diese ist eine Privatbank, die früher zur Dresdner Bank gehörte, dann im Allianz-Konzern war und jetzt an einen Finanzinvestor (was aber auch mit ehemalig richtigen Landesbanken passiert ist) verkauft wurde.
Völlig falsche Sichtweise, frei nach dem liberalen Motto „Marktwirtschaft um jeden Preis“. Bevor eine Bank sich darum kümmert, Entwicklerfreundlich zu sein, sollte sie Kundenfreundlich sein. Eine Bank, die ihre Kunden zwingt, Bankgeschäfte über Drittanbieter abzuwickeln und damit den Wunsch des Kunden nach Datensparsamer Ende-zu-Ende-Kommunikation mit seiner Bank mit Füßen tritt, ist nicht kundenfreundlich. Als Kunde habe ich kein Interesse daran, ob irgendwelche Fintechs sich fair behandelt fühlen oder ihr Stück vom Kuchen bekommen. Ich und viele andere strafen die ING daher völlig zurecht mit einer Kündigung. Auch hat PSD2 nichts von Moderne. Es ist wie so oft, die nachgeschobene gesetzliche Lösung für ein Problem, dass der Markt längst ohne zutun verschlafener Politiker gelöst hatte. Die FinTechs sind bisher gut ohne ausgekommen. Die Quintessenz von PSD2 ist sicherheitstechnischer Wahnsinn, fortschrittsblockierende Überregulierung und ein Datenschutztechnischer Supergau. Kurz: Der typische EU-Blödsinn.
Die Sicht der Fintechs ist die Sicht von gewinnorientierten Unternehmen, nicht die der Kunden.
Daher widerspreche ich mal heftig.
„Dieser feine Unterschied, also online/ Drittdiensleister-Server vs. App/ lokaler Speicher des Nutzers, begründet heute durch die gesetzliche Grundlagen eine immense Ungleichbehandlung für Dienstleister (Regulierung vs. fehlende Regulierung). Ist das gerechtfertigt?“
Ja ist er. Denn es geht hier eben nicht um Marktanteile und Marktzugangshürden, es geht um Sicherheit. Fintechs, die ungehindert auf Kundendaten zugreifen und damit arbeiten wollen, müssen sich der Kontrolle stellen.
Warum sollte sich ein Softwarehersteller, der eine lokale Software dem Kunden zur Verfügung stellt, dieser Kontrolle stellen? Er hat zu keinem Zeitpunkt Zugriff Kundendaten, der betreibt keine Server, die Kundendaten vorhalten.
Die aktuelle Richtlinie wirkt wie von Fintechs geschrieben, die mehr oder weniger subtil die Multibanking-Softwareanbieter aus dem Markt drängen und die Services als servergestützte Dienstleistungen selbst anbieten wollen.
Das ist aber gegen die Idee von psd2.
Auch wenn mich nicht wundert, das die Autorin als Fintech-Vertreterin das so ganz anders sieht.
Ich kann dem vorherigen Kommentator (Martin Kraft) nur zustimmen.
Und wenn ich das Statement der Autorin lese: „Die ING schafft ein Level Playing Field, das der Gesetzgeber dem deutschen Markt bis heute schuldet.“, dann mag das so sein aus Sicht vieler Fintec-Unternehmen (wie z.B. figo), die in diesem Bereich Marktchancen sehen. Das dürfen sie ja, sich ihren Markt für ihre neuen Produkte suchen.
Nur als Kunde der ING interessiert mich das einen feuchten Kehricht, insbesondere dann nicht, wenn ein vorher tadellos im Zusammenwirken mit einer Onlinebanking-Software funktionierendes Produkt, was es nun einmal schon seit rund 30 Jahren (auf PC’s) und rund 15 Jahren (auf Smartphones) gibt, jetzt plötzlich nicht mehr funktionieren soll.
Oder wurden etwa Pferdekutschen verboten, bloß weil es vor gut 100 Jahren dann auch Automobile gab …?
Das bessere Produkt sollte der Maßstab sein, nicht irgendeine gesetzliche bzw. EU-Vorgabe !
Nein ich kann der Autorin nicht zustimmen. Es werden Begriffe vermischt, die nichts mit einander zu tun haben. 1.Fints und HBCI beschreiben eine Schnittstelle, die sich bisher exzellent bewährt hat. 2. Die PSD2 Richtlinie beschreibt einen Sicherheitsstandart.
3.Eine API also ein Programm muss erst einmal die PSD2 Richtlinie beinhalten, ich habe als User keinen Einfluss darauf.
Frage: Wieso soll eine API, die mit HBCI funktioniert nicht auch PSD2 konform sein?
Sich auf neue Programme einer Bank zu verlassen bringt keinen Sicherheitsgewinn erst Recht nicht Webfrontentbasiert. Die Phishing-Programmierer stehen schon in den Startlöchern.