Я узнал об отключении не из новостей. Утром мне написал знакомый из небольшого банка: «всё упало, паспорта не проверяются, онлайн встал». В то время как раз дописывал обработку ошибок в smev4-rs, Rust-крейте для работы с СМЭВ 4.
Совпадение так совпадение.
Первые несколько часов ушли на то, чтобы понять, что вообще происходит. Минцифры говорило что транспорт в порядке. Жалобы шли и от тех, кто на СМЭВ 3, и от тех, кто переезжал на СМЭВ 4. Значит дело было не в версии протокола.
Параллельно в чатах разработчиков началось то, что я бы назвал «коллективным дебаггингом вслух». Люди постили статусы своих систем, пробовали разные эндпоинты, сравнивали коды ответов.
У одних была 403, у других 503 без тела, у третьих запросы просто висели. Это само по себе было информативно: такой разброс при одновременном сбое говорил о том, что проблема не в транспортном слое.
Когда стало ясно, что МВД закрыло доступ к своим данным как оператор ГИС, у меня в голове щёлкнуло: это именно тот сценарий, для которого я последние недели писал явное разграничение типов ошибок.
И вовсе не потому, что предвидел апрель.
Просто когда интегрируешься с государственными данными долго, понимаешь, что «СМЭВ лежит» и «МВД закрыло доступ» — это совершенно разные ситуации с разными последствиями. Первое чинится само, второе нет.
По горячим следам этих апрельских событий написал о том, что конкретно идёт не так в типичных интеграциях, и как я думал об этом в процессе разработки своего крейта.
Почему всё встало, хотя транспорт работал
СМЭВ 4 по сравнению с третьей версией сделал одну хорошую вещь: ввёл централизованную ролевую модель управления доступом. Детальный контроль над тем, кто и к каким данным имеет доступ. Для безопасности это правильно.
Побочный эффект: одно административное действие на стороне владельца данных приводит к тому, что все 500+ подключённых организаций теряют доступ синхронно. Не нужно ничего ломать в транспорте.
Настройка в интерфейсе, и всё.
Это не баг СМЭВ 4, это следствие его архитектуры. И с этим нужно жить при проектировании интеграции.
Правовая ситуация, о которой мало кто говорит
Пока разворачивались события, я перечитал Положение ЦБ 444-П.
Пункт 2.2 положения и разъяснительное письмо Центробанка от декабря 2023 года довольно прямо говорят: для проверки паспорта в части сведений МВД при дистанционной идентификации есть только один законный способ — СМЭВ.
Других открытых систем с нужным правовым статусом попросту нет.
ЕСИА является идентификацией пользователя, а не проверкой документа. Сайт МВД — справочный сервис, он не годится для целей 115-ФЗ. Коммерческие агрегаторы не создают юридически достаточного основания.
То есть при недоступности СМЭВ банк физически не может выполнить требование закона и при этом не имеет законной альтернативы. Так себе ситуация.
20 апреля часть банков получила доступ обратно. Это были банки, которые смогли подтвердить наличие аттестата ФСТЭК по новым требованиям.
С 1 марта 2026 вступил в силу Приказ ФСТЭК №117. Он расширил требования к защите на системы, которые получают данные из государственных информационных систем.
Так как база МВД является государственной ИС, то и подключённые к ней банки тоже должны соответствовать требованиям. МВД воспользовалось этим как основанием для отключения.
Что конкретно ломается в интеграциях
Я поговорил с несколькими командами после инцидента. Общая проблема одна: любая ошибка внешнего сервиса схлопывается в один статус.
Что-то пошло не так, пишем в лог «smev error», идём дальше.
Для регуляторной отчётности это катастрофа.
Потому что «403 от МВД как результат административного решения» и «503 потому что агент перегружен» это принципиально разные события. У них разный путь деградации, разный смысл для комплаенса, разная строка в аудиторской записи.
Одна из команд, с которыми я говорил, обнаружила это именно 15 апреля: у них была «ошибка сервиса», они начали рестартить агенты, дёргать поддержку своего вендора и только через несколько часов выяснили, что проблема вообще не у них. Всё это время в логах была одна и та же нечитаемая строчка.
В smev4-rs я решил это через отдельный тип.
Классификатор принимает HTTP-статус и наличие заголовка Retry-After и возвращает enum:
let reason = UnavailableReason::from_http_status(403, false);
// ProviderAccessDenied — владелец закрыл доступ
let reason = UnavailableReason::from_http_status(503, true);
// QuotaOrRateLimit — 503 с Retry-After = лимит, а не деградация
let reason = UnavailableReason::from_http_status(503, false);
// ServiceDegraded — просто плохо
В обработке ошибок клиента это выглядит так:
match xml {
Ok(body) => { /* всё хорошо */ }
Err(SmevError::Unavailable { reason }) => {
// сюда попадают 403, 423, 429, 503
// reason содержит класс ошибки и статус
log_incident("provider_unavailable", &reason);
route_to_fallback();
}
Err(SmevError::Timeout) => {
log_incident("transport_timeout", "polling_limit_reached");
route_to_manual_queue();
}
Err(SmevError::Payload(msg)) if msg.contains("not found or expired") => {
// тикет устарел — это не проблема доступности
// это управление сессией на стороне вызывающего кода
log_incident("ticket_expired", &msg);
}
Err(e) => {
log_incident("unexpected_error", &e.to_string());
}
}Отдельно обрабатывается 404: истёкший тикет возвращается как SmevError::Payload, потому что это другой класс проблемы.
СМЭВ 3 и СМЭВ 4 возвращают разные данные
Это деталь, о которой я почти нигде не видел нормального объяснения.
СМЭВ 3 при проверке паспорта (вид сведений MVDR23) возвращает три поля: статус, код причины недействительности, дату с которой паспорт стал недействительным.
СМЭВ 4 (витрина rfp_check) возвращает только статус.
Это значит, что организация, которая мигрировала на СМЭВ 4 и отключила СМЭВ 3, потеряла два поля. Причём поля существенные: «паспорт недействителен потому что выдан новый» и «паспорт недействителен потому что в базе похищенных».
Это очень разные ситуации с разными действиями. Без кода причины разница неотличима.
Я думал об этом при проектировании роутера. Пока в smev4-rs его нет (запланировал на будущее), но архитектурно правильно держать обе версии за единым интерфейсом: СМЭВ 4 как основной канал, СМЭВ 3 для расширенных данных по мере необходимости.
Аудит попытки при отказе
Одна вещь, которую 15 апреля обнажил жёстко: у многих организаций нет записи о том, что попытка верификации вообще была сделана. А 115-ФЗ интересует не только успешный результат.
При проверке нужно доказать что банк пытался выполнить требование. Даже в том случае, если внешний сервис не ответил.
Это означает: в идеале у вас должен быть журнал с временной меткой каждой попытки, хешем запроса и причиной неудачи.
Не «система упала в 2:15», а «попытка верификации в 2:15:43.219, статус ProviderAccessDenied, перенаправлено в ручную очередь». Разница в том, что второе является доказательством, первое — просто лог.
В smev4-rs есть два варианта с аудитом. Простой, для одной попытки:
let fingerprint = SmevClient::request_fingerprint(canonical_request_bytes);
let (result, audit) = client
.poll_response_audited(ticket, fingerprint)
.await;
// audit создаётся независимо от исхода
// при Unavailable — маркер SMEV_UNAVAILABLE
// при Timeout — SMEV_TIMEOUT
// при успехе — хеш ответа
persist_audit_entry(&audit).await?;И для серии попыток в одной сессии, с непрерывной цепочкой:
let nonce = SmevClient::request_fingerprint(canonical_request_bytes);
let (result1, audit1) = client
.poll_response_chained(ticket1, nonce, None)
.await;
// вторая ссылается на первую
let (result2, audit2) = client
.poll_response_chained(ticket2, nonce, Some(&audit1))
.await;Каждая запись содержит хеш предыдущей. Вставить или удалить запись без нарушения цепи невозможно. Это особенно важно, когда несёшь артефакты на проверку.
Хеш запроса вычисляется от канонического представления без персональных данных в явном виде. Это не просто privacy-by-design, это ещё и практично: хранить доказательство что именно запрашивалось, не храня сами данные.
Про дедупликацию и деньги
Постановление Правительства №1687 ввело тарификацию СМЭВ ещё в ноябре 2025. Плюс МВД хочет отдельный тариф за свои данные. Конкретные суммы ещё в нормативном процессе, но направление понятно.
Дублирующие запросы при любой тарификации выливаются в дополнительные расходы. request_fingerprint в крейте даёт детерминированный BLAKE3-хеш от входящих байтов. Один и тот же запрос, один и тот же хеш.
Можно использовать как ключ кеша:
let key = SmevClient::request_fingerprint(canonical_request_bytes);
if let Some(cached) = cache.get(&key, ttl_secs) {
return Ok(cached);
}
let result = client
.poll_response_with_config(ticket, config)
.await?;
cache.set(&key, &result, ttl_secs);Логика простая: один реальный запрос при первичной проверке, повторные сессии берутся из кеша. Это быстро окупится, когда появится тариф.
Про трейсинг
Клиент логирует через стандартный трейт tracing. Если у вас уже есть tracing-subscriber, работает просто:
DEBUG smev4_rs: starting SMEV queue polling ticket="tkt_abc" max_attempts=12
WARN smev4_rs: SMEV provider unavailable ticket="tkt_abc" status=503 reason=ServiceDegraded
DEBUG smev4_rs: SMEV queue response ready ticket="tkt_xyz" attempts=3warn для недоступности и таймаутов. Эти события должны триггерить алерты, а не просто попадать в дефолтный поток дебаг-логов.
Отдельно про аттестацию ФСТЭК
После 20 апреля стало очевидно: аттестат ФСТЭК перестал быть просто бумагой для службы безопасности. Он стал условием доступа к критически важной функции.
Приказ №117 изменил модель: теперь это не разовый проект, а непрерывный процесс с пересчётом показателей и жёсткими сроками устранения уязвимостей (критические за 24 часа). Для команд, которые привыкли раз в несколько лет обновлять аттестат, это другой операционный ритм.
Банки, у которых аттестат был актуальным, получили доступ обратно 20 апреля. У остальных простой продолжается.
В итоге
Сбой доступа в апреле 2026 года не является уникальным событием.
В 2021 году МВД объявило о закрытии офлайн-файла паспортов. В 2023 году закрыло. В 2026 году временно закрыло СМЭВ-доступ.
Паттерн один: зависимость критических процессов от государственного контура, у которого нет договорных обязательств обеспечивать непрерывность для потребителей.
Это архитектурный факт, который нужно учитывать при проектировании.
Крейт smev4-rs с реализацией, о которой я написал, опубликован на crates.io под Apache-2.0: smev4-rs. Исходный код доступен на GitHub.
Если кто-то работает с СМЭВ на Rust, посмотрите, буду рад обратной связи.
Источники
Банки лишились доступа к сервису проверки паспортов МВД · Коммерсантъ, 16 апреля 2026
Банки лишились доступа к паспортным данным клиентов через базу МВД · РБК, 16 апреля 2026
Крупнейшим банкам вернули доступ к проверке клиентских паспортов · Коммерсантъ, 20 апреля 2026
Документы вернулись в оборот · Коммерсантъ, 20 апреля 2026
Информационное сообщение ФСТЭК №240/22/1492 · ГАРАНТ
Постановление Правительства №1687