FAQ

The NV Global KYC platform allows companies to remotely verify user identities using document and facial recognition. It automates the KYC (Know Your Customer) process, combining document scanning, biometric verification, and other checks for fast and accurate identity confirmation.

The platform recognizes passports, national ID cards, driver's licenses, and other official documents from many countries. The specific list of supported documents is regularly updated – before integration, it is recommended to clarify whether the system covers documents from your country and of the required type. The list of supported documents is available at the link: [

If the document you need is not yet supported, you can contact NV Global support. The team will be able to assess the possibility of training the system on this document and release an update. Adding a new document type usually requires time for data collection and model retraining, but it is possible within the framework of cooperation.

It is recommended to photograph the document in good lighting, without flash and glare, so that all important areas (photo, stamps, numbers) are fully visible. Selfies should be taken with a good quality camera, in sufficient lighting, looking directly into the camera with a neutral facial expression – this will increase recognition accuracy and reduce the likelihood of errors.

The platform is by default oriented towards working with photos of original documents. If anti-fraud checks for photocopies and printouts (both black and white and color) are enabled, then such images may be recognized as suspicious and flagged with errors such as "image printed," "black and white image," or "image edited." However, if necessary, these checks can be disabled in the scenario editor. In this case, the system will accept high-quality copies and scanned documents (including printouts and Xerox copies) without issues, provided they meet the requirements for resolution, completeness, field visibility, and other parameters. To use copies, ensure that the corresponding anti-fraud rules are disabled in the verification scenario.

On NV Global servers, a full document check (including upload, recognition, field extraction, verification, and face matching) takes an average of 500–600 milliseconds, and in some cases, even less than half a second. This is achieved through an optimized architecture and high-performance neural networks. On the demonstration version servers (in demo mode), a similar check can take up to 5 seconds, which is due to limitations in computing resources and background loading. If the Liveness check (authenticity check) is included in the scenario, the total verification time may increase. In this case, the time for the user to pass the Liveness check ranges from a few seconds to one minute, depending on the shooting quality, lighting conditions, and the user's reaction speed.

A user can upload a document photo from a file, which is allowed by the platform. However, for the face verification stage (including Liveness), the use of a camera is mandatory. This is necessary to confirm liveness and exclude spoofing attempts – the system must ensure that it is a live person in front of it, not an image. Nevertheless, for photographing documents, we strongly recommend using the built-in camera component – WebSDK. This significantly reduces the risk of fraud. If anti-fraud checks within the current scenario are not critical, and the scenario allows uploading files without protection against falsification, then the user can provide document images directly from the gallery or by uploading a file.

The system accepts images exclusively in JPEG or PNG formats. Files in other formats (e.g., HEIC, WEBP, PDF, etc.) will be rejected. Image size requirements apply not to the entire file, but to the size of the object in the image: The document in the photo must occupy at least 200 pixels on its larger side (width or height). If it is smaller, the system will return the error "too small image" or "document too small" because it will not be able to extract data correctly.

The user's face (e.g., in a selfie or document) must be at least 30×30 pixels. Smaller faces cannot be analyzed and recognized properly and will lead to the error "face too small".

It is also important to avoid strong compression, blurriness, and poor lighting – such defects can degrade OCR quality and reduce the accuracy of face comparison.

