Client API Verification: What a Legal Service May Check

Short version: API verification of a client, meaning an automatic comparison of the client’s data with government registers, has legal limits. Every register has its own access rules.

But even open data may not be processed without a ground.

For a legal service the question is practical. Before accepting a client, the service needs to understand who it is dealing with. Is the company active? Are there signs of bankruptcy, enforcement proceedings or large disputes? All of this affects payment and the work plan.

An everyday example: a building with a concierge. The notice board by the entrance can be read by any passerby. But a concierge who copies the residents’ phone numbers into a table and checks every visitor against it is keeping a file of his own, and the file has its own rules.

A resident’s mailbox is off limits to the concierge, even if a key happens to be within reach. Registers work in a similar way: some data sits on the notice board, other data is locked in the mailbox, and only the person has the key. A file assembled from open data remains a file, and whoever keeps it answers for it.

Three Questions Before Every Request

The service asks itself these questions before it sends a request to a register:

  1. Whose data is this? A company’s or a person’s. This decides whether the personal data law applies.
  2. On what ground may it be processed? “The register is open” is not a ground.
  3. Who answers for it? The law firm, the developer of the service, or the API provider, meaning the company through which the service receives data from registers.

The first question is answered here. The other two get their own articles in the series.

An automatic check saves a lawyer’s time on routine work and shows risks before the firm spends effort on the case. Most often the service answers four questions:

  1. Company status. The company exists, and the register names the person entitled to act for it without a power of attorney.
  2. Bankruptcy. Notices of bankruptcy of a client or its counterparty change the strategy and the payment terms.
  3. Enforcement proceedings. This is the compulsory collection of debts under enforcement documents, and it says something about the client’s ability to pay.
  4. Court disputes. The cases show whom the client is already suing or being sued by, and over what.

The purpose sets the scope of the check. The personal data law requires the content and volume of processed data to match the stated purposes. The data must not be excessive (Art. 5(5) of Federal Law No. 152-FZ of July 27, 2006 “On Personal Data,” hereinafter 152-FZ).

A check against every database at once, “just in case,” sits badly with this principle. The service has to be able to explain why it needs each source.

Which Sources Are Open and Which Are Closed?

Let’s take a fictional service for the initial screening of a law firm’s clients. Only the service is made up. The rules are real: they are stated as of October 14, 2026, and must be verified again before use in a product.

SourceAccess ruleWhat the service does
Unified State Register of Legal Entities and of Individual Entrepreneurs (EGRUL and EGRIP, kept by the tax service)The data is open (Art. 6(1) of Law No. 129-FZ on Registration of Legal Entities). The number, date of issue and issuing authority of an individual’s identity document are not released to private users (Art. 6(2))Queries by INN (taxpayer ID) or OGRN (company registration number). Does not treat missing data as an answer of “clean”
Unified Federal Register of Bankruptcy Information (EFRSB)The data is open and may be used without restrictions (Art. 28(2) of Law No. 127-FZ on Insolvency)Looks for bankruptcy notices and passes any it finds to a lawyer
Enforcement proceedings database (kept by the Federal Bailiff Service, FSSP)Only the data listed in Art. 6.1(3) of Law No. 229-FZ on Enforcement Proceedings is publicly available, and the period of openness is limited (Art. 6.1(4))Matches by full name and date of birth, and a lawyer confirms the match
Texts of court rulingsCommercial (arbitrazh) courts post rulings in full (Art. 15(2) of Law No. 262-FZ on Access to Court Information, exceptions in Art. 15(6)). In rulings of courts of general jurisdiction personal data is removed, but the full names of the parties remain (Art. 15(3))Searches for disputes by INN and company name, and for individuals by surname, and passes what it finds to a lawyer
Tax data about the clientTax secrecy: tax authorities do not disclose information about a taxpayer (Art. 102(2) of the Tax Code). Only what Art. 102(1) lists is open, for example the INN and the amount of tax debtDoes not request tax returns or other closed data and asks the client for a document when needed
Credit histories (credit history bureaus, CHB)A report is issued under a contract with the bureau and with the person’s consent (Art. 6(2) and 6(9) of Law No. 218-FZ on Credit Histories)Requests one only with a separate consent that records the purpose

The sources fall into three groups:

  • open registers (EGRUL and EGRIP, EFRSB, courts);
  • a register with a limited period of openness (FSSP);
  • closed data (tax secrecy, credit histories).

A Company or a Person: Where the Line Runs

Checking a company and checking a person are different tasks. Information about a company (status, address, bankruptcy notices, cases) is not in itself personal data, and the personal data law does not apply to it.

The law applies when the request or the answer contains information about an individual:

  • the manager and founders in EGRUL;
  • an entrepreneur;
  • a citizen who is a debtor in the FSSP database or in an insolvency case;
  • the full names of the parties in court rulings.

An entrepreneur is listed in EGRIP as an individual, so I treat that information as personal data too. An entrepreneur is checked under the same rules as any other person.

The line depends on what the request contains: for a sole proprietor or a small company, information about the organization and about its owner often coincides.

For open registers a second layer remains, and it concerns the service itself. Even when access to a register is free, the data received may be processed only on a ground the law provides. That is the subject of the next article in the series.

Frequently Asked Questions

Is consent needed to check a company in EGRUL? No, consent is not needed for information about a company: it is open (Art. 6(1) of Law No. 129-FZ) and is not personal data.

But the register names the manager and founders. A surname together with a position or a share in the company identifies a person, and any such information is personal data (Art. 3 of 152-FZ).

Consent is not required for them either. A ground from Art. 6(1) is enough, for example the service’s legitimate interest, if the person’s rights are not infringed.

Can tax data about a client be obtained through an API? Almost never. Tax secrecy covers information about a taxpayer (Art. 102(2) of the Tax Code). Only what Art. 102(1) lists is open, for example the INN, the amount of tax debt and the amounts of income and expenses in an organization’s accounting statements.

The tax authority passes anything else to another person only with the taxpayer’s own consent (Art. 102(2.3)). It is simpler to ask the client for the document.

Does “not found” in a register mean “all clear”? No. The register may have restricted access to part of the data, the data may have passed its period of openness, or the register itself may have failed to respond. How a service should read such answers I will cover in one of the next articles of the series.

Read Also


Need a legal architect to write the client-checking rules for your service? Write to me: +7 (902) 899-07-58 (Telegram, WhatsApp, KakaoTalk) or send a request.

Need legal advice?

Submit a request — we respond within 24 hours

Submit a Request