Fraudmanagement und PSD2

Ein dominierendes Thema der vergangenen Monate war die EU-Zahlungsdiensterichtlinie PSD2. Ein Grundgedanke der Direktive ist – anders als so manche Schlagzeile des Boulevards zu suggerieren versuchte – ein besserer Verbraucherschutz und die Eindämmung von Betrug und kriminellen Handlungen.


Cybercrime-Angriffe auf Finanzinstitute nahmen in den vergangenen Monaten zu. Dabei wird häufig auf die Methode des Distributed-Denial-of-Service (DDoS) zurückgegriffen, welches das angegriffene System lahmlegt, um anschließend ein Lösegeld zu fordern. Bildnachweis: istock.com/erhui1979

Kurz gesagt verfolgt die Payment Services Directive 2 (PSD2) das Ziel, Nichtbanken die Teilnahme am Wettbewerb im Bereich Zahlungsverkehr zu ermöglichen und gleichzeitig eine Harmonisierung des Verbraucherschutzes zu erreichen. Im Zuge dessen unterwirft die EU-Richtlinie die Anbieter sogenannter Zahlungsauslöse- und Zahlungsinformationsdienste der Regulierung. Nach Artikel 95 müssen sie Technologien einsetzen, die „eine sichere Authentifizierung des Nutzers gewährleisten und das Betrugsrisiko möglichst weitgehend einschränken können.“ Um das Betrugsrisiko zu minimieren, wurden verschiedene Voraussetzungen definiert, die in Zukunft zu beachten sind. Zum einen muss die Authentifizierung stets anhand von mindestens zwei der drei folgenden Elemente durchgeführt werden: Wissen, Besitz und Inhärenz. Der bei der Authentifizierung generierte Code muss während des gesamten Prozesses eine „dynamische Verknüpfung“ zwischen Betrag und Empfänger vorweisen. Bei der Übertragung gilt das Prinzip der „Kanaltrennung“, d.h., dass dieser Code nicht auf dem gleichen Kanal empfangen werden darf, über den die Transaktion initiiert wurde. Die Zwei-Faktor-Authentifizierung zwischen Bank und Drittanbieter wird idealerweise über spezielle Webzertifikate von Trust Service Providern (TSP) abgewickelt.

Ausnahmen vom Prinzip der starken Authentifizierung

Um die Benutzerfreundlichkeit zu erhöhen, sind Ausnahmen von diesen Anforderungen formuliert worden, welche sich am Transaktionsrisiko und der Höhe des Betrags orientieren. Auf diese Weise können Kleinstbeträge am PoS ohne PIN-Eingabe oder im Internet mit einem einzigen Faktor gezahlt werden. Hier könnte nun eine für Betrug und Geldwäsche beliebte Strategie ansetzen: die Aufteilung größerer Summen in kleinere Einheiten, um auf diese Weise hohe Transaktionssummen zu verschleiern oder die Authentifizierung zu umgehen. Dem soll dadurch entgegengewirkt werden, dass nach einer Reihe von Zahlungen immer wieder eine starke Authentifizierung verlangt wird.

APIs bieten eine vergrößerte Angriffsfläche

Durch sogenannte Application Programming Interfaces (APIs), zu deutsch Anwendungsprogrammier-schnittstellen, können Services von Drittanbietern mit dem System der Bank verknüpft werden. Bildnachweis: istock.com/PeterPal

