PSD2: Die finalen RTS – was bedeuten sie für Banken?

Die finalen RTS zur starken Kunden­au­then­ti­fi­zierung und sicheren Kommunikation wurden am 27.11.2017 dem europäischen Parlament zur Verabschiedung übergeben – damit heißt es: Entweder wird diese Version in den nächsten drei Monaten verabschiedet und in Kraft treten oder es wird eine neue Konsultation bei Ablehnung geben. Da keiner nach dem kontroversen und beschwerlichen Entstehungsprozess der RTS letzteres erwartet, lohnt sich nun ein Blick auf die Änderungen und Implikationen der finalen Version. Was sich im Vergleich zum finalen Entwurf vom Februar an wesentlichen Inhalten geändert hat – im Detail.

von Lilli Looks, Senior Consultant Capgemini Consulting

Bereits im Januar 2017 sollten die RTS verabschiedet werden und wurden seitdem von den betroffenen Zahlungsdienstleistern, worunter auch Kreditinstitute und E-Geldinstitute fallen, sehnsüchtig erwartet. Nach Erscheinen des finalen Entwurfs im Februar 2017 folgte im Mai die Zustimmung der Europäische Kommission zu diesem – jedoch mit vier Anmerkungen. Im Juni nahm die EBA zu den Anmerkungen der Europäischen Kommission Stellung. Nun nach langer Konsultationsphase, wohl aufgrund der intensiven Lobbyarbeit verschiedenster Parteien, ist das finale Dokument endlich erschienen.

Nach Veröffentlichung in den nächsten drei Monaten haben die Institute 18 Monate Zeit, um die Anforderungen umzusetzen.”

Jedoch haben viele Häuser bereits mit den Arbeiten an der Kommunikationsschnittstelle und der starken Kundenauthentifizierung begonnen. Zahlreiche IT-Dienstleister bieten bereits u.a. jetzt schon Lösungen für eine PSD2-konforme Kommunikationsschnittstelle an.

Änderungen zum finalen Entwurf der RTS – Wurden die Forderungen der EBA umgesetzt?

Einsatz Prüfer
Die Europäische Kommission ist dem Vorschlag der EBA nachgekommen, für die Prüfung der RTS “Wirtschaftsprüfer/statutory auditors” gegen Prüfer mit Fachwissen auf dem Gebiet der IT-Sicherheit und des Zahlungsverkehrs auszutauschen. Der Prüfer muss auch weiterhin unabhängig sein.

Ausnahme von der starken Kundenauthentifizierung bei bestimmten B2B-Transaktionen
Die Kommission hat in der finalen RTS-Version gegen den Vorschlag der EBA eine weitere Ausnahme im Rahmen der starken Kundenauthentifizierung hinzugefügt. Diese betrifft elektronische Zahlungsvorgänge, die typischerweise nur durch von Unternehmen genutzte dedizierte Zahlungsprozesse oder -protokolle ausgeführt werden, bei denen Sicherheit anders als durch die Authentifizierung einer Einzelperson erzielt wird. Diese Ausnahme gilt jedoch nur, wenn die zuständigen Behörden bestätigen, dass diese Zahlungsmethoden das durch die PSD 2 geforderte hohe Sicherheitsniveau erfüllen.

Meldung der Methodik und Kalkulation der Betrugsrate sowie der Betrugsraten selbst
Es wurde dem Hinweis der EBA gefolgt, die Meldung bzgl. der Methodik und dem Modell zur Berechnung der Betrugsraten sowie die Meldung von den Betrugsdaten selbst an die EBA und die zuständigen Behörden mit dem Hinweis zu versehen, dass dies nur auf Anfrage geschehen muss sowie mit vorheriger Information an die zuständigen Behörden. Somit entstehen zu diesem Thema kein reguläres Reporting und keine Doppelanfragen durch EBA und Behörde.

