Automatic client verification

Q: When is the session outcome final?

The statuses success and suspicious are final immediately. failed becomes final when the session lifetime has expired or the attempts have run out, and expired — when the client did not complete the check in time. If you need to receive only the final outcome, enable the “Notify only if the session is finalised” flag in the scenario.

Automatic client verification is when a KYC session reaches an outcome on its own under the rules of your scenario: the document is acceptable or not, the data match or not, there are signs of forgery or there are none. Your system receives the outcome with reasons and decides without an employee, while the employee is left with exceptions — and decisions that the law does not allow to hand over to automation.

Set up the rules What the outcomes mean

4 outcomes success, failed, suspicious, expired — with reasons for each step

15 min — 6 h session lifetime, set in the scenario

30 s the platform waits for your server to respond to the webhook

from 16 ₽ per KYC session with all scenario steps

Rules — in the KYC editor, no development Manual status change — in the account and via API Document anti-fraud — in all packages

Verification without an operator: what the platform decides and what — your system

An outcome without a queue to an employee

An employee does not take part in a typical session: the platform checks, your system applies the rule. Manual review — only by the criteria you have set in advance.

01
The platform issues the check outcome

Every KYC session ends with a status: the check passed, failed, was flagged as suspicious, or the client did not finish it in time. The status is set automatically under the scenario rules, with errors for each step attached — what exactly failed and why.
02
You set the rules, no development

Which documents and countries to accept, which forgery signs to treat as a rejection, what age is acceptable, how many critical errors to tolerate, how long a session lives — these are all scenario settings in the KYC editor. Changes apply to new sessions after saving.
03
Your system makes the decision about the client

Opening an account, issuing a loan, allowing sales — this is the company's decision. Automating client checks means that your system does this itself based on the session outcome rather than waiting for an employee. Where the boundary lies and what the law requires — below, in the block on Federal Law 152‑FZ and 115‑FZ.
04
An employee handles exceptions

Suspicious sessions, disputed database matches, failures and client objections go to a person. They see the photo, the recognised fields, the check results and the reason for rejection, and change the status manually. How to build this into the whole client journey — on the page about automated client onboarding.

7 session statuses, 4 of them final
0 = no limit critical errors before blocking are set in the scenario
1 session one payment for all steps and retries

Scenario rules: which condition leads to which outcome

KYC scenarios with rules are built in the account: “KYC/AML” → “KYC Editor”. Below — what in a scenario turns a check result into a session status. The error code in the response tells your system what to do next. How the same rules look from the client's side and where they fit in onboarding — on the page about decision rules in onboarding.

The step has document types and permitted countries selected. The client photographed a different document — the error [document] bad document type, the step is not passed. The client does not need to specify the type and country — the platform detects them itself failed
The document has expired, the fields are unreadable or recognised with low confidence, a required signature or stamp is missing — if these checks are enabled in the step failed
Flags soften the rule: “ignore text recognition errors”, “disable cross-document data matching”. Enable them deliberately — they raise the share of successful sessions at the cost of strictness Scenario flag

A photo of a screen or of another device, a photocopy, a printout, traces of a graphics editor, a pasted-in photo, logical inconsistencies in the fields — category codes [fraud] failed
Different documents or documents of different people are uploaded in a session; two different documents at one step — the session is blocked by a scenario flag Scenario flag
The critical error limit set in the scenario has been reached — protection against guessing forged images. The session immediately gets the outcome “suspicious” suspicious

The age from the date of birth in the document is outside the “From — To” range from the scenario — [general] age requirement mismatch, “the check cannot be passed now”. More details — on the page age verification failed
Full name or date of birth differ between session steps — [general] data mismatch failed
In a two-stage scenario the document data did not match the form: the name is compared word by word with a tolerance, the date of birth — exactly. The client is not told which field did not match failed

The last attempt at a step failed — [general] too many tries, the session closes immediately failed
The client did not finish the session within its lifetime (15 minutes — 6 hours) — the outcome is “expired” expired
If the scenario has a selfie or liveness: the images show faces of different people — the session is blocked for good. Whether to use the face step in your process is decided by your lawyer suspicious572-FZ
Database checks from the scenario run in parallel and arrive as a separate result. They do not change the session status — what counts as an obstacle is decided by your system Separate from the status

