Deepfake Detection in Production KYC: What the Benchmarks Don't Tell You
Deepfake detection papers routinely report accuracy in the high nineties. Then you deploy into real KYC, where the camera is a $50 Android phone, the lighting is a Lagos office at noon, the user has dark skin the training data barely saw, and the adversary changes tactics faster than your release cycle. I build biometric fraud prevention for African financial institutions at Agregar; the systems I have worked on have processed thousands of verifications for dozens of them. This is what that work teaches you that no benchmark will.
A correction first, in fairness to earlier readers: a previous version of this post quoted precise system metrics, a verification count, detection and false-rejection rates, per-device accuracy breakdowns. I have removed them. Some were unverifiable, and the precise operational numbers of a client-facing fraud system are confidential in any case; publishing them would be wrong twice. What remains is the part that was always more valuable: the failure modes, the architecture, and the lessons, stated qualitatively and grounded in published research where numbers matter.
The gap is not one gap, it is four
The standard research datasets (FaceForensics++, the DFDC, Celeb-DF) measure something real: can a model separate genuine from manipulated faces under the dataset's conditions. A production KYC pipeline fails for reasons that live entirely outside those conditions, and it pays to name them separately, because each one demands a different fix.
Device gap. Benchmarks are built from high-quality source video. Production means 2-megapixel front cameras, cracked lenses, and aggressive video compression on poor networks, and compression is especially cruel here because it destroys precisely the high-frequency artifacts that many detection models key on. A detector that leans on subtle spectral fingerprints can lose its signal to a bad connection before the fraudster does anything at all.
Population gap. The demographic one, which gets its own section below, because in African markets it is not an edge case, it is the customer base.
Threat-model gap. Research concentrates on detecting generated imagery. Production fraud is mostly not generated imagery, as the next section shows.
Base-rate gap. In a benchmark, half the samples are fake. In production, the overwhelming majority of sessions are legitimate customers, which transforms the economics of every design decision: at production base rates, even an excellent detector produces far more false alarms than true catches, and a false rejection is not a statistic, it is a real person locked out of their bank account, often one with no alternative bank. This is why the output of a verification pipeline should be a confidence score consumed by a risk engine, never a hard verdict: the threshold for a small mobile-money transfer and a large wire transfer should not be the same number.
What attacks actually look like
When I started this work I expected GAN-generated faces to be the main event. What the queue actually contained, overwhelmingly, was the humble end of the spectrum: printed photographs held up to cameras, videos replayed on a second phone, photos curved around jars to defeat naive flatness checks. The biometrics industry has a name for this class, presentation attacks, and an ISO standard for testing against them (ISO/IEC 30107-3), and the unglamorous truth is that a KYC system's first job is presentation attack detection, not deepfake forensics.
The mistake this observation invites is complacency, and it would be a serious one. Face-swap tooling that needed a GPU and expertise three years ago now runs in consumer apps, and injection attacks (feeding a synthetic stream in below the camera, where no liveness prompt can see the screen) are the clear direction of travel. The design conclusion is not “optimize for prints” or “optimize for deepfakes.” It is that the threat is a moving distribution, and the architecture has to assume every layer will eventually be defeated.
Cascade over ensemble
The architecture that survives contact with all four gaps is a cascade with early exits, ordered by cost. Liveness and quality checks run on every session and dispose of the print-and-replay volume cheaply. Texture and moiré analysis catches the better replays and mask work. Temporal analysis across frames catches what single frames cannot, including the boundary instability of live face swaps. Frequency-domain analysis, the most expensive and most fragile signal, is reserved for the small residue where generated imagery is genuinely in question, and whatever survives all of it with low confidence goes to a human.
Why not an ensemble, running everything and voting? Two reasons that matter more in our markets than elsewhere. Latency: KYC abandonment rises steeply with onboarding friction, and an always-on full battery prices out exactly the low-end devices most of the continent onboards from. And economics: the cascade's compute cost scales with the attack rate rather than the session rate, which is the right shape when the overwhelming majority of sessions are honest. The structural idea is the same one I keep arriving at in transaction monitoring and name matching: spend the cheap filter generously, spend the expensive judgment only where the cheap filter leaves doubt.
The skin-tone problem is an engineering problem
This section is the reason this post exists, because it is the most consequential and least discussed issue in production face analysis for African markets. The published evidence is not subtle. Buolamwini and Gebru's Gender Shades study found commercial face analysis error rates dramatically higher for darker-skinned subjects. NIST's FRVT demographic-effects report (NISTIR 8280) measured higher false match rates for West and East African faces across a large share of the algorithms it tested. These findings come from datasets and populations where dark skin is a minority slice. Deploy in Ghana or Nigeria and the minority slice is your entire customer base: whatever demographic differential your models carry is now the headline behavior of your product.
Where it bit us hardest was liveness. A family of liveness techniques (rPPG, remote photoplethysmography) works by detecting the tiny periodic color changes that blood flow produces in skin, and the raw RGB signal for those changes is weaker at higher melanin concentrations; the research literature documents the degradation clearly. A liveness check that silently works worse for dark skin does not fail loudly: it just quietly rejects more of your legitimate users, and in KYC a false rejection can mean a person cannot open the account at all.
The engineering responses, none of them exotic: chrominance-based rPPG methods (the CHROM family) that are substantially more robust across skin tones than raw RGB analysis; reweighting evaluation so that per-demographic false rejection is a tracked, release-blocking metric rather than an aggregate-accuracy footnote; and treating dataset composition as a requirements question, because a model trained on faces that do not look like your users is a bug filed against the training set, not the users. The general lesson deserves stating plainly: aggregate accuracy is a marketing number. Ship the per-population numbers internally, or your fairness problem will ship itself.
The adversary is a fast-follower
Every defense teaches the attacker. We shipped blink detection and the photos became videos. We caught screen replays through moiré aliasing and the replays moved to better screens. We added depth cues and the prints acquired curvature. None of these adaptations required sophistication, only feedback, and a fraudster probing an onboarding flow gets feedback for free with every attempt.
Two operational conclusions follow. First, single-signal defenses have a shelf life measured in weeks, which is the real argument for the cascade's signal diversity: geometry, texture, motion, and frequency content fail independently, and an attacker optimizing against one usually becomes more visible in another. Second, the pipeline must eat its own confirmed frauds as training data on a regular cadence, because a detection model is not an artifact, it is a position in an ongoing game. The goal was never an unbreakable system; it is to price the attack above its payoff, and prices need continuous adjustment.
What I would tell you if you were building this
- Do presentation attack detection before deepfake forensics. The volume is in prints and replays; the ISO/IEC 30107 framing will serve you better than the deepfake literature for your first year.
- Order your checks by cost and let confident rejections exit early. Compute should scale with attacks, not with honest sessions.
- Emit scores, not verdicts, and let transaction risk set the threshold. The same session can be good enough for a wallet top-up and not for a loan.
- Track per-demographic false rejection as a release-blocking metric. If you serve African users with models validated elsewhere, assume a differential until you have measured its absence.
- Assume every layer gets defeated, and build the retraining loop before you need it. The adversary's iteration speed is part of your requirements.
Sources and further reading
- Buolamwini & Gebru, Gender Shades (FAT* 2018) (demographic error differentials in commercial face analysis)
- NIST, FRVT Part 3: Demographic Effects (NISTIR 8280, 2019)
- ISO/IEC 30107-3, Biometric Presentation Attack Detection (the testing framework for the attacks that dominate production)
- FaceForensics++ and the Deepfake Detection Challenge dataset (the research benchmarks this post is contrasting with production)
- de Haan & Jeanne, Robust Pulse Rate from Chrominance-Based rPPG (IEEE TBME, 2013) (the CHROM method referenced in the skin-tone section)
