MiCA Decoded — це щотижнева серія з 12 статей для Bitcoin.com News, співавторами якої є співзасновники та керуючі директори LegalBison: Аарон Глауберман, Віктор Юськін та Сабір Алієв. LegalBison консультує криптовалютні та FinTech-компанії з питань ліцензування MiCA, заявок CASP та VASP, а також регуляторного структурування в Європі та за її межами.
Згідно з MiCA, білий список є обов'язковим інструментом правового розкриття інформації. Його найближчим аналогом у традиційних фінансах є проспект цінних паперів, а не маркетинговий документ. Регулювання визначає, хто має його підготувати, в якому форматі, з якими ідентифікаторами, за якої автоматичної верифікації та з відповідальністю, прикріпленою до конкретної названої особи.
Помилка в будь-якому з цих елементів означає, що документ не існує в очах європейських регуляторів, незалежно від того, наскільки добре він написаний.
Ця шоста стаття MiCA Decoded розбирає, що це насправді означає, частина за частиною.
Міф: білий список MiCA — це просто GitBook або PDF
Білий список MiCA має вагу формального регуляторного подання.
Імплементаційне регулювання Комісії (ЄС) 2024/2984, яке регулює форми, формати та шаблони для білих списків криптоактивів, вимагає, щоб документ був підготовлений у структурованому цифровому форматі, розробленому так, щоб ESMA та національні компетентні органи всіх держав-членів ЄС могли проводити ідентичний автоматизований аналіз кожного подання, незалежно від того, хто його подав або де.
Юридична мета цього дизайнерського рішення важливіша за технічні деталі. MiCA — це регулювання єдиного ринку, і порівнянність між поданнями є основним інструментом забезпечення виконання.
Білий список, який не може бути прочитаний тією ж машиною, що й кожен інший білий список, поданий в Європі, не відповідає вимогам, що б не говорив його зміст. ESMA опублікувала необхідну таксономію (структуровану систему, яка визначає, що має містити відповідний білий список) 5 серпня 2025 року. Правила застосовуються з 23 грудня 2025 року.
Зобов'язання щодо розкриття інформації варіюються залежно від типу криптоактиву. MiCA виділяє три різні категорії, кожна зі своїм шаблоном білого списку та вимогами до полів:
| Тип активу | Хто готує білий список | Ключова характеристика |
| OTHER (Інші криптоактиви, наприклад, утиліті токени) | Пропонувач, особа, яка запитує допуск до торгівлі, або CASP, що керує торговою платформою | Найширша категорія; охоплює більшість токенів, які зараз на ринку |
| ART (Токени, прив'язані до активів) | Авторизований емітент або кредитна установа | Посилається на кошик активів; авторизація потрібна перед випуском |
| EMT (Токени електронних грошей) | Кредитна установа або установа електронних грошей | Прив'язка до однієї валюти; потрібна авторизація EMI або банківська |
Категорія визначає не лише зміст білого списку, але й весь юридичний шлях до його подання. Проєкт не може вибрати, яка категорія застосовується, виходячи з уподобань. Характеристики активу визначають це, і зобов'язання щодо підготовки випливають звідти.
Хто несе юридичне зобов'язання – і відповідальність
Для переважної більшості токенів на ринку (категоризованих як «Інші» криптоактиви, або OTHR), зобов'язання не автоматично покладається на суб'єкт, який створив токен. Для цих активів MiCA покладає зобов'язання на пропонувача або особу, яка запитує допуск до торгівлі, які є визначеними ролями, що можуть збігатися або не збігатися з оригінальним емітентом.
Ця відмінність має реальні наслідки. Проєкт, що потрапляє в категорію OTHR, запущений з Британських Віргінських островів, Кайманових островів або будь-якої іншої офшорної юрисдикції, може бути пропонувачем згідно з MiCA і безпосередньо нести зобов'язання щодо білого списку, без жодної вимоги переносити своє юридичне місцезнаходження до Європи.
(Примітка: ця структурна гнучкість строго застосовується до токенів OTHR. Для токенів, прив'язаних до активів, та токенів електронних грошей юридичне зобов'язання та сувора цивільна відповідальність за білий список повністю покладаються на авторизованого емітента ЄС і не можуть бути делеговані).
Як ми розглянули в другій частині цієї серії, реєстри ESMA підтверджують, що це вже стандартна практика: більшість незалежних подань токенів надходить від суб'єктів зі штаб-квартирою за межами ЄС.
CASP, що керує торговою платформою, також може взяти на себе зобов'язання щодо білого списку, або за власною ініціативою, або за письмовою угодою з командою проєкту. Це не лазівка і не адміністративна зручність.
Коли CASP подає, він бере на себе юридичну відповідальність за точність і повноту розкриття інформації. Якщо білий список містить оманливу інформацію або не відповідає регуляторним стандартам, відповідальність належить тому, хто його подав.
Особа, яка підписує білий список, не може делегувати цю відповідальність постачальнику програмного забезпечення, технічному інтегратору або юридичній фірмі. Юридична перевірка змісту та технічна валідність — це два окремі зобов'язання щодо відповідності, і обидва покладаються на пропонувача. Це момент, який більшість проєктів недооцінюють.
Два коди, які мають існувати до початку подання
Два обов'язкові ідентифікатори є попередніми умовами для будь-якого відповідного білого списку. Обидва взяті з міжнародних стандартів, які передували MiCA. Регулювання не створило їх, воно зробило їх обов'язковими.
Перший — це ідентифікатор юридичної особи (LEI), код ISO 17442, присвоєний юридичним особам і підтримуваний у глобальній базі даних LEI, яку керує GLEIF. Мандат на його використання охоплює кілька регуляторних стандартів: тоді як стаття 14 RTS з ведення обліку (делегований регламент Комісії ЄС 2025/1140) забезпечує виконання вимог LEI для CASP щодо їхніх клієнтів, стаття 3 RTS з класифікації білого списку (делегований регламент Комісії ЄС 2025/421) суворо вимагає, щоб усі підготувачі білого списку ідентифікували свою власну юридичну особу за допомогою дійсного коду LEI. Для будь-якого суб'єкта, який ще не має його, процес подання заявки на LEI має бути завершений до початку підготовки білого списку.
Другий — це ідентифікатор цифрового токену (DTI), код ISO 24165, який ідентифікує сам криптоактив, підтримується в реєстрі DTIF. Стаття 15 RTS з ведення обліку та стаття 3 RTS з класифікації білого списку (делегований регламент Комісії ЄС 2025/421) вимагають його використання. Оперативний момент для будь-якого проєкту, що запускає новий токен: якщо DTI ще не існує в реєстрі, хтось має запросити його створення до того, як білий список можна буде подати. Якщо CASP подає для активу без централізованого емітента і без існуючого білого списку, платформа відповідає за отримання або запит DTI безпосередньо з DTIF.
Джерело: реєстр DTIF для криптоактивів
Білий список, який не містить дійсних LEI та DTI, не проходить автоматичну валідацію до того, як його побачить будь-який людський рецензент. Проєкти, які досягають етапу подання без обох кодів, стикаються з повним перезапуском.
Автоматизовані ворота і що це означає юридично
Жодна людина в національному компетентному органі не переглядає білий список, який не пройшов автоматичні перевірки. Таксономія ESMA визначає 257 перевірок існування (перевірка наявності обов'язкових полів) і 223 перевірки значень (перевірка дійсності вмісту полів). Подання, яке не проходить перевірку з рівнем серйозності «Помилка», є технічно недійсним. Документ не проходить далі.
Юридичне значення цієї архітектури пряме: технічна валідність і точність змісту є однаково відповідальністю пропонувача. Ідеально складене юридичне розкриття інформації в неправильній структурі не проходить. Структурно дійсний файл з оманливим змістом також не проходить; він просто не проходить на іншому етапі і з іншими наслідками.
Проєкти, що пропонують токени в кількох державах-членах ЄС, стикаються з додатковим рівнем. Кожна мовна версія білого списку вимагає свого окремо структурованого файлу. Усі мовні версії мають бути внутрішньо узгодженими і не просто перекладеними, але ідентично організованими на рівні полів. Переклад, який не відображає структуру оригіналу, технічно не відповідає вимогам, незалежно від його лінгвістичної точності.
Розкриття інформації про сталий розвиток додає подальше обмеження. Таксономія вимагає конкретних одиниць виміру для споживання енергії та викидів CO2: кВт·год та тCO2 відповідно. Це юридичні вимоги щодо розкриття інформації, а не необов'язкова екологічна звітність. Подання з різними одиницями або пропуск полів викликає невдалу валідацію.
Схема для всіх цих вимог однакова: білий список є юридичним поданням із стандартами, що забезпечуються машиною. Проєкти, які підходять до нього як до вправи з написання документа, а не як до процесу відповідності зі структурованими попередніми умовами та автоматизованим контролем, зіткнуться з цим забезпеченням виконання до того, як досягнуть людського регулятора.
Що це означає на практиці
Популярне розуміння криптовалютного білого списку як наративної презентації (чогось написаного для переконання, а не для розкриття інформації) описує тип документа, який MiCA замінила на щось категорично інше.
Білий список MiCA є юридичним інструментом із приписаним змістом, обов'язковими ідентифікаторами, структурованим форматом, розробленим для автоматизованої транскордонної порівнянності, та іменною особистою відповідальністю, прикріпленою до того, хто підписує його. Вхідні ворота до європейського ринку криптовалют проходять через нього. Проєкти, які розуміють подання таким, яким воно є юридично, а не тим, що історично означав термін, — це ті, що не повертаються назад при автоматичній перевірці.
Ключові висновки:
- Білий список — це не маркетинговий документ. MiCA перевизначила термін. Найближчий еквівалент у традиційних фінансах — це проспект цінних паперів, і його слід розглядати з тією ж юридичною вагою.
- Три категорії активів, три різні шляхи. OTHR, ART та EMT мають різні вимоги до білого списку та різні попередні умови авторизації. Характеристики активу визначають, яка категорія застосовується, проєкт не вибирає.
- Відповідальність слідує за подавцем, але правила залежать від активу. Для переважної більшості токенів (OTHR) юридичне зобов'язання належить пропонувачу або особі, яка запитує допуск до торгівлі, не обов'язково оригінальному творцю токену. Коли CASP (наприклад, оператор торгової платформи) погоджується підготувати та опублікувати білий список від імені проєкту OTHR, він бере на себе значні регуляторні обов'язки, але не приймає відповідальність повністю. Згідно зі статтею 14(3) MiCA, оригінальна особа, яка запитує допуск до торгівлі, залишається юридично відповідальною, якщо вона надає неповну, несправедливу, незрозумілу або оманливу інформацію CASP. Ви можете передати документообіг на аутсорсинг, але ви не можете повністю передати відповідальність на аутсорсинг.
- Для токенів, прив'язаних до активів (ART), та токенів електронних грошей (EMT), сувора цивільна відповідальність за білий список покладається не лише на авторизованого емітента як корпоративну особу; вона чітко поширюється на членів його адміністративного, управлінського або наглядового органу. Будь-яка договірна спроба обмежити або виключити цю відповідальність є юридично недійсною.
- LEI та DTI є попередніми умовами. Обидва ідентифікатори мають бути на місці до початку підготовки білого списку. Якщо DTI не існує для активу, його треба запросити з реєстру DTIF до того, як щось інше рухатиметься вперед.
- Автоматична валідація — це перший привратник. 257 перевірок існування та 223 перевірки значень виконуються до того, як будь-яка людина переглядає файл. Документ, який не проходить твердження рівня помилки, не досягає регулятора.
- Багатомовні подання несуть приховане технічне зобов'язання. Кожна мовна версія вимагає свого окремо структурованого файлу, організованого ідентично оригіналу. Переклад, який не відповідає структурі джерела на рівні полів, не відповідає вимогам.
- Точність змісту та технічна валідність — це два окремі зобов'язання. Юридична перевірка охоплює перше. Технічне структурування охоплює друге. Обидва покладаються на пропонувача, і жодне не замінює інше.
Ця стаття базується на дослідженні, проведеному LegalBison у квітні 2026 року. Зміст призначений лише для інформаційних цілей і не є юридичною консультацією.
Джерело: https://news.bitcoin.com/mica-decoded-your-crypto-white-paper-cant-just-be-a-gitbook-or-pdf/
