Integrazione dei provider Travel Rule

1) Obiettivo di integrazione

• supportare il modello canonico IVMS101,
• avere un livello di adattamento agnostico al provider,
• garantire la sicurezza (mTLS, firma, crittografia) e SLA,
• coprire il hosted↔hosted e la politica per unhosted.

2) Selezione del protocollo/provider: modelli

2. 1 Protocolli e reti di fiducia

TRISA/TRP/ OpenVASP - p2r/federazioni con PKI, directory VASP, conferma della consegna.
Hub/aggregatori commerciali - Abstrattano i trasporti, danno Discovery e routing.

2. 2 Criteri di selezione (riepilogo)

Copertura delle giurisdizioni/VASR, Directory/Discovery qualità.
Compatibilità con IVMS101 e estensioni.
Sicurezza (PKI, mTLS, firma), latency/SLA, retrai/quorum.
Costo per messaggio/volume, report e revisione.
Supporto unhosted policy (convalida proprietà indirizzo), sandbox e certificazione.

3) Architettura di integrazione dell'arbitro

1. Payments Core → innesca la criptoperuota.

2. Compliance Orchestrator decide se è necessario un Travel Rule (soglia/geo/tipo di contropartita).

3. Travel Rule Gateway (il tuo servizio)

Modello IVMS101 canonico;

Adattamento a TRISA/TRP/OpenVASP/aggregatore;

Firma/crittografia, idampotenza, retrai/quote.
4. Directory/Discovery esegue la ricerca della controparte, convalida dei certificati/regole.
5. KYT/Sanctions Engine prima dello scambio.
6. PII Vault: conservazione dei campi personali, tornizzazione, RBAC/controllo.

1. Creazione della richiesta di rimborso 2) CUT/pre-check 3) Discovery VASP (4) Scambio IVMS101 (richiest/response) 5) Soluzione allow/hold/reject (6) Onchain Broadcast (7) Logi/report.

4) Modello di dati canonico (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.

Pratica: memorizzare IVMS101 come «model canonical» nel suo database; gli adattatori trasformano in un protocollo specifico.

5) Security & Trust

mTLS con autenticazione reciproca (PKI/Directory).
Firma messaggi e crittografia dei contenuti (PII) end-to-end.
RBAC/SoD Separa i ruoli per inviare/approvare/esportare i dati.
Registri/fogli invariati: chi/cosa/quando ha inviato la versione dello schema.

6) Discovery/Directory

Cerca una controparte per ID VASP, dominio, LEGGI/BIC (disponibile).
Cache dei record, rotazione dei certificati, elenco dei certificati CA attendibili.
Feed - Chiede di confermare le informazioni tramite aggregatore o ponte (se consentito da criteri).

7) Gestione dei flussi e SLA

• Discovery + exchange p95: ≤ 60–120 с.
• Pre-KYT p95: ≤ 5–15 с.
• Auto-case: 2-5 minuti, High-risk a mano: 4 ore

• Backoff esponenziale + jitter; Idimpotenza per «travel _ rule _ messaggistica _ id».
• Connessione automatica all'adattatore/hab di riserva in caso di degrado.
• Quorum di conferma di consegna/lettura (ACK/NACK).

8) Gestione degli errori (playbook)

9) Politica per i portafogli unhosted

Conferma della proprietà dell'indirizzo (firma «laghetto microperacale»).
KYT prima dell'iscrizione e prima dell'output; limiti per segmento.
Address book/whitelist con TTL e ricontrollo periodico.
Documentare le eccezioni RBA (piccole somme/low risk) - se è legale.

10) PII Vault e privacy

Separare il PII dai database operativi e dai dati di pagamento.
Crittografia (KMS/HSM), tornitura degli identificatori, accesso need-to-know.
Recensione per giurisdizione (spesso 5 + anni), esportazione automatica, procedure DSR.
Versioning dei circuiti IVMS101 e verifiche trail per ogni scambio.

11) Modelli di integrazione

11. 1 Livello adattatore

Interfaccia: 'send (ivms _ payload) -> ack'/' receive () -> ivms _ payload'.
Trasformazioni: IVMS101 formato specifico (TRISA/TRP/OpenVASP/hab).
Versioning API, webhoop firmati, ripartenze determinate.

11. 2 Soluzioni Compliance

Матрица RBA: `allow` / `limit` / `hold` / `reject` / `escalate`.
Parziale release se parte dei fondi sono puliti.
Collegamento a KYT: non inviare Travel Rule attraverso percorsi chiaramente proibiti.

11. 3 Affidabilità

Due o più provider/protocollo tramite un unico Gateway.
Health-checks, circuito-breaker, real-time alert.

12) Test e messa in funzione

Sandbox provider + il vostro simulatore di contropartita.
Set di valigette: dati completi/incompleti, timeout, mismatch, sfiducia PKI.
Test di carico (tornei/promozioni di picco), misurazione p50/p95/perdita.
Formazione Payments/Risk/Support: script di comunicazione con i clienti.

13) Metriche e dashboard

Coverage%: percentuale di traduzioni con successo.
SLA hit rate по Discovery/Exchange/Decision.
Retry/Failure rate, причины (timeout/mismatch/unsupported/trust).
Hold/Reject% e tempo medio di sblocco.
Complaint/Ticket rate su Travel Rule, output NPS.
Cost per Exchange (all-in) - Provider + operatore. Il tempo.

14) Anti-pattern

Invio onchain fino al completamento di Travel Rule dove si desidera «pre-transfer».
Allacciamento rigido per provider senza adattamento-astrazione.
Conservare il PII in un layout/analitico condiviso senza tornasole.
La mancanza di idepotenza consente di recuperare messaggi/soluzioni.
Ignora unhosted-policy e controlli di indirizzo.
Nessuna versioning di diagrammi/directory per soluzioni «inconfondibili».

15) Foglio di assegno RFP/implementazione (breve)

• Supporto IVMS101 (campi obbligatori/opzionali), convalida.
• Protocollo (s): TRISA/TRP/OpenVASP, aggregatori; Discovery/Directory и PKI.
• Protezione: mTLS, firma/crittografia, registro delle azioni, signed webhooks.
• SLA/retrai: obiettivi p95, backoff + jitter, circuito-breaker, faulker.
• Compatibilità con KUT/Sanzioni, API pre-check e valigetta corretta.
• Unhosted-policy: conferma indirizzo, whitelist con TTL, limiti.
• PII Vault: crittografia, RBAC/SoD, retrazione/DSR, controllo.
• Report: artefatti di scambio, versioni di schemi/etichette, esportazione per SAR/TR.
• Sandbox/simulatori, test di carico e failover.
• Formazione dei comandi e modelli di comunicazione con i clienti.

16) Riepilogo

L'integrazione di Travel Rule è un'architettura gateway con IVMS101 come modello canonico, Discovery/PKI per la fiducia, adattatori per più provider e regole di sicurezza/PII rigorose. Collegatela con le soluzioni KYT e RBA, stipula una politica per unhosted, assicuri SLA/feelover e UX trasparente - e i vostri pagamenti crypto/depositi soddisferanno i requisiti senza compromettere la velocità e la conversione.