Liveness Detection for KYC: Protection Against Spoofing Attacks

Why face liveness detection breaks on real-world streams

In the lab, liveness checks look reliable: even light, tripod, clean optics.

In production traffic through a cheap front camera in the subway or by a window, contrast drops, frames come with noise and compression desync — and face liveness detection either lets a spoof through or rejects real customers.

False rejections at registration are the most expensive part: a person hits "try again" once, and some never come back.

Face spoofing attacks in production also rarely look like in a demo. Replay use of a recording — pre-recorded video of a speaker held up to the camera; cruder — a photo on a screen with glare on the glass.

More complex is stream interception: a virtual camera or video feed substitution before analysis, when all checks formally pass, but instead of a person there is a software double.

A single-frame liveness check cannot distinguish this: it has neither depth nor dynamics. Hence two errors at once — a high threshold catches scenes but breeds rejections, a low one opens a bypass of liveness checks.

In a long funnel, it is not security that suffers but conversion: traffic goes to manual review, and some customers go to those whose registration passed on the first try.

We examine how this is closed: a cascade of checks, active challenges, and injection analysis at the stream capture level.

Some teams take ready-made engines for a quick start, for example iProov, — but the consent, quality degradation, and rollback scenario is still designed for the product.

What liveness checks deliver: measurable effects at the entry point

The effect of liveness checks is measured not by model accuracy on a demo dataset, but by a set of counters that we take from real traffic before implementation and compare after.

This shows exactly what changed at the registration entry point, rather than "it got better overall." The metric set is the same for any funnel: share of blocked attacks, share of successful passes, check time, number of retries, and rejection structure.

• Share of blocked attacks — calculated separately by spoof class: static photo, photo from a screen, video stream from a screen, mask, synthetically generated face. For presentation attack classes, blocking reaches a level confirmed by independent iBeta certification and is not blurred by a single averaged metric.
• Registration conversion — passive verification without "turn your head" challenges does not cut the funnel: live users pass the step on the first try, and the share who reach the end grows due to those who previously abandoned the scenario halfway.
• Check completion time — fits within 1-3 seconds together with frame capture and decision making; a separate app and manual moderation are not needed for this.
• Number of retries — decreases when hints on lighting and face position in frame return the person to the same scenario instead of throwing them back to the start.
• Rejection class — false spoof acceptance goes away; false rejection of a live person becomes a manageable value through the sensitivity threshold and review of disputed cases using the decision log.

Each item is not a reporting number but a tuning knob: by changing the threshold, we see how the balance between attack blocking and successful pass rate is restructured.

Face liveness detection formats: passive, active, hybrid

The verification mode is chosen not by "in a vacuum" accuracy, but by the entry scenario: how the user captures themselves, how much effort they are willing to put in, and what costs more — a missed spoof or a lost customer.

The same algorithm on mass onboarding and on confirmation of a large transaction gives different results: where the cost of a miss is higher, stricter verification is justified; where flow matters, one invisible to the person.

The method's limitations only show up on live traffic, so we collect metrics on a pilot sample — share of successful first-attempt passes, rejection reasons, completion time — and use them to choose the mode. This way the solution adapts to your entry scenario, not to a description from a presentation.

Liveness check implementation stages: from scheme to handover

Liveness check implementation starts not with code, but with analyzing your verification scenario: where the user is, where the operator is, what happens on rejection, and what risk level you are willing to accept.

Then the order is fixed — first we describe data in motion, then calibrate sensitivity for your traffic, and only then test the solution on live people and spoof attempts.

This rules out a situation where face liveness detection passes lab tests but on production traffic lets a spoof through or blocks a real customer.

1. Verification scenario audit. We analyze the user's steps: registration, login, re-verification, escalation to an operator. We record at which step detection is needed and what counts as failure — rejection or a request for additional confirmation.

2. Data flow scheme. We determine where the frame is captured, where it is processed, what goes to external services, and what stays in your environment. The scheme shows storage points and biometric data lifetimes.

3. Sensitivity threshold setup. The threshold is a trade-off between false spoof acceptance and false rejection of a live person. We calibrate on your statistics: camera quality, lighting, typical user devices.

4. Testing on live people. We run the scenario on employees and real traffic: different shooting conditions, age, glasses, headwear, weak connection.

5. Testing on spoof attempts. A separate attack set: photo from a screen, printout, video recording, mask, video stream substitution. We count each class separately to see where the solution holds up.

6. Solution handover and team training. We hand over configurations, the scheme, a set of test scenarios, documentation on thresholds and recalibration procedure. Your engineers change sensitivity and add scenarios without us.

Configurations, schemes, and regulations: what remains with the customer

A liveness check application should not remain a black box accessible only to the developer. We hand over to the customer's team a full set of artifacts — from check profiles to the procedure for handling a suspicious pass attempt.

