Biometric Verification: Face Match, Liveness and Fraud Prevention

What biometric verification covers, and what it does not

Biometric verification answers one question: is the person in front of the camera the same person the record or document says they are? It does not, on its own, tell you that the document is genuine, that the identity exists in an authoritative source, or that the person is not on a sanctions list. Those are separate checks. In a complete onboarding flow, the biometric step is the link between a real, present human and a claimed identity.

This guide focuses on face match and liveness in remote onboarding: how each works, how to read accuracy figures, what certification does and does not prove, and what privacy law expects. For the wider picture of how the methods fit together, see What Is Identity Verification? How Online ID Checks Work. For database-based checks, see Electronic Identity Verification.

Types of biometrics

Biometrics fall into two groups: physiological traits (what you are) and behavioural traits (how you act). Remote onboarding relies mostly on the face because every smartphone and laptop already has a camera. Other modalities need dedicated sensors or are better suited to later authentication than to first-time identity proofing.

The key practical point is the reference. Face works for onboarding because the ID document already carries a face image captured under controlled conditions. For a returning customer, you can instead compare against the selfie captured at onboarding.

Face match vs liveness: two different checks

The two are often sold as one feature, but they fail in different ways and should be evaluated separately.

• Face match (1:1 comparison) answers "do these two images show the same person?" A model converts each face into a numeric template and produces a similarity score. You compare that score to a threshold set for your risk appetite.
• Liveness detection answers "is this a live person captured now, by this camera?" It targets spoofing, not look-alikes.

A perfect face match proves nothing if the selfie was a photo of a photo. A perfect liveness result proves nothing if the live person is not the one on the ID. You need both, and you need the document check upstream: a face match against a forged or tampered ID simply confirms that the fraudster looks like the fraudster. See document authentication for that layer.

1:1 verification is also distinct from 1:N identification, where one face is searched against a large gallery. Onboarding uses 1:1. Some providers and fraud teams additionally run 1:N searches against their own previously rejected or fraudulent faces to catch repeat attempts, which raises extra privacy questions covered below.

How a 1:1 face match works

1. Capture. The user photographs the ID and takes a selfie. Quality checks reject blur, glare, heavy shadow, sunglasses or partial faces before any matching happens.
2. Extract the portrait. The face is located and cropped from the ID. Holograms, watermarks, small image size and ageing of the photo all make this the harder side of the comparison.
3. Create templates. A model turns each face into a template, a numeric representation rather than a stored picture.
4. Score and decide. A similarity score is compared with the threshold. Above it, the result is a match; well below it, a non-match; in between, many teams route to retry or manual review.

Where the ID photo is ten years old, or the user has changed hairstyle, gained glasses or is photographed in poor light, genuine users score lower. That is why a three-way outcome (pass, retry or review, fail) usually works better than a single hard cut-off.

Passive vs active liveness

Liveness methods are usually grouped by how much the user has to do. (For a short definition, see the separate page on liveness detection; this section covers the design trade-offs.)

Neither is automatically more secure. A well-built passive check can outperform a weak active one, and a randomised active challenge can add protection where risk is high. What matters is independent testing results and how the check behaves against the attacks you actually see. Many deployments choose passive by default and step up to an active or assisted check for higher-risk cases.

Accessibility deserves a place in this decision. Users with limited mobility, tremors, facial differences or visual impairment can struggle with prompted movements. Offer an alternative path rather than treating every failure as suspicious.

Reading accuracy metrics: FAR, FRR and the threshold

Vendor accuracy claims are only meaningful if you know which error they describe and at what threshold.

• False acceptance rate (FAR): how often the system accepts someone who should have been rejected, such as an impostor whose face is compared with someone else's ID.
• False rejection rate (FRR): how often the system rejects a genuine user.
• Threshold: the score cut-off. Raising it lowers FAR and raises FRR; lowering it does the reverse. Quoting one without the other, or without the threshold, is incomplete.

