Choose the right check types

A workflow template is a list of checks. The platform supports eight canonical check types: collect_user_info, id_verification, watchlist, background_us_criminal, background_global, custom_form, esign, and credit_history. 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. The name is always captured, as three separate answers: the family name exactly as printed on the ID, an ordered list of given names, each entry stored exactly as it was typed, and a suffix such as Jr. or III. Nothing is split or joined, so a double surname, a name with a particle, a family-name-first name, a person with one name, and a generational suffix are all recorded as given. The suffix is stored on its own and shown last, after the family name. 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 and, optionally, a biometric face check. The document is captured with the device camera by default; a workflow template can also let the applicant supply an existing photo of it, described under Document upload below. 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, or supplies an existing photo of it when the workflow template allows that. 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 every name on file for the applicant. One of those is the identity name: it comes from the Identity information step, or from the given_names and family_name you send when you create the session, and if the applicant completes that step, what they enter there is what gets compared. A second is the booking name, compared as well whenever you send booking_name at session create or on the applicant. Each name is compared separately, and a mismatch on any one of them sends the verification to review for a person to look at. It never declines on its own.	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.

If you supply the identity name yourself and need that value to be the one compared, make sure the applicant is never asked for a name during the journey. Send given_names and family_name along with every field your template marks required on the Identity information step, and that step is skipped automatically. The create response tells you when a field is still outstanding, through collect_user_info_not_presatisfied.

booking_name is a separate field and behaves differently. It is the name the reservation, booking, or payment holds, exactly as you received it, and it is never treated as the applicant’s own claim about who they are: it is not used as the display name, it never reaches a background check, and an applicant completing the Identity information step does not replace it. Send it on the applicant object at session create or on the applicant, and Name match compares it alongside the identity name. It is write-only, so it is not echoed back on a read. A booking name that differs from the document is routinely benign, because the name on a booking is often a travel agent’s or a colleague’s rather than the person checking in, which is why the mismatch sends the verification to review rather than declining it.

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.

Document upload

By default the applicant must photograph the document with the device camera. A workflow template can additionally offer Allow photo upload, which puts an upload option next to the camera on the screen that starts capture. It is off by default, so no existing workflow template changes behavior, and you turn it on per workflow template in the identity-verification step of the editor.

What it is for. Some applicants cannot photograph the document on the device in front of them: the camera is broken, the browser or the operating system refuses access, or the only usable photo of the document is already in their photo library. Turning this on lets those applicants supply the document rather than stall on the capture screen.

What it does not do. It lets the applicant supply the document. It does not remove the camera from the rest of the check. If the same workflow template also runs a biometric face check (selfie or liveness), the applicant still has to complete that face capture with a working camera, and an applicant with no camera at all will not get past it. Enable photo upload if your applicants struggle to photograph documents; do not enable it expecting a camera-less device to finish a verification that also asks for a face.

The tradeoff, stated plainly. An uploaded photo is checked exactly like a photographed one. It runs the same document validations, the same authenticity heuristics, and the same verdict, and it can pass automatically without a person looking at it. It is not held to a higher standard, and enabling this option does weaken the assurance the check carries: a photo picked from a library is easier to obtain, alter, or re-photograph from a screen than one taken live. What you get back is visibility, not a second gate. Every verification records how its document arrived, and every reviewer surface says so: the applicant detail page, the exported report, and the reviewer panel each show a Document source of either Camera capture or Uploaded photo. Turn it on when the applicants you are failing to serve outweigh that, and use the document source when you review.

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.

Custom form

The custom_form check asks the applicant questions you write. Each check is one screen, and a screen holds a set of questions: short and long text, number, email address, phone number, date, single choice, multiple choice, yes/no, file upload, plus heading and paragraph blocks that display instructions and collect nothing. You pick each question’s type and its validation from that fixed list, so a question always validates in a way the platform understands.

It is the one check type a workflow template can list more than once. Use a separate custom_form check per group of questions you want to keep together, and place each one where it belongs in the check order.

Each screen can carry rules. A rule matches an answer on that screen and then sends the verification to manual review, notifies a team member, or both. Pick at least one team member on a notify rule: a rule that names nobody saves and matches as usual but sends no message, and the editor warns you while you author it. A rule can target any question that collects an answer you author, so a file upload and the two display-only blocks are not offered as rule targets. When a rule sends the verification to review, the form’s card under Needs your review on the applicant detail page names the questions whose answers triggered it and lists the applicant’s answers below it, under Submitted answers. A form that passed keeps its answers in its row under Other checks. Questions the applicant left blank are not listed in either place. A custom form never approves or declines on its own.

Which conditions a rule can use depends on the question it targets. The Condition list offers only the comparisons that question type supports, so anything you can pick is something the platform can evaluate. If you retarget a rule at a different question and the condition you had chosen is not one the new question offers, the editor moves it to one that is, so check the condition after you change the target.

