MiCA Compliance Playbook для команд розробки продуктів та технологій

Вступ: Від юридичних вимог до інженерних завдань

Регламент Markets in Crypto-Assets (MiCA) часто сприймається як «суто юридична» тема, проте для менеджерів продуктів, архітекторів рішень та технічних керівників MiCA означає насамперед одне: конкретні вимоги до систем, процесів та архітектури даних. MiCA вимагає не лише документації та політик, а й фактичного технічного впровадження IT-управління, операційної стійкості, менеджменту інцидентів та захисту даних.

Цей Playbook перекладає регуляторні вимоги MiCA, рекомендації ESMA та очікування національних наглядових органів мовою розробки продуктів та інженерії. Він показує, які елементи беклогу виникають, які архітектурні патерни необхідні та які контрольні списки слід опрацювати перед запуском. Основна увага приділяється постачальникам послуг криптоактивів (CASP) у регіоні DACH, проте зміст є актуальним для всіх юрисдикцій ЄС.

Цільова аудиторія: менеджери продуктів, технічні директори (CTO), архітектори рішень, керівники інженерних груп та команди з комплаєнсу криптопроєктів ЄС, які готуються до отримання ліцензії CASP або вже працюють відповідно до MiCA.

Стан інформації: 12 січня 2026 року

1. Обов'язки MiCA, перекладені технічною мовою

MiCA встановлює організаційні вимоги, вимоги до IT-безпеки та аутсорсингу, які мають бути безпосередньо перекладені в конкретні завдання для команд розробки та IT. Наступна таблиця зіставлення пов'язує статті MiCA та рекомендації ESMA з типовими елементами беклогу для продуктових та IT-команд.

Таблиця зіставлення: Норма → Опис → Типові елементи беклогу

Важлива примітка: Ця таблиця призначена для орієнтації та не претендує на повноту. Кожен проєкт повинен провести власний Gap-аналіз та узгодити специфічні вимоги з юридичним відділом та відділом комплаєнсу.

2. Рівні архітектури згідно з MiCA

Архітектуру, що відповідає вимогам MiCA, можна розділити на три основні рівні, кожен з яких має відповідати специфічним регуляторним вимогам:

2.1 Рівень ідентифікації / KYC

Регуляторний контекст: CASP підпадають під дію директив ЄС щодо боротьби з відмиванням коштів (AML) та Регламенту про переказ коштів (TFR / «Travel Rule»). Процеси KYC повинні здійснюватися не лише на початку при реєстрації, а й постійно оновлюватися (поточний моніторинг, періодичні перевірки). Крім того, дані KYC та логіка прийняття рішень мають бути повністю простежуваними та доступними для аудиту.

Технічні вимоги:

• Інтеграція з фреймворками AML: підключення до санкційних списків ЄС/національних рівнів (EU, OFAC, UN), баз даних PEP, скринінгу негативних згадок у медіа, моделей скорингу ризиків.

• Зберігання даних KYC: безпечне, зашифроване зберігання документів, що посвідчують особу, та результатів верифікації; доступ лише за принципом службової необхідності (RBAC).

• Логування рішень KYC: кожне рішення KYC (затверджено/відхилено/ескаловано) має логуватися з міткою часу, особою, що прийняла рішення, обґрунтуванням та використаними точками даних.

• Відповідність Travel Rule (TFR): згідно з Регламентом про переказ коштів діють комплексні зобов'язання щодо надання інформації про криптоперекази (дані відправника/отримувача, адреси гаманців); розширені вимоги при перевищенні порогів (наприклад, 1 000 євро); конкретні вимоги випливають з чинної редакції TFR. Це вимагає технічних рішень, таких як обмін повідомленнями IVMS101 або аналогічні стандарти для обміну інформацією між CASP.

• Зберігання даних: дані KYC повинні зберігатися відповідно до національних законів про AML (зазвичай 5–10 років); водночас слід дотримуватися вимог GDPR (право на видалення при наявності законного інтересу).

