Liveness Detection: Definition and Use in Compliance

What is Liveness Detection?

Liveness detection is a biometric verification control that confirms the subject of an identity check is a physically present person, not a spoofed representation such as a printed photograph, a video replay, or a silicone mask. The check runs at the point of remote onboarding, before identity documents are accepted, and it sits at the center of any compliant Know Your Customer (KYC) program that accepts customers digitally.

The technology works by analyzing a biometric sample for signs of life. Two broad approaches exist.

Active liveness asks the user to perform specific actions during capture: blink, turn your head left, hold up two fingers. The unpredictability of the challenge makes it hard to spoof with a static photo. The downside is friction. Asking a customer to nod, smile, and say a phrase aloud adds time and creates accessibility issues for users with certain disabilities or older devices.

Passive liveness runs silently. The algorithm analyzes depth cues, skin texture variations, light reflectance, and micro-movements in a standard selfie or short video without asking the user to do anything. The trade-off is accuracy; passive systems are generally more vulnerable to high-quality 3D masks and, increasingly, to generative AI-produced faces.

A third attack vector, injection attacks, bypasses the camera entirely. The attacker intercepts the data stream between the camera and the application and injects a synthetic video. Defending against injection requires device integrity verification and runtime application self-protection, controls that sit outside the liveness algorithm itself.

The international benchmark for testing liveness systems is ISO 30107-3, which defines presentation attack instruments, test metrics, and reporting requirements. Financial institutions procuring third-party liveness vendors should request ISO 30107-3 compliance test results, specifically attack presentation classification error rate (APCER) and bona fide presentation classification error rate (BPCER) scores at the institution's chosen operating point. A vendor that won't provide these numbers on request is not ready for regulated deployment.

How is Liveness Detection used in practice?

When a bank or fintech allows customers to onboard through a mobile app, electronic KYC (eKYC) processes typically chain three checks in sequence: document capture and authentication, liveness detection, and face match. The liveness step confirms a live person is present; the face match step confirms that person is the same individual shown in the identity document. These are separate algorithms solving separate problems.

Consider how this works in volume. A major UK neobank processing around 15,000 account applications per day runs active liveness checks on every applicant, then routes liveness failures to manual review. Roughly 3% of attempts fail on the first try, split nearly evenly between genuine users in poor lighting conditions and actual fraud attempts. The manual review queue resolves the genuine failures quickly; the fraud attempts generate records that feed downstream Customer Due Diligence (CDD) reviews and, where patterns emerge across multiple attempts, internal suspicious activity processes.

Beyond account opening, liveness appears in re-verification workflows. Banks subject to periodic KYC refresh cycles deploy passive liveness checks at login or at the point of sensitive authorizations such as large international wire transfers. This shifts the control from a one-time gate to a recurring check tied to risk events.

The configuration that matters most for compliance is the operating threshold. Set the confidence threshold too low and fraudsters pass through; set it too high and genuine customers fail at rates that generate customer complaints and potential discrimination exposure. Most production deployments target a BPCER below 1%. The APCER target depends on the product's documented fraud risk appetite; a high-risk product category warrants a tighter threshold even at the cost of some genuine user friction. Regulators increasingly expect documented, risk-based threshold decisions rather than unreviewed vendor defaults.

Liveness Detection in regulatory context

No major global regulation names "liveness detection" by that exact term, but several frameworks require the underlying control explicitly or by direct implication.

The Financial Action Task Force (FATF) Guidance on Digital Identity, first published in 2020 and updated in 2023, provides the clearest policy statement. It describes presentation attack detection as a technical control expected when digital identity systems are used for customer verification, and it links the required strength of liveness controls to the overall assurance level of the identity evidence being presented. A utility bill plus a selfie produces low assurance. A chip-read government ID plus a liveness-checked video produces high assurance. The assurance level required depends on the transaction risk; higher-risk products require higher assurance.

The European Banking Authority published Guidelines on remote customer onboarding solutions (EBA/GL/2022/15) in November 2022. These guidelines require that video-based identification include controls to confirm the customer is physically present, which in practice means a liveness check. They also require that the technology be as independent of the customer's device camera as possible, a direct reference to injection attack risk.

In the United States, NIST Special Publication 800-63A defines identity assurance levels for remote identity proofing. Identity Assurance Level 3 (IAL3) remote verification explicitly requires a presentation attack detection step, and financial institutions operating at that assurance level for account opening are expected to implement it.

