Erkennung von APP-Betrug (Authorised Push Payment) & Geldkurier-Konten (Money Mules)

Bei einem APP-Betrug genehmigt das Opfer die Überweisung selbst, nachdem es von einem falschen Bankmitarbeiter, einem Anlagevermittler, einem Liebesbetrüger oder einem Rechnungs-Imitator manipuliert wurde. Modelle gegen Kartenbetrug (ANOM-001) sehen einen legitimen Kunden auf einem legitimen Gerät und schlagen nicht an. Banken kombinieren deshalb Sitzungs- und Verhaltenssignale auf der Senderseite mit der Erkennung von Geldkurier-Konten auf der Empfängerseite, dazu eine Prüfung von Name und IBAN sowie bankübergreifende Informationen. Der Nutzen: weniger erfolgreiche Betrugsfälle, schnellere Rückholung von Geldern und geringere Erstattungskosten, ohne zu viele echte Zahlungen zu blockieren.

Problem & Nutzen

• Wer: Privatkundenbanken, Neobanken, Zahlungs- und E-Geld-Institute sowie zunehmend Telekommunikationsanbieter und Plattformen, die Banken Signale liefern. Opfer sind meist Privatkunden, aber kleine Unternehmen leiden unter Rechnungs- und CEO-Betrug durch Vortäuschen einer falschen Identität.
• Heute: Regeln für Beträge und neue Zahlungsempfänger, starre Warntexte, manuelle Rückrufe und Geldkurier-Konten, die erst nach einer Beschwerde eines Opfers auffallen. Bei Sofortzahlungen bleiben Minuten, nicht Tage, um einzugreifen.
• Warum KI hilft: Das Signal steckt im Verhalten (ein Kunde im laufenden Telefonat mit Fernzugriffssoftware, der zögert und einen Empfänger eintippt, den er nie zuvor genutzt hat) und in Netzwerken (ein neues Konto erhält viele erstmalige Zahlungen und leitet sie innerhalb von Minuten weiter). Überwachte Modelle, Graphanalyse und Anomalieerkennung bewältigen das; LLMs helfen bei der Klassifikation von Betrugsnarrativen, bei Fallnotizen der Bearbeiter und bei Warnungen an Kunden.
• Regulatorischer Treiber (warum das jetzt ein Thema für den Vorstand ist): Im Vereinigten Königreich verlangt die Payment Systems Regulator, dass sendende und empfangende Institute APP-Opfer erstatten, im Verhältnis 50:50 zwischen ihnen, mit einer Obergrenze je Anspruch und einer kurzen Erstattungsfrist, in Kraft seit Oktober 2024 [1]. In der EU verpflichtet die Verordnung über Sofortzahlungen (EU) 2024/886 die Zahlungsdienstleister, im Euroraum ab Oktober 2025 eine Prüfung von Empfängername und IBAN (Verification of Payee) anzubieten, mit späteren Terminen für Nicht-Euro-Staaten [2]. Das überarbeitete EU-Zahlungsdienstepaket (PSD3/PSR) wurde Ende 2025 politisch vereinbart; der Standpunkt des Rates in erster Lesung wurde Ende Okt. 2026 zur Annahme vorgelegt [7], die zweite Lesung im Parlament und die Veröffentlichung im Amtsblatt stehen noch aus. Es soll voraussichtlich eine Haftung bei Vortäuschen von Bankmitarbeitern sowie einen stärkeren Austausch von Betrugsdaten ergänzen; prüfen Sie den endgültig veröffentlichten Text und die Anwendungstermine, bevor Sie planen [3].
• Nutzenzahlen: Anbieter veröffentlichen Rückgänge bei Betrugsschäden, doch diese sind selbst berichtet und hängen von Ausgangslage und Reibung ab. Übernehmen Sie sie nicht ohne Rückvergleich (Backtest) auf Ihren eigenen Daten. Der öffentliche Datensatz Bank Account Fraud (NeurIPS 2022) erlaubt es, Methoden bei festen Falsch-Positiv-Raten zu vergleichen [4].

Varianten

