EU-Regulierung zu Zahlungsdiensten

Meine API, deine API, keine API

Christian Kirsch

Mehr Sicherheit bei Geldgeschäften, mehr Komfort und mehr Konkurrenz beim Zahlungsverkehr – das sind einige Ziele der Zweiten Zahlungsdiensterichtlinie der EU. Was sich vielversprechend anhört, ist im Detail heftig umstritten.

Bankgeschäfte online zu erledigen, ist schon seit Jahren üblich. Und längst mischen nicht nur Banken in dem Markt mit, sondern auch sogenannte Fintechs: junge Unternehmen, die digitale Zahlungsdienste anbieten. Das Verhältnis zwischen ihnen und den Banken ist gespannt. Denn Fintechs bedienen meist Bedürfnisse, die klassische Geldhäuser nicht so recht befriedigen können. Dazu gehört zum Beispiel die „Zahlungsauslösung“ wie bei PayPal oder Sofortüberweisung.

Um die Online-Verhältnisse zwischen Banken, Kunden und neuen Anbietern zu ordnen, beschloss die Europäische Union 2015 die „Zahlungsdiensterichtlinie“ (Payment Service Directive, [1]). Da sie eine gleichnamige Vorschrift von 2009 ablöst, heißt sie häufig auch PSD2 (siehe „Alle Links“ am Ende des Artikels). In diesem Zusammenhang häufig anzutreffende Akronyme sind PISP (Payment Initiation Service Provider) und AISP (Account Information Service Provider), die gemeinsam als Third Party Provider (TPP) bezeichnet werden. Sie müssen sich in Zukunft registrieren (AISP) oder den Betrieb von der Bundesanstalt für Finanzaufsicht genehmigen lassen (PISP). Ihre Gegenspieler heißen im Neusprech „Account Servicing Payment Service Provider“ (ASPSP), früher schlicht „Bank“. Dem Verständnis des Gesetzes sind derlei Ungetüme nicht unbedingt zuträglich.

Mehr Sicherheit durch starke Authentifizierung

Doch nicht nur schöne neue Begriffe und Akronyme prägen die PSD2. Vor allem geht es darum, Onlinezahlungen sicherer zu machen, die Rechte von Fintechs gegenüber Banken zu regeln und mehr Rechtssicherheit für sie zu schaffen. So verlangt die Regulierung in Artikel 97 erstmals eine starke Kundenauthentifizierung (SCA), die zwei Elemente aus den Kategorien Wissen, Besitz und Sein verwendet. Letzteres könnten etwa Fingerabdrücke oder Iris-Daten sein. Diese zwei Elemente sind auch bei der ersten Abfrage des Kontostands erforderlich sowie erneut spätestens alle 90 Tage. Bislang reicht dafür hierzulande in der Regel die Online-PIN. Die Authentifizierungsmittel müssen unabhängig voneinander sein, was Anforderungen an das mobile Banking stellt, wenn dasselbe Gerät etwa für die Faktoren „Besitz“ und „Wissen“ Verwendung findet. Bei Überweisungen müssen zudem der Betrag und der Empfänger in die Authentifizierung einfließen. Das ist das Aus für die bisherigen (i)TANs, die keine Transaktionsdetails codieren.

Diese Vorschriften schaffen mehr Sicherheit für Kunden, Banken und Fintechs und sind deshalb unumstritten. Folglich gibt es um sie auch keinen Streit. Ganz anders sieht es jedoch bei den Bestimmungen aus, die das Verhältnis zwischen Banken und TPPs regeln. Sie sind, wie auch die Details der Kundenauthentifizierung, nicht Teil der PSD2, sondern eines „Regulatory Technical Standard“ (RTS), den die europäische Bankenaufsicht EBA im Auftrag der EU-Kommission entwickelt. Die Kommission wird ihn direkt beschließen, ohne dass sich das Europäische Parlament oder der Ministerrat damit befassen.

Bildschirmkratzen ohne Zukunft

Ihren Entwurf des RTS legte die EBA im Februar 2017 vor. Er behandelt zwei Zugänge zu den Kundenkonten bei Banken: Onlinebanking und eine Programmierschnittstelle (API). Ersteres bieten Banken ihren Kunden meist ohnehin an, und es steht damit auch Dritten zur Verfügung. Sie müssen lediglich den HTML-, CSS- sowie JavaScript-Code laden und auswerten. Dieses „Screen Scraping“ verwenden vor allem Fintechs in anderen Ländern. In Deutschland hingegen ist seit Jahren eine früher als HBCI bekannte API etabliert, die heute FinTS heißt. Wo immer möglich, verwenden Bankingsoftware und Dienstleister sie. Der RTS-Entwurf legte erstmals fest, dass Third Party Provider eine solche Schnittstelle nutzen müssen, wenn die Bank sie anbietet.

