# Регулирование в Казахстане: что меняется в BSS/OSS оператора Источник: https://fw-t.ru/articles/mvno-zero-rating-i-antifraud-kak-novoe-regulirovanie-kazahstana-menaet-bss-oss-operatorov Опубликовано: 2026-08-27 · Обновлено: 2026-09-09 Как новые требования казахстанского регулятора отражаются на расчетном контуре оператора: раздельная тарификация трафика, учет и контроль, доработки биллинга. **Коротко.** Каждое новое требование регулятора превращается в доработку расчетного контура и личного кабинета оператора. Раздельная тарификация отдельных категорий трафика требует связки биллинга с системой анализа трафика, контроль злоупотреблений — сверки данных сети с расчетом. Разбор того, что именно меняется в системах оператора. 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-платформа»](/articles/mvno-platforma-bss-oss-centralnaya-aziya). ## Multi-MNO как архитектурный вопрос Формулировка «одного либо нескольких операторов сотовой связи» — не стилистическая деталь. Она допускает мультисетевую модель, а это сразу меняет требования к платформе: - управление профилями SIM и eSIM с привязкой к разным host-сетям; - раздельный сбор и нормализация usage по каждой host-сети; - расчет себестоимости и взаиморасчеты отдельно по каждому партнеру; - разные правила rating и разные ограничения продуктов внутри одного бренда; - единый клиентский опыт поверх нескольких технических контуров. Соседние рынки СНГ идут к этой теме с другой стороны. В России в августе 2026 года публично обсуждался пакет предложений по работе виртуальных операторов, включая ограничение мультисетевых моделей, отказ от регистрации новых Full-MVNO и минимальный уровень тарификации. Инициатива исходит от операторов рынка, окончательных решений пока нет, так что речь именно об обсуждении, а не о действующем регулировании. Для платформы это значит одно: страны региона вполне могут выбрать разные архитектурные подходы к MVNO. Решение, рассчитанное на несколько рынков, должно поддерживать и гибкую мультисеть, и жесткую привязку к одной host-сети — конфигурацией, а не переписыванием ядра. ## Zero-rating соцзначимых приложений: это charging policy, а не скидка Пункт 5 статьи 20 закона: «Операторы сотовой связи обеспечивают круглосуточное и нетарифицируемое соединение каждому пользователю к мобильным приложениям, имеющим социальное и государственное значение, перечень которых определяется уполномоченным органом». Два фрагмента здесь стоят дороже остальных. «Круглосуточное» означает отсутствие исключений по времени и по состоянию лицевого счета. «Перечень определяется уполномоченным органом» означает, что состав приложений меняется подзаконным актом, без правки закона. Правило будет обновляться чаще, чем тарифная линейка. Первый перечень [утвержден приказом от 21 августа 2026 года](https://www.zakon.kz/pravo/6529439-perechen-mobilnykh-prilozheniy-imeyushchikh-sotsialnoe-i-gosudarstvennoe-znacheniya-utverdili-v-rk.html) и действует с 5 сентября: eGov Mobile, eGov Business, Aitu и Enbek. Что за этим стоит технологически. Трафик приложения нужно надежно опознавать: домены, IP-диапазоны, эндпоинты API, CDN. Опознанный трафик не должен списываться из пакета и формировать начисления. Доступ обязан сохраняться при нулевом балансе, исчерпанном пакете и ограничении услуг, поэтому проектировать сценарий правильнее на уровне policy, а не тарифного плана. Правила классификации должны версионироваться и обновляться быстро: приложение переезжает на другой CDN или меняет версию API чаще, чем регулятор правит перечень. И объем нетарифицируемого трафика надо уметь показать отдельно. Узкое место обычно не в самой тарификации, а в скорости обновления правил классификации. Если каждое изменение доменов требует релиза, норма формально выполнена, а фактически нет. ![Путь трафика социально значимого приложения: классификация, правило политики, исключение из тарификации, отчетность](../../assets/legacy/images/articles/kz-blog-reg-2-1_95.webp) ## Antifraud как real-time subscriber control Здесь удобнее думать не про обязанность, а про цикл. Статья 15-4 закона (введена Законом РК от 30.06.2025 № 205-VIII, с последующими изменениями) описывает интеграцию антифрод-центра Национального Банка с базой данных идентификационных кодов абонентских устройств и базами операторов. При выявлении номера, с которого совершался звонок с признаками мошенничества, оператор обязан уведомить антифрод-центр и передать информацию об абоненте: ФИО, ИИН и оформленные на него абонентские номера. Приостановление услуг такому номеру, включая GSM-шлюзы (сим-боксы), выполняется в порядке и сроки, установленные правилами оказания услуг связи. Правила отводят оператору два рабочих дня на проверку при обращении абонента или при получении информации от антифрод-центра; если признаки мошенничества не подтверждаются, оператор уведомляет об этом центр. ![Цикл обработки антифрод-сигнала оператором: от получения сигнала до восстановления обслуживания](../../assets/legacy/images/articles/kz-blog-reg-2-2_95.webp) Чтобы цикл проходил без ручной работы, платформе нужны актуальная связка 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.