KI-getriebener Zahlungsbetrug: Realtime Payments unter Haftungsdruck

Einleitung

Consumer Payments bewegen sich zunehmend in Echtzeit – und Betrug zieht nach. KI‑gestütztes Social Engineering macht Angriffe glaubwürdiger, skalierbarer und günstiger, während Instant Payments den klassischen Schutzfaktor „Zeit“ aus dem System nehmen. Entscheidungen, ob gewarnt, verzögert oder blockiert wird, müssen fallen, bevor Geld das Institut verlässt – nachgelagerte Kontrollen verlieren bei Sekunden‑Finalität einen Großteil ihrer Wirkung.

Mit PSD3/PSR kommt ein zweiter Treiber hinzu: Haftung.

Der europäische Gesetzgeber adressiert ausdrücklich Betrugsformen wie Spoofing und Authorised Push Payment Fraud (APP Fraud), bei denen Angreifer die Identität von Banken oder Zahlungsdienstleistern täuschend echt imitieren. Damit reicht eine formal korrekte starke Kundenauthentifizierung nicht mehr aus, um Haftungsrisiken abzuwehren: Entscheidend wird, unter welchen Umständen die Authentifizierung erfolgte – und ob das Institut angesichts der verfügbaren Signale angemessen interveniert hat.¹

Für Banken, Zahlungsdienstleister und Händler bedeutet das: Betrugsprävention verschiebt sich von einer nachgelagerten Kontrollfunktion in den Kern der Wertschöpfung. Sie wird zur haftungsrelevanten Echtzeit‑Entscheidungsfähigkeit, die 24/7 verfügbar sein muss, systematisch dokumentiert werden kann und über verschiedene Zahlungswege hinweg konsistent agiert.

Die strategische Konsequenz lautet: Realtime Payments ohne Realtime Risk sind kein Innovationsmotor, sondern ein systemisches Risiko. Institute, die jetzt in Echtzeit-Entscheidungsfindung, dokumentierbare Interventionslogik, Portfolio‑Steuerung und railübergreifende Signalorchestrierung investieren, reduzieren nicht nur betrugsbedingte Verluste, sondern stabilisieren Vertrauen, Kundenerlebnis und künftige Haftungspositionen.

Dieser Beitrag beantwortet drei Fragen:

1. Wie verändert KI‑getriebener Zahlungsbetrug die Fraud‑Landschaft?
   Wir zeigen, wie generative KI Social‑Engineering‑Angriffe skaliert, Betrugsszenarien orchestriert und sich insbesondere auf Echtzeit‑Kanäle wie Instant Payments auswirkt.
2. Warum bringen Realtime Payments Zahlungsverkehrsrisiken unter besonderen Entscheidungs‑ und Zeitdruck?
   Wir beleuchten, wie Instant‑Finalität, Multirail‑Setups und APP Fraud klassische Schutzmechanismen entwerten und neue Anforderungen an Architektur und Operating Model erzeugen.
3. Wie machen PSD3/PSR Betrugsprävention zur haftungsrelevanten Kernfunktion?
   Wir analysieren die neue Haftungslogik, leiten Anforderungen an Realtime‑Prävention ab und zeigen, welche Fähigkeiten Banken, PSPs und Akzeptanzstellen künftig benötigen.

KI‑getriebener Zahlungsbetrug: Von der Einzeltransaktion zur orchestrierten Fraud Journey

Historisch war der Faktor Zeit ein Verbündeter der Betrugsprävention. Zahlungsprozesse waren batchfähig, Laufzeiten boten Puffer, Rückabwicklungen waren möglich, und viele Kontrollmechanismen – von Regelwerken bis zu manuellen Reviews – setzten implizit voraus, dass zwischen Autorisierung und wirtschaftlicher Finalität ein relevantes Zeitfenster existiert.

Dieses Paradigma ist im modernen Consumer‑Payment‑Setup obsolet: Instant Payments, Wallets, P2P‑Transfers und Push‑Flows verschieben Finalität in den Sekunden‑Bereich – Entscheidungen über Freigabe, Verzögerung oder Blockierung müssen fallen, bevor die Transaktion unwiderruflich ist.