Biometric testing literature also uses FMR and FNMR (false match and false non-match rates) for the algorithm alone, and FAR and FRR for the whole system including capture failures. ISO/IEC 19795-1 sets out principles for biometric performance testing; see ISO for the standards catalogue.

Metrics for spoof detection are different

Liveness is measured with different error rates. Under ISO/IEC 30107-3, presentation attack detection results are reported as:

• APCER (attack presentation classification error rate): attacks wrongly accepted as genuine.
• BPCER (bona fide presentation classification error rate): real users wrongly flagged as attacks.

The same trade-off applies. A figure like "99% accurate" without APCER, BPCER, attack types and test conditions tells you very little. When reviewing a provider, ask for both error rates, the attack instrument types tested, and the devices and lighting used.

Practical points that rarely make the top results

• Set thresholds per use case, not once for all. A low-value account with other controls can tolerate a lower threshold than a high-limit wallet or a payout change.
• Measure FRR as drop-off. Every false rejection is a genuine customer who may abandon. Track retry rate, abandonment at the selfie step, and manual-review outcomes by device type and region.
• Check for differential performance. Error rates can differ across demographic groups, skin tones, ages and camera quality. Ask providers how they test for this and review your own outcomes by segment where lawful to do so.
• Test on your population. Lab results on benchmark data may not reflect low-end Android cameras, poor connectivity or older ID photos in your markets.
• Keep a fallback. Assisted review or an alternative verification route keeps genuine users from being locked out and reduces pressure to loosen thresholds.

Presentation attacks and injection attacks

Attacks on biometric checks fall into two categories that need different defences.

Presentation attacks

A presentation attack puts a fake trait in front of the camera. Common instruments include a printed photo, a photo or video replayed on another screen, a cut-out or 3D mask, and a lifelike mask or prosthetic. Liveness detection is designed to catch these. Because the attacker must physically present something to the sensor, these attacks are limited by the attacker's materials and effort, and they are what standardised testing covers.

Injection attacks

An injection attack bypasses the camera. The attacker feeds pre-recorded, manipulated or AI-generated video straight into the app or browser data stream, often using virtual cameras, emulators, rooted devices or tampered apps. The liveness model may then be analysing a synthetic feed it assumes is a real camera. Defences sit largely outside the face algorithm: device and app integrity checks, virtual-camera and emulator detection, signed capture from a trusted SDK, and session and device risk signals. This makes IP and device intelligence a useful companion to biometric checks. Deepfakes and injection attacks have their own page, Deepfakes and Injection Attacks in ID Verification, which covers the defence in detail.

The key distinction for buyers is that a liveness result tells you how well the system resisted attacks presented to a camera. It does not automatically tell you how it resists a manipulated video stream. Ask about both.

For how biometric signals feed wider fraud controls, see what is biometric fraud detection, and fraud detection for the broader programme.

Certification and testing: ISO/IEC 30107-3 and iBeta

ISO/IEC 30107-3 is the international standard for testing and reporting presentation attack detection. It defines how to run the tests and how to report results (including APCER and BPCER), so that results from different systems can be compared on a common basis. Details of the standard are available from ISO.

iBeta is an independent test lab that runs presentation attack detection evaluations against ISO/IEC 30107-3. Its testing is commonly described in two levels, with Level 2 using more sophisticated attack instruments than Level 1. Check iBeta's published information for the current scope and criteria.

When a vendor cites certification, ask:

1. Which product and version was tested? A result applies to a specific build, not the vendor's brand.
2. Which level, and which attack types? Level 1 and Level 2 are not equivalent.
3. Is there a confirmation letter or report you can read? Marketing badges are not test reports.
4. Does it cover your capture channel? Web, native app and SDK behave differently.
5. Does it say anything about injection attacks? ISO/IEC 30107-3 addresses presentation attacks, so a pass does not, by itself, speak to injection.

Certification is a useful floor and an efficient screen when comparing vendors, but it is a lab result under defined conditions. It does not replace your own testing, monitoring and fraud review.

Privacy and consent

