Требования MiCA к белой книге для выпуска токенов (2026)

Что нужно раскрыть, чтобы запуститься в ЕС?

К 2026 году MiCA уже не «скоро вступит в силу». Это рабочая реальность для выпускателей токенов в ЕС. Если вы планируете предложить токен широкой публике или добиться его допуска к торгам в Европе, вам нужна белая книга, соответствующая MiCA.

Называем вещи своими именами: это не презентация для инвесторов и не рекламная страница. По MiCA белая книга работает как официальный документ с раскрытием сведений, на который могут опираться регуляторы и участники рынка. Если в ней есть вводящие в заблуждение заявления, пробелы или противоречия с тем, как токен реально устроен, отвечать за последствия будет выпускатель.

Белая книга по MiCA: что это и зачем она нужна

Белая книга по MiCA это стандартизированный документ, который простым и проверяемым языком объясняет:

• кто такой выпускатель и как устроено управление;
• для чего нужен токен;
• как работают выпуск и экономика токена;
• какие основные риски есть (технические, рыночные, операционные, правовые);
• какие права есть у держателей токена и как рассматриваются жалобы.

Белая книга обязательна для служебных токенов, токенов, привязанных к активам, и электронных денежных токенов, если их предлагают в ЕС или допускают к торгам в ЕС.

Почему MiCA на этом настаивает:

• чтобы предложения токенов можно было сопоставлять между странами ЕС;
• чтобы снижать скрытые риски и «выборочную прозрачность»;
• чтобы закреплять личную ответственность эмитента;
• чтобы защищать розничных покупателей через структурированное раскрытие.

Что MiCA требует: основные разделы белой книги

Логика раскрытия в MiCA простая: описать токен и эмитента так, чтобы это было конкретно, внутренне согласованно и не вводило в заблуждение.

1) Сведения о выпускателе, структуре и контроле

В белой книге нужно чётко указать:

• официальное наименование эмитента , организационно-правовую форму и зарегистрированный адрес;
• сведения о регистрации и корпоративные идентификаторы;
• страну ЕС, которая важна для надзора и уведомления;
• модель управления (кто в совете/руководстве за что отвечает);
• внутренние процедуры контроля и устройство соблюдения требований.
  

Смысл в проверяемости: регулятор должен видеть, кто отвечает и как принимаются решения.

2) Устройство токена и экономика (без пустых слов)

Нужно объяснить:

• для чего токен нужен (для служебных токенов) и чем он не является;
• какие права, если они есть, даёт владение токеном;
• как выпускается токен, как определяется общий объём и график выпуска;
• как устроены распределение и продажа;
• правила выпуска/сжигания/стейкинга/погашения, если это применимо;
• где и как технически выпускается токен (сеть/протокол).

Если человек не понимает, как работают объём и распределение, значит раскрытие провалено.

3) Риски, которые соответствуют реальной модели

MiCA ждёт риски, связанные именно с вашим продуктом, а не общие фразы уровня «криптовалюты рискованные». Обычно раскрывают:

• рыночные риски и влияние волатильности;
• уязвимости смарт-контрактов и риски кибербезопасности;
  
• операционные риски (сбои процессов, зависимость от ключевых людей, подрядчики);
  
• риски ликвидности и реалистичные сценарии потерь;
  
• правовые и надзорные неопределённости, влияющие на токен или модель.
  

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

4) Использование привлечённых средств и план работ (если собираете деньги)

Если выпуск связан со сбором средств, раскройте:

• цель сбора;
• распределение средств по понятным статьям;
• план выполнения и этапы;
• правила управления казной и контроль расходов.

Именно тут регуляторы и опытные участники рынка смотрят, «вы строите продукт или просто продаёте легенду».

5) Технологии и уровень защиты

Белая книга должна содержать:

• практичное описание технической архитектуры;
• меры защиты и подход к реагированию на инциденты;
• состояние проверок (проверки проведены, запланированы или отсутствуют);
• критические зависимости и третьих лиц (хранение, интерфейсы, инфраструктура).

Не нужно публиковать секреты безопасности. Нужно честно описать реальность.

6) Права держателей, жалобы и что будет при прекращении проекта

Определите:

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

Это не «по желанию». Это часть юридических обязательств эмитента.

Публикация белой книги по MiCA: как обычно выглядит соблюдение

На практике это процесс, а не «сохранить в PDF»:

• подготовить белую книгу по приложению MiCA (Приложение II) и стандартам ESMA, если они применимы;
• провести проверку согласованности: экономика токена vs технология vs публичные заявления;
• уведомить компетентный орган (например, ЧНБ в Чехии, в зависимости от структуры и обязанностей);
• опубликовать на сайте эмитента до публичного предложения или допуска к торгам;
• обновлять при существенных изменениях (модель, риски, управление, зависимости).

Важное различие:

• токены, привязанные к активам, и электронные денежные токены обычно требуют предварительного разрешения/одобрения до предложения и публикации;
• служебные токены чаще идут по маршруту «уведомление + публикация» без предварительного одобрения, но с теми же требованиями к содержанию и точности.

Кто отвечает по MiCA

Обязанности по белой книге касаются:

• выпускателей, предлагающих служебные токены / токены, привязанные к активам / электронные денежные токены в ЕС;
• проектов, добивающихся допуска токена к торгам в ЕС;
• продаж токенов ради привлечения средств;
• и косвенно поставщиков услуг с криптоактивами, которые листят токены (потому что листинг потребует доказуемого соблюдения требований эмитентом).
  

В 2026 году работать без соответствующей белой книги это не хитрость. Это просто лишний, легко устранимый риск.

Типичные провалы белых книг по MiCA (которые заметны регулятору)

Обычно ломаются на одном и том же:

• расплывчатые, шаблонные риски;
• отсутствие внятного описания ключевой механики (особенно смарт-контрактов);
• заявления, которые звучат как реклама, но по смыслу выглядят как обещания;
• противоречия между белой книгой, сайтом и реальным поведением токена;
• старые версии на сайте после существенных изменений.

MiCA ожидает постоянной точности. Подход «опубликовали и забыли» это приглашение к проблемам.

AMS Europe: практическая помощь с белой книгой по MiCA

AMS Europe помогает выпускателям токенов подготовить белую книгу по MiCA, которая соответствует реальной модели токена, управлению и стратегии выхода на рынок ЕС. Обычно это включает: определение применимых требований (что и почему), структуру документа, формулировку рисков, согласование технического раскрытия и финальную проверку на соответствие требованиям.

Цель простая: белая книга, которая выдерживает проверку, снижает трения с регулятором и не порождает переделки при движении к листингу или распространению.

Вопросы и ответы: требования MiCA к белой книге

Что именно требует MiCA в белой книге токена?

Структурированное раскрытие о выпускателе и управлении, назначении и механике токена, обзоре технологии, рисках, использовании средств (если привлекаются), уровне защиты и проверок, правах держателей, а также порядке жалоб и споров. Текст должен быть ясным, точным и не вводить в заблуждение.

Кто обязан публиковать белую книгу по MiCA?

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

ужно ли предварительное одобрение регулятора для белой книги служебного токена?

Обычно нет. Как правило, белую книгу по служебному токену публикуют после уведомления, но требования к содержанию и раскрытию всё равно обязательны.

Нужно ли одобрение для токенов, привязанных к активам, и электронных денежных токенов?

Да. Такие токены обычно требуют разрешения/одобрения компетентного органа до публичного предложения и до завершения процедуры по белой книге.

Какие слабые места встречаются чаще всего?

Шаблонные риски, невнятная экономика токена (объём/распределение), отсутствие описания уровня защиты, противоречия между документами и неактуальные версии после существенных изменений.