Question type	Conditions it offers
Short text, long text	equals, does not equal, is one of, contains, does not contain
Email address, phone number	equals, does not equal, is one of, contains, does not contain, ends with
Number, date	equals, does not equal, is one of, is greater than, is at least, is less than, is at most
Single choice, multiple choice, yes/no	equals, does not equal, is one of
File upload, heading, paragraph	None. These are not rule targets.

The ordered comparisons read the way you would expect on both question types that offer them: on a number they compare the value, and on a date is greater than means later than the date you set. ends with is offered on email address and phone number because a suffix is a real thing to match there, such as a company email domain or the last digits of a phone number.

Conditions ignore capital letters and accents, and every condition treats an answer the same way, so two rules on one question cannot disagree about it. A rule looking for cafe matches an answer of CAFE, Cafe, and CAFÉ. The limit is a letter that is not a plain letter with a mark added: ø, ł, đ, and ß count as different letters from o, l, d, and ss, so write a rule for each spelling you want to match. Spaces count too. A stray space at either end of your value keeps a condition from ever matching, and makes a does not condition match every applicant instead. The editor repeats this under the Condition list wherever you type the value as plain text: on short text, long text, and email address questions, and on a phone number question under contains, does not contain, and ends with.

A question the applicant skipped matches none of these conditions, with one exception: does not equal matches a skipped question. On an optional question that means a does not equal rule fires for every applicant who left it alone. On a text question, does not contain avoids that, because a question with no answer at all does not match it. One caveat if you submit answers through your own integration rather than the hosted journey or the Web SDK: an answer sent as empty text counts as answered, and does not contain does match that. On any question, turning on Required removes the blank case altogether.

Your plan sets how many custom screens a workflow template may hold. At the cap the editor disables Add a screen and tells you to upgrade or remove a screen first.

Document signing

The esign check has the applicant read a document you wrote and sign it by typing their name. The check is labeled Document signing in the workflow editor. The signed copy is sealed as a PDF with a certificate of completion, and everyone named on it receives a copy.

It is applicant-rendered and resolves at submit. There are two outcomes and both are normal: the applicant signs, or the applicant declines and gives a short reason.

You author the document separately, under Documents in the console sidebar, and then point the step at a published version. A step with no document chosen cannot be saved, and the check needs the Identity information step earlier in the same workflow template, because the document’s fields are filled from the details collected there. See Documents applicants sign for the authoring side.

Per-step settings:

Setting	What it does	Default
Document	Which published document version the applicant signs. One per step.	None chosen
Require read-through	Holds the Finish button off until the applicant reaches the end of the document. Enforced on our side, not only in the browser.	Off
Minimum age	Runs an age check before signing. It uses a date of birth already on file where there is one, and falls back to a confirmation from the applicant where there is not.	Off (unset)
Email a copy to the applicant	Sends the sealed PDF and its certificate to the applicant.	On
Email a copy to your team	Sends the same copy to your organization.	On

One signing step signs one document. The workflow editor offers a single Document signing step per workflow template, so a workflow that needs two agreements signed puts the second one in its own workflow template.

For what these signatures are and are not in legal terms, including the claims we do not make and the signer’s rights, see Electronic signatures.

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, missing-persons, and adverse-media sources. The reviewer surface renders each match as a finding with source attribution. See Watchlist matches 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 matches during manual review.

Credit history

The credit_history check asks the applicant to authorize a credit report, then collects the details the report is ordered against. It is labeled Credit history check in the workflow editor.

A credit report the bureau itself returns marked for review always holds the check for a person, whatever you set below. That is the bureau saying a human should look at the file, and the reviewer is shown it as the reason.

It produces a consumer report under the Fair Credit Reporting Act. Declining a verification that includes it puts adverse-action obligations on you, and the reviewer surface shows you the reminders at the moment you decide. Read Background-check decisions (FCRA) before you add this check to a workflow template.

The applicant works through four screens, in this order:

1. Authorization. The applicant reads the disclosure and authorizes the report. Declining is a recorded outcome, not an error.
2. Address history. The applicant accounts for the months of address history you asked for. Their current address is what decides which country the report is ordered in, which is why this screen comes before the identity screen rather than after it.
3. Identity and title. Names the applicant has used before, if you ask for them, and a national identifier, if you ask for one. The identifier is labeled for the applicant’s own country, which is the second reason the address screen runs first.
4. Review. The applicant checks what they entered and submits.

The result does not arrive at submit. The applicant carries on with the rest of the journey and the outcome lands when the report comes back, the same way id_verification resolves.

Where the check can run

Two independent conditions have to hold, and neither one implies the other.

• Your organization’s region. The check runs on US-region organizations. On an EU-region organization the Credit history check row is not shown in the workflow editor at all, rather than shown as a switch that cannot be turned on. See Where is my data hosted? for why the two regions differ.
• The applicant’s country. A report can be ordered for applicants in the United States and Canada. An applicant living anywhere else reaches the address screen, the flow recognizes the country there, and the step ends without ordering a report and without charging you. What the verification does next is the If the applicant lives outside the countries we can check setting below.

