Platform User Guide

The NV Global™ platform is a set of computer vision solutions for KYC/AML, face workflows, and video analytics.
Below is a practical guide for operators and administrators: from registration and statistics to “Working with faces,” access tokens, and the full KYC workflow.

For integration via API/Web SDK see the links inside the corresponding sections.


Personal account

Registration and login

A user registers via e-mail. To register you need an *invite code* — it is issued by your administrator or a representative of NV Global.

After logging in, the user enters the personal account.

*Registration and login to the platform*


“Statistics” section (KYC dashboard)

One of the main sections of the account is Statistics. It contains key metrics, filters, and settings. For new accounts all counters are zero.

*Summary dashboard*

KYC dashboard structure:

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

The statistics are designed for self-analysis without external BI tools: filter and group the data right here.


Working with faces

This block combines three areas: Data sources, Person lists, and History of operations (Face search).

Data sources

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

*“Data sources” section*

Adding a new source

  1. Open Data sourcesAdd new source.
  2. Specify:
  • Source name
  • Face check parameters for additional attributes (if needed)
  1. Click Create source.

Source groups

  • Create groups to organize sources by locations/projects.

View and status

  • The list shows: activity, basic statistics, state.

Person lists

The Person lists section is key: it stores the database of people recognized by the system.

*Lists, cards, and face search*

Operations with lists and persons

  • Add a person: upload photo(s), fill in the data.
  • Import from multiple files — bulk addition.
  • Edit card: replace photo, update fields, find similar, move to another list.
  • Delete: individually or in batch.

Analytics and alerts

  • Configure events.
  • Use aggregated analytics of visits and activity.

History of operations is a log of recognition events and admin-panel actions.

*Log of recognitions and actions*

What is available

  • View timeline with filters by sources, groups, dates, person.
  • Navigate to the person/source card, browse related objects.

Access Tokens

Tokens are used for authentication/authorization of API requests.

*“Access Tokens” section*

Create a token

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

View/edit/delete

  • Token list; click to edit/delete.

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

# Endpoint URL
url = "https://api.enface.ai/v1/kyc/process"

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

For the full specification see the corresponding API sections. In most endpoints any option (header/body) is acceptable, but in multipart/form-data the token field is often more convenient.

Important

  • Store tokens as secrets, do not share them 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 maintenance.
  • Create Issue — support tickets with file attachments and status tracking.

KYC (Know Your Customer) / AML

The main section for working with incoming and processed requests.

*Working sections of KYC/AML*

KYC Logs (online log)

In real time, incoming sessions are displayed in KYC Logs. Each “tile” is a session assembled according to the configured scenario (a combination of steps: document(s), selfie, liveness).

What is visible on the right side of the logs:

  • Result for the 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 the selfie: that it is a real selfie, document in hand (if required), correct link with the document from step 1.
  • Face Matching: comparison of faces between the selfie and documents (including “selfie with document”); similarity values.
  • Database checks (if enabled): Department of Homeland Security, Federal Bureau of Investigation, etc.
  • In case of failure — reason and issue analysis.

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

*Manual session addition for tests/manual verification*

KYC Reports (reports)

The history of all sessions without realtime updates — for viewing, filtering, and export (CSV).

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

*Filtering and export to CSV*

KYC Editor (scenario editor)

The editor allows configuring KYC scenarios — any combinations of documents, selfies, and (optionally) liveness.

*List of created scenarios*

General scenario properties

  • Scenario ID (schemaId) — identifier of the schema, use it in API/SDK.
  • Secret key — for encrypting notifications/callbacks.
  • Mobile redirect URL upon success — where to redirect after a successful session.
  • Client face list — a list from the “Persons” section where recognized clients are added for subsequent search.
  • Blacklist of faces — a list whose match blocks the session.
  • Critical errors before blocking — e.g., 3. This protects against brute-forcing fraudulent images (probabilistic models).
  • Session data retention period (in days)0 = unlimited.
  • Session lifetime before freezing (min.) — after expiration, new images cannot be added.
  • Flags:
  • Block if two different documents appear in one step.
  • Block if one person submitted the same document type with different data (fraud history detection).
  • Match the issuing authority with the department code database (increases confidence).
  • Allowed age — range (based on the date of birth in the document).

*Notification settings (callback)*

Callback (notifications to your backend)

  • Backend Callback URL — the address to which notifications about the session progress/result are sent.
  • Flags:
  • Encrypt POST body with the secret key;
  • Do not send personal data (statuses only);
  • Notify only upon finalization (no intermediate statuses);
  • Send database check results as they become available.

Verification steps (Steps)

*Step #1 — document(s)*

  • Select document type(s) (passport/ID/driver license/…) and countries.
  • Enable required quality/anti-fraud checks, for example:
  • the document is fully visible;
  • MRZ processing (do not allow skipping MRZ);
  • editing traces (isEdited);
  • screen photo (isDisplay), mobile device;
  • photocopy/printout;
  • logical inconsistencies between fields;
  • glare/blurriness/wear;
  • signature/stamp/mandatory elements, etc.
  • Document frame for WebSDK on weak devices — vertical or horizontal.

*Example of document step settings*

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

  • Checks:
  • Image not modified, not a “screen photo”;
  • Document visible in the selfie (if required);
  • Age/gender by face (and comparison with the document);
  • Deepfake/synthetic detection — protection against face spoofing;
  • General quality requirements (sharpness, lighting, etc.).

*Example of 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.

Section for generating one-time links for passing KYC:

  • Select the scenario, lifetime interval for the link, number of links (1…1000).
  • Below you will see a list of created links with a status indicator (success/failure/opened, etc.).

*Generating one-time links*


Notes on versions

Features and interfaces may differ depending on platform version and your environment settings. For clarifications, contact your administrator or support.