Как регуляторы проверяют криптобиржи: что они проверяют и как подготовиться

Содержание

• Почему большинство бирж проваливают первый аудит
• Четыре типа регуляторного аудита
• Контроль AML/KYC: раздел, который топит большинство бирж
• Проверка резервов и подтверждение платёжеспособности
• Кибербезопасность и тестирование на проникновение
• Операционный контроль и корпоративное управление
• Ведение учёта: скучная часть, которая важнее всего
• Что происходит, когда вы проваливаете аудит
• Чек-лист подготовки к аудиту, который действительно работает
• Как ваш технологический стек определяет исход аудита

Задолго до самого аудита чек-лист требований комплаенса подскажет, какие настройки аудиторы ожидают увидеть в вашей системе.

Почему большинство бирж проваливают первый аудит

Скажу вам кое-что, от чего должно стать немного не по себе: примерно 60% криптобирж, проходящих свой первый официальный регуляторный аудит, получают существенные замечания. Не мелкие наблюдения. Существенные замечания — те, что могут отложить выдачу лицензии, ограничить вашу деятельность или спровоцировать принудительные меры.

Мы наблюдали это снова и снова. Команда строит надёжную торговую платформу, доводит до ума матчинговый движок, запускает маркетинг и даже привлекает тысячи пользователей. Затем появляется регулятор с первой проверкой, и всё встаёт, потому что биржа не может предоставить элементарные записи о транзакциях шестимесячной давности или AML-политика на бумаге не соответствует тому, что система реально делает.

Проблема обычно не в технической компетентности. Проблема в подготовке. Большинство операторов бирж относятся к комплаенс-документации как к формальности: написать один раз, пройти лицензирование и забыть. Регуляторы же рассматривают её как живую систему, которая должна отражать вашу реальную деятельность в любой момент времени.

Вот в чём разрыв: в заявке на лицензию вы описываете то, что планируете делать. Аудит проверяет то, что вы фактически делали. Если эти две вещи не совпадают, у вас проблемы.

Хорошая новость? Каждую типичную причину провала аудита можно предотвратить. Нужно просто знать, что они ищут.

Четыре типа регуляторного аудита

Не все аудиты одинаковы, и понимание того, с каким из них вы столкнётесь, меняет стратегию подготовки.

1. Предлицензионная проверка

Прежде чем выдать лицензию, некоторые регуляторы направляют инспекторов для проверки ваших заявлений. VARA в Дубае проводит выездные оценки до выдачи полной лицензии. MAS в Сингапуре проводит оценку технологических рисков. Национальные компетентные органы ЕС в рамках MiCA всё чаще проводят выездные визиты до выдачи разрешения.

Что они проверяют: соответствует ли ваша деятельность тому, что описано в заявке? Действительно ли здесь работают указанные вами люди? Реален ли технологический стек или это «воздух»?

2. Плановый надзорный аудит

После получения лицензии большинство регуляторов назначают периодические аудиты — как правило, ежегодно или раз в 18 месяцев. AMF во Франции, BaFin в Германии и MAS проводят регулярные надзорные проверки.

Что они проверяют: постоянное соблюдение условий лицензии. Поддерживаете ли вы контроль, который обещали? Вовремя ли подаются AML-отчёты? Должным ли образом вы сообщали об инцидентах?

3. Тематическая проверка

Иногда регуляторы выбирают конкретную тему и проверяют по ней сразу несколько бирж. В конце 2025 года ESMA провела тематическую проверку практики сегрегации клиентских активов на криптобиржах в шести странах ЕС. FCA сделала нечто подобное в отношении финансовой рекламы.

Что они проверяют: одну конкретную область в деталях. Вы можете блестяще пройти всё остальное и всё равно получить удар по той самой теме, которую они решили изучить под микроскопом.

4. Расследование по конкретному поводу

Что-то вызвало подозрение: жалоба клиента, сообщение о подозрительной операции от банка, необычные торговые паттерны, отмеченные системой рыночного надзора, или сигнал от информатора. Регулятор появляется с конкретными вопросами и куда менее дружелюбным настроем.

