«MiCA розшифровано»: ваша технічна документація щодо криптовалюти не може бути просто Gitbook або PDF-файлом

«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 виділяє три окремі категорії, кожна з яких має власний шаблон білої книги та вимоги до полів:

Категорія визначає не лише зміст технічного документа, а й весь юридичний шлях до його подання. Проект не може вибрати категорію на власний розсуд. Це визначається характеристиками активу, а звідси випливають зобов'язання щодо підготовки.

Хто несе юридичне зобов'язання — і відповідальність

Для переважної більшості токенів на ринку (віднесених до категорії «Інші» криптоактиви, або 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 року. Зміст статті має виключно інформаційний характер і не є юридичною порадою.