Step 1
Read the reason
Open the session and look at the status and the error code: “suspicion”, rejection for document authenticity, a data mismatch or a failed database check. What to look at next depends on the reason.
Manual review and the operator interface
Typical KYC sessions are decided automatically; the disputed ones — by your employee. In the NeuroVision account they see the document and selfie frames, the results of all checks and the form data in a single card, change the status in one action, and the log records who made the decision, when and why.
Employee permissions — by roles 2FA for every account user Log export to CSV and XLS
Verification operator interface: what the employee sees in the session card
One card instead of five windows
The employee does not collect evidence across systems: frames, results and rejection reasons are already brought together by scenario step.
- 01
Document and authenticity
Recognised type and fields, the machine-readable zone and its checksums, signs of a photo of a screen, a photocopy, a printout and a graphics editor, signature and stamp. The employee sees which sign triggered the rejection and looks at the frame themselves.
- 02
Selfie, face match and Liveness
The customer’s photo, the result of matching the selfie against the photo in the document and the liveness check result — if these steps are in the scenario. This is a one-off match within a single session, not a search for a person in a database.
- 03
Databases and form
Database check results with the “Re-check” button and a match against the form if the customer filled it in at the first stage. You can see which check was not run and which failed.
- 04
The whole session at a glance
The “JSON” tab — the same result your server receives. From the session menu you can open the scenario, copy the session link, get the user’s data or delete the session after confirmation.
- 20 sessions on the “KYC Logs” screen, new ones appear on their own
- 100 rows per report page with filters
- 365 days the longest search period in reports
Queue of disputed cases: how to collect sessions for review
You decide which sessions go to a person — the criteria are covered on the page automated verification. Here — how those sessions reach an employee and do not get lost. Filters and parameters — in the session filtering documentation.
-
Suspicious first
The “Suspicion” status filter. This is where sessions with a critical-error limit or signs of manipulation end up: they are closed to new frames and wait for a person’s decision.
-
Rejections by reason
The “Search by errors” filter. Collect all rejections with one code — for example, “document from a screen” or “data does not match the form” — and review them as one batch.
-
Customer or document
The “Search by value” filter. Find all sessions by full name, document number or the customer key from your system: you can see how many times a person went through verification and with what outcome.
-
Your flow — your team
The “Scenarios” filter. If retail and corporate use different scenarios, each team sees only its own sessions.
-
A queue in your system
Webhook and filtering via the API. Your back office receives the outcome of every session and queues the disputed ones by its own rules — with an assigned employee and a review deadline. The session filtering method returns the same list as the account.
-
Nothing gets lost
New sessions appear in “KYC Logs” without a page refresh, and the report is exported to CSV or XLS for an end-of-shift reconciliation: how many disputed sessions arrived and how many were reviewed.
Reviewing a session step by step: from the document frame to the decision
An order that is convenient to fix in a verifier guide. Each step relies on a tab of the session card.
Step 2
Look at the document
On the “Document” tab — the frame and the sign that triggered. Glare or a cropped edge — a reason to ask for a retake; traces of an editor or a pasted-in photo — a reason to reject.
Step 3
Compare the frames by eye
On the “Selfie” and “Faces” tabs the employee sees the selfie, the photo from the document and the result of matching them, and decides themselves whether it is the same person. The decision is theirs, not the algorithm’s.
Step 4
Match the data
The “Form” and “Databases” tabs: whether the full name and date of birth match the form, which checks were run and what was found. If a source did not respond — “Re-check”.
Step 5
Make the decision
Change the status: “success”, “rejected”, or leave “suspicion”. The account asks you to confirm the action; after the change the session no longer accepts frames. If you need a new frame — upload it to the session before deciding.
Step 6
Notify and record
Your system receives the new status and tells the customer the outcome or sends a new verification link. The reason for the decision stays in the log — in case the customer objects or the regulator inspects.
The employee compares the frame and the photo themselves: the lawful route under 572‑FZ
-
Liveness and matching in one session
A liveness check and a one-off match of the selfie against the photo in the document the customer is showing right now are ordinary steps of a KYC session. The employee sees their result and the frames on the “Faces” and “Vitality” tabs.
-
“Is this the same person?” — the employee decides
If you need to understand whether this is the customer who has already been verified, the employee opens both sessions and compares the frames themselves. When the comparison is made by an authorised person rather than automatically, 572‑FZ does not apply — this is stated directly in Art. 1, Part 2, Cl. 2.
-
Automatically — only through the EBS
Automatic identity confirmation by biometrics outside your employee goes through the Unified Biometric System (UBS). How to combine the UBS with NeuroVision checks — on the page remote identification via the UBS.
-
A repeat check instead of recognition
If you doubt a customer who has come back, send them a new link: the document and Liveness again, with the selfie matched against the photo in the document. This is a new check, not a search through old images.
The right to view selfie and document images is granted by a role, only to those who review sessions. Fix the manual matching procedure in the verifier guide.
The employee’s decision: changing the status in the account and via the API
A manual decision is a new session status. Your server sees it the same way as an automatic outcome, so your product does not need to learn a separate path. Status values
-
In the account
Where: “KYC Logs”, the status in the session card.
How: pick a new status and confirm. The “manual status change” permission is granted by a role. -
From your back office
Where: the method KYC session status change.
How: session ID and the new status — any of the seven. Handy if the queue and the verifier’s workstation live in your CRM. -
The outcome is locked in
What changes: after a manual change the session no longer accepts frames, so the outcome will not be overwritten by the customer’s later attempt.
If you need a new frame: upload it before changing the status or send a new link. -
Databases — once more
When: a source did not respond or the customer’s data was clarified.
How: the “Re-check” button on the “Databases” tab. A repeat run is a separate request at the price of a check.
Roles and permissions: who views images, who changes the status, who deletes
Account access is built from the account owner: they, or a user with the delegation permission, assemble roles from individual permissions and assign them to employees. A verifier, a shift lead and an auditor get exactly what their work needs.
- KYC session history and the log journal — the basic permission of anyone who works with the queue
- Recognised document data and check results: without the permission they show “access denied”
- Images of documents, selfies and face crops are enabled separately: without the permission the data is visible but the images are hidden
- Manual status change is a separate permission. Give it to those who may decide, not to everyone who looks
- “Re-check” databases starts paid requests; the permission for database checks is granted by a role
- Deleting sessions and destroying personal data is a separate permission; every destruction is entered in the log
- Exporting logs and reports to CSV and XLS — for the auditor and the responsible employee
- Two-factor authentication is mandatory for all account users; registration is by invitation
- Sign-in log: date and time, user, IP address, browser, device
- A list of IP addresses from which API requests are allowed, and disabling a user on dismissal
- Permissions are set in “Settings” → “Roles”; you cannot give an employee more permissions than the owner has. For more on API permissions, see session filtering documentation.
Audit trail: what stays in the log after the decision
A year from now a customer will contest a rejection or an inspector will ask why an account was opened. The answer must be found in minutes: who looked at the session, what they saw and what decision they made.
- Discuss the log
Decision log
Every manual status change.
What is recorded
- employee
- date and time
- status “was → became”
- session ID and customer key
Where to look
- the session card in the account
- reports with filters
- export to CSV and XLS
- Show the logs
Access and data logs
Who signed in and what they deleted.
Sign-in log
- user
- IP address
- browser and device
Data deletion log
- who destroyed the data — an employee, the API or the system
- reason: customer request, withdrawal of consent, purpose achieved
- which parts of the data
- Set up retention
Archive for inspectors
Sessions and decisions for a period.
Export
- KYC session log archive by filter — via the account or the API
- the “Statistics” dashboard: share of successful and rejected sessions, rejection reasons
Deadline
- under 115‑FZ, identification records are kept for at least five years after the relationship ends
- the session data retention period is set in the scenario
Methods — KYC log archive and data deletion log
Managing identification scenarios without a developer
-
Create a session manually
The “+” button above the session list creates a new session of the chosen scenario — for example, for a customer who came to the office or phoned.
-
Send the customer a link
The “KYC Links” tab — one-time links to go through verification. After a disputed outcome the employee starts the repeat check themselves.
-
Go through verification yourself
The “KYC SDK” button opens the widget right in the account: the shift lead sees the scenario through the customer’s eyes before changing the verifier guide.
-
A copy instead of live edits
A scenario can be copied and the changes tested on the copy. Deleted scenarios stay in a separate list.
-
Editor permission — separate
The “KYC Editor” tab is visible only to users with the permission to edit scenarios. A verifier reviews sessions but does not change the rules.
-
See the effect of changes
The “Statistics” dashboard: share of successful and rejected sessions, rejection reasons, number of attempts — by scenario and for the chosen period. A scenario edit shows on the chart.
What exactly is configured in a scenario — on the page digital onboarding and in the KYC editor guide.
Where the law requires a person: customer objection, responsible employee, retention period
Manual review is not only a way to handle a hard case. In three places the law directly counts on a person’s decision, and the operator interface must provide evidence that the decision was made that way.
- A decision with legal consequences for a person may not be based solely on automated processing of their data, except with written consent or where a federal law expressly provides (Art. 16, Parts 1–2)
- The company explains the decision procedure, gives an opportunity to object and considers the objection within 30 days (Art. 16, Parts 3–4). Handling an objection is the employee’s work with the session card
- The organisation appoints designated officials responsible for internal control rules (Art. 7, Cl. 2). They decide on list matches and doubtful customers
- Account roles let you give the responsible employee the permission to decide and everyone else — only to view
- Documents and information obtained during identification are kept for at least five years from the termination of the relationship with the customer (Art. 7, Cl. 4)
- The session data retention period is set in the scenario in days, “0” — indefinitely; the export and the log help move the evidence to your archive
- If an authorised person, not an automatic system, checks that a person’s face matches their data in your system, 572‑FZ does not apply (Art. 1, Part 2, Cl. 2)
- Automatic identification and authentication by biometrics outside this case goes through the UBS (Art. 15, Part 1, Cl. 2); agree the processing of biometric personal data with a lawyer
- This is a guideline, not a legal opinion; the exact text of the rules is in ConsultantPlus. Where the line of an automated decision lies — on the page automated verification; 152‑FZ requirements for a KYC service — on the page a KYC service in Russia.
How much a check with manual review costs
You pay for a KYC session with all the scenario steps. The session card, filters, roles, logs and manual status change are account and API features; they have no separate line in the price matrix.
- Enable
Document
from 16 ₽ per session
Document recognition and anti-fraud: screen, printout, photocopy, pasted-in photo, editing. The employee reviews the document and the data.
-
Everything in the “Document” package plus a selfie or Liveness and face matching against the photo in the document — the employee sees the result and the frames.
- Calculate
Extended
on request
Document, Liveness and database checks in one session: Russian databases and international sanctions and PEP screening.
“Re-check” databases — RUB 5 per check, all 16 checks against Russian databases — RUB 50, international screening — RUB 36, an additional document — RUB 10. The price per session falls with volume — the calculator in the price matrix.
How to connect manual review: account, API or your back office
Terms
- Access — with an invitation code from a manager
- A 1-month trial period
- Support under contract
Manual review glossary
Terms of the account, the API and conversations with a lawyer.
- Manual review
- A review of a KYC session by an employee: they look at the frames and results and set the outcome themselves.
- manual review
- Operator interface
- The verifier’s workstation: “KYC Logs”, “KYC Reports” and the session card.
- back office
- Queue of disputed cases
- A list of sessions that, by your rules, wait for a person’s decision.
- review queue
- Manual status change
- The employee’s decision: a new session status in the account or via the API. After it the session accepts no frames.
- manual status change
- Re-check
- Re-running database checks from the session card. Paid as a new request.
- re-check
- Role
- A set of permissions the account owner gives to employees.
- role
- Decision log
- Records of manual decisions: who, when, what the status was and what it became.
- audit trail
- Matching with an employee involved
- Comparing a person’s face with their photo, done by an authorised person rather than automatically. 572‑FZ does not apply to it.
- staff-confirmed match
- Objection
- A customer’s appeal against an automated decision. Considered within 30 days.
- objection
- A designated compliance officer
- An employee responsible for internal control rules under 115‑FZ.
- compliance officer
Read also
373 19
KYC, AML and Digital Identification
KYC Automation: How AI Reduces the Share of Manual Review and Helps Scale the Process
446 10
KYC, AML and Digital Identification
False Positives in AML Screening: How to Reduce Escalations and Preserve Onboarding Conversion
352 23
KYC, AML and Digital Identification
Repeat KYC: how to conduct re-identification without losing customers
396 16
KYC, AML and Digital Identification
How to ensure the protection of personal and biometric data in KYC processes
392 13
KYC, AML and Digital Identification
How to build a KYC policy compliant with Federal Law 115-FZ, Federal Law 152-FZ, FATF and GDPR
Frequently asked questions about manual KYC review
The workplace of an employee who reviews disputed KYC sessions. In the NeuroVision account these are “KYC Logs” with real-time sessions, “KYC Reports” with filters, and the session card: document, selfie, face match, Liveness, databases, form and the full result.
Usually suspicious ones, final rejections, matches in lists and sanctions lists, incomplete database checks and customer objections. Your company sets the criteria; a detailed breakdown is on the automated verification page.
Yes. Your server receives the outcome of each session by webhook, puts the disputed ones in its own queue, and the employee’s decision comes back through the API status change method. The account stays for viewing frames and auditing.
A one-off match of the selfie against the photo in the document within a session, and Liveness, are ordinary check steps. If the employee compares the frames themselves to understand whether it is the same person, this is a check involving an authorised person: under Art. 1, Part 2, Cl. 2 of 572-FZ the law does not apply to it. Automatic recognition by biometrics goes through the UBS.
Only those to whom the account owner has granted the permission for images. Without it the employee sees data and check results, but not the pictures.
Who changed the status, when, from which to which, the session ID and the customer key. The account sign-in log and the personal data destruction log are kept separately. Sessions and decisions are exported as an archive for the period you need.
The status can be changed again — this is also a manual decision and it will go into the log. New frames are not accepted into the session after a manual change: if you need a new picture, send the customer a new link.
In the account: create a session manually, send a one-time link, go through verification yourself in the widget, make a copy of a scenario and test changes on it. The editor is available only to users with the permission to edit scenarios.
For organisations under 115-FZ — at least five years from the termination of the relationship with the customer. The session data retention period in NeuroVision is set in the scenario, and the export helps move materials to your archive.
You pay for a KYC session: “Document” — from RUB 16, “Document + liveness” — from RUB 29, the extended package with databases — on request. A repeat run of a database check — RUB 5. The account, roles and status change are not listed as a separate line in the price matrix.
We will set up manual review for your team
Tell us how many disputed sessions your employees review per day and where the queue lives now — we will propose roles, filters, a link with your CRM and a per-session price estimate.
Can't put your request into words? Book a call and our team will contact you at a convenient time
Book a call
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.
