Skip to main content
A detailed guide to reading and acting on deepfake detection results — from verdict outcomes and risk scores to per-layer analysis and session status impact.

Where Results Appear

Deepfake detection results are included in the session’s analysis_data object. You can access them through three channels:
  • Retrieve Session API — call the Retrieve Session endpoint to programmatically access detection data for any completed session.
  • Webhook eventssession.status.verified, session.status.rejected, and session.status.submitted payloads include the full deepfake_detection_data object.
  • Admin Console — navigate to a session in the Admin Console to view detection results alongside all other verification data.

Response Structure

When Deepfake Detection is enabled in a workflow, the session’s analysis_data object includes a deepfake_detection_data field:

Top-Level Fields


Layer Results

The layer_results object provides granular results from each of the three analysis layers that run in parallel during detection.

Liveness Layer

The liveness layer validates that a physically present person performed the required actions. It acts as a binary gate — if any check fails, the verdict is immediately DEEPFAKE regardless of other layer results.

Vision Layer

The vision layer analyses the captured frames for visual deepfake artifacts using AI-powered inspection.

Voice Layer

The voice layer analyses the audio clip captured during the session, including verification that the applicant spoke the challenge phrase correctly.

Vision Signals

When visual anomalies are identified, the vision.signals array contains one or more signal identifiers:

Verdict Logic

The verdict engine evaluates results in priority order:
DEEPFAKE verdicts trigger regardless of confidence level — the system is calibrated to prioritize preventing deepfake fraud over avoiding false positives. In the rare case of a false positive, applicants can retry the verification session.

Impact on Session Status

The deepfake detection verdict directly influences the session’s final status:
  • DEEPFAKE → Session REJECTED — The session automatically transitions to REJECTED. This prevents deepfake-based fraud from progressing through the verification pipeline.
  • INCONCLUSIVE → Manual review — The session remains in SUBMITTED status, flagged for manual review in the Admin Console. This occurs when the system does not have sufficient confidence to make a definitive determination (e.g., low webcam quality, poor lighting). A compliance analyst can examine the layer results and make a final call.
  • LIVE → Normal processing — The session continues through normal verification processing. Other workflow steps (ID Verification, PEP & Sanctions, etc.) proceed as configured.

Example: Deepfake Detected

The following response illustrates a session where a face-swap deepfake was identified with high confidence:
In this case, the liveness checks passed (the deepfake software successfully replicated basic movements), but the vision layer detected four distinct artifact signals — texture smoothing, boundary seams, unnatural teeth, and a skin tone mismatch between the face and neck. The vision risk score of 82 exceeded the deepfake threshold, resulting in a DEEPFAKE verdict. The voice layer showed no synthetic indicators, confirming this was a face-swap attack rather than a fully synthetic session.

Example: Inconclusive Result

When the system cannot make a definitive determination, typically due to poor capture conditions:
The average layer confidence of 55 fell below the minimum threshold, so the system returned INCONCLUSIVE rather than making a potentially incorrect determination. This session would be flagged for manual review.
Deepfake detection data is included in webhook event payloads when session status changes. Configure your webhook endpoint under Settings > API Keys to receive real-time notifications. See Webhooks for setup details.