PSD2 unterscheidet zwei Gruppen von Anbietern:

A. Account Information Service Providers (AISPs) – Kontoinformationsdienste
AISPs sind berechtigt auf Zahlungs- und Abrechnungskonten des Kunden zuzugreifen und ihm konsolidierte Kontoinformationen bereitzustellen.

B. Payment Initiation Services Providers (PISPs) – Zahlungsauslösedienste
PISPs sind berechtigt elektronische Zahlungsvorgänge im Namen des Kunden einzuleiten.

• Beispiel A: Martina möchte einen Überblick über Ihre Finanzen bekommen. Wie viel Geld nimmt sie monatlich mit ihrem Onlineshop ein, wie viel Zins und Tilgung zahlt sie für ihr Darlehen, wie hoch sind ihre Kreditkartenabrechnungen, etc. Dazu nutzt sie einen AISP, der die benötigten Informationen von den verschiedenen Konten und Banken besorgt und zusammenführt.
• Beispiel B: Jan möchte etwas aus dem Onlineshop von Martina bestellen. Er besitzt keine Kreditkarte, nutzt kein paydirekt und eine TAN für eine Überweisung hat er auch nicht zur Hand. Er kann jedoch durch das Übermitteln von zus. Informationen (z.B. IBAN) eine Zahlung über einen PISP an Martina einleiten, so dass diese ihre Ware gefahrlos versenden kann.

Bisher war so etwas auch über das sogenannte Screen Scraping möglich. Dabei würden Jan oder Martina einfach einem Drittanbieter ihre Login Daten übermitteln und dieser gibt sich dann als sie selbst aus, um sich die benötigten Daten zu besorgen. Nach der Übergangsperiode Ende 2019 müssen ASPSPs (Account Servicing Payment Service Provider – kontobezogener Zahlungsdienstleister oder Banken) allen Drittanbietern jedoch entweder eine eigene dedizierte Schnittstelle bieten oder sie dieselbe nutzen lassen, wie sie ihren eigenen Kunden bereitstellen. Nur für den Fall, dass diese versagen, darf als Fallback-Szenario noch auf das Screen Scraping zurückgegriffen werden.

Das alles klingt zunächst einmal so, als wären Banken durch die neuen Gesetze im Nachteil und müssten sich Sorgen machen, Kunden an die neuen Anbieter zu verlieren. Die neuen Richtlinien bieten jedoch auch für sie ganz neue Möglichkeiten. Möglichkeiten zum einen, Umsatz zu generieren und zum anderen das Knowhow von Drittanbietern für eigene Entwicklungen zu nutzen.

Die Grafik oben zeigt nur ein Beispiel, wie die Zufriedenheit bestehender Kunden gesteigert werden kann, ohne selbst etwas Neues entwickelt zu haben. PSD2 ist ein weiterer Schritt in Richtung Open Banking, den man nicht als Bedrohung, sondern als Chance ansehen sollte. Als Chance neue Kooperationen und Partnerschaften einzugehen, als Chance neue Geschäftsmodelle zu entwickeln und als Chance, sich von der Konkurrenz abzuheben, die lediglich versucht, die neuen Richtlinien umzusetzen.

Eine Möglichkeit wären zum Beispiel datenbasierte Finanzservices: Über einen sogenannten Aggregator könnte man Zugang zu den Kundendaten sämtlicher Finanzinstitute, Kreditkarten, Wertpapierkonten und FinTechs in Europa bekommen. Damit könnten neue digitale Produkte kreiert werden, die komplett auf die ganzheitliche Umsatzhistorie und das bisherige finanzielle Verhalten des Kunden zugeschnitten sind.

Private APIs - Banken nutzen private APIs intern schon seit Jahren, um Daten zwischen Legacysystemen oder Funktionalitäten zwischen Anwendungen auszutauschen. Bei vielen Banken bilden sie das Rückgrat ihres Gesamtbanksystems (GBS). Sie sind oft unverzichtbar für das Betreiben von Back-Office Systemen, dienen als Schnittstelle zwischen Back- und Frontend Systemen oder der Aufrechterhaltung von Compliance.

Partner APIs - fördern die Integration mit anderen Firmen mit dem Ziel, Geschäftsfelder auszuweiten,  neue Kanäle zu eröffnen oder Prozesse zu vereinfachen. Ein Beispiel dafür können Verbundpartner sein (externe Partner wie z.B. Versicherungen), in deren Auftrag Verbundprodukte verkauft werden. Wenn die Abwicklung der Verträge über eine Partner API erfolgt, können diese direkt an das elektronische Postfach des Kunden bei seinem jeweiligen Kreditinstitut gesendet werden.

Offene APIs - sie stellen Funktionen und Daten der Bank anderen Firmen zur Verfügung, mit denen sie bisher noch gar keine Geschäftsbeziehung unterhält. Dies könnten beispielsweise veredelte Rohdaten sein, die das Institut mit Hilfe von Data-Mining gewonnen hat.

Ein Problem für Banken könnten jedoh genau diese offenen APIs werden, da sie zukünftig Drittanbietern nicht nur zur Verfügung gestellt werden, sondern auch bestimmte Bedingungen erfüllen müssen [3]:

