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