Travel Rule для крипто-платежів

1) Що таке Travel Rule і навіщо він потрібен

Travel Rule - регуляторна вимога для провайдерів віртуальних активів (VASP) обмінюватися ідентифікаційними даними відправника і одержувача при переказах криптоактивів. Мета: знизити AML/CTF-ризики, спростити розслідування і підвищити прозорість крос-VASP перекладів, зберігши працездатність ончейн-інфраструктури.

• Дані «подорожують» разом з перекладом (off-chain канал зв'язку VASP↔VASP).
• Вимоги і пороги залежать від юрисдикції; часто поріг близький до ~ 1000 (в еквіваленті), але в ряді режимів поширюється і на менші суми - фіксуйте локальну норму в своїй політиці.
• Вимоги розрізняють hosted (кастодіальні) і unhosted (самостійні) гаманці.

2) Об'єкти та зони застосування

VASP → VASP (hosted ↔ hosted): повний обмін даними за стандартом (переважно до ончейн-броадкасту).
VASP → Unhosted (самокастодія): збір/верифікація відомостей про адресата та походження коштів з локальної політики RBA; обмін з «контрагентом-VASP» відсутній.
Cross-border: використовуйте Discovery/Directory і угоди довіри для пошуку контрагента і безпечного каналу.

3) Які дані передаються (мінімальний склад)

• Ім'я (або найм. компанії), унікальний ідентифікатор клієнта (з вашої системи),
• Адреса/країна або дата народження (варіативно по країні),
• Номер рахунку/гаманця (внутрішній ідентифікатор/адреса),
• Контакти (при необхідності), ідентифікатор VASP (LEI/BIC/реєстр. номер - де застосовується).

• Ім'я/найменування (якщо одержувач в іншому VASP і верифікований),
• Ідентифікатор рахунку/гаманця у бенефіціар-VASP,
• При unhosted - відомості, зібрані у клієнта згідно вашої RBA-політики.

• Актив/мережа (BTC, ETH/chain), сума, timestamp,
• Payment/Transfer ID, референс на КУТ/санкційний скринінг,
• Ідентифікатор сесії/повідомлення Travel Rule.

4) Стандарти та протоколи обміну

IVMS101 - модель даних (що і як іменувати).
TRISA/TRP/OpenVASP - мережеві протоколи і «мережі довіри» (PKI, mTLS, каталоги VASP, маршрутизація, підтвердження доставки).
Комерційні хаби/агрегатори можуть реалізовувати сумісність (Gateway-підхід) і Discovery.

Рекомендація: абстрагуйте транспорт (Adapter-шар) і зберігайте IVMS101 як «canonical model», щоб вільно міняти провайдера/протокол без ломки API.

5) Архітектура впровадження (референс)

1. Travel Rule Gateway (мікросервіс): прийом/відправка IVMS101-повідомлень, підпис/шифрування, ретраї, квоти.

2. Directory/Discovery: пошук контр-VASP (реєстр, PKI, політика довіри).

3. KYT/Sanctions Engine: скринінг адрес/бірж/кластерів, оцінка ризику перед відправкою.

4. Compliance Engine (RBA): прийняття рішення: allow/hold/reject/запит доп.даних.

5. Case Management: кейси, вкладення, SLA, ескалації (L1/L2/L3).

6. PII Vault: безпечне сховище персональних даних (шифрування, токенізація, RBAC, аудит).

1. Клієнт створює переклад → 2) КУТ/санкції pre-check → 3) Discovery контрагента → 4) Обмін IVMS101 (до ончейн) → 5) Рішення (allow/hold) → 6) Ончейн-броадкаст → 7) Пост-фактум звітність/логування.

6) Unhosted гаманці: політика та перевірки

Збір відомостей про контрагента у клієнта (ім'я/країна/відношення), підтвердження володіння адресою (підпис повідомленням, дрібний «пруф-трансфер», верифікація на біржі).
Ризик-правила: заборона/ліміти для адрес з високим KYT-ризиком (міксери, «темні» ринки, санкційні кластери), заборона P2P-майданчиків без KYC по вашій політиці.
Білі списки адрес (address book/whitelisting) з TTL і рев'ю.

7) Інтеграція з КУТ/санкціями та AML

