User Verification Overview

Verification confirms something about a person that they cannot simply assert: who they are, how old they are, or what organisation they belong to.

Where to find it

Architect Panel → Security:

User Verification — the console — providers, types, checks and their history

Architect Panel → Security:

Permissions — the group a successful verification can award

What it is for

An account tells you somebody registered. It does not tell you they are over 18, that they are a nurse, or that they are the person named on the account. Where a service depends on any of those, verification is how you find out — without asking staff to inspect documents by hand.

How a check flows

A check is requested for a person and a verification type.
They are sent to the provider — or, for a domain check, asked to confirm an e-mail address.
The provider returns an outcome.
The result is recorded with an expiry, and any group award is applied.

Every transition is recorded

Each check accumulates events recording the status it moved from and to, what caused the change, when, and from which address. So the history of a verification is not just its final state — it is the whole sequence.

That matters when somebody disputes an outcome, and it matters more when a regulator asks how you satisfied yourself about a user.

What is stored, and what is not

This is the point people most need reassuring about, and the design is deliberate: the platform records the outcome, a short evidence summary, the provider's reference, and any failure reason.

It does not store the passport, the driving licence or the photograph. Those are handled by the provider, who is set up to hold them. What you keep is the conclusion and a pointer — which is what you need, and far less than you would otherwise be responsible for.

Checks can start from anywhere

A check records where it came from — a stage in a User Input View, a support request, a journey node. So verification can be a step in a form somebody is filling in, or an automated part of a process, not only something an administrator initiates.

Nothing is enabled out of the box

Five providers and seven verification types ship, all disabled and without credentials. Nothing contacts an external service, and no verification is demanded of anybody, until you deliberately turn it on.

Verification is not authentication

Worth separating. Authentication proves somebody is the account holder each time they sign in. Verification establishes a fact about them, once, that then persists until it expires.

Verifying someone does not make their account more secure — that is what two-factor authentication and passkeys are for.

Worked example

A retailer offers a student discount. Registration is ordinary; when a customer selects the discount they are asked to verify their student status. The check runs, succeeds, awards the student group, and expires in a year. Nobody in the business ever sees a student card, and the discount cannot be claimed by asserting it.

Recommendations

Verify only what you actually need to know.
Let the provider hold the documents — that is the design.
Do not treat verification as a security control for the account.
Enable one type first and prove the flow before adding more.