"Deepfake fraud" gets used as a catch-all term, but it actually covers a handful of distinct attack techniques, each of which needs a somewhat different defense. Lumping them together is exactly how gaps get left open.

Presentation attacks

The oldest category, and still the most common in practice because it's the cheapest to attempt: holding a printed photo, a phone or tablet playing a recorded video, or a mask up to the camera during the live session. These don't need AI at all - they rely on a poorly-lit call, a low-resolution camera, or a verification agent who's rushing through their tenth call of the hour. A presentation attack is defeated by checking whether the "face" in front of the camera has the depth, texture, and reflectivity of real skin rather than a printed surface or a screen.

Face-swap and deepfake video

This is where generative AI changes the picture. A face-swap tool overlays a synthetic face - built from a handful of reference photos of the target identity - onto a real person's live video feed, in real time, with the underlying person's expressions and head movements driving the fake face's motion. The attacker doesn't need to look like the identity they're impersonating; the model handles that. A few years ago this needed serious compute and expertise. Today it runs as a plugin on a mid-range laptop.

Injection attacks

Arguably the most dangerous category for banks, and the one that gets the least attention. An injection attack skips the camera entirely and feeds a synthetic video file directly into the KYC application's video stream, using a virtual camera driver or a compromised SDK integration. Because there's no physical camera in the loop, none of the depth or texture cues a good liveness system looks for in a presentation attack are even relevant - the attacker is handing the system a video file and telling it "this came from a camera." Detecting this requires checking the integrity of the capture pipeline itself, not just the content of the video.

Voice cloning

For any video KYC flow that includes a voice-based verification step - reading back an OTP, confirming a name, answering a security question out loud - voice cloning is the audio equivalent of face-swapping. A few seconds of sample audio, increasingly easy to scrape from social media or a prior call recording, is enough for current voice cloning tools to produce a passable synthetic voice matched to a target identity.

A basic face-match check answers one question: does the face in this frame look similar enough to the face on the ID document? That's a useful check, and it catches a lot of casual fraud - someone using a stolen ID with their own face, or a mismatched document. What it does not answer is whether the face in the frame belongs to a live, present human being in the first place. A well-made deepfake is specifically optimized to pass that similarity check, because that's the entire point of the attack. If your only gate is similarity scoring between two images, a good synthetic face sails through it.

This is the reason liveness detection exists as a separate, distinct check from face-matching, not a nice-to-have bolted onto it. Face-match answers "is this the same face as the ID." Liveness answers "is this face coming from a real, present person right now." You need both, and treating either one as a substitute for the other is where video KYC programs get exposed.

Liveness detection is the countermeasure, but it isn't one single technique - it splits into two approaches with genuinely different tradeoffs, and vendors aren't always upfront about which one they're selling you.

Active liveness

Active liveness asks the user to perform an action during the capture - blink, turn their head left then right, smile, or read a randomly generated number out loud - and checks that what the camera captured matches the prompt with the right timing. It's intuitive to explain to a compliance auditor or a customer ("we asked you to blink and you blinked"), and it's been the default approach for years because it's relatively simple to build and reason about.

The honest problem: active liveness challenges are, by definition, predictable in structure even if the specific prompt is randomized. Response-time-optimized deepfake tools are increasingly capable of reacting to a displayed prompt within the same real-time video feed - the synthetic face blinks when asked, turns when asked, because the underlying attack is puppeting a live face in real time and can be trained or tuned to respond to whatever the challenge asks for. Active liveness isn't worthless, but it's not the ceiling of protection it once was, and treating it as sufficient on its own is increasingly a gap.

Passive liveness

