Комплаенс — это система правил, процессов и контроля, которая помогает криптопроектам и провайдерам услуг (биржи, кошельки, финтех-приложения) работать законно и безопасно, снижая риски отмывания средств (AML/CFT), санкций, мошенничества и утечек данных. В крипте классический комплаенс дополняется ончейн-спецификой: мониторингом адресов и транзакций, работой со смарт-контрактами и учётом функций эмитентов (например, у стейблкоинов есть механизмы freeze/wipe, см. blacklists у стейблкоинов).
Этот материал — практическая «база», чтобы выстроить минимально достаточную комплаенс-систему для криптопродукта и говорить на одном языке с банками, платёжными и регуляторами.
|Базовые принципы комплаенса в крипте: от KYC/AML до ончейн-доказательств}}
Риск-ориентированный подход (RBA): фундамент комплаенса
Risk-Based Approach (RBA) означает, что меры контроля должны соответствовать уровню риска клиента, продукта и географии. Не «перекомплаенс» для всех, а разумные фильтры там, где риск выше.
| Объект оценки | Что анализируем | Примеры факторов риска |
|---|---|---|
| Клиент (KYC/KYB) | личность/бенефициары, источники средств | «сложная» структура, PEP-статус, аномальные доходы |
| Продукт/фича | анонимность, скорость, обратимость | P2P-переводы, миксеры, приватные пулы, кросс-чейн-мосты |
| География | юрисдикции, режим санкций | страны с высоким уровнем санкционных/AML-рисков |
| Поведение | паттерны ончейн/оффчейн операций | быстрые круговые переводы, каскады бриджей, «обнал» |
Что делать: определить уровни риска (низкий/средний/высокий), привязать к ним KYC-наборы, лимиты, частоту мониторинга и порог эскалации.
Идентификация и верификация: KYC/KYB
KYC (индивидуальные клиенты)
- Сбор данных: ФИО, дата рождения, гражданство/резидентство, адрес.
- Документы: паспорт/ID, подтверждение адреса; при повышенном риске — источники средств.
- Liveness/antifraud: проверка «живости», сравнение с базами утечек, сверка селфи/документа.
KYB (организации)
- Учредительные документы, бенефициары (UBO), право подписи, деятельность.
- Проверки: судимости/санкции для директоров/UBO, финансовая отчётность (по риску).
Постоянная актуализация (KYC refresh) — по событиям (смена документа/страны) или по графику в зависимости от риска.
Санкционный и PEP-скрининг
Санкционный скрининг — проверка клиента и контрагентов на попадание в санкционные списки и списки запретов. PEP-скрининг — выявление политически значимых лиц (PEP) и их окружения. Результат: «чисто / совпадение / совпадение требует эскалации».
Ончейн-слой: проверяйте адреса получателя/отправителя на включение в известные high-risk кластеры (взломы, darknet, санкции, фрод). Практика: до/после операции, по алерту аномалий.
Travel Rule (передача атрибутов перевода между VASP)
Для переводов между VASP (Virtual Asset Service Provider) действует принцип «Travel Rule»: провайдер-отправитель и получатель обмениваются основными данными о плательщике и получателе (объём и состав варьируется по юрисдикции). Для self-custody кошельков правило обычно не применяется, но VASP часто запрашивает подтверждение принадлежности адреса.
Практика:
- Автоматизировать обмен полями (стандарт сообщений, надёжные каналы).
- Покрыть edge-кейсы: сплит перевода на несколько адресов, кросс-чейн.
- Прозрачно сообщать пользователю, что именно будет передано и зачем.
Мониторинг транзакций: оффчейн + ончейн
Оффчейн: поведенческая аналитика аккаунта (скорость операций, устройства, IP, платежные паттерны). Ончейн: граф адресов, риск-метки, аномалии (множественные быстрые хопы через мосты, взаимодействие с высокорисковыми smart-контрактами).
Точки контроля:
- Pre-trade / pre-withdrawal скрининг адреса и суммы.
- Пост-мониторинг: алерты по порогу/паттерну (например, массовые мелкие выводы на свежие адреса).
- Реакция: ручная проверка, временная приостановка, эскалация SAR/STR (сообщение о подозрительной активности по законам юрисдикции).
См. также ончейн-механику блокировок у эмитентов стейблкоинов — blacklists.
Политика данных и конфиденциальность
Минимизация данных. Храните только то, что нужно для регуляторных требований и риска. Сроки хранения. Фиксируйте в политике срок и порядок удаления/обезличивания. Доступ и сегрегация. Ролевая модель, принцип «минимально необходимые права». Безопасность хранения. Шифрование at-rest/in-transit, контроль ключей, журналирование доступа. Запросы госорганов. Процедуры обработки: валидация запроса, логирование, уведомление пользователя (если разрешено законом).
Кастоди и сегрегация клиентских активов
Если вы кастоди-провайдер (держите ключи/активы пользователей), критичны:
- Сегрегация активов клиентов от операционных средств компании.
- Политика мультиподписи/MPC и лимиты; см. риски MPC-кошельков.
- Резервные планы (DR), процедуры восстановления, стресстесты вывода.
- Прозрачные отчёты об остатках и движениях (proof-of-reserves — с оговорками).
Если вы non-custodial (пользователь сам хранит ключи), риски и обязанности иные: меньше KYC-обязанностей, но больше работа с онбордингом безопасных практик и предупреждениями о вредоносных подписях (см. крипто-дрейнеры).
DeFi и non-custodial: как делать «комплаенс-совместимый» продукт
В non-custodial/DeFi вы не контролируете чужие средства, но всё равно можете снижать системные риски:
- Ончейн-гейтинг высокорискованных действий: предупреждения при взаимодействии с адресами в риск-сетах.
- Опциональный whitelist/allowlist для корпоративных/permissioned-пулов (актуально для токенизированных фондов).
- Объяснимая приватность: используйте конструкции, которые позволяют доказать «чистоту» средств без раскрытия личности, например Privacy Pools.
- Селективная адресация: для скрытия получателя — stealth-адреса, но заранее проработайте UX «доказать невиновность» при выводе на VASP.
- Анти-фишинг и анти-дрейн UX: симуляция транзакций, чёткие экраны подписи, запрет blind-signing — см. гайд.
Роли и процессы комплаенса в компании
| Роль | Зона ответственности |
|---|---|
| MLRO/Head of Compliance | Политики, регистры рисков, отчётность руководству/регуляторам |
| Sanctions/Screening | Списки, обновления, разбор совпадений (hits) |
| KYC/KYB | Онбординг, refresh, эскалации |
| Fraud/On-chain analytics | Мониторинг транзакций, расследования, взаимодействие с аналитическими провайдерами |
| Legal | Трактовка требований юрисдикций, договоры с провайдерами |
| Security/Dev | Технические контроли: хранение данных, логирование, доступы, безопасный UX |
Документы (минимум): политика AML/CFT, политика санкций, KYC/KYB стандарты, Travel Rule SOP, политика данных и хранения, план инцидент-респонса, методика эскалаций.
Инцидент-респонс и взаимодействие с властями
Сценарии: подозрительная активность, санкционный хит, запрос госоргана, утечка данных.
Базовый плейбук:
- Зафиксировать события (логи, ончейн-tx, IP/устройства), заморозить процессы в допустимых рамках.
- Провести скоринг кейса (высокий/средний/низкий), при высоком — эскалировать MLRO/Legal.
- Решения: отказ/приостановка операции, запрос доп.данных, оформление SAR/STR по законам юрисдикции.
- Коммуникации: аккуратные, без раскрытия лишнего; фиксируем таймлайны и статусы.
- Пост-мортем: обновить правила/фильтры, пересмотреть лимиты/пороговые значения.
Отношения с поставщиками и сторонними сервисами
Выбор провайдеров (чек-лист):
- Наличие API для санкций/PEP, ончейн-рисков, Travel Rule.
- Покрытие сетей (EVM, Bitcoin, Solana, Tron) и качество кластеризации адресов.
- Политика данных (хранение, удаление, юрисдикция дата-центров).
- SLA, отчётность, прозрачность методик.
- Вендор-риски: план B, уход без потери данных.
Договоры: ответственность за ложные срабатывания, изменения цен/лимитов, аудит логов по запросу.
Таблицы: быстрое сравнение режимов
| Режим | KYC/KYB | Санкции/PEP | Travel Rule | Мониторинг транзакций | Кастоди/ключи |
|---|---|---|---|---|---|
| Custodial (биржа/кастоди) | Полный набор (по RBA) | Да | Да (между VASP) | Да: оффчейн+ончейн | Ключи у провайдера; сегрегация обязательна |
| Non-custodial (кошелёк/DeFi-интерфейс) | Мягче/по риску (если вообще нужен) | Да (на уровне адресов) | Обычно нет (не VASP), но возможны партнёрские требования | Да: ончейн сигнализация/алерты | Ключи у пользователя; обучение и UX-защиты |
| RWA/permissioned-пулы | Полный whitelist/KYC | Да | Да (где применимо) | Да | Управление доступом на уровне смарт-контракта |
Ошибки и ловушки (и как их избежать)
- Собирать «всё подряд». Излишний сбор персональных данных увеличивает ответственность и риск утечек. Делайте data minimization.
- Отключённые апдейты списков. Санкционные/PEP списки нужно обновлять автоматически; логируйте версию/дату.
- Игнор ончейн-сигналов. Даже при «чистом» KYC поведение может быть сомнительным: следите за графом адресов.
- Жёсткие блоки без объяснений. Коммуникации важны: вовремя запросите документы, объясните причины, фиксируйте сроки.
- Отсутствие плана B по провайдерам. Держите альтернативный канал скрининга/аналитики.
Чек-листы (коротко)
MVP комплаенса для криптосервиса
- Политики AML/CFT и санкций + RBA-матрица.
- KYC/KYB-потоки с эскалацией и refresh.
- Санкционный/PEP-скрининг (ежедневное обновление списков).
- Ончейн-скрининг адресов до вывода.
- Транзакционный мониторинг: алерты по порогам и паттернам.
- Travel Rule (если VASP↔VASP).
- Политика данных: хранение/удаление/доступы.
- Плейбук инцидентов и контактная карта (MLRO/Legal/Sec/PR).
Ончейн-гигиена интерфейса (даже для non-custodial)
- Симуляция транзакций и понятные экраны подписи.
- Предупреждения при взаимодействии с адресами из риск-сеток.
- Никакого blind-signing; логирование ключевых действий.
- Ревок-гайд и напоминания пользователю (см. анти-дрейн).
Частые вопросы (FAQ)
Если мы non-custodial, нам не нужен комплаенс? Нужен — но другого типа: меньше KYC, больше превентивных предупреждений, ончейн-сигналов и документации взаимодействия с VASP/партнёрами.
Можно ли совместить приватность и комплаенс? Да. Используйте «объяснимую приватность»: вывод из приватного пула с доказательством невиновности (см. Privacy Pools), а для адресации — stealth-адреса с возможностью предъявить доказательство источника.
Кто отвечает за заморозку токенов/адресов? Эмитенты некоторых токенов могут делать freeze/wipe по правовым основаниям (см. blacklists). Понимайте политику эмитента и заранее коммуницируйте её пользователям.
Как работать с Tron/низкими комиссиями для массовых переводов? С точки зрения комплаенса важно не «где дешевле», а качественный мониторинг и санкционный скрининг. Для бизнес-практики см. контекст доминирования USDT на Tron.