Kommunikationsschnittstelle
Im Hinblick auf die Kommunikation zwischen konto­führenden Zahlungsdienstleistern, Kontoinformations- und Zahlungsauslösedienstleistern ist die bestehende Praxis, dass Drittanbieter ohne Identifizierung Zugang zu Kundenkonten erlangen (auch als „Screen Scraping“ bezeichnet) nicht mehr zulässig, nachdem die Übergangsfrist von 18 Monaten abgelaufen ist.

Die Kommunikationsschnittstelle, die Drittanbietern zur Verfügung gestellt werden muss, kann jedoch weiterhin eine dedizierte Schnittstelle oder die von den Zah­lungs­dienst­nutzern des kontoführenden Zahlungs­dienst­leisters genutzte Schnittstelle sein. Allerdings ist die Nutzung dieser Kundenschnittstelle nun an konkrete Vorgaben geknüpft, da ein anonymer Zugriff, wie beim Screen Scraping, verhindert werden soll (bei Nutzung der Kundenschnittstelle müssen z.B. durch den Drittanbieter die abgerufenen Daten protokolliert werden und auf Anfrage der zuständigen Behörde zugänglich gemacht werden).

Nutzt der Zahlungsdienstleister eine dedizierte Schnittstelle, muss er in diesem Fall eine Fall-back-Lösung vorhalten, was entweder die Nutzung der Kundenschnittstelle durch Drittanbieter oder eine zweite dedizierte Schnittstelle bedeutet. Hintergrund dieser Forderung ist die Sicherstellung der ständigen Verfügbarkeit der Kontoinformations- und Zahlungsauslösedienste. Von der EBA wurde ein solches Fall-back-Szenario allerdings in ihrer Stellungnahme zu den Änderungen der Kommission im Wesentlichen aus zwei Gründen abgelehnt:

1. Die Kosten der Fall-back-Lösung müssten von den kontoführenden Zahlungsdienstleistern zusätzlich zu den Kosten einer ordnungsgemäß funktionierenden dedizierten Schnittstelle getragen werden.

2. Ein verpflichtendes Fall-back-Szenario schwäche den Anreiz zur Entwicklung standardisierter dedizierter Schnittstellen, da die Fall-back-Lösung an sich für die kontoführenden Zahlungsdienstleister bereits ausreichen würde, um PSD 2 compliant zu sein.

Die Kommission hat diese Bedenken überprüft und eine Ausnahmeregelung eingeführt. Wenn die dedizierte Schnittstelle u.a. ausreichend (mind. 3 Monate) unter Marktbedingungen (d.h. z.B. unter Miteinbeziehung von Drittanbietern) getestet wurde und sie alle Anforderungen der RTS erfüllt, besteht die Möglichkeit, die Pflicht für die Fall-back-Lösung aufzuheben. In Deutschland ist eine Zertifizierung der Schnittstellen durch die BaFin denkbar.

Neu in den finalen RTS sind zudem die Fristen bei der Bereitstellung der Dokumentation der Schnittstelle und der Testumgebung, in der Drittanbieter die Schnittstelle der jeweiligen Bank testen können. Beides muss bereits 6 Monate vor Ende der RTS-Umsetzungsfrist bereitstehen.”

Ebenfalls neu bei den Anforderungen an die Kommunikationsschnittstelle ist, dass Drittanbieter nicht mehr nur ein Redirect auf die Seiten des kontoführenden Dienstleisters als Übertragung der Authentifzierungsmerkmale nutzen können. Es ist nun notwendig, mindestens eine weitere Form der Übertragung der Authentifizierungsmerkmale anzubieten, z.B. die Anmeldedaten direkt auf der Seite des Drittanbieters angeben zu können.

Womit sich Banken in den nächsten 18 Monaten beschäftigen müssen

Banken, aber auch alle anderen von der PSD 2 betroffenen Zahlungsdienstleister, sollten zeitnah eine Betroffenheitsanalyse durchführen, um der Frage nachzugehen, welche Artikel der RTS tatsächlich in ihrem Haus zu Anpassungsbedarfen führen. Eventuell hat das Institut bereits einen PSD 2 konformen Umgang mit personalisierten Sicherheitsmerkmalen oder eine PSD 2 konforme starke Kundenauthentifizierung im Einsatz. Hier müsste dann z.B. nur noch darüber entschieden werden, ob Ausnahmen von der starken Kundenauthentifizierung genutzt werden sollen.

