Authorized Push Payment Fraud: Scam Detection Architecture, Behavioral Signals and Reimbursement Rules (2026)

Systems and architecture analysis only. This is not financial, legal or compliance advice; verify regulatory details against the primary sources before relying on them.

Every control a bank built over the last decade to stop card and account-takeover fraud rests on one assumption: the person authorizing the payment is not the criminal. Authorized push payment fraud breaks that assumption cleanly. The genuine customer logs in from their own phone, passes strong customer authentication, reads the payee details, and taps send, because someone on the other end of a call, a chat or a fake invoice has convinced them it is the right thing to do. Nothing about the credentials, the device or the session is stolen. The only thing forged is the customer’s understanding of what they are doing.

That makes it the hardest fraud class for engineers to attack, and the one where regulators have moved liability onto the payment industry. In the UK, the Payment Systems Regulator (PSR) rules in force since 7 October 2024 require most victims to be reimbursed, with the cost shared between sending and receiving firms; the EU’s Payment Services Regulation deal is following a similar path. This article walks through the mechanism, the scam taxonomy, the detection signals, a real-time decisioning architecture with friction orchestration, mule detection, worked cost trade-offs, evaluation, and the failure modes that make this problem adversarial.

What this covers: why authorized fraud defeats SCA, the scam taxonomy, UK and EU reimbursement rules as of this writing, the signal families (payee, session, behavioral, call-in-progress, mule graph), a reference architecture, friction versus false-positive economics with illustrative numbers, receiving-bank controls and consortium data sharing, evaluation metrics, and failure modes such as coached victims and concept drift.

Context and Background

Payment fraud used to be a story about stolen things: card numbers, passwords, one-time codes. Controls followed the theft. Tokenization, 3-D Secure, device binding, and in Europe the PSD2 requirement for strong customer authentication (SCA) all raise the cost of using a stolen credential. They have worked: unauthorized fraud losses in many markets have been flat or falling relative to volume. The criminal response was to stop stealing credentials and start stealing decisions.

The scale in the UK shows why this matters. UK Finance’s Annual Fraud Report 2026, as summarised by trade press, reports APP scam losses of about 576.4 million pounds in 2025 across roughly 248,000 cases, a 19 percent rise in value on the prior year. Investment scams were the largest category by value at about 221.5 million pounds, while purchase scams were the most common by count at roughly 71 percent of cases. Banks reimbursed about 354.3 million pounds, around 61 percent of losses, and the PSR has reported a much higher reimbursement rate for in-scope claims under the new regime. Treat these as reported figures and check the UK Finance report for the exact definitions, because “reimbursed share of total losses” and “reimbursed share of in-scope claims” are different denominators.

The industry’s first systemic response was Confirmation of Payee (CoP) in the UK, a name-check service that lets the sending bank ask the receiving bank whether the account name entered matches the account at that sort code and account number. The EU’s equivalent, Verification of Payee (VoP), became a requirement of the Instant Payments Regulation, and we cover its design in our analysis of Verification of Payee in instant payments. Name checks are necessary and effective against one scam family, but as the rest of this article shows, they are one signal among many, and a determined fraudster can route around them.

The second response was liability. Once a sending bank bears the loss for a payment it cannot technically distinguish from a legitimate one, the economics of detection change. A detection model no longer exists to protect a customer in the abstract; it exists to avoid a cost the bank now books directly, and to avoid the opposite cost of blocking good payments and losing the customer. That framing, an explicit loss function with two sides, is the one used throughout this piece. For the instant-rail context, see also our piece on SEPA Instant, VoP, FedNow and RTP fraud architecture.

Why the usual controls do not transfer

Four properties make APP fraud structurally different from account takeover or card-not-present fraud.

First, the authentication is genuine. SCA proves possession of a device and a knowledge or inherence factor; it says nothing about intent or comprehension. A risk engine tuned on “is this the real customer?” sees a perfectly real customer.

Second, the payee is novel but plausible. Real customers add new payees every week. Rent, a builder’s deposit, a conveyancing solicitor, a used-car seller: all of these look identical to a scam payee at the moment of creation.

Third, the amounts are within the customer’s behavioral envelope when the scammer is patient. Coached victims are told to move money in stages, to say the transfer is for “home improvements”, and to ignore warnings.

Fourth, the instant rail removes the recall window. On Faster Payments, SEPA Instant, FedNow or RTP, settlement is final in seconds. The window to intervene is the few seconds between the customer tapping send and the bank releasing the payment, plus any friction the bank deliberately inserts earlier in the flow.

