Multiple evidence layers
A valid identity reference, a matching face and an authentic capture path answer different questions. The engine brings those signals into one verification decision.
FaceX’s risk engine brings deepfake detection, camera authenticity, anti-spoofing and identity evidence together. It supports approval, review or rejection based on the combined picture, rather than a single reassuring score.

Media, camera, presence and identity.
Integrity flags remain decision evidence.
Approve, review or reject.
A valid identity reference, a matching face and an authentic capture path answer different questions. The engine brings those signals into one verification decision.
An injected feed, synthetic media or replay evidence can remain a blocking concern despite a strong face match. The illustrative policy makes that relationship explicit.
Insufficient evidence should remain visible as uncertainty. The engine can route a case for review or another capture instead of treating incomplete checks as success.
The decision layer combines the required evidence and the configured policy. The examples use simple qualitative outcomes; they do not expose production thresholds or weights.
Choose a scenario to see how different signals can affect an example decision.
Illustrative scenarios only. These qualitative signals and policies do not expose production scores or thresholds. No camera access, biometric capture or live check occurs on this page.
The security checks answer different questions. Complete identity verification needs their combined evidence.
An inconclusive check is not the same as a passed check. Review and recapture paths can preserve that distinction in the applicant journey.
FaceX’s reported 99% deepfake figure does not establish a separate camera-integrity, anti-spoofing or full-system success rate. Read the performance context.
In the illustrative policy, no. A face can resemble the identity reference while the media, capture source or presentation remains untrusted.
Review represents unresolved or insufficient evidence. Rejection represents a failed requirement or blocking risk under the decision policy. Production routing depends on the published integration and configured policy.
No. The developer reference presents proposed contracts and illustrative evidence summaries. Confirm actual fields, decision semantics and thresholds against the live integration contract.