Betrugserkennung bei Zahlungs- und Kartentransaktionen

Jede Online-Kartenzahlung ist eine Entscheidung in Millisekunden: freigeben, hinterfragen oder ablehnen. Regellisten allein übersehen neue Angriffsmuster und weisen gute Kunden ab; maschinelles Lernen, angereichert mit Geräte-, Verhaltens- und Netzwerksignalen, erkennt Betrug früher und senkt die Zahl fälschlicher Ablehnungen. Für die meisten Händler ist die richtige Antwort die Betrugserkennung ihres Zahlungsdienstleisters; Banken, große PSPs und Marktplätze bauen oder optimieren eigene Modelle.

Problem & Nutzen

• Wer betroffen ist: Online- und Omnichannel-Händler (Betrug bei Zahlungen ohne physische Karte, Card Testing, Kontoübernahme, „freundlicher Betrug“ bzw. Friendly Fraud), Zahlungsdienstleister und Acquirer (Händlerrisiko, Transaktionsüberwachung), Herausgeber (Betrug bei der Autorisierung, nicht autorisierte Überweisungen).
• Heute: statische Regeln („Land X sperren, Bestellungen über N Euro prüfen“), manuelle Prüfwarteschlangen sowie Standardeinstellungen der Kartenorganisationen oder des PSP. Regeln sind starr, Angreifer passen sich binnen Tagen an, und zu viele Ablehnungen kosten Umsatz.
• KI-Nutzen: überwachte Modelle auf tabellarischen Merkmalen (Gradient Boosting) sowie unüberwachte Anomalie- und Graphverfahren erkennen neue Muster; Echtzeit-Bewertung erlaubt eine risikobasierte Zusatzprüfung (3-D Secure) statt einer reinen Ja/Nein-Ablehnung; LLM-Assistenten helfen Analysten bei Untersuchung und Regelformulierung.
• Belegte Zahlen (vom Anbieter berichtet, nicht unabhängig geprüft): Stripe nennt im Schnitt 32 % weniger Betrug mit Radar und gibt an, dass Unternehmen mit Radar Standard im Schnitt 42 % mehr Betrugsversuche blockieren als mit Radar Lite [1][2]. Feedzai berichtet von einer nicht genannten Tier-1-Bank 62 % mehr erkannten Betrug und 73 % weniger Fehlalarme gegenüber der vorherigen Lösung [3]. Behandeln Sie alle derartigen Zahlen als Werbung, bis Sie sie mit Ihren eigenen Daten nachvollzogen haben.
• Marktkontext: EBA und EZB veröffentlichen gemeinsam einen Bericht zu Zahlungsbetrug (aktuelle Ausgabe vom 15. Dezember 2025), der Betrugsniveaus, -arten und die Wirkung der starken Kundenauthentifizierung (Strong Customer Authentication, SCA) im EWR analysiert [4].

Varianten

• Händler / KMU-Webshop: die integrierte Betrugserkennung des PSP nutzen, Schwellenwerte anpassen, einige eigene Regeln und eine Prüfwarteschlange ergänzen.
• Marktplatz / Plattform: bewertet zusätzlich Verkäufer und verbundene Konten (Händlerbetrug, Zahlungsausfälle); zu gefälschten Konten und Missbrauch von Aktionen siehe ANOM-004.
• PSP / Acquirer: Bewertung auf Netzwerkebene über viele Händler hinweg, Erkennung von Card Testing und BIN-Angriffen, Risikobewertung beim Onboarding von Händlern.
• Herausgeber / Bank: Bewertung von Karten- und Sofortzahlungen zum Zeitpunkt der Autorisierung, Entscheidungen über SCA-Ausnahmen (Transaktionsrisikoanalyse), Erkennung nicht autorisierter Transaktionen. Vom Opfer selbst autorisierte Betrugsfälle sind ein anderes Problem: ANOM-022.
• Abonnements / digitale Güter: Missbrauch von Testzeiträumen, Card Testing, Wechsel von Zahlungsmitteln.
• Privatpersonen: kein direkter Nutzer; Verbraucher profitieren über die Systeme ihrer Bank und der Händler (zum Betrugsschutz auf dem Gerät siehe ANOM-025).
• Hier nicht behandelt: Geldwäscheüberwachung (ANOM-002), Krypto-Zahlungsströme (ANOM-023), nachträgliche Bearbeitung von Rückbuchungen (AGENT-031), gefälschte Dokumente (ANOM-017).

