Authorised push payment (APP) scam & money-mule account detection

In an APP scam the victim themselves approves the transfer, after being manipulated by a fake bank employee, investment promoter, romance contact or invoice impersonator. Card-fraud models (ANOM-001) see a legitimate customer on a legitimate device and stay silent. Banks therefore combine session and behavioural signals on the sending side with mule-account detection on the receiving side, plus name-to-IBAN verification and cross-bank intelligence. The benefit is fewer successful scams, faster funds recovery and lower reimbursement cost, without blocking too many genuine payments.

Problem & value

• Who: retail banks, neobanks, payment and e-money institutions, and increasingly telecom operators and platforms that feed signals to banks. Victims are mostly private customers, but small businesses suffer invoice and CEO impersonation.
• Today: rules on amounts and new payees, static warning texts, manual call-backs, and mule accounts found only after a victim complaint. Instant payments leave minutes, not days, to intervene.
• Why AI helps: the signal lives in behaviour (a customer on an active phone call with remote-access software, hesitating, typing a payee they have never used) and in networks (a new account receiving many first-time inbound payments and forwarding them within minutes). Supervised models, graph analytics and anomaly detection handle this; LLMs help with scam-narrative classification, agent case notes and customer-facing warnings.
• Regulatory driver (why this is now a board topic): in the UK, the Payment Systems Regulator requires sending and receiving firms to reimburse APP victims, split 50:50 between them, with a per-claim limit and a short reimbursement deadline, in force since October 2024 [1]. In the EU, the Instant Payments Regulation (EU) 2024/886 obliges payment service providers to offer a payee name/IBAN check (Verification of Payee) in the euro area from October 2025, with later dates for non-euro states [2]. The EU's revised payment-services package (PSD3/PSR) was politically agreed in late 2025; the Council's first-reading position was put up for adoption in late Oct 2026 [7], with Parliament's second reading and Official Journal publication still pending. It is expected to add liability for bank-employee impersonation and stronger fraud-data sharing; check the final published text and application dates before planning [3].
• Benefit figures: vendors publish reductions in scam losses, but they are self-reported and depend on baseline and friction. Do not adopt them without a back-test on your own data. The public Bank Account Fraud dataset (NeurIPS 2022) lets you compare methods at fixed false-positive rates [4].

Variants

• Sender-side scam detection: impersonation (bank, police, tech support), investment and romance scams, invoice redirection, "safe account" scams.
• Receiver-side mule detection: account-opening mules (synthetic or stolen identities, see ANOM-014), recruited real customers ("money-mule recruitment" via job ads and social media), and rented or compromised accounts.
• Business payments: invoice-fraud and supplier-bank-detail change detection for corporate banking (overlaps ANOM-009).
• Consortium and cross-bank intelligence: shared mule-account lists and scam-report exchanges between institutions, within national legal frameworks.
• Telecom and platform signals: scam call and message data (ANOM-025, ANOM-024) delivered to banks as risk signals.
• Private use: none directly; end customers experience this as warnings, payment friction and call-backs. Consumer-side protection tools are covered in ANOM-025.
• Not covered here: unauthorised card or account takeover fraud (ANOM-001), AML transaction monitoring and SAR filing (ANOM-002), crypto flows (ANOM-023).

How it works

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

• Models: gradient-boosted trees for per-payment scoring; sequence and behavioural models on session data; graph features or GNNs on the payer-payee network (new account that receives from many unrelated payers and forwards within minutes); unsupervised models for new typologies.
• LLMs are used outside the millisecond path: classifying free-text payment references and agent notes into scam typologies, summarising cases, and drafting tailored warning texts. They do not make the release/hold decision.
• Human-in-the-loop: fraud agents call customers on held payments, decide on account restriction for suspected mules, and approve reports. Customers keep the final say after an effective warning.

Data preparation

Needed data: payment instructions and history, payee and account master data, session and device telemetry from online and mobile banking, call-centre contacts, Verification-of-Payee results and, above all, confirmed outcomes (scam, mule, false alarm). They typically live in the core banking system, the online-banking backend, a case-management tool and the contact centre, with a long delay until victims report a scam.

Typical gaps: delayed and incomplete labels, fraud cases filed as free text, differing identifiers across channels, telemetry that is not stored or not linkable to payments, and strict access rights for transaction data.

Preparation steps: build a unified event stream and feature store keyed on customer, device and payee (see PREP-005), link case outcomes to the original payment (PREP-020), classify free-text case notes into scam typologies with an LLM (PREP-019), define label windows that respect reporting delays, and create an evaluation set with fraud experts (PREP-018). Pseudonymise data for model development (PREP-022) and check the purpose and legal basis (PREP-025). Tools: Kafka or Flink, a feature store such as Feast, dbt, PostgreSQL. Expect 50 to 60 percent of the effort in data engineering and labelling; GUIDE-003 offers a readiness check.

