Document-only KYC is no longer good enough. Deepfakes defeat selfie checks. Synthetic identities sail through document scans without raising a flag. Credential stuffing walks straight through password-based defences. Pick any single signal, and it covers one attack surface while leaving the others wide open.
The four-signal identity stack solves this by combining document verification, liveness detection, behavioural biometrics, and device intelligence into a layered architecture. Each signal plugs a gap the others cannot. They all feed into a risk orchestration layer that produces one decision: allow, step up, or block.
This article defines each signal type, explains how they fit together architecturally, and gives you a practical framework for deciding what to adopt first. It builds on why static KYC fails against these threats and sits at the architectural core of the broader identity proofing stack overview.
Why does multi-signal identity verification outperform document checks alone?
Document verification authenticates the credential — passport, driving licence, national ID — but it cannot confirm the person presenting it is actually its owner right now. A fraudster can present a genuine stolen document alongside a deepfake selfie and the document check passes without question.
Fraudsters also rely on anti-detect browsers, device emulators, proxy networks, and automated bots — attack surfaces that document verification simply cannot address. The 2025 Verizon DBIR found stolen credentials involved in 31% of breaches, with the human element present in 76% overall.
The four-signal approach maps each signal type to a distinct attack surface. Document verification checks the credential. Liveness detection checks the presenter. Behavioural biometrics checks the session behaviour. Device intelligence checks the environment. None of those surfaces overlap, which is exactly why no single signal is ever sufficient on its own.
There’s also a friction benefit. Leading practitioners combine identity verification, behavioural signals, and device intelligence to start with low-friction checks, then only step up when risk actually increases. Most genuine users pass through without noticing a thing. Suspicious sessions face escalating barriers.
What does liveness detection actually do — and what is the difference between active and passive?
Liveness detection verifies that a selfie or video stream comes from a live human present in real time — not a photograph, mask, deepfake, or virtual camera injection. It closes the gap that document verification leaves open: confirming the presenter is actually the document’s owner.
There are two approaches.
Active liveness asks the user to do something — blink, nod, follow a prompt — while AI analysis verifies completion. It creates an audit trail and visible security assurance. The tradeoff is friction: active liveness increases user abandonment and creates accessibility barriers.
Passive liveness asks nothing of the user at all. The system analyses a standard selfie using AI to detect skin texture, blood flow, 3D depth, and motion cues. iProov’s Express Liveness delivers 98% completion rates in production and averages 1.08–1.22 attempts to pass. Users have no idea anything is being evaluated.
But there’s a wrinkle. Presentation attacks use a physical artefact — a printed photo, silicone mask — held in front of a camera. Injection attacks bypass the camera entirely, inserting a synthetic video stream (deepfake, virtual camera software, or man-in-the-middle) directly into the data path. NIST SP 800-63-4 now mandates that identity systems detect virtual camera injection, not just physical presentation attacks.
Passive liveness alone cannot detect injection attacks. iProov’s Dynamic Liveness closes this gap using Flashmark technology, which projects a unique one-time colour code to the device. The reflection confirms the individual is authenticating in real time — a synthetic video stream cannot replicate it.
On certification: iBeta Level 1 PAD tests liveness systems against commercially available spoofing artefacts. Level 2 tests against custom-fabricated, high-quality artefacts. Level 2 is the highest independently certified PAD assurance level available and is typically required for eIDAS LoA High compliance.
Use passive liveness with injection attack detection for standard consumer onboarding. Use active liveness for high-value transactions, regulated financial services, or contexts where eIDAS LoA High is a hard requirement. The vendor certification requirements for liveness in regulated contexts go into this in more detail.
How does behavioural biometrics work and what does it catch that other signals miss?
Behavioural biometrics analyses how people interact with devices and applications — not what they present at a checkpoint, but how they behave throughout the entire session.
The signals cover keystroke dynamics (timing, pressure, error rate), mouse movement (trajectory, speed, click timing), touch interactions (scroll, tap, swipe), and navigation flow (session progression, time on steps, action sequence). Together they build a behavioural fingerprint that bots and automated scripts cannot replicate convincingly. Bots produce mechanically uniform timing, linear mouse paths, and impossible navigation speeds. Humans produce irregular, self-correcting patterns.
What makes behavioural biometrics distinctively useful is the continuous nature of it. Static authentication verifies once, then trusts the session. Behavioural analytics recalculates risk as context changes throughout the journey — which matters most for session hijacking and account takeover scenarios where the attacker looks legitimate at login but diverges during high-risk actions.
CrossClassify maps specific signals to specific fraud vectors: keystroke cadence detects bots, geovelocity anomalies detect account sharing or takeover, and navigation flow anomalies flag synthetic identity actors. Fraudsters cannot maintain perfectly consistent behaviour over long sessions — which is exactly what continuous monitoring catches.
For FinTech, HealthTech, and EdTech deployments, GDPR considerations apply. The compliant path: collect interaction timings and trajectories rather than raw keystroke content, generate derived features, and support regional consent modes.
Behavioural biometrics tells you a lot about the user — but nothing about the environment they’re operating in. That’s where device intelligence comes in.
What is device intelligence and how does it differ from device fingerprinting?
The market conflates these two terms all the time, but they are not the same thing.
Device fingerprinting builds a static identifier from device attributes — browser type, operating system, screen resolution, installed fonts. Think of it as a licence plate that identifies the device. It tells you which device, but says nothing about risk. And fraudsters know how to swap plates.
Device intelligence reads the whole driving record. It watches behaviour, usage patterns, and context to answer: is this the same customer from yesterday, or someone who has cloned their identity? Why is this device logging in from five cities in a single day? As Stuart Dobbie, Senior Product Director for Digital Trust at Feedzai, puts it: “The idea of a device ID as a persistent, static identifier is dead. What’s replacing it is something far more adaptive: a living, breathing signal shaped by behavior over time, in context, and in relation to other entities.”
The signals device intelligence actually collects: device type and OS version; VPN and proxy detection; jailbreak and root detection; historical device reputation; multi-account detection; and contextual signals like login patterns and historical usage. Microblink frames this as accuracy, accountability, and efficiency — preventing losses before they occur and reducing false positives.
The ROI case is concrete. Proof’s FlightHub case study showed a 6% reduction in false positives after integrating device intelligence — fewer abandoned carts, stronger customer trust, no changes to other verification components.
Device intelligence assesses the environment (trusted device? behind a VPN? associated with fraud?), while behavioural biometrics assesses the user’s behaviour within that environment. See the vendor landscape for each signal type for evaluation guidance.
How do the four signals combine in a risk orchestration layer?
The risk orchestration layer is what takes inputs from all four signal types and produces a single decisioning output. Without it, each signal operates in isolation and cannot inform the others.
The inputs arrive asynchronously, which matters for your architecture. Device intelligence is available immediately at session start. Behavioural biometrics builds over time. Liveness detection occurs at specific onboarding checkpoints. Your orchestration layer needs to handle signals arriving at different times with different confidence levels.
Processing combines these inputs into an aggregate risk score or risk tier. The three-tier model works like this:
Low risk (trusted device, normal behavioural patterns, valid document on file) — session is allowed through with no additional friction. Medium risk (new device but normal behaviour, or a known device with minor behavioural anomalies) — proportionate challenge triggered, such as OTP verification, a knowledge check, or a passive liveness re-check. High risk (unknown device behind VPN, abnormal keystroke patterns, geovelocity anomaly) — active liveness detection, document re-verification, or a block with manual review routing.
The FP Summit practitioner framing puts it well: “winning merchants are not those with the toughest gates — they are the ones making smarter decisions.” Combining identity verification, behavioural data, and device intelligence stops more attacks and challenges fewer genuine customers.
Threshold configuration is an explicit design choice: a FinTech processing financial transactions will set lower step-up thresholds than an EdTech platform managing student records.
What does a step-up authentication model look like in practice?
Step-up authentication is the operational output of the risk orchestration layer. Additional verification only applies when the risk signals warrant it — not uniformly across every user, every time.
In online banking, a user logs in with a valid password but typing rhythm and navigation diverge as they try to add a new payee — step-up MFA triggers before funds move. In a FinTech payout scenario, a contact detail change is followed by behaviour shifts and a new beneficiary — the system pauses the payout and routes to review with device and address reuse evidence attached.
Geovelocity anomaly detection adds location context: a user logging in from London and then Sydney 30 minutes later triggers an elevated risk score because the time between interactions is physically impossible.
Behavioural models also reduce false positives by recognising normal customer behaviour even when other signals look unusual — the travelling customer, the new device, the urgent purchase. Trusted devices glide through. The step-up model is configurable: tighter thresholds for financial transactions, looser for lower-risk interactions. See how these signals feed into continuous lifecycle verification for how this extends beyond the initial session.
Which signals should you prioritise when building the stack?
Your architecture should be proportionate to your risk exposure, regulatory requirements, and budget. All four signals from day one is rarely the right starting point.
Start here for most businesses: document verification plus passive liveness detection with injection attack detection. This covers your onboarding identity proofing requirement, closes the deepfake gap, and meets the KYC regulatory minimum for financial services.
Next: add device intelligence. It brings environmental context with relatively low integration complexity — it operates as an independent signal layer without touching your existing document or liveness verification stack.
After that: behavioural biometrics. It delivers the most ongoing signal value but needs more data to build accurate baselines. Strong deployments use ensembles that correlate behaviour with device, network, and journey context rather than relying on a single metric. Start with a pilot on two or three high-risk journeys with clear success criteria — fewer blocked genuine users, earlier detection of risky transfers — then expand from there.
Design your orchestration layer for four signals from the start, even if you only activate two initially. Retrofitting an orchestration layer after the fact is expensive and disruptive. Build for your end state, then fill it in incrementally.
Vendor bundling is worth a look. Feedzai combines device and behavioural intelligence. Microblink combines document verification and device intelligence. A bundled vendor may cost more per transaction but saves the engineering time that would otherwise go to integrating and maintaining separate point solutions.
GDPR consent requirements for behavioural biometrics data collection apply in FinTech, HealthTech, and EdTech contexts. Build for data minimisation, transparency notices, and opt-out pathways from the start rather than retrofitting them later.
For the full vendor landscape for each signal type, including how to assess vendor claims about device intelligence versus fingerprinting, and for integrating signal layers into your identity assurance architecture see the dedicated architecture guide. Return to the identity proofing stack overview for the broader identity proofing context.
Frequently asked questions
Does liveness detection store biometric data?
It depends on the implementation. Most modern liveness detection systems process biometric data in real time and discard it after the verification decision, storing only a confidence score. iProov handles this server-side rather than storing biometric templates on the client device. When evaluating vendors, ask specifically whether biometric data is stored, for how long, and under what data processing basis — particularly relevant for GDPR compliance.
Can behavioural biometrics be spoofed?
Harder than spoofing static credentials, but not impossible. A fraudster would need to replicate an entire pattern of keystroke cadence, mouse movement, scroll behaviour, and navigation flow simultaneously — and maintain it throughout the session. Sophisticated bot frameworks can mimic some behavioural patterns, but combining behavioural biometrics with device intelligence catches most of these attempts through environmental anomaly detection. No signal is unspoofable, which is exactly why the multi-signal architecture exists.
Is device fingerprinting the same as device intelligence?
No. Device fingerprinting is a component of device intelligence — it creates a unique identifier from device attributes. Device intelligence builds a dynamic, ML-scored risk profile that adds behavioural patterns, network intelligence, historical reputation, and multi-account signals on top. If a vendor claims “device intelligence” but only provides a static device ID, they are offering fingerprinting. Ask for specifics.
What is an injection attack and how does it differ from a presentation attack?
A presentation attack uses a physical artefact — a printed photograph, silicone mask — held in front of a camera. An injection attack bypasses the camera entirely by inserting a synthetic video stream directly into the data path — deepfake software, virtual camera tools, or man-in-the-middle interception. NIST SP 800-63-4 mandates detection of virtual camera injection, not just physical presentation attacks. Passive liveness systems that only address presentation attacks remain vulnerable to injection.
What does iBeta Level 1 and Level 2 PAD certification mean?
iBeta is an NIST-approved testing laboratory for liveness detection systems. Level 1 uses commercially available spoofing artefacts. Level 2 uses custom-fabricated, high-quality artefacts. Level 2 is the highest independently certified PAD assurance level available and is typically required for eIDAS LoA High compliance. Ask vendors for their certification level and testing date.
Can I add device intelligence to an existing identity verification workflow without replacing my current system?
Yes. Device intelligence deploys as an API-based signal that operates independently of your document verification or liveness detection vendor. It slots into an existing verification flow without requiring changes to anything else.
What is eIDAS Level of Assurance High and when does it apply?
eIDAS defines three Levels of Assurance for digital identity: Low, Substantial, and High. LoA High requires certified liveness detection at iBeta Level 2 PAD equivalent and applies to regulated digital identity services in the EU — financial services, government services, and cross-border identity schemes. If your business serves EU customers in regulated sectors, LoA High requirements will shape your liveness detection vendor selection.
How does geovelocity detection work?
Geovelocity flags physically impossible travel patterns — a user logging in from London and then Sydney 30 minutes later. The system calculates whether the time between location-stamped interactions is consistent with possible physical travel and triggers an elevated risk score if not. CrossClassify fuses geovelocity with device intelligence and behavioural signals rather than treating it as an isolated indicator.
What signals indicate a synthetic identity in a multi-signal stack?
Synthetic identities exhibit anomalies across multiple signals rather than one obvious red flag. Document verification may pass — synthetic identities often use genuine document numbers. But behavioural biometrics may detect scripted interaction patterns, and device intelligence may flag the device as associated with multiple accounts or a VPN pattern common in fraud operations. The orchestration layer catches synthetic identities precisely because it correlates signals that individually appear marginal but collectively indicate fabricated behaviour.
Do I need all four signals for regulatory compliance?
KYC regulations for financial services typically mandate document verification plus liveness detection as a minimum. eIDAS LoA High requires certified liveness. NIST SP 800-63-4 mandates injection attack detection. Behavioural biometrics and device intelligence are not currently mandated by regulation but are considered industry best practice. Start with the regulatory minimum and layer additional signals based on your threat exposure.
