Payment & card transaction fraud detection

Every online card payment is a decision made in milliseconds: approve, challenge or decline. Rule lists alone miss new attack patterns and reject good customers; machine-learning scoring, enriched with device, behaviour and network signals, finds fraud earlier and cuts false declines. For most merchants the right answer is the fraud engine of their payment provider; banks, large PSPs and marketplaces build or tune their own models.

Problem & value

• Who has it: online and omnichannel merchants (card-not-present fraud, card testing, account takeover, friendly fraud), payment service providers and acquirers (merchant risk, transaction monitoring), issuers (authorisation fraud, unauthorised transfers).
• Today: static rules ("block country X, review orders over N euro"), manual review queues, and scheme or PSP default settings. Rules are brittle, attackers adapt within days, and over-blocking costs revenue.
• AI value: supervised models on tabular features (gradient boosting) plus unsupervised anomaly and graph methods catch new patterns; real-time scoring allows risk-based step-up (3-D Secure) instead of binary decline; LLM assistants help analysts investigate and write rules.
• Sourced figures (vendor-reported, not independently verified): Stripe states an average 32% fraud reduction with Radar and that businesses on Radar Standard block on average 42% more fraud attempts than on Radar Lite [1][2]. Feedzai reports from an unnamed tier-1 bank 62% more fraud detected and 73% fewer false positives versus its previous solution [3]. Treat all such numbers as marketing until reproduced on your own data.
• Market context: the EBA and ECB publish a joint payment-fraud report (latest edition 15 December 2025) analysing fraud levels, types and the effect of Strong Customer Authentication (SCA) in the EEA [4].

Variants

• Merchant / SMB webshop: use the PSP's built-in engine, tune thresholds, add a few custom rules and a review queue.
• Marketplace / platform: also scores sellers and connected accounts (merchant fraud, delinquency), see ANOM-004 for fake accounts and promo abuse.
• PSP / acquirer: network-level scoring across many merchants, card-testing and BIN-attack detection, merchant onboarding risk.
• Issuer / bank: authorisation-time scoring of card and instant-payment transactions, SCA exemption decisions (transaction risk analysis), unauthorised-transaction detection. Victim-authorised scams are a different problem: ANOM-022.
• Subscription / digital goods: free-trial abuse, card testing, payment-method changes.
• Private users: not a direct user; consumers benefit via their bank's and merchant's systems (for on-device scam protection see ANOM-025).
• Out of scope here: AML monitoring (ANOM-002), crypto flows (ANOM-023), chargeback handling after the fact (AGENT-031), forged documents (ANOM-017).

How it works

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

• Core model: gradient-boosted trees (XGBoost, LightGBM) on engineered features remain the production workhorse because of latency, calibration and explainability. Class imbalance (fraud is a tiny share of transactions) needs sampling or cost-sensitive training and precision-recall evaluation [8][10].
• Unsupervised / anomaly layer: detects novel attacks without labels (isolation-forest-type and autoencoder detectors; PyOD bundles 60+ detectors) [7].
• Graph features: shared devices, cards, addresses and emails link rings of accounts; GNNs (e.g. via PyTorch Geometric) or simple graph aggregates add signal [9].
• Feature store + streaming: velocity features (cards per device in 10 minutes) need a low-latency online store and an event stream; Feast is an open feature store keeping offline and online features consistent [6].
• LLMs are not the scorer. They help around the edges: summarising a case, explaining reason codes, drafting rules for review, triaging disputes. Never put a general LLM in the millisecond decision path.
• Human-in-the-loop: manual review of the grey zone, rule/threshold approval by a risk owner, periodic model review.

Data preparation

Core data are authorisation and order records (amount, BIN or card token, device and IP, shipping address) plus chargeback and fraud-confirmation labels. In an SMB they sit in the shop system, the PSP dashboard and the ERP; the PSP often holds the richest data. Typical gaps: labels arrive weeks late (chargebacks), fraud is rarely tagged consistently, customer duplicates across channels, and personal data mixed into free-text order notes.

Preparation steps: export transactions via API or PSP reports (PREP-005), harvest labels from chargeback and refund records (PREP-020), define a clear category scheme (fraud, friendly fraud, error; PREP-019), and pseudonymise exports before they leave the payment environment (PREP-022). For Path A, little more than clean order data and a feedback loop for confirmed fraud is needed. Check lawful basis and purpose (PREP-025). For the broader readiness view see DATA-003 and DATA-007.

Rough share of effort: 20-30 percent on Path A, 40-50 percent on Paths B and C, mostly label quality and feature history.

Implementation paths

Which path for whom

• SMB: Path A, because PSPs and shop platforms (e.g. Stripe Radar, Adyen, Mollie-class services) ship mature, pooled fraud scoring at per-transaction prices and the process is standard.
• Enterprise: Path B, because own order, customer and chargeback history is a competitive asset and a vendor score is best combined with in-house models and rules.
• Developer: Path C, because open-source tabular ML (gradient boosting, graph features) runs on HW1 and keeps feature pipelines under your control.