Der wohl größte Umsetzungsaufwand ist bei den nachfolgenden vier Themen zu erwarten:

Transaktionen-Überwachung
Banken müssen eine Transaktionen-Überwachung bereitstellen, um betrügerische Aktivitäten aufdecken zu können. Dieses ist auch im Hinblick auf die umfangreichen Reporting-Anforderungen der noch zu verabschiedenden Guidelines zum Betrugs-Reporting notwendig.

Interaktionen-Überwachung
Alle Zahlungsvorgänge, aber auch alle anderen Interaktionen mit dem Kunden, mit anderen Zahlungsdienstleistern und Händlern im Zusammenhang mit der Bereitstellung des Zahlungsdienstes müssen zurückverfolgt werden können. Jede Kommunikationssitzung muss u.a. eine eindeutige Kennung sowie einen Zeitstempel erhalten.

Starke Kundenauthentifizierung bei Online-Zugang zu Zahlungskonto und Auslösung von elektronischen Zahlungsvorgängen
Es sind für den Zugriff auf Informationen im Online Banking sowie bei der Auslösung von elektronischen Zahlungsvorgängen geeignete Authentifizierungsverfahren auszuwählen und zu implementieren. Das Telefon-Banking ist übrigens nicht von der Anwendung der starken Kundenauthentifizierung betroffen. Zu beachten ist, dass bei elektronischen Zahlungsvorgängen der generierte Authentifizierungscode dynamisch mit dem bestimmten Betrag und dem bestimmten Zahlungsempfänger verknüpft sein muss.

Es sind weiterhin Ausnahmen von der starken Kundenauthentifizierung möglich. Es ist abzuwägen, ob der Kunde sich immer stark authentifizieren muss, um z.B. die Sicherheit zu erhöhen, oder ob Ausnahmen angewandt werden sollen, um beispielsweise Kosten zu sparen (z.B. Kosten pro SMS beim mTAN-Verfahren). Die Abbildung zeigt die Fälle, in denen keine starke Kundenauthentifizierung angewendet werden muss. Ebenfalls ausgenommen von der starken Authentifzierung sind Zahlungen bei denen die Transaktions-Risiko-Analyse erfolgreich angewendet wurde.

Kommunikationsschnittstelle
Wie bereits oben beschrieben, ist eine Kommunikationsschnittstelle durch die kontoführenden Zahlungsdienstleister einzurichten, um den Zugriff durch Drittanbieter auf die Zahlungskonten zu gewährleisten. Die dedizierte Kommunikationsschnittstelle können Banken entweder selbst entwickeln oder extern einkaufen.

Die Dokumentation und die Testumgebung sind, wie bereits erwähnt, rechtzeitig bereitzustellen.

Ebenfalls zu berücksichtigen ist auch die geforderte Fall-back-Lösung. Diese kann umgangen werden, wenn die dedizierte Schnittstelle 3 Monate erfolgreich getestet wurde.

Zusammenfassung

Zusammenfassend ist zu sagen, dass zu der Draft-Version nur wenige Unterschiede bestehen. Wer im finalen Dokument nach konkreten Umsetzungsvorgaben sucht, sucht weiterhin vergebens. Es wird nach wie vor lediglich der Zielzustand beschrieben, jedoch nicht, wie die Institute diesen anhand eines detaillierten Plans erreichen.

Insgesamt ist die Einrichtung der Kommunikationsschnittstelle bei den Handlungsbedarfen weiterhin der größte Aufwandstreiber, glücklicherweise abzüglich einer Fall-back-Lösung. Neue Services im Zahlungsverkehr werden sich zwar schon ab dem 13. Januar 2018 entwickeln, aber die großen Veränderungen sind weiterhin erst nach Implementierung der hoffentlich europaweit standardisierten Schnittstellen in 2019 zu erwarten.aj