Manual review

Some verifications the engine will not settle on its own. Either a check came back genuinely uncertain, or one of your own rules said a person should look at this one whatever the checks concluded. Those land here.

Everything you record on this page is recorded against the applicant's session, is sent to your webhook endpoints, and in most cases is emailed to the applicant.

The queue

The list shows open cases with how long each has been waiting, the engine's verdict and score, and the reason codes behind it. Filter by review status, flow, document country, verdict, assignee and when it was queued, search by name, email, document or session id, and sort oldest or newest first. Oldest first is the right default for a team trying not to keep anyone waiting.

The country filter goes by the country that issued the document the applicant photographed, not by where they were when they did it. It is the one to reach for when your reviewers are split by the documents they can read: choose a country and the queue, its counts and its export all narrow to that country's documents. A case whose document carries no country is left out of every country.

Two tabs sit above the queue: Queue is everything open, Mine is what you are holding.

Needs review and Fraud review

The queue is split in two beside those tabs. Needs review is where the list opens, and holds the cases that need somebody's judgement. Fraud review holds the cases that look like somebody you already know, so they stop crowding out the rest.

A case is filed under Fraud review when one of these is true:

Filing is not a decision. Nothing in Fraud review was approved, rejected or scored differently for being there: you open it and decide it the way you decide any other case. Each case says what it matched at the top, and where it matched another of your verifications, links to that one so you can compare the two. Retrying under the same account never files a case here.

The split only applies to the queue itself. Mine and the escalation tab show everything, so a case you already took never disappears because of which half it sits in.

Claiming a case

If your organization has claims switched on, a case has to be taken from the queue before it can be decided. Claiming holds it for a set period and then releases it back if you never finished, so nothing is lost when somebody closes their laptop. You can hand one back deliberately with Give it back.

This is what stops two reviewers reaching opposite conclusions about the same applicant, which is why the setting exists and why leaving it off is a real decision rather than a default. Both are configured on the Team page.

If someone else already has a case open, the console says who, and you are asked to pick another rather than fight over it.

When somebody decided it first

Two people can still reach the same case at once, most easily when one of them is working through your own systems rather than through this console. Only one decision is ever recorded. If yours is the one that did not land, the console now tells you exactly that, and what the case was decided as, so you can move on instead of wondering whether your click registered.

There are two other things it can say, and they mean different things. If the case is no longer assigned to you, nothing was decided at all: your hold ran out or it was routed to a colleague, and the case is still open for somebody. If it is simply no longer available, reload the queue.

When the person is already approved

Approving is refused if you already hold a binding approval for the same person. The console names the verification that stopped you and which identifier matched, their customer reference, their email address, or the document itself.

This is not a mistake on your part, and nothing about the case is wrong. It happens when two verifications for one person are open at the same time, usually because they started twice under two different accounts. Neither blocks the other while both are waiting, because neither has been decided yet. By the time you reach the second one the first has been approved, and approving again would record two approvals for one human, which is exactly what your re-verification setting exists to prevent.

Your decision is not recorded and the case stays open and still yours, so nothing is lost. Read the approval it names. If the two really are the same person verifying twice, the second case is a duplicate and rejecting or retiring it is the honest answer. If you genuinely intend to approve again, issue a re-verification grant against the existing approval first, and then decide.

Rejecting a case that is still waiting is never refused. A rejection cannot duplicate an approval, so a case you want to close stays closable. The one exception is a case whose verification already has its answer, described below.

Cases that leave the queue on their own

While your re-verification setting is on, two things keep one person from holding more than one open question with you.

An approval closes the person's other open cases. When a verification is approved, automatically or by one of your team, any other case for the same person still waiting in the queue is taken off it. Nobody decided that case, so no decision is recorded on it and the applicant is not emailed. In Verifications it shows as expired with the reason ALREADY_VERIFIED, and the approval that closed it is on the same person's person page. If a case you were holding disappears from Mine, this is the usual reason. A case somebody has escalated is left alone, because a colleague is waiting on an answer there.

A new attempt is refused while a case is open. If the same person starts again while their case is waiting on a reviewer, the new attempt does not join the queue. It shows as expired with the reason REVIEW_IN_PROGRESS, and the applicant is told their verification is already being reviewed. The case you already have is the one to decide. The one exception is a case that is only here because a check failed in a way the applicant was invited to retry, such as a selfie that was too dark: their retry is allowed, and if it is approved, the failed attempt leaves the queue as above.

The same person is recognised by your customer reference, their email address, or their document, including the national id printed on it, so a person who comes back with a driving licence after verifying with an ID card is still recognised.

A case whose verification already has its answer is closed automatically. Occasionally a case is left open after its verification was settled without it: approved or rejected when it was run again, or closed as a repeat of an earlier approval. Such a case never appears in the queue, and it is closed on its own within a few minutes. If you reach one first, from the verification page, deciding it would send your systems and the applicant a second, different answer, so the console refuses: it tells you the verification was already approved, rejected or closed, records nothing, and closes the case. Nothing is sent to you or to the applicant. A case we put back in the queue on purpose, for you to look at an approval again, stays yours to decide.