The full list of codes and what to show the client — in the KYC error reference; all scenario settings — in the KYC editor guide. Fraudulent registrations before KYC — on the page registration anti-fraud.

Session outcomes: success, failed, suspicious and expired

Besides the four outcomes, a session has intermediate statuses: idle — created but not yet processed; processing — processing in progress, including database checks; exception — a processing error, the status must be requested again. No decision is made on an intermediate status. All statuses in the documentation

success — the check passed

When: all scenario steps are passed, the document anti-fraud raised no flags, the data match between steps and with the form.

Your system: opens access automatically; takes database check results into account when they arrive.
- Outcome immediately
- successCb in the widget
failed — the check failed

When: a step did not pass — the frame was unsuitable, the wrong document, a forgery, age, a data mismatch. While the session has time and attempts left, the client can retake, and the status will change to success.

Your system: waits for the final outcome and only then rejects or sends to an employee.
- Final
- after the lifetime or attempts run out
suspicious — a suspicious session

When: the critical error limit has been reached or the images show faces of different people. The session is closed, no more frames are accepted into it.

Your system: does not open access and does not offer a retry automatically — the session is reviewed by an employee.
- Outcome immediately
- To manual review
expired — the session expired

When: the client started but did not finish the check within the session lifetime from the scenario.

Your system: offers to take the check again — a new check needs a new session. Abandoned sessions are visible in reports and help find the step where clients drop off.
- Result
- New session

Retries: when a rejection is not yet final

Status failed in the middle of a session — is not a verdict: while the session has time and attempts left, the client can pass the step again. The number of attempts per step is limited, retries are not charged — you pay for the session. Six situations that appear most often in reports. How the client sees the retry texts — on the page verification on a website and in an app.

Situation 1

A bad frame — retake

The passport photo has glare, the document is cropped or the fields are unreadable. The step is not passed, the session is temporarily in the status failed, the client sees a hint and shoots again. A good frame — and the status changes to success.

A frame with glare was not accepted — the client retakes the document

Situation 2

Only the required step is retaken

If the cross-step matching failed, the response contains a list of steps to retake — the field retake. The client repeats only those; the other passed steps do not accept new frames.

Only the step from the retake list is retaken

Situation 3

Attempts ran out

The last attempt at a step failed — the session closes immediately with the error “attempts exhausted”. This is a final failed: a new check needs a new session, for example a new link.

Situation 4

Forgery guessing stopped

The client keeps sending a photo of a screen or a printout. When the number of critical errors reaches the scenario limit, the session gets suspicious and closes — with no new attempts.

The critical error limit was reached — the session is suspicious

Situation 5

Time ran out

The client got distracted and did not come back. When the session lifetime has expired, the unfinished session gets expired, and failed becomes final. The period is set in the scenario: from 15 minutes to 6 hours.

Situation 6

An employee made the decision

An employee opens the disputed session in the account and changes the status manually — or your system does it via API. After the manual change the session no longer accepts frames, the outcome is fixed.

An employee changes the session status manually

When to pass a session to manual review

The “suspicious” outcome

The critical error limit or signs of manipulation are a reason to investigate, not simply to reject. An employee looks at the frames and reasons and decides: rejection, a new check or a request for documents.
A final rejection that cannot be handed to automation

If there is no written client consent to an automatic rejection and the law does not directly permit such a decision, a person confirms the rejection. More details — in the block on 152‑FZ.
A database match

The list of terrorists and extremists, sanctions lists, wanted lists, enforcement proceedings. AML/CFT measures and the decision about the client are made by the responsible employee under your internal control rules.
A database check was not performed

There was not enough data or the source did not respond. A skipped check means “not checked”, not “clean”: first look at whether the check was performed, then — whether it was passed.
A processing failure

Status exception is not final: request the status again. A client cannot be rejected because of a technical failure — if the failure repeats, contact support with the session ID.
A client objection

A person disagrees with the automatic decision and writes to you. Under 152‑FZ the objection must be considered within 30 days and the result communicated — this is always an employee's work.