Path A — Buy (recommended for most SMBs)

• PSP-integrated engines: Stripe Radar (Lite/Standard/Plus/Pro tiers; custom rules, backtesting, adaptive 3-D Secure, manual review in higher tiers; per-checked-transaction fee) [1][2]; Adyen (NL, EU bank licence) with Protect/Uplift risk scoring and rule backtesting [5]; Worldline, Nexi, Unzer and Computop (EU/German PSPs) with their own risk modules, check scope and pricing per contract.
• Fraud platforms for enterprises and banks: Feedzai (PT) with RiskOps platform and agentic investigation assistant [3]; Featurespace (UK, owned by Visa), Mastercard Decision Intelligence and Visa Advanced Authorization (scheme-level scoring for issuers), LexisNexis ThreatMetrix, Riskified, Signifyd, Sift, Nethone (PL), SEON (HU), Ravelin (UK). Check EU hosting, explainability/reason codes, and chargeback-guarantee terms.
• Choose A when: you are a merchant or small PSP, volume is moderate, and you accept the vendor's network model. Decide on fee-vs-fraud-loss with a pilot, not a demo.

Path B — Build on cloud APIs

• Managed ML: train and serve your own tabular models on AWS SageMaker (Frankfurt), Azure ML or Google Vertex AI (EU regions); managed streaming (Kinesis, Event Hubs, Pub/Sub) and feature stores. Cloud vendors also offer packaged fraud APIs, whose EU availability and data handling must be checked per region.
• Identity and device signals as API: device-intelligence and email/phone-risk services (SEON, Nethone, ThreatMetrix).
• LLM layer: a frontier or EU-hosted model (e.g. Mistral, Claude or Gemini in EU regions) for analyst copilots, case summaries and rule drafting, never for the live decision.
• Choose B when: you have in-house data science, need custom features and decision logic, but no strict on-prem constraint.

Path C — Self-host (open source)

• Models: XGBoost (Apache-2.0) and LightGBM for scoring; PyOD (BSD-2) for anomaly detection; imbalanced-learn (MIT) for resampling; PyTorch Geometric (MIT) for graph models [7][8][9][10]. TabPFN (Prior Labs, Freiburg) is a tabular foundation model worth benchmarking for small-data cases; verify license terms for commercial use.
• Stack: Kafka or Redpanda + Apache Flink for streaming features, Feast + Redis for the online store [6], a graph database (Neo4j, Memgraph) for linkage, MLflow for model registry, FastAPI or NVIDIA Triton for serving, Grafana for drift monitoring.
• Hardware: the scoring path is CPU-bound (HW1); a GPU (HW2) only helps for GNN training or large retraining jobs. Latency and high availability matter more than FLOPs.
• Choose C when: data may not leave your perimeter (bank, PSP), or volume makes per-check fees prohibitive. Ops effort is significant: 24/7 availability, monitoring, retraining.

Path D — Custom training

Worthwhile for banks, PSPs and large marketplaces whose fraud mix differs from generic networks. Needs at least months of labelled history with delayed labels (chargebacks arrive 30-120 days later), careful time-based validation (never random splits), and a champion/challenger set-up. Public datasets (e.g. the ULB credit-card or IEEE-CIS Kaggle sets) are for experiments only; synthetic data helps test pipelines, not performance claims. Payments foundation models trained on sequences of transactions are emerging at the large networks and PSPs; for most firms the pragmatic step is a well-engineered boosted model plus network signals from a vendor.

State of the art (2026)

• Networks beat single-merchant models: providers with cross-merchant data (card networks, Stripe, Adyen, Feedzai IQ) see an attacker across many shops; this is the main reason Path A wins for SMBs [1][3][5].
• Gradient boosting stays the baseline in production; deep sequence models and payments foundation models are being deployed by the largest networks and PSPs, with gains mainly on card testing and sparse-history customers. Vendor claims are rarely reproducible externally.
• Risk-based authentication: PSD2 SCA with transaction-risk-analysis exemptions and adaptive 3-D Secure shift the question from "decline?" to "challenge or not?" [2][4].
• Agentic investigation: vendors add AI agents that assemble evidence, explain scores and draft rule changes (Feedzai Farol, Stripe Radar Assistant / agentic insights) [2][3]. Human sign-off on policy stays.
• Adversaries use AI too: synthetic identities, bot-driven card testing and generated documents raise attack volume; defence relies on device, behavioural and network signals rather than content alone (see ANOM-014, ANOM-017).
• Limits and failure modes: label delay and selection bias (declined transactions never get a label), concept drift, false declines hurting good customers, feedback loops, fairness issues if proxies for nationality or age creep into features, and data-protection limits on cross-merchant sharing.

Shared resources & combinations

