When a user holds their phone up to complete a selfie KYC check, how does the system know it's looking at a real person and not a photograph? That's the problem liveness detection solves — and it's one of the most practically important components in any identity verification pipeline.
What is a presentation attack?
A presentation attack is any attempt to fool a face recognition or verification system by presenting something other than a live face. The three most common types are:
- 2D print attacks — holding a printed photograph in front of the camera
- Replay attacks — displaying a video of the legitimate user on a screen
- 3D mask attacks — wearing a silicone or paper mask constructed from images of the target
Print and replay attacks are trivially easy to execute. Mask attacks require more effort but are increasingly accessible. A robust identity verification system must defend against all three.
Active vs passive liveness
There are two broad approaches to liveness detection:
Active liveness asks the user to perform an action — blink, smile, turn their head, or follow a moving target. This is effective but creates friction. Users hate it. Drop-off rates on active liveness challenges can be 15–30% higher than passive flows.
Passive liveness analyses a single still frame or short video clip without asking the user to do anything. The model looks for micro-texture inconsistencies, specular reflection patterns, and depth cues that distinguish a real face from a 2D or 3D artefact. Done well, passive liveness is transparent to the user — they just take a selfie.
Quantilence uses passive liveness detection. A single image is sufficient to generate a liveness score and spoof classification.
Why it matters for KYC compliance
Regulations are increasingly explicit about liveness requirements:
- EU eIDAS 2.0 (Regulation 2024/1183) and its implementing acts for the European Digital Identity Wallet require certified Presentation Attack Detection for high-assurance identity verification
- NIST SP 800-63B §5.2.3 requires that biometric authenticators implement PAD at Authenticator Assurance Level 2 and above — the relevant bar for financial-services authentication
- FATF Digital Identity Guidance (2020, updated 2023) explicitly permits non-face-to-face onboarding when technology provides "equivalent or higher assurance", with liveness detection as a core requirement for that equivalence
- Financial regulators in the UK (FCA), EU (EBA), and US (FinCEN) increasingly expect liveness evidence as part of digital onboarding audit trails
Beyond compliance, liveness detection is a basic economic necessity. Account takeover fraud costs financial institutions billions annually. The spoofing vectors are well-known and cheap to execute. Not having liveness in a face-based KYC flow is a significant liability.
What to look for in a liveness API
Not all liveness APIs are equal. Key metrics to evaluate:
- BPCER (Bona Fide Presentation Classification Error Rate) — the rate at which genuine live users are incorrectly rejected. Should be under 3%.
- APCER (Attack Presentation Classification Error Rate) — the rate at which spoofs pass as live. Should be under 1% for print and replay attacks.
- Demographic parity — accuracy should be consistent across skin tones, ages, and image conditions. Ask vendors for disaggregated benchmarks.
- Latency — liveness detection should complete in under 200ms to avoid degrading the user experience. Our median is ~120ms.
Injection attacks — the threat passive liveness alone doesn't stop
Passive liveness analyses the captured frame content. A more sophisticated attack bypasses this entirely by injecting a synthetic or pre-recorded video upstream of the camera interface — the application never receives a real camera feed, so the liveness model sees a perfect synthetic face. Defending against injection requires signals outside the video frame: device attestation (Apple DeviceCheck / Google Play Integrity confirms the app runs on a genuine unmodified device), cryptographic frame signing (each frame is signed with a device-bound key at capture time and verified server-side before inference), and request behaviour analysis (automated attack pipelines produce anomalous timing and API call patterns). A liveness vendor that does not address injection attacks is only solving half the problem.
Integrating liveness into a KYC flow
The standard integration pattern pairs liveness detection with document verification and face matching: capture a selfie, run liveness on it, then match the selfie face against the photo on the submitted ID document. The liveness step must come first — there's no point matching a high-quality spoof against a genuine ID.
Quantilence's liveness API accepts a single JPEG or PNG and returns a liveness score (0–1), an overall live/spoof verdict, and, where detectable, a spoof type classification. No SDK required. Try it in our live demo.