KYT (Know Your Transaction): ризик-оцінка адрес/бірж, зв'язку до N-хопів з «поганими» кластерами, аномалії обсягу/маршрутів.
Санкції: скринінг клієнта/контрагента (KYC/KYB) та інфраструктури (біржі, кастодіани).
Позитивний ризик → hold, запит документів (SoF/SoW) і/або відмова, при необхідності - SAR/STR.

8) Дані та приватність (GDPR/безпека)

Мінімізація: зберігайте тільки необхідні Travel Rule поля; відокремте PII від платіжних PAN/ключів.
Шифрування: в спокої (KMS/HSM) і в транзиті (mTLS), ротація ключів.
Доступ: суворе RBAC, журнал дій, принцип «need-to-know».
Ретеншн: за законом юрисдикції (часто 5 + років); автоматична експірація та звіти з видалення.
DSR: процедури доступу/виправлення/видалення, де застосовується.

9) SLA, ретраї та деградація

• Pre-check (КУТ/санкції): ≤ 5–15 c p95.
• Discovery+Exchange (VASP↔VASP): ≤ 60-120 c p95 (включаючи ретраї).
• Рішення (allow/hold/reject): ≤ 2-5 хв p95 для авто-кейсів; ручний огляд High-risk - ≤ 4 год.

• Експоненціальний backoff + джиттер; Альтернативні ендпоінти.
• Sunrise-проблема (контрагент не підтримує Travel Rule): RBA-виключення/ліміти, ручний обмін по зашифрованому каналу (якщо допускається політикою/законом) або відмова.

10) UX-патерни (не ламаючи конверсію)

Передзаповнення даних одержувача для частих перекладів (адресна книга).
Ясні повідомлення: «Потрібне підтвердження адреси »/« Потрібні дані одержувача для відповідності правилу».
Контекстні перевірки (підпис адреси, мікропереклад) з покроковими підказками.
Статуси і таймери по hold/перевірці, прозорі очікування.
Альтернативи: «Отримати на біржі з KYC» при відмові unhosted.

11) Метрики та контроль якості

• Travel Rule coverage% (частка переказів VASP↔VASP з успішним обміном IVMS101).
• Частка unhosted з пройденою верифікацією адреси і SoF (по порогу).
• SLA hit rate по обміну/рішенням; частка ручних кейсів.

• KYT high-risk rate, відмов щодо санкцій, SAR-conversion.
• Повторні алерти за адресами/кластерами, share «false positive» за KYT.

• Час до перекладу p50/p95, відмова через Travel Rule (impact), конверсія повторних перекладів (адресна книга).

12) Матриця рішень (ескіз)

13) Анти-патерни

Відправлення ончейн до завершення обміну даними VASP↔VASP (при режимах, де потрібно до перекладу).
«Глуха» блокування всіх unhosted без RBA-винятків і адресної верифікації.
Відсутність Discovery/Directory → нестабільна доставка і часті false hold.
Зберігання надлишкових PII без мети/ретеншну; нерозділені логи і PII.
Жорстка зав'язка на одного провайдера протоколу без абстракції (vendor lock-in).

14) Чек-лист впровадження

• Політика Travel Rule: юрисдикції, пороги, hosted/unhosted, RBA-винятки.
• Канонічна модель IVMS101 і Adapter-шар під TRISA/TRP/OpenVASP.
• Directory/Discovery и PKI/mTLS; управління довіреними VASP.
• Інтеграція КУТ/санкцій в pre-check; правила hold/reject.
• PII Vault: шифрування, RBAC, аудит, ретеншн/DSR.
• SLA/ретраї/алерти, дешборди метрик; плейбуки деградацій.
• Процеси для unhosted: адресна верифікація, SoF-запити, білі списки.
• Case-менеджмент і шаблони комунікацій; SAR/STR процедури.
• Тестові стенди: емуляція VASP-контрагента, failure-сценарії, load-тест.
• Навчання Payments/Risk/Compliance/Support і регулярні навчання.

15) Резюме

Travel Rule - це не «про крипту», а про операційно-безпечний обмін даними між VASP. Побудуйте шлюз з IVMS101 як канонічною моделлю, підключіть Discovery/Directory, інтегруйте КУТ/санкції і RBA-рішення, захистіть PII і задайте зрозумілі SLA. Тоді переклади VASP↔VASP і робота з unhosted-адресами будуть швидкими, відповідними вимогам і не зруйнують конверсію.