Deepfakes don’t wait for your vendor’s release cycle

On December 22, 2025, the Financial Action Task Force published its “Horizon Scan on AI and Deepfakes”, the first FATF publication to name the liveness check specifically as an attack surface. The finding was pointed: criminals were using AI-generated media to circumvent identity verification in KYC onboarding, not just to produce disinformation or impersonate executives. The regulator had caught up with what fraud teams in payments, crypto, and banking had been seeing in production for over a year.

But “caught up” is the operative phrase. By December 2025, the attack type FATF was flagging and had been running in the wild for months. The gap isn’t between regulators and fraudsters. The gap is between the speed at which new deepfake attack variants propagate and the speed at which the liveness vendors your stack depends on can ship a response.

That gap is the argument this post is making. Deepfake detection isn’t a control you evaluate at procurement and leave in place. It degrades as the threat evolves, and the speed at which you can recover is determined almost entirely by whether the detection engine in your stack is yours to update or someone else’s.

Why does deepfake detection go stale so quickly?

Deepfake detection, formally called presentation attack detection (PAD) under ISO/IEC 30107-3, works by training models on known attack artifacts: texture inconsistencies, depth signal anomalies, screen-replay signatures, and lighting mismatches. The model learns what a synthetic face looks like based on the fakes it has been shown.

The problem is that “what a fake looks like” changes every few months.

The attack surface moves faster than any release calendar

In 2023, the dominant attack type at liveness checkpoints was a printed photograph or a looped video played in front of the camera. By 2024, face-swap models trained on open-source architectures were cheap enough that operators were offering them as a service. By 2025, injection attacks where a synthetic video stream bypasses the camera layer entirely and feeds directly into the capture endpoint, had become the preferred vector at enterprise-grade targets.

Each of these shifts required retraining or materially updating the detection model. A vendor shipping on a quarterly release cycle carries a three-month window in which its model is effectively calibrated for the previous threat generation. Three months, in a fraud economy where new attack tooling propagates in weeks, is a meaningful gap.

The issue compounds because attack toolkits circulate on underground markets before most vendors encounter them in production. A new face-swap architecture doesn’t arrive in a vendor’s threat intelligence report the same week it gets deployed against their client’s onboarding flow. Detection models trained against last quarter’s artifacts miss this quarter’s attacks by design not because the model is poorly built, but because it was never shown what it’s now facing.

Injection attacks rewrote the threat model in 2025

Injection attacks matter specifically because they sit outside the original scope of ISO/IEC 30107-3. The standard was designed to test PAD against presentation attacks at the camera sensor, a physical or digital artefact held up to a camera. Injection attacks bypass the sensor entirely, feeding synthetic media directly into the software capture layer.

This is not a flaw in the standard; it’s a gap in what “liveness detection” as traditionally sold actually covers. The Monetary Authority of Singapore’s September 2025 circular on deepfake cyber risks addressed this gap directly, requiring financial institutions to treat endpoint-level injection protection as a distinct additional control not an extension of conventional PAD. That guidance forces a question most procurement processes have never asked: does your vendor’s liveness model address injection, or only presentation attacks? And if only presentation, who owns the injection defence layer, and on whose release cycle does it update?

What does the regulatory signal look like right now?

Three moments in 2025 moved deepfake defence from a fraud-team concern into a compliance question, and each one tightened the window for slow-moving vendors.

MAS Singapore, September 2025.

The Monetary Authority of Singapore published Circular MAS/TCRS/2025/06, “Cyber Risks Associated with Deepfakes” requiring financial institutions to test their liveness detection against deepfake samples regularly through vendors specialising in biometric testing or through internal red-team exercises that simulate real-world attack conditions. The circular frames liveness bypass as a board-level cyber risk, not a vendor-side technical issue to be managed below the compliance line.

FATF Horizon Scan, December 2025.

The Financial Action Task Force (FATF) published its Horizon Scan on AI and Deepfakes on December 22, 2025, identifying deepfakes as a direct threat to AML and customer due diligence (CDD) controls worldwide. The scan specifically noted that criminals can use AI-generated media to circumvent identity verification in KYC onboarding, naming the liveness check as a specific attack surface. For compliance teams, a FATF publication naming a particular attack vector is a signal that national regulators will follow.

EU AI Act, enforceable August 2026.

The EU AI Act’s transparency obligations under Article 50 including mandatory disclosure and labelling of AI-generated content become enforceable in August 2026. Requirements for high-risk biometric systems extend to December 2027. For verification teams operating across EU jurisdictions, the regulatory surface for AI-assisted identity fraud is expanding. Each new enforcement date is another reason an outdated detection layer creates legal exposure, not just fraud loss.

