В конце июня 2026 года Минцифры вынесло на общественное обсуждение проект постановления о базе идентификаторов мобильных устройств: операторы связи и ФТС будут автоматически передавать в нее данные IMEI. Формально это часть пакета «Антифрод-2». Для оператора же это не история про регистрацию телефонов гражданами, а новый обязательный контур данных, где устройство, SIM, абонента и события сети придется связывать между собой.

Что произошло

26 июня 2026 года президент подписал закон, который в отрасли называют «Антифрод-2», — второй пакет мер против кибермошенничества. Одна из его норм — создание единой базы IMEI, уникальных 15-значных идентификаторов мобильных устройств. Почти сразу Минцифры разместило для общественного обсуждения проект постановления правительства о правилах работы этой базы и проект приказа о порядке взаимодействия операторов с ее оператором. Закон вступает в силу с 1 сентября 2026 года, а детали — то есть самое важное для ИТ — пока остаются на уровне проектов.

Стоит сразу зафиксировать, о чем речь и о чем не речь. Массовой ручной постановки телефонов на учет не предполагается. Данные об IMEI передают те, у кого они и так есть: операторы, которые ранее регистрировали устройство в своей сети, и ФТС — при ввозе. Гражданин регистрирует аппарат сам только в одном случае — если купил новый телефон за рубежом и ввез его в Россию; сделать это можно по желанию на Госуслугах. Все остальное — автоматический обмен данными между операторами и государственными системами: ЕПГУ, системами Роскомнадзора, таможенных органов, Минпромторга.

Вот здесь тема и перестает быть новостной. Для оператора автоматический обмен данными об устройствах — это не строчка в законе, а требование к собственной архитектуре: нужно уметь отдавать корректный IMEI, связывать его с абонентом и SIM, отрабатывать статусы и блокировки, вести историю изменений и делать все это в защищенном режиме и круглосуточно.

Почему IMEI — это не просто номер устройства

За привычными «номер телефона» и «симка» стоит несколько разных сущностей. Оператор ведет их давно, но чаще всего — в разных системах.

MSISDN, телефонный номер, — это идентификатор услуги и абонентского доступа. Он живет в биллинге и CRM, переносится при MNP, у одного и того же человека может меняться. SIM или eSIM — носитель профиля абонента в сети, физическая карта или ее программный аналог, к которому привязан доступ к услугам. IMEI — идентификатор самого аппарата: не карты и не владельца, а устройства, и он не меняется при смене SIM. Абонент — клиентская сущность: договор, лицевой счет, обращения, история платежей; она живет в CRM и биллинге. И наконец события сети — регистрация, сессии, факт использования услуги — показывают, как связка «устройство плюс SIM плюс абонент» ведет себя в реальности.

По отдельности каждый из этих объектов оператору знаком. Антифрод же требует другого — видеть связи между ними. Подменный IMEI, устройство из «серого» ввоза, аппарат, засветившийся в мошеннической схеме, выявляются не по одному признаку, а по сопоставлению: какое устройство, с какой SIM, у какого абонента, в каких сессиях. База IMEI добавляет к этой картине внешний статус устройства — разрешено оно или запрещено к использованию на территории РФ. Чтобы этим статусом можно было пользоваться в реальных процессах, а не хранить его отдельной справкой, оператор должен уметь связать его со всем остальным.

Какие системы оператора попадают в IMEI-контур

Задача «принимать и отдавать статус устройства» звучит узко, но затрагивает почти весь стек BSS/OSS.

CRM хранит клиента, договор и обращения. Когда абонент приходит с жалобой «телефон заблокировали», оператору нужно на одном экране видеть и клиента, и его устройство, и причину блокировки. Биллинг ведет договор, услуги, финансовые ограничения и блокировки — статус устройства может влиять на доступность услуг, а значит, должен быть согласован с логикой начислений. OCS и real-time charging контролируют потребление услуг в момент, когда оно происходит; если устройство переходит в запрещенный статус, реакция нужна быстрая, а не «по итогам суток».