The Scam Taxonomy and the Core Detection Architecture

Detection starts with knowing what kind of story the victim has been told, because each story leaves a different footprint in the data. There is no single “scam model”; there are several overlapping hypotheses that a decision engine must score at once.

Scam family	The story	Typical rail footprint	Strongest signals
Bank or police impersonation	“Your account is compromised, move money to a safe account”	Large, urgent, first-time payee, often immediately after a phone call	Call in progress, remote-access tool, hesitation and cadence anomalies, mule-risk payee
Investment	Fake broker or crypto platform, returns shown on a dashboard	Repeated, escalating payments to a series of new payees or exchanges	Payee category, rising amounts, ads-driven origin, payee name and merchant category mismatch
Romance	Long grooming, emergency needs	Many payments over weeks, rising amounts	Slow-burn velocity change, payee clustering, message-length behavioral shift
Purchase	Fake listing on a marketplace	Low value, very high volume, often first-time payee	Marketplace referral, payee age, mule graph features
Invoice and mandate redirection	Genuine supplier, altered bank details	Business or high-value payment to a changed account	Payee changed for existing relationship, name mismatch, new account age
Advance fee and other	Fake fees to release a prize or loan	Small repeated payments	Payee reputation, narrative text

The table is deliberately about footprints rather than victims. A detection stack that organizes by footprint can reuse signals across families: a payee that is a recently opened account receiving funds from a dozen unrelated senders is suspicious whether the story was romance or purchase.

The reference architecture

The reference design is a streaming decision pipeline that runs inline on the payment path. It scores every outbound push payment before release, consumes features from three timescales, and does not simply return “block or allow”. It returns an action from a menu of frictions, which is the single most important design choice in the whole system.

Figure 1: Authorized push payment fraud decision pipeline, from the customer channel through feature assembly and scoring to a friction orchestrator.

Figure 1 shows the flow. The customer channel (mobile app or web) emits two things: the payment instruction and a stream of session telemetry. The payment instruction goes to a payment gateway that calls the decision service before releasing to the rail. The telemetry goes to a behavioral signal service. The decision service assembles a feature vector from the online feature store (customer history, payee reputation, graph features), from the session signals, and from external checks such as Confirmation of Payee or Verification of Payee. A model plus a rules layer produces a risk score and a scam-hypothesis vector. A friction orchestrator then maps risk and hypothesis to an action.

The long-form description matters for accessibility and for how the system is operated: the left side of the diagram is everything the bank knows before the payment (slow and medium-timescale features), the middle is the real-time scoring, and the right side is the action menu. Case management and feedback loops write back into the feature store, so confirmed scam payees raise the reputation risk of the next sender.

Direct answer: what is a good APP fraud decision engine?

A good APP fraud decision engine scores each outbound payment in tens of milliseconds, combines payee, session, behavioral and graph features with a model and explicit rules, and returns a graded friction action instead of a binary block. It is evaluated on precision at very low false-positive rates, because the cost of interrupting legitimate payments is the binding constraint.

Three feature timescales

Slow features change over days to months: the customer’s typical payment sizes, payee counts, tenure, device history, vulnerability flags, and long-run behavioral baselines. These live in the offline store and are materialized into the online store on a schedule. They answer “what is normal for this customer”.

Medium features change over minutes to days: the number of new payees added in the last 24 hours, the sum sent in the current day, whether the customer’s contact details or limits were recently changed, and the payee’s rolling inbound statistics (how many distinct senders paid this account in the last hour). These need a streaming aggregation layer, typically a stateful stream processor with windowed counts.

Fast features are the current session: typing cadence, navigation path, whether a screen-sharing or remote-access application is running, whether a call is active, how long the customer dwelled on the payee confirmation screen. These arrive with the payment and must be computed in-process or from a very low-latency session store.

A subtle point: the slow and medium features are mostly about the payee side, while the fast features are mostly about the sender’s state of mind. The combination is what separates a nervous homebuyer from a victim being walked through a payment by a stranger.

Latency budget

The payment gateway needs an answer quickly. A common internal target for inline fraud decisions is a few tens to low hundreds of milliseconds at the 99th percentile, but this is a design choice, not a standard; verify against your own rail’s timeout and customer experience budget. A workable allocation, illustrative only:

Stage	Illustrative p99 budget
Gateway to decision service	5 ms
Online feature store lookups, parallel	15 ms
Session signal fetch	10 ms
Payee name check (CoP or VoP), cached or live	20 to 150 ms depending on counterparty
Model inference plus rules	10 ms
Orchestrator and response	5 ms