Елементи беклогу (приклади):

• Інтеграція KYC-API зі сторонніми постачальниками (наприклад, Jumio, Onfido, Sumsub; зазначені постачальники наведені лише як приклади; MiCA не приписує конкретних провайдерів)

• Впровадження обміну повідомленнями Travel Rule (IVMS101, Notabene, Sygna або власне рішення)

• Створення аудиторського сліду рішень KYC (схема БД, сервіс логування, інтерфейс запитів для комплаєнсу)

• Впровадження RBAC для даних KYC (повний доступ мають лише команда комплаєнсу та призначені аудитори)

2.2 Транзакційний рівень

Регуляторний контекст: MiCA та правила ЄС щодо зловживань на ринку вимагають повної простежуваності ордерів та транзакцій. CASP повинні мати можливість виявляти та повідомляти про підозрілу діяльність (маніпулювання ринком, інсайдерська торгівля, фіктивна торгівля).

Технічні вимоги:

• Наскрізне логування транзакцій: кожен ордер (розміщений, змінений, скасований, виконаний) має логуватися з міткою часу, ID користувача, деталями ордера та деталями виконання.

• Відстеження транзакцій у блокчейні: для транзакцій on-chain: повні логи хешів транзакцій блокчейну, адрес відправника/отримувача, сум, підтверджень.

• Виявлення аномалій та моніторинг: алгоритми або системи на основі правил для виявлення:

• Незвичних обсягів або патернів торгівлі

• Фіктивної торгівлі (wash trading / self-dealing)

• Раптових рухів цін (індикатори Pump & Dump)

• Лейєрингу, спуфінгу, фронтраннінгу

• Можливість реконструкції: наглядовий орган повинен мати можливість відстежити кожну транзакцію від початку до кінця (знімки книги ордерів, логи механізму зіставлення, записи про розрахунки).

• Сповіщення в реальному часі: при підозрі на зловживання на ринку команди комплаєнсу повинні отримувати інформацію в реальному часі (наприклад, через інтеграцію з SIEM або спеціальний інструмент спостереження).

Елементи беклогу (приклади):

• Впровадження сервісу логування транзакцій (високий обсяг, низька затримка, лог тільки для додавання)

• Визначення правил виявлення аномалій (пороги, тригери сповіщень, робочий процес ескалації)

• Створення механізму знімків книги ордерів (періодичні знімки для аудиту/реконструкції)

• Панель спостереження за зловживаннями на ринку для команди комплаєнсу (сповіщення в реальному часі, робочий процес розслідування)

2.3 Рівень даних

Регуляторний контекст: MiCA та AML вимагають суворих політик зберігання даних, тоді як GDPR гарантує право на видалення та портативність даних. Крім того, усі доступи та зміни чутливих даних повинні бути доступні для аудиту.

Технічні вимоги:

• Політики зберігання даних:

• Дані, релевантні для MiCA (ордери, транзакції, логи інцидентів, комунікація з клієнтами): зазвичай 5 років

• Дані AML (KYC, логи моніторингу транзакцій): конкретно визначено відповідним національним законодавством про AML (зазвичай 5–10 років)

• Автоматизоване видалення після закінчення терміну зберігання (якщо немає юридичних заборон на видалення)

• Шифрування при зберіганні та передачі: усі чутливі дані (PII, документи KYC, приватні ключі, деталі транзакцій) повинні зберігатися та передаватися в зашифрованому вигляді. Конкретні технічні стандарти (наприклад, алгоритм, довжина ключа, версія протоколу, як-от AES-256, TLS 1.2+) мають бути визначені на основі поточних ринкових стандартів та внутрішнього апетиту до ризику; MiCA не приписує конкретних алгоритмів.

• Аудиторський слід доступу до даних: кожен доступ до чутливих даних (хто, коли, які дані, мета) має логуватися.

• Резервне копіювання та аварійне відновлення:

• Регулярні бекапи (щодня або частіше для критичних систем)

