Anzeige
EVENTS & MESSEN19. November 2018

NextGenPSD2 Konferenz 2018: Berlin Group gibt Ausblick auf Mehrwertdienste und Erweiterungen

Am 14. und 15.11.2018 fand zum zweiten Mal die NextGenPSD2-Konferenz der Berlin Group in den Räumen der Deutschen Bank statt. Ging es im vergangenen Jahr noch primär darum, die initiale Spezifikation zu präsentieren und hierzu ein erstes Feedback zu bekommen, so wurde dieses Jahr unter dem Motto „Beyond Delivery“ vor allem ein Ausblick auf potenzielle Mehrwertdienste und funktionale Erweiterungen gegeben.

von Klaus Igel

NextGenPSD2 Konferenz
Klaus Igel
Die Initiative der Berlin Group verfolgt das Ziel, eine offene, standardisierte und europaweit verfügbare API für den Zugriff auf Bankkonten durch Drittanbieter (TPPs) zu erstellen. Während in den RTS (Regulatory Technical Standards) allgemeingültige Zielvorgaben, z.B. hinsichtlich der Sicherheit und Verfügbarkeit der APIs geregelt sind, so hat sich die Berlin Group die Erstellung eines API-Standards für die Core Services zur Aufgabe gemacht.

Die Grafik zeigt den Scope der Berlin Group API – es geht konkret um den Zugriff auf bestimmte Kontoarten durch Drittanbieter.Creative Commons Attribution-NoDerivatives 4.0 International Public License/ General Introduction Paper der Berlin Group https://www.berlin-group.org/nextgenpsd2-downloads

Der direkte Zugriff des Kunden auf sein Konto, die Beziehung zwischen Kunden und Drittanbietern sowie das Online-Banking des ASPSPs bleiben von der Berlin Group API unberührt.

Aktuell haben sich bereits 50 Finanzinstitute aus 20 Ländern der NextGenPSD2-Initiative angeschlossen. Eine nahezu vollständige Abdeckung an Banken/Finanzinstituten, die ihre PSD2-Schnittstelle auf Basis der Berlin-Group-API umsetzen, findet man in Deutschland, Österreich, Italien und Bulgarien. Europaweit kommen noch weitere API-Standards zum Einsatz, wie z.B. Open Banking oder STET.

Die aktuelle Situation

Autor Klaus Igel
Klaus Igel ist Banking- und IT-Experte und seit mehr als 25 Jahren in diesem Bereich tätig. Igel ist geschäftsführender Gesellschafter bei Subsembly und Softwareentwickler mit den Themen Retail Banking, Zahl­ungs­ver­kehr, Mobile Payments, Authen­ti­fi­zier­ungs­lö­sungen und Banking-Schnitt­stellen wie z.B. FinTS/HBCI. Neben Projekten im Inland hat er auch in Asien/Nordamerika Lösungen für den Finanzsektor entwickelt. Klaus Igel äußert sich zu Themen bei Twitter unter kig_de
Funktional bietet die Berlin Group API im Vergleich zur gelebten Praxis aktuell nichts wirklich Neues. Das Abfragen von Kontodaten, Umsätzen, Salden sowie die Auslösung von Zahlungen durch eine Drittpartei sind seit Jahren etablierte Use Cases, z.B. auf Basis nativer APIs, nationaler Schnittstellen wie FinTS oder via ScreenScraping.

Die wesentlichen Änderungen sind dann auch darin zu sehen, dass es künftig nur noch Kontozugriffe durch regulierte Dritte geben wird und dieser anwendungszweckbezogen (Kontoabfragen, Zahlungsauslösung, Bestätigung verfügbarer Beträge) erfolgen kann. So kann beispielsweise künftig im Rahmen einer Zahlungsauslösung nicht mehr einfach „nebenbei“ die Umsatzhistorie des Kunden ausgelesen werden, ohne dass dieser hierfür ein explizites Einverständnis erteilt wurde.

Darüber hinaus stellt die Identifikation der Drittanbieter die große Änderung gegenüber der aktuellen Situation dar, in der der ASPSP (Bank / Finanzdienstleister) nicht unterscheiden kann, ob der Zugriff durch den Kunden selbst oder durch einen Dritten erfolgt.