A case that is only here because we could not run the checks is run again. When our verification service is unavailable, a verification it could not check is placed in your queue with the reason Engine unavailable (ENGINE_UNAVAILABLE), so the applicant is never left waiting with no answer at all. When only our primary document reader was unavailable, the document is read by a simpler backup reader instead, and a case that lands in your queue on that backup reading is treated the same way. Once the service is back, every such case that nobody on your team has started on is run through the checks again with the primary reader, and that result stands: the verification is approved, rejected, or stays in the queue with the real reasons, and you and the applicant are told exactly as for any other verification. A case somebody has assigned, written a note on, messaged the applicant about or decided is left alone and stays yours. Each case is tried a few times at most, over a few hours; if we still cannot check it, it stays in your queue as an ordinary case to decide.

Cases handed out rather than taken

Your organization can hand cases out instead, either by a person assigning them or automatically as they arrive. When that is how you work, Mine is where your work appears and you are notified when something lands there. Owners and review managers still see everything.

Reading a case

What each check found is the heart of it. Each check is written in plain language rather than in codes: the face matches the document, liveness failed and this may be a spoof, the document needs a human look. A check that could not run at all says so, which is a different thing from a check that failed and should not be read as evidence against the applicant.

Applicant shows who they claim to be. Where a name was transliterated by us rather than printed on the document, it is labelled as such, so you are never comparing our rendering against the scan and calling it a mismatch.

Evidence is the captures. Open them large, and zoom.

Internal note is for your team. Say what you checked and what tipped it. The applicant never sees it.

Correcting what the engine read

If the fields are wrong but the decision is not, use Edit under the applicant on the case. It puts the scan beside every field the document prints so you can fix what was misread, and asks for a reason (the document was read wrong, a field was not read, the applicant asked, the document changed, or other) with an optional note for your team.

Editing changes the stored applicant data only. It re-runs no check and approves and rejects nothing, so correct the fields first and then decide the case. Every save is kept as a new version with your name, nothing is ever deleted, and your webhook endpoints receive verification.data_updated. Fields that did not come from the document are not editable here, and the verbatim machine output is shown but never edited, because it is the evidence the parsed fields are checked against.

Once a case has been edited, its applicant section turns amber with a Modified badge showing the version and how many times it was edited, and History lists every version with who changed what, when and why. Any version can be restored. The same editing works after the case is decided, from the verification's own page; see Editing applicant data for what changes once a decision has been made.

Deciding

Approve or reject, then write the outcome.

If nothing will be emailed, because there is no address and no sender, the console says so before you confirm. The decision is still recorded and still reaches your webhook endpoints.

Escalating

When you honestly cannot decide, escalate instead of guessing. You say why, optionally recommend what you would do, and optionally mark what you were able to check. It goes to an owner or a review manager, who is notified.

Your recommendation is an opinion, not the outcome. Whoever takes it still decides, and they can return the case to you with a note saying what to look at.

Escalating and resolving somebody else's escalation are separate permissions on purpose, so nobody resolves their own.

When you cannot decide

If your role can read the queue but not decide, the console says so and the buttons are disabled. Ask an owner. If your seat cannot see applicant details on a case, it says that too: deciding without seeing who it is would be guesswork, so the two normally travel together.

Retiring cases you will never work

Some cases are never going to be decided. A flow you have retired, a backlog that came across when you migrated, applicants who moved on months ago. Approving or rejecting them would be dishonest, because nobody assessed them, and rejecting in particular would overwrite the status each record already carries and tell those people they failed a check that was never run.

Retiring takes those cases off the queue without deciding them. It is available to owners and review managers, and it is a separate permission from deciding, so a reviewer who works your queue every day never sees it.

There are two ways to do it. Ticking cases in the queue gives you Retire in the bar that appears with the selection, for a handful you have looked at. Choosing a flow in the filters gives you Retire every open case on this flow, which is the one to use for a migrated backlog: naming the flow is the selection, and there is deliberately no way to say "everything in the queue".

Either way the console tells you how many cases will go before you confirm, and how many are left afterwards. Large backlogs are cleared several hundred at a time, so if the message says cases remain, run it again.

A retired case is not closed forever. It carries no decision, so if the answer ever arrives, from a platform you migrated from or from anyone else settling it, that real decision still lands on the record. What retiring removes is the demand on your reviewers' attention, not the case itself.

Cases somebody has escalated are left alone. An escalation is a colleague waiting on an answer, and those want a person rather than a bulk action.

Cases decided without you

Your organization can switch on automatic decisions, which settle cases at or beyond the score thresholds you set and leave everything in between for your reviewers. A case with any failed check is never approved automatically, and neither is a case in Fraud review, whatever its score. Those decisions are real, so applicants and your webhooks are notified, and each case shows it was decided automatically. It is off unless you turn it on, and it lives on the Team page.