Data verification is checking the accuracy of information about a person or a company against a source that does not depend on whoever provided the information: a state system, an official register, or an operator service. Let’s look at what data can be checked this way, against which sources, and what exactly each check shows — and what remains outside its scope, even if the check is passed successfully.
What Data Verification Is
The definitions in Federal Law No. 115-FZ “On Combating the Legalization (Laundering) of Proceeds from Crime and the Financing of Terrorism” (Article 3) and Federal Law No. 152-FZ “On Personal Data” (Article 3) do not include the term “verification.”
The closest in meaning is the concept of identification in 115-FZ: under Article 3, identification is the set of measures to establish certain information about customers and to confirm the accuracy of this information using original documents and/or duly certified copies and/or state and other information systems. Confirming the accuracy of information against an independent source is, in essence, exactly what is called data verification in practice. 115-FZ imposes the obligation to identify a customer before accepting them for service on organizations that carry out transactions with funds or other property (Article 7(1)(1)), with exceptions named by the provision itself. When identifying a customer, such organizations are entitled to require identity documents, constituent documents, and state registration documents, and, for a customer who is an individual, are additionally entitled to request the insurance number of the individual personal account in the compulsory pension insurance system, that is, SNILS (Article 7(5.4) of 115-FZ). Such organizations are also entitled to accept the information submitted by the customer in the form of an electronic document signed with an enhanced qualified electronic signature — that is, the provision does not require in-person attendance with paper originals as the only option.
For a customer who is an individual, the law separately describes simplified identification: establishing the surname, first name, patronymic, and the series and number of the identity document, and confirming the accuracy of this information in one of the following ways — using original documents or certified copies; using information from state information systems, including the systems of the Pension and Social Insurance Fund and the Federal Compulsory Medical Insurance Fund; through the Unified Identification and Authentication System (ESIA) with an enhanced qualified or simple electronic signature issued in person (Article 3 of 115-FZ). The law applies this simplified procedure only in the cases established by 115-FZ itself — that is, for specific transactions that are separately listed in 115-FZ. It is not a general substitute for full identification.
The personal data law contains a separate principle: the operator must ensure the accuracy and sufficiency of personal data and, where necessary, their relevance, and must take measures to clarify incomplete or inaccurate information (Article 5(6) of 152-FZ). This is a data quality requirement that the law places on the personal data operator itself.
What Data Is Checked and What Each Check Shows
For each type of data, the table shows the source it is checked against, what exactly such a check confirms — and what remains outside its scope even when it is passed:
| Data | Checked against | Confirms | Does not confirm |
|---|---|---|---|
| Russian passport | Information on invalid passports, including the check on Gosuslugi (State Services) | That at the time of the check the passport is not listed as invalid | That the document was presented by its owner. That the passport is valid if a ground for invalidity has not yet been established — for example, under Article 9(8), items 10 and 12, of Federal Law No. 138-FZ (the citizenship law), a passport becomes invalid once forgery of documents or the owner’s lack of Russian citizenship is established, retroactively, from the date of issue. Recent changes are not guaranteed either: according to Gosuslugi, the details of a new passport may not yet have been updated in the database of the Ministry of Internal Affairs (MVD), and one needs to wait about two weeks. The full list of grounds for invalidity and how to check it — in the article “Invalid Passport: 12 Grounds Under the Law, How to Check, and What a Company Should Do” |
| Full name, document, SNILS, and other details in state systems | Matching against state information systems — the Unified State Register of Individual Entrepreneurs (EGRIP), the Unified State Register of Legal Entities (EGRUL), the register of accredited branches, and others (for the persons covered by 115-FZ — Article 7(5.4)) | That the combination of details matches a record in the state system | That this information was provided by its owner |
| Self-employed (samozanyatyy) status | The Federal Tax Service (FNS) service or API “Checking the Status of a Professional Income Tax (NPD) Payer” — by TIN and date | The status on the specified date: the request parameter `requestDate` is described precisely as the date for which the status is checked | The status on other dates and the nature of the relationship with the client — more on this in the article “Risks of Working With Self-Employed Persons for a Company” |
| Company — via EGRUL | EGRUL information: it is open and publicly available, with exceptions established by law (Article 6(1) of Federal Law No. 129-FZ, the law on state registration of legal entities and individual entrepreneurs) | What is recorded in the register, including whether there is a record of unreliable information — at the application of an individual, a record of unreliability is entered with respect to any information about the company (Article 11(5) of 129-FZ), while following a check by the registering authority — only with respect to the information expressly listed in the law (Article 5(1)(v), (d), (l) of 129-FZ). Before entering a record following a check, the registering authority sends a notice to the company, its founders, and the person entitled to act on its behalf without a power of attorney, and gives 30 days to confirm the accuracy of the information (Article 11(6) of 129-FZ) | That the company actually conducts business. That the person you are dealing with is its head. How to read the extract and what to look for in it — in the article “How to Check a Counterparty by TIN: The Verification Procedure and How to Read the Result” |
Not every type of data has an open source for independent checking: sometimes access to it is gated by the consent of the person themselves, which an outsider cannot give. For example, the FNS service “Find Out TIN” requests consent to the processing of personal data — and only the person whose TIN is being checked can give it.
Phone numbers and email addresses are checked differently — without reference to a third-party source: a code sent to the number or address and entered back confirms access to that number or mailbox at the moment of entry.
A package of checks brings this set — passport, details, company data — together in one place, if several checks need to be combined
Verification, Identification, Authentication
The three terms sit side by side in discussions of customer checks, but mean different things. Identification under 115-FZ is establishing information about a customer and confirming its accuracy (Article 3): for organizations within the scope of 115-FZ, this is the formal counterpart of what is called data verification. Authentication is confirming, at the moment of access, that the party on the line really is who they claim to be: a password, an SMS code, an electronic signature. It confirms that the information is being accessed by the same person who has already confirmed their right to it — it has nothing to do with the accuracy of the information itself. Identity verification is a broader everyday concept that in practice may include both document checks and authentication, depending on what exactly a particular service checks; this concept has no separate legal definition.
Which levels of customer checks (KYC, Know Your Customer) exist and what is required at each of them — from a minimal set of actions to full document verification — we covered in the article “Three-Level KYC Model: How Simplified, Full, and Enhanced Checks Work”.
Verification and Validation
This pair of concepts comes from the broader field of quality control and is not specific to customer data checks. Verification answers the question of whether the data matches the source it is checked against. Validation answers a different question: whether this data is fit for the specific task it is going to be used for. Applied to customer data, the distinction looks like this: verification is matching a full name or document details against a state system; validation is deciding whether the collected data is sufficient for a specific step, for example, for accepting a customer for service. Thus, checking a self-employed person’s status on a specific date is verification; deciding whether one such check is enough before a one-off payment or whether it should be repeated regularly is already validation, and this decision is made by the business itself, not by the state data source.
What It Means to “Get Verified” on a Service
Banks, marketplaces, exchanges, and other services ask users to “get verified,” but mean different sets of checks — from a single code confirming a phone number to full matching of documents against state systems. There is no single standard for what exactly “verification” includes on a particular platform: the set of checks is determined by the service itself, based on its own requirements and the legal provisions that apply to it. Therefore, the word “verification” alone does not tell you in advance what data a service will ask for and what it will check it against: for one service it may be a one-time SMS code, for another — a full package of documents and matching against several state systems at once.
This article is current as of 28 October 2026. Provisions are given in the versions in force on that date: 115-FZ, version of 4 August 2026 — Article 3 and Article 7(5.4); Article 7(1)(1), version of 13 June 2023; 152-FZ, version of 26 July 2026 — Article 5(6); 138-FZ, version of 26 June 2026 — Article 9(8) (source read on 21 October 2026); 129-FZ, version of 4 August 2026 — Article 6(1) and Article 11(5)–(6). The description of the FNS service and API is as of 19 October 2026.
Data verification confirms that information matches a specific source — a state system record, a register, a database of invalid passports. What one is often tempted to conclude from this match — that the document was presented by its owner, that the company conducts business — it does not confirm. The practical takeaway is the same for any such check: look not only at what it confirmed, but also at what remained outside its scope — especially if a decision with financial consequences depends on the result.
FAQ
