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. It sits inside the identity proofing stage of Know Your Customer (KYC), between document capture and customer due diligence. When a customer submits an identity document remotely, liveness detection is the mechanism that confirms the person holding that document is the person claiming to be them.

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. Institutions typically choose between the two based on the risk tier of the customer segment.

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/IEC 30107-3, which classifies presentation attack instruments (photos, videos, 3D masks) and defines test metrics and reporting requirements. Financial institutions procuring third-party vendors should request 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. The NIST Face Recognition Vendor Testing program benchmarks commercial systems against real-world attack datasets, giving an independent basis for selection beyond vendor-supplied figures.

In regulatory guidance the control appears under the broader umbrella of remote identity verification or digital identity verification, and it is sometimes called presentation attack detection (PAD) or anti-spoofing verification.

---

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 starting point is FATF Recommendation 10, which requires institutions to identify and verify customer identity using reliable, independent source documents, data, or information. When onboarding happens remotely, reliable verification increasingly means demonstrating that a live person presented the identity document, not a spoofed image or injected video. The Financial Action Task Force's 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 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 require that video-based identification include controls to confirm the customer is physically present, which in practice means a liveness check, and they name presentation attack detection as a control element for both video-assisted and fully automated onboarding channels. They also require the technology be as independent of the customer's device camera as possible, a direct reference to injection attack risk.

In the UK, FCA Finalised Guidance FG22/5 requires firms to assess spoofing risks and implement detection measures for remote onboarding, with proportionality: higher-risk customers warrant more stringent controls.

In the United States, NIST Special Publication 800-63A defines identity assurance levels for remote identity proofing, and Identity Assurance Level 3 explicitly requires a presentation attack detection step. Separately, FinCEN's Customer Identification Program rules under 31 CFR § 1020.220 require banks to verify the identity of each customer. Weak remote identity checks have appeared in exam findings and consent orders, with examiners citing the absence of controls against synthetic identity fraud.

For higher-risk customer categories, liveness detection connects directly to enhanced due diligence. A customer flagged as a politically exposed person during screening might trigger a supervised video call in addition to automated 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.

---

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.

---

What do regulators expect to see?

On exam day, examiners aren't looking at your vendor brochure. They want documented evidence that the control is designed, calibrated, tested, and supervised.

Policy documentation. A written policy defining what liveness detection is, where it applies in the onboarding flow, which customer segments and channels it covers, and what happens when a check fails or returns a low-confidence result. The policy should be versioned and approved at an appropriate governance level.

Vendor assurance. Evidence that the vendor solution has been tested against a recognized standard. ISO/IEC 30107-3 Level 2 or higher is the benchmark. NIST FRVT results for the specific vendor version in production are the strongest independent evidence available. EU institutions should be able to demonstrate compliance with EBA/GL/2022/15 requirements, which means vendor certification documentation should be on file.

Threshold calibration records. The specific confidence score thresholds used to pass, refer, or reject a check, with documented rationale. Change history showing every adjustment and the approval trail behind it. If a threshold was changed after a fraud spike, the examiner wants to see the business case.

Adversarial testing records. Internal or third-party penetration testing showing the solution was challenged with known attack vectors: printed photos, digital photos displayed on phone screens, pre-recorded video replays, and, for institutions onboarding higher-risk customers, deepfake video. Frequency should be at least annual and more often when the threat environment changes.

Escalation and referral records. Clear documentation of what happens to customers who fail liveness. Who reviews the referral queue, within what SLA, and what is the outcome distribution? Examiners flag unmanaged backlogs.

MI and governance reporting. Management information covering pass rates, failure rates, referral volumes, false positive and false negative rates, broken down by channel and product. Per FATF Rec 11, records must be retained for at least five years. Liveness session metadata, outcomes, and challenge artifacts should be stored with the customer record and retrievable for exam review.

---

What does good Liveness Detection look like?

Good liveness detection isn't about deploying the most aggressive solution. It's about matching the control to the risk.

A well-designed implementation follows these steps:

1. Risk stratification. Map the customer population to risk tiers. A standard retail customer onboarded in-branch differs from a high-value remote onboarding for a trading account. Higher risk warrants active liveness with a higher confidence threshold. Lower risk may be managed with passive detection.
2. Vendor selection against ISO/IEC 30107-3. Select vendors that have tested against the standard and can supply Level 2 performance data. NIST FRVT results for the specific vendor version in production are the strongest independent evidence. Don't accept vendor-published figures alone.
3. Threshold calibration with documented rationale. Set confidence score thresholds based on the institution's fraud risk appetite, not the vendor default. Document the rationale, and revisit it when fraud patterns change or the vendor releases an update.
4. Fallback and manual review. Design a clear fallback path. Customers who fail automated liveness can be referred for assisted verification, a video call identity check, or a branch visit. The fallback path needs its own SLA and is monitored for backlog.
5. Ongoing monitoring. Track false positive rates (genuine customers incorrectly rejected) and false negative rates (spoofed identities incorrectly passed) at least monthly. A rising false negative rate is an early warning signal.
6. Regular adversarial testing. Challenge the system with current attack vectors at least annually. Deepfake quality has improved substantially since 2022; what passed testing three years ago may not reflect today's threat.
7. Change control. Any change to the vendor solution, threshold, or process requires documented approval, regression testing, and version control.