KYC without manual review works on typical sessions. It is better to send these six cases to an employee straight away — by a rule in your system.
An employee's decision is recorded by changing the session status manually — in the “KYC Logs” section or with the method status change. The queue and deadlines of manual review are managed by your system.
How not to flood employees with false database matches — in the article “False positives in AML screening”.

The final outcome on your server: webhook, status and database checks

Five rules so that an automatic decision is made once and on the final outcome. The event format and encryption — in the webhook documentation, widget callbacks — on the page verification on a website and in an app, API methods — on the page API and SDK.

Decide on the server, not in the browser

A widget callback is not a decision. The success callback reaches the browser only on success, and it can be forged. Open access by the status your server received: from the webhook SESSION_COMPLETE or by a session status request.
Wait for the final outcome

Intermediate events are not a reason to reject. By default the webhook arrives on every change of the result while the client goes through the session. The “Notify only if the session is finalised” flag leaves one event — when the time ran out or the attempts ran out.
Account for databases separately

The order of events is not guaranteed. Database check results arrive as an event DATABASE_CHECKS_COMPLETE — before or after the session outcome. First look at whether the check was performed, then — whether it was passed.
Do not lose or duplicate the decision

There is no resending, duplicates are possible. If the webhook did not arrive, get the state with a status request by session ID. One event may arrive twice — process it so that a repeat does not create a second decision.
Protect the channel

There is no signature — there is encryption. Enable body encryption with the scenario secret key: only your server can decrypt it. The “Do not send personal data” flag leaves only statuses and results in the notification.
Respond within 30 seconds

That is how long the platform waits for your server to respond. The response code is not taken into account — accept the event immediately and build the decision in your own queue, not inside the webhook handler.

Instant verification: how long a check really takes

Document and anti-fraud — seconds

Field recognition, document authenticity checks and cross-step data matching take seconds after the client sends a good frame. Most of the time goes on the shooting itself.
Selfie and liveness — up to a minute

If the scenario includes a liveness check, it takes from a few seconds to a minute — depending on how quickly the person performs the task. Whether to enable this step is decided by your lawyer: the processing of face images is regulated by 572‑FZ.
Database checks — separately

Requests to external sources run in parallel and take longer — their result arrives as a separate event. That is why fast client verification is built like this: access on the session outcome, restrictions — when the databases respond.
Where to see the time

The actual processing time of each session and check — in the response field spent . Check the average KYC check speed on your own traffic in the account reports after a test, and the daily trend — in the dashboard.

“Instant” means without a queue to an employee, not within a fixed number of seconds.

What cannot be fully handed to automation by law

Fully automated verification is a technique, not a legal basis. The platform issues the check outcome; the decision about the client, its lawfulness and the client's rights remain with your company.

A decision that produces legal consequences for a person or otherwise affects their rights may not be made solely on the basis of automated processing of personal data (Part 1, Art. 16) Your company
Such a decision is permissible with the person's written consent or in cases provided by a federal law that itself sets measures to protect rights (Part 2, Art. 16). An electronic document signed with an electronic signature is equivalent to written consent (Part 4, Art. 9) Your companyAsk your lawyer
The company must explain the decision-making procedure and its consequences, give an opportunity to object and explain how to protect one's rights. An objection is considered within 30 days with notification of the result (Parts 3, 4, Art. 16) Client rights

Identification and simplified identification are carried out by the organisation itself by the methods set by law (cl. 1, 1.11, 1.12, Art. 7), remotely without personal presence — with ESIA and the Unified Biometric System (cl. 5.8, Art. 7). NeuroVision checks the document and data but does not identify the client Your companyNeuroVision
Internal control rules, client risk assessment, refusing a transaction or contract, reporting to Rosfinmonitoring — are decisions of the organisation and its responsible employee (Art. 7) Your company
A match with the list of terrorists and extremists requires freezing (blocking) measures — this is the organisation's obligation (cl. 6, Art. 7); a KYC session outcome does not replace it Your company