Stand heute ist für den Zugriff auf Kontodaten in der Regel die Kombination „Benutzername/Passwort“ ausreichend. Zukünftig wird eine starke Kundenauthentifizierung (SCA) verlangt, d.h. für die Authentifizierung des Kunden werden mindestens zwei Faktoren aus verschiedenen Kategorien (Wissen/Besitz/Inhärenz) benötigt, wodurch es zu einer erhöhten Sicherheit auf Seiten der Kunden kommen wird.

Die NextGenPSD2-Konferenz

Klaus Igel

Nach dem obligatorischen Willkommensgruß und einleitenden Worten gab es interessante Statements im ersten Diskussionspanel zum strategischen und regulatorischen Ausblick:

1. Es wird an eine Expansion außerhalb Europas gedacht – insbesondere im US-Markt besteht Interesse an den Aktivitäten der NextGenPSD2-Initiative.
2. Es gibt mit der Berlin-Group-API zwar einen Standard, aber viele unterschiedliche Implementierungen. Service Providern, denen die Anbindung zu fragmentiert/kompliziert ist, wird die Nutzung eines Single Access TPP empfohlen.
3. Mit einer PSD3 mag man sich aktuell nicht wirklich beschäftigen – es wird eher auf Nachbesserungen/Erweiterungen der PSD2 hinauslaufen.
4. Im Scope sollten auf längere Sicht nicht nur Finanzdaten, sondern auch andere Kontoarten sein.

Sehr informativ waren die folgenden Vorträge von Dr. Detlef Hillen, Dr. Ortwin Scheja (beide: SRC Security Research & Consulting) und Oliver Bieser (Deutsche Bank) zu den neuen Features, die seit der Veröffentlichung der initialen Spezifikation hinzugekommen sind.

Neben den durch die PSD2 definierten verpflichtenden Services (Artikel 65 / 66 / 67) für die Auslösung von Zahlungen, der Abfrage von Kontoinformationen und verfügbaren Beträgen wurden nunmehr auch Extended Services spezifiziert. Die Umsetzung der Zusatzdienste bleibt allerdings dem jeweiligen ASPSP überlassen und erfordert ggfs. separate Verträge zwischen Anbietern und TPPs.

Im Einzelnen handelt es sich um die folgenden neuen Services:

Use Case Betroffener Service
Terminzahlungen PIS
Massenzahlungen PIS
Wiederkehrende Zahlungen PIS
Stornierung noch nicht ausgeführter Zahlungen PIS
Autorisierung verschiedener Transaktionen mit einer SCA-Methode AIS/PIS
Abfrage von Kontodetails (Kartenkonto) AIS
Saldenabfrage (Kartenkonto) AIS
Transaktionsabfrage (Kartenkonto) AIS

Für die Strong Customer Authentication gab es bisher drei Varianten:
1. Redirect (Endbenutzer wird zum ASPSP weitergeleitet)
2. Decoupled (z.B. in einer mobilen App / zwischen Endbenutzer und ASPSP)
3. Embedded (Endbenutzer gibt seine Zugangsdaten beim regulierten TPP ein)

Neu spezifiziert wurde die Integration des OAuth2-Protokolls als Alternative zum Redirect sowie Sammelfreigaben im Corporate Kontext.

In einer weiteren Präsentation hat Herr Christian Seegebarth von der Bundesdruckerei die Möglichkeiten und Abläufe der TPP-Authentifizierung vorgestellt. Jeder Zugriff auf die PSD2-API setzt die Authentifizierung des TPPs voraus, die entweder durch eine Website Authentication (Protokolllevel) oder durch Electronic Seals (Application Level) erfolgen kann. Für TPPs hat das zur Folge, dass zwei Zertifikatstypen (Electronic Seals / Website Authentication) benötigt werden, sofern man alle ASPSPs adressieren will. Testzertifikate können im vierten Quartal 2018 bei der Bundesdruckerei beantragt werden.

