Travel Rule para pagamento de cripto

1) O que é Travel Rule e o que é necessário

O Travel Rule é um requisito regulatório para os provedores de ativos virtuais (VASP) compartilharem as informações de identificação do remetente e do destinatário nas transferências de criptoativos. O objetivo é reduzir os riscos AML/CTF, simplificar as investigações e aumentar a transparência das transferências cross-VASP, mantendo a infraestrutura onchain operacional.

• Os dados «viajam» com a tradução (canal de comunicação off-chain VASP↔VASP).
• Os requisitos e liminares dependem da jurisdição; muitas vezes o limite é próximo de £1000 (equivalente), mas em vários modos também se aplica a valores menores - fixe a norma local na sua política.
• Os requisitos distinguem as carteiras hosted (castodial) e unhosted (independente).

2) Objetos e áreas de aplicação

VASP → VASP (hosted ↔ hosted): compartilhamento completo de dados com o padrão (preferencialmente até onchain broadcast).
VASP → Unhosted (autodeclaração): coleta/verifica informações sobre o endereço e a origem de ferramentas de política local RBA; Não há troca com «contratante-VASP».
Cross-border: Use o Discovery/Diretoria e os acordos de confiança para encontrar um contêiner e um canal seguro.

3) Quais dados são transmitidos (composição mínima)

• Nome (ou vestir). empresa), identificador único do cliente (do seu sistema),
• Endereço/país ou data de nascimento (variável no país),
• Número de conta/carteira (ID/endereço interno),
• Contatos (se necessário), ID VASP (LEIA/BIC/pare. número - onde se aplica).

• Nome/nome (se o destinatário estiver em outro VASP e estiver verificado),
• Identificador de conta/carteira do beneficiário-VASP,
• Com unhosted - informações coletadas do cliente de acordo com sua política RBA.

• Ativo/rede (BTC, ETH/chain), soma, timestamp,
• Payment/Transfer ID, árbitro em KUT/screening de sanções,
• ID da sessão/mensagem Travel Rule.

4) Padrões e protocolos de troca

O IVMS101 é um modelo de dados (o que e como nomear).
TRISA/TRP/ OpenVASP - Protocolos de rede e «redes de confiança» (PKI, mTLS, diretórios VASP, roteiro, confirmação de entrega).
Os hub/agregadores comerciais podem implementar a compatibilidade (abordagem Gateway) e Discovery.

Recomendação: abstraia o transporte (camada de adaptação) e armazene o IVMS101 como «modelo canonical» para alterar livremente o provedor/protocolo sem quebrar a API.

5) Arquitetura de implementação (arbitragem)

1. Travel Rule Gateway (microsserviço): recepção/envio de mensagens IVMS101, assinatura/criptografia, retais, quotas.

2. Diretory/Discovery: pesquisa contra-VASP (registro, PKI, política de confiança).

3. KYT/Santions Engine: screening de endereços/bolsas/cluster, avaliação de risco antes do envio.

4. Compliance Engine (RBA): tomada de decisão: allow/hold/reject/pedido de adição.

5. Case Management: malas, anexos, SLA, escalações (L1/L2/L3).

6. PII Vault: Armazenamento seguro de dados pessoais (criptografia, tocenização, RBAC, auditoria).

1. O cliente cria a tradução → 2) CUT/sanções pré-check → 3) Discovery do contratante → 4) Troca IVMS101 (antes onchain) → 5) Solução (allow/hold) → 6) Onchain broadcast → 7) Pós-faturamento/loging.

6) Carteiras unhosted: políticas e verificações

Coletar informações sobre o contracheque do cliente (nome/país/relação), comprovante de propriedade do endereço (assinatura da mensagem, pequena transferência «prourfe», credencial em bolsa).
Regras de risco: proibição/limites para endereços de alto risco KYT (misturadores, mercados «escuros», clusters de sanções), proibição de locais P2P sem KYC por sua política.
Lista branca de endereços (address book/whitelisting) com TTL e revezamento.

7) Integração com KUT/Sanções e AML