For higher-risk customer categories, liveness detection connects directly to Enhanced Due Diligence (EDD) requirements. A customer flagged as a Politically Exposed Person (PEP) during screening might trigger a supervised video call in addition to automated liveness checks, because the regulatory expectation for assurance is materially higher. The liveness check alone is not sufficient when the customer's risk profile demands an investigator making a judgment call in real time.

Common challenges and how to address them

The most pressing current challenge is generative AI-produced facial spoofing. Europol's 2022 report on deepfakes documented fraud rings using AI-generated video to pass video KYC checks at European financial institutions, with synthetic faces convincing enough to defeat both the liveness algorithm and the human reviewer on the call. The attacks have improved considerably since that report.

The structural gap is a training data problem. Most liveness systems were built on datasets of printed photos and pre-recorded videos. They weren't designed to detect photorealistic generative video, which lacks the texture artifacts and compression signatures that earlier spoofing methods left behind. Vendors have responded by adding skin blood flow detection, blink micro-timing analysis, and spectral imaging. These help, but the gap between attack capability and detection capability is real and shifts regularly.

Demographic bias is a quieter problem. Liveness systems calibrated on non-representative training data show higher false rejection rates for certain skin tones, ages, and lighting environments. This is an AI bias problem with concrete regulatory consequences. If a liveness system rejects customers in a protected class at a materially higher rate, the institution faces discrimination exposure under fair lending and equal access statutes.

How to address these challenges:

• Vendor testing: Require ISO 30107-3 benchmark results segmented by demographic groups before procurement. A vendor that won't provide this data is not ready for regulated use.
• Threshold governance: Document the threshold decision, who set it, the data behind it, and the review cycle. Regulators expect this as a matter of model risk management.
• Injection attack controls: Implement device attestation (iOS DeviceCheck, Android Play Integrity API) as an independent layer from the liveness algorithm itself.
• Human review routing: Route borderline liveness scores to trained reviewers rather than auto-failing them. Auto-fail policies at scale create demographic bias exposure.

Related terms and concepts

Liveness detection doesn't operate in isolation. It's one component of a broader identity verification (IDV) stack, and understanding where it fits clarifies both its purpose and its limits.

Presentation Attack Detection (PAD) is the ISO term for what most vendors call liveness detection. PAD is technically broader: it covers any attempt to defeat a biometric system using an artificial or altered biometric sample. A silicone fingerprint and a printed face photo are both presentation attacks. Liveness detection specifically addresses the face biometric component during remote onboarding and re-verification.

Face match is the verification step that follows liveness. Once the system is satisfied a real person is present, it compares the live image to the photo in the submitted identity document. A system can pass liveness while failing face match (the person is real but isn't who they claim to be) or fail liveness while presenting a genuine document (genuine customer, poor lighting conditions). Both checks must pass for the session to have meaningful assurance value.

Synthetic identity fraud is a related but distinct fraud vector. Synthetic identity fraud builds fake personas from mixed real and fabricated data elements, often without a corresponding real person to present. Liveness detection closes one attack path for synthetic identity fraudsters who try to submit photos of paid individuals or AI-generated faces during onboarding. It doesn't address the downstream problem of a fully constructed synthetic identity that passes document checks because the document data itself is valid.

Deepfake fraud is the most active threat vector against liveness systems today. A deepfake is an AI-generated or AI-manipulated video that replaces one person's likeness with another's. The distinction from earlier spoofing attacks is that deepfakes can be produced in near-real time and may have no detectable artifacts at standard camera resolutions. Defending against deepfakes requires liveness vendors to update their models continuously, not just at annual procurement review cycles.

Biometric authentication covers the wider use of biometrics for ongoing access control beyond initial identity verification. Liveness detection appears in authentication contexts as well, particularly in high-assurance transaction authorization. The standards and failure modes are similar to those in onboarding, but the latency tolerance is lower; a passive liveness check that takes 3 seconds is acceptable at account opening and frustrating at payment confirmation.

Document authenticity checks and liveness detection are complementary controls that must both function for remote verification to carry regulatory weight. A liveness check without document verification confirms a real person is present but not who that person is. Document verification without liveness confirms the document exists but not that the person presenting it is alive and physically present. Neither alone satisfies the control requirement.