Confirming Identity vs. Confirming a Real Human Is Present

Person holding their ID card with facial coding verifying the human

A user can pass an identity check. That alone doesn’t tell an organisation whether a real person is on the other end of the interaction. That gap matters wherever accounts, payments, moderation decisions or access rights depend on more than a claimed identity.

Javelin’s 2026 Identity Fraud Study puts combined identity fraud and scam losses at $38 billion in 2025. Identity fraud alone accounts for $27.3 billion of that, across 18 million victims. (Source) None of that requires broken identity data. It requires only that a system can’t tell a legitimate claim from a fake one. That fake could be a stolen credential, a replayed session, or an automated script presenting the same information.

For the full breakdown of identity proofing, identity verification and where human verification fits, see identity proofing vs identity verification. Here’s the practical question that follows. Once you treat identity confidence and presence confidence as two separate signals, what changes in your risk decision layer?

Identity Confidence and Presence Confidence Answer Different Questions

Identity verification asks whether submitted information matches a known person or authorised account. It doesn’t establish that the person is physically present and interacting in real time. A stolen credential can carry the right information. So can a replayed video or an automated script, without a live human behind it. Liveness and human-presence checks close that gap. But they answer a narrower question of their own. They can confirm a real person is present. They can’t establish which identity that person holds.

Treating either signal as a stand-in for the other is where the risk shows up. The wrong actor can still operate a verified identity. A confirmed live human isn’t automatically the account’s authorised owner.

Keep Them as Separate Signals in the Decision Layer

The practical fix is architectural, not conceptual. Keep identity confidence and human-presence confidence as separate attributes in the decision layer. Don’t collapse them into a single score. A high-confidence identity match can support onboarding or account recovery. A high-confidence presence signal can indicate that a live person, not a script or replay, is conducting the session. The action taken should reflect both signals combined. It should also weigh the stakes of the specific transaction, not either signal alone.

This separation also makes investigation more useful after the fact. An account may belong to a legitimate person while a specific session shows signs of automation or impersonation. A live human may be present without holding authority over the account in question. Those are different failure modes, and a combined score obscures which one occurred.

Worked example

A financial account-opening flow might validate a government-issued document and match its data against the application. It might then separately confirm a live person is present for the biometric capture. Say the document checks pass but the liveness signal is weak. That’s a different risk profile from a strong liveness signal paired with an inconsistent document. Each calls for a different response. Combining the two into one pass/fail outcome loses that distinction.

Don’t Let a Second Signal Become a Second Data Store

Adding a presence signal to the decision layer doesn’t loosen the case for data minimisation. Biometric data is sensitive and difficult to replace once compromised. Evaluate the signal, then discard it, rather than retaining it as a parallel repository alongside identity records. Ask three questions. What does the presence check need to prove? How long does any derived signal need to persist to support the decision? Would the same outcome hold with less data retained?

Frequently Asked Questions

Should identity confidence and presence confidence use the same threshold?

Not necessarily. They measure different things, so the right threshold for each depends on the risk of the specific action being gated, not a single shared cutoff.

What happens if identity and presence checks disagree?

That disagreement is itself a useful signal. A strong identity match with a weak presence signal, or the reverse, should route to a different outcome, such as step-up, manual review, or decline, rather than being averaged into one score.

Verify real humans. Without the friction.

VerifEye confirms users are real and unique in seconds. No documents, no stored data, no drop-off.

Protect

Fraud Detection API: Human Signals for Risk

A fraud detection API adds human-presence and uniqueness signals to risk decisions, balancing latency and false positives.

Protect

Insurance Claims Fraud: How Identity Verification Reduces Losses

Reduce insurance claims fraud with liveness and identity checks that catch synthetic identities, without slowing down honest policyholders.

Protect

Remote Hiring Identity Verification: A Practical Guide

Remote hiring identity verification confirms real workers and blocks ghost-worker fraud. See the 7-step workflow and where VerifEye fits.