So funktioniert es

1. payment request (checkout / terminal / API)
2. feature enrichment (device fingerprint, IP, velocity counters, customer history, BIN data)
3. real-time scoring: gradient-boosted model + anomaly score + graph/linkage features (< ~100-200 ms budget)
4. decision policy: rules + thresholds + risk-based SCA/3-D Secure challenge
5. action: approve | step-up | manual review | decline
6. case management (analyst, LLM-assisted summary, reason codes)
7. feedback: chargebacks, confirmed fraud, customer disputes
8. delayed labels
9. retraining + monitoring

• Kernmodell: Gradient-Boosted Trees (XGBoost, LightGBM) auf konstruierten Merkmalen bleiben das Arbeitspferd im Produktivbetrieb – wegen Latenz, Kalibrierung und Erklärbarkeit. Das Klassenungleichgewicht (Betrug ist nur ein winziger Anteil der Transaktionen) erfordert Stichprobenverfahren oder kostensensitives Training sowie eine Bewertung mit Precision-Recall [8][10].
• Unüberwachte Anomalieschicht: erkennt neuartige Angriffe ohne Labels (Detektoren vom Typ Isolation Forest und Autoencoder; PyOD bündelt über 60 Detektoren) [7].
• Graph-Merkmale: gemeinsam genutzte Geräte, Karten, Adressen und E-Mail-Adressen verknüpfen Gruppen von Konten; GNNs (z. B. über PyTorch Geometric) oder einfache Graph-Aggregate liefern zusätzliche Signale [9].
• Feature Store + Streaming: Geschwindigkeitsmerkmale (Karten pro Gerät in 10 Minuten) brauchen einen Online-Speicher mit niedriger Latenz und einen Ereignisstrom; Feast ist ein offener Feature Store, der Offline- und Online-Merkmale konsistent hält [6].
• LLMs sind nicht der Bewerter. Sie helfen am Rand: einen Fall zusammenfassen, Begründungscodes erklären, Regeln zur Prüfung entwerfen, Streitfälle vorsortieren. Setzen Sie nie ein allgemeines LLM in den Entscheidungspfad im Millisekundenbereich.
• Mensch-in-der-Schleife (Human-in-the-Loop): manuelle Prüfung der Grauzone, Freigabe von Regeln und Schwellenwerten durch eine verantwortliche Person für Risiko, regelmäßige Modellprüfung.

Datenaufbereitung

Kerndaten sind Autorisierungs- und Bestelldaten (Betrag, BIN oder Kartentoken, Gerät und IP, Lieferadresse) sowie Rückbuchungs- und Betrugsbestätigungs-Labels. In einem KMU liegen sie im Shop-System, im PSP-Dashboard und im ERP; der PSP hält oft die reichhaltigsten Daten. Typische Lücken: Labels treffen Wochen später ein (Rückbuchungen), Betrug wird selten einheitlich markiert, Kunden-Dubletten über Kanäle hinweg und personenbezogene Daten in freien Bestellnotizen.

Aufbereitungsschritte: Transaktionen über API oder PSP-Berichte exportieren (PREP-005), Labels aus Rückbuchungs- und Erstattungsdaten gewinnen (PREP-020), ein klares Kategorienschema festlegen (Betrug, Friendly Fraud, Fehler; PREP-019) und Exporte pseudonymisieren, bevor sie die Zahlungsumgebung verlassen (PREP-022). Für Weg A genügen kaum mehr als saubere Bestelldaten und eine Rückmeldeschleife für bestätigten Betrug. Prüfen Sie Rechtsgrundlage und Zweck (PREP-025). Zur weiteren Einordnung der Datenreife siehe DATA-003 und DATA-007.

Grober Aufwandsanteil: 20–30 Prozent bei Weg A, 40–50 Prozent bei Weg B und C, vor allem für Label-Qualität und Merkmalshistorie.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg A, weil PSPs und Shop-Plattformen (z. B. Stripe Radar, Adyen, Dienste der Klasse Mollie) ausgereifte, gebündelte Betrugsbewertung zu Preisen pro Transaktion liefern und der Prozess Standard ist.
• Großunternehmen: Weg B, weil die eigene Bestell-, Kunden- und Rückbuchungshistorie ein Wettbewerbsvorteil ist und ein Anbieter-Score am besten mit hauseigenen Modellen und Regeln kombiniert wird.
• Entwickler: Weg C, weil quelloffenes tabellarisches ML (Gradient Boosting, Graph-Merkmale) auf HW1 läuft und die Merkmals-Pipelines unter Ihrer Kontrolle bleiben.

