Choose the right check types

A workflow template is a list of checks. The platform supports five canonical check types: collect_user_info, id_verification, watchlist, background_us_criminal, and background_global. Each one falls into one of two categories: it either renders a screen in the verify journey for the applicant to complete, or it executes server-side once its inputs are available. The workflow engine drives both branches from the same workflow template document.

Identity information

The collect_user_info check captures the applicant’s typed details. Legal name is always captured. Email, phone, date of birth, and home address are toggleable fields configured per workflow template; email and phone are on by default. The values feed every server-side check that follows, so there is no second prompt for the same field.

Use this check first in any workflow template that also runs a watchlist or background check. Without it the downstream checks have nothing to match against.

Identity document verification

The id_verification check is an applicant-rendered step that captures a government-issued identity document with the device camera and, optionally, a biometric face check. It runs in a fixed-origin embedded capture frame inside the verify journey, then resolves its verdict asynchronously in the workflow once capture is complete.

Two parts make up the check:

• Document capture: the applicant photographs an accepted document. You choose which document types the workflow template accepts: passport, driver’s license, national ID card, residence permit, visa, or work permit (at least one must stay selected). A driver’s license, national ID card, residence permit, and work permit are two-sided, so the capture flow records a front and a back automatically; a passport and a visa are single-sided and capture the front only. The document is read for its machine-readable data and screened for tampering and authenticity.
• Biometric face check (optional): when enabled, the applicant also provides a live face capture that is matched 1:1 against the photo on the document. This is the biometricMode control described below.

The verdict combines the document result and, when biometrics are on, the face-match result. A clean document plus a confident face match approves; a weak match or a low-confidence biometric routes the verification to manual review rather than declining outright. See Why was a verification declined? for the decline and review reasons.

Document validations

On top of capturing and reading the document, the id_verification check runs a set of validations against the data it reads. Each validation is configured per workflow template, and each one is built to protect the applicant: when a validation does not pass, it routes the verification to manual review so a person can take a closer look. None of these validations decline an applicant on their own. The four validations that work from the document data are available in all regions.

Validation	What it checks	Default
ID expiration	The document is still valid and has not passed its expiry date. A document with no expiry date by design (such as a permanent card) passes.	On
Document data match	The data printed on the front of a two-sided document agrees with the machine-readable data on the back. A disagreement can indicate a tampered or mismatched document. Single-sided documents such as passports skip this validation because there is nothing to cross-check.	Off
Minimum age	The applicant meets a minimum age you set, calculated from the date of birth read off the document. Leave it unset to disable the validation.	Off (unset)
Document authenticity	Heuristics that look for signs the captured image is a photocopy or a recapture of a screen rather than an original document.	Off
Name match	The name on the document matches the legal name the applicant typed into the verification flow. Requires the Identity information step in the same workflow template, since that step is where the applicant enters their name.	Off

How to read the table:

• ID expiration is on by default, so every new workflow template validates the document is not expired unless you turn it off.
• Minimum age and Name match are opt-in. Turn them on when your verification policy needs them.
• Each validation is independent. Turning one on does not change the others, and a failure in one routes to review without affecting the rest.

When a validation routes a verification to review, the reviewer sees exactly which validation flagged it, so they can resolve the verification quickly. See Manual review for how review works and Why was a verification declined? for the review and decline reasons.

Biometric modes

The biometric face check on id_verification is configured by a single biometricMode field with three mutually exclusive values. It is strictly opt-in (the default is none, so a workflow template never silently turns on a live-person comparison), and there is no region gate: every region may select any mode.

Mode	What it adds	When to choose it
none (default)	Document capture only. No selfie, no face match, no biometric check runs.	You only need to verify the document itself, or you are not yet ready to collect biometrics.
selfie	A single guided selfie snapshot, matched 1:1 against the document photo.	You want face-to-document matching with the lightest applicant friction.
liveness	An active liveness face scan (a short guided movement challenge), then a 1:1 match against the document photo.	You need higher assurance that a real, present person (not a photo or a screen) is being matched to the document.

In the workflow template editor the control is labeled Face match, with three options: Off (document only), Selfie photo (match a single snapshot to the document), and Active liveness (guided face scan, then match to the document). Higher-assurance modes add a biometric check step, so pick the lightest mode that satisfies your verification policy.

For where biometric data is processed and how it is retained, see Data residency and Compliance settings.

Address proof

There is no standalone address-proof check type. Address is captured as an optional field inside collect_user_info and is forwarded to watchlist and background checks as part of their applicant input. If you need address proof as a separate evidence artifact, handle it outside the verification workflow template.

Background check

Two background-check types are available. Both are server-side: the applicant submits their information through the collect_user_info screen, and the workflow engine dispatches the background check automatically after the input is captured.

• background_us_criminal runs a US-jurisdiction criminal record check. Use this when your applicants are US-based and you do not need international coverage.
• background_global runs a global background check that combines criminal records with adverse-media signals. Use this when applicants are outside the US or when you need international reach.

The jurisdiction is encoded in the check type itself, so a workflow template that needs both flavors lists both check types. The legal review path for US declines is documented separately; see Background-check decisions (FCRA).

Watchlist screening

The watchlist check is also server-side. It screens the applicant’s identity against sanctions, PEP, enforcement, regulator-alert, sex-offender, and adverse-media sources. The reviewer surface renders each hit as a finding with source attribution. See Watchlist hits for the investigation flow.

The single workflow-template-level control is the minimum match confidence: raise it for stricter matching, lower it to see borderline hits during manual review.

Fraud signals

Separate from the checks above, a workflow can also screen for fraud: suspicious patterns such as one device driving many verifications, networks with a poor reputation, automated behavior, or a repeat applicant. Fraud screening is not a check type; it is a cross-cutting layer you turn on in the workflow editor’s Fraud signals section, and it can flag an applicant, send them to manual review, or adjust the fraud score, never decline on its own. See Add fraud signals to a workflow for how to configure it.

Combining checks

A typical workflow template chains collect_user_info → id_verification → watchlist → background_us_criminal (or background_global). The information step gates everything else, identity-document capture confirms the person and their document up front, the watchlist is fast and inexpensive, and the background check is the heaviest call. Run them in that order so a hard fail on a cheap step short-circuits the expensive one.

Cost considerations

Each check that runs has a per-check price in US dollars, debited from your wallet. Workflow templates that include both background_us_criminal and background_global charge for both runs even if the same applicant is screened against overlapping sources. Pick the narrowest set of checks that satisfies your verification policy.

For the full term list, see the Glossary. If a verification ends in an unexpected decline, the verification-declined FAQ walks through the most common causes.