Клиент отправил 5000 USDT, а перевод завис на сутки — партнёр запросил имя и адрес получателя. Это и есть Travel Rule для криптообменников: требование FATF передавать данные отправителя и получателя вместе с самим переводом, если сумма выше порога, установленного в стране.
Правило появилось не вчера, но именно в 2026 году его начали спрашивать всерьёз — банки и биржи-партнёры массово блокируют переводы от VASP, которые не подтвердили соответствие. Для обменника это уже не абстрактный комплаенс, а вопрос доступа к ликвидности.
Что такое Travel Rule простыми словами
Представьте банковский перевод: вместе с деньгами всегда идёт имя отправителя и назначение платежа — это стандарт SWIFT ещё с прошлого века. Travel Rule переносит тот же принцип в крипту: платформа-отправитель обязана передать платформе-получателю имя, номер кошелька и, часто, адрес клиента.
Формально правило — это Рекомендация 16 FATF, но в каждой стране её реализуют по-своему: где-то порог 1000 долларов, где-то 1000 евро, где-то данные нужны на любую сумму.
Кого это касается и с какой суммы
Правило применяется к переводам между VASP — то есть между обменником и любой другой лицензированной платформой: биржей, кошельком с KYC, другим обменником. Перевод на несамостоятельный (self-hosted) кошелёк формально под Travel Rule не подпадает, но регуляторы всё активнее просят собирать данные и в этом случае — на всякий случай.
- Порог обычно 1000 USD/EUR — но в ЕС по MiCA его фактически убрали, требования действуют с первого евро.
- Проверяется не разовая сумма, а совокупность переводов за период — дробить платежи бесполезно.
- Если получатель — незарегистрированная площадка, обменник обязан либо отказать, либо запросить данные вручную.
Как данные передаются технически
Вручную гонять имена по email никто не хочет — для этого существуют протоколы обмена: TRUST, Notabene, Sygna Bridge, VerifyVASP, открытый стандарт OpenVASP. Они шифруют пакет с данными клиента и привязывают его к конкретной транзакции по хэшу, так что сообщение доходит до нужного получателя, а не куда попало.
Обменнику не обязательно писать интеграцию с нуля: большинство провайдеров travel-rule-сообщений подключаются как API поверх уже работающей системы комплаенса, а не заменяют её.
Риски и ограничения — что может пойти не так
Главная боль — «sunrise problem»: далеко не все площадки в мире уже подключены к какому-либо протоколу, и перевод может зависнуть просто потому, что получателю нечем принять зашифрованный пакет.
Второй риск — ложные срабатывания комплаенс-фильтров: система блокирует легитимный перевод из-за неполного совпадения имени в паспорте и в форме. И третий — приватность: чем больше персональных данных гуляет между площадками, тем выше цена утечки при взломе одной из них.
Частые ошибки обменников при подготовке
Самая частая ошибка — откладывать вопрос до первого отказа от партнёрского банка. К этому моменту переговоры с новым платёжным партнёром занимают недели, а клиенты уже недовольны зависшими переводами.
- Полагаться на ручную сверку данных вместо протокола — не масштабируется дальше десятка переводов в день.
- Не документировать процесс для регулятора — при проверке нечем подтвердить, что правило вообще соблюдается.
- Игнорировать переводы на self-hosted кошельки, хотя банк-партнёр уже требует по ним минимальные данные.
Вывод
Travel Rule — не разовая галочка, а часть инфраструктуры, с которой обменнику придётся жить постоянно: протоколы обновляются, пороги в разных странах меняются, а партнёры ужесточают требования быстрее, чем хотелось бы. Разумнее встроить передачу данных в процесс с самого начала, а не чинить его после первого замороженного перевода. Запустить обменник с продуманной архитектурой комплаенса и KYC-процессов можно на платформе iEXExchanger.
