Клієнт надіслав 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 його фактично прибрали, вимоги діють з першого євро.
- Перевіряється не разова сума, а сукупність переказів за період — дробити платежі марно.
- Якщо отримувач — незареєстрований майданчик, обмінник зобов'язаний або відмовити, або запросити дані вручну.
Як дані передаються технічно
Вручну ганяти імена поштою ніхто не хоче — для цього існують протоколи обміну: TRUST, Notabene, Sygna Bridge, VerifyVASP, відкритий стандарт OpenVASP. Вони шифрують пакет із даними клієнта і прив'язують його до конкретної транзакції за хешем, тож повідомлення доходить саме до потрібного отримувача.
Обміннику не обов'язково писати інтеграцію з нуля: більшість провайдерів travel-rule-повідомлень підключаються як API поверх уже наявної системи комплаєнсу, а не замінюють її.
Ризики й обмеження — що може піти не так
Головний біль — «sunrise problem»: далеко не всі майданчики у світі вже підключені до якогось протоколу, і переказ може зависнути просто тому, що отримувачу нічим прийняти зашифрований пакет.
Другий ризик — хибні спрацювання комплаєнс-фільтрів: система блокує легітимний переказ через неповний збіг імені в паспорті та у формі. І третій — приватність: що більше персональних даних гуляє між майданчиками, то дорожче обходиться витік при зламі одного з них.
Часті помилки обмінників під час підготовки
Найчастіша помилка — відкладати питання до першої відмови від партнерського банку. На цей момент перемовини з новим платіжним партнером тривають тижнями, а клієнти вже незадоволені зависаннями переказів.
- Покладатися на ручну звірку даних замість протоколу — не масштабується далі десятка переказів на день.
- Не документувати процес для регулятора — під час перевірки нема чим підтвердити, що правило взагалі дотримується.
- Ігнорувати перекази на self-hosted гаманці, хоча банк-партнер уже вимагає мінімальні дані і по них.
Висновок
Travel Rule — не одноразова галочка, а частина інфраструктури, з якою обміннику доведеться жити постійно: протоколи оновлюються, пороги в різних країнах змінюються, а партнери посилюють вимоги швидше, ніж хотілося б. Розумніше вбудувати передачу даних у процес із самого початку, а не лагодити його після першого замороженого переказу. Запустити обмінник із продуманою архітектурою комплаєнсу та KYC-процесів можна на платформі iEXExchanger.
