P2P payment fraud has a fundamental property that makes it harder to detect than most other fraud types: the sending account authorized the transfer. The transaction is technically authenticated. The account holder performed the action. The friction of fraud detection was designed to stop unauthorized use, and this is authorized use directed by a scammer who manipulated the account holder into making the payment voluntarily.
Authorized push payment scams are the dominant fraud vector on digital wallet platforms, and the industry has not solved them at the platform level. UK Finance data from recent years has consistently shown APP scam losses running into hundreds of millions of pounds annually across the UK financial system, with digital wallet and faster payment channels disproportionately represented. The fundamental challenge is structural: you are trying to detect fraud in a transaction where the authentication path is completely clean.
Why Standard Fraud Scores Miss APP Scams
A standard transaction risk score evaluates a transaction against the account's established behavioral patterns and known fraud indicators. For most fraud types, this works because the fraudster's behavior departs from the legitimate account holder's baseline in ways the model can detect.
In an APP scam, the account holder is executing the transaction themselves, in their own session, on their own device, often during normal usage hours. There is no device mismatch, no session anomaly, no location inconsistency. The behavioral deviation is in the account holder's intent and understanding, not in their device behavior. Conventional behavioral features do not capture intent.
The features that are actually informative for APP scam detection are different: they concern the characteristics of the recipient account, the circumstances under which the sender initiated the transfer, and the degree to which the transfer deviates from the sender's historical sending patterns specifically rather than their general transaction patterns.
Recipient-Side Signals
For APP scam detection, the most tractable signal is on the recipient side of the transaction. Scammer-controlled accounts have identifiable characteristics that legitimate P2P recipients generally do not.
Account age at time of receipt is a strong signal. Scammer-controlled receiving accounts are frequently created shortly before the scam campaign begins, used for a short window, and then abandoned. A receiving account that is less than 30 days old and is receiving a first or second significant inbound transfer is structurally different from an established account with a history of normal P2P receives.
Outflow velocity on the receiving account is the other key signal. When scam funds land, they are moved out quickly. A receiving account that shows high outflow velocity within hours of receiving funds, to accounts that in turn show similar outflow patterns, is a mule account in an extraction chain. This requires looking at transaction sequences on the recipient side, not just the sender side.
Account graph position matters here. A receiving account that shares device infrastructure, phone number, or IP range with other accounts that have recently received significant inbound transfers followed by rapid outflows is part of a mule network even if the individual account looks clean. This is precisely the kind of pattern that individual account scoring misses and graph-based features are designed to surface.
Sender-Side Behavioral Deviation
Even though the sender is making the transfer voluntarily, their behavior during the APP scam session often deviates from their normal P2P sending patterns in detectable ways.
Transfer amount relative to sender history is informative. A sender who typically sends P2P transfers in the $20 to $150 range initiating a $2,400 transfer to a first-time recipient shows a substantial amount deviation that is not explained by their established behavior. Amount alone is not conclusive, but combined with first-time recipient and an unusual initiation context, it contributes meaningfully to a risk assessment.
Session duration and hesitation patterns capture something interesting. In legitimate large P2P transfers, senders often show deliberate session patterns: they verify recipient details, may navigate away and return, show evidence of considered decision-making. In scam scenarios, scammers often keep the victim on the phone during the transfer, which creates unusual session behaviors: abnormal time-on-screen, rapid form completion despite the large amount, or uncharacteristic interaction with the confirmation step.
First-time recipient combined with urgency signals is worth treating as a specific pattern. Scams are structurally urgent: the narrative the scammer creates requires the victim to act quickly, and urgency creates measurable session behaviors. A first-time large transfer to an unfamiliar account completed during a phone call (inferred from device sensor data where available) is a risk context that warrants friction even if the transaction itself passes all behavioral checks.
The Friction Design Problem in P2P
Adding friction to P2P transactions is a more sensitive design decision than adding friction to checkout. The P2P use case has a strong usability expectation: the whole point of a digital wallet is that you can send money to someone quickly. Any friction that makes that feel like a bank wire transfer defeats the product's core value.
The friction has to be targeted and proportionate. Blanket friction on all transfers above a threshold creates too much false positive impact on legitimate high-value P2P transfers (rent payments, shared expenses, family transfers). Friction calibrated specifically to the risk pattern, first-time recipient plus amount anomaly plus other signal combination, applies friction where it is actually informative without touching the normal-use cases.
The content of the friction matters more than its presence. A generic "confirm your transfer" step adds friction without reducing scam completion rates, because the scammer has already convinced the victim to confirm. Friction that explicitly references the scam scenario, something like "Are you sending this money because someone contacted you unexpectedly and asked you to?" provides information the victim needs to reconsider, which is what actually interrupts scam completion.
What Platforms Cannot Solve Alone
To be direct: platform-level fraud detection cannot fully solve APP scam risk. The scam happens in a social engineering interaction that is external to the platform. The most sophisticated behavioral detection you can build will still approve a significant fraction of APP scam transfers because the sender's behavior, under active social engineering pressure, may not deviate detectably from legitimate large transfers.
Industry-level data sharing about known mule accounts and scam recipient patterns would substantially improve detection rates by allowing platforms to pool recipient-side signals across institutions. This exists in some regulatory frameworks (the UK's Confirmation of Payee system is a partial step in this direction) but is incomplete, and not all jurisdictions have equivalent mechanisms.
The practical implication for digital wallet platforms is to focus detection investment on the recipient-side signals and the sender-side amount-deviation and first-time-recipient combinations, accept that some fraction of APP scam losses will not be detectable at the transaction level, and invest in scam awareness friction that gives victims an explicit opportunity to reconsider, rather than neutral confirmation friction that does not change behavior. The third category of investment, post-scam recovery, is operationally important for customer experience even though it does not prevent the loss.
