Dados e mensagens da Travel Rule

Um programa de Travel Rule só é tão bom quanto as mensagens que envia e recebe. As equipes de compliance não precisam escrever o código, mas devem ser capazes de ler uma mensagem, identificar um campo ausente ou malformado, avaliar se um protocolo autentica a contraparte e protege os dados e decidir quando os dados devem chegar. Esta aula oferece esse conhecimento prático.

IVMS101: um modelo de dados compartilhado

O interVASP Messaging Standard (IVMS101) define como os dados do originador e do beneficiário são estruturados para que quaisquer duas VASPs possam ler as mensagens uma da outra. Um grupo de trabalho conjunto do setor publicou a primeira versão em maio de 2020. A versão atual, IVMS 101.2023, é mantida pelo interVASP Standards Working Group, que lançou uma atualização em junho de 2024.

IVMS101 é um modelo de dados, não um protocolo. Sua própria declaração de escopo exclui segurança da informação, privacidade de dados, identificação de VASPs, protocolos de rede e armazenamento, e nada diz sobre como a VASP do beneficiário usa os dados. Detalhes da transação, como o ativo, o valor e o txid, também estão fora de seu escopo; o protocolo de mensagens os transporta em seu próprio envelope.

O modelo tem um pequeno número de elementos básicos:

Os nomes são divididos em primaryIdentifier (geralmente o sobrenome) e secondaryIdentifier (nomes próprios), cada um marcado com um código de tipo, como LEGL para o nome legal ou ALIA para um nome alternativo. Nomes em escrita nacional vão em localNameIdentifier, com a forma latina em nameIdentifier. Os endereços contêm um addressType (HOME, BIZZ ou GEOG), um townName e um country obrigatórios, e addressLine ou campos de rua estruturados. Os identificadores nacionais contêm um nationalIdentifierType, como CCPT (passaporte), RAID (identificador de autoridade de registro) ou LEIX (LEI).

Regras de validação que vale a pena conhecer

O IVMS101 associa restrições ao modelo, e um revisor de compliance pode usá-las como lista de verificação:

• Um originador que seja pessoa natural deve ter pelo menos um dos seguintes elementos: endereço geográfico, identificação do cliente, identificação nacional ou data e local de nascimento. Isso reflete o elemento “um de” no conjunto de dados do FATF.
• Toda pessoa precisa de pelo menos um nome do tipo LEGL.
• Os valores de país devem ser códigos ISO 3166-1 alpha-2 (ou XX), e as datas devem seguir a ISO 8601. A data de nascimento deve estar no passado.
• O identificador nacional de uma pessoa jurídica deve ser do tipo RAID, MISC, LEIX ou TXID. Um LEI não contém país de emissão nem autoridade de registro.
• Os dados devem estar em UTF-8 e, salvo indicação em contrário, em escrita latina.

A aprovação na validação mostra que uma mensagem está bem formada. Não mostra que os dados sejam verdadeiros ou que pertençam ao cliente correto.

Uma mensagem de exemplo

{
  "payloadMetadata": { "payloadVersion": "101.2023" },
  "originator": { "originatorPerson": [ {
    "naturalPerson": {
      "name": { "nameIdentifier": [ { "primaryIdentifier": "Moreau", "secondaryIdentifier": "Lea",
                "naturalPersonNameIdentifierType": "LEGL" } ] },
      "geographicAddress": [ { "addressType": "HOME", "streetName": "Harbor Road", "buildingNumber": "18",
                "townName": "Port Alder", "country": "XX" } ],
      "dateAndPlaceOfBirth": { "dateOfBirth": "1990-03-14", "placeOfBirth": "Port Alder" } },
    "accountNumber": [ "bc1q…7k3f" ] } ] },
  "beneficiary": { "beneficiaryPerson": [ {
    "naturalPerson": { "name": { "nameIdentifier": [ { "primaryIdentifier": "Okafor",
                "secondaryIdentifier": "Chidi", "naturalPersonNameIdentifierType": "LEGL" } ] } },
    "accountNumber": [ "bc1q…9m2x" ] } ] },
  "originatingVASP": { "originatingVASP": { "legalPerson": {
    "name": { "nameIdentifier": [ { "legalPersonName": "Alpha Exchange Ltd", "legalPersonNameIdentifierType": "LEGL" } ] },
    "nationalIdentification": { "nationalIdentifier": "5493…0042", "nationalIdentifierType": "LEIX" } } } }
}

A mensagem fictícia mostra um originador que é pessoa natural, com nome legal, endereço residencial, data e local de nascimento, o que satisfaz com folga a regra do “um de”. O beneficiário tem apenas nome e conta, que é tudo o que se espera que a VASP de origem saiba. A VASP de origem se identifica pelo nome legal e pelo LEI (truncado aqui). O código de país XX é permitido pelo padrão; uma mensagem real teria o código ISO. Normalmente, viria em seguida um bloco beneficiaryVASP.