• Betrugserkennung auf der Senderseite: Vortäuschen einer Identität (Bank, Polizei, technischer Support), Anlage- und Liebesbetrug, Rechnungsumleitung, „Sicheres-Konto“-Betrug.
• Geldkurier-Erkennung auf der Empfängerseite: Konten, die zur Kontoeröffnung missbraucht werden (synthetische oder gestohlene Identitäten, siehe ANOM-014), angeworbene echte Kunden („Money-Mule-Anwerbung“ über Stellenanzeigen und soziale Medien) sowie vermietete oder kompromittierte Konten.
• Firmenzahlungen: Erkennung von Rechnungsbetrug und Änderungen der Bankverbindung von Lieferanten im Firmenkundengeschäft (überschneidet sich mit ANOM-009).
• Konsortien und bankübergreifende Informationen: geteilte Listen von Geldkurier-Konten und der Austausch von Betrugsmeldungen zwischen Instituten, im Rahmen nationaler Rechtsvorgaben.
• Signale von Telekommunikation und Plattformen: Daten zu Betrugsanrufen und -nachrichten (ANOM-025, ANOM-024), die Banken als Risikosignale geliefert werden.
• Privatnutzung: keine direkte; Endkunden erleben dies als Warnungen, Zahlungsreibung und Rückrufe. Schutzwerkzeuge für Verbraucher behandelt ANOM-025.
• Hier nicht behandelt: nicht autorisierter Karten- oder Kontoübernahme-Betrug (ANOM-001), Geldwäsche-Transaktionsüberwachung und Verdachtsmeldungen (ANOM-002), Krypto-Flüsse (ANOM-023).

So funktioniert es

1. payment instruction (instant / credit transfer) + session telemetry
2. feature service (payer history, payee risk, device & behaviour, call/remote-access flags, VoP result)
3. real-time scoring (<~100 ms): supervised model + anomaly model + graph features (mule proximity)
4. decision: release / dynamic warning / step-up / hold for agent call-back
5. LLM-assisted agent console: scam-type summary, suggested script, case note
6. outcome labels (confirmed scam, customer abort, false alarm)
7. retraining receiving side (parallel): inbound-flow monitoring
8. mule score
9. restrict / review / report
10. recovery request to the beneficiary bank, case file, reimbursement evidence, AML hand-over

• Modelle: Gradient-Boosting-Bäume für die Bewertung jeder Zahlung; Sequenz- und Verhaltensmodelle auf Sitzungsdaten; Graphmerkmale oder GNNs auf dem Netzwerk von Zahler und Empfänger (neues Konto, das von vielen nicht verbundenen Zahlern Geld erhält und es innerhalb von Minuten weiterleitet); unüberwachte Modelle für neue Typologien.
• LLMs werden außerhalb des Millisekundenpfads eingesetzt: Klassifikation freier Verwendungszwecke und Bearbeiternotizen in Betrugstypologien, Zusammenfassung von Fällen und Entwurf zugeschnittener Warntexte. Sie treffen nicht die Entscheidung über Freigabe oder Rückhaltung.
• Mensch-in-der-Schleife (Human-in-the-Loop): Betrugsbearbeiter rufen Kunden bei zurückgehaltenen Zahlungen an, entscheiden über die Einschränkung von Konten bei Verdacht auf Geldkuriere und genehmigen Meldungen. Nach einer wirksamen Warnung behalten die Kunden das letzte Wort.

Datenaufbereitung

Benötigte Daten: Zahlungsaufträge und -historie, Stammdaten zu Empfängern und Konten, Sitzungs- und Gerätetelemetrie aus Online- und Mobile-Banking, Kontakte im Kundenservice, Ergebnisse der Empfängerprüfung (Verification of Payee) und vor allem bestätigte Ergebnisse (Betrug, Geldkurier, Fehlalarm). Sie liegen typischerweise im Kernbankensystem, im Backend des Online-Bankings, in einem Fallmanagement-Werkzeug und im Kontaktcenter, mit einer langen Verzögerung, bis Opfer einen Betrug melden.

Typische Lücken: verspätete und unvollständige Labels, als Freitext abgelegte Betrugsfälle, abweichende Kennungen über Kanäle hinweg, Telemetrie, die nicht gespeichert oder nicht mit Zahlungen verknüpfbar ist, sowie strenge Zugriffsrechte auf Transaktionsdaten.