Parallel hat sich die Angriffsseite professionalisiert. Generative KI ermöglicht Social‑Engineering‑Angriffe, die hochgradig personalisiert, mehrsprachig und kontextsensitiv sind: Phishing‑Mails, Fake‑Bank‑Anrufe oder Messenger‑Chats werden in Varianten getestet, optimiert und skaliert – nicht für Umsatz, sondern für Betrug. KI‑basierte Werkzeuge erzeugen täuschend echte Stimmen, manipulierte Dokumente, synthetische Identitäten und realistisch wirkende Chat‑Dialoge, die in kurzer Zeit in großer Zahl ausgerollt werden können. Damit steigt nicht nur die Zahl der Angriffe, sondern vor allem ihre Qualität und Konversionsrate.

Der Europol‑Spotlight‑Report „Online fraud schemes: a web of deceit“ ordnet diese Szenarien als zentrale Bedrohung ein und hebt insbesondere Investment‑Betrug, Romance Scams, Account Takeover und Money Muling als Kernmuster moderner, arbeitsteilig organisierter Prozessketten hervor.²

Die Betrugslandschaft im Zahlungsverkehr hat sich in den letzten Jahren grundlegend gewandelt. Während klassische Systeme zur Betrugsabwehr lange auf Muster wie ungewöhnliche Beträge, geografische Abweichungen oder Kartenmissbrauch trainiert waren, zeigt die Praxis heute eine deutlich größere Vielfalt und Komplexität. Zahlungsbetrug ist nicht mehr primär in der Transaktion selbst sichtbar, sondern manifestiert sich in unterschiedlichen, oft vorgelagerten Szenarien. Lageberichte von EBA und EZB bestätigen diesen Trend: Der gemeinsame „Report on Payment Fraud 2025“ zeigt, dass sich Betrugsverluste zunehmend von klassischen Kartenbetrugsformen hin zu Social‑Engineering‑ und Überweisungsbetrug – insbesondere im Umfeld von Instant Payments – verlagern.³

In der Folge verlagert sich Zahlungsbetrug weg von der „verdächtigen Einzeltransaktion“ hin zu orchestrierten betrügerischen Prozessketten. Typische Muster sind: Social Engineering Fraud, bei dem Opfer durch gezielte Kommunikation zu Zahlungen oder zur Herausgabe ihrer Authentifikationsmerkmale gedrängt werden; Impersonation‑Angriffe, bei denen sich Täter als Bank, PSP oder Behörde ausgeben; Account Takeover durch Phishing, Credential Stuffing oder Malware; APP Fraud, bei dem Opfer selbst autorisieren; sowie Fake Investment und Romance Scams, die Zahlungsströme über Mules und Krypto‑Brücken verschleiern. In vielen dieser Szenarien ist die eigentliche Zahlung nur noch der Endpunkt einer längeren Manipulationskette – die entscheidenden Weichenstellungen finden davor statt.

Aus Sicht der Institute ist damit klar: Klassische, transaktionszentrierte Fraud‑Systeme, die primär auf ungewöhnliche Beträge, geographische Abweichungen oder Kartenmissbrauch schauen, greifen zu kurz. Wirksame Prävention muss den gesamten Ablauf betrachten – von Identität und Onboarding über Login‑Verhalten, Geräte‑ und Kanalnutzung bis zur Empfängeranlage und Auszahlungslogik.

Genau hier liegt der eigentliche Hebel für KI‑getriebenen Zahlungsbetrug: Angreifer nutzen KI, um diese Abläufe zu gestalten und zu missbrauchen; Institute müssen KI nutzen, um dieselben Abläufe besser zu verstehen, abzusichern und in Echtzeit Entscheidungen treffen zu können.

Diese Szenarien verdeutlichen, dass moderne Betrugsprävention weit über die reine Transaktionsanalyse hinausgehen muss und ein tiefes Verständnis für den gesamten Zahlungsablauf erfordert.

Realtime und Multirail: Wenn Sekunden und Silos zum Risiko werden

Realtime Payments wurden gebaut, um Geld und Bezahlen schneller, bequemer und jederzeit verfügbar zu machen. Für Kundinnen und Kunden bedeutet das Komfort, für Händler Liquiditätsvorteile und bessere Kundenerfahrung. Für Betrüger entsteht damit ein Umfeld, das perfekt auf ihre Geschäftsmodelle zugeschnitten ist: Finalität in Sekunden, 24/7‑Verfügbarkeit und oft noch heterogene Kontrolllogiken über verschiedene Rails hinweg.

