Die Zwei-Faktor-Authentifizierung (2FA) von Zahlungstransaktionen ist Standard geworden beim Bezahlen von Dienstleistungen oder Produkten. Der zweite Faktor ist aber auch ein häufiger und kritischer Bruch im Kaufprozess, die UX ist hierbei für den Anbieter/Verkäufer von höchster Bedeutung. Ich freue mich deshalb den folgenden Artikel von Kevin Hampel und Alain Dietrich euch vorzustellen.
Hintergrundinformationen
Neben anderen Zielen sollen durch die Payment Service Directive 2 (PSD2) in Verbindung mit den daraus separierten Regulatory Technical Standards (RTS) die Payer besser vor Missbrauch geschützt werden. Dazu wurde eine SCA-Verpflichtung für Zahlungstransaktionen eingeführt.
Für eine bessere User Experience hat der Gesetzgeber 6 Ausnahmen definiert, bei denen wegen niedrigen Betrugsrisikos von einer SCA abgesehen werden kann. Je nach Höhe des Transaktionsbetrages, bestehen verschiedene Möglichkeiten, eine Transaktion von einer SCA zu entbinden oder diese bei Bedarf gezielt mittels SCA abzusichern[1] Eine der komplexesten und weitreichendsten Ausnahmen – in Bezug auf deren zusätzlich zu erfüllenden Anforderungen – stellt die TRA-Ausnahme dar. Die TRA-Ausnahme kann unter Einhaltung bestimmter Voraussetzungen bei Transaktionsbeträgen zwischen 0 und 500 EUR angewendet werden.
[1] Zum Vergleich sei hier erwähnt, dass es im Kreditkartenumfeld lediglich bei 0,1% aller Transaktionen überhaupt zu einer Reklamation kommt.
Transaktionsbeträge für die SCA-Ausnahmen
Darüber liegende Beträge können nur durch nicht-betragsabhängige Ausnahmen ohne SCA durchgeführt werden. Sowohl der PSP des Payer als auch des Payee sind berechtigt, die TRA-Ausnahme zu nutzen bzw. gegenüber dem anderen Zahlungsdienstleister als Ausnahme – mittels Haftungsübernahme – vorzuschlagen.
Regulatorik / Rahmenbedingungen
Grundsätzlich müssen bei der Nutzung einer TRA quantitative und qualitative Anforderungen unterschieden und umgesetzt werden.
Sowohl der PSP auf Payer- als auch auf Payee-Seite kann eine TRA-Ausnahme anwenden bzw. vorschlagen. Die Kernanforderungen der TRA, die gegenüber der zuständigen lokalen Finanzaufsichtsbehörde bei Bedarf nachzuweisen sind, gliedern sich in drei Kategorien:
- Einhaltung allgemeiner IT-Sicherheitsstandards (PSD2), sowie authentifizierungsspezifischer Maßnahmen (RTS & TRA).
- Erfüllung der im jeweiligen Betrachtungszeitraum zugrundeliegenden Referenzbetrugsquote (je Zahlungsmittel).
Die European Banking Authority (EBA) definiert gemäß der RTS folgende Referenzbetrugsraten:
Die entsprechende Formel zur Berechnung der Referenzbetrugsrate sieht wie folgt aus:
- Durchführung einer Echtzeitrisikoanalyse inkl. der vorgegebener Sicherungsmaßnahmen und der Überwachung der Referenzbetrugsquote.
Neben diesen quantitativen rechtlichen Kriterien existieren noch eine Reihe weiterer qualitativer Anforderungen, die ebenfalls als Bestandteil einer aufsichtsrechtlichen TRA-Compliance anzusehen sind.
Hier ist vor allem auf einen qualifizierten Nachweis durch einen sachverständigen Dritten zu verweisen. Dieser attestiert dem PSP neben einer korrekten Berechnungsmethode der Referenzbetrugsrate, sowie deren zugrunde gelegten Daten und letztlich auch die schriftlich fixierte Dokumentation der damit verbundenen Prozesse und Maßnahmen.
Neben den Anforderungen an ein quartalsweises Reporting zur Überwachung der Kennzahlen und Referenzbetrugsrate, sind vor allem dokumentierungspflichtige Anforderungen zu den vor- und nachgelagerten TRA-Prozessen vorgeschrieben. Dies beinhaltet die Dokumentation für die Aufsichtsbehörden. Auch eine Integration in das Meldewesen an die zuständige Finanzaufsicht ist sicherzustellen.
Es ist daher ratsam, die organisatorisch rechtlichen Anforderungen bereits vor der erstmaligen Nutzung der TRA-Ausnahme durch einen externen Sachverständigen überprüfen zu lassen. Ob bestehende Risikopräventionssysteme den Anforderungen der PSD2 / RTS entsprechen, muss dabei individuell für jeden Marktteilnehmer geprüft und attestiert werden.
Technik / Funktionen
Da die Sicherstellung der Anforderungen an eine Risikoanalyse organisatorisch nur bei der direkten Verarbeitung einer Transaktion möglich ist, muss eine Echtzeitanalyse in der Authentifizierung bzw. in der Autorisierung sichergestellt werden.
Die Echtzeitrisikoanalyse der Zahlungs-transaktionen erfolgt auf Basis von prüfbaren Kriterien und Abläufen, die zur Evaluierung des Risikos notwendig sind.
Eine Echtzeitrisikoanalyse erfordert neben dem technischen Risikopräventionssystem / dem System der Risikoüberprüfung bzw. -messung vor allem auch eine intelligente Steuerungslogik, welche die Transaktion entsprechend für die finale Autorisierung aussteuert. Diese Steuerungslogik kann ggf. durch das gleiche Tool bewerkstelligt werden, das die eigentliche TRA durchführt. Idealerweise laufen Authentifizierung und Autorisierung als Prozess und Ablauf miteinander zusammen.
Beides – Steuerungslogik und TRA – erfordern eine Verarbeitung in Echtzeit. Hierfür wird eine skalierbare, hochverfügbare Anwendung und Architektur benötigt. Die meisten hierfür eingesetzten Tools arbeiten mit einem hybriden Ansatz aus statistischem Machine Learning (ML) und einem regelbasierten Expertensystem. Darüber hinaus müssen auch die entsprechenden Protokollversionen des jeweiligen Zahlungs-instrumentes zur Verarbeitung der korrekten TRA-Felder unterstützt werden. Im Kartengeschäft ist SCA bspw. im 3DS2-Protokoll vom EMVCo spezifiziert. Dieses wird von der Mehrheit der internationalen Kartenorganisationen eingesetzt. Unterschiede ergeben sich jedoch in den Feldbelegungen innerhalb von Autorisierung und Clearing bei Nutzung einer TRA (oder anderer Ausnahmen).
User Experience (UX)
Die UX aus Sicht des Payer bzw. dessen PSP besteht zumeist darin, die SCA bei risikoarmen Transaktionen und soweit dies zulässig ist, zu vermeiden.
Für den Payer wird daher im Idealfall, neben der standardmäßigen Eingabe der Zahlungsdaten z. B. einer Kartennummer, dem Ablaufdatum und ggf. einer Prüfziffer auf eine Authentifizierung verzichtet.
Entscheidend bei einer reibungslosen Umsetzung ist die Einbettung der TRA-Ausnahme in die korrekte und sinnvolle Prüfungsreihenfolge aller bestehenden und im Einsatz befindlichen Ausnahmen. Neben der technischen Umsetzung ist jedoch ebenfalls entscheidend, welche SCA-Methoden im Falle einer SCA-Abfrage vom Kunden akzeptiert und genutzt werden. Diese sollten sowohl für den Payer als auch für den Payee einfach und verständlich durchzuführen bzw. zu unterstützen sein.
Strategisches Potential
Bisher hat sich das Screening von Transaktionen vor allem an der Betrugsprävention und an den Compliance-Vorgaben der Geldwäsche-gesetzgebung ausgerichtet. Dies mündete entweder in der Ablehnung oder der Meldung einzelner Transaktionen.
Die Regulierung zur TRA schreibt eine risikoorientierte Echtzeitanalyse vor, definiert Zielquoten für den Betrug und setzt einen organisatorischen Rahmen für Betrugsprävention. Betrugsprävention rückt damit aus einer rein betriebswirtschaftlichen, eher durch größere Ausfälle punktuell motivierte Perspektive in eine stärker formalisierte, professionalisierte Struktur.
Dies in Verbindung mit dem Einsatz von ML-Tools wird zu einer intensiveren und ganzheitlichen Themenbetrachtung auch mit den Chancen dieser Infrastruktur führen. Insbesondere entsteht durch das Abrücken von einer reinen „Ablehnen-oder-Genehmigen“-Logik eine multikriterielle Sicht. Die Betrugsprävention durch Ablehnen von Transaktionen wird nun durch das weitere Mittel der Wahl zwischen starker Kundenauthentifizierung und friktionsfreier UX ergänzt. ML-Tools können aber auch Kriterien wie Haftung oder Routingweg in Echtzeit optimieren.
Je nach Geschäftsmodell oder dem Risikoappetit des jeweiligen PSP, sind unterschiedliche Ansätze für die SCA-Anwendung denkbar. Es muss nicht zwingend die niedrigste Referenzbetrugsrate angestrebt werden. Ebenso kann es gewollt sein, grundsätzlich eine SCA durchzuführen, um das Kundenerlebnis zu vereinheitlichen. Da die Regulierung neben der reinen Technik auch einen organisatorischen Rahmen vorgibt, werden diese Themen nun systematisch auf Entscheider Ebene gebracht. Die TRA wird damit zum Katalysator einer Bewegung weg von der reinen Transaktionsverarbeitung hin zu einem intelligenten Echtzeit-Transaktionsmanagement.
Zusammenfassung
Die Transaktionsrisikoanalyse (TRA) ist eine von insgesamt 6 Ausnahmen, die einen Payment Service Provider (PSP) von der Durchführung einer Secure Customer Authentication (SCA)[1] bei einer Zahlungstransaktion rechtlich entbindet. Die nach einigen Verschiebungen seit 15. März 2021 vollständig für Deutschland (sowie anderen europäischen Staaten[2]) gültige Verpflichtung bei bestimmten kartenbasierten Transaktionen eine SCA durchzuführen, führt zu einer Vielzahl an rechtlich notwendigen Authentifizierungen und damit verbunden zu abgebrochenen Transaktionen im eCommerce.
Die TransaktionsRisikoAnalyse (TRA) ist eine risikobasierte Ausnahme gemäß der PSD2 / RTS zur Abwicklung einer Zahlungstransaktion ohne SCA (zweiten Faktor)
Mittels einer TRA-Ausnahme kann, unter Einhaltung technischer und organisatorisch-rechtlicher Vorgaben, die SCA entfallen. Nach ersten Erfahrungen zählt die TRA zu den am meisten verwendeten Ausnahmen zur SCA.
[1] auch bekannt als Zwei-Faktor-Authentifizierung
[2] Zeitpunkt des Inkrafttretens EU-weit nicht einheitlich
Über die Autoren
Kevin Hampel: Ist seit über 10 Jahren in den Bereichen Payments, Banking und Cards tätig. Spezialisiert auf die Bereiche Regulatorik, Projekt- & Strategie-Beratung.
Alain Dietrich: Mehr als 25 Jahre Branchenerfahrung, Führungsarbeit und die Mitwirkung in deutschen und europäischen Gremien bilden die Grundlage für seine Beratung bei Banken und Payment-Unternehmen.
Bilder
Image by rawpixel.com
Weitere Artikel zum Thema:
Tokenisierung im Kartengeschäft