Schritte der Aufbereitung: einen einheitlichen Ereignisstrom und Feature Store aufbauen, geschlüsselt nach Kunde, Gerät und Empfänger (siehe PREP-005), Fallergebnisse mit der ursprünglichen Zahlung verknüpfen (PREP-020), freie Fallnotizen mit einem LLM in Betrugstypologien klassifizieren (PREP-019), Label-Zeitfenster festlegen, die Meldeverzögerungen berücksichtigen, und mit Betrugsexperten einen Evaluationsdatensatz erstellen (PREP-018). Daten für die Modellentwicklung pseudonymisieren (PREP-022) sowie Zweck und Rechtsgrundlage prüfen (PREP-025). Werkzeuge: Kafka oder Flink, ein Feature Store wie Feast, dbt, PostgreSQL. Rechnen Sie mit 50 bis 60 Prozent des Aufwands für Dateningenieurwesen und Labeling; GUIDE-003 bietet eine Bereitschaftsprüfung.

Umsetzungswege

Welcher Weg für wen

• enterprise (Banken, Zahlungsinstitute): A, weil ausgereifte Anbieter Verhaltensbiometrie und Konsortial- oder Geldkurier-Netzwerkdaten mitbringen, die eine einzelne Bank nicht nachbilden kann; große Banken mit starkem Data-Science-Team können Komponenten aus B oder C ergänzen.
• developer: B, weil Cloud-Streaming- und ML-Dienste in EU-Regionen den Bau eigener Merkmale und Bewertungen rund um zugekaufte oder eigene Daten erlauben.

Weg A — Kaufen (Standardsoftware)

Beste Standardwahl für Banken und Zahlungsinstitute: Scoring-Engines mit Verhaltensbiometrie und Konsortialdaten. Typische Anbieter: BioCatch (Verhaltensanalyse, für Betrugs- und Geldkurier-Erkennung genutzt), Featurespace (ARIC Risk Hub, Teil von Visa), NICE Actimize, Feedzai, SAS, Mastercard (Consumer Fraud Risk, Dienste im Stil von Scam Protect), Cleafy (Italien, EU: Erkennung von Betrug und Fernzugriff), Hawk (Deutschland, EU: KI-basierte Betrugs- und Geldwäscheüberwachung), Nexi / Nets für in Acquirer und Prozessoren eingebettete Dienste. Im Vereinigten Königreich sind zudem die Confirmation of Payee von Pay.UK und bankeigene Geldkurier-Informationen im Einsatz. Prüfen Sie, wo der Anbieter Daten verarbeitet (EU-Region, Unterauftragnehmer) und ob sich das Modell gegenüber Ihrer Aufsicht erklären lässt. Kleine Zahlungsdienstleister kaufen meist einen verwalteten Dienst, statt selbst zu bauen.

Weg B — Auf Cloud-KI-Diensten aufbauen

Nutzen Sie eine Cloud-ML-Plattform in einer EU-Region (AWS, Azure oder Google Cloud in EU-Regionen oder EU-Anbieter wie STACKIT oder OVHcloud) für Feature Store, Streaming (Kafka/Flink oder Cloud-Entsprechungen) und Modellbereitstellung. LLM-APIs mit EU-Datenresidenz (zum Beispiel Mistral, Azure OpenAI EU, Google Vertex AI, Anthropic über EU-fähige Cloud-Anbieter) decken Fallzusammenfassungen, Typologie-Klassifikation von Zahlungstexten und Entwürfe für Kundenwarnungen ab. Belassen Sie den Echtzeit-Bewertungspfad bei eigenen Modellen; nutzen Sie APIs nur für nicht latenzkritische Textarbeit, mit Maskierung personenbezogener Daten und einem Auftragsverarbeitungsvertrag (AVV). Binden Sie Ihren Zahlungs-Hub, das Online-Banking-Frontend (für dynamische Warnungen) und das Fallmanagement an.

Weg C — Selbst betreiben (Open Source)

Stack: Kafka/Flink für Datenströme, XGBoost/LightGBM/scikit-learn, PyTorch Geometric oder DGL für Graphmodelle, Neo4j oder ein anderer Graphspeicher für das Empfängernetzwerk, ein Feature Store wie Feast. Open-Source-Entscheidungs-Engines wie Marble (Frankreich) und Jube gibt es für Regeln und Fallmanagement; prüfen Sie Reife und Support, bevor Sie sie als primäre Kontrolle einsetzen. Für Textaufgaben betreiben Sie ein Open-Weight-Modell wie Qwen3, Mistral oder Llama-Varianten selbst mit vLLM. Hardware: HW2 genügt für das Scoring und ein quantisiertes LLM mit ca. 30 Mrd. Parametern; das Training von GNNs auf einem großen nationalen Zahlungsgraphen braucht HW3. Teuer ist der Betrieb: 24/7-Pipelines, Latenz-SLOs, Modell-Governance und Prüfpfade.

