Liveness Detection: What It Is, What Regulators Expect, and What Gets You Cited

What is Liveness Detection?

Liveness detection is a biometric verification control that determines whether the face presented during a digital identity check belongs to a live person physically present at the time of the check, rather than a photograph, video replay, silicone mask, or AI-generated deepfake.

It sits inside the identity proofing stage of 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.

Two implementation patterns are common. Passive liveness uses AI to analyze a single frame or short video clip for involuntary physiological signals: micro-movements, skin texture variation, and light reflection patterns a flat image can't replicate. No user instruction is required. Active liveness prompts the user to perform a specific action, such as blinking, turning their head, or holding up fingers. Active approaches are harder to spoof but add friction to the onboarding journey; institutions typically choose based on the risk tier of the customer segment.

The technical standard most institutions reference is ISO/IEC 30107-3, which classifies presentation attack types (photos, videos, 3D masks) and defines detection performance metrics. The NIST Face Recognition Vendor Testing program benchmarks commercial liveness systems against real-world attack datasets, giving institutions an independent basis for vendor selection beyond vendor-supplied figures.

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

Why is Liveness Detection required?

The regulatory case for liveness detection flows from 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 FATF's 2020 Guidance on Digital Identity addresses this directly. It states that remote identity verification must be assessed against presentation attack risks and that institutions should apply controls proportionate to those risks. The guidance is publicly available at https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Guidance-digital-identity-2020.html.

In the EU, the European Banking Authority's Guidelines on Remote Customer Onboarding (EBA/GL/2022/15) require institutions to check whether the person presenting credentials is physically present. Presentation attack detection is named as a control element for video-assisted and fully automated onboarding channels. The guidelines are available at https://www.eba.europa.eu/regulation-and-policy/anti-money-laundering-and-countering-financing-terrorism/guidelines-remote-customer-onboarding.

In the UK, FCA Finalised Guidance FG22/5 requires firms to assess spoofing risks and implement detection measures for remote onboarding. The FCA expects proportionality: higher-risk customers warrant more stringent liveness controls. The guidance is at https://www.fca.org.uk/publication/finalised-guidance/fg22-5.pdf.

In the US, 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.

Know Your Customer (KYC) is the broader control family of which liveness detection is one component. Without it, the KYC chain has a gap that synthetic identity fraudsters and account takeover operators will exploit.

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 (see https://www.wolfsberg-principles.com/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 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.

How Liveness Detection connects to other controls

Liveness detection doesn't work alone. It's one part of an identity and fraud control stack, and its effectiveness depends on how well it connects to adjacent controls.

Customer Due Diligence (CDD) is the parent control. Liveness detection validates the identity verification step within CDD. A failed or inconclusive liveness check should trigger a CDD escalation, not just an onboarding rejection. If the liveness outcome isn't fed back into the CDD record, the compliance team has incomplete information for risk rating the customer.

Enhanced Due Diligence (EDD) applies when standard liveness controls aren't sufficient. High-risk customer segments, PEPs, and high-value remote onboardings should trigger EDD-level identity verification, which may include video call identity checks or document notarization alongside automated liveness.

Transaction Monitoring downstream benefits from good liveness data. Accounts that passed liveness with low confidence scores can be flagged for heightened transaction monitoring during the first 90 days. The liveness confidence score is a useful behavioral baseline signal that most institutions don't yet pass downstream.

Sanctions screening and adverse media screening run in parallel to liveness in the onboarding flow. An account that passes liveness but hits a sanctions match should be held. The liveness pass doesn't override other controls.

The typologies most directly relevant to this control 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.