Intercâmbio de Dados da Travel Rule: TRISA, TRP e OpenVASP (PT-PT)

Se analisarmos a Travel Rule da FATF na sua mecânica, é um problema de mensageria. Antes de uma transferência de cripto ser liquidada, a VASP de envio tem de entregar à VASP de receção um pacote estruturado que descreve o remetente e o beneficiário — nome, identificadores, referências de conta — e o lado recetor tem de confirmá-lo. A questão é que não existe uma única via global para essa comunicação. Em vez disso, existem protocolos de interoperabilidade concorrentes, e uma transferência só é bem-sucedida quando ambas as VASPs conseguem comunicar num deles.

A Didit executa essa comunicação por si. A troca de dados da Travel Rule está integrada no Transaction Monitoring, e o motor opera com os três protocolos que as VASPs realmente utilizam em produção — TRISA, TRP e OpenVASP. Envia a transferência uma vez; o motor resolve a contraparte, escolhe um protocolo que ambos os lados suportam, troca os dados do remetente e do beneficiário, e acompanha a obrigação até um estado. Este guia explica os protocolos, os dados e como a troca funciona.

Principais pontos

• A Travel Rule é uma troca de dados VASP-para-VASP. O remetente transmite informações do remetente e do beneficiário; o recetor recolhe e confirma-as.
• Três protocolos realizam essa troca — TRISA, TRP e OpenVASP — cada um com um modelo de confiança e transporte diferente. A Didit suporta os três.
• Os dados são o registo do remetente e do beneficiário — as partes da transferência, estruturadas para que ambas as VASPs leiam os mesmos campos.
• A Didit executa a troca dentro do Transaction Monitoring, resolvendo cada obrigação para um dos seis estados (UNKNOWN, COMPLIANT, PENDING_ACTION, PENDING_COUNTERPARTY, FAILED, EXEMPT).
• Uma API /v3/. As transferências de cripto são enviadas para POST https://verification.didit.me/v3/transactions/ com currency_kind: "crypto", e a verificação de carteiras é executada em paralelo a partir de $0,02 (traga a sua própria chave).

O que os protocolos fazem

Todos os três protocolos resolvem os mesmos dois problemas — como encontro e confio na VASP contraparte? e como lhe envio os dados do cliente de forma segura? — mas fazem diferentes compromissos.

• TRISA (Travel Rule Information Sharing Architecture) é um modelo peer-to-peer construído sobre uma autoridade de certificação. As VASPs registam-se, provam a sua identidade e recebem certificados, depois trocam dados diretamente através de um canal encriptado. A confiança é ancorada no diretório de membros verificados.
• TRP (Travel Rule Protocol) é uma especificação API-first favorecida por um grupo de grandes instituições. Define uma comunicação REST leve para enviar os dados do remetente e do beneficiário entre contrapartes que estabeleceram uma conexão.
• OpenVASP é um padrão aberto que utiliza sinalização on-chain e na camada de mensagens para estabelecer uma sessão entre VASPs antes da transferência, e depois troca os dados do cliente off-chain.

Uma VASP que deseja um alcance amplo tem de suportar mais do que um, porque as suas contrapartes não utilizarão todas o mesmo protocolo. Executar a troca dentro da Didit significa que não precisa de escolher um e esperar — o motor negocia qualquer protocolo que a contraparte suporte.

Porque é que isto é importante

De acordo com a Recomendação 16 da FATF e as suas implementações regionais — a Regulamentação de Transferência de Fundos da UE entre as principais — a troca de dados do remetente e do beneficiário é obrigatória acima do limite, e os supervisores examinam-na. Mas o requisito é escrito em termos de resultados (os dados devem ser transmitidos, mantidos e confirmados), não de protocolos. A fragmentação dos protocolos é uma realidade de engenharia que se herda, não uma regra que se pode contornar.

É exatamente por isso que o suporte a protocolos não deve ser um problema seu. Configurar o registo TRISA, um endpoint TRP e a sinalização OpenVASP — e manter os três atualizados — é um custo de engenharia contínuo que não tem nada a ver com o seu produto. Integrá-lo no mesmo motor de monitorização que já avalia a transferência reduz esse custo a uma única integração.

Detalhes técnicos

A transferência é criada através da API unificada /v3/. O remetente é o subject, o beneficiário é a counterparty, e currency_kind: "crypto" aciona os caminhos da Travel Rule e da verificação de carteiras.

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "txn_7b9e22",
    "category": "travel_rule",
    "amount": 12500,
    "currency": "BTC",
    "currency_kind": "crypto",
    "direction": "OUTBOUND",
    "txn_date": "2026-05-21T12:14:00Z",
    "subject": {
      "vendor_data": "user_8830",
      "role": "ORIGINATOR",
      "entity_type": "INDIVIDUAL",
      "first_name": "Marta",
      "last_name": "Ferreira"
    },
    "counterparty": {
      "role": "BENEFICIARY",
      "entity_type": "INDIVIDUAL",
      "wallet_address": "bc1q...0a7k"
    }
  }'

O motor resolve a VASP contraparte, seleciona um protocolo suportado, troca os dados e devolve o protocolo utilizado, bem como o estado da Travel Rule:

{
  "transaction_id": "txn_7b9e22",
  "status": "APPROVED",
  "travel_rule_status": "COMPLIANT",
  "protocol": "TRP",
  "counterparty_vasp": "vasp_resolved",
  "wallet_screening": {
    "risk_score": 9,
    "risk_level": "LOW"
  }
}

Os dados do remetente/beneficiário. Cada transferência inclui as duas partes como registos estruturados — o remetente (o cliente que envia) e o beneficiário (o cliente que recebe) — para que ambas as VASPs mapeiem para os mesmos campos, independentemente do protocolo. Os dados do remetente são fornecidos por si a partir do KYC que já possui; os dados do beneficiário são confirmados pela contraparte durante a troca.

Os seis estados. Qualquer que seja o protocolo que realize a troca, a obrigação resolve para um dos seguintes estados:

Estado	Significado
UNKNOWN	Ainda não avaliado, ou a VASP contraparte não pôde ser resolvida.
COMPLIANT	Dados trocados e confirmados — obrigação cumprida.
PENDING_ACTION	Algo do seu lado é necessário para prosseguir.
PENDING_COUNTERPARTY	Aguardando resposta da VASP contraparte.
FAILED	A troca não pôde ser concluída — contraparte inacessível, dados rejeitados ou incompatibilidade de protocolo.
EXEMPT	Fora do âmbito — abaixo do limite ou de outra forma não obrigatório.

Verificação de carteiras em paralelo. O endereço da contraparte é verificado on-chain na mesma chamada a partir de $0,02 por verificação com chave própria (Crystal ou Merkle Science), para que um estado COMPLIANT ao nível do protocolo não oculte um risco ao nível do endereço.

Escolher — e não escolher — um protocolo

A orientação prática para uma VASP é: não escolha. As suas contrapartes estão distribuídas por TRISA, TRP e OpenVASP, e o protocolo que leva uma determinada transferência a COMPLIANT é aquele que essa contraparte suporta. Como a Didit negoceia o protocolo por transferência, a sua integração é a mesma, independentemente de tudo — envia os dados do remetente e do beneficiário uma vez, e o motor trata da comunicação. Um estado FAILED com uma incompatibilidade de protocolo é um sinal para investigar a contraparte, não uma falha na sua infraestrutura.

Casos de uso

• VASPs e Exchanges — alcance contrapartes em todos os três protocolos a partir de uma única integração, em vez de construir e manter cada via.
• On/off-ramps — troque dados do remetente e do beneficiário com as VASPs de destino enquanto verifica a carteira recetora na mesma chamada.
• Custodiantes — lide com um grande número de contrapartes em protocolos mistos com um modelo de estado único e consistente.
• Front-ends DeFi — realize a troca onde uma VASP regulada está no fluxo, e resolva para EXEMPT onde a obrigação genuinamente não se aplica.

Como integrar com a Didit

1. Ative as regras da travel-rule. Na Business Console, ative as regras predefinidas da travel-rule juntamente com a monitorização de cripto e a verificação de cripto.
2. Envie a transferência. POST /v3/transactions/ com currency_kind: "crypto", o remetente como subject, o beneficiário como counterparty, e a categoria travel_rule.
3. Leia o protocolo e o estado. A resposta indica qual protocolo realizou a troca e o travel_rule_status resultante. Aja sobre as obrigações PENDING_* e FAILED.
4. Trabalhe as exceções na Console. Trocas pendentes e falhadas, alertas e o fluxo de trabalho de casos estão disponíveis na mesma interface que a sua monitorização.

Tudo funciona na API unificada /v3/, então o cliente que integrou com KYC, verificou com AML e para quem agora serve uma transferência é a mesma identidade que passa pela monitorização, verificação de carteiras e Travel Rule.

Perguntas Frequentes

Quais protocolos da Travel Rule a Didit suporta?

TRISA, TRP e OpenVASP — os três protocolos que as VASPs usam em produção. O motor negoceia aquele que uma dada contraparte suporta.

Que dados são trocados?

Os registos do remetente e do beneficiário — as partes da transferência — estruturados para que ambas as VASPs leiam os mesmos campos. Fornece os dados do remetente do seu KYC existente; a contraparte confirma os dados do beneficiário.

Tenho de escolher um protocolo?

Não. Escolher um iria isolá-lo de contrapartes nos outros. A Didit seleciona o protocolo por transferência com base no que a contraparte suporta.

O que acontece se a contraparte não puder ser alcançada?

A obrigação resolve para FAILED (com uma razão como incompatibilidade de protocolo ou contraparte inacessível) ou fica em PENDING_COUNTERPARTY enquanto espera — ambos visíveis na Console.

Isto é um produto separado do Transaction Monitoring?

Não. A troca de dados está integrada no Transaction Monitoring, na mesma transferência de cripto que já envia para monitorização e verificação de carteiras.

Pronto para começar?

Leia a documentação da Travel Rule, veja o panorama completo na página da solução Travel Rule para cripto e na página do produto Transaction Monitoring, e consulte os preços transparentes por chamada na página de preços. Quando estiver pronto, comece gratuitamente — 500 verificações KYC gratuitas todos os meses, com a troca de dados da Travel Rule integrada na monitorização.