• Зберігання за межами об'єкта (географічно відокремлене)

• Визначення та тестування цільової точки відновлення (RPO) та цільового часу відновлення (RTO)

• Проведення тренувань з відновлення (щонайменше раз на рік)

• Географія даних та аутсорсинг: при хмарному зберіганні має бути чітко зрозуміло, де фізично зберігаються дані (ЄС vs поза межами ЄС). При зберіганні поза межами ЄС можуть виникнути додаткові вимоги щодо захисту даних та нагляду.

Елементи беклогу (приклади):

• Впровадження механізму політики зберігання даних (автоматизоване управління життєвим циклом даних, архівування, видалення)

• Активація шифрування при зберіганні для всіх БД (RDS Encryption, шифрування дисків, управління ключами через HSM або Cloud KMS)

• Налаштування аудиторського логування для доступу до БД (аудиторські логи БД, інтеграція з SIEM, сповіщення при аномальних патернах доступу)

• Тестування стратегії резервного копіювання (вимірювання RPO/RTO, проведення тренування з відновлення, оновлення документації)

• Створення карти географії даних (які дані де знаходяться? перевірка відповідності правилам аутсорсингу GDPR/MiCA)

3. Наглядові очікування щодо аутсорсингу та хмарних сервісів

Аутсорсинг — особливо критичних IT-функцій та хмарних сервісів — є однією з чутливих тем у межах MiCA. Наглядові органи хочуть переконатися, що CASP не перетворюються на «фіктивні компанії» і що вони в будь-який час зберігають контроль над своїми процесами та даними.

3.1 Принципи аутсорсингу MiCA

Ст. 63(6) MiCA та відповідні пункти преамбули чітко зазначають:

• CASP залишаються повністю відповідальними за функції, передані на аутсорсинг.

• Аутсорсинг не повинен перешкоджати можливості нагляду з боку NCA (тобто наглядовий орган повинен мати доступ до систем, даних та процесів у будь-який час).

• «Важливі» або «критичні» функції (наприклад, комплаєнс, управління ризиками, основні IT-системи) вимагають особливої ретельності та суворіших договірних положень.

• Аутсорсинг не повинен призводити до того, що CASP де-факто втрачає оперативне управління (проблема фіктивної компанії).

3.2 Наглядовий брифінг ESMA щодо авторизації CASP

ESMA у своєму наглядовому брифінгу (розробленому у співпраці з NCA під час перехідного етапу) сформулювала такі очікування:

• Оцінка сутності (Substance Assessment): NCA перевіряють, чи CASP «дійсно» працює в домашній юрисдикції, чи суттєві функції передані на аутсорсинг і залишається лише «фасад».

• Глибина аутсорсингу: чим більше функцій передається на аутсорсинг, тим критичнішою є перевірка. CASP повинні довести, що вони мають власний ключовий персонал ІКТ, здатний контролювати та управляти послугами на аутсорсингу.

• Моніторинг функцій на аутсорсингу: CASP повинні постійно контролювати ефективність та відповідність партнерів з аутсорсингу (SLA, KPI, регулярні аудити).

3.3 Рекомендації ESMA щодо систем та безпеки (ст. 14(1)(d) MiCA)

Хоча ці рекомендації стосуються насамперед емітентів та осіб, які звертаються за допуском до торгівлі, вони містять важливі принципи, релевантні і для CASP:

• Управління ризиками ІКТ третіх сторін: ідентифікація та оцінка постачальників IT-послуг; категорізація за рівнем критичності.

• Контроль субаутсорсингу: партнери з аутсорсингу не можуть просто передавати послуги далі; CASP повинен схвалювати субаутсорсинг та мати видимість усього ланцюжка постачання.

• Договірні застереження: контракти повинні містити:

• Права на аудит для CASP та NCA

• Доступ до даних для наглядових органів

• Управління змінами: партнер з аутсорсингу повинен заздалегідь повідомляти про суттєві зміни та отримувати на них дозвіл