Weg A — Kaufen (für die meisten KMU empfohlen)

• In PSPs integrierte Systeme: Stripe Radar (Stufen Lite/Standard/Plus/Pro; eigene Regeln, Backtesting, adaptives 3-D Secure, manuelle Prüfung in höheren Stufen; Gebühr pro geprüfter Transaktion) [1][2]; Adyen (NL, EU-Banklizenz) mit Risikobewertung durch Protect/Uplift und Backtesting von Regeln [5]; Worldline, Nexi, Unzer und Computop (EU-/deutsche PSPs) mit eigenen Risikomodulen – Umfang und Preise je Vertrag prüfen.
• Betrugsplattformen für Großunternehmen und Banken: Feedzai (PT) mit RiskOps-Plattform und agentischem Untersuchungsassistenten [3]; Featurespace (UK, im Besitz von Visa), Mastercard Decision Intelligence und Visa Advanced Authorization (Bewertung auf Ebene der Kartenorganisation für Herausgeber), LexisNexis ThreatMetrix, Riskified, Signifyd, Sift, Nethone (PL), SEON (HU), Ravelin (UK). Prüfen Sie EU-Hosting, Erklärbarkeit/Begründungscodes und die Bedingungen der Rückbuchungsgarantie.
• Wählen Sie A, wenn: Sie Händler oder kleiner PSP sind, das Volumen moderat ist und Sie das Netzwerkmodell des Anbieters akzeptieren. Entscheiden Sie über Gebühr gegenüber Betrugsverlust mit einem Pilotversuch, nicht mit einer Demo.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Verwaltetes ML: eigene tabellarische Modelle auf AWS SageMaker (Frankfurt), Azure ML oder Google Vertex AI (EU-Regionen) trainieren und bereitstellen; verwaltetes Streaming (Kinesis, Event Hubs, Pub/Sub) und Feature Stores. Cloud-Anbieter bieten auch vorgefertigte Betrugs-APIs an; deren Verfügbarkeit in der EU und der Umgang mit Daten müssen je Region geprüft werden.
• Identitäts- und Gerätesignale als API: Dienste für Geräteerkennung sowie E-Mail-/Telefon-Risiko (SEON, Nethone, ThreatMetrix).
• LLM-Schicht: ein Spitzenmodell oder in der EU gehostetes Modell (z. B. Mistral, Claude oder Gemini in EU-Regionen) für Analysten-Copiloten, Fallzusammenfassungen und Regelentwürfe, nie für die Live-Entscheidung.
• Wählen Sie B, wenn: Sie eigene Data-Science-Kompetenz haben, individuelle Merkmale und Entscheidungslogik brauchen, aber keine strikte On-Premises-Vorgabe besteht.

Weg C — Selbst betreiben (Open Source)

• Modelle: XGBoost (Apache-2.0) und LightGBM für die Bewertung; PyOD (BSD-2) für Anomalieerkennung; imbalanced-learn (MIT) fürs Resampling; PyTorch Geometric (MIT) für Graphmodelle [7][8][9][10]. TabPFN (Prior Labs, Freiburg) ist ein Foundation-Modell für Tabellendaten, das sich für kleine Datenmengen als Vergleich lohnt; prüfen Sie die Lizenzbedingungen für kommerzielle Nutzung.
• Stack: Kafka oder Redpanda + Apache Flink für Streaming-Merkmale, Feast + Redis als Online-Speicher [6], eine Graphdatenbank (Neo4j, Memgraph) für Verknüpfungen, MLflow als Modellregister, FastAPI oder NVIDIA Triton fürs Bereitstellen, Grafana zur Drift-Überwachung.
• Hardware: der Bewertungspfad ist CPU-lastig (HW1); eine GPU (HW2) hilft nur beim GNN-Training oder bei großen Nachtrainings. Latenz und Hochverfügbarkeit zählen mehr als Rechenleistung.
• Wählen Sie C, wenn: Daten Ihren Verantwortungsbereich nicht verlassen dürfen (Bank, PSP) oder das Volumen Gebühren pro Prüfung unbezahlbar macht. Der Betriebsaufwand ist erheblich: 24/7-Verfügbarkeit, Überwachung, Nachtraining.

Weg D — Eigenes Training