Что они проверяют: то, что спровоцировало расследование. Такие проверки точечные, быстрые и сопровождаются гораздо более высокой вероятностью принудительных мер.

Более широкий обзор лицензионных требований в каждой юрисдикции смотрите в нашем руководстве по лицензиям для криптобирж.

Контроль AML/KYC: раздел, который топит большинство бирж

Если ваша биржа и провалит аудит, то, скорее всего, именно здесь. AML/KYC — это область, где у регуляторов больше всего опыта, самые чёткие ожидания и меньше всего терпения к пробелам.

Вот что реально проверяют аудиторы:

Идентификация и верификация клиентов

Они возьмут выборку клиентских аккаунтов — обычно 20-50 из разных категорий риска — и проследят каждый через ваш процесс онбординга. Собрали ли вы необходимые документы? Проверили ли их? Отметила ли ваша KYC-система какие-либо аномалии? Сколько времени заняла верификация? Не начал ли кто-то торговать до завершения проверки?

Вопрос-убийца: «Покажите клиента, которому вы отказали при онбординге, и объясните почему». Если вы не можете предъявить случаи отказа, аудиторы предполагают, что вы одобряете всех подряд, а значит, ваш контроль не работает.

Мониторинг транзакций

Аудиторы хотят увидеть ваши правила мониторинга транзакций, а затем протестировать их. Они спросят: «Что запускает сигнал о подозрительной активности?» Затем посмотрят в ваш журнал алертов. Затем сверят ваши алерты с реальными подозрительными паттернами в ваших данных.

Типичная ошибка: правила на бумаге не соответствуют тому, что делает система. Если в политике написано, что вы отслеживаете структурирование (разбиение крупных транзакций на мелкие для обхода пороговых значений), но в системе мониторинга такого правила фактически нет — это существенное замечание.

История подачи SAR

Сколько сообщений о подозрительной активности (SAR) вы подали? Когда? Что их спровоцировало? Каким был результат?

Ноль SAR — это тревожный сигнал. Это не значит, что у вас чисто. Это значит, что вы не ищете. Каждая биржа со значимым объёмом сталкивается с подозрительной активностью. Аудиторы это знают. Если вы утверждаете, что никогда ничего подозрительного не видели, копать будут глубже.

Расширенная должная проверка (EDD)

Клиенты с высоким риском — PEP (публичные должностные лица), клиенты из юрисдикций с высоким риском, трейдеры с крупными объёмами — должны проходить дополнительную проверку с документированием. Аудиторы запросят ваш список высокорисковых клиентов и проверят, действительно ли проводилась EDD.

Полную картину того, как выглядит комплаенс KYC и AML на практике, мы разобрали в нашем руководстве по KYC-комплаенсу. Прочитайте его до аудита, а не после.

Скрининг по санкционным спискам

Проверяете ли вы клиентов по санкционным спискам OFAC, ЕС и ООН? Как часто обновляете списки? Что происходит при совпадении? Покажите случай, когда у вас было совпадение, и что вы сделали.

Скрининг по санкциям должен быть непрерывным, а не только на этапе онбординга. Если клиент попадает в санкционный список уже после верификации, ваша система должна это отловить. Ваш комплаенс-модуль должен выполнять пакетный повторный скрининг по обновлённым спискам как минимум ежедневно.

Проверка резервов и подтверждение платёжеспособности

После FTX регуляторов глубоко волнует, действительно ли биржи владеют активами, о которых заявляют. Ряд юрисдикций уже требует периодических аттестаций доказательства резервов (proof-of-reserves).

Что проверяют аудиторы:

• Сегрегация активов. Хранятся ли клиентские средства отдельно от операционных? Можете ли вы продемонстрировать чёткую сегрегацию на уровне кошельков? Большинство регуляторов хотят видеть отдельные горячие и холодные кошельки для клиентских и корпоративных активов.
• Обеспечение 1:1. Совпадают ли ваши совокупные обязательства перед клиентами (то, что вы должны пользователям) с совокупными активами (тем, чем вы реально владеете)? Аудиторы сверят ваш внутренний реестр с балансами в блокчейне.
• Аттестация третьей стороной. Некоторые юрисдикции требуют аудит proof-of-reserves от независимых бухгалтерских фирм. Даже там, где это не обязательно, наличие такой аттестации выделяет вас. Такие фирмы, как Armanino и Mazars (пока не прекратили), делали это для крупных бирж.
• Проверка холодного хранения. Аудиторы могут попросить вас подписать сообщение с кошельков холодного хранения, чтобы доказать контроль над ними. Имейте готовую процедуру для этого. Не стоит судорожно искать ключи от аппаратных кошельков, пока регуляторы сидят у вас в офисе.

Типичная ошибка:

Использование клиентских депозитов как оборотного капитала. Даже временно. Даже с намерением вернуть. Если аудиторы обнаружат, что клиентские BTC были переведены на операционный кошелёк биржи — по любой причине — это существенное замечание, а в некоторых юрисдикциях потенциально уголовное преступление.

Кибербезопасность и тестирование на проникновение

Регуляторы всё чаще ожидают от бирж программ безопасности, сопоставимых с программами традиционных финансовых институтов. Технологическая оценка VARA особенно тщательна. MiCA требует от CASP «надёжного управления ИКТ-рисками».

Что хотят увидеть аудиторы:

• Отчёты о тестировании на проникновение. Когда был ваш последний пентест? Кто его проводил? Что нашли? Что исправили? Ежегодные пентесты — минимальное ожидание. Некоторые регуляторы хотят видеть ежеквартальные сканирования уязвимостей в дополнение к ежегодным пентестам.
• План реагирования на инциденты. Не просто документ, а протестированный план. Аудиторы могут спросить о вашем последнем учебном разборе или даже о последнем реальном инциденте. «У нас не было инцидентов» не успокаивает — это намекает, что вы их не обнаруживаете.
• Контроль доступа. У кого есть доступ к производственным системам? Как доступ предоставляется и отзывается? Есть ли многофакторная аутентификация? Ведутся ли журналы административных действий?
• Управление ключами. Как генерируются, хранятся, ротируются и восстанавливаются приватные ключи? Требования к мультиподписи? Использование аппаратных модулей безопасности (HSM)?

Ваша архитектура безопасности должна генерировать документацию, готовую к аудиту. Если нет, вам придётся неделями собирать её вручную перед каждой проверкой.

Технические детали того, как выглядит сильная модель безопасности, разобраны в нашем глубоком погружении в архитектуру безопасности.

Вопрос аудиторского следа:

Каждое действие на вашей платформе — административное или иное — должно логироваться. Аудиторы попросят показать логи конкретных событий: «Покажите журнал доступа к горячему кошельку за последние 30 дней». «Покажите все административные действия по этому аккаунту». «Покажите журнал изменений конфигурации комиссий».

Если вы не можете предоставить эти логи, аудитор не знает, ничего ли не произошло или у вас просто нет записей о том, что произошло. Он предположит худшее.

Ваша админ-панель здесь на передовой. Она должна логировать каждое действие с метками времени, идентификаторами пользователей, IP-адресами и состоянием «до/после» для любых изменений.

Операционный контроль и корпоративное управление

Регуляторы хотят видеть, что вашей биржей управляют компетентные люди с чётко определёнными обязанностями и надзором.

Структура совета директоров и менеджмента:

• Кто несёт конечную ответственность за комплаенс? Назовите его.
• Получает ли ваш совет директоров (или аналогичный надзорный орган) регулярные отчёты о комплаенсе?
• Существует ли документированный путь эскалации комплаенс-вопросов?
• Подвергался ли кто-то из руководства ранее регуляторным мерам? (Они проверят.)

Политики и процедуры:

Аудиторы запросят весь комплект ваших политик. Как минимум:

• Политика AML/CFT
• Процедуры KYC
• Рамки управления рисками
• Политика реагирования на инциденты
• План обеспечения непрерывности бизнеса и аварийного восстановления
• Процедура обработки жалоб
• Политика конфликта интересов
• Политика противодействия рыночным злоупотреблениям и надзора
• Политика защиты данных и конфиденциальности

У каждой политики должен быть номер версии, владелец, дата последнего пересмотра и подтверждение обучения персонала. Политики, написанные два года назад и ни разу не обновлённые, — тревожный сигнал.

Управление изменениями:

Запускали ли вы новый продукт или функцию с момента последнего аудита? Аудиторы хотят видеть, что вы оценили комплаенс-последствия до запуска, а не после. «Мы добавили маржинальную торговлю шесть месяцев назад», за которым следует молчание о комплаенс-ревью, — это замечание.

Ведение учёта: скучная часть, которая важнее всего

Ведению учёта уделяют меньше всего внимания при построении биржи, а больше всего проблем оно создаёт во время аудитов. Вот что нужно хранить и как долго.

Записи о транзакциях: каждая сделка, депозит, вывод и внутренний перевод. Большинство юрисдикций требуют хранения 5-7 лет. MiCA указывает 5 лет. VARA хочет 8 лет. MAS требует 5 лет после завершения деловых отношений.

Записи KYC: все документы, удостоверяющие личность, результаты верификации, досье EDD и записи текущего мониторинга. Те же сроки хранения, что и для записей о транзакциях.

Записи коммуникаций: взаимодействия с клиентской поддержкой, внутренняя комплаенс-переписка и любые коммуникации, связанные с расследованиями подозрительной активности. Да, это значит, что нужно архивировать тикеты поддержки и внутренние чаты.

Системные логи: журналы доступа, ошибок, изменений и событий безопасности. Минимум 2 года, но 5 лет надёжнее.

Формат имеет значение. Записи должны быть доступны для поиска и предоставления в разумные сроки. «Всё в нашей базе данных, но на извлечение нужно две недели» — неприемлемо. Аудиторы ожидают, что конкретные записи будут предоставлены в течение 24-48 часов после запроса.

Закладывайте политику хранения записей в архитектуру системы с первого дня. Внедрять задним числом пятилетнее хранение после того, как вы годами ежегодно очищали данные, — это… не самый приятный разговор с регулятором.

Что происходит, когда вы проваливаете аудит

Результаты аудита обычно делятся на четыре категории:

1. Чистое заключение с наблюдениями. Вы прошли. Аудитор отметил области для улучшения, но ничего, требующего немедленных действий. Отпразднуйте скромно и устраните наблюдения до следующего аудита.

2. Условно положительное заключение с существенными замечаниями. В целом прошли, но есть конкретные области несоответствия требованиям. Вы получите график устранения — обычно 30-90 дней на каждое замечание. Уложитесь в сроки или столкнётесь с последствиями.

3. Отрицательное заключение. Вы провалили. Множественные существенные замечания, возможно, системные проблемы. Регулятор может ограничить вашу деятельность (запрет на онбординг новых клиентов, снижение торговых объёмов) до завершения и проверки устранения. Скорее всего, вас ждёт ускоренный повторный аудит.

4. Отзыв или приостановка лицензии. Худший сценарий. Замечания настолько серьёзны, что регулятор ставит под вопрос само ваше право работать. В крайних случаях, особенно когда под угрозой клиентские активы, регуляторы могут потребовать немедленной приостановки.

Важна и динамика. Если в первом аудите у вас 3 замечания, а во втором 5 — это плохой тренд. Регуляторы хотят видеть улучшения со временем. Ухудшение говорит о том, что руководство не воспринимает комплаенс всерьёз.

Чек-лист подготовки к аудиту, который действительно работает

За шесть недель до аудита начните отсюда:

Недели 6-5: ревизия документации

• Соберите все политики. Проверьте номера версий и даты последнего пересмотра
• Обновите любую политику старше 12 месяцев
• Убедитесь, что политики соответствуют реальному поведению системы (проверьте это, а не просто перечитайте документ)
• Убедитесь, что все обязательные политики существуют (см. список в разделе «Операционный контроль» выше)

