How a Service Reads a Register Response: Five Rules

Short version: a register response remains raw material, and it is better to leave the conclusions to a lawyer. The service finds the information, saves the source and hands it to a person.

This is the fifth article in the series on client checks through an API. It explains what the service does with a ready response.

What came before:

• the first explained which registers are open and which are closed;
• the second covered the grounds for processing data from registers;
• the third dealt with the people in a register response and the API provider;
• the fourth covered client consent and the credit history.

The main points of this article:

• a match by surname, first name and patronymic remains a hypothesis;
• “found” goes to a person together with the source, the date and the time of the request;
• “not found” does not mean “clean”;
• the response is kept while it is needed for the purpose, and the record of the ground is kept longer;
• it is safer to leave the refusal to a client to a lawyer than to automation.

The rules are given as of October 24, 2026.

How Does a Service Read a Register Response?

What counts as personal data. Rules 1, 4 and 5 rest on Arts. 5, 9 and 16 of Federal Law No. 152-FZ of July 27, 2006 “On Personal Data” (hereinafter 152-FZ). The law protects people: a client who is an individual, the director, the founders, the parties to disputes. Information about the company itself is not personal data (see the first article). For it I recommend the same approach as good practice; the law does not require it.

Rule 1. A match by full name remains a hypothesis. Registers are full of people with the same name. Telling a client “you have debts” because of a similar name is risky: you may attribute someone else’s debts to the client. Data about a person must be accurate, and the operator (whoever decides what data to collect and why, usually the firm) must correct or delete inaccurate data (Art. 5(6) of 152-FZ).

What the sources contain:

• in the enforcement proceedings database, a debtor who is an individual is listed with surname, first name, patronymic, date and place of birth (Art. 6.1(3), item 5 of Law No. 229-FZ on Enforcement Proceedings);
• in acts of courts of general jurisdiction, the surnames, first names and patronymics of the parties stay, while the date of birth, address and passport data are removed (Art. 15(3) and 15(4) of Law No. 262-FZ on Access to Information on the Activities of Courts);
• acts of arbitration courts are published in full, except for provisions containing state or other legally protected secrets (Art. 15(2) and 15(6)), so there may be more information about an individual there. What exactly remains in such acts in practice, I did not check.

The link to the client is established from the client’s documents: the case number, the address and the tax number (INN). Acts of courts of general jurisdiction contain no INN or address, so there the link rests on the case number and on circumstances the client knows. If there is nothing to confirm the match, the service leaves the note “match not confirmed” and draws no conclusion.

Rule 2. “Found” goes to a person with the source. Along with the result, the service saves the name of the register and the date and time of the request. The service does not word a message such as “the client is insolvent”.

A detected sign works as a red flag, and then triage takes over.

Rule 3. “Not found” does not mean “clean”. The register may have restricted access to part of the data, the data may have passed its period of openness (as in the database of the Federal Bailiff Service, FSSP), or the register itself may have failed to respond. Court acts add two more reasons. The act may not have been posted yet: the term is up to one month (Art. 15(1) of Law No. 262-FZ). For some cases the texts are not posted at all, for example family disputes and limitation of legal capacity (Art. 15(5)). How to tell a glitch from a refusal, I explained in the article Where’s the Line Between a Glitch and a Refusal?.

Rule 4. The response is kept while it is needed for the purpose. Data is kept no longer than the purposes of processing require, unless a federal law or a contract with the person sets a term. When the purpose is achieved, the data is destroyed or anonymized (Art. 5(7) of 152-FZ). The term is written into the technical specification, the document with the requirements for the service, as a separate line.

The record of the ground (of consent or of the assessment of a legitimate interest under Art. 6(1), item 7) is better kept longer than the response itself: the operator must prove the ground (Art. 9(3) of 152-FZ). The law does not name a retention period for such a record. As an example I recommend this: while the processing lasts and three years after it, following the general limitation period (Art. 196 of the Civil Code). The record holds the minimum of information sufficient as proof.

Rule 5. The final decision is made by a person. Decisions that create legal consequences for a person or affect the person’s rights and legitimate interests may not be made solely by automated means. The exceptions are the person’s written consent and cases expressly named in federal laws (Art. 16(1) and 16(2) of 152-FZ).

