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

1) Что такое Travel Rule и зачем он нужен

Travel Rule — регуляторное требование для провайдеров виртуальных активов (VASP) обмениваться идентификационными данными отправителя и получателя при переводах криптоактивов. Цель: снизить AML/CTF-риски, упростить расследования и повысить прозрачность кросс-VASР переводов, сохранив работоспособность ончейн-инфраструктуры.

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

2) Объекты и зоны применения

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

3) Какие данные передаются (минимальный состав)

• Имя (или наим. компании), уникальный идентификатор клиента (из вашей системы),
• Адрес/страна или дата рождения (вариативно по стране),
• Номер счета/кошелька (внутренний идентификатор / адрес),
• Контакты (при необходимости), идентификатор VASP (LEI/BIC/рег.номер — где применимо).

• Имя/наименование (если получатель в другом VASP и верифицирован),
• Идентификатор счета/кошелька у бенефициар-VASР,
• При unhosted — сведения, собранные у клиента согласно вашей RBA-политике.

• Актив/сеть (BTC, ETH/chain), сумма, timestamp,
• Payment/Transfer ID, референс на KYT/санкционный скрининг,
• Идентификатор сессии/сообщения 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: поиск контр-VASР (реестр, 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) KYT/санкции pre-check → 3) Discovery контрагента → 4) Обмен IVMS101 (до ончейн) → 5) Решение (allow/hold) → 6) Ончейн-броадкаст → 7) Пост-фактум отчетность/логирование.

6) Unhosted кошельки: политика и проверки

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

7) Интеграция с KYT/санкциями и 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 (KYT/санкции): ≤ 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.
• Интеграция KYT/санкций в 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, интегрируйте KYT/санкции и RBA-решения, защитите PII и задайте понятные SLA. Тогда переводы VASP↔VASP и работа с unhosted-адресами будут быстрыми, соответствующими требованиям и не разрушат конверсию.