What a Liveness Check Is Actually Testing, and Why a Real Face Gets Refused

When something asks you to “take a quick selfie to verify”, two checks are running at once. One is a comparison: your face now against the photo on your document, same person or not. The other is a liveness check: was this a live person at the lens, or a photo, a video played back on a screen, a mask.

When it fails, almost everyone assumes the first one — “it does not recognise me”. Often it is the second. The awkward part is that both tend to fail with the same vague on-screen wording, so the message itself will not tell you which. This page is about the second check.

It scores the presentation, not the person

There is a proper international standard for this, and its vocabulary is clean. The ISO/IEC 30107 series on biometric presentation attack detection defines the thing being caught as:

the presentation of an artefact or of human characteristics to a biometric capture subsystem in a fashion intended to interfere with system policy.

Two companion terms go with it. A presentation attack instrument (PAI) is defined as the “biometric characteristic or object used in a presentation attack” — documented examples include printed photos, a video replayed on a tablet held to the camera, and flexible silicone masks. The other is a bona fide presentation: simply the presentation that is not an attack. NIST’s metrics are defined exactly on that line, splitting samples into attack presentations and bona fide ones.

Look at the subject of each definition. It is always a presentation. Never a person. What is scored is one event at the lens, not your standing as a user. Which is why “I am obviously me” and “this presentation was classified as an attack” can both be true at the same time. You are genuine, and the frames you produced holding a phone in a dim room with a window behind you landed on the side the system treats as suspicious.

The standards also split attacker intent two ways: impersonation, trying to be matched as someone else, and evasion, trying not to be matched as yourself. Account opening is guarding mainly against the first, which is why it is so sensitive to anything that looks like a replay.

The real reason: it is a dial someone set

In September 2023 NIST published NIST IR 8491, an evaluation of 82 prototype algorithms from 45 developers — software only, working on conventional 2D imagery. It reports two error rates:

Then it says the thing everybody skips: as in other decision systems, the two error rates can be traded off against each other — one goes up, the other goes down — by changing a decision threshold. So the report publishes summary numbers from both ends:

• Hold refusals of genuine users to 1% and see how many attacks slip through (the convenience end);
• Hold missed attacks to 1% and see how many genuine users get flagged as attacks (the security end).

Put those side by side and you have it: “harder to spoof” and “refuses fewer real people” are two ends of the same lever. No system gets to maximise both. It picks a position.

And NIST names the situations. Controlling the refusal rate matters where the system owner cannot tolerate high rejection of legitimate submissions and the cost of undetected fraud is not punitive — the example given is eGate operations. Controlling the miss rate matters where rejection of bona fide submissions is acceptable and fraud costs are large — and the example given is bank account access.

One boundary before going further: this site does not know, and cannot find out, where any given platform sets its threshold or which vendor it uses. What is described above is the shared structure of these systems, not a claim about any one company.

In front of the camera, and behind it

The most repeated claim online is that “a virtual camera gets you through”. It refers to a different layer, and naming that layer clears up a lot.

NIST devotes a section of the same report to the split. Physical, analog attacks put an object in front of the sensor — donning a silicone mask, holding up a printed photo or a tablet display. Digital injection attacks are “a direct electronic introduction of a digital image or video”, bypassing the sensor entirely; the report notes these are of particular concern on personal devices, where a virtual camera is not readily distinguishable from the physical one.

And then it states the scope: the evaluation covered physical attacks with analog artefacts, and digital injection attacks were out of scope. That is not merely how one evaluation drew its boundary — it is where the standard itself draws the line:

The attacks considered in this document take place at the biometric capture device during presentation. Any other attacks are considered outside the scope of this document.

So the split is definitional: something injected into the data stream never made that presentation at all. It has to be caught by a different layer, not by a stricter liveness check. The same scope statement also puts “overall system-level security or vulnerability assessment” outside the document — this standard never set out to vouch for the security of a whole system.

Why it passes there and fails here

NIST evaluated passive algorithms — judging from ordinary 2D imagery, with nothing asked of you. The report is explicit that it did not evaluate approaches based on 3D, on near-infrared illumination, or on real-time human interaction with the camera, including challenge-response, variable illumination and automated adjustment of the imaging system.

So what you meet in different places may be fundamentally different technology: one takes a single frame and decides, another asks you to blink or turn your head, another throws changing coloured light at your face from the screen. They frequently come from different third-party vendors, too. Two practical consequences:

1. “It passed there but not here” is ordinary. It does not support the conclusion that something is wrong with your face, nor that something is wrong with the platform.
2. Your experience changes when a platform changes vendor, and that change is not usually announced. A flow that went smoothly last year and stalls this year is not evidence that something happened to your account.

The report also carries an observation ordinary users can use: within the same collection event, many algorithms produce lower error rates when the input is a video sequence rather than a single still. That is a statement about algorithms, not an instruction; our own inference from it is that when a capture asks you to hold still for a few seconds, seeing the whole sequence through steadily is more sensible than moving about or backing out early. Treat that as inference.

What you can change, and what to leave alone

Start with what is yours to change. The warnings platforms print all point at one rule: anything that degrades the image of your face pushes you towards the suspicious side. Binance, for instance, states in its verification steps: “Do not wear hats, glasses, or use filters, and make sure that the lighting is sufficient.” Unpacked:

• Filters and beauty modes alter precisely the texture and geometry cues the algorithm reads. Use the stock camera with every enhancement off.
• Hats and glasses occlude and reflect around the eyes, which is the region that matters most.
• Lighting. Backlight, hard overhead light and dim rooms all strip detail. Find a plain light wall, put the light in front of you, and make your face the brightest thing in frame.
• Screens and printouts. Capturing by pointing at another display or a photograph is the textbook presentation attack instrument — and the report shows print and replay attacks are among the categories detection handles best. A refusal there means it is working.
• The lens. Wipe it. The film on a front camera does more damage to an image than people expect.

Now what to leave alone: any tool or agent promising a guaranteed pass. Beyond the terms and privacy costs above, there is a longer tail — if it does slip through once, your account now rests on a verification record that is not yours, and every later review will surface it.

If what you actually need is to work through the on-screen error state, that is a different job: see face verification failed, sorted by error state, or use the face failure self-diagnosis to work out which class you are in. Shooting the document itself is covered in KYC documents and photo tips. And the other common stumble, well before the camera, is the name field: see entering your name exactly as your ID shows it.

Why this page exists

Search this topic in English and the first page is largely identity-verification vendors writing about their own product category, plus platform-specific help snippets. Vendor explainers are not worthless, but they have a structural blind spot: none of them will tell you that refusing you is a setting, because the setting belongs to their customer, not to you. The two facts that actually answer the question — that the threshold trades security against convenience, and that financial account access is the named example of the security end — sit in a public NIST report that almost nobody links. That gap is the reason for this page.

Questions people ask