Консультування з комплаєнсу та регулювання криптопроєкту

Чому комплаєнс криптопроєкту не можна закрити шаблоном

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

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

FATF і локальні регулятори дивляться не на наявність регламенту, а на підтверджуваний зв’язок між регламентом і фактичними транзакціями.

Перше місце відмови — неперевірені джерела коштів. Якщо платформа не пов’язує вхідний переказ із перевіреним клієнтом і присвоєною йому оцінкою ризику, великий депозит залишається непояснюваним, і запросять саме його.

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

Третє — звітність, яку неможливо підтвердити. Рішення щодо клієнтів живуть у внутрішніх системах, тікетах і листуванні; немає журналу, хто, коли і на якій підставі схвалив операцію. На перевірці такий звіт відновлюють тижнями і все одно не зводять із вивантаженням по ланцюжку.

Ціна помилки — ризик блокування криптооперацій: банки-партнери та платіжні провайдери обмежують обслуговування, розрахунковий контур закривається, а повернення займає місяці й потребує вже готового пакета доказів.

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

Вимірний ефект: менше блокувань, швидше погоджень

Регуляторний контур криптопроєкту — це зв’язка правил, скринінгу та журналів, за якими відновлюється історія кожного рішення. Перевірка регулятора дивиться на трасованість: хто підтвердив джерело коштів, коли спрацював санкційний скринінг.

Якщо це збирають вручну з листування та таблиць, готовність до перевірки вимірюється тижнями роботи аналітиків.

Після автоматизації картина змінюється: санкційний скринінг клієнтів іде на вході та за кожної суттєвої зміни профілю, збіги надходять на розгляд із фіксованим строком. Частка операцій без ручного втручання зростає, час погодження скорочується з днів до годин.

Вимоги FATF і локальних наглядів сходяться: рішення має бути пояснюваним і відтворюваним постфактум. Тому журнал рішень і версії правил зберігаються поряд з операцією — вивантаження для перевірки формується за хвилини.

Зниження ризику відкликання ліцензії — наслідок, а не гасло: порушення фіксуються рано і закриваються до ескалації. Показники беремо з комплаєнс-процесів — частка автоматичних рішень, середній час розгляду, кількість відкритих винятків, — а не з презентації.

Комплаєнс криптопроєкту: режими супроводу та їхні обмеження

Формат супроводу залежить не від розміру команди проєкту, а від того, у якому режимі він працює з регулятором — повідомному чи ліцензованому.

Це визначає обсяг процесів: десь достатньо поставити ідентифікацію клієнтів, санкційний скринінг і моніторинг операцій, а десь додаються роздільне зберігання коштів клієнтів, Travel Rule і регулярна звітність.

Разовий аудит і постійний супровід відповідають на різні питання: перший — «що заважає працювати легально зараз», другий тримає відповідь актуальною, коли змінюються вимоги, додаються юрисдикції або продукти.

На практиці частіше обирають зв’язку: проєктне впровадження, потім супровід із ревізією раз на звітний цикл.

Відповідальність за рішення залишається в оператора. Ми готуємо процеси, внутрішні правила та форми звітності, але підпис і вибір трактування — за вашим комплаєнс-відповідальним. Цю межу проговорюємо до старту, а не в момент перевірки.

Етапи побудови регуляторного контуру проєкту

Регуляторний контур — це не папка з політиками, а набір перевірок, вбудованих у сам шлях проходження операції: від приймання коштів до звітності. Тому будуємо його від фактів, а не від шаблону — якщо правила описують продукт, якого немає, перша ж розбіжність ламає конструкцію. Порядок робіт такий.

1. Розбір поточних операцій: які активи приймаються та виводяться, хто контрагенти, де кошти тримає проєкт, а де користувач зберігає ключі сам, у яких юрисдикціях перебувають клієнти.
2. Класифікація токена й операцій — від неї залежить режим регулювання: платіжний інструмент, цінний актив, утилітарний токен. Розмічаємо не продукт цілком, а кожен сценарій обігу, щоб правила лягали точково.
3. Схема потоків коштів і даних: карта «джерело → рахунок проєкту → виведення», точки, де ланцюжок може розірватися, і місця, де потрібне ручне підтвердження.
4. Налаштування процедур і правил протидії відмиванню коштів: рівні перевірки клієнтів, пороги сум, звірка із санкційними списками, порядок блокування та розморожування, матриця рішень.
5. Перевірка на реальних сценаріях: прогін операцій через контур, замір частки хибних спрацювань і ручних розборів, коригування порогів — щоб потік не зупинявся на типових клієнтах.
6. Підготовка звітності регулятору: склад і періодичність звітів, формати вивантажень, відповідальні, строки зберігання підтверджувальних документів.
7. Передача команді: регламенти у придатному для виконання вигляді, журнали перевірок, навчання співробітників і порядок перегляду правил у разі зміни продукту.

Політики, регламенти та схеми, які передаємо команді

Передаємо не звіт «для полиці», а робочий пакет документів із призначеними власниками та датою перегляду — за ним команда далі веде контроль сама, без постійного супроводу з нашого боку.

