Trust Factors & Decisioning
A verification produces many individual signals — a face-match score, a liveness score, document checks, an age estimate. Trust Factors turn those signals into a single, explainable decision: accept, review, or reject. They are how a Company encodes its risk appetite without writing code.
The decision model
Each Trust Factor evaluates one signal and returns a verdict. The overall outcome is the most severe verdict across all active factors:
- If any factor says reject → the verification is rejected.
- Otherwise, if any factor says review → it goes to review.
- Otherwise → accepted.
This makes decisions predictable and auditable: every outcome traces back to the specific factors that drove it, visible in the Digital Identity detail.
Types of Trust Factors
| Type | How it decides |
|---|---|
| Score | Compares a 0–1 score against two thresholds — one below which it rejects, one below which it sends to review. |
| Boolean | A pass/fail check (e.g. "document not expired"). Failure rejects or sends to review. |
| Integer | Compares a calculated integer number against thresholds. |
The score and integer Trust Factors have four input thresholds:
- Reject low - A score below this threshold causes the TF to return Reject
- Review low - A score below this threshold causes the TF to return Review
- Review high - A score above this threshold causes the TF to return Review
- Reject high - A score above this threshold causes the TF to return Reject
There is an input validation ensuring that Reject low < Review low < Review high < Reject high. If some of the values are not entered, the TF will not return such result
The boolean Trust factors can be configured to one of these 4 conditions:
- Reject if True
- Review if True
- Review if False
- Reject if False
If the Trust Factor is not enabled, the underlying computed value does not affect the identity verification result (TF is ignored).
Trust Factor groups
In the configuration editor the factors are grouped by the signal they judge:
| Group | Examples |
|---|---|
| Face Trust Factors | Face comparison score, passive and active liveness, deepfake, age estimation, gender consistency. |
| Document Trust Factors | Authenticity checks, expiry, MRZ consistency, age verification from the date of birth. |
| Palm Trust Factors | Palm liveness and palm matching score — shown only for tenants with palm verification enabled. |
Age-related Trust Factors
Three factors deal with age, and they answer three different questions:
| Trust Factor | Group | Type | What it judges | Default |
|---|---|---|---|---|
age_estimation | Face | Integer | The age estimated from the selfie by the biometric engine (in whole years). Passes when the estimate is at or above the threshold. | Reject below 25 |
age_verification | Document | Integer | The age computed from the date of birth on the document (in whole years). Passes when the age is at or above the threshold. A document with no readable date of birth scores 0 and is therefore rejected — the check fails closed. | Reject below 18 |
age_validation | Face | Integer | The discrepancy between the estimated age and the document age. Flags a selfie that does not plausibly belong to the document holder. | Review above 15, reject above 20 |
Only the reject low thresholds are set by default; the estimation factor deliberately has no review band, so an estimate of 24 with a threshold of 25 is rejected rather than reviewed. In the predefined age verification workflow this is intended: a rejected estimate is followed by a document capture that settles the age from the date of birth. Choose a different configuration if the estimation is your only check.
Age estimation is a probabilistic measure with an error of a few years; the safety margin above the legal limit (25 for an 18+ service in the defaults) accounts for it. Whether estimation alone is acceptable, and which margin, is a legal question for the jurisdiction of the Company — the platform makes both configurable.
Default thresholds
Trust Factors ship with sensible defaults that a Company can tune. These values are defaults, not fixed rules — see Administration → IDV Configuration to review and adjust them.
Per-workflow profiles
A Company can define multiple Trust Factor profiles and assign a different one to each workflow, based on the possible risk of such operation. The workflow references its profile; changing the profile changes the decision behavior without touching the flow. A workflow can even evaluate different profiles at different steps — the age verification workflow, for example, judges the estimation after the selfie and the document age after the document capture.
See also
- Face verification, Document verification and Palm verification — the underlying signals
- Duplicity check — the uniqueness signal
- Workflows — where profiles are referenced