In my view, a refusal to a client based on a single register response may fall under this ban. It is safer when a lawyer words and signs the refusal. A formal signature does not protect: the ground of the refusal must really be checked.

There is another reading: refusing to conclude a contract remains freedom of contract, and compulsion to conclude one is not allowed (Art. 421(1) of the Civil Code), so the refusal does not affect the person’s rights. I found no official clarifications for either reading. If you need an automatic refusal, obtain written consent to such a decision (Art. 16(2)) or leave automation only a note “pass to a lawyer”.

If automation does make the decision, the operator must explain the procedure to the person, let the person file an objection and consider it within 30 days (Art. 16(3) and 16(4)).

Rule 5 concerns a client who is an individual. For a corporate client Art. 16 does not directly apply, but the recommendation stays the same.

What to Write Into the Technical Specification?

For each source, the specification contains the same fields: the purpose, the condition of the request, the ground and the action of the service. How to write a specification I covered in the article How to Write a LegalTech Spec. Below is a summary table for the whole series with sample values. The abbreviations of the registers (EGRUL, EGRIP, EFRSB) are explained in the first article of the series.

Which Eight Mistakes Are Made Most Often in Client Checks?

A checklist for the whole series:

1. Relying on the openness of data instead of a ground. The phrase “the register is public” does not replace a ground from Art. 6(1) of 152-FZ: contract, legitimate interest, publication by law (more).
2. A general checkbox instead of separate consent. Consent buried in the user agreement does not meet Art. 9(1) of 152-FZ (more).
3. A credit report “just in case”. A request without the client’s consent and without a contract with the bureau violates Art. 6 of Law No. 218-FZ on Credit Histories, and unlawfully obtaining a report is punished under Art. 14.29 of the Code of Administrative Offenses.
4. A conclusion from a namesake. A match by full name is taken as confirmation that this is the client, and the client is told about someone else’s debts.
5. A register response without a date and a source. A month later it is impossible to check where the service got the information and whether it is still current.
6. A provider without an assignment and without consent. Requests to registers go to an outside company without an assignment contract (the law’s name for handing processing to another company) and without consent to the transfer. That is the result of the literal text of Art. 6(3) of 152-FZ; there is another reading (more).
7. An automatic refusal to a client. The service itself rejects an application based on a register response, with no lawyer involved. For an individual’s application this, in my view, may violate Art. 16 of 152-FZ (there is another reading, see Rule 5).
8. The client’s consent instead of a ground for third parties. A client may not give consent on behalf of a counterparty, a founder or a beneficiary unless the client is their representative (Art. 9(1) of 152-FZ).

Frequently Asked Questions

May a service refuse a client by itself based on a register response? Decisions that affect a person’s rights may not be made solely by automated means, except with written consent and in cases named in federal laws (Art. 16 of 152-FZ). If the client is an individual, a refusal, in my view, may fall under this ban, but there is another reading: freedom of contract (Art. 421(1) of the Civil Code). For an organization Art. 16 does not directly apply, but it is still better to leave the refusal to a lawyer.

How long should a register response be kept? No longer than needed for the purpose of processing, unless a federal law or a contract with the person sets a term (Art. 5(7) of 152-FZ). The term is written into the specification as a separate line. The record of the ground is kept longer than the response itself.

What should be done if the register did not respond? Repeat the request under a set rule and then hand it to a person. A silent register does not mean the client has no problems.

How to tell the client from a namesake in a register response? It cannot be done by surname, first name and patronymic alone. The FSSP database has the date and place of birth, acts of courts of general jurisdiction do not. The link is established from the client’s documents: the case number, the taxpayer number, the address. If nothing confirms the match, the service leaves the note “match not confirmed”.

Read Also

• 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
• What Is Triage Logic in LegalTech?: how a service chooses a route and a priority
• Red Flags in LegalTech: When a Legal AI Service Hands the Case to a Human: which conditions stop a service before any other rule
• Where’s the Line Between a Glitch and a Refusal?: what a service does when the register is silent

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.