1. A scenario in the personal account
In the scenario editor you set the verification steps, document types and countries, anti-fraud checks, the callback URL and the secret key. The scenario ID (schemaId) is needed in the API and SDK.
One REST API for customer checks: recognition of passports and other documents with anti-fraud checks, AML checks against state registers and sanctions lists, with the result delivered in JSON and by webhook. For websites and mobile browsers — a ready-made Web SDK. It runs in the cloud in Russia or inside your perimeter.
POST /kyc/process POST /kyc/checks/run POST /kyc/checks/result DATABASE_CHECKS_COMPLETE Online customer checks via API: one account, one token and a common response format for all products. Connect only what your process needs — the rest can be added later without a new integration. Transaction monitoring (KYT) is connected per project — see the page KYT.
Russian passport, foreign passport, driving licence, ID card and 16 000+ more document types from 195+ countries and territories. The response contains the document type, fields with a confidence level and anti-fraud checks of the image: editing software, a photo of a screen, a printout.
The Rosfinmonitoring list, OFAC, EU, UK and UN sanctions lists, PEP compliance screening, wanted lists, debts, bankruptcy and courts — by full name and passport, without uploading a document. Each check is selected separately.
Checking the series, number and issue date of a Russian passport via SMEV and getting the taxpayer ID (INN) by passport are separate checks of the same AML API. Suitable for bank passport verification without a visit to the office.
A selfie, a selfie with a document and a liveness check are steps of the same KYC scenario: you enable them in the scenario editor and users go through them in the Web SDK. The result of matching the face with the document photo arrives in the session response.
A ready-made JavaScript widget guides the user through the scenario steps and sends the images to the API itself. It works in desktop and smartphone browsers.
Company status, signs of a shell company, courts, the director and founders — see the counterparty checks page. KYB methods are not yet published in the documentation: we will discuss API access during test access.
All methods use POST at https://api.neuro-vision.ru/v1/, the body is JSON or multipart/form-data for images, the response is JSON. Below are the methods you need for integration; the full list with parameters is in the REST API documentation.
A session collects all verification steps of one user within a scenario. The document response fields and an example of /kyc/process — see the page OCR API and SDK.
/kyc/process — document and selfie images, mode sync or async; /kyc/session/create — a new session/kyc/session/status — status and results by sessionId or clientKey; /kyc/session/status/change — manual status change/kyc/sessions, /kyc/sessions/filter — list and filter of sessions, CSV/XLSX export; /kyc/download — log archiveData-based checks, without a KYC session or a document upload.
/kyc/checks/run — the person's data and a list of checks in checkers, immediately returns runId/kyc/checks/result — polling by runId every 5–10 seconds until checksStatus becomes complete/kyc/session/databases — checks on the data of the recognised document; the result comes as a webhook event DATABASE_CHECKS_COMPLETEAPI access, balance and personal data management.
/user/login — a temporary JWT valid for valid_days; /token/create, /token/update, /token/delete, /tokens — permanent tokens/user/balance — the current balance of an account or a groupkyc/session/erase — erasing personal data by sessionId or by clientUser across all of the user's sessions; kyc/session/erase/log — the logYour backend stores the token and makes the decision; the frontend only captures the document and selfie. This way keys never reach the browser, and the check outcome always arrives at the server — even if the user closed the tab. Checks can be connected to a CRM, ERP or 1C through the same REST API.
The KYC API passport and AML checks in code: launching checks of an individual, the response and result, then the KYC session status. The structure comes from the documentation; the data is fictitious. An example of document recognition is in /kyc/process — see the page OCR API and SDK. Parameters are in the description of launching checks and session status.
Request: launching checks
cURLcurl -X POST "https://api.neuro-vision.ru/v1/kyc/checks/run" \
-H "Content-Type: application/json" \
-d '{
"token": "<YOUR_TOKEN>",
"person": {
"lastName": "Lavrov",
"firstName": "Yaroslav",
"middleName": "Ilyich",
"birthDate": "1990-01-01",
"passport": { "series": "0000", "number": "000000", "issueDate": "2010-01-01" }
},
"checkers": [
"passportVerification",
"regulatoryRestrictions",
"sanctionsLists",
"debtBurden",
"insolvencyStatus"
]
}' Response 200 OK
JSON{
"runId": "00000000-0000-1000-8000-000000000000",
"checksStatus": "pending",
"pending": 5,
"checkers": [
"passportVerification",
"regulatoryRestrictions",
"sanctionsLists",
"debtBurden",
"insolvencyStatus"
],
"responseTime": "2026-10-17T09:00:00.000Z"
} Response /kyc/checks/result (excerpt)
JSON{
"runId": "00000000-0000-1000-8000-000000000000",
"checksStatus": "complete",
"pending": 0,
"results": [
{
"checker": "regulatoryRestrictions",
"status": "success",
"outcome": "performed",
"notPerformedReason": null,
"missingInputs": [],
"result": { "passed": true, "items": [], "totalCount": 0, "error": null }
},
{
"checker": "debtBurden",
"status": "success",
"outcome": "unavailable",
"notPerformedReason": "providerUnavailable",
"missingInputs": [],
"result": { "passed": null, "items": [], "totalCount": 0, "error": null }
}
],
"responseTime": "2026-10-17T09:02:00.000Z"
} Polling for the result
Pythonimport time
import requests
API = "https://api.neuro-vision.ru/v1"
TOKEN = "<YOUR_TOKEN>"
def wait_checks(run_id, timeout=600):
"""Polls the result every 7 seconds until checksStatus != complete."""
started = time.time()
while time.time() - started < timeout:
resp = requests.post(f"{API}/kyc/checks/result",
json={"token": TOKEN, "runId": run_id}, timeout=30)
data = resp.json()
if data.get("checksStatus") == "complete":
return data["results"]
time.sleep(7)
raise TimeoutError("The checks did not finish in the allotted time")
for item in wait_checks("<RUN_ID>"):
print(item["checker"], item["outcome"], item["result"]["passed"]) Request by clientKey
cURLcurl -X POST "https://api.neuro-vision.ru/v1/kyc/session/status" \
-H "Content-Type: application/json" \
-d '{"token": "<YOUR_TOKEN>", "clientKey": "client-000001"}' Response (excerpt)
JSON{
"status": "success",
"sessionId": "00000000-0000-1000-8000-000000000000",
"schemaId": "00000000-0000-1000-8000-000000000001",
"clientKey": "client-000001",
"isClientNew": true,
"spent": 4.215,
"errors": [],
"results": ["… results for the scenario steps: document, selfie, faces …"],
"createdAt": "2026-10-17T09:00:00.000Z"
} The result of each AML check comes in two fields — the three possible statuses are below. The names of all checks are in the catalogue.
The outcome field tells whether the check reached the source; the passed field tells what the source answered. Read them in this order.
The check reached the register and returned a result: look at the passed field. Such a check is charged.
The check did not run: a required parameter was not passed. It is not charged. An empty result here means «not checked», not «clean» — do not take it for a passed check.
The source is temporarily unavailable, so there is no result. You can repeat the launch later with the same request.
Own interface + REST API — your frontend or mobile app does the capture, and your backend sends the images to /kyc/process and reads the response. The NeuroVision Web SDK — the widget does the capture: instructions, a frame, «fields not visible» hints, retakes; your backend creates the session, encrypts clientKey and receives the webhook.
Own interface — an HTTP client in any language; how to pass a series of frames for the liveness check without the widget, we will clarify during test access. Web SDK — liveness is a scenario step and runs in the widget; integration — <script> with widget-lib.js or the npm package kyc-widget-nv for React.
Own interface — the styling is entirely yours, and behaviour on a computer without a camera is your logic. Web SDK — the logo, colours, screen texts and a light or dark theme are set in the scenario editor; on a computer without a camera the user switches to a phone via a QR code or a link.
There are no separate iOS and Android SDKs at the moment. The widget is responsive and works with the smartphone camera, so inside an app it is opened in the built-in browser or WebView. Inside a cross-origin iframe the browser blocks the camera — the widget must not be embedded in someone else's iframe.
There are no server libraries for Python, Java and C# either: the API works over plain HTTP, and ready-made scripts are available in Python. The widget integration code for HTML and React is on the page OCR API and SDK and in the documentation: integration, parameters, working with clientKey.
Your own interface and the Web SDK require code integration. Without integration — a direct link to the widget or one-time KYC links from the personal account, up to 1 000 at a time.
Both options lead to the same result — a session with the same JSON and the same webhook. The difference is who draws the capture screens and checks image quality before sending. The Web SDK for verification suits a quick start; your own interface suits cases where capture is already built into your product.
mode=sync mode=async sessionId — structured data is stored indefinitely or for as long as the scenario sets. Access by token and roles
A permanent token is created with no expiry or with an end date, the term can be changed and the token can be deleted. The owner assigns account users roles with the sections they need, and sign-in is protected by two-factor authentication.
The browser sees no secrets
clientKey for the Web SDK is encrypted on your server with the scenario's secret key (the documentation gives an AES-256-CBC example). The secret key itself and the token are never passed to the browser.
Encryption and minimal data
The webhook body is encrypted with the scenario's secret key. The «do not send personal data» flag leaves only statuses in the notification — the backend fetches the data itself by sessionId.
One call per user
The method kyc/session/erase destroys the personal data of one session or of all of the user's sessions by clientUser, the erasure log is kyc/session/erase/log. Images are stored for 6 months; the retention period for results is set in the scenario.
Cloud or your own perimeter
The NeuroVision cloud runs on servers in Russia. With installation in your perimeter, images and results never leave your servers.
152‑FZ
servers in Russia · Russian software registry entry no. 19972
Quick start: a token and a scenario — and you can send requests. Scaling, monitoring and model updates are on NeuroVision's side. More details: KYC service in Russia.
The platform is installed as a set of Docker containers on your servers, and NeuroVision engineers perform the installation and updates. After installation it works without the internet: access is needed for licence activation and updates.
The same methods, the same JSON and the same webhooks — moving from the cloud to your perimeter does not require rewriting the integration. Only the API address changes. Server requirements are on the page OCR API and SDK.
For banks and state-owned companies with an isolated perimeter, dedicated servers and an individual SLA are discussed in the contract.
Check them during test access — on your data and your load.
Limits and packages
The tariff does not limit request frequency: a purchased package can be used up in a day or in a year. If the package runs out, the service is not blocked. We discuss the expected load and the number of parallel requests during test access.
One session — one at a time
Simultaneous uploads to one KYC session are processed one by one. The next request waits up to 25 seconds, then receives 409 session is busy — the frame was not processed and the attempt was not charged. Repeat the request after the previous one responds.
Versions and changelog
The API version is in the path: /v1/. Every release is described in the changelog: what changed in the API, webhooks, the widget and error codes, whether there are breaking changes and what to do in the integration.
Integration support
On working days from 10:00 to 18:00 Moscow time — tickets in the personal account, Telegram and email. Round-the-clock support with an SLA is under a separate contract. In your request, state sessionId and the scenario — the answer will come faster.
400 invalid schema 400 unknown or not allowed checkers 401 access denied 404 run not found 409 session is busy failed suspicious expired skipped unavailable message: the request is rejected entirely, nothing changes in the session, and the attempt is not charged. A check result is a normal response 200, where the reason for rejection is in status, errors or outcome. bad image, text fields not visible etc.) are covered on the page OCR API and SDK. Connecting the KYC API is an evening of a developer's time for the first request and a few days for the webhook, rejection handling and tests on your data. The organisational steps are on our side.
You pay for checks, not for connecting. Packages can be used up at any pace. The test period is 1 month.
Calculate the cost
The project «Development of a multimodal system using artificial intelligence "Neuromed" for managing the diagnostic processes of a clinic on the basis of the "Neurovision" computer vision platform» is supported by the Innovation Promotion Foundation within the federal project «Domestic Solutions»
The Neurovision computer vision platform is registered with Rospatent (certificate No. 2023661508) and included in the Russian Software Registry (entry No. 19972 of 13.11.2023)
The right to use the Platform is granted under a licence agreement concluded by Neurovision with its customers
Tell us which checks you need — documents, AML database checks or both — the monthly volume and where the service should run. We will give you access to the personal account and help with the first request.
Can't put your request into words? Book a call and our team will contact you at a convenient time
Book a callThe company is included in the register of IT companies and the register of personal data operators of the Russian Ministry of Digital Development.
Address: Moscow, Presnenskaya Embankment 12 — Moscow City business centre, Federation Tower. Nearest metro stations: Delovoy Tsentr and Mezhdunarodnaya.
How to build customer checks, choose a deployment model and not lose users at verification — in our blog. Data protection throughout the verification process is covered in the article on KYC and personal data.
Document recognition with anti-fraud checks, a selfie and a liveness check as steps of a KYC session, as well as AML checks of an individual against state registers and sanctions lists. Everything works through one REST API with one token. For websites and mobile browsers there is a ready-made Web SDK.
The KYC API works with images: a document, a selfie, face matching, with the result in the KYC session. The AML API checks a person by data — full name, date of birth, passport — without uploading a document: the /kyc/checks/run and /kyc/checks/result methods. They can be linked: database checks are launched on the recognised document data of the same session.
In two steps. The KYC API recognises the passport from a photo and checks the image for editing, a photo of a screen and a printout. The passportVerification AML check compares the series, number and issue date with Ministry of Internal Affairs data, and taxIdLookup gets the taxpayer ID (INN) by passport.
There are no native iOS and Android SDKs at the moment. The Web SDK works in mobile browsers and opens inside an app via WebView or the built-in browser, so verification can be embedded in a mobile app too. One limitation — the widget cannot be embedded in someone else's iframe: the browser will block the camera.
There are no separate server libraries: the API works over plain HTTP, so any language will do. The documentation has ready-made Python scripts, and this page has cURL and Python examples.
Both ways are available. For a KYC session a webhook to the callback URL from the scenario is more convenient; if needed, the status is requested by sessionId or clientKey. The result of AML checks without a session is fetched by polling /kyc/checks/result every 5–10 seconds.
With a permanent token from the «Access» section of the personal account or a temporary JWT issued by the /user/login method. A permanent token is more convenient for server-side integration; it is passed in the token field of the request body. Without a token the API responds 401 access denied.
Yes, we give test access for 1 month — with a personal account, a token and the documentation. Leave a request at the bottom of the page. You can see how verification looks for the user in the demo.
The tariff does not limit request frequency: a package can be used up at any pace, and after it runs out the service is not blocked. Requests to one KYC session are processed one by one. We discuss the expected load at the start of test access.
A KYC session with document recognition and anti-fraud checks — from 16 ₽, an AML check against a state register — 5 ₽. A check that lacked data is not charged. The exact price depends on the scenario and volume — the price matrix calculates it.
Yes. The platform is installed in your perimeter as a set of Docker containers, and NeuroVision engineers perform the installation and updates. After installation it works without the internet, and the API methods stay the same.
The kyc/session/erase method destroys the personal data of one session or of all of the user's sessions by clientUser. Support handles integration questions: tickets in the personal account, Telegram and email — contacts are in the documentation.