Erweiterungen wurden auch bei der Consent-Erteilung (Zustimmung des Kunden zur Nutzung der Daten) angekündigt, die exemplarisch nachfolgend anhand des erstmaligen Umsatzabrufs für einen TPP (AIS) dargestellt wird.

Berlin Group

Künftig wird es neben dem Standard-Consent, bei dem der Umfang des Zugriffs (Gültigkeitsdauer / Kontoangabe / Zugriffsart) angegeben wird, noch die folgenden optionalen Consent-Typen geben:
1. Der „Global Consent“ ermöglicht den Zugriff für alle PSD2-Services / alle PSD2-Konten.
2. Der „Bank Offered Consent“ erlaubt es dem TPP, einen leeren Consent Request an den ASPSP zu senden und im Anschluss die erteilten Berechtigungen abzufragen. Der „Bank Offered Consent“ basiert dabei auf den SCA-Methoden redirect oder decoupled.

Neben den erweiterten (optionalen) Services gibt es auch eine Reihe neuer akzeptierte Change Requests:
I. Consent API für Mehrwertdienste
II. API Discovery Service
III. Push Notifications bei Änderung eines Transaktionsstatus oder Ausführung einer Transaktion
IV. Push Service, z.B. bei eingehenden Instant Payments

Features, deren Umsetzung noch diskutiert wird, sind z. B.:
I. Unterstützung von Verbraucherkrediten (Pay Later)
II. Unterstützung weiterer Kontoarten
III. Bereitstellung erweiterter Kontoinformationen
IV. Bereitstellung einer längeren Transaktionshistorie (bisher 90 Tage)

Die Uhr tickt

Seit dem Inkrafttreten der RTS (Regulatory Technical Standards) am 13.03.2018 steht die Timeline fest, in denen Banken ihre APIs für den Kontozugriff und die Auslösung von Zahlungen zur Verfügung stellen müssen. Denn:

Bis 03.2019 müssen die APIs im Testbetrieb für Drittanbieter (TPPs) zur Verfügung stehen und spätestens 09.2019 müssen die APIs dann produktiv zur Verfügung stehen.”

Sofern die Bereitstellung RTS-konformer APIs durch eine Bank nicht erbracht wird, können TPPs auch nach dem 14.09.2019 entsprechende Fallback-Lösungen nutzen.

NextGenPSD2-Fazit

Die Konferenzinhalte waren sicher keine „leichte Kost“, da viele Präsentationen/Vorträge sehr detailliert waren und gleichzeitig auch ein breites Themenspektrum (Regulatorik, Technik, Prozesse, Strategie) abgedeckt wurde. Das war allerdings nicht, da man so auch tiefere Einblicke in die jeweiligen Themenbereiche bekommen konnte.

Schade war allerdings, dass es bei den Podiumsdiskussionen doch sehr wenige kontroverse Diskussionen gab, während es im Markt bei TPPs und Banken doch sehr unterschiedliche Auffassungen gibt – man denke z.B. an das Thema „SCA via Redirect“ oder auch den Umfang der über die API verfügbaren Daten. Hier gibt es im Markt Bedenken, dass es im Vergleich zu den heutigen Verfahren Rückschritte bei der Usability geben wird. Gerade im Bereich „Personal Finance Management / Multibanking“ wird sich noch herausstellen, inwieweit die starke Kundenauthentifizierung hier die Usability beeinträchtigt und im ungünstigsten Fall sogar „unbenutzbar“ macht.

Ein weiterer Kritikpunkt betrifft die nicht mehr zeitgemäße Geschlechterverteilung – kumuliert standen einer Frau insgesamt 27 Männer bei den Paneldiskussionen gegenüber. Hierzu gab es auch via Twitter einen regen Austausch, ob denn Open Banking wirklich Männersache ist.

Es bleibt spannend, wie die PSD2-APIs und hier vor allem die Berlin-Group-API den Markt ab September 2019 verändern und welche weiteren TPPs wir künftig sehen werden. Zu diesen und weiteren Punkten dürften wir dann bei der dritten NextGenPSD2-Konferenz Ende 2019 mehr Klarheit bekommen.Klaus Igel

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert