Меня зовут Никита Неминущий, я ведущий инженер‑программист финансового маркетплейса «Выберу.ру». Этой статьей я хочу приостановить распространение мифа о том, что Цифровой профиль переходит в офлайн-режим взаимодействия из-за перехода с REST API на СМЭВ.

Статья будет полезна больше не столько разработчикам, сколько менеджерам финансовых организаций. Ибо разработчики и сами разберутся, но скромно промолчат. Тогда как менеджеры с умным видом продолжат повторять ерунду, потому что говорить её легко. Но вот дела: ерунда скользкая, и, поскользнувшись, можно лицом обнять грязь при падении.

Основная мысль статьи в том, что нет никакой офлайн-версии Цифрового профиля в процессе удаленной выдачи займа. Отмечу, что здесь два несовместимых друг с другом момента:

  • офлайн;

  • удаленная выдача займа.

Ну казалось бы очевидна разница в смысле слов "онлайн" и "офлайн", которые отражают состояние подключения к сети и наличие, либо отсу��ствие возможности обмена данными по сети. Однако некоторые IT-компании то ли в рамках маркетингового хода компании, то ли из-за некомпетентности (во что я не хочу верить) с умным видом активно на своем сайте и в публичных выступлениях распространяют миф, о том, что Цифровой профиль переходит в офлайн.

Никаких конкретных ссылок на апологетов "офлайн в онлайн" или "плоской земли" здесь вы не встретите, суть статьи не в этом. А участники финансового рынка и так знают, что "это был слонёнок" - в мультфильме 38 попугаев как раз расследовали подобный инцидент даже без использования указательных пальцев.

Озвучим элементарные понятия и определения

Цифровой профиль – это (в нашем контексте) инструмент, который позволяет микрофинансовым организациям получать доступ к подтвержденным данным о клиенте из государственных информационных систем, и в текущих реалиях, через Систему межведомственного электронного взаимодействия (СМЭВ). Он упрощает процесс оценки кредитоспособности заемщика, позволяет быстрее вынести решение и повысить точность скоринга.

СМЭВ – федеральная государственная информационная система, обеспечивающая обмен данными в электронной форме между участниками этой самой СМЭВ. Участники СМЭВ, в нашем случае, это банки, микрофинансовые организации (МФО), Министерство внутренних дел, Федеральная налоговая служба, Социальный фонд России и множество других организаций.

ЕСИА – это единая система идентификации и аутентификации, а именно государственная информационная система России, обеспечивающая санкционированный доступ граждан и организаций к сведениям в государственных информационных системах через единый аккаунт. Говоря совсем по-простому – эта та система, которая отвечает за показ пользователю формы входа в Госуслуги.

REST API Цифрового профиля – это интерфейс для взаимодействия информационных систем с инфраструктурой Цифрового профиля через архитектурный стиль REST. Этот REST API поддерживается системой ЕСИА и инфраструктурой электронного правительства. Его собственно и решили похоронить.

Online / онлайн ("на линии", "на связи") – состояние, когда устройство или человек подключён к сети и может обмениваться данными по сети.

Offline / офлайн ("вне линии", "вне сети") – состояние, когда устройство или человек не подключен к сети или работает автономно, то есть не может обмениваться данными по сети.

Предыстория

Так вот...

В 2019 году стартовал эксперимент по инфраструктуре Цифрового профиля: государство наводило порядок в данных и связях между системами. Тогда и появился ныне мертворожденный REST API Цифрового профиля.

REST API на фоне СМЭВ выглядел как глоток воздуха. Пока классическая интеграция ассоциировалась с бюрократией, сертификатами, регламентами и выяснением у регулятора почему те или иные запросы не работают, REST API предлагал понятную разработчикам модель: запрос - ответ, JSON, прозрачное логирование на уровне приложения (в СМЭВ логика обычно размазана по нескольким с��оям), быстрый запуск и быстрые правки.

Он был понятен и удобен. Неудивительно, что вокруг него быстро начали строить процессы: кто-то делал интеграцию самостоятельно, кто-то покупал "коробки" у интеграторов.

Но по итогу со словами "это недостаточно безопасно" в конце прошлого года Минцифры объявило о том, что со 2 февраля 2026 года закрывает REST API как способ доступа к данным Цифрового профиля. То есть если раньше было два способа: через REST API и через СМЭВ, то сейчас остался только один – СМЭВ.

Тут же некоторые коллеги на этом рынке поспешили написать статьи и даже выступить с заявлениями, противоречащими здравому смыслу. А чтобы подкрепить свои слова они сослались на собственные же публикации на других площадках. ¯\_(ツ)_/¯

Мы же с вами так делать не будем и разберём официальные документы.

Как дела на самом деле в этом деле

У нас с вами в наличии документ озаглавленный как "Сценарии использования инфраструктуры Цифрового профиля физического лица" (далее просто – методичка). Найти эту методичку можно на сайте Минцифры в разделе с документами.

Так вот на тридцать второй странице данного документа, имеющего версию 1.47 и дату публикации 26 ноября 2025 года, можно узреть занимательную табличку в названии столбцов, в которых фигурируют эти пресловутые слова "online" и "offline".

Скриншот таблицы №1 "Сценарии взаимодействия с Цифровым профилем"
Скриншот таблицы №1 "Сценарии взаимодействия с Цифровым профилем"

И о боже! Тут четыре столбика, три из которых относятся к "онлайн", но только в одном из них фигурирует REST API. Это столбик персикового цвета.

И здесь я принесу слова соболезнования этому большинству пилотных кредитных организаций, которые вложились в "персиковую схему". Мне очень жаль, что вам пришлось всё переделать. Не стоило доверять тому, что персикого цвета.

Но как видно из данной таблички "онлайн" всё ещё жив! Просто вариантов немного поубавилось.

И как выше было описано, передача данных пользователя с 2026 года в Цифровом профиле будет осуществляться только через СМЭВ.

Так, как это всё дело работает?

Из мультфильма "Простоквашино" как будто с молоком матери мы впитали простую мысль: чтобы продать что-нибудь ненужное, необходимо сначала купить что-нибудь ненужное. Так и в Цифровом профиле – организации вначале нужно получить от пользователя согласие на доступ к его данным, а только потом она может вытаскивать эти данные к себе.

Но согласие случайного прохожего нас не интересует. Нам, как организации, нужен именно тот самый Мюнхгаузен, который худощавый, довольно обычного телосложения, носит закрученные усы и бородку под названием "Эспаньолка".

И тут мы подходим к необходимости провести процедуру, состоящую из двух шагов:

  1. Идентификации – запрос и получение данных от человека о том, кто же он такой;

  2. Аутентификации – проверка подлинности этих данных.

А теперь давайте подумаем вместе как и в каких режимах это с Вами можно провернуть? Допустим Вы выступаете в роли заемщика, доходы которого необходимо подтвердить...

... ну, наверное, при личном присутствии, предъявляя из широких штанин документ подтверждающий, что Вы гражданин. И как раз это Ваше личное присутствие, например в офисе банка, и называется этим самым "офлайн-режимом".

С другой стороны, можно инициировать данный процесс, находясь дома, лёжа на удобном диване с банкой безалкогольного пива в руках (алкоголь вреден для Вашего здоровья). Тогда как организация, которой Вы собираетесь выдать согласие находится совсем в другом городе.

И тут в свет софитов выходит вышеупомянутая ЕСИА. Например, на сайте или в мобильном приложении МФО, после того как Вы изъявили желание получить заём. Там Вы выбрали на калькуляторе сумму, график платежей и нажали кнопку "Получить". Вам объясняют, что чтобы не вбивать паспортные данные вручную, Вам следует предоставить их через Госуслуги. После небольшого инструктажа открывается форма входа в Госуслуги, где Вас просят войти, а затем и нажать на кнопку "Выдать согласие".

Данный вариант получения согласия на доступ к информации о Вашей личности проходит уже в "онлайн-режиме". И именно этот вариант относится к OAuth (первый и второй столбцы в таблице).

Процитируем строки из тридцать первой страницы вышеупомянутой методички:

Сценарии подтверждения согласия пользователем доступны в двух режимах: online и offline.