Недели 4-3: тестирование систем

• Прогоните собственные правила мониторинга транзакций на тестовых данных. Срабатывают ли они корректно?
• Возьмите случайную выборку из 30 клиентских аккаунтов и проследите их через KYC
• Проверьте, что журнал подачи SAR полон и актуален
• Убедитесь, что вы можете предоставить записи о транзакциях за любой период в течение 24 часов
• Протестируйте аудиторский след вашей админ-панели: можете ли вы показать каждое административное действие за последние 6 месяцев?

Недели 2-1: подготовка людей

• Проинструктируйте комплаенс-офицера о вероятных вопросах и требованиях к доказательствам
• Проинструктируйте CTO или технического руководителя о возможных вопросах по кибербезопасности
• Убедитесь, что ключевые сотрудники доступны в период аудита (никаких отпусков)
• Подготовьте data room (физическую или виртуальную) со всей документацией, структурированной по темам

В день аудита:

• Назначьте контактное лицо, которое координирует запросы аудиторов
• Отвечайте на запросы данных оперативно. Скорость сигнализирует о компетентности
• Если не знаете ответа на вопрос, скажите об этом. Не угадывайте. «Мы вернёмся с ответом до конца дня» лучше, чем неправильный ответ
• Фиксируйте всё, о чём спрашивают аудиторы. Их вопросы показывают, на чём они сфокусированы

Как ваш технологический стек определяет исход аудита

Об этом говорят недостаточно часто: ваше программное обеспечение биржи — главный фактор того, пройдёте вы аудит или провалите его. Не ваша комплаенс-команда (хотя она важна). Не ваши политики (хотя они тоже важны). Ваша технология.

Почему? Потому что аудиторов не волнует, что написано в вашей политике. Их волнует, что делает ваша система. И они проверяют это, извлекая данные из вашей системы.

Что должен поддерживать ваш технологический стек:

• Встроенные аудиторские следы. Каждое действие пользователя, административное действие, системное событие и изменение конфигурации должны логироваться неизменяемо. Если ваше ПО биржи не логирует действия администраторов, вы не сможете доказать наличие управления.
• Отчётность по запросу. Аудиторы будут запрашивать отчёты о транзакциях, статусах KYC, истории подачи SAR и журналы доступа к системам. Если генерация отчёта занимает дни инженерной работы, у вас проблемы. Хорошее ПО для бирж поставляется со встроенной комплаенс-отчётностью.
• Интеграция KYC/AML. Верификация личности, мониторинг транзакций и скрининг по санкциям должны быть интегрированы в платформу, а не прикручены постфактум. Аудиторы проверяют точки интеграции на наличие пробелов.
• Сегрегация активов на уровне инфраструктуры. Архитектура кошельков должна обеспечивать разделение клиентских и операционных средств на уровне дизайна, а не политики. Если человеческая ошибка может случайно смешать средства, это дефект проектирования.
• Настраиваемые комплаенс-правила. В разных юрисдикциях разные пороговые значения, требования к отчётности и ожидания по мониторингу. Система должна позволять настраивать их без кастомной разработки.

Биржи, которые проходят аудиты играючи, — это те, чей технологический стек генерирует комплаенс-доказательства как побочный продукт обычной работы. Если вашей команде приходится вручную собирать доказательства для аудита, что-то не так с вашей архитектурой.

---

Источники и дополнительные материалы

• Руководство FATF по риск-ориентированному подходу к виртуальным активам — Группа разработки финансовых мер борьбы с отмыванием денег
• Регламент MiCA, раздел V: обязанности CASP — Европейский парламент
• Свод правил VARA по комплаенсу и управлению рисками — Управление по регулированию виртуальных активов Дубая
• Руководство MAS по управлению технологическими рисками — Денежно-кредитное управление Сингапура
• Доклад IOSCO о вопросах, рисках и регуляторных аспектах платформ торговли криптоактивами — IOSCO