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 and 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).

Missing input: Skipped or Rejected

An enabled Trust Factor can only be evaluated when its input exists — a face factor needs a selfie, a document factor a document, a chip factor a chip reading, age_verification a readable date of birth. When the input is missing, the factor's Mandatory switch decides what happens:

Mandatory	State of the factor	Effect on the decision
Off	Skipped, reason missing input	None — the verdict is derived from the other factors.
On	Rejected, reason missing input, no value	Counts as a reject, exactly like a threshold reject.

• Mandatory is on by default for age_estimation and age_verification, and off for every other factor. Turn it on for any factor that must never be passed over silently.
• Mandatory has no effect on a factor that was evaluated (its thresholds decide) or on a disabled factor (it is not evaluated at all).
• If every enabled factor is Skipped, there is no evidence to accept on, and the result is review.
• In the Digital Identity detail, a factor rejected for missing input shows Missing input in place of a value, so it is distinguishable from a threshold rejection. The workflow result webhook reports each factor's state, its mandatory setting and the reason missing_input where it applies.

The switch is set per factor in each Trust Factor configuration — see Administration → IDV Configuration.

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; Mandatory
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, or with no portrait photo detected on it, has no age to judge — see Missing input.	Reject below 18; Mandatory
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 and age_verification are Mandatory by default, so a missing age — no estimate from the selfie, or no readable date of birth on the document — rejects the factor with the reason missing input, distinguishable from an age below the limit. Turn Mandatory off only if the factor may be passed over when the age cannot be determined; the factor is then Skipped and the verdict comes from the other factors. A document whose date of birth cannot be read can be let through capture with the Accept missing date of birth setting; with the default Mandatory age_verification it is then still rejected at the trust evaluation.

Because these two factors gate below a limit, they accept only the reject low and review low thresholds, and at least one of them must be set.

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