A selfie, comparing the face with the photo in the document and liveness are a scenario step. Processing biometric data for identification outside the Unified Biometric System is restricted by Art. 15 of 572‑FZ — whether the step can be enabled is decided by a lawyer Ask your lawyer
The “Document” package works without a face: an automatic outcome can be built on the document, anti-fraud and data alone NeuroVision

This is a guide for a conversation with a lawyer, not a legal opinion; the exact text of the norms — in ConsultantPlus. In practice companies choose one of three paths: 1) only approve automatically, with an employee confirming the final rejection; 2) obtain written consent to an automated decision and give the client a way to object; 3) rely on a direct permission of a federal law, if there is one for your operation. The other 152‑FZ requirements for a KYC service — on the page a KYC service in Russia; the general KYC policy — in the article “How to build a KYC policy under 115‑FZ and 152‑FZ”.

The price of an automatic check: you pay per session, not per attempt

The KYC session price includes all scenario steps, document anti-fraud and retries. A manual status change and review in the account are not charged separately.

Document

from 16 ₽ per session

Enable

Document recognition and anti-fraud: screen, printout, photocopy, pasted-in photo, editing, logical inconsistencies. An automatic outcome without the face step.
Document and face

Document + liveness

from 29 ₽ per session

Enable

Everything from the “Document” package plus a selfie or liveness and comparing the face with the photo in the document. Use is at your lawyer's discretion (572‑FZ).
Extended

on request

Calculate

Document, liveness and database checks in one session: checks against Russian databases and international sanctions and PEP screening.

An additional document in the same session — 10 ₽, a database check — 5 ₽, all Russian database checks — 50 ₽, international screening — 36 ₽. The data retention period is set in the scenario. The price depends on volume — the calculator in the price matrix.

How to launch automatic verification

Rules in the editor

Build a scenario: steps, documents and countries, checks, age, the critical error limit, the session lifetime. The rules apply to new sessions.

Editor guide

Terms

Access — with an invitation code from a manager
Cloud or deployment inside your perimeter
Support under the contract, via a ticket system

Get test access

Automatic verification glossary

Terms from the API response, the account and a conversation with a lawyer.

Session outcome: The final KYC session status: success, failed, suspicious or expired. Set automatically under the scenario rules.; session result
Intermediate status: idle, processing or exception: the session is not finished yet or processing failed. No decision is made on it.
Session lifetime: How much time the client has to complete the check: 15 minutes, 30 minutes, 1 hour or 6 hours. After it, an unfinished session gets expired.; session TTL
Finalisation: The moment when the outcome will no longer change: the lifetime expired, the attempts ran out or the status success or suspicious.; finalized
Critical error: An error that indicates an attempt at deception rather than a bad frame. After the scenario limit the session gets suspicious.; critical error
Retake: Only the steps listed in the field are repeated retake of the response.; retake
Manual status change: An employee's decision: the session status is changed in the account or via API. After that the session does not accept frames.; manual status change
Skipped check: A database check that was not performed — for example, there was not enough data. It means “not checked”, not “clean”.; skipped check
Webhook: A notification the platform sends to your server when a session result changes or database checks arrive.; webhook
Automated decision: A decision about a person made solely on the basis of automated processing of their data. Restricted by Art. 16 of 152‑FZ.; automated decision
Objection: A person's appeal against an automated decision. The company considers it within 30 days.; objection

Frequently asked questions about automatic verification

It is a client check in which an employee does not take part in a typical case: the KYC session sets the outcome itself under the scenario rules, and your system opens access or rejects based on the outcome. An employee joins only for exceptions — suspicious sessions, database matches, failures and client objections.

Technically — yes: the outcome of each session is set automatically. Legally, rejecting a client solely on the basis of automated data processing is permissible with their written consent or in cases directly provided for by a federal law (Art. 16 of 152‑FZ). That is why many companies approve automatically while an employee confirms the final rejection. Choose the scheme with your lawyer.

NeuroVision checks the document and data and sets the check outcome. The decision about the client — opening an account, issuing a loan, allowing a transaction — is made by your company under its own rules, including the internal control rules under 115‑FZ.

The statuses success and suspicious are final immediately. failed becomes final when the session lifetime has expired or the attempts have run out, and expired — when the client did not complete the check in time. If you need to receive only the final outcome, enable the “Notify only if the session is finalised” flag in the scenario.

