Gastautor Hakan Eroglu von Accenture wirft einen Blick auf die Open Banking-Regulierung in Grossbritannien und auf die PSD2 aus Brüssel. Und er zieht in seiner Analyse Vergleiche zwischen den Initiativen von Berlin Group (NextGenPSD2) und Open Banking (UK), welche die API-Standardisierung für Europa im Fokus haben.
Hakan Eroglu ist Senior Manager und Experte für Zahlungsverkehr, PSD2/Open Banking und Digitale Ökosysteme bei der Unternehmensberatung Accenture im Bereich Financial Services.
Die Regulierungen und die Frage der APIs
Die britische Wettbewerbsbehörde Competition & Markets Authority (CMA) hat mit der Open Banking-Regulierung eine grosse Veränderungswelle im britischen digitalen Ökosystem der Finanzindustrie ausgelöst. Gleiches gilt für die in Brüssel beschlossene EU-Richtlinie PSD2 (Payment Services Directive 2). Ab 2018 müssen Banken ihre Systeme für Drittanbieter öffnen und Schnittstellen zur Verfügung stellen, zum Beispiel zur Auslösung von Bezahlvorgängen oder dem Abruf von Kontoinformationen. Auf welche Weise sich Drittanbieter technisch mit den Banken verbinden bzw. kommunizieren, lassen diese Regulierungen jedoch offen.
Gemeinsame Standards für ein gesamteuropäisches Ökosystem
Es bleibt zu klären, wie sich bankübergreifende bzw. pan-europäische API Standards für die genannten Anwendungsfälle etablieren lassen. Während die britischen Banken auf Anweisung der CMA eine Implementation Entity – eine eigenständige Firma namens "Open Banking Limited" – zu gründen hatten, wurde die Initiative für PSD2 dem Markt überlassen. Die von der Europäischen Kommission (EK) beauftragte European Banking Authority (EBA) gibt im Entwurf der Regulatory Technical Standards (RTS) für die starke Kundenauthentifizierung und sichere Kommunikation lediglich technische Rahmenbedingungen und keinen Schnittstellenstandard vor.
Die Entwicklung eines pan-europäischen, innovativen digitalen Ökosystems für Finanzprodukte ist eines der zentralen Ziele der PSD2. Für einen funktionierenden einheitlichen Markt sind einheitliche Schnittstellen und Prozesse daher unerlässlich. Aufgrund einer fehlenden "Implementation Entity" für die EU hat die Berlin Group – bestehend aus knapp 40 Banken, Verbänden und PSP aus der EU – unter dem Arbeitstitel "NextGenPSD2" einen gemeinsamen API-Standard für die in der PSD2 vorgegebenen Anwendungsfälle definiert. Parallel dazu laufen Initiativen in Polen, Slowenien und Frankreich.
Die Standardisierungsinitiativen von Open Banking und Berlin Group sind derzeit in der PSD2-Welt die prominenteren Vertreter. Es macht daher durchaus Sinn, sich den Open Banking-Standard in der Version 1.1.0 und Berlin Group (Version 0.99, Version 1.0 erscheint Ende 2017) genauer anzuschauen und die wesentlichen Unterschiede mit Stärken und Schwächen herauszuarbeiten.
Initiativen von Open Banking und Berlin Group: Unterschiede
Bisher können folgende wesentliche Unterschiede – unter einigen anderen – identifiziert werden:
- Open Banking unterstützt im Kontext von PSD2 die Anwendungsfälle "Payment Initiation" (Zahlungsauslösung, Artikel 66 der PSD2) und "Account Information" (Kontoinformationen, Artikel 67 der PSD2). Die Berlin Group komplettiert die Anwendungsfälle mit "Fund Confirmation" (Verfügbarkeitsprüfung eines Betrags, Artikel 65 der PSD2) und deckt somit die gesamte PSD2-Bandbreite bzgl. der Anwendungsfälle ab.
- Die Berlin Group hat gemeinsam mit zahlreichen EU-Banken die verschiedenen Online Banking Masken analysiert und herausgefunden, welche Datenfelder dem Kunden beim Anzeigen von Kontoinformationen zur Verfügung gestellt werden. Auch bei den Überweisungsformularen für die Zahlungsauslösung wurden die möglichen Eingabefelder betrachtet. Daraus entstand ein Minimum-Set von Datenfeldern, das alle Banken über die API standardisiert anbieten müssen. Der Open Banking-Standard hingegen wurde lediglich unter den CMA9-Banken und einer Advisory Groups aus Drittanbietern, innerhalb Grossbritanniens ausgehandelt. Hier werden noch umfangreichere Informationen bereitgestellt, die insbesondere für FinTechs zur Generierung zusätzlichen Mehrwerts in ihren Diensten sehr relevant sind.
- Das Consent-Modell von Open Banking ermöglicht dem Kunden, spezifische Datencluster zur Nutzung von Drittanbietern zu erlauben (zum Beispiel nur Kontostände, Einzahlungen oder Lastschrift-Transaktionen). Dieser Ansatz kommt den Anforderungen der Datenminimalisierung im Rahmen der EU-Datenschutz-Grundverordnung (DSGVO) nahe. Die Berlin Group sieht aktuell einen Consent für Kontostände und Transaktionshistorien für einen bestimmten Zeitraum vor.
- Während der Open Banking Standard nur auf das JSON (JavaScript Object Notation) Format mit Feldnamen basierend auf ISO 20022 Elementnamen setzt, bietet die Berlin Group für Zahlungsauslösung und Kontoinformationen noch alternative Industriestandard-Formate.
- Die starke Kundenauthentifizierung läuft bei Open Banking über den "Redirect"-Ansatz (Weiterleitung auf Bankseite), wogegen die Berlin Group den Banken zwei weitere Ansätze zur Wahl stellt: Decoupled (Verwendung einer dezidierten Bank-App zur Authentifizierung) und Embedded (Authentifizierung wird im Namen des Kunden direkt über die API bei der Bank durchgeführt).
- Open Banking hat neben den API-Spezifikationen zusätzlich die User Experience und die in der Klickstrecke zu nutzenden Textbausteine als Guideline standardisiert. So werden die Consent-Erteilung, Authentifizierung (2FA) und Autorisierung für Kontoinformationen und Zahlungsauslösungen in konkreten Vorschlägen vereinheitlicht. Die Berlin Group stellt jeder Bank frei, wie die User Experience aussehen kann.
- Die in den RTS definierte Transaction Risk Analysis wird durch die verschiedenen Standards unterschiedlich mit relevanten Risikoparametern über die API versorgt. Auch hier bietet der Open Banking Standard mehr Parameter, die über die API an die Bank übergeben werden können.
- Open Banking hat neben den CMA9-Banken auch Vertreter von FinTechs und Challenger-Banken mit an Bord. Die Berlin Group hat den Standard aktuell aus der Banken-Perspektive entwickelt und wird im Rahmen der Marktkonsultation bis Ende 2017 voraussichtlich noch Anforderungen der FinTechs einfliessen lassen.
Mit der Umsetzung eines Standards ist eine Bank nicht automatisch PSD2-compliant. Beide Standards können den Banken alle anderen Aspekte der RTS nicht abnehmen, zum Beispiel die Bereitstellung RTS-konformer Authentifizierungsmethoden, die Umsetzung der Ausnahmeregelungen (Excemptions from SCA) von der starken Kundenauthentifizierung und die Bereitstellung von API-Testsystemen und API-Dokumentation.
Wie geht es weiter?
Die EK hat am 27. November 2017 die finale RTS veröffentlicht. Etwaige Änderungen zur Vorversion können anschliessend in der finalen Version der Berlin Group berücksichtigt werden. Diese hat bis zum 17. November 2017 eine Marktkonsultation durchgeführt und angekündigt, zum Jahresende eine finale Version 1.0 zu veröffentlichen.
Die RTS wird voraussichtlich Ende Februar 2018 vom Europäischen Parlament (EP) ratifiziert. Danach haben Banken und andere PSP 18 Monate Zeit, die RTS umzusetzen – ein Teil davon ist die Bereitstellung von APIs. Dafür haben Berlin Group und Open Banking viel Vorarbeit geleistet.
Banken können zwischen mehreren Standards wählen. Hier spielen strategische und technische Gesichtspunkte eine Rolle, die Banken frühzeitig evaluieren sollten, um rechtzeitig mit dem sinnvollsten Standard an den Start zu gehen.
Was bedeuten diese Standardisierungs-Initiativen für die Schweiz?
Weder die CMA noch die PSD2-Regulierung gelten in der Schweiz. Allerdings haben sich auf dem Schweizer Finanzplatz einige API Banking-Initiativen gebildet, in denen auch API-Standardisierungen eine wichtige Rolle spielen. Schweizer Banken sollten die Entwicklungen ihrer Nachbarn stets im Auge haben. Hier kann aus Fehlern gelernt und auf etablierte Lösungen zurückgegriffen werden – zum Vorteil des Schweizer Bankensektors.
Weitere Informationen zum Thema
Hakan Eroglu präsentiert auf unserer Plattform zentrale Überlegungen und Auszüge seiner Analyse. Für vertiefte Informationen ist der Autor direkt erreichbar:
E-Mail: Hakan.Eroglu(at)mastercard.com
LinkedIn: Profil Hakan Eroglu
