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?](/guides/faq/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](/guides/verification/reviewer-manual-review) for how review works and [Why was a verification declined?](/guides/faq/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](/guides/faq/data-residency) and [Compliance settings](/guides/organizations/compliance).

## 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)](/guides/verification/reviewer-background-checks-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](/guides/verification/reviewer-watchlist) 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](/guides/workflows/workflow-templates-fraud-rules) 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](/glossary). If a verification ends in an unexpected decline, the [verification-declined FAQ](/guides/faq/verification-declined) walks through the most common causes.