Flows
The ordered set of checks an applicant goes through, how it looks to them, and what it accepts
A flow is the thing an applicant actually experiences: which checks they do, in what order, what the screens look like, and what you are willing to accept. Change a flow and the next verification created against it runs the new version, with no code deployed by anybody.
Most accounts have a handful. A full onboarding is one flow, an age gate is another, a liveness-only check is a third.
The list
Active flows and archived flows, with the checks each one runs, its status and when it last changed. One flow carries the default badge.
The default flow is load-bearing
It runs whenever a verification is created without naming a flow. Every integration that sends nothing gets it, so changing which flow is the default changes what those applicants go through.
From a row you can test a flow, make it the default, archive it, restore it, or copy a sandbox flow to live.
Archiving stops the flow accepting new sessions immediately and keeps every verification it has already run. You can restore it whenever you like. Deleting is permanent and only offered while no verification has ever used the flow; once one has, archive it instead.
The editor
Open a flow and it has three sections.
Checks
The ordered steps. Drag a step by its handle to move it, or focus the handle and use the arrow keys.
| Step | What it does |
|---|---|
| Document | Scan and validate an identity document |
| Liveness | On-device gesture liveness |
| Face match | Match the selfie to the portrait on the document |
| Age estimation | Estimate age from the selfie |
| AML screening | Sanctions, PEP and watchlist screening |
| Proof of address | Validate an address document |
| Phone number | Ask the applicant for their phone number |
| Email verification | Ask for their email and confirm it with a mailed code |
Each step is required or optional. A required step that fails fails the verification. An optional one that fails is recorded on the result, with its own verdict and reason codes, without failing anything on its own.
Each check can also carry its own sensitivity, which overrides the flow's. Leave that off unless you have a specific reason, and the check follows the flow.
Age rules live on the age step. You can set a minimum age, a maximum age, and bands in between, each choosing whether it rejects or sends to a person. It is decided from the date of birth printed on the document, never from the applicant's face, and you choose what happens when no date can be read. Nobody is ever refused on an estimated age.
Test flow opens a sandbox session running the saved flow, so save your changes before you use it. A test session runs what is saved, not what is on your screen.
Branding
How the flow looks to an applicant: brand name, logo, accent colour, and the support link behind the "Need help?" line, which is hidden if you leave it blank. There is a live preview beside the fields.
Anything you leave blank falls back to your organization's settings, so a flow only overrides what it needs to.
Two language settings sit here and they are not the same one. Languages limits what the applicant can choose, which is what you want when your support team can only answer in a few. Email language is the language of the outcome email, and its list is deliberately shorter, because an applicant may complete a flow in a language the email has no copy for. Leave the email default unset and a reviewer has to choose a language before they can record any decision on this flow.
Acceptance policy
What this flow accepts. Every rule here belongs to this flow alone, so a second flow can accept a completely different set, and rules you set account-wide in Settings are inherited here unless this flow drops them.
Countries are checked against where the applicant's document was issued.
Leave the allow list empty and every country is accepted. Name even one country and it becomes a closed list: everything not on it is rejected, including countries you have not thought about yet. The block list beats everything, so a blocked country cannot also be allowed or reviewed. The review list is the useful middle: the verification runs in full and every check is reported, then a person on your team decides whatever those checks concluded.
For a blocked country you also choose how it is enforced. Hiding it means it never appears in the list the applicant picks from. Running and deciding means the applicant goes through the whole flow and the country is applied to the finished result, so you keep the evidence. Blocking on the connection refuses the session before the first screen.
Nationality rules are about the person rather than the paperwork. Sanctions usually attach to a document, so somebody holding a passport from a country you serve is served normally. Obligations that attach to the person survive a second passport, and that is what these rules are for. A flow with a nationality rule asks applicants for their nationality, because a second citizenship is never printed on the passport somebody presents.
Documents decides which types this flow's document step will take. Applicants are offered only the types you enable, and a country override replaces the baseline for that country entirely. Accept at least one type, or nobody can finish the flow.
Expired documents has a default and a list of exceptions. This matters more than it sounds: in some places a document cannot be reissued at all right now, so an expired national ID is the only thing an applicant there can produce, while an expired passport from the same country is not. The narrowest match wins, country and type first, then type, then country, then the default, and where you put a rule in the list changes nothing. The console flags an exception that duplicates another and one that a narrower rule has made unreachable.
A document with no readable expiry goes to a reviewer
Your expiry rules answer what an expired document means to you. A document we could not read an
expiry from at all is a different question, and it is not covered by those rules. It carries the
reason EXPIRY_UNREADABLE and always goes to a reviewer, whatever your sensitivity is set to,
because approving it would mean accepting a document nobody has confirmed is in date. It reaches a
reviewer as a retryable outcome, so the applicant can be invited to photograph the document again.
Some documents print no expiry at all, a lifetime national ID for instance, and those reach a
reviewer the same way until we can tell the two cases apart.
Network signals are off by default. Turn them on and the flow reacts to applicants arriving through a VPN, a proxy or a datacenter address, and can send a session to review if the applicant's network changes between steps.
Read this before you switch network signals on
In some markets a VPN is how people reach the internet at all. Leave it off, or exempt those countries, or you will reject the applicants you meant to serve. Exemptions are matched on the document's country, not the address, because somebody on a VPN appears to be wherever their exit node is.
Findings is the fine-grained layer: what happens when a check reports a specific problem, either everywhere or only in the markets where it means something different. A finding is always recorded on the result, so an accepted verification still tells you what was noticed about it. Each finding carries a plain explanation of what it actually means, which is worth reading before you make one fatal. Some findings can be sent for review but never accepted outright, because they can equally be a bad scan or a forged document.
Sensitivity
One control moves the whole flow between automation and caution.
| Setting | Effect |
|---|---|
| Very lenient | Almost everything is decided automatically, and only unreadable results reach your queue |
| Lenient | Borderline results lean towards automatic approval, so your queue stays small |
| Balanced | Where every flow starts. Clear results are automatic, genuinely uncertain ones wait for a person |
| Strict | More of the uncertain middle is held back, including weaker matches and softer warnings |
| Very strict | Anything short of a clean pass waits for a person. Expect a much larger queue |
It moves the uncertain middle and nothing else. It applies to verifications our engine decides, and it never declines an applicant on its own. If your review queue is bigger or smaller than you want, this is the first control to move, and moving it a little at a time beats moving it a lot.
Promoting a flow to live
Copy to live creates a separate live copy. The sandbox flow stays exactly as it is, later edits to it do not follow the copy, and the copy does not become your default until you make it one.