How should organisations use face comparison in onboarding without creating new fraud or bias risks?

Teams should use face comparison as one control in a broader identity proofing flow, not as a standalone trust decision. The strongest use case is matching a live selfie or liveness image against a trusted reference image, while keeping review paths for mismatches and edge cases. Accuracy also depends on representative training data, threshold tuning, and clear KYC and AML governance.

Why Face Comparison Matters in Onboarding

Face comparison can reduce friction in onboarding, but it should be treated as an identity signal, not proof of truth. The control only works when the image being matched is tied to a trusted enrolment step, the capture is live, and the organisation has a way to review low-confidence results. That matters because onboarding is exactly where synthetic identities, document tampering, and rushed approvals can slip through.

It also creates a bias and false-rejection problem if the system is treated as universally reliable. Performance can vary by image quality, lighting, camera quality, age, skin tone, head coverings, disability, and the quality of the reference image. The governance question is therefore not whether face comparison is useful, but where it fits in the proofing chain and what evidence is required before it can influence a decision. Current guidance suggests pairing it with document checks, device and session signals, and human review for exceptions rather than letting a single score decide access.

In practice, many teams discover the weakness only after a rejected applicant, a fraud attempt, or a disproportionate exception pattern has already exposed it.

How Face Comparison Should Work in Practice

The safest model is to use face comparison as one step in a layered onboarding flow. A live selfie or liveness capture is matched against a trusted reference image, but the result is only one input to a broader decision. That broader decision should also consider document validation, control over the enrolment channel, risk-based review, and whether the claimed identity aligns with other asserted attributes.

Operationally, the main design choice is thresholding. A low threshold reduces false rejects but increases fraud exposure; a high threshold reduces fraud acceptance but can create avoidable friction and bias-related outcomes. Organisations should tune thresholds against their own population and use a clear exception path for edge cases rather than forcing borderline matches into an automated yes or no. The control should also distinguish between a failed comparison, a failed liveness check, and a mismatch between the reference image and the enrolled identity record, because those are different failure modes with different responses.

Face comparison is strongest when the reference image comes from an authoritative source and the onboarding flow is resistant to replay, spoofing, and account takeover. That is why it is usually better to treat the technology as a verification aid rather than a standalone trust decision. A useful governance pattern is to require review when a score falls near the acceptance boundary, when the source image is poor quality, or when the applicant presents higher fraud indicators from other controls.

Use live capture and liveness checks before comparison, so a static image cannot be reused easily.
Separate identity proofing evidence from the matching score, so reviewers can see why a case was accepted or escalated.
Validate performance across demographic and environmental conditions, not just average accuracy.
Retain audit trails for threshold settings, manual overrides, and exception outcomes.

For teams building formal controls, NIST’s identity and security guidance can help anchor the surrounding process, while FATF recommendations remain relevant when onboarding sits inside KYC and AML obligations. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks is also useful for practitioners who want a governance lens on identity trust, review paths, and control drift.

These controls tend to break down when organisations let the matching engine make the final decision without a separate fraud review path or a documented thresholding standard.

Common Failure Modes and Edge Cases

Tighter face comparison thresholds often reduce impersonation risk, but they also increase false rejects and can disproportionately affect legitimate users whose images are harder to match. That tradeoff becomes more visible in remote onboarding, low-bandwidth capture, and regions where device quality varies widely.

One common edge case is over-reliance on a poor reference image. If the source photo is outdated, low resolution, or captured under different conditions from the live selfie, the system may be accurate in a technical sense while still producing an unreliable onboarding decision. Another is treating a successful face match as sufficient for high-risk accounts, when the actual fraud risk may come from synthetic identity assembly, stolen documents, or account mule activity elsewhere in the flow. Best practice is evolving, but current guidance suggests mapping the biometric step to the specific risk it reduces instead of assuming it covers all onboarding threats.

Bias concerns also appear when teams validate only aggregate accuracy. What matters operationally is whether error rates remain acceptable across the actual applicant mix and whether reviewers have a consistent rule for resolving borderline cases. If an organisation cannot explain why a case was escalated, accepted, or rejected, the control is probably too opaque for regulated onboarding.

In short, face comparison is most defensible when it supports a decision rather than replacing one, especially where KYC, AML, or regulated customer onboarding demands both accuracy and explainability.

Risk and Threat Considerations

Face comparison introduces two material risk classes: fraud acceptance risk and discriminatory false-reject risk. It can also create governance risk if organisations treat a biometric score as a standalone trust signal without verifying the provenance of the reference image or the quality of the capture process.

Failure mechanism: Fraudsters can exploit weak enrolment, replay attacks, poor liveness controls, synthetic or stolen reference images, and over-permissive thresholds. Bias and operational error arise when models are tuned on non-representative data, when capture conditions vary materially, or when reviewers lack a defined escalation path for mismatches and edge cases.

Impact: Organisations may onboard impostors, miss identity manipulation, or reject legitimate applicants at scale. The downstream consequences include account abuse, regulatory exposure in KYC and AML workflows, customer churn, and loss of trust in the broader identity proofing process.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, CIS Controls v8, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.RM-01 — Risk Management Strategy	Face comparison onboarding needs risk-based decisioning and governance.
Recommendation — Set biometric use cases and escalation thresholds within a documented onboarding risk strategy.
CIS Controls v8	6.3 — Data Recovery Management	Onboarding evidence and exception records need retained, recoverable audit data.
Recommendation — Retain onboarding evidence and exception logs so disputed biometric decisions can be reviewed.
NIST SP 800-63	4.4 — Authenticator Binding	Face comparison is part of identity proofing and binding, not a standalone assertion.
Recommendation — Bind biometric verification to the enrolled identity proofing record before granting trust.
NIST AI RMF	MEASURE 1 — Map Context and Risks	Biometric onboarding requires measuring model limits and context-dependent risk.
Recommendation — Measure biometric performance across the actual onboarding context and adjust controls accordingly.

Practitioner Guidance

What to prioritise: Make the biometric step one control in an identity proofing chain, not the decision point. If the face match is the only strong signal, treat the case as higher risk and require additional verification.

What to verify: Check that the reference image is trusted, the capture is live, thresholds are documented, and reviewer instructions distinguish a biometric mismatch from a broader onboarding failure. Also verify that performance testing includes the actual devices and applicant conditions you expect in production.

Decision rule: If a case lands near the threshold or the image quality is weak, route it to human review rather than forcing automation. If the applicant is entering a regulated flow, preserve the evidence needed to explain why the case was accepted or escalated.

Practitioner takeaway: The control is only as safe as the surrounding proofing chain; if you cannot defend the source image, the threshold, and the exception path, face comparison is more likely to create risk than reduce it.