Implementation paths

Which path for whom

• enterprise (banks, payment institutions): A, because mature vendors bring behavioural biometrics and consortium or mule-network data that a single bank cannot replicate; large banks with a strong data-science team may add B or C components.
• developer: B, because cloud streaming and ML services in EU regions allow building custom features and scoring around purchased or own data.

Path A — Buy (off-the-shelf)

Best default for banks and payment institutions: scoring engines with behavioural biometrics and consortium data. Representative vendors: BioCatch (behavioural intelligence, used for scam and mule detection), Featurespace (ARIC Risk Hub, part of Visa), NICE Actimize, Feedzai, SAS, Mastercard (Consumer Fraud Risk, Scam Protect style services), Cleafy (Italy, EU: fraud and remote-access detection), Hawk (Germany, EU: AI-based fraud and AML monitoring), Nexi / Nets for acquirer and processor-embedded services. In the UK, Pay.UK's Confirmation of Payee and bank-specific mule intelligence are also in use. Check where the vendor processes data (EU region, sub-processors) and whether the model can be explained to your regulator. Small PSPs usually buy a managed service rather than build.

Path B — Build on cloud APIs

Use a cloud ML platform in an EU region (AWS, Azure or Google Cloud EU regions, or EU providers such as STACKIT or OVHcloud) for feature store, streaming (Kafka/Flink or cloud equivalents) and model serving. LLM APIs with EU data residency (for example Mistral, Azure OpenAI EU, Google Vertex AI, Anthropic via EU-capable cloud providers) cover case summaries, typology classification of payment texts, and customer-warning drafting. Keep the real-time scoring path on your own models; use APIs only for non-latency-critical text work, with PII masking and a data-processing agreement. Integrate with your payment hub, online-banking front end (for dynamic warnings) and case management.

Path C — Self-host (open source)

Stack: Kafka/Flink for streams, XGBoost/LightGBM/scikit-learn, PyTorch Geometric or DGL for graph models, Neo4j or other graph store for the payee network, a feature store such as Feast. Open-source decision engines such as Marble (France) and Jube exist for rules and case management; verify maturity and support before using them as a primary control. For text tasks, self-host an open-weight model such as Qwen3, Mistral or Llama variants with vLLM. Hardware: HW2 is enough for scoring and a ~30B quantised LLM; training GNNs on a large national payment graph needs HW3. The expensive part is operations: 24/7 pipelines, latency SLOs, model governance and audit trails.

Path D — Custom training

Worthwhile for larger institutions and consortia: train on your own confirmed-scam and mule labels, fine-tune sequence models on session telemetry, and build graph models across institutions. Needs several years of labelled outcomes (labels are delayed: victims report days later) and careful handling of label bias. Privacy-preserving collaboration (federated learning, privacy-enhancing technologies, supervised data-sharing schemes) is active, but each scheme needs a legal basis under GDPR and banking secrecy.

State of the art (2026)

• Behavioural intelligence plus payee risk is the established core: session signals (active call, remote-access tools, coaching-like hesitation) combined with payee-side mule scores. Feature quality and latency matter more than model complexity.
• Name-to-IBAN verification (Verification of Payee under the Instant Payments Regulation, Confirmation of Payee in the UK) removes a large class of misdirected and invoice-redirect fraud but not scams where the victim is told the correct name [2].
• Network and consortium views: graph-based mule detection and bank-to-bank sharing of mule indicators are the main new lever; the UK and several EU markets are building shared infrastructure, and the EU payment-services reform aims to give a legal basis for fraud-data sharing [3].
• Dynamic friction: targeted, scam-specific warnings and short call-back holds perform better than generic warnings; measure by A/B test.
• LLMs in the loop: classification of scam narratives, agent assistance and warning generation are in production at leading banks. They are not trusted for the release decision.
• Adversaries adapt: deepfake voice and AI-written scripts raise the quality of social engineering, and criminals shift to fresh mule accounts and instant rails. Scores degrade fast; plan weekly monitoring and rapid retraining.
• Limits and failure modes: delayed and incomplete labels; false positives that block genuine large payments (house purchases, vehicle sales); vulnerable-customer handling; privacy of behavioural data; cold-start for new accounts.

Shared resources & combinations

