Short version: state registers, for example the register of legal entities or the bankruptcy register, are open to everyone. But free access to a register does not give you the right to process the data received from it: these are two separate questions.
You may process data from registers only on a lawful ground. The general grounds are listed in Art. 6(1) of Federal Law No. 152-FZ of July 27, 2006 “On Personal Data” (hereinafter 152-FZ). There used to be an item on publicly available personal data, but it ceased to be in force on March 1, 2021.
A bare reference to “this information is public” is not enough: you have to name a ground that is in force.
This is the second article in the series on client checks through an API. The first one explained which registers are open. This one covers the grounds for processing the data from these registers.
Who Answers for the Data in a Check
Three parties take part in a check:
- the law firm: it accepts the client;
- the vendor: the company that built the program for the check;
- the API provider: the company through which the program receives data from registers.
The one who decides what data to collect and why is called the operator. The operator answers for the data before the law.
Usually the firm is the operator: it decides whom to check and why, and the vendor and the provider work for it. But if the vendor or the provider itself chooses what data to collect and keep, it becomes an operator too.
For example, a provider keeps its own database and sells access to it. In that case it decides for itself what to store there and most likely answers for the database as an operator. What this changes for the firm is covered in the third article of the series.
Divide the roles in advance. When three parties answer for the data, it is hard to tell in a dispute who decided what. An example of the division:
| Party | What it decides | What it answers for |
|---|---|---|
| The firm | whom to check and why | the ground for processing, notifying the client, storing the result |
| The vendor | how the program is built | the security of the program, working to the firm’s instructions |
| The API provider | how to get the data from a register and pass it on | its own database if it keeps one; otherwise carrying out the firm’s instruction |
The division is recorded in the contract with the vendor and the provider. If the provider works on the firm’s instruction, the law requires such a contract: it defines the list of data, the actions with it, the purposes of processing and the protection duties (Art. 6(3) of 152-FZ). The roles are then carried over into the technical specification, the document with the rules for the developer (how to write one).
Below I write “the service” for short: that is how I call the one who checks the client and answers for the data.
Which Grounds for Processing Personal Data Exist Besides Consent
Consent remains the clearest ground for the operator: it is the easiest to prove. But it is not the only one.
Four more grounds fit a client check, with different degrees of reliability:
I. Contract (Art. 6(1)(5))
- When it fits. A person came to you for a service on their own, and the check is needed to conclude a contract.
- What you need to prove. Show that the contract cannot be concluded without the check. Wanting to check is not enough.
- The weak spot. The client came on behalf of a company. You check its director, but you sign the contract with the company itself. The director has no contract with you, so the “contract” ground will not work for the director’s data.
II. Legitimate Interest (Art. 6(1)(7))
- What it is. You may process data if it is needed to protect your legitimate interests or those of other persons, and in doing so you do not infringe the person’s own rights.
- What you need to prove. Show that your interest outweighs the possible harm to the person. The service weighs this itself, and the law does not do it for the service.
- The weak spot. The person may demand that you stop processing. In that case you will need to prove that your interest is stronger.
A court example. A website without media status posted information about a doctor and said that a medical organization had already disclosed it as the law requires. The doctor demanded its removal. The courts held that the website had no ground to process the information. The website turned to the Constitutional Court, but it refused to accept the complaint. So the court decisions stayed in force (Ruling of June 30, 2026 No. 2029-O).
The case concerned publication, not a client check. But the conclusion is general: the openness of data does not protect against a person’s demand to stop processing if no ground can be named.
III. Data the Law Requires to Be Published (Art. 6(1)(11))
- What it is. The law itself requires some information to be published, for example bankruptcy notices. Since publication is mandatory by law, the person’s consent is not needed to process such data.
- Where it fits best. The Unified Federal Register of Bankruptcy Information (EFRSB). The law requires the information to be published and allows it to be used without restrictions, including passing it on (Art. 28(2) of the Insolvency Law No. 127-FZ).
- Where it is weaker. For the register of legal entities (EGRUL) the support is weaker. For the enforcement proceedings database of the bailiff service (FSSP) it is very weak: the law calls this information “publicly available” and does not say it “must be published” (Art. 6.1(3) of the Enforcement Proceedings Law No. 229-FZ).
The purpose of publication matters too. The law does not allow data to be used for purposes incompatible with the purpose of its publication (Art. 5(2) of 152-FZ). Bankruptcy information is published so that interested parties can learn about it. In my opinion, checking a client before accepting the case fits that purpose. Collecting all notices “just in case” goes beyond it.
What practice says. Roskomnadzor’s letter of September 21, 2018 No. 08-77473 allowed such processing of procurement participants’ data to the extent of procurement legislation, but it says nothing about a third-party service. I found no direct answer from the regulator or in case law (open sources, October 17, 2026).
IV. Obligation Under Law (Art. 6(1)(2))
- What it is. The law itself obliges you to check the client. In that case the ground exists without consent.
- Where this applies. For some legal services. Law No. 115-FZ on countering money laundering requires identifying the client if the firm prepares or carries out certain operations on the client’s behalf or instruction (Art. 7.1).
- Which operations. For example, real estate transactions, managing the client’s property, and creating, selling and managing companies.
What the clarification says. Rosfinmonitoring (the Federal Financial Monitoring Service), in its information letter of July 19, 2018 No. 54, counts legal support of an organization as “supporting its activities”: reviewing and drafting contracts, supporting transactions, consultations.
How to Prove the Ground for Processing
Any ground will have to be proved (Art. 9(3) of 152-FZ).
For a request without a separate consent I recommend three conditions:
- The ground is named and recorded in the service’s documents together with a balancing assessment.
- The client has been notified of the processing.
- The API provider question is settled.
Notifying people from the response and the provider’s role are covered in the third article of the series.
The assessment for a legitimate interest is recorded briefly, under four headings:
- The purpose of the check.
- The scope of data.
- The possible harm to the person.
- Why that harm is proportionate to the purpose.
That format is my suggestion, and the law does not name it. Where no such entry exists, getting consent is easier than proving a ground later.
What the court says. I found no direct case law on such a service, and my conclusion rests on the text of the law. The nearest ruling is Supreme Court Resolution of March 20, 2025 No. 25-AD25-1-K4 under Part 1 of Art. 13.11 of the Code of Administrative Offenses.
The Supreme Court set aside the decisions of the lower courts and sent the case back for a new hearing. The courts had not checked whether there was a ground for processing without consent (taking part in a court case, Art. 6(1)(3)), or whether the person’s rights were violated. The case concerns a different situation, so the conclusion is cautious.
Which Ground Should You Name for Each Source
The table below shows my assessment from the text of the law: I found no case law on such a service. For each source, write the ground in the technical specification next to its name.
| Source | Ground | How reliable |
|---|---|---|
| EFRSB | Publication under law (Art. 6(1)(11)), legitimate interest (Art. 6(1)(7)) if needed | Most reliable: the law requires publication and allows use without restrictions |
| EGRUL and EGRIP | Legitimate interest (Art. 6(1)(7)); publication under law (Art. 6(1)(11)) is disputed | The law calls the data open, and checking a counterparty is a legitimate interest if the data about people is kept to a minimum |
| FSSP database | Legitimate interest (Art. 6(1)(7)) | Publication under law (Art. 6(1)(11)) is a weak ground: the law does not say “must be published”; for an individual debtor the balance of interests matters |
| Texts of court rulings | Legitimate interest (Art. 6(1)(7)); publication under law (Art. 6(1)(11)) is disputed | Rulings are posted under Law No. 262-FZ on Access to Court Information, and a search by surname gives only a hypothesis. Rulings may contain data on health or criminal record: for these you need a ground from Art. 10 of 152-FZ |
| Credit histories | Consent under Law No. 218-FZ on Credit Histories | The law itself sets the form, the term and the contract with the bureau |
| Tax data | Closed data: no ground. Open FTS data: as for open registers | The tax authority does not disclose the data (Art. 102(2) of the Tax Code). Only what Art. 102(1) lists is open, for example the INN (taxpayer ID), the amount of tax debt, the income and expenses of an organization from its accounting statements |
For services covered by Law No. 115-FZ, the ground becomes an obligation under law (Art. 6(1)(2)).
Frequently Asked Questions
Is it enough to state in the personal data processing policy that the data was taken from open sources? No. The item on publicly available personal data ceased to be in force on March 1, 2021. You now have to name a ground from Art. 6(1) of 152-FZ: a contract, a legitimate interest, publication under law, an obligation under law or consent.
Can a client be checked in the FSSP database without consent? The law does not require consent, yet a ground is always needed. Only the data the law lists is publicly available: the individual debtor’s full name, date and place of birth, the claim and the amount of debt. It stays open while the enforcement proceeding lasts (Art. 6.1(3) and 6.1(4) of the Enforcement Proceedings Law No. 229-FZ).
The service may rely on a legitimate interest (Art. 6(1)(7) of 152-FZ) as long as the debtor’s rights are not infringed. The debtor must be notified of the processing (Art. 18(3)). The exceptions are listed in Art. 18(4): for example, the person has already been notified or the data was obtained under a law.
The ground “the law requires publication” (Art. 6(1)(11)) is weak here: the law calls this information publicly available, but the words “must be published” are not in it. It is simpler to obtain consent: it is easier to prove than a legitimate interest.
Can data from open sources be processed without consent? Yes, but you need another ground. For example, a legitimate interest, or the fact that the law requires this information to be published (Art. 6(1) of 152-FZ). A bare reference to the data being open is not enough: the ground has to be named and recorded.
Is consent needed to check EFRSB? As a rule, no. The law itself requires this information to be published and allows it to be used without restrictions, including passing it on (Art. 28(2) of the Insolvency Law No. 127-FZ). The ground here is the strongest: “the law requires publication” (Art. 6(1)(11) of 152-FZ). But the general rules apply here too: take only the data the check needs and keep it no longer than necessary.
Read Also
- Third Parties and the API Provider in Client Checks: how to notify people from a register response and who answers for the provider
- How a Service Reads a Register Response: Five Rules: what a service does with what is found and not found
- Client Consent to a Check and the Credit History: how to draft the consent and what the credit histories law requires
- Client API Verification: What a Legal Service May Check: which registers are open and which are closed
- How to Write a LegalTech Spec: six steps from a parameter table to test scenarios
- Red Flags in LegalTech: When a Legal AI Service Hands the Case to a Human: which conditions stop a service before any other rule
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.