Lohnt sich für Banken, PSPs und große Marktplätze, deren Betrugsmix sich von allgemeinen Netzwerken unterscheidet. Erfordert mindestens mehrere Monate gelabelter Historie mit verzögerten Labels (Rückbuchungen treffen 30–120 Tage später ein), sorgfältige zeitbasierte Validierung (nie zufällige Aufteilungen) und ein Champion/Challenger-Setup. Öffentliche Datensätze (z. B. die Kaggle-Sets ULB Credit Card oder IEEE-CIS) taugen nur für Experimente; synthetische Daten helfen beim Test von Pipelines, nicht für Leistungsaussagen. Foundation-Modelle für Zahlungen, trainiert auf Transaktionsfolgen, entstehen bei den großen Netzwerken und PSPs; für die meisten Unternehmen ist der pragmatische Schritt ein gut gebautes Boosting-Modell plus Netzwerksignale eines Anbieters.

Stand der Technik (2026)

• Netzwerke schlagen Modelle einzelner Händler: Anbieter mit händlerübergreifenden Daten (Kartenorganisationen, Stripe, Adyen, Feedzai IQ) sehen einen Angreifer in vielen Shops; das ist der Hauptgrund, warum Weg A für KMU gewinnt [1][3][5].
• Gradient Boosting bleibt die Basis im Produktivbetrieb; tiefe Sequenzmodelle und Foundation-Modelle für Zahlungen werden von den größten Netzwerken und PSPs eingesetzt, mit Gewinnen vor allem bei Card Testing und Kunden mit dünner Historie. Aussagen der Anbieter lassen sich extern selten nachvollziehen.
• Risikobasierte Authentifizierung: PSD2-SCA mit Ausnahmen aufgrund der Transaktionsrisikoanalyse und adaptives 3-D Secure verschieben die Frage von „ablehnen?“ zu „hinterfragen oder nicht?“ [2][4].
• Agentische Untersuchung: Anbieter ergänzen KI-Agenten, die Belege zusammentragen, Bewertungen erklären und Regeländerungen entwerfen (Feedzai Farol, Stripe Radar Assistant / agentische Erkenntnisse) [2][3]. Die menschliche Freigabe der Richtlinie bleibt.
• Auch Angreifer nutzen KI: synthetische Identitäten, bot-gesteuertes Card Testing und erzeugte Dokumente erhöhen das Angriffsvolumen; die Abwehr stützt sich auf Geräte-, Verhaltens- und Netzwerksignale statt allein auf Inhalte (siehe ANOM-014, ANOM-017).
• Grenzen und Fehlerbilder: Label-Verzögerung und Auswahlverzerrung (abgelehnte Transaktionen erhalten nie ein Label), Konzeptdrift, fälschliche Ablehnungen, die gute Kunden verärgern, Rückkopplungsschleifen, Fairnessprobleme, wenn Stellvertretermerkmale für Nationalität oder Alter in die Merkmale gelangen, und datenschutzrechtliche Grenzen für den händlerübergreifenden Austausch.

Gemeinsame Bausteine & Kombinationen

• Gleiche Bausteine (tabular-ml + anomaly-detection + streaming): ANOM-009 Spesen- und Beschaffungsbetrug, ANOM-006 Anomalien im Hauptbuch, ANOM-005 Sensoranomalien, ANOM-008 Netzanomalien, PRED-009 Kredit-Scoring und PRED-021 Vorhersage des Zahlungsverhaltens (gemeinsamer Feature Store, Boosted-Tree-Stack, Überwachung).
• graph-ml gemeinsam mit: ANOM-002 Geldwäscheüberwachung, ANOM-022 Erkennung von Mule-Konten, ANOM-004 Netzwerke gefälschter Konten, ANOM-023 Krypto-Forensik (eine Graphdatenbank und eine Pipeline zur Entitätsauflösung).
• Vorgelagerte Signale: ANOM-014 (Dokumenten- und Lebendigkeitsprüfung beim Onboarding), ANOM-017 (manipulierte Dokumente), ANOM-004 (Konto-/Bot-Signale).
• Nachgelagert: AGENT-031 Automatisierung von Rückbuchungen und Streitfällen nutzt dieselben Belege; CONV-013 Banking-Assistent für Kundenbestätigungen; AGENT-014 Versicherungsschäden teilt das Muster der Fallbearbeitung.
• Hardware: HW1-CPU-Cluster fürs Bereitstellen plus optional eine gemeinsam genutzte HW2-GPU für GNN und Nachtraining, wiederverwendbar mit anderen Tabellen-/Graph-Workloads.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis Wochen; die Kosten sind eine Gebühr pro Transaktion oder ein Anteil am Volumen plus Prüfpersonal.
• Weg B: 2–4 Monate für Merkmals-Pipeline, Modell, Entscheidungsmaschine und Integration; Cloud-Kosten sind im Verhältnis zu Betrugsverlusten bei großem Volumen gering.
• Weg C: 4–9 Monate inkl. Streaming, Hochverfügbarkeit und Überwachung; erfordert Data Scientists und Plattform-Ingenieure.
• Weg D: laufendes Programm mit eigenem Team für Risikoanalytik.
• Kennzahlen: Betrugsrate in Basispunkten des Volumens, Rückbuchungsquote (Überwachungsschwellen der Kartenorganisationen gelten), Anteil der Fehlalarme und Rate fälschlicher Ablehnungen, Freigabe-/Autorisierungsrate, Quote und Dauer der manuellen Prüfung, Precision bei fester Prüfkapazität, 3-D-Secure-Challenge-Rate und Abbruchquote, Latenz der Bewertung (p99), Modelldrift (PSI), Nettoeffekt auf den Umsatz gegenüber einer Kontrollgruppe.

