What a deepfake actually is, briefly
Deepfake detection technology already has a saturated content market, vendor after vendor explaining the same generative-adversarial-network and diffusion-model mechanics. That ground is covered. This guide does not repeat it. What almost nobody covers is the compliance judgement once a session is already flagged, and that is the actual subject of everything below.
There is no single legal definition of a deepfake in UK law. Ofcom's own working definition, used in its 2024 discussion paper on the harms of deceptive deepfakes, is the clearest available: a deepfake is audio-visual content that has been generated or manipulated using AI, and that misrepresents someone or something.[1] The broader category is synthetic media, any image, video, audio, or text generated in whole or in part by AI. A deepfake is the subset built specifically to misrepresent.
Two attack patterns that matter at onboarding
Face-swap and reenactment tools take an existing photo or video of a target identity and map a different face onto it, adjusting for lighting, angle, and expression. This is the technique behind the ABN AMRO case below, a stolen ID photo had the fraudster's own facial characteristics blended onto it, closely enough to pass an automated selfie-to-ID match.
Live injection attacks are a materially different and more serious pattern. Rather than submitting a manipulated photo or video file, the attacker feeds synthetic video directly into the verification pipeline in real time, bypassing the device camera entirely. Detection vendors and DSIT's own market analysis treat this as the most pressing and scalable current threat, because it defeats checks that assume a live camera feed is inherently trustworthy.[1]
One line on scope, since it matters: this guide is about the moment a submitted or live verification session is suspected to be synthetic media. The broader pattern of a fabricated identity built from stitched-together real fragments, which is a different problem with a different investigation, is covered in Synthetic Identity and Device-Network Fraud.
Generative model mechanics, vendor detection tool comparisons, and liveness certification standards are all real, useful ground, and all already covered elsewhere. This guide covers what to do once a session is flagged, not how the flag was technically generated.
Why a detection tool cannot be the whole answer
This is not caution for its own sake, it is what DSIT's own commissioned market analysis actually found, not vendor marketing:
- Detection accuracy claims are inconsistent between vendors because there is no standardised testing methodology or dataset, making genuine comparison difficult.[1]
- Real-world accuracy runs materially below lab-tested figures, DSIT's report puts the gap at 10 to 20 percentage points once tools meet manipulation techniques they were not trained on.[1]
- The Online Safety Act creates a regulatory backdrop but does not resolve ambiguity around synthetic media specifically, and the safety tech industry has itself described a reactive, wait-and-see posture toward deepfakes under the OSA as a result.[1]
The honest takeaway, stated plainly rather than implied: no detection tool gives you a clean yes or no you can act on alone. A confidence score is an input to a judgement, not a substitute for one. That judgement is what the rest of this guide actually teaches.
From flag to decision
A flag is the start of a process, not an automatic outcome. The four scenarios below work each branch in detail, this is the shape of the path they walk.
A liveness check returns a 62 percent confidence score that the submitted selfie may be synthetic, not a clear pass or fail. The applicant has otherwise submitted a genuine, unaltered passport image.
The applicant from Scenario 1 is escalated, and manual review cannot rule out synthetic media with confidence either way. The application is declined on a precautionary basis. No other applications, addresses, or documents connect to this one.
Someone using documents very similar in style to a previously flagged application attempts onboarding again days later, with a different name and address, but a suspiciously similar facial structure across the flagged sessions.
A genuine applicant triggers a detection flag purely because of unusual lighting conditions from a phone camera, or because they are wearing a face covering for religious or medical reasons. Nothing else about the application is unusual.
The ABN AMRO deepfake onboarding case
A 34-year-old man in Amsterdam collected stolen identity documents, partly by posting a fake rental property listing on Marktplaats and asking prospective tenants to send copies of their passports "for verification".[3] He then used face-swap software to blend his own facial features onto the stolen ID photos, closely enough that automated selfie-to-ID matching accepted them. Using this method he opened 46 fraudulent accounts at ABN AMRO through the bank's standard mobile onboarding flow, which asks an applicant to photograph an ID document and then take a selfie for automated comparison.[3]
The fraud came to light only when one application's submitted ID photo showed a woman while the accompanying selfie showed a man, a mismatch that triggered ABN AMRO's own investigation into the wider pattern.[3] He was convicted in June 2026 and sentenced to 30 months, six of them suspended, and ordered to repay ABN AMRO more than EUR13,000.[2]
This is a Dutch case, prosecuted under Dutch law, not a UK enforcement action. It's included because it is the clearest real, court-confirmed example currently available of exactly the attack pattern this guide addresses, a face-swap defeating a bank's own onboarding flow at scale before detection, not because it reflects UK regulatory practice specifically. Reporting on the exact account count varies slightly between sources (46 to 47), the figure used throughout this guide follows DutchNews.nl's reporting.
Why this case matters for the judgement, not just the technology: no single flagged session in isolation triggered detection. It was the cross-application pattern, caught by a human noticing an inconsistency the automated system hadn't decisively flagged, that surfaced the fraud. This directly supports Scenario 3's reasoning above.
Sources
Each numbered claim above is checked against the specific source below it. Figures without a bracketed number are illustrative examples rather than verified facts, the surrounding text says which.
- Department for Science, Innovation and Technology / PUBLIC, Deepfake Detection Technology, published 26 March 2026. gov.uk/government/publications/deepfake-detection-technology
- De Rechtspraak (Dutch Judiciary), Rechtbank Amsterdam news item, 2,5 jaar cel voor oplichten bank met deepfake-technologie, June 2026. rechtspraak.nl, Rechtbank Amsterdam nieuws
- DutchNews.nl, Man opened 46 bank accounts using deepfakes and stolen IDs, 18 March 2026. dutchnews.nl/2026/03/man-opened-46-bank-accounts-using-deepfakes-and-stolen-ids
- Ofcom, Deepfake Defences: Mitigating the Harms of Deceptive Deepfakes, discussion paper, published 23 July 2024. ofcom.org.uk/online-safety/illegal-and-harmful-content/deepfake-defences
FAQ
At a glance
Four patterns, the risk each one carries, the signal that tells you which one you're looking at, and the response that fits.
The score is an input. The decision is still yours.
Detection technology tells you a session might be synthetic. It does not tell you whether to decline, escalate, request secondary verification, or file a SAR, that is the judgement this guide walks through. FinCrimeRadar's Scenario Lab puts similar investigative decisions in front of you under real time pressure and partial information, free, no signup required.