Authorized Push Payment Fraud Prevention With Behavioral Signals
Stopping Scam Payments the Customer Genuinely Authorised
Authorised push payment fraud is the fraud problem that defeats every control a bank spent the last decade building. Authentication succeeds because it is the real customer. Device checks pass because it is their device. The payment is within limits, to a valid account, with correct details, and the customer confirms it deliberately, sometimes twice.
The Payment Systems Regulator describes these as cases where someone is tricked into sending money to a fraudster posing as a genuine payee, and puts UK losses at £459.7 million in 2023. Prevention therefore cannot be about verifying identity, because identity is not in question. It has to be about reading intent and circumstance, on both sides of the payment, inside the seconds available before an irrevocable transfer settles.
Why is APP fraud different from every other fraud problem?
Because the customer authorised it, so every identity-based control passes and there is nothing to reverse afterwards.
On instant rails settlement is final, which removes the recovery mechanism traditional fraud economics assume. Recovery depends on asking the receiving institution to return funds that have often already moved on. That changes where controls must sit and what they must detect: not whether this is the right person, but whether this person is being deceived right now.
What does authorised actually mean for your controls?
That your only remaining levers are intent detection, intervention design, and receiving-side interception.
Intent cannot be observed directly, so it is inferred from circumstance and behaviour. Intervention is what you do with that inference, and its design determines whether the inference matters at all. Receiving-side interception is the underused third lever, because a fraudster's account behaves very differently from a genuine one even when the payer looks entirely normal. Any prevention programme that only works on the payer's side has given up two thirds of the available surface.
Why does the receiving side matter as much as the sending side?
Because mule account behaviour is often a clearer signal than anything visible on the payer's side, and because the cost is now shared.
Under UK rules, reimbursement costs are split equally between the sending and receiving firms, with most victims reimbursed within five business days and additional protections for vulnerable customers. That turns receiving-side detection from goodwill into direct financial self-interest. An account receiving unusual inbound value from unrelated parties, moving it onward within minutes, and showing onboarding characteristics typical of a recently opened mule is detectable, and detecting it protects both your own losses and your share of someone else's.
Is your APP programme entirely focused on the paying customer?
Which signals actually indicate a scam in progress?
Behavioural signals from the session, payee novelty, contextual anomalies, and receiving-side account patterns.
| Signal group | Examples | Strength |
|---|---|---|
| Session behaviour | Long hesitation on the amount field, repeated correction of payee details, unusually slow or unusually rushed entry, evidence of reading from another source | High when combined |
| Device and channel | New device, remote access tooling present, concurrent call activity where observable | High |
| Payee novelty | First payment to this payee, payee recently added, payee associated with prior reports | High |
| Payment context | Amount atypical for the customer, near a balance or limit, unusual time, sequence of escalating payments | Medium to high |
| Customer context | Age or vulnerability indicators, recent change of contact details, recent unusual login patterns | Medium, use carefully |
| Receiving side | Inbound from unrelated parties, rapid onward movement, account recently opened, mismatch with stated purpose | Very high |
What does behavioural intelligence add over rules?
It detects the pattern of a coached customer, which no static rule expresses.
Rules catch what you have already seen: a threshold, a new payee, a country. Behavioural intelligence catches how the payment is being made, which is where deception shows up. A customer being talked through a transfer by a stranger types differently, pauses differently, and navigates differently from one paying a builder they know. None of those signals is conclusive alone, which is exactly why they need a model rather than a rule, and why the model must combine them with payee and context features. The detection architecture is the same as any real-time scoring problem, and the precomputation constraints in this guide to real-time fraud detection apply without modification.
How is the threat itself changing?
Scams are becoming more convincing and more scalable, which raises the value of behavioural signals rather than lowering it.
Synthetic voice and generated text have made impersonation cheaper and more plausible, so controls that depend on a customer recognising a fake are weakening, as set out in this look at AI-enabled phishing and synthetic social engineering. What does not change is that a deceived customer behaves differently from an undeceived one, and that a mule account cannot hide its cash flow pattern. Both are structural signals rather than content signals, which is why they hold up as the deception gets better.
How should interventions be designed?
As a tiered ladder from targeted warning to hold and contact, with hard blocks reserved for the highest confidence.
| Risk level | Intervention | Cost to genuine customers |
|---|---|---|
| Low | Proceed, log for feedback loop | None |
| Medium | Specific named-scam warning matched to the pattern | Small |
| Medium to high | Dynamic questions about the payment's purpose and how it was arranged | Moderate |
| High | Short hold plus outbound contact attempt | Moderate to high |
| Very high | Block, with a clear route to review | High |
Why do generic warnings fail?
Because customers see them on every payment and learn to dismiss them.
A warning that says payments can be scams teaches nothing and gets clicked through. A warning that says this payment resembles an impersonation scam, that a genuine organisation will not ask you to move money to a safe account, and that asks whether someone contacted you first, engages the specific deception. Matching warning content to the detected pattern is one of the highest-return changes available, and it is a content and product decision more than an engineering one. Measure dismissal rates per warning type and rewrite the ones that are always dismissed.
When is delaying a payment the right control?
When the score is high and urgency is part of the scam, which it almost always is.
Scams depend on time pressure, so a short hold with an outbound contact attempt removes the mechanism rather than the payment. Design it explicitly: how long, who attempts contact, what happens if the customer cannot be reached, and how the customer overrides. Then measure outcomes, because holds that never change a customer's mind are pure friction while holds that stop a meaningful share are cheap insurance against an irrecoverable loss. Note that this control only exists if your platform can hold a payment without failing it, which is a design decision in the payment path rather than in the fraud engine, as covered in instant payment participation architecture.
What role does payee verification play?
It removes the misdirection cases and gives the scam detection model a strong feature.
Name checking catches wrong-account payments outright and provides a signal for everything else, since a scam payment frequently goes to an account whose name does not match what the victim believes. In the euro area, verification of payee has been required since October 2025 under the Instant Payments Regulation, and the PSR has overseen the continued rollout of confirmation of payee in the UK. Feed the verification outcome into the risk score rather than treating it as a separate gate, and design the close-match experience carefully, as discussed in confirmation of payee architecture.
Are your scam warnings generic enough that customers ignore them?
Talk to Digiqt about intervention design and warning effectiveness
How should receiving-side detection be built?
As continuous account behaviour monitoring, with onboarding signals retained and inbound patterns scored.
Mule accounts are identifiable from the pattern of use rather than from the identity behind them. Score inbound receipts from unrelated parties, rapid onward dispersal, mismatch between actual activity and stated account purpose at onboarding, clusters of accounts sharing devices or contact details, and dormancy followed by sudden throughput. Retaining onboarding data in a form the monitoring model can use is what makes this possible, which is why identity and onboarding architecture matters here, as described in this guide to digital onboarding and KYC automation. Then act: hold suspicious inbound credits before they can be dispersed, because a hold on the receiving side is the only intervention that still works after the payer has authorised.
What does shared liability change architecturally?
It makes receiving-side controls a funded priority and makes case data a shared asset.
When the receiving firm bears half the reimbursement cost, the business case for mule detection stops depending on reputational argument. Practically, that means building three things: receiving-side scoring with the ability to hold, a case management process that can respond to another institution's recall request within hours rather than days, and reporting that attributes losses to sending-side and receiving-side causes separately so investment goes where the losses are. Institutions that cannot split their APP losses that way are usually over-investing on the payer side and under-investing on the account they opened for the fraudster.
How should institutions share intelligence?
Through structured, timely exchange of account and pattern signals rather than case-by-case emails.
The signals with the shortest useful life are the ones about accounts currently receiving scam proceeds, and they are worthless a week later. Where industry mechanisms exist, integrate them as data feeds into scoring rather than as a reference someone checks manually. Where they do not, the internal equivalent still matters: a confirmed case in your own institution should tighten limits, update payee reputation, and adjust model features within minutes, not at the next model release. The PSR has also committed to promoting improved fraud intelligence sharing between firms, so expect this surface to grow and build the ingestion path now.
How do you measure prevention without gaming it?
By pairing value prevented with customer friction, and by attributing losses to a specific control failure.
| Metric | What it shows | Why it needs a pair |
|---|---|---|
| Value prevented | Payments stopped that were confirmed scams | Meaningless without the false positive cost |
| False intervention rate | Genuine payments delayed or blocked | Meaningless without prevention value |
| Warning dismissal rate by type | Whether warnings are read | Identifies content that needs rewriting |
| Hold conversion | Share of held payments the customer abandons | Distinguishes useful holds from friction |
| Receiving-side interception | Value held before dispersal | The lever most banks underuse |
| Loss attribution split | Sending-side versus receiving-side cause | Directs investment honestly |
| Reimbursement outcomes | Cost borne and cases upheld | Connects prevention to financial result |
Report fraud loss and false intervention together, always. Loss alone rewards blocking everything, conversion alone rewards passivity, and only the pair produces a design anyone can defend to both the risk committee and the commercial teams.
How should delivery be phased?
Payee verification and targeted warnings first, then behavioural scoring, then receiving-side detection, then intelligence sharing.
Start with payee verification and pattern-specific warnings, which are inexpensive and reduce losses immediately. Add behavioural scoring next, with the intervention ladder configured as policy rather than code so risk teams can tune it without a release. Build receiving-side detection third, because it takes longer and needs onboarding data, and it is the phase that changes your loss profile most once shared liability applies. Then integrate intelligence sharing and close the feedback loop so confirmed cases tighten controls within minutes. Behavioural signal collection sits underneath all of it, which is why the instrumentation described in behavioural biometrics and device intelligence should be sequenced alongside rather than after.
APP fraud is the one payment risk where the technology cannot carry the whole answer, because the deceived customer is the one pressing the button. What technology can do is notice that the button is being pressed under duress, make the warning specific enough to land, buy a few minutes of delay, and stop the money moving on once it arrives in an account that should never have received it.
Frequently Asked Questions
Why is APP fraud different from other payment fraud?
Because the customer genuinely authorises the payment. Authentication succeeds, the credentials are real, and the systems work correctly, so detection has to read intent rather than identity.
Where is APP fraud easiest to detect?
On the receiving side. A mule account shows unusual inbound patterns and rapid onward movement, which are often clearer signals than anything visible on the payer's side.
What behavioural signals indicate a scam in progress?
Hesitation and correction patterns during entry, an unusually long session, evidence of being coached, a first-time payee, an atypical amount, and rushed navigation to the payment screen.
Why do generic scam warnings fail?
Because customers see them on every payment and stop reading. Warnings only change behaviour when they name the specific scam pattern the payment resembles.
Is delaying a payment an acceptable control?
For high-risk cases, yes. A short hold with a contact attempt breaks the urgency scammers rely on, and it is far cheaper than reimbursing an irrecoverable payment.
How does shared reimbursement change the architecture?
It makes receiving-side detection a direct financial concern rather than a courtesy, since the receiving firm bears half the cost of a reimbursed scam under UK rules.
Can behavioural models be deployed without hurting genuine customers?
Yes, if intervention is tiered. Most risk should be handled by better warnings and questions rather than blocks, with hard stops reserved for the highest scores.
What single metric matters most?
Value prevented per unit of customer friction. Fraud loss alone rewards blocking, and conversion alone rewards passivity, so only the pair drives the right design.
