Запуск MVNO в Центральной Азии: платформа и регулирование

В Казахстане действуют правила выдачи разрешения виртуальному оператору сотовой связи, а с 20 августа 2026 года закон «О связи» определяет и условия доступа MVNO к сети оператора сотовой связи. Регулятор закрепил роли виртуального и базового оператора, состав документов и договорную схему их взаимодействия. За сухой процедурой виден сдвиг поважнее: MVNO в Центральной Азии перестает быть «дешевой связью без своей сети» и встраивается в цифровые экосистемы. А это в первую очередь вопрос не лицензии, а готовности BSS/OSS.

Что изменилось в регуляторике

Правила касаются одной государственной услуги — выдачи разрешения виртуальному оператору. Но именно в их формулировках есть то, чего рынку раньше не хватало: понятные роли. Виртуальный оператор определен как оператор связи, который пользуется инфраструктурой одного или нескольких операторов сотовой связи, чтобы оказывать услуги. Базовый оператор — это лицензированный оператор, с которым виртуальный заключает договор об использовании сети.

Чтобы получить разрешение, заявитель подает заявление через портал цифрового правительства и прикладывает документы, подтверждающие соответствие квалификационным требованиям: договор с оператором сотовой связи, соглашение об использовании инфраструктуры, систему учета трафика и схему взаимодействия с базовым оператором. Правила утверждены приказом от 22 октября 2024 года № 665/НҚ; в мае 2026 года Минцифры Казахстана выносило на обсуждение проект изменений к ним.

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

Почему MVNO интересен не только операторам

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

Банки и финтех смотрят на связь как на продолжение платежного и клиентского опыта: SIM внутри банковского приложения, тарифы, привязанные к карте, кешбэк, единая точка обслуживания. Цифровые экосистемы и суперприложения добавляют мобильную связь к уже собранному набору сервисов — финансам, доставке, медиа. Ритейл использует связь как инструмент лояльности и лишний повод для контакта с покупателем. Провайдеры домашнего интернета достраивают мобильность к фиксированной сети и получают конвергентный продукт. Медиасервисы упаковывают трафик и контент в один тариф. Отдельная история — IoT и M2M, а также корпоративные сервисные провайдеры, которым SIM нужны для устройств, автопарков, платежных терминалов и промышленной телеметрии.

Бизнес-модели у этих игроков разные, но мотив общий. Мобильный номер и трафик — это регулярный контакт с клиентом и еще один источник данных о его поведении. Для экосистемы это нередко ценнее, чем маржа с самой связи.

Договор с хост-оператором — только вход

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

Нужно управлять тарифами и пакетами — и менять их без переписывания систем под каждую акцию. Нужен real-time charging, списание в момент потребления услуги, иначе абонент уходит в минус, а оператор теряет контроль над балансом. Нужна поддержка MNP, чтобы клиент мог прийти со своим номером. Нужны SIM и eSIM с полным жизненным циклом: выпуск, активация, замена, блокировка. Нужен клиентский self-care внутри того самого приложения экосистемы, ради которого все и затевалось. Нужны расчеты с базовым оператором — сверка потребленного трафика и взаиморасчеты по договору. Наконец, нужны отчетность, аналитика и маркетинговые кампании с персональными предложениями, иначе связь остается статьей затрат, а не инструментом удержания.

Каждый из этих пунктов — не функция, а процесс, который должен работать без ручных обходов. Договор фиксирует, кто кому предоставляет сеть; исполняет все остальное BSS/OSS-контур.

Конвергентный продукт — где сложность становится видимой

Насколько это серьезнее «просто мобильной связи», хорошо видно на планах Freedom Holding. В начале июня 2026 года руководство холдинга заявило, что рассчитывает в 2026 году запустить мобильную связь в формате MVNO и находится на финальной стадии переговоров и получения лицензий. Смысл проекта — не отдельный мобильный тариф, а полностью конвергентный продукт, объединяющий мобильную связь, домашний интернет и городские сети Wi-Fi поверх уже собранной экосистемы с банком, страхованием и суперприложением.