The name check is usually the long pole because it crosses to another institution. Many designs run it earlier in the flow, when the customer enters the payee details, so the result is already available when the payment is submitted. That is also better for the customer, who sees the mismatch before committing.

Deeper Analysis: Signals, Friction and Mule Detection

Payee signals and Confirmation of Payee

The payee is the cheapest and most reliable place to look, because the criminal must eventually receive money into an account that the financial system can observe. Useful payee-side features include account age, the number of distinct senders in rolling windows, the ratio of inbound to outbound value, how quickly funds leave after arrival, whether the account was opened with thin-file identity evidence, and whether the sending customer has ever paid it before.

Confirmation of Payee in the UK returns one of a small set of outcomes: a match, a close match (with the correct name revealed for the sender to see), a no-match, or “unable to check”. The check protects against misdirection, where an invoice or a typo sends funds to the wrong account, and it deters a basic fraud pattern where the scammer gives an account in a different name from the claimed company. Its limits are well understood: a criminal who controls a mule account opened in the right name for the story (“Lloyds Conveyancing Ltd” is not available, but a name-alike limited company can be registered) can pass a match. And where the check returns “unable to check”, the signal degrades to uncertainty. The EU Verification of Payee mechanism has the same strengths and the same limits; design the engine to treat the result as a feature with a calibrated weight rather than as a pass/fail gate.

A practical pattern is to treat name-check outcomes as a three-way feature crossed with payee novelty:

Name check	Payee known	Payee new
Match	Low risk contribution	Mild uplift; depends on payee account age and inbound graph
Close match, customer accepted	Mild uplift	Moderate uplift, because the customer overrode a warning
No match, customer proceeded	Strong uplift	Strongest uplift of the name-check family
Unable to check	Neutral	Mild uplift, scaled by payee-side features

The key insight is that the override is itself a behavioral signal. A customer who sees “the name does not match” and proceeds, especially after a long dwell, is either confident or coached; the model must learn which from the rest of the session.

Session signals and remote-access detection

Remote-access and screen-sharing applications are the classic enabler of the bank-impersonation scam: the fraudster asks the victim to install a tool “to secure the account” and then watches, or even drives, the session. Mobile operating systems and apps can detect several indicators: the presence of a known remote-control application in the process list where the platform permits it, an active screen-capture or screen-mirroring session, accessibility services enabled for an unfamiliar package on Android, overlay windows drawn over the banking app, or input events with synthetic characteristics. Platform policies differ and evolve, so verify what your OS version and app permissions let you observe, and treat each indicator as a probabilistic feature, not proof. Some indicators are also benign: accessibility services used by screen readers must never be a blunt block signal, both for fairness and for accessibility law.

Other session features that carry information include whether the session began with a login shortly after a new-device registration, whether the customer navigated directly to a payment screen without the usual balance check, and the time since a limit change. None is decisive; together they shape the prior.

Behavioral biometrics

Behavioral biometrics model how a person interacts with the device: touch pressure and swipe geometry on mobile, keystroke dynamics and mouse movement on desktop, and accelerometer and gyroscope data as the phone is held. Vendors originally used these to detect account takeover, comparing the session to the genuine user’s baseline. For APP fraud, the same raw signals support a different question: is this customer behaving as they normally do, under duress or instruction?

Reported indicators of coached sessions include unusually long pauses between fields (the victim is listening), a distinctive hesitation pattern on the amount field, typing the payee details character by character as if dictated, a phone held to the ear while interacting (detectable via proximity and orientation), and sudden erratic navigation as the caller redirects. These are population-level patterns reported by vendors and in the literature, not guarantees; individual customers vary widely, and any model must be validated on your own data and monitored for demographic bias. A senior customer who types slowly is not a fraud signal.

Two engineering cautions. First, behavioral features require consent and lawful basis under data protection law (in the EU and UK, treat behavioral biometrics used for identification as potentially special-category data and consult counsel); minimize retention and keep raw telemetry out of the long-term store. Second, the signal is session-local and cannot be backfilled; if you do not capture it at payment time, you cannot train on it later, so instrument early.

Call-in-progress and telecom signals