• Same building blocks (tabular-ml, graph-ml, anomaly-detection, streaming): ANOM-001 (card and unauthorised payment fraud, same feature store and scoring service), ANOM-002 (AML monitoring: mule findings feed SARs and vice versa), ANOM-023 (crypto off-ramp flows), ANOM-004 (platform fake accounts and bots, device and behaviour features).
• Upstream signals: ANOM-014 (onboarding identity checks catch account-opening mules), ANOM-025 and ANOM-024 (scam-call and telecom fraud signals), ANOM-016 (screening hits as additional risk features).
• Shared infrastructure: one streaming platform, feature store, graph database and case-management/workflow engine can serve all fraud and AML queues; one on-prem LLM (HW2/HW3) serves case summaries across them.
• Customer-facing: warning texts and call-back scripts can reuse the multilingual generation stack of customer-service use cases.

Effort, cost & KPIs

• Path A: about 6–12 months including data integration, front-end warning flows, agent processes and regulatory validation; licences scale with payment volume.
• Path B: 6–12 months for a build with an experienced fraud-data team; cost drivers are data engineering, latency engineering and model governance, not API fees.
• Path C/D: multi-year programme with a dedicated data-science, platform and model-risk team.
• KPIs: scam loss per million payments (basis points of volume), detection rate at fixed false-positive rate, share of held payments that were genuine, customer-abort rate after warnings, time to restrict a mule account, funds recovered, reimbursement cost per case, mule accounts detected before first victim payment, agent handling time, model drift and fairness across customer groups.

People & change

Involve management and the head of fraud first, then IT security, the data protection officer, compliance and the model-risk function. Fraud agents, who call customers on held payments, are the key end users and should join design and testing from the start. Customer-facing warning texts need input from legal and customer service.

Works council: yes in practice, because agent consoles and case tools log individual handling times and decisions and are objectively suited to monitor performance (§87(1) no. 6 BetrVG); inform it early under §90(1) no. 3 and consider an expert under §80(3). Data protection: a DPIA is likely (systematic evaluation of customers at scale), with processor agreements for every vendor (Art. 28 GDPR) and DPO involvement; customers keep the final say after an effective warning, so no purely automated decisions with legal effect.

AI literacy measures (AI Act Art. 4) should support agents and analysts in reading scores and reason codes. Start with a pilot in one channel or customer segment in shadow mode, then enable warnings. Typical concerns are customer friction from false positives and agent monitoring; address them with KPIs on false-positive rates and a written agreement that metrics are not used for individual performance rating. See GUIDE-004, GUIDE-005 and GUIDE-010.

Risks, regulation & compliance

• EU AI Act: Annex III point 5(b) high-risk covers creditworthiness and credit scoring of natural persons but expressly excludes AI systems used to detect financial fraud [5]. Typical APP/mule detection is therefore not high-risk; classification is minimal. It can become high-risk if the same scores are reused for credit or essential-services decisions, or if applied by law enforcement. Art. 5(1)(d) prohibits assessing individuals' risk of offending solely on profiling; mule scoring must rest on objective account behaviour and be reviewed by humans before an account is closed.
• GDPR: legal basis typically legitimate interest and legal obligation for fraud prevention; behavioural biometrics may touch Art. 9 if they identify a person, so do a DPIA and minimise. Art. 22 limits solely automated decisions with significant effects: account closure or long freezes need human review and a way to contest. Sharing mule data between banks needs an explicit legal basis; watch tipping-off rules in AML law.
• Payments and sector law: PSD2 strong customer authentication, the Instant Payments Regulation (VoP, fraud-screening duties) [2], the upcoming PSD3/PSR [3], UK PSR reimbursement rules [1], DORA (ICT risk, third parties), AMLR (EU) 2024/1624 for reporting duties, and BaFin / EBA guidance on fraud reporting and model risk.
• Risks and mitigations: false positives blocking genuine customers (tune friction, offer fast agent release); discrimination against vulnerable or non-native-language customers (fairness tests, vulnerable-customer flags); over-reliance on LLM summaries (cite source data, human sign-off); adversarial adaptation (continuous monitoring); data leakage to LLM APIs (masking, EU region, no training on customer data).
• Sensitive-domain note: this page describes defensive fraud prevention only and gives no guidance on evading detection.

Getting started

1. Baseline your APP losses, reimbursements and mule cases by typology and channel; define the label pipeline including delayed victim reports.
2. Implement name-to-IBAN verification and dynamic, scam-specific warnings first; measure customer-abort rates.
3. Add session telemetry (remote-access, active-call, device) and payee-risk features to your existing scoring service; back-test on historic cases.
4. Build the mule view: inbound/outbound flow features and a payee graph; set a process for restriction, review and recovery requests.
5. Prepare governance: DPIA, AI Act classification note, vulnerable-customer procedures and contestation path.

Sources

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