This is enough to tune sensitivity for your traffic, review disputed cases, and evolve the solution without us.

• Check profiles — active scenarios, confidence thresholds, and rules for different entry points: web, mobile app, reception terminal. Changed by configuration, without rebuilding the model.
• Integration schemes — call order, response formats, behavior when the service is unavailable, request examples for each channel.
• Incident review procedure — how to distinguish a false rejection from a spoof attempt, which events to store, whom to escalate to, and within what timeframes.
• Verification documentation — description of each check, composition of the test set, shares of false acceptances and false rejections on your traffic.
• Storage and logging policy — which frames and events we record, what we mask, how long we store them, and how we delete them upon data subject request.
• Operations instructions — profile updates, rollback to the previous model version, checklist before releasing changes.
• Knowledge transfer — architecture walkthrough with your team, answers on disputed cases, support tier contacts.

After the solution handover, you manage settings and case review yourselves, and our role comes down to consultations on complex episodes.

Case study: how a class of face spoofing attacks on verification disappeared

What it was before

Verification relied on comparing a selfie with a document photo, and the sign "there is a live person in frame" was not checked at all.

Bypass went three ways: photo from a screen, pre-recorded video, and a virtual camera substituting the stream from the device — each such attempt passed as a regular application.

The share of missed spoofs stayed around 9%, false rejections reached 12%, and manual review of suspicious applications took almost half of operators' shifts.

What was changed

Liveness checks were built directly into the capture moment: passive frame assessment plus a short active sequence that cannot be reproduced by a recording.

Bypass attempt review was moved to a separate log — with spoof type, rejection reason, and model decision, so every new scheme could be seen and closed with a rule, not a one-off ban.

Tuning was done on real applications, and we separately monitored that real customers would not be rejected in weak light, glasses, or motion.

The outcome

The share of missed spoofs fell from ~9% to 0.4%, false rejections — from 12% to 3%, and successful first-attempt passes increased by a quarter. The manual review queue shrank by about four times: operators look only at borderline cases.

Resilience to new spoofing schemes was confirmed by an independent test according to the iBeta methodology — this is external verification, not our internal assessment.

How does passive liveness detection differ from active?

Passive verification requires nothing from the person except looking at the camera. The system itself collects a sequence of frames and evaluates liveness signs: micro-movements, changes in reflections, face depth.

For the user, this is ordinary selfie capture; for the customer, it is a minimum of steps in the registration scenario.

Active verification is built as a challenge-response: the system asks the user to turn their head, blink on a prompt, move their face closer or farther.

The user's action during the check becomes part of the protocol — a screen recording or a substituted photo will not reproduce such a challenge, because it is generated anew for each attempt.

But a dependence on behavior appears: the person did not understand the prompt, got distracted, is in a hurry at the payment stage — and the scenario is not completed.

The share of false rejections in the two modes differs by source. Passive produces fewer rejections on the stream — there is nothing to fail, no step that can be performed incorrectly.

However, it is more sensitive to frame quality: a weak camera, backlight, glasses with glare consume part of the features. Active is more resilient on weak channels, but gets its own share of rejections from user behavior, not from capture quality.

Choosing the verification mode is not about "what is stricter," but about which scenario it fits. Initial registration, re-login to a personal account, and confirmation of a high-risk transaction require a different balance between strictness and conversion.

The working scheme is a hybrid: passive verification at entry and active as escalation when model confidence is low or the request looks atypical.

Limitations and technical concerns about liveness checks

Weak lighting and a mid-range front camera produce more rejections than real spoofs. Backlight and a dark room consume texture details, and the passive scenario begins rejecting live people.

Thresholds are never a constant: when the user stream or camera models change, the solution requires recalibration. We calculate false rejection and false acceptance shares separately — their balance depends on which error class is more expensive in your process.

Do you store user images?

By default, no: frames live in memory only during the check, then only a numeric descriptor remains. If per regulations images are needed for reviewing disputed cases, we enable a separate storage with a limited retention period, encryption, and access segregation.

How often will thresholds need to be reconfigured?

After launch — once or twice, then according to monitoring signals: growth in rejections, mass change of camera models, a new traffic source. Calibration is done on a labeled sample from your side so that thresholds reflect the real audience, not a test set.

Let's discuss the task: where the project begins

A face liveness detection project begins not with model selection, but with analyzing the customer verification scenario.

We need to understand exactly where the person goes through verification — in a mobile app, in a web account, or on an operator's tablet — and which spoofs are realistic for that channel: photo from a screen, video recording, mask, camera video stream substitution.

This determines the set of checks in the chain, the triggering thresholds, and how the system behaves in weak lighting or on a slow communication channel.