The impersonation scam depends on a live phone call. If the bank can learn that the customer’s mobile is on an active call at the moment of the payment, that is a high-value feature. Two routes exist. On-device, the app may read call state where the OS allows it (with strong privacy limits, and platform rules vary). Network-side, telecom operators or network-API initiatives such as the CAMARA project’s fraud-oriented APIs (for example, call forwarding and SIM swap checks) can expose signals, subject to commercial availability and consent. Verify the current API set and your market’s availability before designing around them; do not assume global coverage.

A call-in-progress flag is not a standalone block. A customer talking to their spouse while paying a plumber is common. The flag becomes powerful in combination: active call, new payee, amount above typical, and a no-match name check together move the posterior sharply.

The mule-account graph

Every APP scam needs a money mule: an account that receives the victim’s funds and passes them on. Mules are often recruited through job adverts, social media or romance, and many are themselves victims, which matters for fairness and for law-enforcement handling. For the receiving institution, the mule account is the observable object; for the sending bank, the mule account is the payee.

Figure 2: Mule network structure in authorized push payment fraud: many victims pay first-layer mules, funds fan in, hop to second-layer accounts, and exit via cash, crypto or international transfer.

Figure 2 shows the structure that graph features exploit. Victims pay into first-layer mule accounts (fan-in); funds hop quickly to a smaller number of second-layer accounts (consolidation); and exits occur through cash withdrawal, crypto exchange or cross-border rails. Useful graph features include: in-degree of the payee over a window; the count of distinct senders with no prior relationship; pass-through ratio and dwell time (money in, money out within minutes); shared devices, addresses or phone numbers across supposedly unrelated accounts; and proximity (graph distance) to accounts already confirmed as mules.

Graph methods range from simple SQL-computed aggregates materialized in the feature store to graph neural networks that propagate risk labels. In practice, hand-built features such as “number of new senders in the last hour” and “minutes between credit and debit” capture most of the signal at far lower operational cost. Heavier graph machine learning pays off at institutions with large account bases and a mature labeling pipeline.

Friction orchestration

The decision engine’s output is an action. A well-designed orchestrator offers a ladder rather than a switch.

Figure 3: Friction orchestration for authorized push payment fraud: a graded response ladder from allow, through tailored warning and confirmation questions, to call-back, delayed release and decline.

The ladder in Figure 3 has these rungs, from least to most intrusive:

Allow, with passive logging. The vast majority of payments.
Tailored warning: a short, scam-specific message shown at the moment it is relevant. The PSR’s reasoning on the “consumer standard of caution” depends on warnings being specific and prominent; generic “be careful of scams” banners are widely regarded as ineffective because customers habituate to them.
Dynamic questions: “What is this payment for?” with a dropdown, followed by a message tailored to the answer, such as a conveyancing warning for “buying a property”. Coached victims often pick the false answer they were told to choose, so the answer is also a feature: a stated purpose that contradicts the payee category or the customer’s history raises risk.
Interactive friction: a forced pause, a mandatory video or a confirmation screen requiring the customer to type a phrase. Intended to break the caller’s script.
Out-of-band step-up: a call-back from the fraud team on a trusted number, or an in-app secure chat, before release.
Delayed release and hold: holding an outbound payment for a bounded period for review, where rules allow (the UK’s Payment Services Regulations amendments allow firms to delay certain payments for fraud checks for a limited period; verify current provisions and conditions).
Decline, with a clear route to complete a genuine payment after verification.

Two principles govern the ladder. Friction must be proportional and adaptive, so the same customer who pays rent monthly never sees it. And friction must be measurable: each rung should be logged with an experiment arm, so you can estimate its causal effect on scam interdiction and on abandonment of genuine payments.

A minimal scoring and orchestration sketch

The following Python sketch shows the shape of an inline decision function: feature assembly, a rules layer for hard conditions, a model score, and a ladder mapping. It is illustrative, not production code; feature names, thresholds and the model are placeholders.

from dataclasses import dataclass
from enum import IntEnum

class Action(IntEnum):
    ALLOW = 0
    WARN = 1
    ASK = 2
    PAUSE = 3
    CALLBACK = 4
    HOLD = 5
    DECLINE = 6

@dataclass
class Features:
    amount_ratio: float          # amount / customer's 90-day p95 payment
    payee_is_new: bool
    name_check: str              # match | close | nomatch | unavailable
    name_check_overridden: bool
    payee_account_age_days: int
    payee_new_senders_1h: int
    payee_pass_through_min: float  # median minutes credit-to-debit
    remote_access_flag: bool
    call_in_progress: bool
    dwell_seconds_confirm: float
    purpose_mismatch: bool
    vulnerable_customer: bool

