Implementação da Travel Rule · Aula 4 de 5
Carteiras não hospedadas e transferências de autocustódia
8 min de leitura
Uma transferência de ou para uma carteira de autocustódia não tem uma segunda VASP para receber dados, executar controles ou responder a perguntas. O próprio cliente da empresa é a única parte obrigada na transação, então tudo o que a Travel Rule normalmente dividiria entre duas prestadoras recai sobre uma só. Os órgãos de supervisão esperam cada vez mais que as empresas demonstrem uma abordagem deliberada e baseada em evidências para essas transferências, em vez de ignorá-las ou proibi-las por completo.
Por que as transferências de autocustódia são importantes
Uma carteira não hospedada (carteira de autocustódia) é controlada por seu usuário por meio de suas próprias chaves, sem um prestador de serviços intermediário. As transferências entre essas carteiras são peer-to-peer (P2P) e ficam fora do perímetro de AML/CFT até que os valores cheguem a uma VASP ou instituição financeira. É nesse ponto de entrada ou saída que se aplicam os controles da empresa.
A FATF já identificou repetidamente as transferências P2P por meio de carteiras não hospedadas como um risco prioritário em seus relatórios direcionados e atualizações anuais, observando que nenhuma entidade obrigada vê essas transferências ou as reporta.
A maioria das transferências de autocustódia é legítima: os clientes transferem ativos para armazenamento a frio, usam DeFi ou recebem pagamentos de pessoas físicas. A tarefa é distinguir essas transferências daquelas que movimentam valores para terceiros ou agentes ilícitos.
O que a FATF espera
Pessoas físicas que usam suas próprias carteiras não são entidades obrigadas, portanto não há ninguém para quem enviar uma mensagem da Travel Rule. A orientação da FATF sobre ativos virtuais não proíbe essas transferências. Em vez disso, espera-se que as VASPs:
- obtenham do próprio cliente as informações exigidas sobre o originador e o beneficiário e as mantenham;
- verifiquem os nomes em listas de sanções e cumpram os deveres de congelamento e proibição previstos na R.16;
- usem as informações no monitoramento de transações e na comunicação de transações suspeitas;
- apliquem controles baseados em risco e proporcionais ao risco, como monitoramento reforçado, limites ou restrições a transferências para endereços que a empresa tenha avaliado.
Os países podem acrescentar exigências. Alguns regimes, por exemplo, exigem que as empresas verifiquem se o cliente é proprietário ou controla um endereço de autocustódia acima de determinado valor, enquanto outros deixam o método a critério da avaliação de risco da empresa. A aula Como os regimes nacionais implementam o padrão mostra como mapear essas diferenças.
Uma abordagem baseada em risco
Uma política viável atribui uma pontuação a cada transferência de autocustódia com base em alguns fatores e define os controles conforme o resultado:
| Fator | Menor risco | Maior risco |
|---|---|---|
| Propriedade | Endereço próprio do cliente, propriedade comprovada | Terceiro, relação desconhecida |
| Histórico do endereço | Verificado anteriormente e usado sem problemas | Primeiro uso ou criado recentemente |
| Exposição identificada por análise | Nenhuma exposição significativa a categorias ilícitas | Exposição direta ou próxima a grupos associados a sanções, mixers, golpes ou mercados da darknet |
| Valor e padrão | Compatíveis com o perfil do cliente | Alto, repentino ou logo abaixo dos limites internos |
| Risco do cliente | Padrão | Pontuação de alto risco, PEP, alteração recente do perfil |
Os controles então se intensificam: registrar e monitorar; exigir comprovação de propriedade; solicitar os dados do terceiro e a finalidade; aplicar um limite menor ou reter a transferência para análise; ou rejeitá-la. A política deve especificar quem pode aprovar exceções e quais evidências são necessárias em cada etapa. A exposição identificada por análise é abordada em detalhes na aula Verificação de carteiras e transações.
Comprovação da propriedade de um endereço
Os métodos mais robustos comprovam o controle da chave privada, não apenas o conhecimento do endereço:
- Mensagem assinada. O cliente assina um texto de desafio escolhido pela empresa, que inclui um valor aleatório e uma data, usando a chave associada ao endereço, e a empresa verifica a assinatura. Há especificações abertas para isso: BIP-322 para Bitcoin, EIP-191 e EIP-712 para contas no estilo Ethereum e EIP-1271 para carteiras de contratos inteligentes, que validam assinaturas por meio do próprio código.
- Teste de satoshi. O cliente envia da carteira um valor pequeno, especificado pela empresa, para a empresa. Isso comprova o controle do endereço naquele momento, ao custo de uma tarifa e de um breve atraso.
- Microtransferência reversa. A empresa envia um valor pequeno e incomum para o endereço e pede ao cliente que o informe. Isso comprova apenas que o cliente consegue ver o endereço, algo que qualquer pessoa pode fazer em um explorador de blocos, portanto é um método fraco.
- Captura de tela ou declaração. Uma captura de tela de um aplicativo de carteira ou uma declaração assinada é fácil de falsificar e não comprova o controle da chave. Use isso apenas como informação complementar em casos de baixo risco.
Cada método comprova o controle em um determinado momento. As chaves podem ser compartilhadas, vendidas ou comprometidas, portanto as verificações de propriedade complementam o monitoramento, mas não o substituem. Carteiras multisig exigem cuidado: uma assinatura pode mostrar que o cliente detém uma chave, não que controla a carteira.
Um endereço verificado deve gerar um registro de evidências que um auditor possa verificar novamente:
{
"customer_id": "C-20418",
"address": "bc1q…4h8s",
"chain": "bitcoin",
"method": "signed_message_bip322",
"challenge": "Alpha Exchange ownership check C-20418 2026-10-14 nonce 7f3e91",
"signature": "AkcwRAIg…Qe1",
"verified_at": "2026-10-14T09:42:17Z",
"verified_by": "system",
"result": "pass",
"analytics_check": { "risk_category": "none_detected", "checked_at": "2026-10-14T09:42:20Z" },
"review_due": "2027-10-14"
}O registro mantém o texto exato do desafio e a assinatura, para que a verificação possa ser repetida, junto com o resultado da análise naquele momento e uma data para revisão. O nonce e a data no desafio impedem que o cliente reutilize uma assinatura feita para outra empresa ou para uma verificação anterior.
Quando coletar dados do originador e do beneficiário
Os dados vêm do próprio cliente da empresa, e o que deve ser solicitado depende da direção da transferência e de quem controla a outra carteira:
| Transferência | Parte principal (carteira própria do cliente) | Terceiro |
|---|---|---|
| Saída para carteira de autocustódia | Registrar que beneficiário e originador são a mesma pessoa; comprovar a propriedade de acordo com o risco | Coletar o nome do beneficiário e, conforme o risco, o endereço ou outros dados e a finalidade |
| Entrada de carteira de autocustódia | Registrar o cliente como originador; comprovar a propriedade de acordo com o risco | Coletar o nome do originador e sua relação com o cliente; considerar a origem dos fundos |
As transferências recebidas de terceiros merecem atenção, porque um cliente que recebe valores de muitas carteiras de autocustódia sem relação entre si pode estar atuando como mula financeira ou empresa não registrada. Os dados coletados pela empresa são tão confiáveis quanto as respostas do cliente, portanto devem ser comparados com o que a blockchain mostra: uma “carteira própria” que recebe valores de dezenas de desconhecidos não está se comportando como tal.
Falhas comuns
As análises dos controles de carteiras de autocustódia tendem a encontrar as mesmas fragilidades:
- Capturas de tela aceitas como comprovação para transferências de alto valor ou alto risco, porque os métodos mais robustos pareciam inconvenientes.
- Verificar uma vez e confiar para sempre. Um endereço verificado há anos continua sendo tratado como verificado, embora seu comportamento tenha mudado completamente.
- Ausência de dados de terceiros. O formulário de saque solicita apenas um endereço, então a empresa não consegue dizer quem recebeu os fundos.
- Controles desconectados do monitoramento. Os resultados das verificações de propriedade e as relações declaradas ficam armazenados em um sistema e nunca chegam às regras de monitoramento que poderiam usá-los.
- Tratamento inconsistente. Equipes diferentes aplicam limites ou métodos distintos a transferências semelhantes, e ninguém consegue explicar o motivo.
É fácil testar cada falha: selecione uma amostra de endereços verificados, refaça a verificação a partir do registro de evidências e compare a relação declarada com o padrão observado na blockchain.
Caso prático
Um cliente com dois anos de histórico e uma pontuação de risco padrão recebe ETH no valor de US$ 9.500 de um endereço de autocustódia nunca visto antes. A análise não mostra exposição a atividades ilícitas. O cliente declara que a carteira é própria.
- De acordo com a política, uma primeira transferência de um novo endereço de autocustódia acima do nível interno de análise aciona uma verificação de propriedade.
- A empresa envia um desafio e o cliente retorna uma assinatura EIP-191 válida. O endereço é verificado e registrado.
- Os fundos são creditados, e o endereço é incluído na lista de endereços verificados do cliente com uma data para revisão.
Um mês depois, o mesmo endereço envia cinco transferências em uma semana, e a análise mostra que ele recebe valores de várias carteiras criadas recentemente e financiadas por um grupo conhecido de golpes. A comprovação de propriedade anterior não encerra a questão: o analista abre um alerta, pergunta ao cliente sobre a origem dos fundos e considera comunicar uma transação suspeita.
Foco no exame: por que carteiras não hospedadas não podem receber mensagens da Travel Rule e o que a FATF espera em seu lugar (coletar informações do próprio cliente, mantê-las, fazer verificações, monitorar e aplicar controles baseados em risco); que a FATF não proíbe essas transferências; fatores de risco e controles graduais para transferências de autocustódia; os quatro métodos de comprovação de propriedade e quais comprovam o controle da chave (mensagem assinada, teste de satoshi), em oposição à visibilidade (microtransferência reversa) ou a nenhum controle (captura de tela); ressalvas sobre EIP-1271 e carteiras multisig; coleta de dados de partes principais versus terceiros; e que a comprovação de propriedade é uma verificação pontual que não substitui o monitoramento.