Unbefangenen Beobachtern mag eine solche Festlegung sinnvoll erscheinen. Schließlich ist Screen Scraping keine technisch sinnvolle Lösung, sondern eher eine Krücke aus dem letzten Jahrhundert. Es erfordert immer Anpassungen, wenn eine Bank ihren Onlineauftritt ändert. Das erfahren deutsche Nutzer von Bankingsoftware schon seit Jahren, wenn sie zum Beispiel eine Miles&More-Kreditkarte besitzen: Deren Umsätze sind nicht via FinTS zugänglich, sodass die Programme die Webseite auslesen müssen. Ändert sich dort etwas, braucht die Software ein Update.

Fallback oder nur Kosmetik?

Obwohl technisch wenig für Screen Scraping zu sprechen scheint, kam von den europäischen Fintechs ein Aufschrei der Empörung, weil der RTS-Entwurf dessen Nutzung untersagen wollte, wenn die Bank eine API bereitstellt. Damit könnten die Banken, so die Befürchtung der Fintechs, sie auf einen langsameren oder gar unvollständigen Zugang festlegen. Das würde ihre innovativen Geschäftsmodelle behindern. Mit dieser Sicht der Dinge bekamen sie viel mediale Aufmerksamkeit – Banken haben ohnehin einen schlechten Ruf, und hier sah es wieder einmal so aus, als ob ein seniler Goliath sich dem agilen, modernen David in den Weg stellte.

Auch bei der EU-Kommission fanden die Fintechs mit ihren Sorgen Gehör. Sie änderte den RTS-Entwurf so, dass er eine „Fallback“-Option enthält. Steht die Bank-API nicht zur Verfügung, darf der TPP auf Screen Scraping ausweichen. Die europäische Bankenaufsicht überzeugte diese Änderung jedoch nicht: Es gebe wenige Anhaltspunkte, dass das Onlinebanking noch funktioniere, wenn die API zusammengebrochen sei. Denn letztlich betrieben Banken sein großes, zusammenhängendes System. Noch gibt es in dieser Frage keine Entscheidung. Immerhin herrscht in anderer Hinsicht Einigkeit: Fintechs sollen sich mit einer eIDAS-konformen ID bei den Banken authentifizieren, damit diese zwischen echten Kunden und TPPs unterscheiden können.

Aber warum verteidigen die innovativen, ausschließlich auf Digitales setzenden Fintechs die Steinzeit-Technik Screen Scraping, zumal sie in Deutschland mit FinTS schon länger und regelmäßig eine API nutzen? Eine Antwort könnte die Reaktion des europäischen Verbraucherverbands BEUC (Bureau Européen des Unions de Consommateurs) geben. Er kritisierte in einem Brief an die Kommission den Wunsch nach Zugriff auf das Onlinebanking: „Wir sind gegen … ,Screen Scraping‘. Der Kunde müsste einem Dritten seine Zugangsdaten überlassen, damit dieser Dritte Zugriff auf Daten bekommt, die nicht unbedingt etwas mit dem von ihm angebotenen Dienst zu tun haben.“ Denn wer das Onlinebanking als „Schnittstelle“ verwendet, sieht dieselben Daten wie der Kontoinhaber: Konten, Kontostände, Kreditlinien, Umsätze, Kontaktdaten, Depotbestände. Wer nur mal schnell einen Onlinekauf bezahlen will, möchte aber womöglich nicht Auskunft über die Höhe seines Dispokredits oder die Daimler-Aktien im Depot geben.

Schreckensbild: sechstausend APIs

Gleichzeitig äußerte das BEUC jedoch Verständnis für die API-Angst der Fintechs. Denn sowohl die PSD2 als auch der RTS überlassen es jeder Bank, eine solche Schnittstelle selbst zu entwickeln. Bei geschätzt 6000 Banken in der EU könnte es so zu 6000 APIs kommen, und sich darauf einzustellen, sei unzumutbar. Dass sich diese Herausforderung nicht grundsätzlich von der unterscheidet, 6000 Banken per Screen Scraping anzubinden, scheinen die Verbraucherschützer zwar nicht bemerkt zu haben. Sie weisen aber darauf hin, dass eine EU-weite, einheitliche API für den Zugriff auf Bankkonten und -dienstleistungen sinnvoll wäre.

Genau das möchten jedoch Kommission und EBA bislang nicht. Wie so oft soll es der Markt irgendwie richten, die Regulierung ist „technologieneutral“. Anders als beim Zahlungssystem SEPA, das die europäischen Bankenverbände untereinander standardisierten, gibt es bereits etliche Ansätze, eine Banken-API zu formulieren. Eigene Vorschläge vorgelegt haben die französische STET, die EBA-Association (nicht zu verwechseln mit der Europäischen Bankenaufsicht), Accenture und das Open Bank Project. Hierzulande arbeitet die Berlin Group, an der die Deutsche Kreditwirtschaft beteiligt ist, ebenfalls an einer API. Sie soll im Oktober präsentiert werden. Außerdem schreiben angeblich die Sparkassen, die Deutsche Bank, Credit Agricole, Nordea sowie etliche andere Banken und Bankgruppen an eigenen APIs.