• Вихід/Оборотність: чіткі правила того, як послуги можуть бути передані після закінчення або розірвання контракту

3.4 FMA «Поговоримо про нагляд» – Аутсорсинг основних послуг CASP (Випуск 01)

Австрійське управління фінансового ринку (FMA) у своїй серії публікацій «Поговоримо про нагляд» (випуск 01) спеціально розглянуло тему аутсорсингу основних послуг у CASP:

• Основні послуги включають комплаєнс, управління ризиками, IT-операції та функції кастодіального зберігання.

• FMA наголошує, що аутсорсинг цих функцій можливий лише за суворих умов.

• CASP повинні довести, що вони зберігають реальний контроль над основними послугами на аутсорсингу — через власних співробітників, які є професійно компетентними, через регулярні аудити та через договірні можливості управління.

• FMA у процесі ліцензування інтенсивно перевіряє, чи має CASP достатньо власної сутності (substance), чи існує ризик перетворення на «фіктивну компанію».

3.5 Інструкція AMF DOC-2025-05 (Повна інформація для авторизації CASP)

Французьке AMF у своїй інструкції DOC-2025-05 сформулювало детальні вимоги до повноти заявок CASP, зокрема:

• Документована політика аутсорсингу: опис принципів, за якими приймаються рішення про аутсорсинг (наприклад, оцінка критичності, процес вибору постачальника, поточний моніторинг).

• Реєстр аутсорсингу: детальний список усіх функцій на аутсорсингу із зазначенням постачальника, послуги, терміну дії контракту, критичності.

• Внутрішньогруповий аутсорсинг: у разі корпоративних структур має бути чітко зрозуміло, які послуги надаються дочірніми або материнськими компаніями та як здійснюється управління.

• Плани виходу: для критичного аутсорсингу повинен існувати план виходу (перехід до нового постачальника або інхаус, портативність даних, безперервність послуг).

3.6 Практичні міркування щодо дизайну хмарних рішень та SaaS

Для команд продукту/технологій з цих вимог випливають конкретні міркування щодо дизайну:

Права на аудит у хмарних контрактах:

• Стандартні хмарні контракти (наприклад, AWS, Azure, GCP) зазвичай не містять прямих прав на аудит для клієнтів; натомість вони пропонують сертифікації (SOC2, ISO27001) та звіти про аудит.

• Для цілей MiCA необхідно перевірити, чи достатньо цих сертифікацій, чи потрібні додаткові договірні положення (наприклад, для доступу NCA).

• З постачальниками SaaS слід домовлятися про договірні права на аудит (щонайменше щорічні аудити, доступ для регуляторних інспекцій).

Місцезнаходження та резидентність даних:

• CASP повинні знати, де фізично зберігаються їхні дані (ЄС vs поза межами ЄС).

• При зберіганні поза межами ЄС можуть виникнути додаткові вимоги (наприклад, угоди про обробку даних, рішення про адекватність, стандартні договірні застереження).

• Хмарні провайдери зазвичай пропонують вибір регіону (наприклад, «eu-central-1» для Франкфурта); це має бути закріплено договором та впроваджено технічно (наприклад, через Infrastructure as Code).

Оборотність / Стратегія виходу:

• Хмарні сервіси мають бути спроектовані так, щоб була можлива зміна постачальника або перехід на власне рішення (портативність даних, сумісність API, документація).

• «Залежність від постачальника» (Vendor Lock-In) є проблематичною з точки зору MiCA, оскільки вона обмежує здатність CASP до управління.

• Практично: мультихмарні стратегії або гібридні підходи можуть підвищити оборотність, але також збільшують складність.

Видимість субаутсорсингу:

• Якщо хмарний або SaaS-провайдер сам використовує послуги третіх сторін (наприклад, субпідрядників для дата-центрів, CDN, інструментів безпеки), CASP повинен бути про це поінформований.

