Choosing a KYC (Know Your Customer) provider starts with answering the question of what the law requires of this particular business — comparing features in vendor presentations makes sense only after that. Customer identification must be carried out by the organization itself if it is classified as a subject of Article 5 of Federal Law No. 115-FZ of 7 August 2001 “On Combating the Legalization (Laundering) of Proceeds from Crime and the Financing of Terrorism” — it may be delegated only to persons expressly named in the law, and a commercial KYC vendor is not on that list. This directly determines which requirements for a supplier make sense at all: the provider supplies a technical tool; that does not discharge the obligation itself.
For a bank, a microfinance organization (MFO), and a marketplace, this obligation is structured differently and rests on different provisions and deadlines. A bank is entitled to rely on state infrastructure — the Unified Identification and Authentication System (ESIA) and the Unified Biometric System. Microfinance companies have been required to do the same since 1 March 2026; for microcredit companies, this has been postponed until 1 March 2027. For a marketplace, the verification obligation is structured differently: it is assigned to the platform operator and is carried out through a closed list of verification methods.
Where the Choice Starts: Who Is Responsible for the Result of the Check
The circle of obligated persons is defined by Article 5 of 115-FZ — it includes both banks and microfinance organizations — and the obligation to identify the customer itself is established by Article 7(1)(1). The law allows this to be delegated only to expressly named persons: a credit institution may delegate identification to a postal organization, a telecom operator, or an accredited certification center (Article 7(1.5)); professional securities market participants, investment platform operators, management companies, operators of digital financial asset information systems, digital depositories, and insurance organizations may delegate it only to a credit institution (Article 7(1.5-1)); microfinance organizations — also only to a credit institution (Article 7(1.5-2)). Requirements for the credit institutions to which identification may be delegated, and for the delegating MFOs, are set by the Bank of Russia in agreement with the Federal Financial Monitoring Service (Rosfinmonitoring) (Article 7(1.5-3)).
A commercial KYC vendor is not mentioned on this list even once. A technology supplier provides a tool — document recognition, database checks, an anti-fraud loop — while the obligated person before the law and the regulator remains the organization itself. Wording such as “the provider performs identification on the company’s behalf” or “connecting the service satisfies the requirements of 115-FZ” does not match this allocation of responsibility. The obligations of businesses under 115-FZ are covered in detail in the article 115-FZ: What Businesses Are Required to Do and How to Meet the Law’s Requirements.
What the Law Requires of a Bank, an MFO, and a Marketplace
Below — what regulatory framework stands behind each of the three segments and what follows from it for supplier requirements. The three segments cannot be merged into one list: their provisions, deadlines, and even the very availability of the simplified procedure differ.
Bank
Credit institutions and organizations supervised by the Bank of Russia are entitled to identify an individual and a representative of a legal entity without in-person presence — through ESIA and the Unified Biometric System (EBS) under 572-FZ (the law on identification using biometric personal data) (115-FZ, Article 7(5.8)). This right is conditional on a closed list of conditions (115-FZ, Article 7(5.8), paragraphs 2–9). The customer must not be on the list of persons involved in extremism or terrorism or on the UN Security Council lists, there must be no decision of the interdepartmental commission to freeze their funds, and their transactions must not have been suspended by a court. In addition, there must be no suspicions of money laundering and no grounds to believe there is another beneficial owner, no record of unreliable information in the Unified State Register of Legal Entities (EGRUL), and no information on the application of measures under subclauses 5.2 and 11 of the same article.
For some banks, the same thing is already an obligation, not a right: a bank with a universal license that meets the criteria of Article 7(5.7), paragraphs 2–4, and offers the ability to open an account or obtain a ruble loan via its website or mobile app is required to ensure acceptance for service under the procedure of clause 5.8 (115-FZ, Article 7(5.8-1)). The Bank of Russia is entitled to set restrictions for an individual organization on transactions with customers identified this way (Article 7(5.10)).
Remote acceptance for service under this procedure relies on state infrastructure — the Unified Biometric System and ESIA, and they cannot be replaced by a commercial solution: the law names them directly. A KYC provider covers a different task — document recognition and verification, detecting traces of image editing, checks against external databases, liveness checks, and keeping a customer’s check history. The cost of a false rejection here is a lost customer on an expensive acquisition channel; the cost of a miss is operational and regulatory risk.
Microfinance Organization
For MFOs, a similar structure becomes mandatory and rigidly tied to state infrastructure. When remotely accepting an individual customer for service, MFOs are required to identify the customer and their representative using ESIA and the EBS under Article 9 of 572-FZ (115-FZ, Article 7(5.8-2), paragraph 1, introduced by Federal Law No. 41-FZ of 1 April 2025). When remotely concluding each consumer credit (loan) agreement, MFOs are additionally required to ensure authentication of the customer through ESIA and the EBS under Article 10 of 572-FZ — provided that identification at the preceding acceptance for service was already carried out under this same procedure (paragraph 2 of the same clause).
For microfinance companies, this provision is already in effect — since 1 March 2026 (Federal Law No. 41-FZ, Article 16(5)). For microcredit companies (MKK — a type of MFO under Article 2(1)(2.2) of Federal Law No. 151-FZ), application of paragraph 1 of clause 1.5-2, paragraph 2 of clause 1.12-1, and clause 5.8-2 of Article 7 of 115-FZ has been postponed until 1 March 2027 (Federal Law No. 41-FZ, Article 16(6)). These are two different dates for two different types of MFO, and they are easy to confuse when planning an integration.
A separate restriction applies specifically to consumer lending: simplified identification may not be used for the purpose of a microfinance organization concluding a consumer credit (loan) agreement (115-FZ, Article 7(1.12-1), paragraph 2; for MKKs — also postponed until 1 March 2027). An MFO may delegate identification or simplified identification only to a credit institution — for concluding a loan agreement and for updating information, except in this prohibited case (Article 7(1.5-2), paragraph 1).
For an MFO’s remote onboarding, a commercial KYC provider does not substitute for the mandatory procedure through ESIA and the EBS — this follows directly from the provision, without any assessment of the market as a whole. As with a bank, it covers a different task in the same process: checking the authenticity and readability of the document, detecting traces of editing, database checks, signals for risk assessment, and an anti-fraud loop. For an MFO, the cost of a miss is a direct credit loss, while the cost of a false rejection is calculated for the specific business — taking into account the deal cycle and the customer acquisition cost.
Marketplace and Digital Platform
From 1 October 2026, Federal Law No. 289-FZ of 31 July 2025 “On the Platform Economy in the Russian Federation” is in effect (Article 23(1)). The law does not address the obligation to verify information about a partner to every marketplace: it arises for an operator of an intermediary digital platform included in the register (289-FZ, Article 2(9), Article 4(2)), and the verification is carried out when concluding a contract with a partner or a pickup point owner (Article 5(2)).
The verification methods are established by Government Resolution No. 768 of 20 June 2026, and this list is closed: state registers and the public Federal Tax Service (FNS) service for checking professional income tax payer status; ESIA or another information system that meets the requirements of the legislation on information; the SME digital platform; information resources of the foreign applicant’s country of registration (Resolution No. 768, clause 2 of the Rules, Sections III–VI). The operator chooses the method itself, and the verification periods differ: via state registers — up to 5 business days, via ESIA or another information system — one calendar day, via the SME platform — one calendar day, for a foreign applicant — up to 15 business days (clauses 13, 23, 28, 32, 39 of the Rules).
The list is closed, but it describes verification methods, not types of suppliers: there is no “commercial KYC service” class in it simply because the Rules do not operate with such a category. Within the method under Section IV, the law expressly allows two technical implementations — ESIA or another information system and/or computer program that meets the requirements of the legislation on information, information technology, and information protection (Resolution No. 768, clause 24(b)). The condition attached to it is strict: the information about the applicant transmitted to the platform operator as a result of identification and authentication through such a system must have been established by the operator of that system in accordance with the customer identification requirements set by AML/CFT (anti-money laundering and combating the financing of terrorism) legislation (clause 26 of the Rules), and the identification itself takes place on the platform and with the applicant’s consent (clause 25).
Hence the practical conclusion for supplier requirements: the obligation to carry out the verification remains with the platform operator, the operator chooses the method itself from the closed list, and connecting a third-party service does not in itself confirm fulfillment of this obligation. If a supplier positions itself as an implementation of the method under Section IV, it is worth asking them on what basis they consider the condition of clause 26 to be met — this is a question for the system operator, not for the platform.
On a marketplace, a KYC provider can also solve a separate task — checking individual users and reducing fraud risk; this loop does not coincide with the obligation to verify a partner under Article 5 of 289-FZ. These two loops should be separated in the supplier requirements: they should not be merged into one task. A detailed breakdown of 289-FZ is in the article Checking Sellers and Partners on Marketplaces Under 289-FZ.
| Segment | Who is checked | Provision | What the provider covers |
|---|---|---|---|
| Bank | An individual or a legal entity’s representative during remote acceptance for service | 115-FZ, Article 7(5.8), (5.8-1) | Document recognition and verification, image anti-fraud, database checks, liveness — not a replacement for ESIA and the EBS |
| MFO | An individual or a representative during remote onboarding and each consumer credit (loan) agreement | 115-FZ, Article 7(5.8-2) (from 1 March 2026; for MKKs — from 1 March 2027) | The same as for a bank — does not replace ESIA and the EBS where they are mandatory |
| Marketplace | A partner or pickup point owner when concluding a contract | 289-FZ, Article 5(2); Resolution No. 768 | Technical implementation of the method under Section IV — only under the conditions of clauses 24–26 of the Rules; the obligation remains with the operator. Checking individual users and fraud risk is a separate loop |
Which Provider Requirements Are Mandatory and Which Depend on the Scenario
Supplier requirements are best divided into three levels: some are needed in almost any scenario, some only under certain conditions, and some depend on the company’s scale and maturity. They should not be presented as a single list.
Basic — Needed by Practically Everyone
- Which document types and which countries are actually supported in the client’s own scenarios — a general list on the supplier’s website does not confirm this.
- Reading the document’s fields and machine-readable zone, verifying check digits.
- Detecting traces of forgery and image editing: a printout, a photo of a screen, a photocopy, processing in a graphics editor, a pasted-in fragment.
- What exactly is returned as a result: status, reason for rejection, session materials, structured fields.
- How the result is obtained — polling the session status or a webhook.
- How the strictness of the check is configured and whether different thresholds can be set for different scenarios.
- Where data is processed and stored, and what is deleted and when.
- Logging of decisions: what will remain in the system six months later, when a decision has to be explained.
Scenario-Based — Only If the Scenario Requires It
- Face matching and liveness checks — taking into account the restrictions discussed in the next section.
- Protection against image and video stream substitution.
- Checks against external sources and screening against lists — only if the scenario requires it, not by default.
- Manual review of disputed cases: who performs it, on whose side, with what materials, and within what time frame.
- Support for foreign documents and non-resident customers.
- Working with legal entities and their representatives — a separate task, not part of checking an individual.
Additional — Depend on Maturity and Scale
- On-premise or an isolated data processing environment.
- Dedicated capacity and custom SLA parameters.
- Detecting repeated attempts by the same person under different details — subject to the same restrictions on processing biometric personal data.
- A ready-made widget that makes it possible to launch a check without development on the client’s side.
- A multilingual interface.
| Criterion | What to ask the supplier | What confirmation to request | How to check in the pilot |
|---|---|---|---|
| Supported documents and countries | Which document types and countries actually work on the client’s samples | Results on the submitted samples, not a general list from the website | Run samples from your own set and record any discrepancies with the expected coverage |
| Result format | What exactly is returned: status, reason for rejection, structured fields, session materials | A sample response on a real case | Check on real cases whether the fields are sufficient for a decision, and record the gaps |
| Thresholds and strictness settings | Whether different thresholds can be set for different scenarios | Threshold configuration documentation | Set two thresholds on the same sample and record how the result changes |
| Data storage and deletion | Where data is processed and stored, what the retention period is, and what is deleted | Contractual storage obligations and documentation of the available retention settings | Check whether test materials can technically be deleted in your own environment; if not, record this as a limitation |
| Face matching (if required by the scenario) | Which mode is implemented and who, under the scheme, is responsible for the decision — automatic matching or the involvement of an authorized officer | A documented processing scheme and the allocation of roles between supplier and client | Observe whether the scenario’s actual behavior matches the described scheme — this is a check of conformity to behavior, not a legal assessment of the mode |
| Manual review of disputed cases | Who reviews, on whose side, with what materials, and within what time frame | An SLA for manual review in the contract | Measure the actual review time on pilot cases and compare it with the time stated in the SLA |
| On-premise and infrastructure (if relevant) | Minimum and recommended hardware requirements | The supplier’s technical specification | Compatibility checking with your own infrastructure is a separate technical stage, not part of a pilot on a cloud environment |
| Exit terms | How data and logs are exported, the migration period | The termination clause of the contract | Clarified before signing, not in the pilot |
What the Law Restricts and What Not to Expect From a Supplier
The information systems of organizations, individual entrepreneurs, and notaries are prohibited from processing, including collecting and storing, biometric personal data used for identification purposes — except where it is collected for placement in the Unified Biometric System in accordance with federal laws (Federal Law No. 572-FZ of 29 December 2022, Article 15(1)(1); the provision has been in effect since 1 June 2023). Separately, the law expressly exempts from this restriction the case where the provided biometric personal data are compared with data in an information system not by automated means but with the involvement of an authorized officer (572-FZ, Article 1(2)(2)).
This gives the framework worth keeping in mind when formulating requirements for a face-matching scenario: the law distinguishes between automatic matching for identification purposes and manual comparison with the involvement of an officer — these are two different modes with different requirements, and the question of which mode a particular supplier has implemented should be put to them before the pilot — finding out after the fact is already too late. The article describes exactly this regulatory framework. It does not assess the lawfulness of specific products on the market — that requires a separate legal review of the solution once chosen.
Regardless of what functions a supplier claims, the obligated person before the law remains the client. A contract with a KYC provider does not transfer the obligation under 115-FZ to it, does not confirm compliance with 289-FZ for a platform operator, and does not replace ESIA and the EBS where they are mandatory by law. Wording such as “the provider ensures compliance with the law” or “guarantees no fraud” does not match this allocation of responsibility for any of the three segments.
How to Structure a Pilot So That It Shows Something
Presentations and demo stands are fine for initial screening — each supplier shows its best case — but a final choice cannot be made on them. A meaningful comparison is obtained only under one condition: all pilot participants are tested on one sample, under the same conditions, using one methodology.
Collect a sample that resembles the real flow: document types and years of issue, the share of worn and foreign documents, devices and camera quality, shooting conditions, the share of repeat attempts — and, separately, a flow resembling fraud, if the client has one.
Label the ground truth in advance: for each example in the sample, the correct answer, established by people, must be known in advance. Without ground truth, a pilot shows only how well two systems agree with each other — not the quality of the decision.
Fix uniform conditions for all participants: the same constraint by which the operating point is set — for example, the same false match rate or the same share of manual reviews — one scenario of steps and one way of submitting images. The same numerical threshold value is not a uniform condition: different systems have their own score scales, and the same number means different strictness for them.
Check the quality of data extraction for each field separately — surname, first name, patronymic, date of birth, series and number, date of issue, issuing office code, machine-readable zone. A summary “recognition accuracy” metric hides the fact that one field is read poorly.
Count false rejections and misses separately: a rejection costs a lost customer, a miss costs a loss and regulatory risk. They cannot be combined into a single “accuracy percentage.”
Measure user completion of the scenario — the share who reach the end, the share who drop off and at which step — as well as the share of repeat attempts and the share of cases sent to manual review: these are direct operating costs.
Measure latency as a distribution, not as an average: what matters is the median and the upper percentiles at the target load.
Check resistance to attacks that are realistic specifically for the client’s scenario, and calculate the cost of a completed check and the cost of an accepted customer — the methodology is in the next section.
There are no universal pass thresholds suitable for every scenario, and transferring someone else’s selection procedure to your own scenario is not a good idea. The threshold is chosen based on expected losses: the cost of a false rejection and the cost of a miss are multiplied by how often each occurs on the real flow — and the boundary shifts to where the total damage is smaller. If the share of misses is limited by risk appetite or a regulatory requirement, that constraint is set first, and everything else is optimized within it. The threshold cannot be chosen and the result measured on the same data: the sample is split, the threshold is set on one part, and the final metrics are calculated on the held-out part. For the same reason, thresholds for different operations of the same business usually differ — calibrating a threshold to a risk profile is covered in detail in the article Risk-based KYC: how to choose the verification level by risk profile, and face recognition metrics in the article Face recognition accuracy in KYC.
One of the questions worth checking at this stage is how the supplier arranges test access to the KYC platform for an independent pilot.
At NeuroVision, test access is granted upon request, usually with a preliminary NDA; load parameters, scenario limits, and SLA terms are discussed individually. This is an example of the kind of procedure to expect from a supplier before a pilot — other vendors’ procedures may differ.
How to Calculate the Full Cost
For comparing suppliers, what matters is the cost of an accepted customer, not the price of a single check — and the list of questions here is usually longer than procurement expects.
| Cost item | What to clarify with the supplier |
|---|---|
| Integration | Scope of work on your side, availability of a test environment, whether development is needed at all |
| Billable operations | What counts as a check: an application, a session, or a unique customer |
| Repeat attempts | Whether repeats and sessions interrupted by the user are billed |
| Unsuccessful and skipped checks | Whether a check that lacked data, and a rejection due to photo quality, are billed |
| External queries | Whether each check against an external source is billed separately |
| Manual review | On whose side it is performed, whether it is included in the rate, how it is calculated |
| Minimum commitments | Minimum payment, minimum volume, contract term |
| Support and SLA | What is included in the base rate and what is sold separately |
| Storage | Free retention period for check materials, the rate after it |
| Infrastructure (for on-premise) | Hardware, licenses, operation, updates |
| Exit | Export of data and logs, migration period, the fate of the integration, what happens to check materials |
Below is a hypothetical example of the calculation method itself; the figures are not market rates and do not relate to any particular supplier. Suppose one check costs ₽20 according to the price list, and 100 applications came in over a month. Of these, 20 required a repeat attempt, and each repeat attempt is billed as a separate check — that is another 20 × ₽20 = ₽400. Another 10 cases went to paid manual review at ₽100 per case — ₽1,000. Total for the month: 100 × ₽20 + ₽400 + ₽1,000 = ₽3,400. If 90 of the 100 applicants passed the check successfully, the cost of one accepted customer is about ₽38, almost twice the list price of a single check — it is this final figure that should be compared between suppliers, not the list price on its own. This is a simplified calculation of only the operational part — repeats and manual reviews; it does not include integration, infrastructure, support, storage, or the cost of erroneous decisions, so ₽38 should not be read as the total cost of ownership. An expanded model with these items and the cost of errors is covered in the article The economics of KYC: how to calculate the cost of an approved customer and the price of errors.
What to Ask About Contract Termination
The question of contract termination is worth asking before connecting, while it has not yet become pressing. An example of why this matters: according to a CNews report of 15 October 2026, Kabutek LLC (OOO “Kabutek”), which operated under the IDnGo brand (Cyberity until 2024), notified its clients that it was ceasing operations in Russia; operating activities end after 31 December 2026, and the legal entity is being liquidated. According to the publication, the company’s software will not be transferred for further commercial use and will be decommissioned.
A single case of a particular supplier leaving says nothing about the KYC market as a whole: no conclusion about a trend follows from it, but it does give a reason to ask any supplier specific questions in advance. Before signing a contract, it is worth getting answers to three questions: exactly how and within what time frame data and decision logs are exported when the contract is terminated; what happens to the materials of checks already performed; and what period is allotted for migrating to another solution without interrupting the customer verification process.
Requirements for a KYC provider cannot be formulated as a single list for every business: the law defines the obligations of a bank, an MFO, and a marketplace differently, and this directly determines what part of the task can be given to a supplier at all. Customer identification remains an obligation of the organization itself; the provider supplies a tool and works within the boundaries set by the law — including cases where ESIA and the EBS are mandatory and nothing commercial replaces them.
A meaningful comparison of suppliers is built on a pilot on one sample using a uniform methodology, where false rejections and misses are counted separately, without being reduced to a single “accuracy percentage”: vendor presentations do not provide such a comparison. The full cost of a solution is made up of billing for repeats, manual reviews, data storage, and the terms of exiting the contract — and this last item should be clarified before signing, while it has not yet become pressing.
FAQ
