Payment fraud detection systems are generally designed around payment events — transaction velocity, account age, payee novelty, behavioural biometrics at the device level. These are the right signals for detecting anomalous sessions where someone is using a compromised credential. But APP fraud doesn't begin at the payment event. It begins in a conversation. Understanding how social engineering propagates from initial contact to payment instruction is essential for building controls that actually interrupt the chain rather than observing its completion.
The Conversation Precedes the Payment by Design
Every APP scam involves a conversation layer — a channel of communication between the scammer and the victim that precedes, and typically continues through, the payment instruction moment. The conversation is not an afterthought. It is the mechanism by which the scammer overrides the victim's normal scepticism and installs a compelling belief: that this person is who they say they are, that the payment is necessary and legitimate, and that any doubt the victim feels is itself a risk to be managed.
The conversation layer is invisible to the payment system. From the Faster Payments infrastructure's perspective, a fully socially-engineered victim and a person paying their rent look identical: authenticated user, correct credentials, deliberate payment instruction to a valid account number. The distinction that matters — was the victim deceived about the payee's identity? — is not resolvable from the transaction data. It requires access to the conversation.
This is the architectural insight that shapes how we think about APP fraud detection. The meaningful signal is not at the payment event. It is in the conversation that precedes it.
How the Social Engineering Chain Actually Works
A plausible mid-complexity investment scam scenario illustrates the mechanics. A consumer — let's say someone in their 50s with a modest savings account at a growing digital bank — encounters an advertisement on social media for a managed cryptocurrency investment service offering returns significantly above base rate. The advertisement links to a professionally constructed website with company registration numbers and a contact form.
The consumer fills in the form with a small expression of interest. Within 24 hours they receive a call from a "relationship manager" with a UK mobile number. The relationship manager is articulate, patient, and does not pressure the consumer on the first call. They establish rapport, explain the investment product, and offer a small "free trial" amount. The consumer is told they can withdraw anytime.
Over the following two weeks, the consumer receives regular WhatsApp messages with "portfolio updates" — screenshots of a fake dashboard showing their initial amount growing. The relationship manager checks in periodically, answers questions, builds familiarity. The consumer's family knows they've been "investing." There is no sign of fraud yet from any system the PSP operates.
At week three, the relationship manager proposes a larger "investment round" — £15,000, with the caveat that it must be transferred via Faster Payments rather than card (because "the card processor has limits"). The consumer opens their banking app, enters the sort code and account number provided in a WhatsApp message, and initiates the transfer. The payment instruction is clean. The Faster Payments transaction completes in 23 seconds.
At no point did the PSP's fraud stack fire a high-confidence alert. The transaction velocity was normal for the consumer. The amount was large but not outside their account history. The new payee flag was triggered, a generic warning was shown, and the consumer dismissed it because they had been coached three days earlier on exactly how to respond to it.
Where Social Engineering Actually Stalls
APP scams are not uniformly successful. There are predictable points where the social engineering chain breaks down — and those stall points are informative for designing pre-transfer interventions.
Unexpected re-contact or delay. Scammers operate on momentum. If the victim's decision-making process is interrupted — by a family member asking questions, by the victim deciding to "sleep on it," by a bank call that introduces doubt — the scammer loses the psychological control they've built. The coaching architecture of a well-run APP scam invests heavily in preventing any pause or external input. Anything that introduces a genuine delay creates the possibility of the victim seeking independent information.
A credible alternative voice in the conversation. If the scammer's narrative is challenged by someone the victim trusts more than the scammer — a family member, an actual bank representative, or a seemingly authoritative interlocutor — the belief structure the scammer has built can collapse rapidly. This is the logic behind the "safe phrase" call-back mechanisms some banks introduced, and it's also the mechanism that underlies the honeybot approach: introducing a conversational entity that asks questions the scammer cannot answer credibly without revealing inconsistencies.
Too-specific payment friction. Generic payment warnings ("this payment may be fraudulent") are easy for scammers to coach around. Specific, context-aware friction — "payments to accounts opened within the last 30 days with no inbound payment history" — is harder to pre-empt because the scammer can't know the exact threshold. The friction that stalls social engineering is friction that catches the scammer by surprise, not friction the victim was told to expect.
Channel Diversity and Attack Surface
Investment scams primarily use messaging apps and social platforms for initial contact, transitioning to voice calls and WhatsApp for the trust-building phase. Bank impersonation scams rely heavily on voice calls with spoofed numbers. Romance scams typically begin on dating platforms and migrate to WhatsApp or direct messaging. Purchase scams happen within hours on a single channel — a marketplace listing, a direct message, a payment.
The channel matters for two reasons. First, it determines how much conversation data is available for analysis — messaging apps create a persistent thread; voice calls typically don't unless the PSP has some form of call data access. Second, it determines the intervention architecture. A honeybot that operates in a messaging thread is structurally different from a honeybot that intercepts a voice call scenario. We're not saying channel doesn't matter for tooling design — it absolutely does. But the core principle (enter the conversation before the payment instruction) is channel-agnostic.
Timing the Intervention: Before, During, or After?
Most PSP fraud interventions today happen at or after the payment instruction. Transaction monitoring fires at the moment the payment is submitted. CoP fires at the moment the account details are entered. The 5-business-day claims clock starts after the funds have moved. These are late interventions by design — the payment infrastructure is where the PSP has data and control.
Pre-transfer intervention that occurs in the conversation layer requires the PSP to extend its operational perimeter beyond the payment event. This is a significant conceptual shift. The PSP doesn't traditionally have a role in the conversation between a scammer and a victim that is happening on WhatsApp. They have no data on it, no visibility, no infrastructure there.
The AVIEL architecture changes that by deploying a honeybot that enters the conversation from the scammer's side rather than the victim's side. Rather than trying to intercept the victim's banking session, the honeybot enters the scammer's conversation channel as a potential victim — extracting intelligence about the scammer's account details, timing, and methods before those details are used against real consumers. This is why RIPA 2000 lawful interception principles are part of the legal framework for how honeybots operate: they are not monitoring consumer communications; they are participating in the communications the scammer initiates.
What Happens When a Honeybot Stalls a Scammer
The operational effect of a honeybot engaging a scammer in conversation is multi-layered. The immediate effect is time: a scammer who believes they are working a viable target is not, during that period, working a real victim. The second effect is intelligence: the conversation extracts account details, communication patterns, device metadata, and linguistic characteristics that constitute a scammer fingerprint — a behavioral signature that can be used to identify the same actor appearing on a different channel or under a different cover story.
The third effect is the one PSP fraud ops teams find most operationally significant: the scammer fingerprint, once extracted, can be matched against incoming payment instructions. A Faster Payment to a sort code and account number that appeared in a honeybot conversation 48 hours earlier is a high-confidence APP fraud signal, even if the transaction itself looks clean. That signal arrives before the payment completes.
That is the mechanism that bridges the conversation layer and the payment rails. Social engineering moves through payment rails because those rails have no sight of the conversation. The honeybot creates sight of the conversation, and the fingerprint it extracts becomes a pre-transfer alert that the existing stack can act on.