Platform User Manual

The NeuroVision™ platform is a suite of computer vision solutions for KYC/AML, facial recognition, and video analytics.
Below is a practical guide for operators and administrators: from registration and statistics to “Facial Recognition,” access tokens, and the complete KYC loop.

For integration via API/Web SDK, see the links within the relevant sections.


Personal Account

Registration and Login

The user registers using e‑mail. To register, you need an *invite code* — this is provided by your administrator or a representative of NeuroVision.

After logging in, the user is taken to their personal account.

*Registration and login to the platform*


“Statistics” Section (KYC Dashboard)

One of the main sections of the Personal Account is Statistics. Key indicators, filters, and settings are located here. For new accounts, the counters are zero.

*Consolidated Dashboard*

KYC Dashboard Composition:

  1. Percentage of successful/declined sessions — for the selected interval and scenario.
  2. Error Distribution — A “pie chart” showing the proportions of error types (e.g., “fields not visible,” “screen/printout,” etc.).
  3. Success by attempts — a “pie” showing the proportion of sessions that were successful on the 1st, 2nd, 3rd attempt, etc.
  4. Daily dynamics — bar chart: the number and proportion of successful/unsuccessful sessions by date.

Statistics are designed for self-analysis without third-party BI tools: filter and group data right here.


Working with Faces

This block combines three areas: Data Sources, Person Lists, and Operation History (Face search).

Data Sources

Sources are channels through which the NeuroVision™ platform receives images/video streams: surveillance cameras, photo files, archive videos.

*Data Sources Section*

Adding a New Source

  1. Open Data SourcesAdd New Source.
  2. Specify:
  • Source Name
  • Parameters for checking faces for additional features (if necessary)
  1. Click Create source.

Source Groups

  • Create groups to combine sources by location/project.

View and Status

  • Visible in the list: activity, basic statistics, status.

Lists of Persons

The Person Lists section is key: it stores the database of people that the system recognizes.

*Lists, cards, and search by faces*

Operations with lists and persons

  • Add a person: upload a photo (one or more), enter the details.
  • Import from multiple files — bulk addition.
  • Edit card: replace photo, update fields, find similar, move to another list.
  • Deletion: one person at a time or in a batch.

Analytics and Alerts

  • Configure events.
  • Use aggregated traffic and activity analytics.

Operation History (Face search)

Operation history is a log of recognition events and actions in the admin panel.

*Log of recognitions and actions*

What’s available

  • View history with filters by sources, groups, dates, person.
  • Navigate to the person/source card, navigate through related objects.

Access Tokens

Tokens are used to authenticate/authorize requests to the API.

*Access Tokens Section*

Create Token

  1. Access TokensCreate new token.
  2. Specify the name, expiration date (if needed), permissions.
  3. Save.

View/Edit/Delete

  • List of tokens; click to edit/delete.

How to pass the token Feature for endpoints: the token can be (and is often more convenient to) passed in the request body as a token field. Example:

# Endpoint URL
url = "https://api.neuro-vision.ru/v1/kyc/process"

# Parameters for KYCDocument
data = {
    "token": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",        # token is passed in the body
    "schemaId": "ca30efc0-9202-11f0-ad12-90496423b317",
    "mode": "sync",                                    # or "async"
}

For a complete specification, see the relevant API sections. Any variant (header/body) is acceptable for most endpoints, but the token field is often more convenient in the multipart/form-data format.

Important

  • Store tokens as secrets, do not share with third parties, and do not publish.

Help Center

*Support and notifications*

  • Support — support contacts, knowledge base (FAQ/articles/videos).
  • Notifications — system messages about updates and scheduled maintenance.
  • Create Issue — support tickets with files and status tracking.

KYC (Know Your Customer) / AML

The main section for working with incoming and received requests.

*KYC/AML Working Sections*

KYC Logs (online journal)

