20 августа 2026 года заработала основная часть изменений в Закон Республики Казахстан «О связи», внесённых Законом РК от 19 июня 2026 года № 320-VIII. Формально это пакет про развитие телекоммуникаций, защиту абонента и противодействие мошенничеству. Практически — это ещё и список требований к биллингу.

Разница существенная. Норму вроде «предупредить абонента о повышении тарифа заранее» можно закрыть регламентом и рассылкой. Норму «этот трафик не тарифицируется никогда» регламентом закрыть нельзя: она либо живёт в каталоге продуктов, charging и policy control, либо не работает вообще.

Регулирование переехало в операционный контур

Раньше телеком-compliance держался на лицензиях, договорах и периодической отчётности. Сейчас регулятор всё чаще описывает не документ, а поведение системы в реальном времени.

Из казахстанского пакета:

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

Ни одно из этих требований не проверяется по бумагам. Всё проверяется по логам.

MVNO: у модели появилось определение

Закон теперь определяет виртуального оператора прямо: «виртуальный оператор сотовой связи – оператор связи, использующий инфраструктуру одного либо нескольких операторов сотовой связи для предоставления услуг сотовой связи» (пп. 67-6 ст. 2).

Для рынка интереснее другая часть. Статья 12 относит работу MVNO к случаям совместного использования радиочастот и сетей связи, которое оформляется договором. Host-оператор предоставляет доступ к инфраструктуре своей сети «при наличии технической возможности и отсутствии загруженности сети связи». И указывает в договоре вид технологии, в котором виртуальный оператор может оказывать услуги.

Последнюю формулировку стоит перечитать дважды. Вид технологии, записанный в договоре, фактически ограничивает каталог продуктов MVNO. Если виртуальный оператор продаёт то, чего host-сеть ему по договору не даёт, проблема всплывёт не в юридическом отделе, а в активации и в претензиях абонентов. Значит, ограничение должно жить в правилах eligibility и в provisioning, который умеет отказать автоматически.

Условие про техническую возможность и загруженность работает похожим образом. Формулировка не абсолютная, поэтому отношения host-MNO и MVNO нуждаются в измеримых метриках и понятной привязке к wholesale-договору. Иначе спор о том, была ли сеть загружена, превращается в спор без данных.

Для host-оператора всё это означает, что MVNO перестаёт быть «ещё одним партнёром в CRM». Появляется отдельное wholesale-направление со своим жизненным циклом: онбординг партнёра, provisioning абонентов, активация SIM и eSIM, сбор usage, оптовая тарификация, взаиморасчёты, отчётность по SLA, разграничение доступа к абонентским данным.

Про платформенную сторону запуска виртуального оператора мы подробно писали в материале «Казахстан формализует MVNO: почему виртуальному оператору нужна не только сеть, но и BSS-платформа».

Multi-MNO как архитектурный вопрос

Формулировка «одного либо нескольких операторов сотовой связи» — не стилистическая деталь. Она допускает мультисетевую модель, а это сразу меняет требования к платформе:

• управление профилями SIM и eSIM с привязкой к разным host-сетям;
• раздельный сбор и нормализация usage по каждой host-сети;
• расчёт себестоимости и взаиморасчёты отдельно по каждому партнёру;
• разные правила rating и разные ограничения продуктов внутри одного бренда;
• единый клиентский опыт поверх нескольких технических контуров.

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

Для платформы это значит одно: страны региона вполне могут выбрать разные архитектурные подходы к MVNO. Решение, рассчитанное на несколько рынков, должно поддерживать и гибкую мультисеть, и жёсткую привязку к одной host-сети — конфигурацией, а не переписыванием ядра.

Zero-rating соцзначимых приложений: это charging policy, а не скидка

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

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

Что за этим стоит технологически. Трафик приложения нужно надёжно опознавать: домены, IP-диапазоны, эндпоинты API, CDN. Опознанный трафик не должен списываться из пакета и формировать начисления. Доступ обязан сохраняться при нулевом балансе, исчерпанном пакете и ограничении услуг, поэтому проектировать сценарий правильнее на уровне policy, а не тарифного плана. Правила классификации должны версионироваться и обновляться быстро: приложение переезжает на другой CDN или меняет версию API чаще, чем регулятор правит перечень. И объём нетарифицируемого трафика надо уметь показать отдельно.

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

Antifraud как real-time subscriber control

Здесь удобнее думать не про обязанность, а про цикл.

Статья 15-4 закона (введена Законом РК от 30.06.2025 № 205-VIII, с последующими изменениями) описывает интеграцию антифрод-центра Национального Банка с базой данных идентификационных кодов абонентских устройств и базами операторов. При выявлении номера, с которого совершался звонок с признаками мошенничества, оператор обязан уведомить антифрод-центр и передать информацию об абоненте: ФИО, ИИН и оформленные на него абонентские номера. Приостановление услуг такому номеру, включая GSM-шлюзы (сим-боксы), выполняется в порядке и сроки, установленные правилами оказания услуг связи. Правила отводят оператору два рабочих дня на проверку при обращении абонента или при получении информации от антифрод-центра; если признаки мошенничества не подтверждаются, оператор уведомляет об этом центр.

Чтобы цикл проходил без ручной работы, платформе нужны актуальная связка subscriber / SIM / device / ИИН, API-интеграция с внешним контуром, таймеры и контроль сроков, журнал действий с возможностью восстановить хронологию, автоматические уведомления абонента и рабочий сценарий восстановления обслуживания. Последний пункт недооценивают чаще других: заблокировать номер технически проще, чем корректно вернуть его в обслуживание и объяснить абоненту, что произошло.

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

Список требований к платформе получается вполне инженерным:

• актуальная и консистентная абонентская база;
• связка subscriber / SIM / device / ИИН;
• каталог продуктов с версионированием правил и датами вступления в силу;
• online charging с поддержкой исключений из тарификации;
• policy control и классификация трафика;
• взаиморасчёты и оптовая тарификация для MVNO;
• интеграции с антифрод-контуром;
• сквозной audit trail;
• автоматические уведомления абонентов;
• регуляторная отчётность;
• сценарии ограничения и восстановления обслуживания;
• API-интеграции с государственными и финансовыми информационными системами.

Вывод: "compliance-by-design"

Пакет вводится поэтапно. Основная часть норм заработала 20 августа 2026 года, а отдельные положения, связанные с базами идентификационных кодов абонентских устройств и централизованной базой абонентских номеров, вводятся в действие с 1 июля 2027 года. Окно на подготовку есть, но к этой дате часть требований нужно уже эксплуатировать.

Отсюда практический вывод. Умением быстро выпустить новый тариф сегодня никого не удивишь. Гораздо реже платформа умеет так же быстро принять новое регуляторное правило: без доработки ядра, без релиза на каждое изменение перечня, без ручных выгрузок для отчётности. Именно эта способность и превращается в обычное требование к архитектуре BSS/OSS.