Почему compliance криптопроекта нельзя закрыть шаблоном
Почти каждый проект приходит с готовым шаблоном compliance криптопроекта: противодействие отмыванию, идентификация клиентов, порядок ответов на запросы органов. Проблема не в том, что документов нет, а в том, что они писались под усреднённый образец и не описывают реальную модель операций — откуда приходят средства, кто контрагент, через какие сервисы уходит вывод. FATF и локальные регуляторы смотрят не на наличие регламента, а на подтверждаемую связь между регламентом и фактическими транзакциями.
Первое место отказа — непроверенные источники средств. Если платформа не связывает входящий перевод с проверенным клиентом и присвоенной ему оценкой риска, крупный депозит остаётся необъяснимым, и запросят именно его. Второе — расхождение политики и практики: в документе лимиты и ручная проверка выше порога, в системе операции проходят автоматически, а исключения никто не фиксирует.
Третье — отчётность, которую невозможно подтвердить. Решения по клиентам живут во внутренних системах, тикетах и переписке; нет журнала, кто, когда и на каком основании одобрил операцию. На проверке такой отчёт восстанавливают неделями и всё равно не сводят с выгрузкой по цепочке.
Цена ошибки — риск блокировки операций крипто: банки-партнёры и платёжные провайдеры ограничивают обслуживание, расчётный контур закрывается, а возврат занимает месяцы и требует уже готового пакета доказательств. Разбираем, как строится регуляторный контур под конкретную юрисдикцию и модель операций, который проверку проходит, а не имитирует её.
Измеримый эффект: меньше блокировок, быстрее согласований
Регуляторный контур криптопроекта — это связка правил, скрининга и журналов, по которым восстанавливается история каждого решения. Проверка регулятора смотрит на трассируемость: кто подтвердил источник средств, когда сработал санкционный скрининг. Если это собирают вручную из переписки и таблиц, готовность к проверке измеряется неделями работы аналитиков.
После автоматизации картина меняется: санкционный скрининг клиентов идёт на входе и при каждом существенном изменении профиля, совпадения уходят на разбор с фиксированным сроком. Доля операций без ручного вмешательства растёт, время согласования сокращается с дней до часов.
| Класс риска | Что закрыто правилом | Что видно в операциях |
|---|---|---|
| Низкий | Проверка клиента, лимиты | Доля операций без ручного разбора |
| Средний | Скрининг по спискам, источник средств | Срок разбора совпадения |
| Повышенный | Углублённая проверка, согласование | Доля решений с обоснованием |
| Санкционный | Непрерывный скрининг, блокировка | Время реакции на смену статуса |
Требования FATF и локальных надзоров сходятся: решение должно быть объяснимым и воспроизводимым постфактум. Поэтому журнал решений и версии правил хранятся рядом с операцией — выгрузка для проверки формируется за минуты.
Снижение риска отзыва лицензии — следствие, а не лозунг: нарушения фиксируются рано и закрываются до эскалации. Показатели берём из комплаенс-процессов — доля автоматических решений, среднее время разбора, число открытых исключений, — а не из презентации.
Compliance криптопроекта: режимы сопровождения и их ограничения
Формат сопровождения зависит не от размера команды проекта, а от того, в каком режиме он работает с регулятором — уведомительном или лицензируемом. Это определяет объём процессов: где-то достаточно поставить идентификацию клиентов, санкционный скрининг и мониторинг операций, а где-то добавляются раздельное хранение средств клиентов, Travel Rule и регулярная отчётность.
| Формат | Когда подходит | Ограничения |
|---|---|---|
| Разовый разбор | Нужна карта требований и оценка рисков перед запуском или перед проверкой | Не создаёт процессов: карта устаревает после первого изменения требований |
| Проектное внедрение | Получение регистрации, запуск лицензируемого режима, вход в новую юрисдикцию | Решает задачу на дату сдачи; контроль изменений остаётся на стороне заказчика |
| Постоянное сопровождение | Действующая деятельность, поток операций, регулярная отчётность | Требует доступа к данным и согласованных регламентов; эффект накапливается, а не виден сразу |
| Донастройка под юрисдикцию | Расширение в новую страну при готовом ядре процессов | Не заменяет локального юриста и комплаенс-ответственного в этой стране |
Разовый аудит и постоянное сопровождение отвечают на разные вопросы: первый — «что мешает работать легально сейчас», второе держит ответ актуальным, когда меняются требования, добавляются юрисдикции или продукты. На практике чаще выбирают связку: проектное внедрение, затем сопровождение с ревизией раз в отчётный цикл.
Ответственность за решение остаётся у оператора. Мы готовим процессы, внутренние правила и формы отчётности, но подпись и выбор трактовки — за вашим комплаенс-ответственным. Эту границу проговариваем до старта, а не в момент проверки.
Этапы построения регуляторного контура проекта
Регуляторный контур — это не папка с политиками, а набор проверок, встроенных в сам путь прохождения операции: от приёма средств до отчётности. Поэтому строим его от фактов, а не от шаблона — если правила описывают продукт, которого нет, первое же расхождение ломает конструкцию. Порядок работ такой.
- Разбор текущих операций: какие активы принимаются и выводятся, кто контрагенты, где средства держит проект, а где пользователь хранит ключи сам, в каких юрисдикциях находятся клиенты.
- Классификация токена и операций — от неё зависит режим регулирования: платёжный инструмент, ценный актив, утилитарный токен. Размечаем не продукт целиком, а каждый сценарий обращения, чтобы правила ложились точечно.
- Схема потоков средств и данных: карта «источник → счёт проекта → вывод», точки, где цепочка может разорваться, и места, где нужно ручное подтверждение.
- Настройка процедур и правил противодействия отмыванию средств: уровни проверки клиентов, пороги сумм, сверка с санкционными списками, порядок блокировки и разморозки, матрица решений.
- Проверка на реальных сценариях: прогон операций через контур, замер доли ложных срабатываний и ручных разборов, корректировка порогов — чтобы поток не вставал на типовых клиентах.
- Подготовка отчётности регулятору: состав и периодичность отчётов, форматы выгрузок, ответственные, сроки хранения подтверждающих документов.
- Передача команде: регламенты в пригодном для исполнения виде, журналы проверок, обучение сотрудников и порядок пересмотра правил при изменении продукта.
Политики, регламенты и схемы, которые передаём команде
Передаём не отчёт «для полки», а рабочий пакет документов с назначенными владельцами и датой пересмотра — по нему команда дальше ведёт контроль сама, без постоянного сопровождения с нашей стороны.
- Пакет политик и регламентов крипто — процедуры идентификации клиентов, сверка с санкционными и риск-списками, правила приёма и отправки средств, требования к хранению доказательной базы по каждой операции.
- Матрица ролей и прав доступа к данным — кто видит персональные данные, кто работает с историей транзакций, кто утверждает исключения; доступ выдаётся по минимуму необходимого и логируется.
- Схема потоков данных и отчётности — от поступления операции до отчёта регулятору: где данные возникают, где хранятся, кто и в какой момент к ним обращается, какие выгрузки формируются автоматически.
- Регламент внутреннего контроля операций крипто — контрольные точки, разделение полномочий (инициирует один сотрудник, подтверждает другой), периодические сверки и порядок разбора расхождений.
- Сценарии реагирования — запрос от банка или регулятора, заморозка средств, обращение правоохранительных органов, инцидент с доступом к ключам: кто принимает решение, кому сообщает, в какой срок.
- Инструкции для команды комплаенс — пошаговые памятки для первой линии: что проверять на входе, какие признаки считать подозрительными, куда эскалировать и когда фиксировать отказ.
- Карта рисков криптопроекта — перечень с оценкой вероятности, владельцем и плановой мерой по каждому пункту, плюс журнал принятых решений и исключений.
Документы отдаём в редактируемом виде с разметкой ролей, чтобы новые сотрудники вводились в процесс по инструкции, а не по устным договорённостям.
Разбор проекта: от разрозненных процедур к прозрачной отчётности
Клиент — криптосервис с обменом и хранением активов. Регуляторные проверки шли по графику, но каждая превращалась в аврал: учёт вёлся в трёх системах, происхождение средств по части адресов восстанавливали вручную по выпискам, а аналитику Chainalysis применяли точечно — её выводы не сходились с внутренним реестром.
Что было до разбора
Доля операций, требующих ручного разбора, держалась на 18% — свыше сотни обращений в месяц, каждое по 20–40 минут работы аналитика. Отчётность готовили три недели: выгрузки сводили в таблицах, расхождения искали глазами, а историю решения по каждой операции восстанавливали по переписке. Из десяти запросов регулятора семь уходили на эскалацию к юристам: подтвердить источник данных было нечем.
Что изменили и что стало
Собрали единый реестр операций с обязательным набором полей: адрес, источник поступления, оценка риска, ссылка на первичный документ, принятое решение и ответственный. Правила разбора оформили как политику с порогами — типовые случаи закрываются автоматически, к человеку уходит только то, что выходит за рамки. Доля спорных операций упала с 18% до 4%, подготовка отчётности сократилась с трёх недель до четырёх дней, девять из десяти запросов закрываются внутри команды без эскалации.
Отдельно зафиксировали журнал редакций политики: на проверке видно, по какой версии правил принималось решение и когда она вступила в силу.
Что делать, если операции уже велись вне регулируемого поля?
Полного чистого листа при переходе не бывает: регулятор смотрит не на отсутствие лицензии, а на то, восстанавливается ли картина операций, которые велись вне регулируемого поля. Минимум, с которого начинают, — реестр операций с атрибуцией: контрагент, направление, основание, источник средств. Собранные разрозненно данные восстанавливают из выгрузок и биржевых историй, и уже по ним готовят раскрытие.
Объём раскрытия и периодичность отчётности задаёт режим, в который вы переходите. Уведомительный проверяет деятельность и внутренние правила, лицензируемый — ещё структуру, источники капитала и процедуры проверки клиентов.
Требования к отчётности по юрисдикциям различаются не только формами, но и логикой: где-то ждут периодические отчёты по объёмам, где-то — уведомления о сделках выше порога. Поэтому модель данных строят один раз, с признаками юрисдикции, режима и порогов, а формы собирают из неё.
Практический порядок такой: инвентаризация прошлых операций, оценка расхождений с целевым режимом, перевод операций в регулируемый контур без остановки сервиса. Опишите задачу — вернёмся с оценкой и планом.
Технические сомнения: лицензии, отчётность, проверки
Сомнения обычно возникают в трёх точках: нужно ли переделывать работающие процедуры, что отвечать банку и когда пересматривать политики. Ниже — короткие ответы, с которых начинается разбор конкретной ситуации.
Работающие процедуры придётся переделывать?
Нет. Сначала снимаем текущее состояние: где собираются данные о клиенте, кто проверяет адреса, как хранятся решения по операциям. Переделываем только разрывы — непокрытые сценарии, отсутствие версионирования политик, ручные проверки без журнала.
Пришёл запрос банка о происхождении средств — что готовить?
Пакет собирается заранее: история операций по адресам с датами и контрагентами, отчёт аналитики по риску адресов, результаты проверок клиента, пояснение экономики сделки. Если это собирается вручную за неделю — узкое место закрывается регламентом и выгрузкой в один клик.
Как часто обновлять комплаенс-политики?
Плановый пересмотр — раз в год, внеплановый — при смене требований, запуске нового продукта или подключении банка-партнёра. Версии фиксируются с датой и ответственным: на проверке важна не папка с документом, а история его изменений.
Нужна ли лицензия и что будет без неё?
Отказ банков в обслуживании и заморозка фиатных потоков, предписания регулятора, невозможность легально подключить платёжные расчёты. Технически проект живёт, но перестаёт масштабироваться: партнёры требуют документы, которых нет.
Начнём с разбора вашей текущей схемы операций
Достаточно прислать то, что уже есть: схему движения средств, перечень юрлиц с юрисдикциями, текущие правила проверки клиентов и короткое описание продукта. Готовить пакет документов заранее не нужно — пробелы в описании сами по себе показывают, где контур операций не покрыт. Дальше сверяем схему по пунктам:
- Структура юрлиц и юрисдикции: где регистрируется деятельность, кто держит счета и как они связаны между собой.
- Движение средств клиентов — приём, хранение, вывод, обмен: на каком шаге возникает обязанность проверок.
- Идентификация клиентов и контрагентов: процедуры, источники данных, провайдеры проверок.
- Санкционный скрининг и правила мониторинга операций: пороги, сценарии, реакция на срабатывание.
- Лицензионный режим под задачу: регистрация, уведомление или работа в рамках действующего периметра.
- Отчётность и хранение данных: что фиксируется, в какие сроки, кто готовит выгрузку по запросу регулятора.
- Роли и доступы внутри команды: кто меняет правила проверок и подтверждает исключения.
Возвращаемся письменным документом: перечень расхождений с приоритетом, оценка и план работ по комплаенсу по этапам с ожидаемым результатом на каждом. Обязательств с вашей стороны это не создаёт — разбор идёт по вашей схеме и остаётся у вас. Дальше либо фиксируем этапы и подключаемся к внедрению, либо передаём контур команде заказчика — правила, процедуры и документацию с сопровождением на переходный период. Чтобы обсудить задачу compliance предметно, покажите текущую схему операций: вернёмся с оценкой и планом.
