Skip to main content

IDV Configuration

IDV Configuration controls how verifications are judged. It has four tabs — Trust factors, Document OCR quality, Face duplicity check and Document deduplication — and, like all settings, is kept per environment. Editing requires the configuration permission (Administrator); other roles see the values read-only. Above the tabs, Administrators can export and import the whole configuration as one file.

Trust Factors​

A Trust Factor configuration is a named set of checks and thresholds that produce the accept / review / reject decision. A workflow references a configuration by name from its trust-evaluation step (see Workflow Settings), so a Company can keep several — for example a strict one for onboarding and a lighter one for age verification.

The configuration library​

The Trust Factors tab lists every configuration:

  • Platform-seeded configurations carry a Default badge and cannot be deleted. They are default_trust_evaluation_configuration (onboarding), default_auth_trust_configuration (authentication), default_age_estimation_trust_configuration and default_age_verification_trust_configuration (the two steps of age verification), and idv_nfc_trust_factors (onboarding with chip reading).
  • Clone copies the selected configuration to a new editable one (<name>_copy).
  • Edit opens it in the editor; Delete removes a custom, non-default configuration.

The editor​

Rename the configuration inline and Save (enabled only when there are changes, no validation errors, and you have modify permission; Cancel prompts before discarding unsaved changes). The factors are grouped into Face Trust Factors, Document Trust Factors and — for tenants with palm verification enabled — Palm Trust Factors. Each factor is edited in a table:

  • Score / numeric factors — set the reject and review thresholds (the bands below which a result is rejected outright or sent to manual review).
  • Boolean factors — set the expected pass/fail value.
  • Enabled — turns the factor on or off for this configuration.
  • Mandatory — decides what happens when the factor's input is missing: Rejected when on, Skipped when off. On by default for age_estimation and age_verification, off for the rest. See Missing input: Skipped or Rejected.
  • Invalid values are flagged and block saving.

For the meaning of individual factors and their defaults, see Trust Factors & Decisioning.

Document OCR Quality​

Controls the quality checks applied to a captured document before its extracted data is trusted. A document that fails a check is sent back for a retake, up to the tenant's retake limit. Edit it as a guided Form or as raw JSON (toggle at the top), then Save.

The form is organized into sections:

SectionSettings
OCR confidenceThe minimum acceptable OCR confidence (0–1).
Date validationAccepted ranges for date of birth (min/max age), date of issue (min/max age), and date of expiry (min/max duration), plus three toggles — see below.
MRZ & portraitToggles for MRZ text-consistency, MRZ checksum, and portrait-not-covered validation.
Fixed-length field validationRules requiring a specific character length for a field on a given document type and country; add and remove rows as needed.

The three Date validation toggles let documents through that lack a date. All are off by default:

ToggleJSON keyWhen on
Accept missing date of birthdobAcceptMissingDateOfBirthA document without a valid date of birth in any source (visual zone, MRZ, chip, barcode) is not sent back for a retake, and the date-of-birth age range check is skipped. For documents that carry only a personal number.
Accept missing issue datedoiAcceptMissingIssueDateA document without a valid date of issue passes, and the issue-date range check is skipped.
Accept missing expiry datedoeAcceptNoExpirationA document without a valid expiry date passes, and the expiry range check is skipped.

"Missing" means that no valid date was read — the field is absent or unreadable. A date that is read is still checked against its range, and all other checks still run. The toggles change capture only: a Trust Factor that needs the date, such as age_verification, still treats it as missing input.

The JSON view edits the same configuration as raw JSON and is validated on save (invalid JSON or values are rejected with the offending field reported). A key left out of the JSON keeps its default.

Face Duplicity Check​

The thresholds that govern the face duplicity check (the 1:N match and review thresholds).

Document Deduplication​

The comparison rules of the document duplicity check: which document fields are compared, the weight of each field, and the match and similar thresholds. Edit it as a guided Form or as raw JSON; both views edit the same configuration and are validated on save.

The same tab holds the Operator name search settings, which tune the name search on the Customers and Digital Identities lists of the back office:

SettingDefaultRangeMeaning
Top-K candidates501–200The most records a name search returns.
Jaro-Winkler cutoff800–100How similar a name must be to be listed; a higher value lists fewer, closer matches.
Cooldown after a search3 s0–300 sThe pause an operator waits before the next search.

Export and import​

Administrators see two buttons above the tabs — Export all configuration and Import configuration. They act on the whole IDV configuration, not on the open tab:

  • every Trust Factor configuration, with all factors, thresholds and the Enabled and Mandatory switches,
  • the Document OCR quality, Face duplicity check and Document deduplication settings,
  • every workflow of the tenant (Workflow Settings).

The file is a single JSON document. Its header records the schema version, the tenant, the environment it was exported from, the export time and the platform version, and it carries the Trust Factor catalog with every factor's defaults as a reference for editing. It contains no credentials — no webhook secrets, connection settings or API keys. A tool or AI assistant that understands the Workflow Manifest Reference can review or edit it and you can import the result.

Export downloads the file immediately.

Import asks for a file (JSON, at most 10 MB) and checks it completely before anything changes:

  • Every item is validated — the schema version, each workflow through the same checks as the workflow editor, each Trust Factor configuration, and each workflow's references to Trust Factor configurations, which must be in the same file. All problems are listed at once, and nothing is applied.
  • A valid file opens a preview of the differences — added, changed and removed items per category. A file exported from another tenant or another environment is flagged; in production a warning states that the change applies to live verifications immediately.
  • Apply import replaces the configuration with the file's content in one step. Items missing from the file are removed, except that the platform-seeded Trust Factor configurations and the tenant's default workflow cannot be removed. Within an existing configuration, a factor cannot be removed — set "enabled": false instead. Cancel changes nothing.
  • The import is all-or-nothing. If the configuration was changed after the preview, nothing is applied and you are asked to check the file again.
  • Before applying, the current configuration is saved as a snapshot so it can be restored. Every applied import is written to the audit log with who imported it, when, the environment, the file's hash and a summary of the changes.

See also​