• Пакет політик і регламентів крипто — процедури ідентифікації клієнтів, звірка із санкційними та ризик-списками, правила приймання й відправлення коштів, вимоги до зберігання доказової бази за кожною операцією.
• Матриця ролей і прав доступу до даних — хто бачить персональні дані, хто працює з історією транзакцій, хто затверджує винятки; доступ видається за мінімумом необхідного і логується.
• Схема потоків даних і звітності — від надходження операції до звіту регулятору: де дані виникають, де зберігаються, хто і в який момент до них звертається, які вивантаження формуються автоматично.
• Регламент внутрішнього контролю операцій крипто — контрольні точки, розподіл повноважень (ініціює один співробітник, підтверджує інший), періодичні звірки та порядок розбору розбіжностей.
• Сценарії реагування — запит від банку або регулятора, заморожування коштів, звернення правоохоронних органів, інцидент із доступом до ключів: хто ухвалює рішення, кому повідомляє, у який строк.
• Інструкції для команди комплаєнс — покрокові пам’ятки для першої лінії: що перевіряти на вході, які ознаки вважати підозрілими, куди ескалювати і коли фіксувати відмову.
• Карта ризиків криптопроєкту — перелік з оцінкою ймовірності, власником і плановим заходом за кожним пунктом, плюс журнал ухвалених рішень і винятків.

Документи віддаємо в редагованому вигляді з розміткою ролей, щоб нові співробітники вводилися в процес за інструкцією, а не за усними домовленостями.

Розбір проєкту: від розрізнених процедур до прозорої звітності

Клієнт — криптосервіс з обміном і зберіганням активів.

Регуляторні перевірки йшли за графіком, але кожна перетворювалася на аврал: облік вівся в трьох системах, походження коштів за частиною адрес відновлювали вручну за виписками, а аналітику Chainalysis застосовували точково — її висновки не сходилися з внутрішнім реєстром.

Що було до розбору

Частка операцій, що потребують ручного розбору, трималася на 18% — понад сотня звернень на місяць, кожне по 20–40 хвилин роботи аналітика.

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

Що змінили і що стало

Зібрали єдиний реєстр операцій з обов’язковим набором полів: адреса, джерело надходження, оцінка ризику, посилання на первинний документ, ухвалене рішення та відповідальний.

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

Частка спірних операцій упала з 18% до 4%, підготовка звітності скоротилася з трьох тижнів до чотирьох днів, дев’ять із десяти запитів закриваються всередині команди без ескалації.

Окремо зафіксували журнал редакцій політики: на перевірці видно, за якою версією правил ухвалювалося рішення і коли вона набула чинності.

Що робити, якщо операції вже велися поза регульованим полем?

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

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

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

Вимоги до звітності за юрисдикціями різняться не лише формами, а й логікою: десь чекають періодичні звіти за обсягами, десь — повідомлення про угоди вище порога. Тому модель даних будують один раз, з ознаками юрисдикції, режиму та порогів, а форми збирають із неї.

Практичний порядок такий: інвентаризація минулих операцій, оцінка розбіжностей із цільовим режимом, переведення операцій у регульований контур без зупинки сервісу. Опишіть завдання — повернемося з оцінкою та планом.

Технічні сумніви: ліцензії, звітність, перевірки

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

Надійшов запит банку про походження коштів — що готувати?

Пакет збирається заздалегідь: історія операцій за адресами з датами та контрагентами, звіт аналітики щодо ризику адрес, результати перевірок клієнта, пояснення економіки угоди.

Якщо це збирається вручну за тиждень — вузьке місце закривається регламентом і вивантаженням в один клік.

Як часто оновлювати комплаєнс-політики?

Плановий перегляд — раз на рік, позаплановий — у разі зміни вимог, запуску нового продукту або підключення банку-партнера. Версії фіксуються з датою та відповідальним: на перевірці важлива не папка з документом, а історія його змін.

Чи потрібна ліцензія і що буде без неї?

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

Почнемо з розбору вашої поточної схеми операцій

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

• Структура юросіб і юрисдикції: де реєструється діяльність, хто тримає рахунки і як вони пов’язані між собою.
• Рух коштів клієнтів — приймання, зберігання, виведення, обмін: на якому кроці виникає обов’язок перевірок.
• Ідентифікація клієнтів і контрагентів: процедури, джерела даних, провайдери перевірок.
• Санкційний скринінг і правила моніторингу операцій: пороги, сценарії, реакція на спрацювання.
• Ліцензійний режим під завдання: реєстрація, повідомлення або робота в межах чинного периметра.
• Звітність і зберігання даних: що фіксується, у які строки, хто готує вивантаження на запит регулятора.
• Ролі та доступи всередині команди: хто змінює правила перевірок і підтверджує винятки.

Повертаємося письмовим документом: перелік розбіжностей із пріоритетом, оцінка та план робіт із комплаєнсу за етапами з очікуваним результатом на кожному. Зобов’язань із вашого боку це не створює — розбір іде за вашою схемою і залишається у вас. Далі