GH GambleHub

Интеграция 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)

ОшибкаПричинаДействие
406/Неполные данныеНе хватает полей IVMSЗапросить недостающее, повторить
408/TimeoutVASP не отвечаетРетрай, фейловер на хаб, уведомление клиента (hold)
425/UnsupportedКонтрагент не поддерживает протоколВендор-мост/ручной канал по политике или отказ
409/MismatchНесогласованные данные бенефициараHold, запрос уточнений/доков
403/Trust failPKI/сертификат/доверие не сошлисьОтказ, эскалация SecOps/Compliance

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 — и ваши крипто-выплаты/депозиты будут соответствовать требованиям без ущерба для скорости и конверсии.

Contact

Свяжитесь с нами

Обращайтесь по любым вопросам или за поддержкой.Мы всегда готовы помочь!

Telegram
@Gamble_GC
Начать интеграцию

Email — обязателен. Telegram или WhatsApp — по желанию.

Ваше имя необязательно
Email необязательно
Тема необязательно
Сообщение необязательно
Telegram необязательно
@
Если укажете Telegram — мы ответим и там, в дополнение к Email.
WhatsApp необязательно
Формат: +код страны и номер (например, +380XXXXXXXXX).

Нажимая кнопку, вы соглашаетесь на обработку данных.