Biometric verification
Face match, liveness and ID document checks
Biometric verification compares a person's biometric characteristics with a reference associated with the identity they claim. In a document-based online flow, that usually means comparing a selfie with the portrait on a government ID. A document check assesses the credential, a liveness check looks for spoofing, and face matching assesses whether the two images show the same person.
Verification, identification and authentication
Biometric systems do two kinds of comparison. Authentication is one of the things the first kind is used for.
| Term | What it is | Reference used | Typical example |
|---|---|---|---|
| Verification | A 1:1 comparison against the reference for a claimed identity | Whatever is tied to that claim: an ID portrait, a wallet credential, or a template enrolled earlier | Checking a selfie against a driver's license |
| Identification | A 1:N search to find who someone is among many people | A gallery of many enrolled people | Watchlist or border screening |
| Authentication | Using verification to confirm a returning user | A template the user enrolled earlier, often on their own device | Unlocking a phone with your face |
You will also see it called face verification, selfie verification or biometric identity verification. In each case the comparison is one to one.
Facial recognition is the umbrella term: it covers both verification and identification. What matters for a business is where the reference comes from:
- Checking someone against an ID they present needs no earlier enrollment.
- Re-authenticating a returning user means you, or their device, enrolled and stored a reference first.
For apps and websites, the characteristic used is almost always the face. Every phone has a camera, and nearly every government ID carries a portrait. Fingerprint and iris systems usually need dedicated readers.
Looking for fingerprinting for a background check? That is livescan, done in person by a licensed provider. An online flow cannot do it.
How it works
The three checks in a document-based flow
Take Maya, a seller changing where her payouts go. Before the change goes through, the platform runs all three in one session, in this order.
Document check
The ID is captured and inspected: issuer format, the machine-readable zone or barcode, and signs of tampering such as altered fields or a replaced photo.
Liveness
The capture is tested for signs that it is not a live person in front of the camera, such as a printed photo, a screen replay or a mask. Standards call this presentation attack detection (PAD).
Face match
The live face is compared with the portrait on the document, and the result says how strongly they match.
What each combination helps establish
Each check is evidence, not certainty. Together they are much stronger than any one alone.
| Checks run | What it helps establish | What it leaves open |
|---|---|---|
| Document only | The credential looks genuine | Whether the person presenting it is its holder |
| Face match without liveness | The selfie resembles the ID portrait | Whether the selfie came from a live person or a photo of the holder |
| Liveness without a document | Someone live appears to be present | Who that person is |
| All three | A live person who resembles the portrait on a credential that looks genuine | Whether they are allowed to do what they are asking. That is your policy's call |
You don't always need all three
In Stile, liveness can run on its own, without a document. That fits cases where you only need to know a live person is present, such as slowing down bots or repeat sign-ups, but it does not tell you who the person is.
No combination is perfect
Plan for the legitimate person who cannot finish a check, whether because of a damaged ID, a poor camera, lighting, or a disability. Offer a retry, a route to manual review, or another way to verify.
Camera attacks and injected media are different threats
- Presentation attacks are shown to the camera: prints, replays, masks. PAD testing measures these.
- Injected media comes in through a virtual camera or a modified app. It never passes in front of a lens, so PAD results do not speak to it.
When you evaluate a vendor, ask about both, and ask what their test evidence covers and what it does not.
Stile's liveness evidence
- Runs on AWS Rekognition Face Liveness.
- iBeta conformance letters for ISO/IEC 30107-3 PAD Level 1 and Level 2, covering presentation attacks at the camera.
- Not a measure of face-match accuracy or bias, and not a test of the whole verification flow.
More on the iBeta PAD levels and on how Stile's liveness works.
When the credential is a mobile driver's license
A mobile driver's license (mDL) or wallet ID built on ISO/IEC 18013-5 changes the document step:
- No photo of a card to inspect. The verifier checks the issuer's cryptographic signature.
- Only what you ask for. The wallet shares just the attributes requested, called selective disclosure.
Whether you also need a selfie depends on the wallet, how it is presented and the assurance you need. In Stile, an mDL can replace photographing a physical license, and liveness or face match are added when your policy requires them.
Where it fits
Where biometric verification fits
Use it when the cost of the wrong person acting is high, and a password or one-time code cannot tell you who is acting. Passwords and codes show that someone holds a secret or a device. They do not show who that someone is.
Opening an account
Opening an account where regulation or fraud risk calls for knowing the customer.
Recovering an account
Recovering an account after the normal login is lost.
Changing a payout
Changing where money is paid out.
Releasing an item
Releasing a high-value or age-restricted item.
Before you add a check
Vendors and drivers
It also fits onboarding a vendor, driver or seller who gets access to customers or goods.
Identity is not permission
Your own records still decide whether this person owns the account, represents the vendor or holds the pickup assignment.
When to skip it
Use something lighter when the action is low-risk. Tie each check to a specific action, and tell the person which action triggered it.
Biometric privacy rules
Biometric data is regulated in many places, and the rules differ in:
- What triggers them
- What notice and consent they require
- How long data can be kept
Several US states have biometric privacy laws. In the EU and UK, biometric data used to identify someone is special category data, which needs a specific legal condition to process.
Principles that hold up across most of them:
- Tell people first. Say what you collect, why, who processes it and how long it is kept, before the capture starts.
- Get consent where it is required, in the flow itself. When a Stile workflow requires explicit biometric consent, the widget collects it before the biometric step and records it against the session.
- Keep it only as long as the purpose needs, and have a written retention and deletion policy.
- Be ready to delete on request.
This is not legal advice. Confirm your obligations in each jurisdiction with counsel before launch.
Retention
What gets kept, and by whom
People asked for a selfie want to know one thing: is it kept? Your system needs proof that a check happened, not a copy of the face or the ID. With Stile, the result reaches your server as an HMAC-SHA256-signed webhook carrying the outcome. Document images, raw PII and biometric templates are not in it.
How long Stile keeps each kind of data
| Data | How long it is kept |
|---|---|
| Captured document images and extracted document data | Purged after the final verification or review decision. A session held for review keeps the evidence the reviewer needs until the review resolves |
| Biometric data, such as face-match templates | 72 hours by default. A jurisdiction's rule can set a different window. Can be deleted on request, independently of the outcome |
| Other personal data collected by the workflow | Purged under the session's data-retention window |
| Hashed anchors (for example an email hash or document fingerprint) | Kept for deduplication and returning-user lookup. Not raw data, but still treated as sensitive |
| The verification outcome | Kept, so a returning user can skip re-verifying until the credential expires |
What to keep on your side
A stored selfie is rarely better evidence than a signed result. It is a breach liability and a deletion request waiting to happen.
The outcome
Store it with the session it belongs to.
Which checks ran
Record each check and its result.
An audit trail
The timestamp and the signed event you received.
It is one kind. Facial recognition covers both 1:1 verification, which checks one person against one claimed identity, and 1:N identification, which searches one face against many. Checking a selfie against an ID is 1:1 verification.
Not to check them against an ID they present. That comparison uses the portrait on the credential from the same session. You need a stored reference only if you want to re-authenticate the same person later without an ID.
Liveness checks are designed to catch photos, replays and masks presented to the camera, and independent PAD testing measures how well they do. Video injected into the capture channel is a separate attack that PAD testing does not cover. No check is perfect, so pair the result with your own risk signals and a review path.
Authentication is a use of verification. Verification is the 1:1 comparison itself. Authentication uses that comparison to confirm a returning user against a reference enrolled earlier, the way a phone unlocks.
Stile prices completed checks, and the first 1,000 each month are free. The pricing page lists current rates for a full check and for each component.
Add biometric verification to one workflow
Start with the one action where the wrong person costs you most. Create a free account to get sandbox and production keys.