def rules_floor(f: Features) -> Action:
    """Hard conditions that set a minimum friction level."""
    if f.remote_access_flag and f.payee_is_new:
        return Action.CALLBACK
    if f.name_check == "nomatch" and f.name_check_overridden and f.payee_is_new:
        return Action.PAUSE
    if f.payee_new_senders_1h >= 8 and f.payee_account_age_days < 14:
        return Action.HOLD
    return Action.ALLOW

def decide(f: Features, model) -> Action:
    p_scam = model.predict_proba(f)          # calibrated probability
    floor = rules_floor(f)

    # Ladder thresholds come from the cost model, not from taste.
    if p_scam >= 0.60:   ladder = Action.HOLD
    elif p_scam >= 0.25: ladder = Action.CALLBACK
    elif p_scam >= 0.08: ladder = Action.PAUSE
    elif p_scam >= 0.02: ladder = Action.ASK
    elif p_scam >= 0.005: ladder = Action.WARN
    else:                ladder = Action.ALLOW

    action = max(floor, ladder)
    if f.vulnerable_customer and action >= Action.ASK:
        action = max(action, Action.CALLBACK)  # route to a human sooner
    return action

The thresholds in decide are the interesting part. They should be set by the expected-cost calculation in the next section, one threshold per rung, using each rung’s own cost and effectiveness, not by choosing round numbers.

Economics: Tuning Friction Against False-Positive Cost

APP fraud is an asymmetric-cost decision. Interdicting a scam saves the loss share the bank bears; interrupting a genuine payment costs customer time, support effort, abandonment and attrition risk. Both costs depend on friction type, so the right way to tune is per-rung expected cost.

A worked illustrative example

All numbers below are invented for illustration. Suppose a bank processes 10 million outbound push payments per month. Suppose 0.05 percent are APP scams, so 5,000 scam payments, with an average value of 3,000 currency units. Gross scam exposure is 15 million per month. Suppose, per a regime like the UK’s, the bank reimburses 90 percent of scam value after recovery from the receiving side of 50 percent and some funds recovered, giving a net bank cost of roughly 40 percent of value for these scams. The net exposure is then about 6 million per month, or 1,200 per scam on average.

Now consider a model with an operating point that flags 1 percent of all payments for friction (100,000 payments) and catches 70 percent of scams at that threshold. Of the 100,000 flagged, 3,500 are scams and 96,500 are genuine. Precision is 3.5 percent. Now assume each rung of friction has a cost on a genuine payment, and an interdiction rate on scams.

Rung	Cost per genuine payment	Scam interdiction rate (assumed)	Share of flagged payments
Tailored warning	0.10	20%	70%
Dynamic questions	0.50	35%	20%
Pause and confirm	1.50	50%	7%
Call-back	12.00	85%	3%

Cost of friction on genuine payments: 96,500 times the weighted cost. The weighted cost is 0.7 times 0.10 plus 0.2 times 0.50 plus 0.07 times 1.50 plus 0.03 times 12.00 = 0.07 + 0.10 + 0.105 + 0.36 = 0.635. Multiplying by 96,500 gives roughly 61,000 per month. Scam value saved: 3,500 flagged scams times the weighted interdiction rate (0.7 times 0.20 + 0.2 times 0.35 + 0.07 times 0.50 + 0.03 times 0.85 = 0.14 + 0.07 + 0.035 + 0.0255 = 0.2705) is about 947 scams interdicted, times 1,200 net cost, or roughly 1.14 million per month saved.

On these invented numbers, friction is overwhelmingly worthwhile: about 1.14 million saved for about 61,000 of friction cost, a ratio near 19 to 1. The lesson is not the ratio, which depends entirely on assumptions, but the structure. The marginal analysis matters: moving the flag rate from 1 percent to 2 percent adds mostly genuine payments (low precision at the margin), and the marginal ratio falls quickly. The optimum is where the marginal cost of the next unit of friction equals the marginal expected loss avoided.

Marginal cost, not average

Define the score threshold t. For payments with score above t, expected cost of intervention per payment is c_f (the weighted friction cost) and the expected benefit is P(scam | score) * I * L, where I is interdiction effectiveness and L is net loss per scam. You should intervene while P(scam | score) * I * L > c_f. With c_f = 0.635, I = 0.27, and L = 1,200, the breakeven scam probability is 0.635 / (0.27 * 1200), about 0.2 percent. Any payment whose calibrated scam probability exceeds about 0.2 percent is worth some friction under these assumptions. Note that this requires calibrated probabilities, not just a good ranking. A model that ranks well but is miscalibrated will place thresholds wrongly.