As versões importam. Na versão de 2020, a lista de originadores era plural (originatorPersons), o número da conta ficava diretamente dentro de originador e beneficiário, e o elemento de tipo de nome da pessoa natural era nameIdentifierType (um exemplo desenvolvido no próprio texto de 2023 ainda usa o nome antigo, por isso uma análise sintática tolerante ajuda). Um analisador que espera uma versão pode descartar dados silenciosamente da outra, e é por isso que o IVMS 101.2023 torna payloadVersion obrigatório.

Análise de uma mensagem recebida

Quando uma mensagem chega, a VASP do beneficiário segue uma sequência definida antes de aceitá-la:

1. Versão e validade. Leia payloadVersion, analise com o esquema correspondente e execute as verificações de restrições. Uma mensagem que falha é uma exceção, não um êxito parcial.
2. Correspondência da conta. Confirme que o accountNumber (ou o endereço e a etiqueta no envelope do protocolo) é um endereço de depósito de um de seus clientes.
3. Correspondência do nome. Compare o nome do beneficiário com o nome verificado do titular da conta. Use uma correspondência aproximada que tolere identificadores primário e secundário invertidos, acentos ausentes, diferenças de transliteração e nomes do meio, e registre a pontuação e o motivo da aceitação ou rejeição.
4. Triagem do originador. Verifique o nome do originador e, quando disponível, a data de nascimento em relação às listas de sanções, e incorpore os dados ao monitoramento.
5. Verificação da contraparte. Confirme que a originatingVASP corresponde ao remetente autenticado e a uma contraparte com diligência prévia atualizada.
6. Decisão e armazenamento. Aceite ou rejeite, envie a resposta e armazene juntos a mensagem, a resposta e o txid final.

As etapas 3 e 4 são onde surgem a maioria dos casos concretos: pagamentos à pessoa errada, contas usadas por alguém que não é o titular e correspondências com listas de sanções.

Protocolos e redes

O IVMS101 precisa de um meio de transporte. As soluções se dividem em dois grandes grupos:

• Protocolos abertos publicam suas especificações para que qualquer pessoa possa implementá-los. O TRP (Travel Rule Protocol), atualmente mantido pela OpenVASP Association, é um protocolo baseado em API que usa TLS com autenticação mútua e um “Travel Address” que codifica o endpoint da VASP do beneficiário. O TRISA (Travel Rule Information Sharing Architecture) combina um diretório, certificados emitidos para VASPs verificadas, conexões com autenticação mútua e envelopes selados que somente o destinatário pode descriptografar. O OpenVASP começou como um protocolo separado antes de sua associação assumir a administração do TRP.
• Redes fechadas são operadas por um único operador que admite membros, hospeda o diretório e, muitas vezes, encaminha as mensagens. Pode ser mais fácil ingressar nelas, mas a empresa fica vinculada à cobertura desse operador.

Toda solução precisa resolver os mesmos quatro problemas:

A interoperabilidade é a lacuna prática mais comum. Uma empresa que oferece suporte a um protocolo só consegue se conectar aos membros desse protocolo; por isso, a maioria das empresas oferece suporte a vários protocolos ou usa pontes e testa se os campos permanecem intactos durante a tradução.

Fluxos anteriores e posteriores à transação

Em um fluxo anterior à transação, a VASP de origem envia os dados, aguarda a aceitação da VASP do beneficiário e só então transmite a transação e envia o txid. Em um fluxo posterior à transação, a transação é transmitida primeiro e os dados são enviados depois.

A exchange anterior à transação é um controle mais robusto, porque uma transferência confirmada não pode ser revertida. Fluxos posteriores à transação continuam sendo comuns quando a ferramenta da contraparte não consegue responder em tempo real; nesse caso, a empresa precisa monitorar o atraso efetivo na chegada dos dados.

Foco no exame: que o IVMS101 é um modelo de dados, não um protocolo, e o que seu escopo exclui (segurança, identificação de VASPs, transporte, dados da transação); as principais entidades e elementos do IVMS 101.2023, tipos de nome como LEGL, tipos de endereço e tipos de identificador como LEIX; regras essenciais de validação (a regra do “um de” para originadores que são pessoas naturais, um nome legal obrigatório, formatos ISO de país e data); leitura de uma mensagem de exemplo e identificação de um elemento ausente; diferenças entre as versões de 2020 e 2023 e por que payloadVersion importa; protocolos abertos versus redes fechadas e os quatro problemas de descoberta, autenticação, criptografia e interoperabilidade; fluxos anteriores versus posteriores à transação.