Skip to main content
The Liveness Verification module determines whether a real, physically present person was in front of the camera at the point the selfie photograph was taken. It detects presentation attacks such as:
  • Attempts to spoof the verification process using a printed photograph
  • A screen replay
  • A video recording
  • A 3D mask
  • A digitally injected (deepfake) image.
The module returns a confidence score indicating the likelihood that the captured selfie represents a genuine, live person. This page contains documentation for the Liveness Verification module, including its variants, capabilities, and the scoring thresholds it uses. The module has two variants. Both analyse a selfie image to confirm genuine presence, but they differ in result type and detection scope.
VariantResult typeDetection scopeReview tier
V1Numeric score (0–100)Presentation attacksAvailable
Injection Attack DetectionBinary (Live / Not Live)Presentation attacks + injection attacksAvailable

​
Liveness Verification V1

The Liveness Verification V1 variant analyses a selfie image captured during the onboarding journey and produces a score that reflects the system’s confidence in the subject’s genuine presence. It’s typically placed alongside or before the Facematch Verification module, which compares the selfie against the photograph on the subject’s identity document. Liveness verification confirms the person is real and present; facematch verification confirms they are the same person shown on the document. Liveness verification is also supported as a standalone module. It can run on its own in a journey without requiring a Facematch Verification or document module to precede it. This is useful for use cases where confirming genuine human presence is the only check needed.

​
Capabilities

The module returns a single capability: a liveness score.

​
Liveness score

This capability returns an integer score from 0 to 100 indicating the system’s confidence that the selfie was captured from a real, physically present person at the time of the photograph.
DetailDescription
TypeInteger
Range0–100
Default0
A higher score indicates greater confidence that the selfie is genuine. A lower score indicates a higher likelihood that the image is a presentation attack or does not represent a live person. The score reflects the combined output of multiple analysis signals, which may include
  • Texture analysis: Detecting the flat, reflective surface of a printed photo or screen.
  • Depth estimation: Distinguishing a three-dimensional face from a two-dimensional image.
  • Edge and boundary detection: Identifying the borders of a held-up photograph or device screen.
  • Digital injection detection: Identifying images that weren’t captured by the device camera but inserted into the capture pipeline programmatically.
A score of 0 indicates that the liveness check could not produce a result. This may occur if the selfie image was corrupted, if no face was detected in the image, or if a system error prevented analysis. Evaluation rules should treat a score of 0 as an inconclusive result rather than a definitive failure.

​
Default outcomes

The module uses score thresholds to classify the liveness result into one of three outcomes. These thresholds are pre-configured as default outcomes and can be used in evaluation and routing logic within the journey designer.
OutcomeConditionDescription
SuccessScore ≥ 75The system has high confidence that a real, live person was present when the selfie was captured. The journey can proceed to downstream biometric checks such as facematch verification.
ReviewScore ≥ 60 and < 75The system’s confidence is moderate. The selfie may be genuine, but the analysis detected some signals that could indicate a presentation attack, or the image quality reduced the system’s ability to make a definitive determination. Common causes include poor lighting, extreme camera angles, or partial face occlusion. This outcome typically routes to manual review, where a human operator can visually inspect the selfie and the surrounding session data.
FailScore < 60The system has low confidence in genuine presence. The selfie is likely a presentation attack, a photograph of a photograph, a screen replay, a mask, or a digitally injected image. This outcome typically routes to rejection or escalation, depending on your fraud policy.
ERRORDefault (no conditions matched)The liveness check could not be completed. This fallback outcome typically indicates a system-level issue, such as a service outage or image processing failure, rather than a spoofing attempt.

​
Input payload

The following is a sample payload used to submit a selfie image to the Liveness Verification V1 variant for processing.
JSON
{
  "resourceId": "<resourceId>",
  "context": {
    "subject": {
      "biometrics": [
        {
          "selfieImage": "<base64-encoded string>"
        }
      ]
    }
  }
}
FieldRequiredDescription
selfieImageYesBase64-encoded selfie image captured from the end user.
biometricsYesAccepts at least one item.

​
Liveness Verification with Injection Attack Detection

The Liveness Verification with Injection Attack Detection variant extends the standard liveness check with an additional layer of security that detects injection attacks at the capture level. This variant requires an EncryptedSelfie input with selfieImageEncryption set to true.

​
Capabilities

The module returns two capabilities: a face liveness result and an injection attack detection result.

​
Face liveness result

This capability indicates whether the face in the selfie is determined to be live, meaning a real, physically present person was in front of the camera at the time of capture.
ValueDescription
LiveThe face is live. The system has determined that a real, physically present person was in front of the camera when the selfie was captured.
Not LiveThe face is not live. The system has determined that the selfie does not represent a genuine, live person. This might indicate a presentation attack such as a printed photograph, screen replay, video recording, or 3D mask. This is the default value.
ErrorThe face liveness check could not be completed due to a technical issue.

​
Injection attack detection result

This capability indicates whether an injection attack was detected during the selfie capture process. An injection attack occurs when an image is programmatically inserted into the capture pipeline rather than being captured through the device’s camera in real time.
ValueDescription
LiveNo injection attack detected. The selfie image was captured through a legitimate device camera. This is the default value.
Not LiveThe face is not live. The system has determined that the selfie does not represent a genuine, live person. This might indicate a presentation attack such as a printed photograph, screen replay, video recording, or 3D mask. This is the default value.
ErrorThe injection attack detection check could not be completed due to a technical issue.

​
Default outcomes

The module combines the face liveness result and the injection attack detection result to produce an overall outcome. These default outcomes can be used in evaluation and routing logic within the journey designer.
OutcomeConditionDescription
SuccessFace liveness result is Live and injection attack detection result is LiveThe subject is confirmed as genuinely present and the selfie was captured through a legitimate device camera. The journey can proceed to downstream biometric checks such as facematch verification.
ReviewFace liveness result is Live or injection attack detection result is Not LiveThe face liveness check passed but an injection attack was detected, or vice versa. The results are mixed, so this outcome typically routes to manual review for further inspection.
FailFace liveness result is Not Live and injection attack detection result is Not LiveBoth checks failed. The subject is not confirmed as genuinely present and the selfie appears to have been injected. This outcome typically routes to rejection or escalation.
ERRORDefault (no conditions matched)An unexpected error occurred during processing. This fallback outcome typically indicates a system-level issue rather than a spoofing attempt.

​
Input payload

The following is a sample payload used to submit an encrypted selfie image to the Liveness Verification with Injection Attack Detection variant for processing.
JSON
{
  "resourceId": "<resourceId>",
  "context": {
    "subject": {
      "biometrics": [
        {
          "selfieImageEncryption": true,
          "selfieImage": "<base64-encoded string>"
        }
      ]
    }
  }
}
FieldRequiredDescription
selfieImageEncryptionYesMust be set to true to indicate the selfie image has been encrypted for injection attack detection.
selfieImageYesBase64-encoded encrypted selfie image.