Liveness and deepfake detection

A quality outcome on this step is fail or review, with a cite that names which check tripped. Auto-pass is allowed only when liveness, document tamper, and face-match each return a pass you can store on the application. A weak selfie that looks sharp under office lighting is not a pass. A vendor confidence number without those cites is not a completed KYC file.

Identity and fraud ops own this gate because a synthetic face or a replayed ID at capture poisons every downstream control. Sanctions screening, customer identification, and deposit monitoring inherit the identity you booked. If this check is soft, later queues spend time on the wrong people.

Vendors in this class, including Onfido, Jumio, and iProov, typically wrap capture, liveness, and document inspection into an SDK and a score. Treat that layer as capture-and-score. Your policy decides fail, review, or continue. Do not map "score above threshold" to "customer is verified."

Start capture in the onboarding app or the assisted branch channel, not from an email attachment. Bind the session to an application ID, a device or workstation ID, a timestamp, and an operator ID when a banker is assisting. The applicant presents the ID first, then the selfie, in the same session. Do not accept a selfie uploaded hours later against an ID captured yesterday.

For the ID, capture both sides when the document type has a reverse, under the SDK glare and crop guidance. Freeze the raw frames you will send to tamper and extraction. Do not let the applicant crop after the fact.

For the selfie, require a live challenge the model can score, such as a turn, blink, or spoken prompt, limited to what your vendor session actually supports. Reject a single still as the liveness sample. Keep the capture short enough that dropout does not become an informal bypass.

If ID data will later pre-fill the application, run extraction only after tamper has not failed. Form pre-population from ID extraction is a convenience step. It is not a substitute for liveness or face-match.

Order the work so a later check never cleans up a missing earlier cite.

Liveness runs on the selfie session. The outcome is pass, fail, or insufficient sample. Insufficient is not pass.

Tamper runs on the ID frames: reprint, screen recapture, photo-of-photo, MRZ or hologram inconsistency the vendor exposes, cropped edges that hide a laminate. The outcome is pass, fail, or review.

Face-match runs between the live selfie and the ID portrait. The outcome is match, mismatch, or unusable portrait.

Write the cite on the application: check name, vendor session ID, model or policy version, and the discrete result. If you only store a blended score, reviewers cannot tell whether lighting, injection, or a mismatched face caused the flag.

Here is the pattern to train against, not a measured case study. An applicant presents a government ID that extracts cleanly, then a well-lit face that sits in frame. Lighting and crop look fine, so an image-quality gate would go green. The liveness step sees a video-injected feed rather than a live person. The correct booking is fail, or review if your policy requires a second sample, with cite liveness: presentation-attack / injection. It is not pass because the photo was clear. Face-match is irrelevant until liveness has a pass. Booking that applicant as verified because OCR completed is the failure this page exists to stop.

Do not publish a detection rate for that attack. Your control is the cite and the fail-closed rule, not a percentage on a slide.

No-liveness means the session did not prove a live person. That includes timeout with no usable frames, a challenge not completed, injection or replay flagged, or the vendor returning an error. Fail closed: do not create a funded account, do not issue a debit product, do not treat the KYC file as complete. Offer one retry with a new session ID so you can tell attempt 1 from attempt 2. A second no-liveness is still fail, not good enough.

Ambiguous is different from no-liveness. Ambiguous includes low confidence, face-match in a gray band, an ID type the tamper model has not seen, or capture conditions your fairness review has already flagged as error-prone. Queue those to identity ops or a four-eye desk. The queue item must show the frames, the cites, and which check is uncertain. Do not dump them into a generic manual KYC pile with no reason code.

Keep two failure modes off the production path.

The first is passing because lighting was fine. Image quality is a capture hint, not a liveness result. A deepfake or replay can be well lit. If your dashboard greens on brightness and sharpness, you will auto-pass attacks that never faced a live challenge.

The second is blocking every dark-skin selfie without a review path. If false fails concentrate on darker skin tones, poorer cameras, or branch lighting, a hard fail with no queue becomes a discriminatory block. That is an ops design failure, not strict risk. Route those sessions to review with the same cite discipline. Track fail and review rates by channel and capture condition so you can change lighting guidance, device allowlists, or vendor settings without silently auto-passing the weak samples.

Risk-tiered onboarding routing should consume these outcomes as structured reasons: fail-closed, review-liveness, review-tamper, review-face-match, or continue. A single refer bucket hides which control actually moved.

When all three checks cite pass, you have a live person who presented an ID that did not fail tamper and a face that matched the portrait. You do not yet have a completed customer file. Name, date of birth, and address still need to land in the application. Sanctions and PEP still need to run. Product eligibility still needs a decision. Agentic KYC orchestration is where this gate sits among those steps. Do not skip orchestration because the selfie SDK returned a high score.

The same identity can still be first-party fraud at funding. A live applicant can open with their own ID and bounce a first deposit or mule the account. First-party fraud detection at first deposit starts after this page's job is done. AML work at funding is a later file, not a liveness retry. AML case disposition at funding should inherit the capture cites so investigators know whether the face at onboard was live, reviewed, or never proven.

After go-live, sample fail and review files weekly and confirm every auto-pass has three cites. Watch for operators who re-run capture until the score looks friendly. Watch for product teams who treat vendor verified as a checkbox that closes customer identification. If a check cannot produce a cite, it cannot produce a pass.