Hidden costs complicate the picture. Abandonment of genuine payments (a customer who gives up and pays by another channel) loses revenue and trust. Vulnerable customers who are genuinely helped by friction should be weighted, and regulators care about outcomes for them. And scammers adapt: if friction is predictable, coaching scripts adapt, which lowers I over time. Track I as a time series, not a constant.

The reimbursement cost loop

Under mandatory reimbursement, the sending bank’s cost includes its share of reimbursement. Under the UK rules, the sending and receiving firms split the reimbursement cost 50:50 (check the PSR’s current policy statements for any recalibration from its independent review, which was reported as under way with findings expected in 2026 to 2027). That makes the receiving bank’s mule controls financially significant, not merely a compliance matter. It also creates an incentive to reduce the receiving side’s exposure by detecting mule accounts at onboarding and during their active life.

Figure 4: Reimbursement cost flow under a UK-style regime: the sending firm reimburses the victim, then recovers half from the receiving firm; both firms invest in detection to reduce their share.

Figure 4 shows the settlement path conceptually: claim, assessment, reimbursement by the sending firm within the regime’s deadlines, then inter-firm recovery of the receiving firm’s share through the scheme’s reimbursement claims management system. The PSR’s reported timelines are five business days for most claims, extendable (with a “stop the clock” mechanism) up to 35 business days where more information is needed. The maximum reimbursement per claim was set at 85,000 pounds in the PSR’s October 2024 policy statement, lower than the 415,000 pounds first proposed. Operators should confirm current limits, any excess, and the claim window against the live rules, since these are exactly the parameters the review could change.

The EU direction

On the EU side, the Payment Services Regulation (PSR) and PSD3 reached a provisional political agreement announced on 27 November 2025, according to law-firm summaries; formal adoption and a transition period (reported as around 21 months) follow. Reported elements include mandatory payee-name verification, an obligation for payment service providers to share fraud information with one another, refund obligations where a fraudster impersonates the provider’s own staff and the customer reports to the police, and a route for providers to claw back from online platforms that failed to remove reported fraudulent content. Because the texts were still being finalized at the time of the sources consulted, treat all of this as reported and check the Official Journal text for the final scope. Note also the naming collision: “PSR” means the UK Payment Systems Regulator in one jurisdiction and the EU Payment Services Regulation in the other.

A sending bank sees one side of each scam: a customer who is about to pay. The receiving bank sees the other: an account that may be receiving money from strangers. Neither has the full picture, which is why the most effective controls combine both and why regulatory design pushes cost to the receiving side.

Inbound payment screening

Receiving institutions can score inbound credits in the same pipeline architecture. Features include the sender’s own risk score (if shared), the number of first-time senders to this account, narration text patterns, and the account’s expected profile at onboarding (declared occupation and expected turnover versus actual inflows). Risk actions differ: hold the credit pending review, restrict outbound movement of funds from newly credited balances, or place a delay on first-time large outbound transfers from young accounts. Because mule money is typically moved out within minutes, even a short, rules-compliant delay on outbound transfers from high-risk new accounts shrinks the loss.

Mule account lifecycle

Mule controls span the whole account life: onboarding (identity verification quality, document and liveness checks, device and network fingerprints linked to other accounts), early-life monitoring (the first 30 to 90 days carry disproportionate mule risk), and exit (closing and reporting). The practical metric is time to detect: how many minutes or hours elapse between the first suspicious credit and a restriction. Each additional hour of delay is more victims’ money gone.

Single-institution models are weak where it matters most: a mule account that has just been opened and has done nothing yet. Sharing fraud intelligence across institutions raises the base rate of true signals. Models in practice include: consortium services where participants pool confirmed fraud account indicators; bilateral intelligence feeds; central scheme-level services in some markets; and the regulatory data-sharing duties in the EU reform. Legal basis, data-minimization and liability for false reports are the hard problems, not the technology. A privacy-preserving approach, such as exchanging salted or tokenized identifiers or using private set intersection to ask “have you seen this account?” without revealing your full list, reduces exposure, but should be validated with counsel and with the particular consortium’s rules.

The labels that flow through these channels are also the training data for every model in the system. Poor label quality, such as marking a payee as a mule because one customer disputed a purchase, pollutes the graph. Insist on a confirmed-fraud taxonomy, and keep “reported” and “confirmed” as separate states with their own latency.