What does iBeta Level 3 conformance actually test?

iBeta Level 3, introduced in June 2025 under ISO/IEC 30107-3, is the current published ceiling for independent liveness testing. Understanding what it tests and why the previous levels were no longer sufficient is the clearest way to evaluate whether a vendor’s deepfake posture is real or residual.

Expert attackers, no budget ceiling, weeks to attempt a breach

Level 3 testing assigns a team of expert attackers with no constraint on budget or tooling. The attacking team has weeks to study the target system, develop custom artifacts, including AI-generated faces, mechanically controlled masks that respond to liveness prompts, and deepfake animations capable of mimicking required head movements in real time and attempting a breach. The system passes only if it maintains a Bona Fide Presentation Classification Error Rate (BPCER) of no more than 10% across all attack attempts.

Level 1 and Level 2 tested known, off-the-shelf attack artifacts with constrained resources and timelines. Level 3 tests adversarial resourcefulness. The difference is the same as testing your lock against a standard bump key versus testing it against a locksmith who built custom tools and had a month to study your specific door.

Very few vendors globally hold Level 3 conformance. The test is recent, the bar is high, and the resource commitment to run it is substantial. Any vendor claiming conformance should be asked for the specific confirmation letter date, which establishes whether the test was conducted against current attack generation capability or against artifacts from a prior period.

Why Levels 1 and 2 were no longer enough

Level 1 and Level 2 conformance were meaningful standards when the dominant attack types were static: printed photos, pre-recorded video loops, and simple 3D masks. The model needed to recognize the known toolkit, and the toolkit changed slowly enough that quarterly retraining kept pace.

Level 3 was introduced in June 2025 because AI-generated attack media had reached a quality level where that assumption no longer held. Face-swap architectures in 2025 could generate novel synthetic faces that had never appeared in any training dataset, making artifact-matching a less reliable detection strategy. A model that held Level 2 conformance in 2024 might not hold Level 3 in 2025, not because the model degraded, but because the attacking capability advanced past what it was trained to catch.

This is the central tension in deepfake detection: the test level advances to match the attacker’s generation capability, but a vendor’s model only advances when it gets updated. If the model belongs to a third party, the vendor waits for that party’s schedule to clear.

The release-cycle gap is a fraud window

Most vendors in the identity verification market did not build their liveness detection engine. They licensed or integrated it from a biometric component supplier, layered their onboarding workflow on top, and shipped a product. The liveness model is not theirs to update.

When a new attack type emerges a new injection method, a new face-swap architecture, a model fine-tuned to spoof the artifact signatures, the current detection layer is looking for the patch chain runs: vendor detects the gap, reports to the component supplier, the supplier prioritizes the request, ships an update, vendor tests and integrates, your instance eventually updates. That chain has a length measured in quarters in most cases, not in weeks.

In the meantime, the attack runs. The gap between the attack’s first documented use and your vendor’s patch is not empty time; it is the period during which a motivated fraudster can onboard successfully at your platform.

There is also an asymmetry that doesn’t get discussed enough. Fraud teams optimize new attack toolkits against live systems before they are deployed at scale. The first victims of a new injection method are not the ones who see a blunt mass deployment; they are the ones whose vendor is running an unpatched model during the initial targeted phase. By the time the patch ships, the adversarial economy has often moved to the next variant anyway.

The vendors who can move faster are the ones who own the model. When they detect a new attack type through production signal monitoring, internal red-teaming, or a regulatory-mandated test they can retrain and ship to production on their own timeline, without routing through a supplier’s backlog.

This is not an abstract architecture preference. It is an incident-response question: when the next attack type lands, who controls your patch, and how fast can they move?

Shufti’s approach to deepfake defence

If your fraud team has filed a ticket with a liveness vendor and been told a fix is “on the roadmap,” you’ve already experienced the structural problem this post describes. The issue isn’t the vendor’s responsiveness; it’s the dependency structure they operate inside.

Most identity verification vendors assembled their biometric layer from third-party components:  liveness from one supplier, deepfake detection from another. When an attack type evolves past their current model, the fix sits in someone else’s backlog.

Shufti built and owns its entire liveness and biometric stack. The detection models are Shufti’s own, which means updates ship on Shufti’s timeline. Active liveness and passive deepfake detection run from the same owned engine, with no component-supplier handoff on the critical path. When the threat evolves, Shufti retrains. That’s the structural answer to the release-cycle problem.

The resulting posture is independently validated: Shufti holds iBeta Level 3 conformance under ISO/IEC 30107-3 tested under the expert-attacker, no-budget-ceiling methodology, covering the advanced AI-generated attacks that Levels 1 and 2 do not reach.