• Це має бути врегульовано договором (повідомлення про субаутсорсинг, вимога схвалення для критичних субпідрядників).

4. Типові сценарії проблем з технічної точки зору

Наступні сценарії базуються на вимогах матеріалів ESMA/FMA/AMF і показують типові проблеми, які можуть виникнути при недостатній технічній реалізації.

Сценарій А: Нечіткий розподіл ролей між CASP та хмарним провайдером

Ситуація: CASP передає всі свої IT-операції (хостинг, моніторинг, управління безпекою, бекап/DR) хмарному провайдеру. У CASP лише кілька власних IT-співробітників, які переважно розробляють «бізнес-логіку», але не мають глибокої експертизи в інфраструктурі, безпеці або реагуванні на інциденти. Контракти з хмарним провайдером не містять прав на аудит для наглядових органів, а субаутсорсинг не врегульований.

Занепокоєння наглядового органу:

• CASP де-факто стає «фіктивною компанією» — він не має реального контролю над своїми IT-системами.

• NCA не може інспектувати системи (відсутність прав на аудит).

• Субаутсорсинг неконтрольований (провайдер може передавати критичні функції далі без відома CASP або NCA).

Що це означає конкретно для продукту/технологій?

Завдання з усунення:

• Сформувати ключовий персонал ІКТ: CASP повинен найняти або навчити власних IT-співробітників з експертизою в інфраструктурі, безпеці та реагуванні на інциденти.

• Створити реєстр аутсорсингу: задокументувати всі хмарні сервіси та їхню критичність.

• Переглянути контракти: вимагати права на аудит для CASP та NCA; додати обов'язок схвалення субаутсорсингу; уточнити положення про вихід.

• Налаштувати моніторинг та управління: CASP повинен активно контролювати хмарні сервіси (продуктивність, інциденти безпеки, комплаєнс); не просто «сліпо довіряти».

• Документація для NCA: довести, що CASP дійсно здійснює управління (наприклад, через регулярні перегляди, звіти про аудит, логи інцидентів за участю CASP).

Сценарій B: Недостатній моніторинг та сповіщення

Ситуація: CASP логує всі транзакції та ордери (відповідність MiCA), але немає кореляції, сповіщень та виявлення аномалій. Логи записуються в Data Lake, але їх ніхто не переглядає, крім ручних Ad-hoc запитів. Немає визначених правил сповіщень, інтеграції з SIEM, інструкцій (runbooks) для типових інцидентів.

Занепокоєння наглядового органу:

• CASP не може вчасно виявити інциденти та зловживання на ринку.

• У разі інциденту безпеки або маніпулювання ринком проблема буде виявлена лише через кілька днів або тижнів.

• Наглядовий орган під час перевірки може встановити, що «обробка інцидентів» (ст. 66 MiCA) існує лише на папері.

Що це означає конкретно для продукту/технологій?

Завдання з усунення:

• Впровадити SIEM або платформу моніторингу: централізоване логування з механізмом кореляції (наприклад, Splunk, ELK Stack, Datadog, Azure Sentinel; зазначені рішення наведені лише як приклади, жодна конкретна технологія не є обов'язковою).

• Визначити правила сповіщень: конкретні пороги та патерни для різних типів аномалій (наприклад, «обсяг ордерів > у 10 разів перевищує медіану протягом 5 хвилин», «невдалі спроби входу > 5 за 1 хвилину», «незвичний патерн виведення коштів»).

• Створити інструкції (runbooks) з реагування на інциденти: для кожного типу сповіщення: які перші кроки? хто відповідальний? які існують шляхи ескалації?

• Сповіщення в реальному часі: сповіщення повинні надходити в реальному часі черговим командам (PagerDuty, OpsGenie, інтеграція зі Slack).

• Впровадити аналіз після інцидентів: після кожного релевантного інциденту: документувати аналіз першопричин, вивчені уроки, заходи з покращення.

Сценарій C: Відсутність прав на аудит у хмарних контрактах

Ситуація: CASP використовує кілька інструментів SaaS (KYC-провайдер, інструмент моніторингу транзакцій, хмарний хостинг) зі стандартними умовами та положеннями. Вони не містять прав на аудит для CASP або для наглядових органів. NCA у процесі ліцензування вимагає доступу до систем для перевірки комплаєнсу — CASP не може цього забезпечити.

Занепокоєння наглядового органу:

• NCA не може перевірити дотримання вимог MiCA (відсутність доступу до системи).

• Це фундаментальна проблема: можливість нагляду є основною умовою для отримання ліцензії CASP.

• Заявка може бути відхилена або надана з умовами («переглянути контракти до надання ліцензії»).

Що це означає конкретно для продукту/технологій?

Завдання з усунення:

• Перевірити контракти з постачальниками: перевірити всі контракти на аутсорсинг на наявність прав на аудит.

• Ініціювати переговори: юридичний відділ/відділ закупівель повинен поговорити з постачальниками та вимагати права на аудит (для CASP та для NCA/аудиторів).

• Альтернатива: сертифікації: там, де прямі права на аудит не підлягають обговоренню (наприклад, у великих хмарних провайдерів), перевірити, чи достатньо звітів SOC2/ISO27001 і чи приймає їх NCA.

• Документація та комунікація: прозоро пояснити NCA, які сервіси використовуються, які права на аудит існують і які компенсаційні заходи вжито (наприклад, сертифікації, власні оцінки безпеки).

Сценарій D: Незрозумілий ланцюжок субаутсорсингу

Ситуація: CASP використовує KYC-провайдера, який, у свою чергу, використовує субпідрядника для сканування документів. Субпідрядник базується в країні поза межами ЄС, і CASP нічого не знає про цей субаутсорсинг. Наглядовий орган виявляє це під час Due Diligence і встановлює, що чутливі дані KYC обробляються в країні без рішення про адекватність захисту даних.

Занепокоєння наглядового органу:

• Порушення захисту даних (GDPR).

• Відсутність контролю над усім ланцюжком надання послуг.

• Потенційні ризики для безпеки даних та комплаєнсу.

Що це означає конкретно для продукту/технологій?

Завдання з усунення:

• Поглибити Due Diligence постачальників: запитати у всіх критичних постачальників: «Чи використовуєте ви субпідрядників? Якщо так, то яких? Де вони базуються?»

• Адаптувати контракти: додати обов'язок схвалення субаутсорсингу («Постачальник не має права передавати критичні функції далі без попередньої згоди CASP»).

• Створити карту географії даних: задокументувати, де вздовж усього ланцюжка обробляються та зберігаються дані.

• Перевірити відповідність GDPR/MiCA: для субпідрядників поза межами ЄС: чи є рішення про адекватність? чи укладені стандартні договірні застереження? чи в порядку угоди про обробку даних?

5. Контрольний список перед запуском згідно з MiCA

Наступний контрольний список підсумовує найважливіші вимоги до продукту/технологій, які мають бути опрацьовані перед запуском сервісу CASP. Цей список не замінює юридичну перевірку та перевірку на відповідність, а доповнює їх з технічної точки зору.

5.1 Контроль ІКТ та безпеки

☐ Політика ІКТ задокументована (сфера дії, ролі, відповідальність, управління змінами/релізами, контроль доступу) ☐ Власник ризиків ІКТ призначений (рівень C-level або призначена функція, регулярні перегляди ризиків) ☐ Контроль доступу впроваджено (RBAC, мінімальні привілеї, MFA, управління привілейованим доступом, щоквартальні перевірки доступу) ☐ Розподіл обов'язків реалізовано (розподіл Dev/Prod, принцип «чотирьох очей» для критичних змін) ☐ Процес управління ключами задокументований та протестований (генерація ключів, зберігання (HSM/KMS), ротація, бекап, тренування з відновлення) ☐ Шифрування при зберіганні та передачі активовано (шифрування згідно з поточними ринковими стандартами, управління сертифікатами) ☐ Логування та моніторинг налаштовані (централізоване логування (наприклад, система SIEM або аналогічне рішення), визначені правила сповіщень, термін зберігання логів згідно з MiCA/AML) ☐ Управління вразливостями впроваджено (регулярні сканування, управління патчами, відстеження CVE, тестування на проникнення (щонайменше щорічно)) ☐ Мережева безпека посилена (брандмауери, сегментація мережі, виявлення/запобігання вторгненням, принципи Zero Trust, де це доцільно)

5.2 Менеджмент інцидентів

☐ Класифікація інцидентів визначена (рівні серйозності з чіткими критеріями: критичний/високий/середній/низький) ☐ Процес реагування на інциденти задокументований (виявлення → локалізація → ліквідація → відновлення → вивчені уроки) ☐ Створені інструкції (runbooks) для типових інцидентів (компрометація гаманця, простій API, DDoS, витік даних тощо) ☐ Журнал інцидентів ведеться централізовано (мітка часу, опис, вплив, вжиті заходи, вирішення) ☐ Визначені тригери сповіщення (коли інформувати NCA? які терміни? хто відповідальний?) ☐ Визначені внутрішні SLA (час реагування, час вирішення за рівнем серйозності) ☐ Впроваджено аналіз після інцидентів (аналіз першопричин після кожного релевантного інциденту, заходи запобігання, документація)

5.3 Аутсорсинг та хмара

☐ Створено реєстр аутсорсингу (постачальник, послуга, критичність, деталі контракту, дата перегляду) ☐ Проведено оцінку ризиків ІКТ третіх сторін (Due Diligence постачальника: фінансова стабільність, сертифікати безпеки, рекомендації) ☐ Договірні застереження перевірені/узгоджені (права на аудит для CASP та NCA, доступ до даних, схвалення субаутсорсингу, вихід/оборотність) ☐ Контроль субаутсорсингу впроваджено (видимість усього ланцюжка постачання, процес схвалення, документація) ☐ Стратегія виходу задокументована (план переходу при зміні постачальника, портативність даних, безперервність послуг) ☐ Налаштовано моніторинг послуг на аутсорсингу (SLA, показники ефективності, регулярні перегляди, шляхи ескалації) ☐ Створено карту географії даних (де знаходяться дані? ЄС vs поза межами ЄС? перевірено відповідність GDPR/MiCA?)

5.4 Управління та зберігання даних

☐ Політика зберігання даних впроваджена (дані MiCA: 5 років; дані AML: 5–10 років залежно від національного права; автоматизоване управління життєвим циклом) ☐ Шифрування при зберіганні та передачі активовано (див. 5.1) ☐ Налаштовано аудиторський слід доступу до даних (логування всіх доступів до чутливих даних, інтеграція з SIEM) ☐ Резервне копіювання та аварійне відновлення протестовано (RPO/RTO визначені та виміряні, зберігання за межами об'єкта, тренування з відновлення проведені та задокументовані) ☐ Відповідність GDPR перевірена (право на видалення, портативність даних, управління згодою, угоди про обробку даних з усіма постачальниками)

5.5 Рівень транзакцій та KYC

☐ Процес KYC задокументований та інтегрований (початковий KYC, поточний моніторинг, посилена перевірка, інтеграція з фреймворками AML) ☐ Логування рішень KYC впроваджено (мітка часу, особа, що прийняла рішення, обґрунтування, точки даних) ☐ Відповідність Travel Rule реалізована (TFR-messaging для переказів > 1 000 євро, IVMS101 або аналогічно) ☐ Логування транзакцій повне (наскрізне логування всіх ордерів та транзакцій, включно зі знімками книги ордерів, відстеженням TX у блокчейні) ☐ Виявлення аномалій та спостереження за зловживаннями на ринку налаштовано (на основі правил або ML, сповіщення в реальному часі, робочий процес розслідування для комплаєнсу) ☐ Можливість реконструкції забезпечена (нагляд може відстежити кожну транзакцію від початку до кінця)

5.6 Знання та компетентність

☐ Програма навчання для персоналу, що працює з клієнтами, запущена (початкове навчання: основи MiCA/токеноміки, розкриття ризиків, регуляторні вимоги) ☐ Оцінювання та сертифікація проведені (внутрішні тести, за потреби зовнішні сертифікації, документація) ☐ Планування безперервного професійного розвитку (CPD) (щорічне оновлення знань, оновлення при зміні регуляторних норм) ☐ Документація для інспекцій NCA підготовлена (записи про навчання, результати оцінювання, матриця компетентності персоналу)

5.7 Узгодження з національними очікуваннями

☐ FMA (Австрія): враховано специфічні аспекти CASP (наприклад, аутсорсинг основних послуг (Випуск 01), інформаційний документ про процедури авторизації) ☐ AMF (Франція): опрацьовано контрольний список DOC-2025-05 (документована політика аутсорсингу, реєстр аутсорсингу, внутрішньогрупові домовленості, плани виходу) ☐ BaFin (Німеччина): перевірено пам'ятки та циркуляри ([необхідне джерело — запитувати специфічні вимоги BaFin безпосередньо в BaFin]) ☐ CSSF (Люксембург): використано форми/шаблони та контактні пункти ([необхідне джерело — запитувати специфічні вимоги CSSF безпосередньо в CSSF])

5.8 Фінальна перевірка перед запуском

☐ Отримано внутрішнє підтвердження комплаєнсу (юридичний відділ/відділ комплаєнсу перевірив та прийняв усі технічні впровадження) ☐ Проведено зовнішній аудит (опціонально, але рекомендовано: аудит IT-безпеки, тест на проникнення, аудит комплаєнсу зовнішніми експертами) ☐ Пробний запуск із симуляцією NCA (симуляція наглядової перевірки: чи може бути надана вся необхідна інформація/дані?) ☐ Проведено тренування з реагування на інциденти (настільна вправа або повна симуляція критичного інциденту) ☐ Документація повна та актуальна (усі політики, процеси, інструкції, архітектурні діаграми, контракти з постачальниками задокументовані та версіоновані)

Важлива примітка: Цей контрольний список призначений для орієнтації та не претендує на повноту. Він не замінює індивідуальні юридичні консультації та консультації з комплаєнсу. Кожен проєкт повинен співпрацювати зі спеціалізованими експертами з права та комплаєнсу та розробити індивідуальний контрольний список.

Висновок: Від комплаєнсу до конкурентної переваги

MiCA — це більше, ніж регуляторний бар'єр; це можливість побудувати надійні, безпечні та професійні системи, які створюють довіру у клієнтів та наглядових органів. Команди продукту та технологій, які на ранніх етапах інтегрують вимоги MiCA у свою архітектуру та процеси, уникають дороговартісних доопрацювань та позиціонують себе як «готові до комплаєнсу» — що є вирішальною конкурентною перевагою на жорсткому крипторинку ЄС.

Цей Playbook пропонує вступ до технічної реалізації MiCA. Для глибших питань командам продукту та технологій слід тісно співпрацювати з юридичним відділом, відділом комплаєнсу та, за необхідності, зі спеціалізованими консультантами. Інвестиції в солідні системи та процеси окупаються в довгостроковій перспективі: у швидших процедурах ліцензування, менших наглядових ризиках та вищій довірі клієнтів.

Про NEXORA Unternehmensberatung GmbH

NEXORA — бутик-консалтингова компанія зі штаб-квартирою у Відні, що спеціалізується на RegTech, FinTech, стратегічному консалтингу та послугах з комплаєнсу для австрійських і міжнародних клієнтів. Наша команда підтримує криптопроєкти в регіоні DACH у технічному та регуляторному впровадженні MiCA — від консультацій з архітектури та управління аутсорсингом до підготовки до наглядових перевірок.