Menschen & Veränderung

Binden Sie früh die Geschäftsleitung für die Risikobereitschaft ein (wie viele fälschliche Ablehnungen sind akzeptabel), die Abteilungsleitung (Zahlungsverkehr, Kundenservice) als Prozessverantwortliche, IT und IT-Sicherheit für Integration und PSP-Zugang sowie die/den Datenschutzbeauftragte(n) für die Rechtsgrundlage und die Auftragsverarbeitungsverträge (AVV) mit dem Anbieter. Kunden sind von Ablehnungen betroffen, planen Sie daher klare Wege für Rückfrage und Widerspruch ein.

Betriebsrat: kommt darauf an. Die Bewertung betrifft Kunden, nicht Beschäftigte, und ist daher normalerweise nicht mitbestimmungspflichtig; Fallwarteschlangen der Analysten und Produktivitätsstatistiken der Betrugsprüfer können jedoch zur Leistungsüberwachung geeignet sein (§ 87 Abs. 1 Nr. 6 BetrVG, objektive Eignung genügt), und § 90 Abs. 1 Nr. 3 verlangt die rechtzeitige Unterrichtung über KI-gestützte Arbeitsabläufe.

Datenschutz: Automatisierte Entscheidungen mit erheblicher Wirkung für Kunden brauchen Schutzmaßnahmen nach Art. 22 DSGVO (menschliche Prüfung, Erklärung); bei umfangreichem Profiling ist eine Datenschutz-Folgenabschätzung (DSFA) wahrscheinlich. KI-Kompetenz: Unterstützen Sie Analysten mit Schulungen zum Lesen von Begründungscodes und zu den Grenzen des Modells (Art. 4 KI-Verordnung). Pilotieren Sie im Schattenmodus in einem Markt oder für eine Zahlungsart, justieren Sie die Schwellenwerte und gehen Sie dann live. Typische Sorge: „Die Maschine blockiert gute Kunden“ – begegnen Sie ihr mit manueller Prüfung grenzwertiger Werte und der Überwachung fälschlicher Ablehnungen. Siehe GUIDE-005, GUIDE-006 und GUIDE-009.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): in der typischen Ausprägung minimales Risiko. Erwägungsgrund 58 stellt klar, dass nach Unionsrecht vorgesehene KI-Systeme zur Aufdeckung von Betrug beim Angebot von Finanzdienstleistungen nicht als Hochrisiko-Kreditscoring gelten [11]. Vorsicht: Wird derselbe Score für die Entscheidung über Kreditwürdigkeit oder Kreditzugang wiederverwendet oder fällt das System in eine andere Kategorie des Anhangs III, gelten die Pflichten für Hochrisiko-Systeme. Die KI-Kompetenz (Art. 4) gilt für das Personal. Kein Problem nach Art. 5, solange Merkmale kein verbotenes Social Scoring oder keine biometrische Kategorisierung aufbauen.
• DSGVO: Gerätefingerabdrücke, IP-Adressen und Transaktionshistorien sind personenbezogene Daten. Die Rechtsgrundlage ist typischerweise berechtigtes Interesse (Betrugsprävention, Erwägungsgrund 47) oder rechtliche Verpflichtung; dokumentieren Sie die Interessenabwägung und führen Sie bei umfangreichem Profiling eine DSFA durch. Art. 22 gilt für ausschließlich automatisierte Entscheidungen mit erheblicher Wirkung (die Ablehnung eines Kaufs kann dazu zählen): bieten Sie menschliche Prüfung und Erklärung an. Der händlerübergreifende Datenaustausch braucht eine klare Analyse der Rollen als Verantwortlicher/Auftragsverarbeiter; Übermittlungen in Drittländer brauchen Garantien.
• Zahlungsrecht: PSD2-SCA und Meldepflichten bei Betrug (EBA-Leitlinien) [4]; das Paket PSD3/PSR wurde am 27. Nov. 2025 vorläufig vereinbart (endgültige Kompromisstexte April 2026; der Standpunkt des Rates in erster Lesung wurde Ende Okt. 2026 zur Annahme vorgelegt [13], danach stehen die Billigung des Parlaments in zweiter Lesung und die Veröffentlichung im Amtsblatt noch aus) und führt den Austausch von Betrugsdaten zwischen PSPs ein sowie eine auf die Fälle der Vortäuschung des eigenen PSP des Zahlers verengte Erstattungshaftung der PSPs – prüfen Sie daher den endgültigen Text und die Anwendungstermine. DORA gilt für Finanzunternehmen (IKT-Risiko, Drittanbieter). Regeln der Kartenorganisationen (PCI DSS, Überwachungsprogramme für Rückbuchungen) gelten zusätzlich.
• Risiken: Diskriminierung durch Stellvertretermerkmale, zu viele Ablehnungen und Kundenschäden, Modelldrift, Abhängigkeit vom Anbieter, gezieltes Austesten der Regeln durch Angreifer. Gegenmaßnahmen: Begründungscodes, regelmäßige Prüfung auf Verzerrung und Leistung, Champion/Challenger-Einführung, Holdout-Gruppen, Rückfallregeln bei Ausfall des Modells.

