"Digital Profile Online" Lives On After Transitioning from REST API to SMEV

The article will be useful more for managers of financial organizations than for developers. Because developers will figure it out themselves but will modestly remain silent. While managers, with a wise look, will continue to repeat nonsense because it's easy to say. But here's the thing: nonsense is slippery, and slipping on it can lead to a face-plant in the dirt when falling.

The main point of the article is that there is no offline version of the Digital Profile in the process of remote loan issuance. I would like to note that there are two incompatible moments here:

• offline;

• remote loan issuance.

It would seem obvious the difference in meaning of the words "online" and "offline," which reflect the state of network connection and the presence or absence of the ability to exchange data over the network. However, some IT companies, either as part of a marketing strategy or due to incompetence (which I do not want to believe), actively propagate the myth on their websites and in public speeches that the Digital Profile is transitioning to offline.

You will not find any specific references to the advocates of "offline to online" or "flat earth" here; the essence of the article is not about that. And participants in the financial market already know that "it was a little elephant" - in the cartoon 38 parrots, they investigated a similar incident even without using pointing fingers.

Let's state elementary concepts and definitions

The Digital Profile is (in our context) a tool that allows microfinance organizations to access verified data about the client from state information systems, and in the current realities, through the System of Interdepartmental Electronic Interaction (SMEV). It simplifies the process of assessing the borrower's creditworthiness, allows for quicker decision-making, and increases the accuracy of scoring.

SMEV is a federal state information system that facilitates data exchange in electronic form between participants of this very SMEV. The participants of SMEV, in our case, are banks, microfinance organizations (MFOs), the Ministry of Internal Affairs, the Federal Tax Service, the Social Fund of Russia, and many other organizations.

ESIA is a unified identification and authentication system, namely a state information system of Russia that provides authorized access for citizens and organizations to information in state information systems through a single account. To put it simply – it is the system that is responsible for showing users the login form for State Services.

The REST API of the Digital Profile is an interface for interaction between information systems and the Digital Profile infrastructure through the REST architectural style. This REST API is supported by the ESIA system and the e-government infrastructure. It was actually decided to bury it.

Online – a state when a device or person is connected to the network and can exchange data over the network.

Offline – a state when a device or person is not connected to the network or operates autonomously, meaning it cannot exchange data over the network.

Background

So...

In 2019, an experiment on the infrastructure of the Digital Profile was launched: the state was organizing order in data and relationships between systems. That is when the now stillborn REST API of the Digital Profile appeared.

The REST API against the backdrop of SMEV looked like a breath of fresh air. While classic integration was associated with bureaucracy, certificates, regulations, and figuring out with the regulator why certain requests were not working, the REST API offered a clear model for developers: request - response, JSON, transparent logging at the application level (in SMEV, the logic is usually spread across several layers), quick launch, and quick fixes.

It was understandable and convenient. No wonder that processes quickly began to build around it: some did the integration themselves, while others bought "boxes" from integrators.

But ultimately, with the words "it's not safe enough," at the end of last year, the Ministry of Digital Development announced that starting February 2, 2026, it will close the REST API as a means of accessing the Digital Profile data. This means that if there were previously two methods: through REST API and through SMEV, now there is only one left – SMEV.

Immediately, some colleagues in this market hurried to write articles and even make statements that contradict common sense. To support their words, they referred to their own publications on other platforms. ¯\_(ツ)_/¯

We, however, will not do that and will analyze the official documents.

What's really going on with this matter

We have a document titled "Scenarios for the Use of the Infrastructure of the Digital Profile of an Individual" (hereinafter simply – the guideline). This guideline can be found on the Ministry of Digital Development's website in the documents section.

So, on the thirty-second page of this document, which has version 1.47 and was published on November 26, 2025, one can see an interesting table with the column titles featuring the infamous words "online" and "offline."

And oh my! Here are four columns, three of which relate to "online," but only one of them features the REST API. That is the peach-colored column.

And here I extend my condolences to the majority of pilot credit organizations that invested in the "peach scheme." I am very sorry that you had to redo everything. You shouldn't have trusted what was peach-colored.

But as can be seen from this table, "online" is still alive! It just has fewer options.

And as described above, the transmission of user data in the Digital Profile will be carried out only through SMEV starting in 2026.

So, how does this all work?

From the cartoon "Prostokvashino," it seems that we absorbed the simple idea with our mother's milk: to sell something unnecessary, you must first buy something unnecessary. The same goes for the Digital profile – the organization must first obtain the user's consent to access their data, and only then can it pull this data in.

