Регулирование в Казахстане: что меняется в BSS/OSS оператора

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.