Evaluation: Precision at Low False-Positive Rates

Standard classification metrics mislead here. With a base rate near 0.05 percent, a model with 99 percent accuracy can be useless, and area under the ROC curve hides the region that matters, because operations can only tolerate a flag rate of perhaps 0.5 to 2 percent of payments.

Metrics that matter

Evaluate at the operating point. Useful measures:

Precision at a fixed alert rate (or at fixed false-positive rate): of the top 1 percent scored payments, how many are scams.
Recall (value-weighted) at the same alert rate: what share of scam value is covered, because a miss on 50,000 matters more than ten misses on 50.
Detection value rate: scam value interdicted divided by total scam value, per scam family.
Customer friction rate: share of genuine payments that see rung 3 or above; and abandonment on those rungs.
Time to interdict, for mule detection.
Calibration error (expected calibration error or reliability diagrams), since thresholds are derived from the cost model.

Report these by segment: age band, vulnerability flag, channel, payment size and scam family. An aggregate number can hide a model that does well on investment scams and badly on romance scams.

Label problems and evaluation traps

Labels arrive late. Many scams are reported days or weeks after the payment, so a model trained and evaluated on last month’s data sees an incomplete positive set. Use label maturity windows: evaluate on cohorts old enough that most scams have been reported, and track the reporting-delay distribution. A second trap is selection bias from friction: when your system blocks or warns a payment, you never learn whether it would have been a scam; the outcome is censored. Hold out a small randomized, ethically reviewed control group (for instance a lower rung only, never allowing a high-risk payment to complete unexamined) to estimate intervention effects without bias. A third trap is data leakage from features computed after the payment, such as payee statistics that include the payment itself or the later fraud flag.

Backtesting should be time-split, not random: train on months one to six, test on months seven and eight. Random splits leak scammer behavior across the boundary and overstate performance.

Offline-to-online gap

Offline precision at the target alert rate is an upper bound on online precision because the scammer population shifts. Run new models in shadow mode (scoring without acting) for several weeks, compare to the production model, and then ramp through a canary percentage with an experiment framework. Track the metrics above by cohort during the ramp.

Trade-offs, Gotchas, and What Goes Wrong

Coached victims. The strongest adversary is a scammer on the phone who has rehearsed the bank’s warnings and tells the victim exactly what to say. This defeats warning-based friction and dynamic questions, and it explains why the best signals are the ones the victim does not control: payee-side graph features, device state, remote-access indicators and out-of-band contact. A call-back to a number the bank holds on file, rather than one the victim supplies, is stronger than any on-screen text. Even so, long-con victims, such as romance and investment cases, may resist human intervention because they trust the scammer more than the bank. Some institutions train staff for conversation techniques and escalate to law enforcement or to a banking protocol; effectiveness varies.

Concept drift. Scam scripts, mule recruitment channels and payee patterns change quickly. A model trained on last quarter’s scams decays: precision at fixed alert rate drops, and nobody notices because the lost cases arrive as claims months later. Monitor input feature distributions (population stability), score distribution, alert rate and, as labels mature, performance by cohort. Retrain on a regular cadence and keep a fast-path rules channel so analysts can deploy a new pattern in hours.

Friction fatigue. Overuse of rung 2 and 3 warnings trains customers to click through. If more than a tiny share of customers see a warning on most payments, effectiveness collapses. Rank warnings by specificity and show fewer of them.

False-positive harm is not evenly distributed. Customers who legitimately make large irregular payments (buying a house, paying a builder, moving savings, small business owners) are most likely to be interrupted. Customers with limited digital literacy or accessibility needs find friction harder. Regulatory regimes include vulnerable-customer provisions, and a model that flags older customers more often must be validated for fairness. Design the decline path so a genuine payment can be completed after verification, rather than leaving the customer stranded.

The ‘authorised’ edge case. Reimbursement rules distinguish between a scam and a civil dispute (goods not as described), and between a scam and first-party fraud where the claimant is complicit. Misclassifying these in claims handling creates both cost leakage and wrongful denials. Claims analytics is its own pipeline and shares labels with the detection model.

Privacy and consent. Behavioral telemetry, device state and call-state signals are personal data. Document the lawful basis, minimize retention, and avoid using signals the platform or regulator forbids. A feature that cannot legally be collected in a market must not be silently imported from a model trained elsewhere.

Latency tails and fail-open decisions. When the decision service times out, the gateway must pick a default. Fail-open (allow) protects customer experience but is exactly what a scammer would aim to trigger by, for example, overloading a dependency. Fail to a conservative fallback such as a simple rules engine running locally with the last-known features, and alert on timeouts.