But we are not interested in the consent of a random passerby. As an organization, we need exactly that Münchhausen, who is thin, of quite ordinary build, has curled mustaches, and sports a little beard called "Españolka."

And here we come to the necessity of conducting a procedure consisting of two steps:

1. Identification – requesting and obtaining data from a person about who they are;

2. Authentication – verifying the authenticity of this data.

Now let's think together about how and in what modes this can be done with you? Suppose you are acting as a borrower, whose income needs to be confirmed...

... well, probably in person, presenting a document from your wide trousers confirming that you are a citizen. And this very personal presence of yours, for example in the bank's office, is called "offline mode."

On the other hand, you can initiate this process while at home, lying on a comfortable couch with a can of non-alcoholic beer in hand (alcohol is harmful to your health). Meanwhile, the organization to which you are going to give consent is located in a different city.

And here comes the aforementioned ESIA into the spotlight. For example, on the website or in the mobile app of the microfinance organization (MFO), after you express your desire to take a loan. There, you selected the amount on the calculator, set the payment schedule, and clicked the "Get" button. You are informed that to avoid manually entering your passport details, you should provide them through State Services. After a brief instruction, a login form for State Services opens, where you are asked to log in and then click the "Give Consent" button.

This option of obtaining consent to access information about your identity occurs in "online mode." And this option refers to OAuth (the first and second columns in the table).

Let’s quote lines from the thirty-first page of the aforementioned manual:

User consent confirmation scenarios are available in two modes: online and offline.

The online mode implies that the user initiates the process of obtaining banking, insurance, or other services in a mobile application or portal from an authorized zone of the consumer information system, for example, a credit institution.

The offline mode refers to the initiation of obtaining the same services by the user in person at the consumer information office, for example, a credit institution, through interaction with an employee of that organization.

Thus, these "offline" and "online" modes simply divide the process of accessing the Digital profile into two types based on the method of obtaining consent: "face to face" and "I wish my eyes had not seen you."

After obtaining consent, the financial organization has the opportunity to access your data in the Digital profile for several years (up to fifty). Until death do you part. Or at least until you decide to revoke your consent.

But, as we have already established, access will now only be possible through SMEV, as the REST API has passed into oblivion. And there, the exchange of "Information Views" (in XML format, SOAP) will take place if we are talking about SMEV 3. Alternatively, the execution of "Regulated Requests" described in the participant's personal account will occur if we are talking about SMEV 4. But that is a completely different story...

How SMEV is related to the offline mode

Since we have reached SMEV and perhaps even trudged to the organization's office, it is worth mentioning the request for consent through SMEV. This is the third and fourth columns in the table.

If we, as an organization, want to obtain consent from a user who has physically manifested before us for access to some information system, we will need to request something that uniquely identifies them.

The user's identifier in the ESIA will suffice for this purpose, but the user simply does not know it. They only know that they came in from the cold and want to get a loan, but they do not have the 2-NDFL certificate with them and do not want to return again in the biting cold outside.

In this case, to specify a particular user to whom the request will be sent, we can use their passport details. Namely, the series and number along with their surname, first name, and patronymic. And of course, we need to specify the type of document, as a passport can be foreign.

On the other hand, we can use the SNILS – just this number will be enough, but not everyone has a SNILS. For example, contract servicemen typically do not have a SNILS, as their pension is formed not through the mandatory pension insurance system, but through the relevant agency (Ministry of Defense, FSB, Ministry of Internal Affairs, etc.).

In general, having gathered various data identifying the user, the organization connected to SMEV sends a request for consent from this user through SMEV.

And then it only has to wait… wait for the user to log into their personal account on State Services, find this request among the notifications, and respond to it by giving their consent.

Remember that the user has a poor memory; they forgot the 2-NDFL certificate and surely won't remember their password for State Services (read: ESI). So they might go home and do everything there.

In conclusion

After all, it’s better not to be in prison. Once there, you can’t come out the same way. ʕ ᵔᴥᵔ ʔ

Offline/online in documents is not magic and not a mode with or without the internet, but merely how exactly a person confirms consent: from the couch or in the office. REST API is dead and still being mourned – yes, but the death of transport does not mean the death of online interaction: we continue to live through SMEV.

One should not call white black and support those who do so. The world is complicated enough, and there’s no need to add more confusion to it.

If you engage in such practices to gain a marketing advantage and capture the attention of those poorly versed in the topic with such statements, be prepared to catch rotten tomatoes flying towards your stage.

We all make mistakes, and so do I. But what distinguishes us from one another is the ability to acknowledge our mistakes.

P.S.: I’m sorry to disappoint you, but this article was written with the help of neural networks, especially the one between my ears.