Do not open access and do not offer a retry automatically: the session is closed, no more frames are accepted into it. This outcome means the critical error limit or signs of manipulation. An employee reviews the session and changes the status manually if the decision is different.

Recognition and document authenticity checks take seconds after a good frame, a liveness check — from a few seconds to a minute. Database checks run in parallel and arrive separately. The actual time of each session — in the spent field of the response.

Database check results arrive as a separate event and are handled by your system: it decides what counts as an obstacle. A skipped check means “not checked”, not “clean”: first look at whether the check was performed, then — whether it was passed.

While the session has time and attempts left, the client retakes the failed step, and on a mismatch between steps — only the steps from the retake list. After the final outcome a new check needs a new session — for example, a new link.

In the “KYC Logs” section of the account the session status is changed manually after confirmation; from your system — with the API status change method. After the manual change the session does not accept frames, the outcome is fixed.

The price is per KYC session with all steps and retries: “Document” — from 16 ₽, “Document + liveness” — from 29 ₽, the extended package with database checks — on request. The exact calculation by volume — in the price matrix.

We will set up the automatic check rules

Tell us which applications employees check now and what you want to decide automatically — we will propose the scenario rules, the manual review criteria and a per-session price calculation.

The NeuroVision platform is listed in the Russian software registry, entry no. 19972. Rospatent certificate no. 2023661508.

Address: Moscow, Presnenskaya Embankment 12 — Moscow City business centre, Federation Tower. Nearest metro stations: Delovoy Tsentr and Mezhdunarodnaya.

Automatic client verification

Verification without an operator: what the platform decides and what — your system

An outcome without a queue to an employee

The platform issues the check outcome

You set the rules, no development

Your system makes the decision about the client

An employee handles exceptions

Scenario rules: which condition leads to which outcome

1. Document and country

2. Document authenticity

3. Age and data between steps

4. Attempts, time, face and databases

Session outcomes: success, failed, suspicious and expired

success — the check passed

failed — the check failed

suspicious — a suspicious session

expired — the session expired

Retries: when a rejection is not yet final

A bad frame — retake

Only the required step is retaken

Attempts ran out

Forgery guessing stopped

Time ran out

An employee made the decision

When to pass a session to manual review

The “suspicious” outcome

A final rejection that cannot be handed to automation

A database match

A database check was not performed

A processing failure

A client objection

The final outcome on your server: webhook, status and database checks

Decide on the server, not in the browser

Wait for the final outcome

Account for databases separately

Do not lose or duplicate the decision

Protect the channel

Respond within 30 seconds

Instant verification: how long a check really takes

Document and anti-fraud — seconds

Selfie and liveness — up to a minute

Database checks — separately

Where to see the time

The share of automatic decisions: how to calculate it on your own traffic

What you can see in the account

Dashboard

Reports

What to calculate in your own system

Metrics

Quality control

How to change rules safely

Procedure

Do not

What cannot be fully handed to automation by law

1. 152‑FZ: decisions based on automated processing

2. 115‑FZ: identification and AML/CFT measures

3. 572‑FZ: the face step

4. Consent and transparency for the client

The price of an automatic check: you pay per session, not per attempt

Document

Document + liveness

Extended

How to launch automatic verification

Rules in the editor

Test scenario

Widget, link or API

Terms

Automatic verification glossary

Read also

KYC Automation: How AI Reduces the Share of Manual Review and Helps Scale the Process

False Positives in AML Screening: How to Reduce Escalations and Preserve Onboarding Conversion

Document verification in KYC: how automatic checking increases the approval rate and reduces the risk of fraud

How to build a KYC policy compliant with Federal Law 115-FZ, Federal Law 152-FZ, FATF and GDPR

Frequently asked questions about automatic verification

What is verification without an operator?

Is fully automated verification possible?

Who makes the decision — NeuroVision or our company?

When is the session outcome final?

What to do with the suspicious status?

Is it true that verification takes seconds?

`success` — the check passed

`failed` — the check failed

`suspicious` — a suspicious session

`expired` — the session expired