Ниже по стеку работает mediation — сбор и нормализация событий сети. Именно оттуда берутся данные о том, какой IMEI с какой SIM реально присутствует в сети. Service Provisioning исполняет команды на сетевое оборудование: подключить, ограничить, заблокировать, — и решение о статусе устройства должно доходить до сети через управляемый провижининг, а не через ручную операцию инженера. DWH, DMP и BI дают аналитику и выявление аномалий: нетипичные связки IMEI и SIM, устройства с признаками подмены, всплески активности по конкретным аппаратам. Антифрод-контур — это правила и риск-сценарии, которые используют все перечисленное как вход. А API-слой — то, через что оператор обменивается данными с базой IMEI и остальным государственным контуром в защищенном и проверяемом виде.

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

Где это обычно ломается

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

Справочники не совпадают: в биллинге абонент один, в CRM — с чуть другим набором атрибутов, в антифроде — третья версия. Данные расходятся во времени: событие в сети уже произошло, а в аналитике оно появится через час или к утру. Часть сверок держится на ручных выгрузках — Excel, сопоставление, загрузка обратно. Единого статуса устройства нет ни в одной системе, потому что раньше он и не требовался. Историю изменений — когда, кто и на каком основании поменял статус или связку — восстановить трудно. И ко всему этому добавляется требование защищенного обмена с внешней системой и растущие требования к аудиту: кто, когда и зачем передал или запросил данные.

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

Какой должна быть целевая архитектура

Ответ на новое требование — не еще одна точечная интеграция «сбоку», а управляемый контур данных, который потом можно расширять. Его опорные принципы вполне понятны.

В основе — единая модель данных, где клиент, договор, SIM или eSIM, устройство, услуга и событие связаны между собой, а не лежат отдельными списками. У устройства появляется свой профиль уровня golden record — с историей и текущим статусом. Дальше — API-first и событийная интеграция: системы обмениваются не ночными выгрузками, а событиями в момент, когда что-то произошло. Изменился статус устройства — об этом сразу узнают биллинг, charging и провижининг. События сети приводятся к единому виду в mediation-контуре, чтобы данные о том, какой IMEI и с какой SIM работает, годились и для антифрода, и для аналитики.

Отдельный слой — управляемость. История изменений хранится и проверяема: по каждому устройству и связке видно, когда и на каком основании менялся статус. К этому добавляются разграничение прав доступа, мониторинг обменов и audit trail, который можно предъявить и внутреннему контролю, и регулятору. Ничего экзотического в этом наборе нет. Сложность не в отдельном принципе, а в том, чтобы все они работали в одном контуре, а не в семи разных системах с ручными мостами между ними.

Здесь тема смыкается с тем, чем Forward занимается по сути своей продуктовой линейки. Компания развивает BSS/OSS как набор связанных компонентов — CRM, Product Catalog, Billing, Fusion/OCS, Mediation, Service Provisioning, DMP/BI и интеграционный слой, — которые закрывают расчет, обслуживание, управление услугами, сбор событий и обмен с внешними системами. Forward Fusion отвечает за контроль баланса и тарификацию услуг в реальном времени и поддерживает CAMEL, DIAMETER, Radius и другие интерфейсы. Для задачи вроде базы IMEI важно не наличие отдельной «системы под IMEI», а то, что устройство, SIM, абонент, услуга и событие живут в одном управляемом контуре и связываются между собой.

Что это значит для оператора

База IMEI — не последняя инициатива такого рода. Логика «Антифрод-2» и родственных мер в том, что от операторов все чаще требуют не просто хранить данные, а обмениваться ими с внешними системами — в реальном времени и в проверяемом виде. За устройствами, скорее всего, последуют новые контуры: по услугам, абонентам, событиям.

Поэтому выигрышная стратегия — не дорабатывать под каждое новое требование отдельную интеграцию, а один раз выстроить контур данных, в котором сущности связаны, обмен идет через API и события, а история и доступ проверяемы. Тогда очередное требование становится настройкой в уже работающей архитектуре, а не отдельным проектом с ручными сверками.

Антифрод в телекоме начинается не с новой системы проверок, а со связности данных. Оператор, у которого устройство, SIM, абонент и события сети видны в одном контуре, отвечает на регуляторные требования быстрее — и, что важнее, сам точнее понимает, что происходит в его сети.