Online-режим предполагает, что пользователь инициирует процесс получения банковской, страховой или иной услуги в мобильном приложении или портале из авторизованной зоны информационной системы потребителя сведений, например, кредитной организации.

Под offline-режимом имеется в виду инициация получения тех же услуг пользователем лично в отделении потребителя сведений, например, кредитной организации, посредством взаимодействия с сотрудником этой организации.

Таким образом эти режимы "офлайн" и "онлайн" лишь разделяют процесс доступа к Цифровому профилю на два вида по способу получения согласия: "глаза в глаза" и "лучше бы мои глаза тебя не видели".

Опосля получения согласия финансовая организация имеет возможность в течение нескольких лет (вплоть до пятидесяти) ходить в Цифровой профиль за Вашими данными. Пока смерть не разлучит вас. Или хотя бы до тех пор, пока Вы не примите решение отозвать у неё Ваше согласие.

Но, как мы уже выяснили, ходить придётся уже только через СМЭВ, так как REST API почил в пучине забвения. И там уже пойдёт обмен "Видами сведений" (в XML формате, SOAP), если речь идёт о СМЭВ 3. Либо же выполнение "Регламентированных запросов" описанных в личном кабинете участника взаимодействия, если речь идет о СМЭВ 4. Но это уже совсем другая история...

Как СМЭВ связан с офлайн режимом

Раз уж мы дошли до СМЭВ и возможно даже дотопали до офиса организации, то стоит упомянуть про запрос согласия через СМЭВ. Это третий и четвертый столбцы в таблице.

Если мы, как организация, хотим у пользователя физически воплотившегося перед нами взять согласие для доступа в некую информационную систему, то нам понадобиться с него запросить что-то, что однозначно его идентифицирует.

Идентификатор пользователя в ЕСИА для этой цели подойдет, но вот пользователь его просто не знает. Он лишь знает, что пришел с мороза и хочет получить заём, но у него нет справки 2-НДФЛ с собой и на собачий холод за окном он лишний раз возвращаться не хочет.

В этом случае, чтобы указать конкретного пользователя, которому будет выслан запрос, мы можем использовать его паспортные данные. А именно серию и номер с его фамилией, именем и отчеством. И естественно нужно указать тип документа, так как паспорт бывает заграничным.

С другой стороны, мы можем использовать СНИЛС – одного этого номера будет достаточно, но СНИЛС есть не у всех. Например, военнослужащие по контракту, как правило, не имеют СНИЛС, так как их пенсия формируется не через систему обязательного пенсионного страхования, а по линии профильного ведомства (Минобороны, ФСБ, МВД и др.).

В общем, собрав те или иные данные, идентифицирующие пользователя, организация, подключенная к СМЭВ, отправляет по этому самому СМЭВ запрос на получение согласия у этого пользователя.

И дальше ей остаётся только ждать… ждать, пока пользователь войдет в свой личный кабинет на Госуслугах, найдёт среди уведомлений этот запрос и, откликнувшись на него, выдаст согласие.

Вспоминаем, что у пользователя плохая память, он ведь забыл справку 2-НДФЛ и наверняка не будет помнить пароля от Госуслуг (читай ЕСИА). Поэтому он может пойти домой и сделать всё уже там.

Вместо заключения

Ведь в заключении лучше не пребывать. Оттуда прежним уже не выйти. ʕ ᵔᴥᵔ ʔ

Offline/online в документах – это не магия и не режим с наличием или без интернета, а всего лишь как именно человек подтверждает согласие: с дивана или в офисе. REST API похоронили и до сих пор отпевают – да, но похороны транспорта не означают похороны онлайн-взаимодействия: дальше живём через СМЭВ.

Не стоит называть белое черным и поддерживать тех, кто так делает. Мир и так сложен, и не стоит вносить в ��его ещё больше путаницы.

Если Вы делаете подобные вещи, чтобы получить маркетинговое преимущество и захватить подобными заявлениями внимание плохо разбирающихся в теме людей, то будьте готовы ловить гнилые помидоры, летящие в направлении вашей сцены.

Все мы ошибаемся, и я тоже. Но отличает нас друг от друга умение признавать свои ошибки.


P.S.: Разочарую, но данная статья написана с помощью нейросетей, особенно той, что между ушами.