Интеграция Travel Rule провайдеров
1) Цель интеграции
Travel Rule требует обмена идентификационными данными Originator/Beneficiary между VASP до или в момент крипто-перевода (по требованиям юрисдикции). Интеграция должна:- поддерживать каноническую модель IVMS101,
- иметь агностичный к провайдеру Adapter-слой,
- обеспечивать безопасность (mTLS, подпись, шифрование) и SLA,
- охватывать hosted↔hosted и политику для unhosted.
2) Выбор протокола/провайдера: модели
2.1 Протоколы и сети доверия
TRISA / TRP / OpenVASP — p2p/федерации с PKI, каталогами VASP, подтверждением доставки.
Коммерческие хабы/агрегаторы — абстрагируют транспорт, дают Discovery и маршрутизацию.
2.2 Критерии выбора (сводка)
Покрытие юрисдикций/VASР, Directory/Discovery качество.
Совместимость с IVMS101 и расширениями.
Безопасность (PKI, mTLS, подпись), latency/SLA, ретраи/кворумы.
Стоимость за сообщение/объем, отчетность и аудит.
Поддержка unhosted policy (валидация владения адресом), sandbox и сертификация.
3) Референс-архитектура интеграции
Слои:1. Payments Core → инициирует криптоперевод.
2. Compliance Orchestrator → решает, требуется ли Travel Rule (порог/гео/тип контрагента).
3. Travel Rule Gateway (ваш сервис)
Каноническая IVMS101 модель;
Adapters к TRISA/TRP/OpenVASP/агрегатору;
Подпись/шифрование, идемпотентность, ретраи/квоты.
4. Directory/Discovery → поиск контрагента, валидация сертификатов/политик.
5. KYT/Sanctions Engine → pre-check до обмена.
6. PII Vault → хранение персональных полей, токенизация, RBAC/аудит.
1. Создание заявки → 2) KYT/санкции pre-check → 3) Discovery VASP → 4) Обмен IVMS101 (request/response) → 5) Решение allow/hold/reject → 6) Ончейн-броадкаст → 7) Логи/отчет.
4) Каноническая модель данных (IVMS101)
Minimum viable payload (пример):- Originator: name, identifier, country/address or DOB, account/wallet id.
- Beneficiary: name (при VASP), account/wallet id.
- Transaction: asset, chain, amount, timestamp, internal transfer id.
- Compliance refs: KYT check id, sanctions screen id, Travel Rule message id.
Практика: храните IVMS101 как «canonical model» в своей БД; адаптеры делают трансформации в конкретный протокол.
5) Security & Trust
mTLS со взаимной аутентификацией (PKI/Directory).
Подпись сообщений и end-to-end шифрование контента (PII).
RBAC/SoD: разделение ролей для отправки/одобрения/экспорта данных.
Журналы/неизменяемые логи: кто/что/когда отправил, версия схемы.
6) Discovery/Directory
Поиск контрагента по VASР-идентификатору, домену, LEI/BIC (где доступно).
Кэширование записей, ротация сертификатов, список доверенных CA.
Фолбэк-канал: запрос подтверждения реквизитов через агрегатор или «мост» (если допускается политикой).
7) Управление потоками и SLA
Ориентиры:- Discovery + exchange p95: ≤ 60–120 с.
- Pre-KYT p95: ≤ 5–15 с.
- Решение auto-case: ≤ 2–5 мин, ручные High-risk: ≤ 4 ч.
- Экспоненциальный backoff + джиттер; идемпотентность по `travel_rule_message_id`.
- Автопереключение на резервный adapter/хаб при деградации.
- Кворум подтверждений доставки/прочтения (ACK/NACK).
8) Обработка ошибок (playbook)
9) Политика для unhosted-кошельков
Подтверждение владения адресом (подпись, «пруф-микроперевод»).
KYT до зачисления и перед выводом; лимиты по сегментам.
Address book/whitelist с TTL и периодической реверификацией.
Документируйте исключения RBA (малые суммы/low risk) — где это законно.
10) PII Vault и приватность
Отделите PII от операционных логов и платежных данных.
Шифрование (KMS/HSM), токенизация идентификаторов, need-to-know доступ.
Retention по юрисдикции (часто 5+ лет), авто-экспирация, DSR-процедуры.
Версионирование схем IVMS101 и audit trail для каждого обмена.
11) Интеграционные паттерны
11.1 Adapter-слой
Интерфейс: `send(ivms_payload) -> ack` / `receive() -> ivms_payload`.
Трансформации: IVMS101 ⇄ конкретный формат (TRISA/TRP/OpenVASP/хаб).
Версионирование API, подписанные вебхуки, детерминированные повторные отправки.
11.2 Решения Compliance
Матрица RBA: `allow` / `limit` / `hold` / `reject` / `escalate`.
Partial release если часть средств «чиста».
Связка с KYT: не отправляйте Travel Rule по очевидно запрещенным маршрутам.
11.3 Надежность
Два и более провайдера/протокола через единый Gateway.
Health-checks, circuit-breaker, real-time алерты.
12) Тестирование и ввод в эксплуатацию
Sandbox провайдера + ваш симулятор контрагента.
Набор кейсов: полные/неполные данные, таймауты, mismatch, недоверие PKI.
Нагрузочные тесты (пиковые турниры/акции), замер p50/p95/потерь.
Обучение Payments/Risk/Support: скрипты коммуникаций с клиентами.
13) Метрики и дашборды
Coverage %: доля VASP↔VASP переводов с успешным обменом.
SLA hit rate по Discovery/Exchange/Decision.
Retry/Failure rate, причины (timeout/mismatch/unsupported/trust).
Hold/Reject % и среднее время разблокировки.
Complaint/Ticket rate по Travel Rule, NPS вывода.
Cost per Exchange (all-in): провайдер + опер.время.
14) Анти-паттерны
Ончейн-отправка до завершения Travel Rule там, где нужно «pre-transfer».
Жесткая завязка на одного провайдера без Adapter-абстракции.
Хранение PII в общих логах/аналитике без токенизации.
Отсутствие идемпотентности → дубли сообщений/решений.
Игнор unhosted-policy и адресной верификации.
Нет версионирования схем/каталогов → «неповторяемые» решения.
15) Чек-лист RFP / внедрения (коротко)
- Поддержка IVMS101 (обязательные/опциональные поля), валидации.
- Протокол(ы): TRISA/TRP/OpenVASP, агрегаторы; Discovery/Directory и PKI.
- Безопасность: mTLS, подпись/шифрование, журнал действий, signed webhooks.
- SLA/ретраи: цели p95, backoff+jitter, circuit-breaker, фейловер.
- Совместимость с KYT/санкциями, pre-check API и кореляция кейсов.
- Unhosted-policy: подтверждение адреса, whitelist с TTL, лимиты.
- PII Vault: шифрование, RBAC/SoD, retention/DSR, аудит.
- Отчетность: артефакты обмена, версии схем/меток, экспорт для SAR/STR.
- Sandbox/симуляторы, нагрузочные и отказоустойчивые тесты.
- Обучение команд и шаблоны коммуникаций с клиентами.
16) Резюме
Интеграция Travel Rule — это gateway-архитектура с IVMS101 как канонической моделью, Discovery/PKI для доверия, адаптерами к нескольким провайдерам и строгими правилами безопасности/PII. Свяжите ее с KYT и RBA-решениями, пропишите политику для unhosted, обеспечьте SLA/фейловер и прозрачный UX — и ваши крипто-выплаты/депозиты будут соответствовать требованиям без ущерба для скорости и конверсии.