Passive liveness analyzes a single capture, or a few seconds of ordinary video, without asking the user to do anything - it looks at texture and depth cues (does the surface behave like skin, does it have the micro-variation real skin has under the camera's specific lighting), subtle involuntary micro-movements a synthetic overlay tends to smooth away, and often camera or sensor-level signals about how the capture was actually produced. Done well, passive liveness is harder to spoof because there's no known "challenge" for an attacker to optimize against, and it's far less disruptive to the onboarding experience - no waiting for prompts, no re-recording because the user blinked at the wrong moment.

The honest tradeoff here runs the other way: passive liveness quality depends entirely on the underlying model and the breadth of attack types it was trained against, and it's less visibly explainable - you can't point to a specific action the user took and say "see, they did the thing we asked." A weak passive liveness implementation can be just as exploitable as a weak active one; the label "passive" isn't itself a guarantee of strength.

In practice, most mature setups use passive liveness as the default layer for every session, with a lightweight active step reserved for higher-risk accounts or when the passive check returns a borderline confidence score - defense in depth rather than picking one over the other.

RBI's Video-based Customer Identification Process framework is what allows banks and other regulated entities to complete customer identification remotely, through a live video interaction, as an alternative to in-person verification. In general terms, the framework requires banks to put in place reasonable safeguards that the person appearing on camera during the video KYC session is a live, present individual actually undergoing verification in that moment - not a static photo, a recorded video, or some other substitute presented to the camera.

That's a deliberately general description, and it's worth being precise about why: the specific operational requirements, permitted exceptions, and any updates to the V-CIP framework are matters for your compliance and legal teams to confirm against the current RBI circulars, not something to take as fixed from a vendor blog post. What matters for this discussion is the underlying intent, which hasn't changed even as the threat landscape has - banks doing remote onboarding are expected to have a real, defensible basis for believing the person on camera is who and what they claim to be, live, at the time of verification. Deepfakes and injection attacks are precisely the kind of threat that intent is meant to guard against, and a liveness layer that hasn't kept pace with how those attacks have evolved is a compliance gap as much as a fraud one.

If you're a bank or NBFC evaluating vendors for this layer - or auditing one you already have in production - a few things matter more than a demo reel or a glossy accuracy number.

• Real-time detection speed: liveness checks that add ten or fifteen seconds of visible lag to a video KYC call push customers to abandon the session, or push agents to rush through the check in a way that defeats its purpose. The check needs to run inside the flow of the call, not as a separate slow step bolted onto the end.

• Injection-attack detection, not just presentation-attack detection: this is the gap most vendor pitches gloss over. A system that only checks whether the face in the video has real depth and texture will pass an injected synthetic file just fine, because the injected content can be built to have those cues too. Ask specifically whether the vendor detects virtual camera drivers, SDK tampering, and other signs the capture didn't come from a genuine device sensor.

• Independence from ambient lighting and device quality: your customer base is verifying from a huge range of devices, network conditions, and lighting - a badly lit room, an older phone's camera, a shaky connection in a smaller town. A liveness model tuned mainly on studio-quality test data tends to perform worse exactly where you need it most.

• False-rejection rate for genuine users: a system tuned aggressively against fraud but that also rejects a meaningful share of real customers isn't actually a win - it pushes genuine applicants into manual review queues, frustrates onboarding, and quietly pressures your operations team to loosen thresholds, which undoes the fraud protection you paid for. Ask for false-rejection numbers, not just detection rates, and ask what they were measured against.

• Vendor transparency about testing and certification methodology: what dataset and attack types was the model tested against, how recently was it updated to account for newer generative tools, and is there any independent testing or certification behind the claimed numbers. A vendor that can't answer this clearly, or answers only in marketing language, is a harder one to defend to your own risk committee later.

None of these are exotic asks - they're the kind of due diligence questions a bank's risk and compliance teams should already be running through for any fraud-prevention vendor, and liveness detection deserves the same rigor as any other control that sits directly in your onboarding decision path.

Deepfake and injection attacks against video KYC aren't a distant risk banks can plan around for next year - the tools are already accessible, and the gap between "looks like a live person" and "is verifiably a live person" is exactly where fraud is finding room to operate. Closing that gap means treating liveness detection as its own distinct control, separate from face-matching, and being honest about what active versus passive approaches each do and don't cover. Verify Edge is built around exactly this problem - face-match and liveness capabilities designed with passive liveness and injection-attack detection in mind, as one layer in a broader onboarding verification stack. If you're reviewing your video KYC setup against where deepfake techniques stand today, get in touch with SecureEdge to talk through your flow.