Facial templates are personal data you cannot change if they leak. Regulators treat them accordingly. This section is general information; requirements vary by jurisdiction and change over time, so confirm current rules with the relevant regulator or legal counsel. It is not legal advice.

GDPR (EU and UK-style regimes)

Under the GDPR, biometric data is defined in Article 4 as personal data from specific technical processing of physical characteristics that allows or confirms unique identification of a person. Article 9 treats biometric data processed for the purpose of uniquely identifying a person as a special category. Processing is prohibited unless one of the Article 9(2) conditions applies, such as explicit consent, or a basis in Union or Member State law. Because a 1:1 face match to verify identity is processing for unique identification, you should assume Article 9 applies and document your condition.

Practical consequences:

• You also need a lawful basis under Article 6 in addition to the Article 9 condition.
• Where consent is relied on, it needs to be explicit, specific and freely given. Offering a genuine alternative route, such as manual review, supports that.
• Principles in Article 5 (purpose limitation, data minimisation, storage limitation, security) apply. Delete selfies and templates when the purpose ends and be clear about retention.
• Large-scale processing of special category data and systematic use of new technologies may call for a data protection impact assessment under Article 35.
• Member States may add their own conditions on biometric data, so local rules matter.

Australian Privacy Act

In Australia, the Privacy Act 1988 treats biometric information and biometric templates as sensitive information. Under the Australian Privacy Principles, collecting sensitive information generally requires the individual's consent and the collection must be reasonably necessary for your functions or activities, subject to exceptions. Organisations must also take reasonable steps to secure the information. The OAIC publishes guidance on sensitive information and the Australian Privacy Principles. Reporting entities under AML/CTF law should also consider how their identification obligations interact with privacy obligations.

Design choices that reduce risk

• Tell users clearly before the selfie step what is captured, why, who processes it and how long it is kept.
• Separate the verification purpose from any other use, such as model training or cross-customer fraud matching, and get advice before enabling those.
• Store templates, not raw images, where your process allows, and encrypt both in transit and at rest.
• Define retention periods that reflect your regulatory record-keeping duties without keeping biometric data longer than needed.
• Do due diligence on processors, including where data is hosted and which sub-processors are involved.

ScreenlyyID's own handling of data is described on its security and privacy policy pages.

Use cases

• Customer onboarding: selfie-to-ID match plus liveness at account opening for fintech, banking, crypto, gaming and marketplaces. See customer onboarding, and what is eKYC for how this fits a fully online KYC process.
• Step-up verification: re-checking a face when risk spikes, for example a change of payout details, a new device or a password reset following suspected account takeover.
• Account recovery: replacing weak knowledge-based questions with a selfie compared to the one captured at onboarding.
• Age checks: where age is determined from a verified document, the selfie confirms the document holder is present. See the age verification guide.
• Marketplace and gig platforms: confirming that the person using an account is the person who was verified, and limiting multiple accounts per individual where the law permits.

Putting biometrics in a verification flow

1. Authenticate the document and extract its data and portrait.
2. Run liveness on the selfie capture, with a risk-based choice of passive or active.
3. Match the face to the ID portrait at a threshold that matches the risk of the product.
4. Corroborate with database checks, address, email, phone and device signals where relevant.
5. Screen against sanctions and PEP lists where your obligations require it.
6. Route outcomes: auto-approve, retry, manual review or decline, and record the reasons.
7. Monitor pass rates, retries and fraud outcomes by device and channel, and revisit thresholds regularly.

ScreenlyyID offers biometric verification with document authentication, eIDV, AML screening and device intelligence through one API, within the wider identity verification product. The identity verification hub links to related guides.

Questions to ask any biometric vendor

• What are the APCER and BPCER, at what thresholds, and under which attack types?
• Which product version has independent PAD testing, at which level, and can I see the report?
• How do you defend against injection and virtual-camera attacks?
• How is performance tested across demographics, devices and lighting?
• What is stored, where, for how long, and how is it deleted?
• What fallback is available for users who cannot complete the capture?