Erste Schritte

1. Ausgangslage messen: Betrugsrate in Basispunkten, Rückbuchungsquote, Ablehnungsrate, Prüfaufwand und der durch fälschliche Ablehnungen entgangene Umsatz.
2. Die native Betrugserkennung des PSP und den risikobasierten 3-D-Secure-Ablauf einschalten; vor Regeländerungen Backtesting nutzen, wo verfügbar [2].
3. Eine kleine Entscheidungsrichtlinie (freigeben/Zusatzprüfung/Prüfung/ablehnen) mit Verantwortlichen, Schwellenwerten und einer wöchentlichen Prüfung der Grauzone festlegen.
4. Saubere Labels erfassen: Rückbuchungen und bestätigten Betrug mit den Transaktions-IDs verknüpfen; eine zufällige Holdout-Gruppe behalten, um Auswahlverzerrung zu vermeiden.
5. Erst danach ein eigenes Modell erwägen (Weg B/C): eine zeitlich aufgeteilte XGBoost-Basis auf Ihren eigenen Daten trainieren und mit dem Anbieter bei der Precision bei fester Prüfkapazität vergleichen.

Quellen

1. Stripe — Radar (claims: 32% average fraud reduction) — https://stripe.com/radar
2. Stripe Docs — How Radar works (plans, 42% more blocked on Standard vs Lite) — https://docs.stripe.com/radar/how-radar-works
3. Feedzai — platform and customer results (vendor-reported) — https://www.feedzai.com/
4. EBA — Payment services and electronic money (EBA/ECB Report on Payment Fraud, 15 Dec 2025; PSD3/PSR opinions) — https://www.eba.europa.eu/regulation-and-policy/payment-services-and-electronic-money
5. Adyen — Protect / risk management — https://www.adyen.com/risk-management
6. Feast — open-source feature store — https://github.com/feast-dev/feast
7. PyOD — anomaly detection library (60+ detectors, BSD-2) — https://github.com/yzhao062/pyod
8. XGBoost — gradient boosting library (Apache-2.0) — https://github.com/dmlc/xgboost
9. PyTorch Geometric — GNN library (MIT) — https://github.com/pyg-team/pytorch_geometric
10. imbalanced-learn — resampling for imbalanced data (MIT) — https://github.com/scikit-learn-contrib/imbalanced-learn
11. EU AI Act, Recital 58 (fraud-detection exclusion from high-risk credit scoring) — https://artificialintelligenceact.eu/recital/58/
12. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
13. 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