• der Drittanbieter  muss jederzeit in der Lage sein, sich gegenüber der Bank zu identifizieren
• jeder AISP muss in der Lage sein, Informationen zu Konten oder Transaktionen über einen sicheren Kanal anzufordern oder zu erhalten
• jeder PISP muss in der Lage sein, eine Zahlung des Kunden über einen sicheren Kanal auslösen und deren Status abfragen zu können

Dies kann über die dedizierten Schnittstelle geschehen oder über die für die eigenen Kunden bereits vorhandene. In beiden Fällen müssen die technischen Spezifikationen der Schnittstelle dokumentiert und Drittanbietern zugänglich gemacht werden. Zusätzlich muss eine Übersicht der Dokumentation öffentlich auf der Webseite zur Verfügung gestellt werden. Darüber hinaus müssen Banken Drittanbietern ebenfalls eine Testumgebung bereitstellen, damit diese ihre Software und Anwendungen testen können.

A. Kundenauthentifizierung

Gleich der allererste Punkt (Artikel 1, 1a) [7] der RTS besagt, dass die Identität des Kunden stets mit Hilfe einer starken Kundenauthentifizierung (SCA – Strong Customer Authentification) verifiziert werden muss. Voraussetzungen hierfür ist eine sogenannte Zwei-Faktor-Authentifizierung (2FA).

Dies ist im Grunde nichts Neues. Jeder der Online-Banking nutzt, gebraucht bereits eine 2FA durch die Eingabe einer PIN und beispielsweise einer pushTAN. Neu ist jedoch, dass SCA nun für weit mehr Vorgänge verpflichtend sein wird, als dies bisher der Fall war – wie z.B. das Ändern von sensiblen Daten wie der Adresse.

Die FI-SP kennt durch ihre langjährige Erfahrung sowohl die betroffenen Geschäftsvorfälle, als auch die neuen regulatorischen Anforderungen an diese. Wir können Sie somit dabei unterstützen:

• sämtliche berührten Geschäftsvorfälle zu identifizieren
• von den Ausnahmeregelungen Gebrauch zu machen, um die Benutzerfreundlichkeit zu erhöhen und sich von anderen Instituten abzuheben, die dies nicht tun

B. Ausnahmen für eine starke Kundenauthentifizierung

Die europäische Bankenaufsichtsbehörde (EBA) hat in der finalen Version der RTS bereits eine Reihe von Ausnahmen für eine starke Kundenauthentifizierung genannt.

Befreiung aufgrund der Höhe der Transaktion

Einige Transaktionen sind von dem Zwang zur starken Kundenauthentifizierung (SCA) ausgeschlossen. Es handelt sich dabei hauptsächlich um Vorgänge, die der Kunde entweder sehr häufig tätigt oder deren Beträge sehr niedrig sind. Dazu zählen z.B.:

• das kontaktlose Zahlen am POS (Point of Sale) wenn der Betrag 50€ nicht übersteigt [8]
• das elektronische Bezahlen von Parkgebühren oder Nahverkehrstickets [9]
• Vorgänge, wenn sich der Zahlungsempfänger auf einer von dem Kunden angelegten “Whitelist“ befindet [10]
• wenn sich der Kunde Geld an sich selbst sendet [11]
• eine elektronische Zahlungsanweisung, die 30€ nicht übersteigt

Befreiung auf Basis der Transaktionsrisikoanalyse (TRA)

Jede Transaktion muss gemäß Artikel 2 der EBA-RTS vor der Ausführung auf ihre Betrugswahrscheinlichkeit untersucht. Liegt diese unter einem festgelegten Schwellenwert, so wird sie als Low-Risk Transaktion eingestuft und der Zahlungsdienstleister kann von der Ausnahme der SCA bis zu dem angegebenen Betrag Gebrauch machen (Artikel 16, 2a [12])

Die erfordert jedoch, dass der Zahlungsdienstleister (PSP) eine Real-Time Risikoanalyse durchführt, noch bevor die Zahlungsanweisung durchgeführt werden darf. Liegt das Ergebnis dieser Risikoanalyse unter dem Wert der Tabelle, kann der PSP von der Ausnahme bis zur Höhe des angegeben Schwellenbetrags Gebrauch machen.

Dies ist zwar bequem für den Kunden und kann somit wieder helfen, sich von anderen Anbietern zu differenzieren. Es erfordert jedoch auch ein Transaktions-Monitoring-System, welches das Risiko sämtlicher elektronischen Zahlung in Echtzeit messen kann. Dazu muss es in der Lage sein, folgende Faktoren zu berücksichtigen:

• abnormales Zahlungsverhalten des Kunden
• Erkennen von Schadsoftware oder merkwürdigen Endgeräten
• Identifizieren von bekannten Betrugs-Szenarien
• Erkennen, ob der Kunde sich in einem für ihn ungewöhnlichen Land aufhält
• Erkennen, ob der Zahlungsempfänger aus einem Hoch-Risiko-Land stammt

Zusätzlich müssen diese Risikowerte und jeder Betrugsfall gespeichert und für spätere Prüfungen archiviert werden. Dies ist nicht einfach, denn es erfordert Anwendungen, die dazu in der Lage sind, als auch die richtigen Informationen, mit denen diese versorgt werden müssen.