• Same building blocks (tabular-ml + anomaly-detection + streaming): ANOM-009 expense and procurement fraud, ANOM-006 ledger anomalies, ANOM-005 sensor anomalies, ANOM-008 grid anomalies, PRED-009 credit scoring and PRED-021 payment-behaviour prediction (shared feature store, boosted-tree stack, monitoring).
• graph-ml shared with: ANOM-002 AML, ANOM-022 mule-account detection, ANOM-004 fake-account rings, ANOM-023 crypto forensics (one graph database and entity-resolution pipeline).
• Upstream signals: ANOM-014 (document and liveness checks at onboarding), ANOM-017 (tampered documents), ANOM-004 (account/bot signals).
• Downstream: AGENT-031 chargeback and dispute automation uses the same evidence; CONV-013 banking assistant for customer-confirmation flows; AGENT-014 insurance claims shares the case-management pattern.
• Hardware: HW1 CPU cluster for serving plus optional shared HW2 GPU for GNN and retraining jobs, reusable with other tabular/graph workloads.

Effort, cost & KPIs

• Path A: days to weeks; cost is a per-transaction fee or share of volume plus review staff.
• Path B: 2-4 months for feature pipeline, model, decision engine and integration; cloud cost modest versus fraud losses at scale.
• Path C: 4-9 months incl. streaming, HA and monitoring; needs data-science plus platform engineers.
• Path D: ongoing programme with a dedicated risk-analytics team.
• KPIs: fraud rate in basis points of volume, chargeback ratio (card-scheme monitoring thresholds apply), false-positive ratio and false-decline rate, approval/authorisation rate, manual-review rate and time, precision at fixed review capacity, 3-D Secure challenge rate and abandonment, score latency (p99), model drift (PSI), net revenue impact versus control group.

People & change

Involve management early for the risk appetite (how many false declines are acceptable), the department lead (payments, customer service) as process owner, IT and IT security for integration and PSP access, and the DPO for the legal basis and processor agreements (AVV) with the vendor. Customers are affected by declines, so plan clear challenge and appeal paths.

Works council: depends. The scoring concerns customers, not employees, so it is normally not co-determined; but analyst case queues and productivity statistics of fraud reviewers can be suited to monitor performance (§87(1) no. 6 BetrVG, objective suitability suffices), and §90(1) no. 3 requires timely information on AI-supported work processes.

Data protection: automated decisions with significant effects on customers need Art. 22 GDPR safeguards (human review, explanation); a DPIA is likely for large-scale profiling. AI literacy: support analysts with training on reading reason codes and on model limits (Art. 4 AI Act). Pilot in shadow mode on one market or payment method, tune thresholds, then go live. Typical concern: "the machine blocks good customers", addressed by manual review of borderline scores and monitoring of false declines. See GUIDE-005, GUIDE-006 and GUIDE-009.

Risks, regulation & compliance

• EU AI Act: minimal risk in the typical form. Recital 58 states that AI systems provided by Union law for detecting fraud in the offering of financial services are not considered high-risk credit scoring [11]. Caution: if the same score is reused to decide on creditworthiness or access to credit, or the system falls into another Annex III category, high-risk duties apply. AI literacy (Art. 4) applies to staff. No Art. 5 issue unless features build prohibited social scoring or biometric categorisation.
• GDPR: device fingerprints, IPs, transaction histories are personal data. Legal basis is typically legitimate interest (fraud prevention, recital 47) or legal duty; document the balancing test and run a DPIA for large-scale profiling. Art. 22 applies to solely automated decisions with significant effects (declining a purchase may qualify): offer human review and explanation. Cross-merchant data sharing needs a clear controller/processor roles analysis; third-country transfers need safeguards.
• Payments law: PSD2 SCA and fraud-reporting duties (EBA guidelines) [4]; the PSD3/PSR package was provisionally agreed on 27 Nov 2025 (final compromise texts April 2026; the Council's first-reading position was put up for adoption in late Oct 2026 [13], after which Parliament's second-reading approval and Official Journal publication are still pending) and introduces fraud-data sharing between PSPs and PSP refund liability narrowed to impersonation of the payer's own PSP, so verify the final text and application dates. DORA applies to financial entities (ICT risk, third-party providers). Card-scheme rules (PCI DSS, chargeback monitoring programmes) apply on top.
• Risks: discrimination through proxy features, over-blocking and customer harm, model drift, vendor lock-in, adversarial probing of rules. Mitigations: reason codes, periodic bias and performance review, champion/challenger rollout, holdout groups, fallback rules when the model is unavailable.

Getting started

1. Measure the baseline: fraud rate in bps, chargeback ratio, decline rate, review workload, and the revenue lost to false declines.
2. Switch on the PSP's native engine and 3-D Secure risk-based flow; use backtesting where available before changing rules [2].
3. Define a small decision policy (approve/step-up/review/decline) with owners, thresholds and a weekly review of the grey zone.
4. Capture clean labels: link chargebacks and confirmed fraud back to transaction IDs; keep a random holdout to avoid selection bias.
5. Only then consider a custom model (Path B/C): train a time-split XGBoost baseline on your own data and compare it against the vendor on precision at fixed review capacity.

Sources

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