KYT (Know Your Transmissão): avaliação de risco de endereços/bolsas, comunicações de até N-hop com clusters «ruins», anomalias de volume/rotas.
Sanções: screening cliente/contratante (KYC/KYB) e infraestrutura (bolsas, castodianos).
Risco positivo → hold, solicitação de documentos (SoF/SoW) e/ou rejeição, se necessário - SAR/TR.

8) Dados e privacidade (GDPR/segurança)

Minimizar: guarde apenas os campos exigidos por Travel Rule; separa o PII dos PAN/chaves de pagamento.
Criptografia em paz (KMS/HSM) e em trânsito (mTLS), rotação de chaves.
Acesso: RBAC rigoroso, registro de ação, princípio «need-to-know».
Retensschn: de acordo com a lei de jurisdição (muitas vezes 5 + anos); exportação automática e relatórios de remoção.
DSR: procedimentos de acesso/correção/remoção, onde aplicável.

9) SLA, retais e degradação

• Pré-check (KUT/Sanções): ≤ 5-15 c p95.
• Discovery + Exchange (VASP↔VASP): ≤ 60-120 c p95 (incluindo retraí).
• Solução (allow/hold/reject): ≤ 2-5 min p95 para malas automáticas; Visão manual de High-risk - ≤ 4 h.

• Backoff exponencial + jitter; endpoints alternativos.
• Problema Sunrise (o contêiner não suporta Travel Rule): exceções RBA/limite, troca manual por canal criptografado (se permitido por política/lei) ou rejeição.

10) Pattern ux (sem quebra de conversão)

Preenchimento dos dados do destinatário para traduções frequentes (livro de endereços).
Mensagens claras: «É necessário confirmar o endereço »/« Os dados do destinatário são necessários para corresponder à regra».
Verificações contextuais (assinaturas de endereço, microexame) com dicas passo a passo.
Estados e temporizadores hold/verificação, espera transparente.
Alternativas: «Obter na bolsa com KYC» quando a unhosted desistir.

11) Métricas e controle de qualidade

• Travel Rule coverage% (proporção de transferências VASP↔VASP com câmbio bem-sucedido IVMS101).
• Proporção de unhosted com verificação de endereço e SoF concluídos (no limite).
• SLA hit rate sobre compartilhamento/soluções; A parte das malas manuais.

• KYT high-risk rate, recusas de sanções, SAR-conversão.
• Alertas repetidas em endereços/clusters, share «falso positivo» em KYT.

• Tempo até a tradução p50/p95, rejeição devido a Travel Rule (impact), conversão de traduções (livro de endereços).

12) Matriz de soluções (esboço)

13) Anti-pattern

Envia onchain até a troca de dados ser concluída (nos modos em que você deseja antes da tradução).
Bloqueio «surdo» de todos os unhosted sem exceções RBA ou verificação direcionada.
Falta do Discovery/Diretoria → entrega instável e freqüência falsa hold.
Armazenamento de PII redundante sem alvo/retensor; logs não compartilhados e PII.
Rígido por provedor de protocolo sem abstração (vendor lock-in).

14) Folha de cheque de implementação

• Política Travel Rule: jurisdição, liminares, hosted/unhosted, RBA-exclusão.
• Modelo canônico IVMS101 e camada Adapter abaixo do TRISA/TRP/OpenVASP.
• Directory/Discovery и PKI/mTLS; gerenciamento de VASP de confiança.
• Integração da CUT/sanções no pré-check; regras hold/reject.
• PII Vault: criptografia, RBAC, auditoria, retino/DSR.
• SLA/retais/alertas, varas de métricas; playbooks de degradação.
• Processos para unhosted: verificação de endereços, consultas SoF, listas brancas.
• Gestão casada e modelos de comunicação; Procedimentos SAR/TR.
• Estandes de teste: emulação do contêiner VASP, guiões failure, teste load.
• Treinamento Payments/Risk/Compliance/Apoio e exercícios regulares.

15) Resumos

O Travel Rule não é sobre a cripta, mas sobre o intercâmbio de dados operacionais e seguros entre a VASP. Construa o gateway com o IVMS101 como modelo canônico, conecta o Discovery/Diretoria, integre o COOT/sanções e soluções RBA, proteja o PII e especifique os SLA compreensíveis. As traduções de VASP↔VASP e o trabalho com endereços unhosted serão rápidos, adequados e não destruirão a conversão.