Which sessions should a person look at?

That is your policy. Common choices are sessions flagged as suspicious, failures you do not want to refuse by rule, and results that passed with an unverified liveness step.

Can a reviewer see the images of a session?

Only if the role allows it. Seeing a session and seeing its document and selfie images are separate permissions. Without the image permissions the data is shown and the images are hidden.

Does the decision of a reviewer reach my system by webhook?

Do not assume it. Read the session status again after the reviewer acts, with the session status call or the filter.

Can the same decision be made from my own tooling?

Yes. The status change method records a manual decision, and the filter method finds sessions by status, date and other criteria.

Manual review workflow

The job

A verification flow applies the rules of your scenario without a person: the document passes, the face matches, the liveness step is confirmed. Some sessions will not be that clean. A document is half hidden by a thumb, a result carries a flag, a match on a list needs a human reading. Without a lane for these sessions they pile up, or they are refused by default, which is a cost of its own. This page describes the lane: what puts a session in front of a person, what the person sees, how the decision is recorded, and who is allowed to make it.

What puts a session in the queue

Two things decide it: the rules in the scenario, and the rules in your own system.

The scenario holds rules that the platform applies while the session runs. Examples from the scenario settings are the allowed age range taken from the date of birth in the document, a faces black list whose match blocks the session, the number of critical errors before a session is blocked, and flags for the document steps such as blocking a session when two different documents are detected in one step. For AML screening you set a match threshold from 0 to 100. These are the thresholds and rules of the scenario editor.

Your own system adds rules on top of the results it reads. Typical routes to a person:

What your server reads	Why a person looks
`suspicious`	The platform flagged the result as suspicious.
`failed` on a step you do not want to refuse by rule	The error code says why. Branch on the code, never on message text. See errors.
`success`, with the liveness step unverified	The attempt passed without the verifying services, and your policy for this product asks for a second look.
A database check whose `outcome` is `skipped` or `unavailable`	The check did not give a result. A skipped check is not a clean one. See retrieving the AML result.
A match on a list or a repeat user	A match is a signal, and a person decides what it means.

How the queue is built

The dashboard gives you two views. The logs tab shows new sessions as they arrive, without reloading the page, and the status is on the card of each session: waiting, success, failed, expired, suspicious or processing. The reports tab holds the history and is meant for search, analysis and export. It filters by dates, by recognized values such as the document number or the client key, by status, and by errors, which is the rejection reason. A reviewer who works the flagged cases filters by the status. See KYC and AML in the dashboard.

From your own tooling, the filter method finds sessions by creation date, status, client key, scenario, errors and other criteria. See filter sessions. A webhook tells your system when a session is complete, so that a ticket can be opened in your own queue. The events are described on the webhooks page, and the callback can encrypt its body or omit names, document data and images and keep the session identifier.

What the reviewer sees

The card of a session has a tab for each step of the scenario.

Tab	What it shows
Document	The recognized type, the fields, and the results of the authenticity checks.
Selfie	The image of the customer, with the document in hand if required.
Faces	Whether the face on the selfie matches the document photo.
Liveness	The result of the liveness check.
Address proof	A utility bill or a bank statement, if the scenario has the step.
Databases	The database checks, such as AML screening.
Questionnaire	The questionnaire data, if one is linked to the session.
JSON	The full session result.

Clicking the date of a session copies its identifier, which the reviewer can paste into a ticket.

What the reviewer can do

Change the status by hand. The status can be changed after a confirmation. The same change is available through the status change method of the API, which accepts any value from the list on the session statuses page.
Add a face to the blacklist. On the selfie tab, the blacklist icon on the image makes the face block later sessions, once the scenario has a faces black list selected.
Run a database check again. The re-run button on the databases tab runs the check once more, and a re-run is billed as a separate request.
Export. A filtered set of sessions can be downloaded as a report in CSV or XLS format. The archive can be downloaded once, and then it is deleted from the server.

Who may do it

Roles decide what a person can see and do, and the owner of the account sets them. The permissions that matter here are viewing the session history, viewing document images and selfie images, viewing extracted data and the results of automatic document checks, and changing the status of a session by hand. Image permissions are a separate group. Without them a user sees the session data and the images are hidden.

A sensible split uses two roles. A reviewer can see the images and change statuses. An auditor can see the history and the results but not change a status. Keep the permission to delete sessions for the few people who need it. The dashboard also keeps a sign-in log with the date and time, the user, the address, and the browser and device. See access rights.

Recording the decision

The platform records the new status. Your own system should record what it needs to explain the decision later: who decided, when, and on what grounds. Keep that in your case tool, next to the identifier of the session, and keep the status the platform gave in a separate field from the decision. After the reviewer acts, your system reads the status again. This page does not assume that a manual change sends a webhook.

Scenario setup

Choose the rules that should stop a session in the scenario editor, select the faces black list, and decide whether session video is switched on for the liveness step. Create the reviewer and auditor roles before the first live session.

What your system receives

A session status and a list of results for each step. The dashboard adds the session log, the manual decision, and the roles. See dashboard.

See the session log on sample data in the interactive tour, or talk to us about the review lane for your flow.