Der entscheidende Unterschied zur „alten Welt“ liegt im Zeitfenster. In einem Batch‑Setup konnten Institute verdächtige Zahlungen ex post analysieren, Sammelbuchungen stoppen oder Rückabwicklungen verhandeln. Heute muss eine Entscheidung vor Ausführung fallen – insbesondere bei Instant Payments, P2P‑Transfers und Wallet‑Auszahlungen. Nachgelagerte Kontrollen haben weiterhin ihren Platz für Mustererkennung, Modell‑Tuning und Recovery, sie verlieren aber ihre Schutzwirkung für das einzelne Payment‑Event. Wer in Sekunden final überträgt, verschiebt das Risikofenster vollständig in die vorgelagerten und in den Moment der Autorisierung integrierten Kontrollen.

Hinzu kommt: Moderne Betrugsmodelle nutzen selten nur einen Zahlungsweg. Karten dienen als Einstieg, Account Takeover öffnet den Zugang zum Konto, Instant Payments oder Wallet‑Transfers werden als Cash‑out‑Schiene genutzt. Systemisch anfällig sind vor allem die Übergänge zwischen Rails. Unterschiedliche Risk Engines, fragmentierte Zuständigkeiten und Datensilos erzeugen Brüche, die Angreifer gezielt ausnutzen: Signale aus dem Kartenkanal kommen nicht rechtzeitig in der Account Engine an, Wallet‑Informationen werden nicht mit Kontobewegungen korreliert, verdächtige Muster im E‑Commerce‑Check‑out schlagen sich nicht in Realtime‑Limits nieder. Betrug optimiert sich entlang des schwächsten Übergangs – nicht entlang der stärksten Einzelkontrolle.

Für Institute bedeutet das eine doppelte Herausforderung: Sie müssen einerseits Realtime‑Entscheidungen treffen, die wirtschaftlich tragfähig sind und regulatorisch verteidigt werden können. Andererseits brauchen sie eine Architektur, die Signale aus verschiedenen Rails in Echtzeit zusammenführt und konsistent bewertet. Realtime Risk ist damit kein Feature einzelner Tools, sondern eine Querschnittsfähigkeit der gesamten Payment‑Architektur – von der Ereigniserfassung über Datenintegration und Analytics bis zur dokumentierten Interventionslogik.

Realtime‑Prävention: Von punktuellen Kontrollen zu einer haftungsfähigen Betriebsfunktion

Wenn Betrug sich entlang orchestrierter Prozessketten entwickelt und Zahlungen in Sekunden final sind, reichen punktuelle Kontrollen nicht mehr aus. Eine wirksame Realtime‑Prävention ist kein weiteres Modul im Zahlungsverkehr, sondern eine Betriebsfunktion, die Technik, Prozesse und Steuerung (Governance) zu einem konsistenten System verbindet – mit einem klaren Ziel: Entscheidungen über Eingreifen oder Nicht‑Eingreifen in dem Moment treffen zu können, in dem Haftung entsteht.

Exkurs: Die PSR bündelt mehrere Echtzeitanforderungen – von der Aktualisierung externer Referenz‑Wechselkurse über risikobasiertes Transaktionsmonitoring und Verification of Payee (VoP) bis hin zu schnellen Interventionsentscheidungen – und konfrontiert damit historisch gewachsene Kernbanksysteme mit ihren Latenzgrenzen. Für viele Institute bedeutet das, dass die bisherigen Schnittstellen zwischen Zahlungsverkehr, Fraud‑Systemen und Frontends nicht mehr ausreichen, um regulatorische Latenzvorgaben stabil einzuhalten. Realtime‑Prävention ist damit nicht nur eine Frage intelligenter Modelle, sondern auch eine von Architektur‑Modernisierung und sauber definierten technischen Pfaden für Daten, Entscheidungen und Maßnahmen.^{5, 6}

Vier Designprinzipien sind dabei zentral:

1. Ablaufbasiert statt transaktionszentriert

