Screen Scraping | PayTechLaw

Screen Scraping ist tot – lange lebe Screen Scraping!

Seit Jahren wird heiß diskutiert, ob Konteninformationsdienstleister (KID), Zahlungsauslösedienstleister (ZAD) und Herausgeber von kartengebundenen Zahlungsinstrumenten (HKZ) Screen Scraping nutzen dürfen, um Zugang zu einem Konto eines Zahlungsdienstnutzers bei dessen kontoführenden Zahlungsdienstleister zu erhalten. PSD2 und insbesondere die regulatorischen technischen Standards zu sicherer Kundenauthentifizierung und allgemeiner und sicherer Kommunikation (Regulatory Technical Standards on Strong Customer Authentication and Common and Secure Communication / RTS on SCA and CSC) schienen das Ableben von Screen Scraping eingeläutet zu haben. Nichtsdestotrotz hat die EBA kürzlich ihre Guidelines on the exemption from the contingency mechanism under Art. 33 (6) RTS on SCA & CSC veröffentlicht, die Screen Scraping als Ersatzoption erlauben.

Was ist Screen Scraping?

Screen Scraping ist eine Methode, mit der man eine Website automatisiert nutzen kann, indem man einen Webbrowser imitiert, um Tätigkeiten auf der Website auszuführen, die normalerweise manuell von einem Nutzer vorgenommen werden. Dies ermöglicht daher eine andere Benutzeroberfläche für den Nutzer als die Originalwebsite. Ein Beispiel im Kontext von PSD2 ist, dass ein ZAD etwa die vom Nutzer zur Verfügung gestellten Sicherheitsmerkmale nutzen kann, um automatisch auf das Bankensystem des kontoführenden Zahlungsdienstleister zuzugreifen, indem er sich als der Nutzer „ausgibt“, um einen Zahlungsvorgang über das Konto des Nutzers auszulösen.

Angestrebter Endzustand: dedizierte Schnittstelle

Ob und wenn ein kontoführender Zahlungsdienstleister eine dedizierte Schnittstelle für KIDs, ZADs und HKZs zur Verfügung stellt, dann kann er den Zugang nur zu seinen Konten nur dann auf die dedizierte Schnittstelle beschränken, wenn er beweisen kann, dass er alle regulatorischen Voraussetzungen erfüllt hat. Ist dies nicht der Fall, muss der kontoführende Zahlungsdienstleister Screen Scraping als Ersatzoption erlauben.

Identifizieren Sie sich!

Es gibt jedoch einen wesentlichen Unterschied zum oben beschriebenen Screen Scraping. KIDs, ZADs und HKZs müssen sich gegenüber dem kontoführenden Zahlungsdienstleister identifizieren. Sie dürfen sich also nicht als der Zahlungsdienstnutzer ausgeben, sondern müssen der eIDAS-Verordnung entsprechende Zertifikate verwenden, um sich zu identifizieren. Aus diesem Grund hat die EBA eine weitere Handlungsempfehlung zur Nutzung von eIDA-Zertifikaten im Kontext der PSD2 (guidance on the use of eIDAS certificates) veröffentlicht.

Befreiung von der Ersatzoption

Wenn ein kontoführender Zahlungsdienstleister Screen Scraping nicht als Ersatzoption erlauben möchte, muss er alle Voraussetzungen gemäß Art. 33 (6) RTS on SCA and CSC erfüllen.

Das bedeutet erstens, transparente Key Performance Indikatoren und Service Level zu definieren und aufrechtzuerhalten. Die nun von der EBA veröffentlichten Richtlinien nennen einige der Key Performance Indikatoren, wie verfügbare Betriebszeiten, Ausfallzeiten, Reaktionszeiten und Support außerhalb der Arbeitszeiten und wie diese zu berechnen sind.

Zweitens bedeutet das, dass der kontoführende Zahlungsdienstleister seine dedizierte Schnittstelle einem Stresstest unterziehen muss. Dieser Stresstest muss den Zugriff mehrerer KIDs, ZADs und HKZs sowie ein großes Volumen an Anfragen und ein großes Volumen von Daten beinhalten. Während die RTS on SCA and CSC generell nicht vor dem 14. September 2019 Wirkung entfalten, verlagert die Anforderung sechs Monate lang getestet zu haben, die Deadline für kontoführende Zahlungsdienstleister ihre dedizierte Schnittstelle fertig zu haben, tatsächlich auf den 14. März 2019 vor.

Drittens muss der kontoführende Zahlungsdienstleiter eine breite Nutzung der dedizierten Schnittstelle über einen Zeitraum von drei Monaten nachweisen. Das bedeutet, dass der kontoführende Zahlungsdienstleister die Möglichkeit der Nutzung seiner Schnittstelle für KIDs, ZAGs und HKZs in angemessener Form bekannt machen muss, wie etwa über eine Website, Soziale Medien, Konferenzen etc. Allerdings kann das Erfordernis einer breiten Nutzung erheblich reduziert werden, wenn auf einem bestimmten Markt keine oder nur wenige KIDs, ZAGs oder KHZs aktiv sind.

Zuletzt muss der kontoführende Zahlungsdienstleister Problemlösungsmechanismen anbieten und zu diesen berichten, um etwaige Probleme, die von KIDs, ZAGs und HKZs gemeldet wurden, in den Griff zu bekommen und um zu beweisen, dass während der Testphase auftretende Schwierigkeiten bereits gelöst wurden.

Keine Hindernisse

Ungeachtet ob ein kontoführender Zahlungsdienstleiter nur eine dedizierte Schnittstelle anbietet oder nicht, muss er seiner zuständigen Aufsichtsbehörde nachweisen, dass die Authentifizierungsmethode (gleich ob Schnittstelle, Re-direct, integriert oder auf andere Weise) für den Zahlungsdienstnutzer kein Hindernis darstellt, sich für die Dienste eines KIDs, ZAGs oder HKZs zu entscheiden. Das bedeutet unter anderem, dass kontoführende Zahlungsdienstleister weder zusätzliche Autorisierungen verlangen, noch die Einwilligung des Zahlungsdienstnutzers überprüfen dürfen.

Alles in allem scheint dies der Startschuss für KIDs, ZAGs und HKZs. Jedoch bleibt abzuwarten, ob und wann die Zahl solcher Dienstleistungen steigen wird und ob sie unter Zahlungsdienstnutzern populärer werden, denn bisher gibt es viel Theorie zum Open Banking, aber nur sehr wenige praktische Anwendungen.

 

Cover picture: Copyright © fotolia /trendobjects

0 Kommentare

Dein Kommentar

An Diskussion beteiligen?
Hinterlasse uns Deinen Kommentar!

Schreibe einen Kommentar

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