Інтеграція Travel Rule провайдерів

1) Мета інтеграції

• підтримувати канонічну модель IVMS101,
• мати агностичний до провайдера Adapter-шар,
• забезпечувати безпеку (mTLS, підпис, шифрування) і SLA,
• охоплювати hosted↔hosted і політику для unhosted.

2) Вибір протоколу/провайдера: моделі

2. 1 Протоколи та мережі довіри

TRISA/TRP/OpenVASP - р2р/федерації з 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) КУТ/санкції pre-check → 3) Discovery VASP → 4) Обмін IVMS101 (request/response) → 5) Рішення allow/hold/reject → 6) Ончейн-броадкаст → 7) Логи/звіт.

4) Канонічна модель даних (IVMS101)

• 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

Пошук контрагента по VASP-ідентифікатору, домену, 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.
Навантажувальні тести (пікові турніри/акції), завмер р50/р95/втрат.
Навчання 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, фейловер.
• Сумісність з КУТ/санкціями, 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 - і ваші крипто-виплати/депозити будуть відповідати вимогам без шкоди для швидкості і конверсії.