Конвергентный продукт ломает привычную логику «один продукт — один баланс — один счет». Как только в одном предложении встречаются мобильный трафик, фиксированный интернет и Wi-Fi, появляется набор требований, который редко закрывается силами одной системы. Мобильные и фиксированные услуги приходится описывать в едином каталоге продуктов, а продавать — пакетами и бандлами, а не набором разрозненных тарифов. Тарификация должна быть гибкой, а в рамках одного счета — уживаться разные типы балансов: деньги, гигабайты, минуты, бонусы. Клиент при этом видит и мобильную услугу, и домашний интернет как один договор в едином профиле, а предложения подстраиваются под то, чем он уже пользуется.

Здесь конвергентный биллинг и real-time charging перестают быть модными словами и становятся условием, без которого продукт не собрать. Forward MVNO Suite — с биллингом, продуктовым каталогом, Fusion/OCS, service provisioning, mediation, BPM, движком MNP и SCD — предназначен для построения MNO/MVNX и обслуживания выделенного сегмента абонентов, где мобильные и конвергентные услуги приходится вести в одном контуре.

MVNO, MVNE, MVNX — что за чем стоит

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

MVNO — это оператор, который продает услуги связи под своим брендом, опираясь на чужую сеть. MVNE — технологическая платформа, которая обеспечивает работу одного или нескольких MVNO: биллинг, charging, интеграции с хост-оператором, поддержку абонентских процессов. Сам MVNE обычно не выходит на рынок под своим именем — он дает инфраструктуру тем, кто выходит. MVNX-подход — это когда одна платформа позволяет собирать разные конфигурации: полноценный full MVNO с максимальным контролем, легкий light MVNO, branded reseller, агентскую модель, white-label для партнеров.

Практический смысл прост. Банку, ритейлеру или экосистеме почти никогда не нужно строить полную операторскую инфраструктуру с нуля. Им нужна MVNO-платформа, на которой можно запустить свою модель — и при необходимости перейти от легкой схемы к более глубокой, не меняя весь контур. А тому, кто планирует не один бренд, а несколько, MVNE- и MVNX-логика становится основой бизнеса, а не архитектурной деталью.

Что должна уметь платформа

Из всего этого складывается вполне конкретный список требований к BSS-платформе для MVNO, и он не сводится к «выставить счет».

Платформа должна быстро выводить новые тарифы и пакеты — счет идет на дни, а не на релизы. Поддерживать prepaid, postpaid и гибридные модели на одном контуре. Считать потребление в реальном времени. Обеспечивать MNP и корректную работу с номерной емкостью. Интегрироваться с хост-оператором по трафику и взаиморасчетам. Отдавать API мобильному приложению или суперприложению — для экосистемного MVNO именно приложение, а не отдельный личный кабинет, становится главным каналом. Масштабироваться под рост абонентской базы без переписывания. Разграничивать данные между суб-клиентами, если на платформе живет несколько брендов. Вести партнерские расчеты. Поддерживать локальную регуляторику — от учета трафика до отчетности, которую требует конкретная страна. И давать аналитику, на которой строятся тарифы и офферы.

Ни один пункт по отдельности не экзотичен. Сложность — в связности: биллинг для MVNO, charging, каталог, provisioning, mediation и партнерские расчеты должны видеть одни и те же данные о клиенте и услуге, а не жить в семи системах с ручными мостами между ними. По опыту таких проектов именно здесь проходит водораздел между «запустились за квартал» и «интегрируемся второй год». В практике Forward greenfield-запуск MVNO-решения занимает около трех месяцев, а перевод действующего оператора на новую BSS в наших проектах занимал от пяти месяцев («ВТБ Мобайл») до двенадцати («Алма ТВ»). Разница во времени объясняется не столько объемом кода, сколько тем, собран ли контур заранее или его достраивают на ходу.

Для проектов такого класса важна не отдельная функция, а платформа, которая закрывает весь путь запуска и развития оператора: биллинг, real-time charging, продуктовый каталог, MNP, provisioning, mediation, партнерские расчеты и клиентские интерфейсы. Это ровно тот класс задач, под который развиваются MVNO- и MVNE-решения Forward — не как набор отдельных модулей, а как связанный контур монетизации и обслуживания.

Вывод

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

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