Saga-style failure handling. Holding, releasing and recalling a payment involves several systems: the core ledger, the payment rail, case management and the notification service. If a hold is placed but the ledger posting fails, or a release is sent twice, you create reconciliation breaks. Model the flow as a saga with compensating actions; our guide to saga orchestration versus choreography and compensating transactions covers the pattern, and it applies directly to payment holds.

Practical Recommendations

For teams building or reviewing an APP fraud stack, the following ordering tends to produce the most reduction for the least complexity, subject to your own data and regulatory context.

Begin with the payee side. Payee name checks (CoP or VoP), payee account age and inbound-sender counts are cheap, explainable and valuable, and they feed both sending and receiving controls. Next, get the telemetry in place (session, device, remote-access indicators) before building models on it, because those features cannot be backfilled. Third, build the friction ladder with experiment hooks from day one so every rung has measured effect. Fourth, derive thresholds from a cost model with calibrated probabilities. Fifth, invest in receiving-side mule detection and time-to-detect, because the shared-liability design makes it financially material. Finally, establish label governance and a consortium or data-sharing arrangement.

A short checklist:

[ ] Name check result and override captured as features and logged.
[ ] Payee graph features (new senders, pass-through, account age) in the online store.
[ ] Remote-access, call and overlay indicators captured where legally and technically permitted.
[ ] Graded friction ladder with per-rung experiment arms and abandonment tracking.
[ ] Calibrated model; thresholds derived from expected cost, reviewed quarterly.
[ ] Time-split backtests, label maturity windows, shadow and canary rollout.
[ ] Fail-safe fallback on decision-service timeout, with alerting.
[ ] Vulnerable-customer routing and fairness monitoring.
[ ] Mule detection at onboarding, in early life, and on inbound credits; time-to-detect tracked.
[ ] Claims analytics aligned with regulatory reimbursement rules and review milestones.

Remember the disclaimer: this is systems analysis, not advice; consult compliance and legal functions for obligations that apply to your institution.

Frequently Asked Questions

What is authorized push payment fraud?

Authorized push payment fraud, often shortened to APP fraud, is a scam in which the victim themselves instructs their bank to send money to an account controlled by a criminal. The customer is deceived, for example by a fake bank call, a fake investment or a fake invoice, but the payment is properly authenticated. Because credentials and devices are genuine, controls designed for unauthorized fraud, including strong customer authentication, do not stop it on their own.

Does strong customer authentication stop APP fraud?

No. SCA verifies that the person initiating a payment is the account holder, using two independent factors. In APP fraud the account holder is the one initiating the payment, so SCA passes. SCA does give a useful audit trail and can be combined with transaction risk analysis, but defending against APP scams requires signals about intent and context: payee risk, session anomalies, behavioral patterns, call state, and out-of-band verification for risky payments.

How does Confirmation of Payee help against scams?

Confirmation of Payee checks whether the name entered matches the name on the destination account, returning match, close match, no match or unable to check. It reduces misdirected payments and catches scams where the account name differs from the claimed recipient. It does not stop a criminal who holds a mule account under a plausible name, so it is best used as one calibrated feature plus a warning, not as the only defence.

Who pays when a customer falls for an APP scam in the UK?

Under the Payment Systems Regulator’s rules in force from 7 October 2024, the sending firm reimburses most in-scope victims of Faster Payments and CHAPS APP scams, with the cost split 50:50 between sending and receiving firms. The reported maximum is 85,000 pounds per claim, with exceptions such as gross negligence and fraud by the claimant, and protections for vulnerable customers. An independent review is under way, so check the latest policy statements.

What is behavioral biometrics and is it reliable for scam detection?

Behavioral biometrics analyzes how a user interacts with a device, such as typing rhythm, swipe patterns and navigation, to detect anomalies compared with their baseline. For scam detection it can reveal hesitation, dictation-like typing or remote control. It is a probabilistic signal, not proof; it varies across people, can be biased if poorly validated, and has privacy requirements. It works best combined with payee and graph features.

How do banks detect money mule accounts?

Banks combine onboarding checks (identity and device linkage), early-life monitoring and graph analysis. Typical signals include many unrelated first-time senders, rapid pass-through of funds, young account age, shared devices or contact details with known mules, and inbound payment narratives that match scam patterns. Sharing confirmed mule indicators across institutions improves detection of newly opened accounts that have no history yet.