Weg D — Eigenes Training

Lohnend für größere Institute und Konsortien: auf eigenen Labels bestätigter Betrugs- und Geldkurier-Fälle trainieren, Sequenzmodelle auf Sitzungstelemetrie feintunen und institutsübergreifende Graphmodelle bauen. Benötigt mehrere Jahre gelabelter Ergebnisse (Labels kommen verzögert: Opfer melden Tage später) und sorgfältigen Umgang mit Label-Verzerrung. Datenschutzwahrende Zusammenarbeit (föderiertes Lernen, datenschutzfördernde Technologien, beaufsichtigte Datenaustauschmodelle) ist aktiv, aber jedes Modell braucht eine Rechtsgrundlage nach DSGVO und Bankgeheimnis.

Stand der Technik (2026)

• Verhaltensanalyse plus Empfängerrisiko ist der etablierte Kern: Sitzungssignale (aktives Telefonat, Fernzugriffswerkzeuge, Zögern wie unter Anleitung) kombiniert mit Geldkurier-Werten der Empfängerseite. Merkmalsqualität und Latenz zählen mehr als Modellkomplexität.
• Prüfung von Name und IBAN (Verification of Payee nach der Verordnung über Sofortzahlungen, Confirmation of Payee im Vereinigten Königreich) beseitigt eine große Klasse von fehlgeleiteten Zahlungen und Rechnungsumleitungsbetrug, nicht aber Betrug, bei dem dem Opfer der richtige Name genannt wird [2].
• Netzwerk- und Konsortialsichten: Graphbasierte Geldkurier-Erkennung und der Austausch von Geldkurier-Indikatoren zwischen Banken sind der wichtigste neue Hebel; das Vereinigte Königreich und mehrere EU-Märkte bauen gemeinsame Infrastruktur auf, und die EU-Reform des Zahlungsverkehrs soll eine Rechtsgrundlage für den Austausch von Betrugsdaten schaffen [3].
• Dynamische Reibung: Gezielte, betrugsspezifische Warnungen und kurze Rückruf-Rückhaltungen wirken besser als allgemeine Warnungen; per A/B-Test messen.
• LLMs in der Schleife: Klassifikation von Betrugsnarrativen, Unterstützung der Bearbeiter und Erzeugung von Warnungen sind bei führenden Banken im Produktivbetrieb. Für die Freigabeentscheidung vertraut man ihnen nicht.
• Gegner passen sich an: Deepfake-Stimmen und KI-geschriebene Skripte steigern die Qualität des Social Engineering, und Kriminelle weichen auf frische Geldkurier-Konten und Sofortzahlungsschienen aus. Die Werte verschlechtern sich schnell; planen Sie wöchentliche Überwachung und schnelles Nachtrainieren.
• Grenzen und Fehlerbilder: verzögerte und unvollständige Labels; Falsch-Positive, die echte hohe Zahlungen blockieren (Hauskauf, Fahrzeugverkauf); Umgang mit schutzbedürftigen Kunden; Datenschutz bei Verhaltensdaten; Kaltstart bei neuen Konten.

Gemeinsame Bausteine & Kombinationen

• Gleiche Bausteine (tabular-ml, graph-ml, anomaly-detection, streaming): ANOM-001 (Karten- und nicht autorisierter Zahlungsbetrug, gleicher Feature Store und gleicher Scoring-Dienst), ANOM-002 (Geldwäscheüberwachung: Geldkurier-Funde speisen Verdachtsmeldungen und umgekehrt), ANOM-023 (Krypto-Off-Ramp-Flüsse), ANOM-004 (gefälschte Konten und Bots auf Plattformen, Geräte- und Verhaltensmerkmale).
• Vorgelagerte Signale: ANOM-014 (Identitätsprüfungen beim Onboarding fangen Geldkurier-Konten bei der Eröffnung ab), ANOM-025 und ANOM-024 (Signale zu Betrugsanrufen und Telekommunikationsbetrug), ANOM-016 (Screening-Treffer als zusätzliche Risikomerkmale).
• Gemeinsame Infrastruktur: Eine Streaming-Plattform, ein Feature Store, eine Graphdatenbank und eine Fallmanagement-/Workflow-Engine können alle Betrugs- und Geldwäsche-Warteschlangen bedienen; ein On-Premises-LLM (HW2/HW3) bedient Fallzusammenfassungen über alle hinweg.
• Kundenseitig: Warntexte und Rückrufskripte können den mehrsprachigen Generierungs-Stack aus Anwendungsfällen für den Kundenservice wiederverwenden.

