Consent wallet для telco: что меняется в управлении согласиями после 2026

Регуляторный фон

В Узбекистане Закон о персональных данных (ЗРУ-547) и связанные акты постепенно ужесточают требования к получению, хранению и отзыву согласия на обработку данных. С развитием биометрических требований для digital banking (с апреля 2026) и общим вниманием регулятора к цифровому доверию (cbu.uz) ожидается, что телекомам придётся показывать более структурированный подход к управлению согласиями.

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

Consent wallet — концепция, в которой все согласия клиента живут в едином месте, клиент видит их и может управлять ими в один клик. Это становится требованием не только регулятора, но и ожиданием клиента.

Что значит consent wallet структурно

Consent wallet — единый слой, в котором:

Перечислены все разрешения, которые клиент дал оператору и партнёрам. Не список «согласен с условиями обслуживания», а конкретно: маркетинг по каналу X, данные для credit scoring, обмен данными с партнёром Y для сценария Z.

Каждое разрешение управляется отдельно. Клиент может отозвать одно, оставив другие.

Каждое разрешение имеет timestamp и контекст. Когда дано, на каких условиях, на какой срок.

Audit trail для каждого изменения. Кто и когда менял (клиент сам, через приложение, через retail или другим легитимным способом).

Виден клиенту в реальном времени. Через приложение оператора, через web-портал.

Без любого из этих компонентов это не consent wallet, а просто более структурированная страница согласий.

Четыре варианта подхода для оператора

Своя сборка. Полностью внутренний consent wallet. Под контролем оператора, кастомизируемый.

Когда подходит. Если оператор имеет сильную техническую способность и планирует долгосрочную независимость от вендоров. Если архитектура данных может поддержать интеграцию consent wallet с downstream-системами.

Когда не подходит. Если техническая способность ограничена, сборка займёт 18-24 месяца и риск delivery высок.

Стоимость. Высокая на старте, средняя в operations. 18-24 месяца разработки.

Платформенное решение. Внешний вендор consent management platform. Интегрируется с существующими системами оператора.

Когда подходит. Если speed-to-market критичен, оператор предпочитает проверенные решения, способность разработки ограничена.

Когда не подходит. Если vendor lock-in неприемлем. Если требования к локализации данных строго локальные.

Стоимость. Средняя на старте (лицензионные платежи), средняя в operations.

Упрощённая модель. Базовое управление согласиями без полного wallet — просто аккуратные согласия в стандартном приложении, без единой видимости.

Когда подходит. Если регуляторные требования пока умеренные. Если объём обмена данными ограниченный.

Когда не подходит. Когда регулятор начнёт требовать полную traceability — модель устареет.

Стоимость. Низкая на старте, средняя в operations.

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

Когда подходит. Если у оператора нет долгосрочной ставки на data-driven продукты и compliance минимален.

Когда не подходит. Когда регулятор переходит к enforcement — реакция стоит больше, чем проактивная сборка.

Стоимость. Низкая на старте, потенциально очень высокая реактивно (штрафы, ускоренная сборка).

Сравнение четырёх

Критерий	Своя сборка	Платформа	Упрощённая	Отказ
Speed to market	18-24 мес	6-12 мес	3-6 мес	0
Кастомизация	высокая	средняя	низкая	n/a
Vendor lock-in	низкий	высокий	средний	n/a
Compliance reach	максимальный	хороший	средний	минимальный
Total cost 5 лет	средняя	средняя-высокая	низкая	потенциально очень высокая
Риск при регуляторном усилении	низкий	средний	высокий	критический

Когда какой выбирать

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

Платформа. Часто разумный выбор — speed-to-market хороший, вендор проверенный, кастомная логика возможна. Главный вопрос — выбор вендора с долгосрочным присутствием в стране.

Упрощённая модель. Подходит как первый шаг для оператора, который только начинает строить управление согласиями. С планом перехода к полному wallet через 12-24 месяца.

Отказ. Самый рискованный вариант. Может казаться экономным сейчас, но реактивная стоимость, когда регулятор начнёт enforcement, обычно в 5-10 раз больше, чем проактивная сборка.

Что должно быть в реальной реализации

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

Понятный UX для клиента. Не таблица в стиле «согласен на всё», а структурированный view с понятными опциями. Большинство клиентов не читают юридический текст — UX должен делать выбор лёгким и осмысленным.

Гранулярные элементы управления. Не «согласие на маркетинг» одним пакетом, а «согласие на SMS-маркетинг», «согласие на email-маркетинг», «согласие на push в приложении», «согласие на партнёрские офферы». Гранулярность даёт клиенту реальный контроль.

Default opt-out для новых категорий. Если оператор добавляет новый тип использования данных, клиент должен явно opt-in, не получать его автоматически.

Применение в реальном времени. Если клиент отзывает согласие — это применяется в течение часов, не недель. Иначе compliance иллюзорно.

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

Когда не запускать большой consent-проект

Если оператор только что прошёл major регуляторный этап и имеет мораторий на новые большие проекты, добавление consent wallet тайминг неподходящий.

Если фундамент данных фрагментирован — данные о согласиях в одной системе, использование в другой, без связки — consent wallet будет косметическим.

Если бюджет на 12-18 месяцев ограничен, своя сборка откладывается до лучшего тайминга.

Если регулятор не сообщает чёткий таймлайн усиления требований, urgency может быть переоценена.

Если в организации нет owner для privacy и data governance, проект не сможет собрать stakeholder.

Что обсудить на committee

Какие 5 типов согласий у нас сейчас и где они хранятся? Если ответ «по-разному» — это и есть проблема.

Какова регуляторная roadmap по согласиям? Что подаёт регулятор и в каком таймфрейме?

Кто owner управления согласиями как функции? Если несколько разных команд — конфликт.

Своя сборка, платформа, упрощённая — что подходит под структуру оператора?

Какой горизонт для полного wallet? 12, 18, 24 месяца?

Что может сделать SamaraliSoft

Consent Management Strategy & Implementation — анализ текущего состояния управления согласиями, оценка регуляторного ландшафта, рамка решения для четырёх вариантов с unit-экономикой, дизайн целевой operating model и UX, оценка вендоров, если выбран путь платформы, и поэтапный rollout в течение 12-18 месяцев.

Внутренние ссылки

• /solutions/telecom-trust-platform-cornerstone/ — trust platform детально
• /insights/telecom-youth-segments-payments/ — биометрия и UX
• /insights/telecom-sim-swap-banking-fraud/ — SIM swap и banking fraud
• /insights/telecom-number-reputation/ — number reputation

Источники

• ЦБ РУ — биометрическая верификация digital banking
• The Paypers — digital banking verification УЗ
• Министерство цифровых технологий — телеком инфраструктура УЗ
• Digital Government Portal — digital infrastructure UZ
• UzDaily — рынок телекома