Prävention beginnt nicht mit der Transaktion, sondern deutlich davor. Relevante Risikosignale entstehen beim Onboarding, im Login‑Verhalten, bei Geräte‑ und Kanalnutzung, bei der Anlage neuer Empfängerbeziehungen und in Refund‑ und Service‑Flows. Institute, die Realtime‑Prävention ernst nehmen, verankern Kontrollen entlang des gesamten Ablaufs vor und während der Zahlung: starke Identitäts‑ und Gerätebindung, konsistente Anomalie-Erkennung in Logins, Plausibilitätsprüfungen bei neuen Empfängern, kontrollierte Rückerstattungsprozesse und klare Regeln für „high‑risk journeys“, etwa bei Investments oder P2P‑Zahlungen.

2. Echtzeit-Entscheidungsfähigkeit statt Batch-Kontrollen

Realtime‑Prävention verlangt, dass Risk‑Entscheidungen in den gleichen Zeitfenstern getroffen werden, in denen Zahlungen geroutet werden – also in Sekunden, nicht über Nacht. Technisch bedeutet das: eventgetriebene Architektur, Low‑Latency‑Scoring, vordefinierte Interventionspfade (Warnung, Verzögerung/Hold, Step‑Up‑Authentifizierung, Limitanpassung) und ein durchgängiges Zusammenspiel aus regelbasierten und KI‑gestützten Modellen.

Beispiele sind Verification of Payee als vorgelagerter Empfänger‑Check, dynamische Limits für neue Empfänger oder Echtzeit‑Warnhinweise bei typischen APP‑Fraud‑Mustern.

3. Dokumentierbare Interventionslogik statt Black-Box-Scoring

Unter PSD3/PSR wird es haftungsrelevant, warum ein Institut nicht interveniert hat. Realtime‑Prävention muss daher so gestaltet sein, dass Entscheidungen erklärbar und nachweisbar bleiben – auch wenn KI‑Modelle und komplexe Regeln im Hintergrund arbeiten.

Praktisch heißt das: Jede Zahlung durchläuft eine nachvollziehbare Entscheidungslogik aus Daten, Regeln, Modellen und möglichen Overrides; diese Logik wird in geeigneter Form protokolliert (Scores, genutzte Features, angewandte Regeln, Gründe für Overrides). So entsteht die Fähigkeit, im Streitfall nicht nur zu zeigen, dass authentifiziert wurde, sondern auch, dass Monitoring und Intervention gemessen an den verfügbaren Signalen angemessen waren.

4. Integriert und lernfähig statt fragmentiert und statisch

Wirksame Prävention ist keine Summe isolierter Systeme. Sie erfordert eine einheitliche Fraud Engine, die Daten aus verschiedenen Quellen (Kunden‑, Transaktions‑, Kanal‑ und Drittdaten) verbindet, Regeln und Modelle über Rails hinweg steuert und Alerts in einen integrierten Case‑ und Investigation‑Prozess überführt. Ergänzend dazu braucht es eine Steuerungsstruktur, etwa in Form eines AI/Fraud‑Competence‑Centers, die Modell‑Lebenszyklen steuert, Bias‑ und Robustheitsprüfungen durchführt, regulatorische Anforderungen an Erklärbarkeit (Explainability) erfüllt und sicherstellt, dass operative Erfahrungen (True Positives, False Positives, Near Misses) wieder in Regeln und Modelle zurückfließen.

In dieser Logik wird Realtime‑Prävention zu einer Kernfähigkeit, die ähnlich wie Kreditrisiko‑Steuerung oder Liquiditätsmanagement betrachtet werden muss: mit klarer Verantwortung, definierten KPIs, investitionsfähiger Architektur und einem Operating Model, das 24/7-tragfähig ist. Institute, die diese Transformation rechtzeitig vollziehen, begegnen KI‑getriebenem Zahlungsbetrug nicht nur mit besseren Modellen, sondern mit einer Struktur, die Geschwindigkeit, Komplexität und Haftungsdruck gleichermaßen adressiert.

PSD3/PSR als Game Changer: Haftung im Realtime‑Setting

Von SCA‑Schutz zur kontextabhängigen Haftung

Bislang beruhte ein Großteil der Haftungslogik im Zahlungsverkehr auf einem einfachen Grundsatz: Wenn eine Zahlung korrekt authentifiziert wurde – idealerweise mit starker Kundenauthentifizierung (SCA) – war der Zahlungsdienstleister in vielen Konstellationen weitgehend aus der Haftung. Das Risiko autorisierter, aber betrügerisch veranlasster Zahlungen lag überwiegend beim Kunden, insbesondere bei Social‑Engineering‑ und APP‑Fraud‑Konstellationen.

