Документація для регуляторів: де розсипається пакет під час перевірки
Нагляд рідко відхиляє проєкт через саму модель. Відмова в погодженні частіше надходить туди, де комплект матеріалів перестав бути одним цілим: опис продукту, технічна частина та юридичні формулювання живуть у різних редакціях і розходяться в деталях. Інспектор читає це не як недогляд, а як невідповідність заявленого фактичному.
Перше місце розриву — версії. Опис продукту правили під нову механіку випуску, юридичний розділ залишився в попередній редакції, а додаток про розподіл коштів не оновлювався взагалі.
Розбіжність версій ловиться на першому ж звіряльному питанні: цитата з комплекту не збігається з тим, що проєкт показує в мережі.
Друге — простежуваність. Вимоги регулятора до криптопроєкту майже завжди зводяться до зв'язки «що заявлено — як працює — чим підтверджено».
Якщо емісія описана, а порядку поводження з ключами, обліку коштів користувачів і розмежування ролей адміністраторів у пакеті немає, ці прогалини закриває вже листування з наглядом, а не сам комплект.
Третє — непідтверджені формулювання. Публічні матеріали обіцяють одне, внутрішні регламенти фіксують інше, а доказів — журналів операцій, звітів, процедур — немає під жодне твердження. Кожне таке місце перетворюється на окремий пункт запиту уточнень і відсуває розгляд на нове коло.
Далі розбираємо, як збирається цілісний пакет: єдине джерело істини для формулювань, версіонування з історією змін і матриця простежуваності від заяви до підтверджувального документа.
Ефект від підготовленого пакета: строки погодження та зняті відмови
Коли пакет зібрано з одного джерела та розмічено за розділами вимог, цикл погодження переходить із тижнів на дні: перевіряльник знаходить відповідь на конкретний пункт, а не збирає її з десятка файлів. Строк погодження скорочується в рази саме завдяки знятому етапу листування з уточненнями.
Повернення на доопрацювання майже завжди відбувається за трьома класами причин: розбіжність оборотів у звітності та в даних мережі, непідтверджене джерело коштів на адресах і невідповідність опису токена заявленій економіці.
Такі зауваження знімаються не текстом, а вивіркою — кожен показник у документі прив'язаний до транзакції та часу підтвердження, тому спірний пункт закривається посиланням, а не новою обіцянкою.
Частка ручного збирання виписок падає до поодиноких випадків: рухи за адресами вже зведені у сховищі за гаманцями та контрагентами, інженер не зводить таблиці, а підтверджує коректність вибірки.
На пакетному прогоні це прибирає клас помилок подвійного обліку та округлення, через які найчастіше й надходить повторний запит.
Єдине джерело версій — умова, за якої правка не породжує другої правди. Пакет версіонується цілком, разом із реєстром адрес, схемами руху коштів і описом контролів, тому при змінах оновлюється одна гілка, а не п'ять копій.
Це той рівень простежуваності, якого очікують FATF і національні наглядові органи: версія, дата та склад збігаються в кожному розділі, і усунені зауваження не повертаються на наступній перевірці.
Режими роботи: разовий пакет, пакет під ліцензію, супровід
Режим підготовки комплекту обирають за стадією проєкту та адресатом документів, а не за розміром команди.
Один і той самий набір — опис моделі, поводження з токеном, процедури ідентифікації клієнтів, звіт про безпеку — збирається по-різному залежно від того, хто його читає: партнерський майданчик, регулятор чи служба внутрішнього контролю банку.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Разова підготовка комплекту | Перший вихід на майданчик, підключення партнера, відповідь на запит банку | Фіксує стан на дату здачі: зміна моделі або юрисдикції знецінює частину розділів |
| Пакет під ліцензію | Подання до регулятора, реєстрація юрособи, отримання статусу | Прив'язаний до вимог конкретної юрисдикції — перенесення потребує перероблення, а не перекладу |
| Супровід та актуалізація | Продукт розвивається, змінюються параметри токена й вимоги партнерів | Потрібен доступ до змін продукту та власник процесу на стороні замовника |
Обмеження режиму проговорюємо до старту. Разовий комплект відповідає на питання на дату здачі, але не переживає зміни моделі; пакет під ліцензію не можна перевикористати в іншій країні перекладом. Підтримання документів у живому стані — окрема робота, а не побічний ефект перших двох режимів.
Супровід без внутрішнього регламенту вироджується в хаотичні правки. Потрібен власник процесу, порядок внесення змін і версіонування — тоді видно, яка редакція лежить у партнера, а яка в роботі.
На практиці режими йдуть драбиною: разовий комплект, потім розширення до пакета під ліцензію, потім постійна актуалізація, коли з'являється зовнішній контроль.
Етапи роботи: аудит матеріалів, схема, збірка, перевірка, передача
Порядок роботи вибудований так, щоб комплект не переписувався з нуля і кожен факт у ньому спирався на підтверджене джерело. Спочатку розбираємо те, що вже існує: технічний опис, економіку токена, логіку смарт-контрактів, листування з банком або торговим майданчиком. Далі — сім кроків, і на двох із них долучається замовник.
- Аудит матеріалів. Збираємо все, що вже написано й запущено в мережі, звіряємо документи з фактичним станом коду. На виході — перелік розбіжностей і застарілих формулювань.
- Карта прогалин. Зіставляємо наявне з вимогами обраної юрисдикції та профілю ліцензії: видно, яких документів немає і які доведеться переписати.
- Схема комплекту. Погоджуємо структуру, зміст і відповідальних за кожен блок. Тут замовник підтверджує юридичну та операційну рамку проєкту.
- Збірка комплекту. Пишемо відсутнє, переписуємо розбіжне, зводимо все до єдиних термінів, метрик і позначень ролей.
- Внутрішня перевірка. Другий інженер незалежно звіряє цифри, посилання та відповідність коду; розбіжності повертаються в роботу до усунення.
- Підтвердження фактів. Замовник проходить за спірними пунктами — розподіл токенів, ролі, порядок управління. Фіксуємо затверджені формулювання.
- Передача за актом. Віддаємо фінальні версії, реєстр документів і журнал правок, щоб подальші зміни вносилися контрольовано.
Пакет документації для регуляторів: склад, версії, передача за актом
Пакет збирається не «під перевірку», а як робочий контур: будь-який документ можна пред'явити регулятору, банку-партнеру або аудитору без термінового дозбирання. Нижче — що саме залишається у замовника на руках після здачі, з вихідниками та правом правки.
- Опис токеноміки — випуск, розподіл, графік розблокування, джерела ліквідності та допущення до розрахунків, а не лише підсумковий графік.
- Політики та процедури — перевірка клієнтів, оцінка ризиків, обробка звернень, ескалація підозрілих операцій: з ролями, строками й точками ухвалення рішень.
- Схема структури володіння — юрособи, частки, підпорядкованість підрозділів і явне зазначення, хто підписує документи та відповідає за дані.
- Реєстр операцій — які журнали ведуться, що в них фіксується, строк зберігання і яким запитом вивантажується вибірка за потрібний період.
- Матриця відповідності — вимога регулятора → документ → розділ → відповідальний: видно, чим закрито кожен пункт і де залишилися прогалини.
- Регламент оновлення версій — нумерація, порядок затвердження, фіксація змін і дата набрання чинності новою редакцією.
- Акт передачі — опис із версією кожного документа, датою та підписами сторін.
Версії зберігаються в одному місці, попередні не видаляються: на запит видно, яка редакція діяла на конкретну дату. Передача відбувається за актом з описом, тому у замовника залишаються і редаговані вихідники, і затверджений комплект.
Кейс перевірки: що змінилося в комплекті після перероблення
Перевірку нагляду проєкт проходив двічі, і різниця між цими заходами виявилася в упакуванні матеріалів, а не в самому продукті.
До перероблення
Пакет збирали під конкретний запит: опис токеноміки жив в одному файлі, політики ідентифікації клієнтів і протидії відмиванню — окремими вкладеннями, дорожня карта — у презентації для інвесторів.
У половини документів одночасно ходили кілька версій з різними датами й правками, а підтверджувальні матеріали шукали за листуванням. На перевірці це давало передбачуваний ефект: частина зауважень стосувалася не суті проєкту, а розбіжностей між документами.
Що змінили
Матеріали звели в єдиний комплект зі змістом і реєстром: у кожного документа з'явився власник, номер версії, дата затвердження й посилання на вихідне рішення.
Підтверджувальні матеріали — звіти моніторингу, вивантаження за операціями, журнали звернень — прив'язані до пунктів політик, які вони закривають. Відповідає на питання нагляду тепер структура пакета, а не пам'ять конкретного співробітника.
Що вийшло
Число зауважень скоротилося з двох десятків до семи, і майже всі виявилися щодо суті продукту, а не щодо оформлення.
Середній строк закриття впав з дев'яти тижнів до трьох: інспектору більше не потрібно перепитувати, який файл актуальний, а повторні зауваження щодо одних і тих самих пунктів зникли.
Комплект спирається на рекомендації FATF і вимоги місцевих регуляторів, але виграш дає не відповідність букві, а трасування: будь-яке твердження простежується до процедури та підтвердження.
Чим відрізняється пакет під ліцензію від повідомного порядку?
Вибір між ліцензією та повідомленням визначає обсяг документації, а не лише форму подання. Ліцензована діяльність виникає там, де проєкт отримує доступ до коштів клієнтів: кастодіальне зберігання, обмін, залучення коштів в обмін на токени.
Повідомний порядок підходить, коли таких зобов'язань немає — консультування, розробка, аналітика, сервіси без доступу до активів.
Різниця у вимогах — не в переліку розділів, а в наявності зовнішніх підтверджень. Повідомлення — це опис діяльності, відповідальні особи, внутрішні правила.
Пакет під ліцензію додає процедури ідентифікації клієнта та контролю операцій, модель оцінки ризиків, порядок обліку й звітності, аудит, схему управління ключами та розмежування доступу.
Тому обсяг комплекту відрізняється в рази. Окрема складність — узгодженість: описані процедури мають збігатися з фактичною поведінкою системи.
Розбіжність між документом і реалізацією — найчастіша причина запитів регулятора та відмов, тож опис процесів збирають разом з архітектурою, а не після.
Вибір режиму подання починаємо з розбору моделі продукту: чи є зберігання коштів клієнтів, обмін, випуск токенів на публіку. Якщо ознак ліцензованої діяльності немає, повний комплект — це зайві місяці та розкриття технології регулятору там, де воно не потрібне. Якщо є — повідомлення питання не закриває, і обсяг одразу будується під підтвердження.
Сумніви та обмеження: юрисдикції, дані, строки актуальності версій
Юрисдикція проєкту задає решту: де зареєстровано юридичну особу, звідки приходять користувачі, де фізично обробляються дані.
Пакет збираємо під конкретний набір режимів, а не «на всякий випадок» — інакше документ суперечить собі: одна частина описує некастодіальний сервіс, інша — операції з фіатними потоками.
Персональні дані в блокчейн-проєкті майже завжди живуть поза мережею: ончейн залишаються псевдонімні адреси та хеші, а імена, документи й адреси — у зовнішньому контурі з розмежуванням доступу.
Межі відповідальності фіксуємо матрицею: хто оператор даних, хто обробник, що закриваємо ми, що залишається на замовнику. Вимоги звіряємо з рекомендаціями FATF і профільними режимами цільових країн.
Як бути з правом на видалення, якщо блокчейн незмінний?
Персональні дані не пишемо в мережу — у транзакції залишається хеш або ідентифікатор із зовнішньої бази. Видалення запису в зовнішньому контурі знецінює ончейн-посилання, і відомості перестають бути відновлюваними. Такий контур описуємо явно, щоб у регулятора не виникало питань про «невидалювані» дані.
Що буде, якщо вимоги в юрисдикції зміняться?
Пакет версіонується: дата, номер ревізії, перелік змінених розділів. При зміні вимог оновлюємо зачеплені блоки, а не переписуємо документ цілком, і віддаємо дельту з поясненням.
Доступ до версій розмежовано за ролями, видачі та відкликання потрапляють у журнал — на запит видно, яка ревізія кому й коли передавалася, а застарілі залишаються в архіві з позначкою.
Обговоримо задачу: повернемося з оцінкою, планом і складом робіт
Щоб оцінка обсягу робіт спиралася на факти, а не на припущення, на старті достатньо кількох ввідних: юрисдикції реєстрації та цільові ринки, стадія проєкту — ідея, робочий продукт або діюча мережа, призначення токена та його роль в економіці продукту, чи були аудити контрактів і чи є вже листування з регулятором.
Якщо частина даних не зафіксована, це не блокує старт: зафіксуємо допущення в плані підготовки й уточнимо їх по ходу роботи, не переробляючи вже погоджені документи.
У відповідь на ввідні дані надсилаємо конкретний набір:
- Оцінку обсягу робіт: перелік документів під ваші юрисдикції, трудовитрати за кожним блоком і порядок, у якому їх логічно закривати.
- План підготовки: етапи, відповідальні з обох сторін, точки погодження та залежності між документами — від технічного опису проєкту до політик комплаєнсу.
- Склад комплекту: опис токеноміки, процедури ідентифікації клієнтів і протидії відмиванню, розкриття ризиків, звіти про аудит контрактів, внутрішні регламенти для команди.
- Розподіл зон відповідальності: що закриваємо ми, що залишається за вашими юристами та фінансовою службою і які дані потрібні від них на кожному етапі.
- Регламент передачі та підтримки: у якому вигляді віддаємо вихідники, як версіонуємо правки і що робимо, коли змінюються вимоги регулятора або сам продукт.
Опишіть задачу у вільній формі — повернемося з оцінкою, планом підготовки та складом комплекту, після чого зафіксуємо строки й точки контролю.