Before you add it

The check needs the Identity information step earlier in the same workflow template, and that step must have date of birth turned on: a report cannot be ordered without one. The editor refuses to save a workflow template that breaks either requirement and names the control to fix.

The applicant’s given names and family name are ordered as separate values rather than as one typed line, because guessing which words are the surname pulls a credit file on a different person. collect_user_info always captures them separately, so a workflow template that starts from the Identity information step already satisfies this.

Per-step settings

Setting	What it does	Default
Permissible purpose	The legal basis you are certifying the report is pulled under: Tenant screening or Employment screening. There is no default and the workflow template cannot be saved until you choose one, because a report pulled under a basis nobody chose is the failure the authorization screen exists to prevent. The applicant is never asked for it.	None chosen
Months of address history to collect	How far back the applicant accounts for their addresses, from 1 to 120 months.	6
National identifier	Ask, but let the applicant skip it, or Require it before the applicant can continue. Requiring it stops an applicant who will not provide one. Leaving it out can slow the report down or return no match.	Ask, but let the applicant skip it
Ask for names the applicant has used before	Adds a previous-names section to the identity screen. Each previous name searched is priced separately, so this is an explicit choice rather than something that is on by default.	Off
Most previous names one applicant may add	Your ceiling on how many, from 0 to 10. Without a ceiling the charge would be the applicant’s to decide, not yours.	3
If the applicant lives outside the countries we can check	Send the session for review holds the verification for a person to decide, because a file that was never requested is an open question rather than a clean result. Continue without the check records the check as passed with the reason shown to the reviewer, so the verification can complete on its other steps. Neither one orders a report and neither one is charged.	Send the session for review
If no credit file is returned	Send the check for review holds a report that came back with no file at all. Off by default, because no file is a normal result for someone with little borrowing history and stalling every one of them is the wrong default for a tenant screen. Turn it on where the absence is itself the answer you need. The reviewer is told this is why the check was held.	Off
Minimum credit score	A score below this holds the check for review. There is no default, and leaving it empty means the score is not used as a threshold at all: score scales differ by model and by country, so any number the platform picked would be wrong for someone. A report that came back with no score is never held by this setting, because there is no score to be below anything. The reviewer is told this is why the check was held, and sees the score next to the number you set.	None set
Notice text	An optional notice of your own, shown next to the platform’s authorization copy. You can write one per language, in up to five languages, at up to 2,000 characters each.	None

Two limits to plan around

A completed credit step cannot be re-run. Re-verify on the applicant detail page refuses a credit history step and names the one action that works: start a new verification to run the check again. The other checks on the original verification keep their results.

A credit history check has to be authored in a workflow template. It cannot be added to a one-off list of checks on the API call that starts a verification, because a permissible purpose has nowhere to come from in that shape. Author the check in a workflow template and point the verification at the workflow template instead; see Create a verification workflow template.

Fraud signals

Separate from the checks above, a workflow can also screen for fraud: unusual 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 stop on a cheap step short-circuits the expensive one.

Add a custom_form check wherever its questions belong in that order. Place one early when its answers give the reviewer context for everything that follows, and later when the questions only make sense after the applicant has been identified.

Place an esign check after the identity checks you want completed before the applicant is asked to sign. It always runs after Identity information, and putting it after id_verification is what lets the document quote the details read off the applicant’s document.

Place a credit_history check after Identity information as well. It reads the applicant’s name and date of birth from that step, and it collects its own address history on its own screens, so it does not need id_verification ahead of it. Its result arrives after the applicant has finished, so its position in the order changes when the applicant is asked, not when you learn the answer.

Cost considerations

Each paid 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.

collect_user_info and custom_form are not priced per run. Custom screens are part of your plan, which is also what caps how many of them a workflow template may hold.

credit_history is priced per report: $20.00 for a United States report, and $20.00 for a Canadian report. Previous names are priced separately: a further $20.00, charged once per previous name searched, on top of the report. That is why Most previous names one applicant may add exists: it is your ceiling on a charge the applicant would otherwise set. Read the report price as a floor rather than the cost of the check: at the highest ceiling the editor allows, a single check bills the report plus a separate search for every name. The check also runs only where Where the check can run says it does, so it is not a price every organization can reach. No plan includes a consumer report at no per-check charge. Nothing is charged when no report is ordered, which is the case when the applicant declines the authorization and when the applicant’s country is outside the countries the check covers.

esign is priced per run on Basic and Pro and is included at no per-check charge on Max. It is available on every plan; the plan changes the price, not the access. The charge lands when the applicant submits the step, whether they signed or declined, because by that point the platform has prepared the document, filled it in, and recorded the whole signing session as evidence. An applicant who opens the document and never submits is not charged.

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.