Regulatorik / Rahmenbedingungen TRA

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:

1. Einhaltung allgemeiner IT-Sicherheitsstandards (PSD2), sowie authentifizierungsspezifischer Maßnahmen (RTS & TRA).
2. Erfüllung der im jeweiligen Betrachtungszeitraum zugrundeliegenden Referenzbetrugsquote (je Zahlungsmittel).
   Die European Banking Authority (EBA) definiert gemäß der RTS folgende Fraud-Raten:

Die Referenzbetrugsrate wird nach folgender Formel berechnet:

3.  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 TRA

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 Zahlungstransaktionen 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 Zahlungsinstrumentes 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).

Die folgende Abbildung illustriert die SCA-Prüfung mit TRA für das Beispiel einer Kartenzahlung:

User Experience (UX) TRA

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 TRA

Bisher hat sich das Screening von Transaktionen vor allem an der Betrugsprävention und an den Compliance-Vorgaben der Geldwäschegesetzgebung 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.