Integração dos provedores Travel Rule

1) Objetivo de integração

• suportar o modelo canônico IVMS101,
• ter uma camada de adaptador agnóstico para o provedor,
• garantir a segurança (mTLS, assinatura, criptografia) e SLA,
• abranger hosted↔hosted e políticas para unhosted.

2) Seleção de protocolo/provedor: modelos

2. 1 Protocolos e redes de confiança

TRISA/TRP/ OpenVASP - p2r/federações com PKI, diretórios VASP, confirmação de entrega.
Hub/agregadores comerciais - abstrata transporte, dá Discovery e Routing.

2. 2 Critérios de seleção (resumo)

Cobertura de jurisdição/VASR, Diretoria/Discovery qualidade.
Compatibilidade com IVMS101 e extensões.
Segurança (PKI, mTLS, assinatura), latency/SLA, retraí/quórum.
Custo por mensagem/volume, relatórios e auditoria.
Suporte unhosted policy (validação de propriedade de endereço), sandbox e certificação.

3) Arquitetura de integração

1. O Payments Core → está a iniciar a criptoperrejuga.

2. O Compliance Orquestrator → decide se o Travel Rule (limiar/geo/tipo de contrapartida) é necessário.

3. Travel Rule Gateway (seu serviço)

Modelo IVMS101 canônico;

Adaptadores para TRISA/TRP/OpenVASP/Agregador;

Assinatura/criptografia, idempotidade, retraí/quotas.
4. Diretory/Discovery → Pesquisando um contracheque, validando certificados/políticas.
5. KYT/Santions Engine → pré-check-up.
6. PII Vault → armazenamento de campos pessoais, tocenização, RBAC/auditoria.

1. Criação do pedido → 2) CUT/sanções pré-check → 3) Discovery VASP → 4) Troca de IVMS101 (request/response) → 5) Solução allow/hold/rejt → 6) Onchain broadcast → 7) Logi/relatório.

4) Modelo de dados canônicos (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.

Prática: Armazene o IVMS101 como «modelo canonical» no seu banco de dados; adaptadores fazem transformações em um protocolo específico.

5) Security & Trust

mTLS com autenticação mútua (PKI/Diretoria).
Assinatura de mensagens e criptografia de conteúdo end-to-end (PII).
RBAC/SoD: separação de papéis para envio/aprovação/exportação de dados.
Registros/logs imutáveis: quem/o/quando enviou a versão do esquema.

6) Discovery/Directory

Procure uma contrapartida de ID VASP, domínio, LEIA/BIC (onde está disponível).
Armazenamento de gravações, rotação de certificados, lista de CA confiáveis.
Canal de folback: pedido de confirmação de adereços através do agregador ou «ponte» (se a política permitir).

7) Gerenciamento de fluxo e SLA

• Discovery + exchange p95: ≤ 60–120 с.
• Pre-KYT p95: ≤ 5–15 с.
• Solução auto-case: ≤ 2-5 min, manual High-risk: ≤ 4 h.

• Backoff exponencial + jitter; idimpotência por 'travel _ rule _ mensagem _ id'.
• Conversão automática para adaptador de reserva/hab em degradação.
• Quórum de confirmação de entrega/leitura (ACK/NACK).

8) Processamento de erros (playbook)

9) Política para carteiras unhosted

Confirmação de propriedade do endereço (assinada, «Prof-Microexame»).
KYT antes da inscrição e antes da retirada; limites por segmento.
Address book/whitelist com TTL e revalidação periódica.
Documente as exceções RBA (pequenas quantias/low risk) - onde é legal.

10) PII Vault e privacidade

Separe o PII dos logs de operações e dados de pagamento.
Criptografia (KMS/HSM), torneamento de ID, acesso need-to-know.
Retenção por jurisdição (muitas vezes 5 + anos), exposição automática, procedimentos DSR.
Versionização dos circuitos IVMS101 e auditoria trail para cada troca.

11) Pattern de integração

11. 1 Camada de adaptação

Interface: 'send (ivms _ payload) -> ack '/' receive () -> ivms _ payload'.
Transformações: IVMS101 ⇄ formato específico (TRISA/TRP/OpenVASP/hab).
Versioning API, webhooks assinados, reencontros determinados.

11. 2 Soluções Compliance

Матрица RBA: `allow` / `limit` / `hold` / `reject` / `escalate`.
Partial release se parte dos fundos são «limpos».
Ligação com KYT: Não envie Travel Rule por rotas aparentemente proibidas.

11. 3 Confiabilidade

Dois ou mais provedores/protocolo através de um Gateway único.
Health-checks, circuito-breaker, real-time alerts.

12) Testes e entrada em operação

Sandbox provedor + seu simulador contábil.
Conjunto de malas: dados completos/incompletos, temporizações, mismatch, desconfiança PKI.
Testes de carga (torneios de pico/promoções), medição de p50/p95/perdas.
Treinamento Payments/Risk/Suporte: links de comunicação com clientes.

13) Métricas e dashboards

Coverage%: taxa de transferência VASP↔VASP com sucesso.
SLA hit rate по Discovery/Exchange/Decision.
Retry/Failure rate, причины (timeout/mismatch/unsupported/trust).
Hold/Reject% e tempo médio de desbloqueio.
Complaint/Party rate em Travel Rule, NPS de saída.
Costa per Exchange (all-in): provedor + ópera. hora.

14) Anti-pattern

Envio onchain antes que o Travel Rule seja concluído onde você quiser «pré-transferência».
Rígido por provedor sem adaptação de abstração.
Armazenamento de PII em logs compartilhados/analíticos sem toquenização.
Falta de idempotação → duplicação de mensagens/soluções.
Ignorar unhosted-policy e verificação direcionada.
Não há versionagem de diagramas/diretórios → soluções «inatingíveis».

15) Folha de cheque RFP/implementação (curta)

• Suporte IVMS101 (campos obrigatórios/opcionais), validações.
• Protocolo (s): TRISA/TRP/OpenVASP, agregadores; Discovery/Directory и PKI.
• Segurança: mTLS, assinatura/criptografia, registro de ação, signed webhooks.
• SLA/retrai: alvos p95, backoff + jitter, circuito-breaker, feelover.
• Compatibilidade com KUT/Sanções, API pré-Check-Check e Maculação Coral.
• Unhosted-policy: confirmação de endereço, whitelist com TTL, limites.
• PII Vault: criptografia, RBAC/SoD, retenção/DSR, auditoria.
• Relatórios: artefatos de troca, versões de circuitos/marcas, exportação para SAR/TR.
• Sandbox/simuladores, testes de carga e resistência a falhas.
• Treinamento de comandos e modelos de comunicação com clientes.

16) Resumos

A integração do Travel Rule é uma arquitetura gateway com o IVMS101 como modelo canônico, Discovery/PKI para confiança, adaptadores para vários provedores e regras de segurança rígidas/PII. Vincule-a a soluções KYT e RBA, estabeleça políticas para unhosted, forneça SLA/Fawer e UX transparente - e seus pagamentos/depósitos cripto serão adequados sem comprometer a velocidade e a conversão.