5 Min
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.