Aufwand, Kosten & Kennzahlen

• Weg A: etwa 6–12 Monate einschließlich Datenintegration, Warnabläufen im Frontend, Bearbeiterprozessen und regulatorischer Validierung; die Lizenzen skalieren mit dem Zahlungsvolumen.
• Weg B: 6–12 Monate für einen Aufbau mit einem erfahrenen Team für Betrugsdaten; Kostentreiber sind Dateningenieurwesen, Latenz-Engineering und Modell-Governance, nicht die API-Gebühren.
• Weg C/D: mehrjähriges Programm mit eigenem Team für Data Science, Plattform und Modellrisiko.
• Kennzahlen: Betrugsschaden je Million Zahlungen (Basispunkte des Volumens), Erkennungsrate bei fester Falsch-Positiv-Rate, Anteil der zurückgehaltenen Zahlungen, die echt waren, Abbruchquote der Kunden nach Warnungen, Zeit bis zur Einschränkung eines Geldkurier-Kontos, zurückgeholte Gelder, Erstattungskosten je Fall, vor der ersten Opferzahlung erkannte Geldkurier-Konten, Bearbeitungszeit der Bearbeiter, Modelldrift und Fairness über Kundengruppen.

Menschen & Veränderung

Beziehen Sie zuerst die Leitung und den Leiter der Betrugsabwehr ein, dann IT-Sicherheit, die Datenschutzbeauftragte bzw. den Datenschutzbeauftragten, Compliance und die Modellrisiko-Funktion. Betrugsbearbeiter, die Kunden bei zurückgehaltenen Zahlungen anrufen, sind die wichtigsten Anwender und sollten von Anfang an an Entwurf und Tests teilnehmen. Warntexte für Kunden brauchen Beiträge von Recht und Kundenservice.

Betriebsrat: ja, in der Praxis, weil Bearbeiterkonsolen und Fallwerkzeuge individuelle Bearbeitungszeiten und Entscheidungen protokollieren und objektiv zur Leistungskontrolle geeignet sind (§87 Abs. 1 Nr. 6 BetrVG); informieren Sie ihn früh nach §90 Abs. 1 Nr. 3 und erwägen Sie einen Sachverständigen nach §80 Abs. 3. Datenschutz: Eine Datenschutz-Folgenabschätzung (DSFA) ist wahrscheinlich nötig (systematische Bewertung von Kunden in großem Umfang), mit Auftragsverarbeitungsverträgen (AVV) für jeden Anbieter (Art. 28 DSGVO) und Einbindung der Datenschutzbeauftragten; die Kunden behalten nach einer wirksamen Warnung das letzte Wort, also keine rein automatisierten Entscheidungen mit rechtlicher Wirkung.