NV Global can automatically recognize which document was uploaded (e.g., passport or driver's license, and from which country, if the format is unique). You don't need to manually select the type – just upload the photo, and the algorithm will classify the document itself. However, in some cases (if documents of different types are very similar), the system may require specifying the type in the verification scheme settings.

If the system incorrectly recognized the text on the document, it is likely that the image quality was insufficient (glare, blurriness). In such a situation, it is better to take a new photo of the document with better quality and try again – this most often solves the problem. If the recognition error repeats on a clear image, you can report it to support, and in the meantime, manually correct this data outside the system.

The NV Global algorithm analyzes image quality and the presence of mandatory elements (stamp, signature, owner's photo) and can detect copies or fakes. However, a full authentication of security holograms or UV markings from a regular photograph is difficult. Thus, the system identifies obvious discrepancies (document format, fake elements) but does not guarantee the detection of all types of fakes, especially if they are not reflected in the photo.

If the identity document consists of two pages (like an internal passport with registration), the platform can process both pages sequentially. In the schema settings, you can specify the need for an additional step – first, a scan of the main page, then, for example, the registration page. The user will be prompted to upload both sides, and the system will combine this data for a complete verification.

NV Global can read text in Russian and other languages with the Cyrillic alphabet, as well as in Latin script (English, French, etc.), and in many other languages represented in documents. The system is trained on international samples, so it automatically extracts fields (full name, date of birth, document number, etc.) regardless of the language – the only important thing is that the document is on the list of supported formats.

Enface platform's Liveness check is used to confirm that a real living person is in front of the camera, not a photo, video, or other deception. We use three modes of active Liveness check: — Simple tasks — the user performs individual commands (e.g., turn head left or right, blink, look at a specific point). — Complex tasks — tasks are complicated and follow in quick succession (e.g., combinations of turns and gazes) for deeper verification. — Circular head movement — the user moves their head in a circle, similar to the initial Face ID setup on an iPhone. This method allows for collecting the maximum amount of 3D facial information.

During task execution, the system takes a series of snapshots (key frames) which are automatically sent to the server. On the server, these images are analyzed using neural network models that determine the presence of signs of a living person (micro-movements, skin texture, depth, etc.). Based on the analysis of all frames, the system makes a final decision on passing the Liveness check.

If the liveness check fails, the system could not verify that it was a live person (e.g., due to poor lighting or failure to perform actions). It is recommended to ask the user to repeat the liveness check: look directly into the camera, do not cover your face, and perform the required action. The system usually allows several attempts. If it fails repeatedly, it may be possible to switch to an alternative identification method (e.g., manual verification by an operator).

The Liveness test is recommended to ensure that the document is presented by its owner at the time of verification. Nevertheless, the platform is flexible – at the client's request, a simplified KYC scheme can be used, which includes only document upload and recognition. In this case, the user's face is not confirmed via selfie, which somewhat increases the risks of fraud, so disabling Liveness makes sense only in low-risk scenarios.

Built-in Liveness mechanisms check for natural behavior: they can distinguish a live face from a static photograph or a video playback. If, for example, an attacker wears a silicone mask or tries to show another person's video on the camera screen, the system will very likely recognize this as an attempted deception and will not count the liveness check.

NV Global implements a number of anti-fraud mechanisms: it checks the document for forgery (for example, by recognizing a copy or photomontage), compares facial biometrics with those already known in the system (to identify if the same person has tried to register under a different name), and also monitors the sequence of user actions. Any deviations (black and white copy of the document, mismatch between the face and data, suspiciously frequent attempts, etc.) are flagged and can serve as a signal for rejection or additional verification.

The label [fraud] image printed indicates the detection of signs of a copy: the system determined that the document is likely not an original, but a scan or photocopy (e.g., black and white or color). This error serves as a signal of possible fraud. It is recommended to request a photo of the original document from the user – with real security features – to pass the verification.

The platform supports the storage of biometric facial templates of users who have successfully passed verification. During new KYC attempts, the system automatically compares the face with the database of already known embeddings.

If the face has been encountered in previous sessions—even under a different name, with a different document, or in a different context—the system will detect a match. This allows for timely identification of repeated KYC attempts with data substitution.

In the interface, upon a match, the system highlights the current session ID in red, which is a direct indicator that the person has already appeared in the system. Clicking on this ID opens the history of all sessions in which this face was detected, with the ability to view and analyze them.

The platform supports a built-in mechanism for adding faces to a blacklist. This allows for the automatic blocking of verification attempts by the same person, even if they use different documents or personal data.

To do this, click on the icon with a crossed-out circle in the session viewing interface. After that, the face detected in this session will be added to the blacklist. During subsequent verification attempts:

• If the face matches a previously blocked one, the session will be automatically rejected.
• This will be accompanied by the label "User on blacklist" in the interface.

Blacklist in the interface

This approach is effective against repeated fraudulent attempts with data substitution, as it relies on biometrics rather than just document details. The mechanism does not require additional implementation from the client – it works out of the box.

All technical documentation is available on the NV Global portal: it describes REST API endpoints, request and response formats, examples, and errors. For ease of integration, you can use Swagger/UI at or read the guide on GitBook. It is advisable to familiarize yourself with these materials before starting the integration.

To gain access to the platform's API, you need to:

Request a unique promo code from the NV Global administrator.

Register on the platform (via the web interface) using this promo code.

After registration, you will get access to your personal account, where you can:

    Manage connections,

    Obtain tokens,

    Configure scenarios and integration,

    View statistics and request status.

All access parameters (tokens, identifiers, configurations) are issued automatically through the platform – we do not transfer anything manually, including any clientKey or secret keys.

Usually, a Non-Disclosure Agreement (NDA) is concluded before this. After that, you can start using the test access. Load parameters, limits, and scenario restrictions are discussed individually.

After a full contract is signed, production access will be granted, with the possibility of connecting to an isolated environment, dedicated servers, and custom SLA parameters.

The general process is as follows: your backend calls the NV Global API method, passing the document image and the user's selfie/video (either in sequential requests or within a single session, depending on the chosen scheme). The NV Global server processes the data (OCR, face comparison, liveness) and returns a structure with the results – the verification status and extracted data. In the integration, you will need to implement sending the data, receiving the response, and parsing the results (e.g., filling out a user form with data from the passport, processing the "success/failure" status).

The NV Global platform supports various integration schemes, both using a ready-made widget and through direct API requests.

If you use the web widget, everything happens automatically: it sends all data (document, selfie, liveness) in stages and in the correct sequence, creating a single session.

With direct API integration, you can choose between several approaches:

• In one request — some scenarios allow sending the document and face simultaneously (e.g., with a static selfie with the document).
• In stages — the sequential scheme is more often used, where:
• A session is initiated,
• A document photo is sent,
• A selfie is sent separately.

Both synchronous and asynchronous processing modes are supported: you can receive the result immediately or via webhook/polling.

This approach provides maximum flexibility — you can optimize UX, adapt to specific scenarios (e.g., document only, selfie only, selfie with document, liveness, etc.), and precisely control the verification logic.

When initiating a check, the system assigns a unique sessionId to the request. You need to use it for further requests: for example, to link a selfie to an already sent document, or to request the status/result of the check. SessionId helps to match responses with a specific identification attempt, especially if you have checks running in parallel for different users.

SessionId is uniquely associated with a specific KYC attempt. If one user fails and the check starts over (or another user passes KYC), a new sessionId is generated. Reusing an old identifier is unacceptable – it will lead to data mixing. Thus, each check has its own session, and completed or expired sessionIds are not used further.

You can periodically request the KYC session status by sessionId until you receive a final answer (SUCCESS/FAILED). However, it is more convenient to set up a callback URL: then, after the check is completed, NV Global will send a notification with the result to your server itself. The webhook notification will contain the sessionId and the final status (and data), which eliminates the need for polling. The method of receiving the result is agreed upon during integration.

A complete list of all errors and codes that the system may return during the KYC verification process is available in a special directory — the "KYC errors" section.

• The directory contains:
• Verification code (e.g., [general] bad image, [fraud] mobile device);
• Error description — what exactly happened;
• Comment — how to interpret it from the user's perspective;
• Technology description — which algorithms were triggered and why the error occurred.

## Examples from the directory

• [general] bad image — the file is not an image (e.g., not JPEG/PNG or corrupted);
• [document] text fields not visible — key document fields could not be read;
• [fraud] mobile device — the document or selfie was taken from a smartphone screen.

The directory is presented in a tabular format and is regularly updated. It is used by both technical specialists and support operators.

If an unknown code appears during integration or verification that is not in the directory, you can always contact support — we will provide its interpretation and recommendations for handling it.

Upon successful document recognition, the platform returns personal data in a structured JSON format, where each field contains:

• Title (title) — for example, Surname, Date of Birth, Document Number;
• Value (value);
• Confidence level (conf);
• Validity status (e.g., isMismatch, isUnreadable, isEdited);
• Image index (imageIndex), if there are multiple images.

The format is universal and suitable for both foreign documents (e.g., ePassport, ID cards) and Russian documents (e.g., Russian Federation passport). Example structure for a foreign passport:

{
  "title": "Given name(s)",
  "value": "EDGAR ANDRES",
  "conf": "high"
}

Similarly, for a Russian passport:

{
  "title": "Father's name",
  "value": "ДМИТРИЕВНА",
  "conf": "high"
}

Additionally, the response may include:

• Machine-readable zone (MRZ Strings);
• Date fields in ISO format (valueUTC);
• Specialized fields such as Issuing authority, Nationality, Place of Birth;
• Authenticity check metadata (markers isPrinted, isEdited, isXerocopy, isMobile, etc.).

The JSON response also includes blocks with fraud checks and face matching results, with similarity percentages between the document, selfie, and selfie with the document.

In such cases, the final status "FAILED" indicates that the identification algorithm considered the check to be unsuccessful. For example, the neural network might have recognized the text but considered its authenticity to be low (low confidence) – in this case, the system prefers to refuse, even though the data looks correct. Another example is that the user's face matched the photo, but Liveness was not passed, or the document was read but recognized as invalid. Thus, even with filled-in data, the platform may return a refusal if at least one of the verification criteria is not met.

Instead of developing your own interface, you can use a ready-made widget from NV Global. It is an embedded component that displays all the necessary steps (passport upload, selfie, liveness) to the user in a clear way. The widget is easily integrated into your web page with a few lines of code and automatically interacts with the API – you don't need to write the data exchange logic with the server yourself.

The process is very simple: you add a JS-library connection for the widget to the page (`). Then you call the window.KYCWidget.setupKYC({…}) method, specifying your verification's schemaId and clientKey (if required). In React or other frameworks, you can install the kyc-widget` package from npm. The documentation provides examples: it's enough to launch the widget opening method on a button click – everything else happens automatically.

Currently, NV Global offers a web widget that can also be used in mobile applications (e.g., via WebView or an embedded browser within the app). Separate Android/iOS libraries are not directly provided yet, however, the web solution is adaptive and supports smartphone cameras. Thus, even without a native SDK, you can implement the KYC process on mobile platforms using the existing web component.

The widget interface is neutral and can be integrated into your website as part of a page. You can place your company logo next to it or in the header. The widget also supports some style settings (e.g., you can override CSS to change the main colors to match your brand). Full white-labeling of the interface is limited by the widget's capabilities, but basic design customization is possible to ensure the KYC form seamlessly fits into your product.

The platform can have several KYC schemes (scenarios) – for example, a simplified check of only a passport, a full check of passport + selfie, a check with additional documents, etc. Each scheme is assigned a unique schemaId. When connecting the widget, you need to specify the schemaId that corresponds to the desired process. This identifier will be provided to you by the NV Global integration manager, or you can find it in your personal account when configuring the system.

When integrating a widget or making direct API requests, the clientKey can be used to confirm your access rights. This key is linked to your account and issued by NV Global for your applications. It is usually obtained along with other integration data (as test and production keys). In some cases, the widget may work without explicitly specifying the clientKey (schemaId is sufficient if the key is bound on the server side). Always follow the documentation instructions regarding the use of clientKey.

This error message appears when the system does not detect all the required zones in the document image. For example, the owner's signature, the issuing authority's stamp, or other mandatory passport/ID details may be missing. In practice, this error is often caused by a part of the document being out of frame or obscured. It is recommended to take a new photo that shows the entire document completely – then the verification will be successful if all elements are in place.

The bad_image error means that the uploaded file cannot be processed as an image.

• Main reasons for the error:
• The file is not an image at all (e.g., PDF, TXT, DOCX, or another invalid extension);
• The image format is not supported — only JPEG and PNG are allowed;
• The file is corrupted or encoded with errors;
• In rare cases, the image is so blurry, dark, or distorted that the system cannot start processing.
• What to do to fix the error?
• Make sure you are uploading an image in JPEG or PNG format;
• The file size is not zero and it is not corrupted;
• The document or face is clearly visible in the image, without blurriness, distortion, or excessive darkness.

If the file is valid but the error persists, it is recommended to re-photograph the object and try uploading again.

The bad_face_matching error indicates a failed biometric verification:

• The system compared the user's face image with the photo in the document and concluded that they are different people (or the degree of similarity is too low).
• Simply put, the algorithm did not confirm that the selfie belongs to the document owner.

## Reasons for the error:

• A genuinely different person;
• Poor photo quality (blurriness, shadows, angle, lighting);
• Significant differences in appearance between the photo in the document and the selfie.

## Recommendation:
If the user is confident that everything is correct, they should try again with different photos – perhaps the previous ones were unclear or taken from a different angle.

The system returns several key statuses based on the results of identity and document verification. Each status reflects the current state or outcome of the verification:

• success — verification completed successfully. All verification stages are completed, data is confirmed, the face matches the document, and no errors were found.
• failed — verification failed. One or more verification stages ended with an error (e.g., the document is invalid, the face does not match, or signs of forgery were detected).
• idle — the session remained incomplete. The user did not complete the process: did not upload a selfie, closed the window prematurely, did not pass liveness, etc.
• suspicious — the session was marked as suspicious. This can happen if:
• The user is found on a blacklist;
• A repeated face with different data was detected (e.g., one face — two different passports);
• Within a single session, there were attempts to upload several different documents with different faces (a sign of fraud).

Additionally, the API response structure may contain intermediate component statuses (e.g., ocr, fraud, face_matching) — these allow for analysis of at which stage errors occurred, but the final session status will be one of the four listed above.

The idle status appears if the user has started a process but has not provided all the data.

• Typical situations when idle occurs:
• The user uploaded a document but did not take a selfie;
• Did not pass the Liveness stage;
• Closed the window or left the page before completing all steps;
• Did not confirm or send the required information.
• What it means for integration:
• The final check did not occur — the status is neither a success nor an error;
• Usually, such sessions are considered abandoned and closed by timeout;
• You can decide for yourself how long to wait for the user and what to do with such sessions (e.g., notify the user or delete the session).

If the KYC platform response returns a "failed" status, it means that one or more parts of the verification were not successfully passed.

• Where to find the reason for rejection:
• The results array contains individual objects for each verification type (document, selfie, faces, etc.).
• Each element has an errors field — a list of error codes.

{
  "errors": [
    "[fraud] mobile device",
    "[document] text fields not visible"
  ]
}

This means:

• It was detected that the document or selfie was photographed from a mobile device screen ([fraud] mobile device);
• Important document fields, such as place of birth, were not recognized in the image ([document] text fields not visible).
• Verification of anti-fraud results (checks):

«`
{
"caption": "fraud",
"items": [
{
"status": "failed",
"caption": "isMobile",
"confidence": 0.947
}
]
}
«`

This confirms that the mobile device check (isMobile) failed, with high confidence (0.947).

• Document fields and readability status (ocr):

«`
{
"title": "Place of birth",
"value": "…",
"isUnreadable": true
}
«`

This means that the "Place of birth" field could not be recognized, which can also be a critical error depending on the scenario.

• Step-by-step to understand the reason for rejection:
• Check the top-level status field ("status": "failed").
• Examine the nested results — for each type (document, selfie, etc.).
• Look at the errors field within these blocks — it contains the main reasons.
• Look into checks and ocr if you need to understand the details (e.g., which fields are unreadable or what caused suspicion).

For companies with increased security and data privacy requirements, the NV Global platform offers an On-Premise solution – a software package for local deployment within the client's IT infrastructure.

• In this option:
• All images and results are processed and stored solely on the client's side, without accessing external cloud services;
• The system is delivered as a set of Docker containers ready for installation;
• Isolated environments are supported, including a complete lack of internet access.
• Installation process:
• NV Global specialists connect to the client's servers (usually via SSH or a secure channel);
• They install all components, configure the environment, and verify functionality;
• Subsequently, if updates or technical support are needed, the NV Global team can remotely connect to the server and perform upgrades, model updates, or troubleshoot issues.

This solution is suitable for banks, government agencies, medical institutions, and other organizations where data control requirements are critically important.

In the cloud option, the entire infrastructure is supported by the provider: you just need to use the API over the internet, and NV Global handles updates and scaling.

In the On-Premise option, you deploy the system yourself: this ensures maximum autonomy and compliance with security policies, but requires resources for installation, support, and updates.

• Key Differences:
• Location: Cloud version — on NV Global servers, On-Premise — on your servers.
• Data Control: On-Premise provides full control and data isolation.
• Updates and Support: In the cloud, NV Global handles this; On-Premise requires independent or joint maintenance.
• Functionality: The core of the platform is the same; differences lie in the execution location and responsibility for maintenance.

For an On-Premise installation of the NV Global platform, high-performance hardware is required to process images and biometrics in real-time. The minimum and recommended system requirements are listed below.

✅ Minimum requirements:

• CPU: AMD Ryzen 9 3900X (or equivalent with ≥16 threads, AVX2 support)
• GPU: NVIDIA RTX 3090 with 24 GB of video memory, or an NVIDIA card with similar capacity and performance (e.g., A5000, RTX 4080)
• RAM: 64 GB
• Disk: SSD from 1 TB

This minimum configuration ensures comfortable operation under moderate load and a small number of parallel sessions.

✅ Recommended requirements:

• CPU: Intel Core i9-12900KF or equivalent ≥24 threads
• GPU: 2× NVIDIA RTX 3090 (total 48 GB VRAM) or similar cards — for example, 2× A5000, A6000, RTX 4090
• RAM: 128 GB
• Disk: SSD/NVMe from 2 TB
• Network: 1 Gbit/s and above

This configuration allows operation under high load with many parallel requests.

🔁 Redundancy and fault tolerance:

• For production environments with high SLAs, it is recommended to use two servers:
• A load balancer is configured on both servers, ensuring stability in case of failures and scalability.

On-Premise version updates for the NV Global platform include:

• new versions of neural network models (OCR, anti-fraud, Face Matching, Liveness, etc.);
• updates to infrastructure components (Docker images, API);
• bug fixes and performance improvements.

The update process is organized as follows:

• NV Global company notifies the client about the available update and agrees on the time of implementation.
• NV Global specialists connect to the client's server via a secure channel (e.g., via VPN or according to an agreed corporate procedure).
• The following is performed:
• updating all necessary Docker images and components;
• full testing on the client's side after the update;
• verification of the correct operation of key functions.
• After confirmation, the new version is considered active, and all processes switch to it.

After you deploy the NV Global platform within your network, all checks occur locally.

• Features of complete isolation:
• Internet connection is not required for algorithm operation or data storage – everything remains within your organization's perimeter.
• All image and biometric processing is carried out on your servers.
• Data does not leave the client's infrastructure.
• When the internet might be needed:
• License activation;
• Downloading updates (can be done in a controlled manner, for example, by temporarily opening access or via offline packages).

Thus, the On-Premise option is suitable for completely isolated environments – for example, in banking or government systems, where maximum autonomy and data protection are required.

NV Global is developing a Digital ID solution, within which a record (digital passport) is created in a distributed system (blockchain) based on KYC results.

• What is a digital passport on the blockchain:
• A unified verified identity profile created after successful KYC completion;
• Stored in a distributed blockchain network — decentralized and immutable;
• Allows for the reuse of verified data across different services without the need for re-identification;
• Can be implemented as a Soulbound NFT token or another digital certificate;
• Recognized by ecosystem partners, facilitating access to various services.

Essentially, it's an add-on to KYC: undergo identification once — receive a digital certificate that can be presented repeatedly.

The "digital passport" project is relatively new, and its integration is carried out in cooperation with interested clients and partners.

• Current status and capabilities:
• Digital ID functionality is being implemented in agreement with clients;
• To connect to the decentralized identity ecosystem, please contact the NV Global team;
• In the future, the system will become publicly available – users will be able to use a unified digital identity when working with various organizations.

The service pricing is flexible:

• For small volumes — pay-as-you-go (e.g., N rubles per identity verification, pay-per-use);
• For large clients — tariff plans with a prepaid number of verifications per month or year (essentially a subscription providing a certain volume of KYC);
• Details of costs and cooperation models are discussed individually in the contract.

Thus, NV Global can offer both pay-per-use and fixed packages — depending on your needs.

The NV Global platform operates on a package model: you purchase a certain number of checks (KYC sessions) that can be used at any time and at any speed, without any monthly, daily, or hourly limits.

For example:

• If you purchased a package of 10,000 checks, you can use them all within one day, or spread them out over a year – there are no time limits.
• The platform does not limit the request frequency, as long as your server or integration can technically handle a high flow.

Thus, all limits are quantitative, not temporal.

If you have exhausted the volume of your purchased check package, nothing critical will happen: the system will continue to process requests as usual.

• You will need to purchase an additional package corresponding to the expected volume of transactions.
• No automatic restrictions, blocks, or disconnections occur — we consciously avoid such scenarios so as not to interfere with your business process.
• You can track usage in advance and receive notifications from your accounting system or NV Global manager.

Thus, exceeding the package is simply a reason for prompt purchase of the next volume, not a risk factor for service stability.

To obtain a report on the number of KYC checks performed for a specific period, simply use the "KYC Reports" tab in your NV Global platform personal account.

In this section, you can:

• select any date range;
• filter sessions by status (success, error, suspicion, incomplete);
• filter by error type or field values;
• view the total number of found sessions;
• download the report in CSV or Excel format – it will include all key data: time, status, username, document type, error (if any), etc.

This allows you to independently track activity, compare statistics with your tariff plan, and analyze the quality and correctness of checks.

Additionally, NV Global generates an official monthly report with the number of checks, which is sent to you for approval and invoicing. If necessary, you can request an extended detailed report – with sessionId, results, and deviation indicators for each session.

Under the NV Global agreement, a package of closing documents is prepared at the end of each reporting period.

• This typically includes an acceptance certificate for services rendered, indicating the number of verifications performed during the month (or other period) according to the accounting system.
• These certificates are then transferred to your authorized representative (e.g., the accounting department) for signature.
• You will receive official documents confirming the volume of KYC services provided, for settlement and reporting purposes.

Many clients first integrate and pilot on a monthly basis to ensure effectiveness.

• After that, a long-term contract is usually concluded – for example, for a year – with fixed terms (often with a reduced cost per check for large volumes).
• If you need a predictable annual plan, you can agree on it with the NV Global manager.
• As a rule, this provides a price advantage compared to monthly payments.

Each KYC session has a lifetime, which is set in the scenario settings.

If a user starts the process but does not complete it (e.g., uploads a document but does not pass the selfie or Liveness check), the session goes into an idle state (incomplete).

After the specified lifetime expires:

• the session automatically receives the status "expired";
• no manual closing is required from your side;
• such sessions are stored in the system and can be viewed in reports as incomplete.

In your business logic, you can set your own waiting timeout for the user (e.g., 15 minutes), and if it is exceeded, you can offer them to start the process again or initiate a new session via API.

Thus, managing the session's active period is part of the scenario constructor, and its duration is easily configurable for specific processes.

The NV Global platform stores all KYC check results indefinitely, including:

• session status (success, failed, idle, suspicious, expired);
• recognized document fields (OCR);
• Face Matching results;
• metadata, errors, fraud checkers, and more.

To access the results at any time, you only need to know the sessionId:

• retrieve all data via API;
• view results and images in your personal account;
• download a report in CSV/Excel.

Original images (documents, selfies, Liveness) are stored for 6 months. After this period, images are automatically deleted or overwritten, but other structured data remains available without restrictions.

For business convenience, you can save key fields yourself (e.g., full name, date of birth, status), but this is not necessary in terms of accessing history – everything can be re-obtained via API.

Immediately after launching the integration, you retain access to NV Global technical support.

Support is divided into two levels:

• 🔹 Basic support (included by default):
• Hours: 5 days a week, from 10:00 to 18:00 Moscow time.
• Communication channels:
• Ticket system in your personal account — the primary and preferred method of contact;
• Telegram chat — for informal or urgent questions (as available);
• Email support — for general or technical inquiries.
• 🔹 Extended support (under contract):
• Hours: 24/7, including weekends and holidays;
• Activated separately, according to SLA: priority line, accelerated response, and monitoring.

📌 Important: in many cases, answers are already available:

• In the documentation, accessible from your personal account;
• Through the bot integrated into the platform or Telegram;
• In the FAQ and error guides.

If you still cannot find an answer, please submit a ticket describing the problem and, if possible, provide the sessionId, your organization's name, or the scenario — this will speed up processing.

After launching the KYC service, you retain full control over its logic and composition. For this, a built-in scenario editor (KYC editor) is used, which is available in the KYC/AML → KYC Editor tab.

Through the editor, you can:

• Create and edit scenarios without involving developers;
• Configure:
• secret key (if callback is used);
• client list (if it is known in advance);
• blacklist of individuals;
• maximum number of critical errors before session blocking;
• session lifetime before freezing (e.g., 15 minutes);
• data retention period (e.g., 0 means indefinitely);
• Activate anti-fraud settings:
• blocking for two different documents in one session;
• blocking for resubmission of documents by the same person but with different data;
• Configure an age filter by date of birth from the passport (e.g., from 16 to 100 years);
• Specify a callback URL for notifications to the client's backend, with the ability to encrypt, filter personal data, and configure sending conditions.

Verification Steps:

• Each scenario consists of one or more verification steps:
• Step 1 — for example, document upload (internal passport, international passport, etc.);
• select the required countries and document types;
• enable checks: machine-readable zone, traces of editing, screen check, mobile device check, photocopy check, insertion check, logic check, etc.
• Step 2 — for example, selfie or selfie with document;
• activate checks: face visibility, age, gender, traces of editing, screen, mobile device, face comparison.

Changes to a scenario take effect immediately after saving — you can adapt KYC to any business logic: from simple to multi-level schemes.

If you notice a slowdown in the platform or API unavailability, please report it to technical support in any convenient way — via ticket, email, or Telegram.

⏱ Basic technical support (by default) operates on weekdays during business hours (Moscow time). We promptly respond to all inquiries, including diagnosing causes and restoring functionality.

📌 Important: the extended 24/7 mode is available only with a separate contract for round-the-clock technical support.

What happens during a failure:

• An automated monitoring system is used, which tracks the performance of all cloud platform components;
• In case of a failure, engineers receive a notification and begin troubleshooting without waiting for a customer inquiry;
• Most failures (if they occur) are resolved within a few minutes — we try to notify customers in advance if it affects their processes.

For On-Premise solutions, diagnostics can be performed jointly with your IT department — if necessary, our engineers connect remotely and help restore access.