Чому VASP ліцензування буксує на етапі перевірки
Регулятор перевіряє не декларацію про наміри, а зв'язність даних: від клієнта до операції, від операції до джерела коштів, від джерела до звітності.
Тому VASP ліцензування частіше буксує не на юридичній частині, а на стику, де комплаєнс-документація має підтверджуватися вивантаженнями з працюючої системи. Досьє збирають як набір файлів, а перевіряльник іде ланцюжком і на кожному кроці шукає підтвердження.
Перший типовий зрив — неповне досьє. Частина процедур описана в різних редакціях, частина живе лише в листуванні, а версії політик не пов'язані з датами їх запровадження.
Другий — потоки операцій не описані: не видно, які канали приймання та виведення використовуються, хто контрагент, як фіксується статус операції і хто зі співробітників має до неї доступ.
Третій і найдорожчий — джерело коштів клієнта. Якщо його підтверджує вручну збережений скриншот, а не вивантаження із системи з ідентифікатором клієнта, датою та відповідальним, перевірка такого підтвердження не приймає. Тут вимоги регулятора й інфраструктура розходяться: процедура є, слідів її виконання немає.
Наш досвід: розходження між описаним процесом і тим, що реально фіксує система, — основна причина повернень і додаткових запитів. Розбираємо, як це закривається на етапі підготовки до перевірки.
Що змінюється після впровадження: строки, відмови, запити
Коли документація та інфраструктура проєктуються разом, ефект видно в цифрах, а не в описах. До цього досьє на ліцензію збирається місяцями: частина історії операцій відсутня, частина листувань живе в пошті, вивантаження із систем не сходяться між собою. Кожну прогалину доводиться закривати вручну — і саме на ній перевіряльник зупиняється найуважніше.
Ключова метрика — частка операцій з повною, відтворюваною історією. Якщо потік транзакцій пишеться в незмінний журнал, до нього прив'язані перевірки адрес і відомості за правилом подорожі, ця частка тримається близько 95% замість 60–70%.
Аналітика на кшталт Chainalysis закриває оцінку ризику контрагента, а власне сховище — строк і повноту зберігання: дані не залежать від того, чи змінився постачальник або формат вивантаження.
Строк підготовки досьє скорочується з тижнів до кількох днів, тому що профіль ризику, схема руху коштів та опис процедур беруться з працюючої системи. Їх не відновлюють із пам'яті й не переписують під кожен запит заново — змінюється лише супровідна частина.
Далі падає кількість повторних запитів: початковий пакет уже містить відповіді на типові питання щодо джерел коштів, контрагентів і контролю. Це і є стійкість до перевірки — не одноразова тека документів, а стан, який підтверджується під час кожної наступної звірки.
Формати VASP ліцензування: порівняння варіантів
VASP ліцензування не зводиться до подання пакета документів: варіантів отримання статусу кілька, і кожен задає свій периметр операцій, вимоги до технічної інфраструктури та строк виходу на ринок. Вибір залежить від того, працюєте ви з кастодією та фіатом чи обмежуєтеся обміном.
Нижче — чотири схеми, між якими найчастіше обирають. Порівняння йде за трьома осями: швидкість старту, обсяг зобов'язань перед регулятором і те, наскільки інфраструктура залишається вашою.
| Варіант | Коли підходить | Обмеження підходу |
|---|---|---|
| Власне ліцензування в юрисдикції | Кастодія, обмін і робота з резидентами ринку — потрібен прямий контроль | Тривалий цикл погоджень, вимоги до капіталу та локальної присутності, повна програма AML і KYC, незалежний аудит |
| За ліцензією партнера (агентська схема) | Швидкий старт і перевірка попиту без власного статусу | Периметр послуг задає партнер, клієнтські кошти та звітність залишаються поза вашим контролем |
| Юрособа з чинним статусом | Потрібен працюючий периметр одразу: розрахунки, кастодія, банківські відносини | Успадковуються історія звітності та зобов'язання, зміна контролю погоджується з регулятором, інфраструктуру переоформлюють |
| Реєстрація з полегшеним режимом | Вузький набір операцій: консультування, обмін без зберігання коштів клієнтів | Заборона на кастодію та роботу з резидентами великих ринків, складнощі з банками-кореспондентами |
Обмеження підходу — не формальність: вони визначають, яку AML-програму доведеться вибудувати і чи потрібен локальний офіцер з комплаєнсу.
Супровід статусу теж потребує інфраструктури: журналювання транзакцій, порядок зберігання ключів і регламенти звітності мають бути задокументовані та відтворювані з першого дня — інакше повторна перевірка регулятора перетворюється на переробку процесів.
Етапи роботи: аудит, налаштування інтеграцій, передача
Порядок кроків тут не формальність: якщо інтеграції підключають раніше, ніж описані потоки даних, перевірки починають дублюватися, а звітність збирається вручну. Ми йдемо від розбору поточного контуру до працюючої схеми, і кожен етап спирається на артефакт попереднього.
- Аудит інфраструктури. Дивимося, де зберігаються ключі та як підписуються операції, хто має доступ до систем, які сервіси перевірки вже підключені. На виході — карта розривів: спільні облікові записи, неповні журнали, перевірки, результат яких неможливо відтворити.
- Схема потоків даних. Описуємо маршрут даних клієнта, точки звірки зі списками, строки зберігання та події, які потрапляють у незмінний журнал і вивантажуються на запит регулятора.
- Розмежування доступу. Вибудовуємо ролі так, щоб налаштування перевірок не змінював оператор, який веде розбір спрацювань. Двофакторне підтвердження, окремі середовища для тестових операцій і бойової роботи.
- Налаштування інтеграцій. Підключаємо перевірку особи та документів, звірку із санкційними та політично значущими списками, аналітику по блокчейну, обмін даними про перекази з іншими провайдерами. У кожного каналу — обробка відмов і повторних спроб.
- Перевірка сценаріїв. Проганяємо контрольовані випадки: збіг зі списком, дроблення суми, переказ на адресу з групи ризику. Спрацювання має приводити до зрозумілої дії, а хибне — зніматися з обґрунтуванням.
- Документація та регламенти. Правила внутрішнього контролю, порядок розслідування, матриця ескалації, строки оновлення списків. Усе прив'язано до фактичної конфігурації, а не написано окремо від неї.
- Передача. Віддаємо доступи, схеми потоків, регламенти та навчену команду: розбираємо інциденти на живих прикладах і показуємо, як змінювати правила без зупинки сервісу.
На виході замовник отримує схему, яку можна показати регулятору і далі підтримувати власними силами.
Конфігурації, політики доступу та комплект документів
Комплект документів — не тека, зібрана до подання на VASP-ліцензію, а робочий опис системи. Якщо конфігурації, політики доступу та регламенти розходяться з тим, як інфраструктура влаштована насправді, перший же запит регулятора або розбір інциденту розкриває цей розрив. Ми збираємо артефакти так, щоб за ними можна було відтворити середовище й пояснити кожне рішення.
- Конфігурація систем — склад компонентів, зв'язки між ними, параметри розгортання та розділення середовищ, щоб стенд піднімався за описом, а не з пам'яті інженера.
- Політики доступу — матриця ролей і прав, порядок видачі, перегляду та відкликання, правила підтвердження критичних операцій двома співробітниками.
- Опис ролей — хто за що відповідає: від адміністратора до відповідального за відповідність вимогам, із зонами відповідальності та порядком заміщення.
- Схеми потоків даних — звідки надходять дані клієнта, де зберігаються, куди передаються, на яких ділянках фіксуються сліди операцій.
- Регламенти роботи — обробка запитів регулятора, реагування на інциденти, відновлення після збою, порядок зміни конфігурацій.
- Журнали та сліди операцій — що саме фіксується, скільки зберігається, хто має право на вивантаження.
- Порядок оновлення — власник кожного документа, тригери перегляду, правила версіонування та фіксації змін.
У кожного артефакту є власник і правило перегляду: при зміні складу систем, ролей або маршрутів даних документ оновлюється разом із ними, а не після зауваження. Версії зберігаються поруч, тому видно, яка редакція діяла на момент конкретної операції.
Комплект перестає бути формальністю і стає інструментом, яким користуються і інженери, і ті, хто відповідає за відповідність вимогам.
Кейс: підготовка до перевірки без зупинки сервісу
Замовник — провайдер послуг з віртуальними активами, готувався до перевірки регулятора в межах процедури ліцензування. Історія операцій при цьому жила в чотирьох місцях: біржовий модуль, каса фіату, ручні реєстри за великими угодами та вивантаження з аналітики блокчейну.
Зібрати повну картину щодо конкретного клієнта за довільний період можна було лише вручну: на кожен запит ішло близько дев'яти робочих днів, а в частини операцій губився зв'язок із джерелом коштів.
Що змінили
Звели історію в єдиний реєстр із незмінним журналом: запис отримував ідентифікатор клієнта, суму та напрямок, посилання на транзакцію в мережі та правило ризик-оцінки, за яким операція пройшла перевірку на свою дату.
Щоденна звірка з вивантаженнями аналітики транзакцій Chainalysis закривала розходження між внутрішнім обліком і даними мережі — розходження потрапляло в окрему чергу на розбір, а не спливало на перевірці.
Правила ризик-оцінки версіонувалися, тому можна відтворити, чому операція вважалася низькоризиковою тоді, а не лише зараз.
Динаміка за контрольними метриками
| Показник | До | Після |
|---|---|---|
| Повнота історії операцій за період | 74% | 99,6% |
| Операції з підтвердженим джерелом коштів | 61% | 97% |
| Час відповіді на запит регулятора | 9 робочих днів | 4 години |
| Вивантаження по клієнту за довільний період | вручну, двоє фахівців | автозвіт за заданим зрізом |
Міграцію провели без зупинки сервісу: новий реєстр наповнювався паралельно з поточною роботою, модулі підключалися по одному зі зворотним перемиканням, якщо звірка давала розходження.
Перевірка пройшла без зауважень до повноти даних, а запити регулятора тепер закриваються вибіркою з реєстру, а не збиранням виписок по підрозділах.
Що робити, якщо інфраструктура вже розгорнута?
Працюючу інфраструктуру не перебудовують з нуля — поряд із нею збирають другий контур, приведений у відповідність до вимог, і переводять туди навантаження частинами.
Сервіс не зупиняється на жодному кроці, а відкат — це повернення одного перемикача, а не відновлення з резервної копії з втратою операцій, надісланих за останню годину.
Починають з інвентаризації систем: які сервіси реально обслуговують клієнтські операції, де зберігаються ключі підпису та як підтверджуються вихідні транзакції, які зовнішні взаємодії виходять за межі контуру, хто і з якими правами допущений до кожної ланки.
На виході — схема фактичного потоку операцій і список розходжень між тим, як влаштовано насправді, і тим, що описано в документації. Частина невідповідностей знімається налаштуванням, частина потребує доопрацювання коду.
Розмежування доступу вводиться поетапно: спочатку ролі з мінімально необхідними правами та окреме підтвердження для критичних дій, потім розділення обов'язків між тим, хто ініціює операцію, і тим, хто її санкціонує.
Попередні широкі права вимикають лише після того, як журнал покаже: новий набір ролей закриває всі робочі сценарії. Інакше нічна операція стане через закритий доступ до сервісу.
Вимоги наглядових органів, зокрема підхід FATF до віртуальних активів, перевіряються на збіг регламенту та реального контуру виконання.
Документацію правлять у тій самій зміні, де змінюється налаштування: схеми маршрутизації, матриця ролей, журнали подій і порядок дій при інциденті оновлюються разом із кодом, а не окремим етапом наприкінці.
На виході — чинний сервіс без простою, формалізовані права доступу, відтворювані журнали операцій та описи, які перевіряльник може звірити із системою за один прохід. Далі залишається плановий супровід: будь-яка зміна проходить той самий шлях, що й первинне доопрацювання.
Часті сумніви: зберігання даних, інтеграції, звітність
Заперечення щодо VASP ліцензування майже ніколи не про сам пакет документів — вони про інфраструктуру під ним: скільки і як довго зберігати дані, як зістикувати вже працюючі системи, у якому вигляді віддавати звітність і чим підтвердити, що історія операцій не правилась. Розбираємо кожне.
Скільки і що доведеться зберігати?
Строки зберігання вважаємо від дати операції, а не від закриття рахунку: у даних про клієнта, транзакцій та звернень строки різні, тому політика описується за типами записів, а не одним рядком «зберігати все».
Журнал ведемо тільки на дозапис — запис не можна переписати або видалити до закінчення строку, а після його завершення дані архівуються та видаляються за регламентом, а не вручну. Так обсяг зберігання не зростає безконтрольно, і видалення нічого не ламає.
У нас облік розкиданий по кількох системах — це все переписувати?
Зазвичай ні: збирається шар інтеграції, який пов'язує обліковий контур, платіжний і моніторинг за єдиним ідентифікатором клієнта та операції. Приймання подій ідемпотентне — повторний пакет не створює дубль, а довідники зіставляються один раз. Звіт тоді будується з однієї картини, а не звіряється вручну між трьома вивантаженнями.
У якому вигляді віддавати звітність і як довести її достовірність?
Формат вивантаження підбираємо під вимоги регулятора, а не під зручність внутрішніх систем, і фіксуємо його схемою — звірка йде автоматично, розходження видно до запиту, а не після.
Цілісність історії тримається на журналі тільки на дозапис: кожен запис отримує контрольну суму, суми пов'язані між собою, тому правка заднім числом виявляється без ручної інвентаризації.
Перелічені регламенти, схема інтеграції та правила зберігання оформлюються як робоча документація — її можна передати перевіряльнику й використовувати при зміні команди.Обговоримо задачу і повернемося з оцінкою та планом
Розмова починається з вихідних даних, а не з презентації: щоб повернутися з оцінкою обсягу та планом робіт, нам потрібно побачити, як бізнес влаштований зараз. Чим конкретніші ввідні, тим менше припущень в оцінці і тим точніші межі етапів.
Що надіслати для старту:
- юрисдикції реєстрації та плановані ринки обслуговування — від них залежать вимоги регулятора, процедури ідентифікації та правила звітності;
- модель роботи з клієнтськими активами: кастодіальна чи некастодіальна, хто розпоряджається ключами і як розділені ролі;
- перелік операцій: обмін, перекази, приймання та видача фіату, розрахунки з контрагентами-майданчиками;
- поточну інфраструктуру: що вже розгорнуто, які підрядники та системи в контурі, де зберігаються дані та логи;
- статус документації: чи є чернетки політик AML/CFT, програми ідентифікації клієнтів, описи внутрішніх процедур і контролю;
- обмеження за строками подання заяви та очікуваний порядок взаємодії з регулятором.
У відповідь надсилаємо план робіт за етапами, склад документації з відповідальними та чернеткову архітектуру контуру. Опишіть задачу — повернемося з оцінкою обсягу та форматом роботи.