Einer der Eckpfeiler der PSD2 ist die Öffnung der Zahlungssysteme für Drittanbieter über Programmierschnittstellen (APIs). Für die meisten Banken waren APIs bis zuletzt ein rotes Tuch, da sie dem Grundsatz der totalen Abschottung und Absicherung der eigenen IT-Systeme gegen Eingriffe von außen widersprechen. Potenziell entsteht durch die Bereitstellung von Schnittstellen nun eine größere Angriffsfläche für Cybercrime. Cyberkriminelle werden sich ab sofort wohl stärker auf die Systeme der Drittanbieter konzentrieren, welche noch nicht über solch starke IT-Sicherheitssysteme wie die Banken verfügen. Sie werden die aktuelle Übergangsphase dazu nutzen, etwaige Sicherheitslücken ausfindig zu machen und daraus Kapital zu schlagen. Es bedarf effektiver, sicherer und schneller Fraudmanagement-Software, da sich der Dateninput von Drittanbietern erhöhen wird und der Anspruch besteht, alle Transaktionen in Echtzeit freigeben und durchführen zu können.

Distributed-Denial-of-Service-Angriffe (DDoS)

In der Prävention und Bekämpfung potenzieller Hacker-Angriffe sollte ein besonderes Augenmerk auf sogenannte Distributed-Denial-of-Service-Angriffe (DDoS) gelegt werden. Bei diesen Attacken wird die Schwachstelle eines Systems als Ausgangspunkt genutzt, um von dort aus eine Vielzahl angeschlossener Systeme ebenfalls zu infizieren. Anschließend werden all diese Systeme für einen Angriff auf das eigentliche Ziel gebündelt, um dieses mit Datenpaketen zu überfluten und es somit zum Erliegen (Denial-of-Service) zu bringen. Solche DDoS-Angriffe, die letztlich dem Ziel einer Erpressung des lahmgelegten Systems dienen sollen, wurden in der jüngeren Vergangenheit auch vermehrt gegen Banken und Payment-Anbieter durchgeführt. Eine Erhebung der IT-Sicherheitsfirma Link11 hat für das dritte Quartal 2017 im Vergleich zu den Vormonaten einen Anstieg von DDoS-Attacken um 48,8 Prozent ergeben. Somit ereignen sich durchschnittlich 293 Angriffe pro Tag auf Unternehmen in der DACH-Region. Ein aktuelles Beispiel aus der Finanzbranche ist ein Angriff auf die drei größten niederländischen Banken (Rabobank, ING und ABN Amro) am 29. Januar 2018. Nach einer eingeschränkten Nutzbarkeit des Online-Bankings konnten die Dienste zwar relativ zügig wiederhergestellt werden, das Ereignis bleibt jedoch alarmierend.

Was bleibt zu tun?

Zunächst einmal müssen sich Banken auf die vollkommen neue Ausgangslage einlassen und ihre Denkweise über die Sicherheit ihrer IT-Systeme entsprechend anpassen. Das Prinzip der totalen Abschottung wird durch den verstärkten Einsatz von APIs keinen Bestand mehr haben. Stattdessen müssen zeitgemäße und anwendungsorientierte Strategien zur Verhinderung von Betrug und Cybercrime entwickelt werden. Diese Aufgabe liegt nicht allein auf Bankenseite. Die Betrugsprävention muss in Kooperation mit den involvierten Drittanbietern forciert werden. Und nicht zuletzt müssen auch die Endkunden immer wieder für die bestehenden Gefahren sensibilisiert werden. Ein Vorteil könnte darin liegen, dass viele Modelle derzeit von Grund auf neu entwickelt werden und die aktuellen Standards und Richtlinien, wie etwa die am 25. Mai 2018 in Kraft tretende Datenschutz-Grundverordnung (DSGVO), von Beginn an integriert werden können. Dies kann mutmaßlich besser gelingen als die Implementierung in bestehende, über Jahrzehnte organisch gewachsene Systeme. Eine Herausforderung besteht allerdings darin, dass die Scoringmodelle von Betrugssoftware über mehrere Monate bis hin zu zwei Jahren trainiert werden, bis sie tatsächlich effektiv arbeiten können und z.B. die Falsch-Positiv-Rate auf ein Minimum reduzieren. Dies zwingt alle Beteiligten vor allem in den kommenden Monaten zu proaktivem Handeln und stetigen Anpassungen.