In real-time mode, KYC Logs display incoming sessions. Each “tile” represents a session collected according to a configured scenario (a combination of steps: document(s), selfie, liveness).

What is visible on the right in the logs:

  • Result for **document**: recognized type, **OCR fields** with confidence levels, authenticity status.
  • Anti-fraud checks: MRZ and checksums, signs of screen/printout/editing, stamps/signatures, etc.
  • Result for **selfie**: that it is a **real selfie**, **document in hand** (if needed), correct link with the document from step 1.
  • Face Matching: comparison of faces between selfies and documents (including “selfie with document”); similarity scores.
  • Database checks (if connected): Ministry of Internal Affairs, Federal Bailiff Service, etc.
  • If unsuccessful — cause and problem analysis.

The result of the work is available in JSON (the structure matches the API response). The number of allowed failed shooting attempts is configurable. Blacklist blocking (by face) is available.

*Adding session manually for tests/manual verification*

KYC Reports

History of all sessions without realtime updates — for viewing, filtering, and exporting (CSV).

Filters: by date, status, OCR values (full name/number/city, etc.), by errors, by scenario.

*Filtering and Export to CSV*

KYC Editor (script editor)

The editor configures KYC flow scenarios — any combination of documents, selfies, and (optionally) liveness.

*List of created scenarios*

General Script Properties

  • Schema ID (schemaId) — the schema identifier, use in API/SDK.
  • Secret key — for encrypting notifications/callbacks.
  • Mobile redirect URL on success — where to redirect after a successful session.
  • Client Persons List — a list from the “Persons” section, where recognized clients are added for subsequent searching.
  • Blacklist of persons — a list that, if matched, blocks the session.
  • Critical errors before blocking — e.g., 3. This is a protection against “brute-forcing” of fraudulent images (probabilistic models).
  • Session data storage time (in days)0 = infinite.
  • Session lifetime before freezing (min.) — after this time, new images cannot be added.
  • Flags:
  • Block if two different documents are encountered in one step.
  • Block if the same person submitted the same document type with different data (fraud search by history).
  • Match the issuing authority with the unit code database (increase confidence).
  • Permitted age — range (by date of birth from the document).

*Notification settings (callback)*

Callback (notifications to your backend)

  • Backend Callback URL — the address to which notifications about the session’s progress/outcome will be sent.
  • Flags:
  • Encrypt POST body with a secret key;
  • Do not send personal data (statuses only);
  • Notify only on finalization (no intermediate statuses);
  • Send DB checks as they become ready.

Verification Steps

*Step #1 — Document(s)*

  • Select the document type(s) (passport/ID/driver’s license/…) and countries.
  • Enable the necessary quality checks/anti-fraud measures, for example:
  • document is fully visible;
  • MRZ processing (do not skip without MRZ);
  • edit traces (isEdited);
  • screenshot (isDisplay), mobile device;
  • xerocopy/printout;
  • logical inconsistencies of fields;
  • glare/blur/age;
  • signature/seal/mandatory elements, etc.
  • Document frame for WebSDK on weak devices — vertical or horizontal.

*Example of step settings for documents*

*Step #2 — selfie (or selfie with document)*

  • Checks:
  • Image not modified, not a “screenshot”;
  • Document visible in selfie (if required);
  • Age/gender by face (and comparison with document);
  • Deepfake/Synthetic Media — protection against face swapping;
  • General quality requirements (sharpness, lighting, etc.).

*Example selfie step settings*

WebSDK configuration (widget parameters, clientKey, callbacks) is described in detail in the Web SDK section; details are not duplicated in the user guide.

KYC Links (One-Time Links)

Section for generating one-time links for KYC completion:

  • Select a scenario, a time interval for the link’s life, and the number of links (1…1000).
  • A list of created links will be displayed at the bottom with a status indicator (success/failure/open, etc.).

*One-time link generation*


Version Notes

Functions and interfaces may vary depending on the platform version and your environment settings. For clarification, please contact your administrator or support.