PSD3/PSR stellt diese Logik auf den Prüfstand. Politische Einigungen und Entwürfe sehen vor, dass Zahlungsdienstleister künftig auch für autorisierte Zahlungen haften können, wenn diese auf Spoofing‑ oder Impersonation‑Szenarien beruhen, in denen Täter die Identität von Banken oder Behörden täuschend echt imitieren. Entscheidend ist damit nicht mehr allein, ob eine Zahlung formal korrekt authentifiziert wurde, sondern unter welchen Umständen die Autorisierung zustande kam – und ob der Zahlungsdienstleister angesichts der verfügbaren Informationen angemessen gewarnt, verzögert oder blockiert hat.

Wie konkret diese Verschiebung ausfällt, zeigt der Blogbeitrag: PSD3 und PSR auf der Zielgeraden: Jetzt ist es Zeit, sich vorzubereiten.⁵

Dort werden drei Säulen der PSR‑Betrugsprävention skizziert, die den regulatorischen Anspruch an Banken und Zahlungsdienstleister greifbar machen:

Erstens eine deutlich erweiterte interne Prävention, inklusive risikobasiertem Transaktionsmonitoring in Echtzeit, ausgeweitetem Verification of Payee für Überweisungen in sämtlichen EU‑Währungen sowie der Pflicht, verdächtige Zahlungen bei objektiv begründetem Betrugsverdacht aktiv abzulehnen – andernfalls haftet der Zahlungsdienstleister unmittelbar für den Schaden.

Zweitens eine kollaborative Betrugsbekämpfung, bei der Institute betrugsbezogene Daten über dedizierte Plattformen austauschen, flankiert von Datenschutz‑Folgenabschätzungen und strengen Speicherfristen.

Drittens eine Stärkung der Kundenschnittstelle, etwa durch erweiterte Möglichkeiten zur Limit‑Steuerung und unmittelbaren Sperrung von Zahlungsinstrumenten, kombiniert mit expliziten Interventionsrechten der Institute, Zahlungen unter bestimmten Voraussetzungen proaktiv zu stoppen.

Diese drei Säulen übersetzen sich direkt in Anforderungen an Realtime‑Prävention: Echtzeit‑Monitoring und VoP als vorgelagerte Kontrollen, ein belastbarer Daten‑ und Signalverbund zwischen Instituten und eine Kundenschnittstelle, die bewusst gestaltete Friktion und Interventionsrechte als Teil der Schutzlogik versteht.

Beweislast und Dokumentierbarkeit von Nich-Intervention

Mit dieser Verschiebung ändert sich auch die Beweis‑ und Nachweissituation. Zahlungsdienstleister müssen künftig nicht nur belegen können, dass Authentifizierungsprozesse technisch korrekt durchlaufen wurden, sondern auch, dass Überwachung und Intervention „angemessen“ waren – ein Begriff, der sich zunehmend an Realtime‑Fähigkeiten orientiert.

Damit wird ein Aspekt zentral, der in vielen Instituten bislang eher implizit war: die Dokumentierbarkeit von Nicht‑Intervention. Es reicht unter PSD3/PSR nicht mehr, ein Scoring‑System und eine SCA‑Strecke zu betreiben. Institute müssen im Streitfall erklären können, warum bei einer konkreten Zahlung keine Warnung, keine Verzögerung und kein Block ausgelöst wurde, obwohl bestimmte Muster – etwa neue Empfänger, ungewöhnliche Betrags‑/Frequenzkombinationen oder bekannte Social‑Engineering‑Schemata – vorlagen.

Für das Operating Model bedeutet das: Realtime Decisioning, Logging von Scores und Regeln, Nachvollziehbarkeit von Overrides und klare Kriterien für „grobe Fahrlässigkeit“ werden zu haftungsrelevanten Fähigkeiten, nicht zu Compliance‑Nice‑to‑haves.

Kollaborative Betrugsbekämpfung als regulatorische Erwartung

PSD3/PSR bleibt nicht bei individueller Haftung stehen, sondern stärkt auch die kollaborative Dimension der Betrugsbekämpfung. Neben Maßnahmen wie Verification of Payee und stärkeren Informationspflichten gegenüber Kunden zeichnen sich Regime ab, die einen systematischeren Austausch von Fraud‑Daten, Warnhinweisen und Mustern zwischen Zahlungsdienstleistern, Infrastrukturen und gegebenenfalls zentralen Stellen erwarten – natürlich im Rahmen datenschutz‑ und wettbewerbsrechtlicher Grenzen.