The FATF's Digital Identity Guidance sets the benchmark framework. The Wolfsberg Group's Financial Crime Compliance Programme guidance stresses documented control rationale and ongoing effectiveness measurement as set out in the Wolfsberg Standards). The EBA's remote onboarding guidelines provide the most granular EU-specific requirements, including the specific obligation to test for presentation attacks.

---

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.

---

Common audit findings and exam citations

Liveness detection failures rarely look like complete absence of the control. They look like a control that exists on paper but doesn't work in practice.

Undocumented thresholds. The vendor's default threshold is running in production with no institutional analysis of whether it matches the firm's risk appetite. Examiners ask who approved it, when, and why. If there's no answer, it's a finding.

No testing record. The solution was deployed, often years ago, and never adversarially tested. The vendor was updated twice since deployment, and the thresholds weren't re-validated. The control's effectiveness is assumed, not demonstrated.

Missing segmentation. Enhanced Due Diligence (EDD) customers, politically exposed persons, and high-value account applicants go through the same standard liveness check as retail customers, with no uplift. Examiners treat this as a segmentation failure in the CDD framework.

Manual review backlogs. The referral queue for failed liveness checks has accumulated hundreds of unreviewed cases. Some customers were approved into the bank without a cleared liveness outcome because the queue wasn't managed. The Danske Bank 2018 enforcement action illustrates what regulators conclude when KYC controls exist nominally but aren't operationally enforced: the institution onboarded thousands of non-resident customers through controls that were never properly calibrated or supervised.

Deepfake blind spot. The liveness solution was built before commercially accessible deepfake tools became widespread. It was never updated or tested against video injection or face-swap attacks. Regulators and fraud examiners have started asking about this explicitly since 2023.

No MI. Liveness pass and fail statistics aren't tracked, reported, or reviewed. Compliance teams can't tell an examiner what the false positive rate is or whether it has changed quarter-on-quarter. Absence of MI is treated as evidence of weak governance, not just incomplete reporting.

---

Metrics and KPIs

Measuring liveness detection health requires separating operational metrics from control effectiveness metrics.

Operational metrics:

• Pass rate: The percentage of liveness checks resulting in a pass outcome. A sudden spike may indicate threshold drift or a vendor update. A sudden drop may indicate a new attack vector or a technical fault.
• Failure rate (automated reject): The percentage of checks resulting in hard rejection. Track by channel and product line.
• Referral rate: The percentage of checks returning a low-confidence or inconclusive result and routed to manual review.
• Manual review SLA compliance: The percentage of referred cases resolved within the defined SLA (typically 24 to 48 hours). Backlog size over time is a governance signal.
• Manual review outcome distribution: Of referred cases, what proportion are ultimately approved, rejected, or abandoned by the customer?

Control effectiveness metrics:

• False positive rate (FPR): Genuine customers incorrectly rejected. A high FPR drives onboarding abandonment and may create discrimination risk. Track by customer segment where permitted.
• False negative rate (FNR): Spoofed identities incorrectly passed. Direct measurement is hard; proxy metrics include the proportion of onboarded customers who subsequently appear in fraud investigations or are linked to Money Mule Networks. Accounts opened with synthetic or stolen identities are a primary mule account source.
• Threshold change log: Number of threshold changes in the period, with documented rationale for each.
• Adversarial test results: Pass and fail rates against test attack vectors, compared against the prior period.

Report operational metrics monthly to the financial crime operations team and control effectiveness metrics quarterly to the risk committee. Threshold changes should trigger an out-of-cycle governance report.

---

Related terms and concepts

Liveness detection is 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. Document authenticity checks work the same way: a liveness check without document verification confirms a real person is present but not who that person is, and neither alone satisfies the control requirement.

Synthetic identity fraud is a related but distinct fraud vector. It 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 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 them requires vendors to update their models continuously, not just at annual procurement review cycles.

Customer due diligence is the parent control. Liveness validates the identity verification step within CDD, so a failed or inconclusive check should trigger a CDD escalation rather than just an onboarding rejection. If the outcome isn't fed back into the CDD record, the compliance team has incomplete information for risk rating the customer. Enhanced due diligence applies when standard controls aren't sufficient: high-risk segments, PEPs, and high-value remote onboardings should trigger EDD-level verification, which may include video call identity checks or document notarization alongside automation.

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

Transaction monitoring downstream benefits from good liveness data. Accounts that passed with low confidence scores can be flagged for heightened monitoring during the first 90 days. The confidence score is a useful behavioral baseline signal that most institutions don't yet pass downstream. Sanctions and adverse media screening run in parallel to liveness in the onboarding flow, and an account that passes liveness but hits a sanctions match should still be held; the liveness pass doesn't override other controls.

The typologies most directly relevant are money mule networks, where accounts opened with synthetic or stolen identities are the primary sourcing mechanism, and authorized push payment fraud, where receiving accounts are frequently opened via identity spoofing. When liveness detection is poorly calibrated, those accounts enter the bank undetected and don't generate alerts until money has already moved.

---

How FluxForce supports Liveness Detection

FluxForce AI agents monitor onboarding flows in real time, correlating liveness session outcomes with behavioral and transactional signals to build a complete picture of new-customer risk. Nova Sentinel maps liveness confidence scores to post-onboarding activity patterns, surfacing accounts that passed automated checks but exhibit behavior consistent with synthetic identity or mule account use. Every decision comes with a full evidence trail, giving compliance teams the documentation regulators expect on exam day. Request a demo to see how FluxForce maps to your liveness detection control framework.