The Fraud Journey Your Systems Never See
APP fraud losses reach the bank at the transaction stage. The fraud that produces them begins substantially earlier, at the moment a malicious URL lands on a customer’s device. This article maps the full kill chain of an HMRC impersonation attack as an example and identifies precisely where device-level signals diverge from what your transaction monitoring systems can see.
The UK Fraud Strategy 2026–2029 and the Online Crime Centre: Implications for Bank Fraud Detection established that the regulatory environment, through the PSR mandatory reimbursement requirement and the Online Crime Centre now systematically rewards earlier fraud detection. This article maps what earlier means in operational terms: the specific stages of an attack where device-level intelligence exists and where your systems first become aware. This is done uses HMRC impersonation as an example.
Before Your Systems See Anything
The phrase “APP fraud detection” typically refers to a narrow operational window: the moment a customer initiates a payment in their banking app or online portal.
That window is where most institutional fraud detection operates. It is also the end of the fraud, not the beginning.
The kill chain as a detection framework
The kill chain model, widely used in security operations, maps a multi-stage attack as a sequence of discrete steps. Each step is a detection opportunity. An architecture that engages only at the final step has, by design, treated every prior step as outside its scope.
For APP fraud, the payment instruction is the final step. The social engineering that makes the payment instruction possible begins substantially earlier, in a window entirely outside bank visibility. Understanding where each step of the kill chain occurs and what observable signals it generates, is the precondition for any serious improvement to detection capability.
The structural boundary of transaction monitoring
Transaction monitoring systems are designed to observe what happens inside a banking session. They are not designed to observe what happens before that session begins.
This is not a performance limitation. It is a design boundary. Transaction monitoring analyses the instruction; it cannot analyse the process that produced the willingness to instruct.
The distinction matters because APP fraud is primarily a social engineering problem. The payment instruction is the symptom. The cause, the manipulation of the customer’s decision-making, happens upstream.
Transaction monitoring systems do not fail to detect APP fraud because they are poorly calibrated. They fail because the social engineering that produces the payment instruction completes before the detection layer activates.
The HMRC Impersonation Kill Chain: A Stage-by-Stage Map
HMRC impersonation is among the most heavily reported fraud types in the UK. HMRC received 296,000 phishing reports between 2023 and mid-2025, with more than 283,000 relating to email impersonation alone 3. The attack mechanics are well-documented and the kill chain is tight enough to map with precision. It is a useful worked example because the sequence from first contact to completed payment is representative of a broader class of phishing-led APP fraud.
HMRC communicates with millions of UK adults through digital channels and legitimately requests personal and financial information. It has an institutional reason to contact individuals urgently and to require immediate action. The psychological architecture of a genuine HMRC communication, combining authority, urgency and compliance obligation, is precisely the template that social engineers exploit. The impersonation succeeds not because the underlying fraud is technically sophisticated but because the institutional model it copies is inherently coercive.
Stage 1: the lure arrives
An SMS or email arrives presenting as official HMRC communication. A tax rebate is available, a liability is outstanding, or a compliance obligation requires immediate action. A URL is included.
At this moment, the device holds observable information. The sender identifier may be spoofed. The URL has characteristics that distinguish it from a legitimate .gov.uk domain: domain age, registration data and hosting origin. The message arrived outside the authenticated channels through which HMRC contacts individuals.
No banking session has been initiated. The bank has no visibility.
Stage 2: the URL is resolved
The customer taps the link. The device resolves the URL and loads a page presenting as an HMRC portal: matching branding, plausible form fields, an instruction to enter personal or financial details.
This page generates multiple observable signals. The HTTPS certificate is typically a recently-issued certificate from a low-cost certificate authority, not from a .gov.uk domain registered with HMRC. The domain was likely registered within days or weeks of the attack. Page content carries classification signals that distinguish it clearly from legitimate government infrastructure.
The bank still has no visibility.
Stage 3: credentials and details are entered
The customer enters information on the fake page: National Insurance number, date of birth, bank account details, or some combination of these. The fraudster now holds data that substantially increases the credibility of the next stage.
Interaction patterns on the page are observable at the device level: dwell time, data entry sequence and form field engagement. These signals exist whether or not they are collected.
Stage 4: the follow-up call
In many HMRC impersonation attacks, the web interaction is not the final stage before the payment instruction. A phone call follows, apparently from HMRC, in which the caller references the details just submitted to establish apparent legitimacy.
This is the social engineering peak. The customer has already acted on the initial lure: they tapped the link and entered their details. Commitment has been made. A caller who demonstrates apparent knowledge of those details appears legitimate precisely because of that prior commitment. Article 9 will examine the compliance psychology underpinning this sequencing in detail.
Where screen content analysis operates on the device, the follow-up call generates observable signals. Scripted fraud dialogue carries identifiable linguistic characteristics. The customer’s interaction pattern reflects the behavioural indicators of elevated urgency.
Stage 5: the payment instruction
The fraudster instructs the customer to make a payment: a tax liability settlement, a compliance deposit, a transfer to a “safe account.” The customer, having committed progressively through stages 1 to 4, initiates their banking application.
This is the first moment the bank’s fraud systems have any opportunity to observe the interaction. What they observe is the consequence of completed social engineering, not the process of social engineering itself.
Stages 6 and 7: where the bank enters the picture
The customer opens their banking app. Transaction monitoring engages. Behavioural biometrics, device fingerprinting and payment analytics begin to operate on the session data.
But this analysis operates on a customer who has already committed to making the payment. The decision was made at Stage 5, under conditions of completed social engineering. Transaction monitoring is examining the execution of that decision, not the conditions that produced it.
If the payment instruction does not trigger a fraud alert (in authorised fraud cases it frequently does not because the instruction is consistent with the authenticated customer’s apparent intent) the payment completes. A Faster Payment or CHAPS payment is submitted. The bank’s reimbursement liability under the PSR’s mandatory regime, which covers both payment rails from 7 October 2024, then attaches 2.
The APP Fraud Detection Gap: What Exists in the Pre-Transaction Window
The kill chain above contains five stages before the bank sees anything. Each stage generates observable signals on the customer’s device. This is not a theoretical claim about what might be detectable under ideal conditions. It is a statement about what is structurally present in the pre-transaction window right now.
What device-level data is present at each stage
At Stage 1, the URL in the received message can be assessed against known malicious domain registries, domain age data and sender spoofing indicators. This analysis can occur before the customer taps the link.
At Stage 2, the HTTPS certificate, domain characteristics and page content can each be classified. A legitimate .gov.uk government page has a markedly distinct profile from a recently-registered phishing page designed to mimic it.
At Stage 3, interaction patterns on the fake page are observable: dwell time, data entry sequence and form field engagement. At Stage 4, screen content during the follow-up call may carry scripted fraud language with identifiable patterns. At Stage 5, the transition from a non-banking application to the banking app under elevated urgency conditions constitutes a detectable behavioural signal.
At each of the five pre-transaction stages of an HMRC impersonation attack, the customer’s device holds intelligence about an ongoing fraud. Under current retail bank fraud architectures, none of it is collected, analysed or acted upon.
The legal and practical questions are real
This is not an argument that banks should be collecting all device-level data from their customers’ personal devices. The legal basis for data collection at that level raises genuine questions under UK GDPR that are not resolved by a commercial motivation to prevent fraud.
The argument is more precise: a systematic approach to operating within the pre-transaction window, with appropriate legal basis, consent architecture and defined data scope, would produce intelligence that transaction monitoring architectures structurally cannot reach. The legal questions are answerable. The intelligence gap produced by not answering them carries a direct cost in reimbursement liability.
Transaction monitoring observes the execution of a compromised decision. Device-level intelligence would observe the process that compromised it. These are not the same detection problem and treating them as equivalent leaves five stages of a seven-stage attack entirely invisible.
The Question This Raises
Five stages of intelligence, none currently collected
The intelligence described in this article is not speculative. At each of the five pre-transaction stages of an HMRC impersonation attack, observable signals exist on the customer’s device. Those signals are sufficient, in principle, to identify an attack in progress before a payment instruction is ever issued.
They are not currently being collected. The absence of collection is not an oversight: there are genuine architectural and regulatory reasons why payment service providers fraud stacks have not previously been able to operate in the pre-transaction window. Now, it’s an expectation and substancial opportunity.
The next article examines what artificial intelligence has done to the signal characteristics of that pre-transaction window and why the timing problem is becoming significantly more acute. If that is where the intelligence is, why is no one collecting it?
At what point in an APP fraud attack does a bank’s fraud system first detect anything?
In a standard APP fraud architecture, bank fraud systems first engage when the customer opens their banking app to initiate a payment. In a seven-stage HMRC impersonation kill chain, that is Stage 6. Everything that preceded it, including the delivery of the malicious lure, the loading of the phishing page, the entry of credentials and the social engineering call, occurred entirely outside the bank’s detection boundary.
How does an HMRC impersonation scam typically work?
An HMRC impersonation attack typically begins with an SMS or email containing a malicious URL, presenting as a communication about an outstanding tax liability or available rebate. The customer taps the link, lands on a convincing fake HMRC page and enters personal or financial details. In many cases a follow-up call then uses those details to simulate HMRC legitimacy before issuing a payment instruction. The bank sees none of this until the customer opens their banking application.
What device-level signals are available during a phishing attack before the customer opens their banking app?
Multiple observable signals exist at the device level before any banking session begins. These include URL metadata (domain age, registration characteristics, hosting origin), HTTPS certificate details of the phishing page, page content classification signals, user interaction patterns on the fake page and behavioural indicators during any follow-up social engineering call. None of these signals are captured by standard retail bank transaction monitoring systems.
Why is transaction monitoring insufficient to prevent APP fraud?
Transaction monitoring is designed to analyse the payment instruction and the banking session during which it is made. In APP fraud, the customer makes the payment with apparent authentic intent, because the social engineering has already succeeded. The system examines a decision that was compromised at least two stages earlier, in a window the system has no capability to observe.
What is the APP fraud detection gap in bank fraud architecture?
The APP fraud detection gap refers to the period between the first moment of fraudulent contact with the customer and the point at which the customer initiates a banking session. In a seven-stage HMRC impersonation kill chain, this gap encompasses five stages. It contains observable device-level intelligence that current bank fraud architectures are not designed to collect or analyse.
Does a website using HTTPS mean it is safe to use?
No. HTTPS indicates that the connection between a browser and server is encrypted, not that the server is legitimate. Phishing sites widely use HTTPS, typically with low-cost certificates issued by automated certificate authorities. A genuine .gov.uk domain uses a government-issued certificate with distinct characteristics that can be assessed at the device level, independently of whether a padlock icon appears in the browser.
What are UK banks’ reimbursement obligations when a customer falls victim to APP fraud?
Under the PSR’s mandatory reimbursement regime, which came into effect for Faster Payments in October 2024, sending and receiving banks are required to reimburse customers who fall victim to APP fraud in most circumstances, up to a maximum of £85,000 per claim 2. The liability attaches at the point the authorised payment completes, reinforcing the commercial case for detection that operates earlier in the attack sequence.
- UK Finance, Annual Fraud Report 2025, May 2025. ukfinance.org.uk
- Payment Systems Regulator, PS24/7: Faster Payments APP Scams Reimbursement Requirement — Confirming the Maximum Level of Reimbursement, September 2024. psr.org.uk
- Bridewell, analysis of HMRC phishing report data, September 2025. thinkdigitalpartners.com. Primary source: HMRC, Phishing and Bogus Contact with HMRC. gov.uk
SENGUARD works with UK retail banking institutions on pre-transaction fraud detection. This series examines the fraud policy and technology landscape facing UK banks: the regulatory frameworks shaping detection obligations, the threat environment evolving around them and the detection architectures being developed in response.