Maßnahmen zur KI-Kompetenz (AI Act Art. 4) sollten Bearbeiter und Analysten beim Lesen von Risikowerten und Begründungscodes unterstützen. Beginnen Sie mit einem Pilot in einem Kanal oder Kundensegment im Schattenmodus und aktivieren Sie dann die Warnungen. Typische Bedenken sind Kundenreibung durch Falsch-Positive und die Überwachung der Bearbeiter; begegnen Sie ihnen mit Kennzahlen zu den Falsch-Positiv-Raten und einer schriftlichen Vereinbarung, dass Messwerte nicht zur individuellen Leistungsbewertung verwendet werden. Siehe GUIDE-004, GUIDE-005 und GUIDE-010.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): Die Hochrisiko-Kategorie Anhang III Nr. 5 Buchst. b betrifft Kreditwürdigkeit und Bonitätsbewertung natürlicher Personen, schließt aber KI-Systeme zur Erkennung von Finanzbetrug ausdrücklich aus [5]. Typische APP-/Geldkurier-Erkennung ist daher kein Hochrisiko-System; die Einstufung lautet minimal. Sie kann zu Hochrisiko werden, wenn dieselben Werte für Kredit- oder Grundversorgungsentscheidungen wiederverwendet oder von Strafverfolgungsbehörden angewendet werden. Art. 5 Abs. 1 Buchst. d verbietet, das Risiko einer Straffälligkeit von Personen allein auf Basis von Profiling zu bewerten; die Bewertung von Geldkurier-Konten muss auf objektivem Kontoverhalten beruhen und vor einer Kontoschließung von Menschen geprüft werden.
• DSGVO: Rechtsgrundlage ist typischerweise berechtigtes Interesse und rechtliche Verpflichtung zur Betrugsprävention; Verhaltensbiometrie kann Art. 9 berühren, wenn sie eine Person identifiziert, daher DSFA durchführen und Daten minimieren. Art. 22 begrenzt ausschließlich automatisierte Entscheidungen mit erheblicher Wirkung: Kontoschließung oder lange Sperren brauchen menschliche Prüfung und eine Möglichkeit zum Widerspruch. Der Austausch von Geldkurier-Daten zwischen Banken braucht eine ausdrückliche Rechtsgrundlage; beachten Sie das Verbot der Informationsweitergabe (Tipping-off) im Geldwäscherecht.
• Zahlungsverkehrs- und Branchenrecht: PSD2-starke Kundenauthentifizierung, die Verordnung über Sofortzahlungen (VoP, Pflichten zum Betrugsscreening) [2], die kommende PSD3/PSR [3], die Erstattungsregeln der britischen PSR [1], DORA (IKT-Risiko, Drittparteien), AMLR (EU) 2024/1624 für Meldepflichten sowie BaFin-/EBA-Leitlinien zu Betrugsmeldung und Modellrisiko.
• Risiken und Gegenmaßnahmen: Falsch-Positive, die echte Kunden blockieren (Reibung abstimmen, schnelle Freigabe durch Bearbeiter anbieten); Diskriminierung schutzbedürftiger Kunden oder Kunden mit anderer Muttersprache (Fairness-Tests, Kennzeichen für schutzbedürftige Kunden); übermäßiges Vertrauen in LLM-Zusammenfassungen (Quelldaten angeben, menschliche Freigabe); Anpassung der Gegner (laufende Überwachung); Datenabfluss an LLM-APIs (Maskierung, EU-Region, kein Training mit Kundendaten).
• Hinweis zu sensiblen Bereichen: Diese Seite beschreibt ausschließlich defensive Betrugsprävention und gibt keine Hinweise, wie man der Erkennung entgeht.

Erste Schritte

1. Ermitteln Sie Ihre APP-Verluste, Erstattungen und Geldkurier-Fälle nach Typologie und Kanal; legen Sie die Label-Pipeline einschließlich verzögerter Opfermeldungen fest.
2. Setzen Sie zuerst die Prüfung von Name und IBAN sowie dynamische, betrugsspezifische Warnungen um; messen Sie die Abbruchquoten der Kunden.
3. Ergänzen Sie Sitzungstelemetrie (Fernzugriff, aktives Telefonat, Gerät) und Empfängerrisiko-Merkmale in Ihrem bestehenden Scoring-Dienst; testen Sie per Backtest an historischen Fällen.
4. Bauen Sie die Geldkurier-Sicht auf: Merkmale zu Zu- und Abflüssen und einen Empfängergraphen; legen Sie einen Prozess für Einschränkung, Prüfung und Rückholanfragen fest.
5. Bereiten Sie die Governance vor: DSFA, Vermerk zur Einstufung nach AI Act, Verfahren für schutzbedürftige Kunden und Widerspruchsweg.

Quellen

1. Payment Systems Regulator (UK), APP scams: reimbursement requirement — https://www.psr.org.uk/our-work/app-scams/
2. Regulation (EU) 2024/886 (Instant Payments Regulation), EUR-Lex — https://eur-lex.europa.eu/eli/reg/2024/886/oj
3. European Commission, Proposal for a Payment Services Regulation (COM(2023) 367) — https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52023PC0367
4. Jesus et al., "Turning the Tables: Biased, Imbalanced, Dynamic Tabular Datasets for ML Evaluation" (Bank Account Fraud dataset, NeurIPS 2022) — https://arxiv.org/abs/2211.13358
5. AI Act Annex III (point 5(b) excludes financial-fraud detection) — https://artificialintelligenceact.eu/annex/3/
6. Regulation (EU) 2024/1689 (AI Act), EUR-Lex — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
7. Council of the EU — 'I/A' item note 14798/26 (23 Oct 2026): adoption of the Council's first-reading position on the Payment Services Regulation — https://data.consilium.europa.eu/doc/document/ST-14798-2026-INIT/en/pdf