Für Institute bedeutet das zweierlei: Zum einen steigen die Anforderungen an die eigene Realtime‑Prävention, zum anderen wird die Fähigkeit wichtig, externe Signale – etwa zu Money‑Mule‑Konten, aktuellen Social‑Engineering‑Mustern oder kompromittierten Empfängern – in die eigene Entscheidungslogik einzubetten.

Eine Realtime‑Prävention, die PSD3/PSR‑fähig sein will, ist daher nicht nur technisch robust und gut dokumentiert, sondern auch vernetzbar: Sie kann externe Daten einspeisen, interne Befunde in geeigneter Form teilen und so zur kollektiven Risikoreduktion beitragen.

Konsequenzen für Banken, PSPs und Akzeptanzstellen

Drei Rollen, ein gemeinsames Haftungsproblem

Mit der Kombination aus Realtime Payments, KI-getriebenem Betrug und der neuen Haftungslogik unter PSD3 verändert sich die Rolle aller Beteiligten im Zahlungsverkehr grundlegend. Betrugsprävention ist nicht länger eine isolierte Aufgabe einzelner Akteure, sondern ein durchgängiges Systemrisiko, das entlang der gesamten Payment-Kette wirkt. Die Deutsche Kreditwirtschaft (DK) weist im Kontext der PSR‑Einigung explizit darauf hin, dass die EU‑Maßnahmen vor allem Betrugsformen adressieren, bei denen Kundinnen und Kunden über soziale Medien und digitale Kommunikationskanäle zu Zahlungen oder Preisgabe ihrer Identifikationsmerkmale verleitet werden – also genau jene Social‑Engineering‑ und APP‑Fraud‑Szenarien, die wir hier betrachten.⁴

Was sich dabei unterscheidet, sind die Hebel, die den einzelnen Rollen zur Verfügung stehen – und die Punkte, an denen Verantwortung, Kosten und Risiko wirksam werden.

Banken: Entscheidungsinstanz in Echtzeit

Für Banken wandert Betrugsprävention endgültig aus der „Operations‑Ecke“ in den Kern der Wertschöpfung. Wo Institute bislang primär Zahlungen verarbeitet haben, müssen sie künftig Entscheidungen verantworten – inklusive begründeter Nicht‑Intervention – und diese Entscheidungen unter PSD3/PSR auch verteidigen können.

Konkret heißt das:

• Realtime Decisioning statt Alert: Banken benötigen eine Architektur, die es ermöglicht, in Sekunden über Warnung, Verzögerung/Hold, Step‑Up oder Block zu entscheiden – mit konsistenten Regeln, Modellen und Eskalationspfaden, die 24/7 funktionieren.
• Dokumentierbare Entscheidungslogik: Jede relevante Zahlung muss durch eine nachvollziehbare Kette aus Daten, Scores, Regeln und möglichen Overrides laufen. Die Fähigkeit, im Nachhinein erklären zu können, warum nicht interveniert wurde, wird haftungsrelevant.
• Kundendialog als Teil der Kontrolle: Gezielte Friktion, zum Beispiel Warnhinweise bei typischen APP‑Mustern, Step‑Up‑Checks bei neuen Empfängern, wird vom UX‑„Störfaktor“ zur regulativ legitimierten Schutzmaßnahme. Banken müssen definieren, wann sie Kunden aktiv in die Betrugsvermeidung einbinden.

PSPs und Acquirer: Risk‑Intelligenz als Produktkern

PSPs und Acquirer sitzen im Kreuzfeuer aus Volumen, Performance und Händlerinteressen. Unter PSD3/PSR ist Payment Processing ohne integrierte Risk‑Intelligenz kein neutrales Infrastruktur‑Business mehr, sondern ein potenzieller Haftungstreiber – für sie selbst und für ihre Kunden.

Konkret heißt das:

• Architektur als Hebel. Fraud‑Kontrollen müssen in dieselben Latenzfenster integriert werden wie Routing, Autorisierung und Settlement. Low‑Latency‑Scoring, Realtime Signals und deterministische Degradationspfade gehören in die Plattform – nicht in nachgelagerte Batch.
• Portfoliosteuerung statt Quersubventionierung. PSPs müssen Händler‑Risiko aktiv steuern; unzureichend gesicherte Prozessketten (Login, Checkout, Refund) erhöhen das Gesamtrisiko. Ohne Steuerung zahlen risikoarme Händler für die Fehler risikoreicher. Differenzierte Limits, Pricing und Mindeststandards werden zum Muss.
• Multirail‑Orchestrierung mit Fraud. Wer mehrere Rails (Karte, Konto, Wallet, BNPL, Krypto) anbietet, braucht ein railübergreifendes Fraud‑ und Risk‑Monitoring. Signale dürfen nicht an Rail‑Grenzen hängen bleiben – sonst entstehen genau die Lücken, die Betrüger ausnutzen.

Die Konsequenz ist ein neues Marktversprechen: Nicht „Payments as fast as possible“, sondern „Payments with accountable risk“ wird zum Differenzierungsfaktor.

Praktische Implikation: PSPs und Acquirer müssen Risk Controls als Produktbestandteil denken: SLA-fähige Checks, klar definierte Interventionspunkte, und eine transparente Händler-Governance (inklusive Mindeststandards). Die PSR-Diskussion um risikobasierte Transaktionsüberwachung und Fraud-Datenaustausch unterstreicht genau diese Richtung.

Akzeptanzstellen: Customer Journey als Risikofläche

Händler und andere Akzeptanzstellen tauchen in Regulierungstexten oft eher am Rand auf, prägen aber das Risikoprofil wesentlich: Viele Betrugsmodelle setzen weit vor der eigentlichen Zahlung an – bei Registrierung, Login, Warenkorb, Kommunikation und Refund‑Prozessen.

Konkret heißt das:

• Prävention vor der Zahlung: Schwache Login‑Flows, fehlende Gerätebindung, unklare Empfängerinformationen oder leicht ausnutzbare Promotion‑/Refund‑Mechanismen erhöhen das Fraud‑Risiko der gesamten Kette. Wer nur am Checkout prüft, erkennt Betrug meist zu spät.
• Refund‑ und Service‑Flows als Teil der Angriffsfläche für Betrug: Großzügige, schlecht gesicherte Rückerstattungen oder Serviceprozesse können sekundären Betrug und Money‑Mule‑Strukturen begünstigen – mit Folgen für Limits, Pricing und Kontrollen durch Banken und PSPs.
• Gezielte Friktion als Business: Step‑Ups bei riskanten Zahlungen, gut gestaltete Warnhinweise und klare Empfängerinformationen sind nicht nur „Compliance‑Pflicht“, sondern helfen, Chargebacks, Disputes und Vertrauensverlust zu reduzieren. Betrugsprävention wird damit Teil von Revenue‑Management und Kundenbindung.

Die Konsequenz ist unbequem – aber strategisch wichtig: Betrugsprävention wird für Händler ein Element von Revenue Management und Kundenbindung, nicht nur ein Kostenfaktor.

Fazit: Drei Kräfte, ein Paradigmenwechsel

Generative KI macht Betrug nicht nur häufiger, sondern vor allem besser: Social‑Engineering‑Angriffe werden personalisierter, glaubwürdiger und skalierbarer – und treffen auf Zahlungssysteme, in denen Sekunden über Finalität entscheiden.

Realtime Payments entwerten klassische Schutzmechanismen, weil nachgelagerte Kontrollen kaum noch Eingriffszeit haben und Betrug sich entlang orchestrierter Prozessketten über mehrere Rails entwickelt.

PSD3/PSR verschiebt zugleich die Haftung dorthin, wo diese Entscheidungen fallen: zu Banken, Zahlungsdienstleistern und – mittelbar – Akzeptanzstellen, die erklären können müssen, warum sie in einem konkreten Fall gewarnt, verzögert, blockiert oder eben nicht interveniert haben.

In dieser Konstellation wird Betrugsprävention von der nachgelagerten Kontrollinstanz zur haftungsrelevanten Kernfunktion der Zahlungsverkehrsarchitektur. Oder anders formuliert: Wer Realtime Payments anbietet, ohne Realtime Risk als Betriebsdisziplin zu beherrschen, skaliert nicht Innovation – sondern systemische Risiken.