Trabalhando com provedores de serviços

O rastreamento on-chain geralmente termina em um serviço: uma exchange, um custodiante, um emissor de stablecoin, um processador de pagamentos. A partir daí, as evidências que identificam pessoas e mostram para onde os valores foram em seguida estão nos próprios sistemas do provedor. Obtê-las depende de pedir ao provedor certo, no momento certo, exatamente os registros necessários e, depois, analisar a resposta com o mesmo ceticismo aplicado a qualquer outra fonte.

O que os provedores podem armazenar

Provedores diferentes veem partes diferentes de uma transação. Saber quem armazena o quê evita solicitações desperdiçadas e fontes não identificadas.

O limiar legal geralmente aumenta com a sensibilidade: é mais fácil obter dados de assinantes do que dados de tráfego, que, por sua vez, são mais fáceis de obter do que conteúdo. A aula Autorização legal e cooperação internacional aborda os instrumentos.

Preserve primeiro

Os provedores mantêm registros por períodos limitados, e alguns apagam contas encerradas. Uma solicitação de preservação pede ao provedor que congele uma cópia dos registros especificados até a chegada de uma ordem de produção. É barata, rápida e, muitas vezes, a única forma de impedir que os dados desapareçam enquanto a solicitação formal é preparada.

Envie a solicitação de preservação assim que uma conta for identificada, não quando a ordem de produção estiver pronta. Peça ao provedor que confirme por escrito o que foi preservado e até quando, e registre a data de expiração. Se o caso exigir também que os fundos sejam bloqueados, além da preservação dos registros, envie uma solicitação voluntária de congelamento separada, citando as evidências de que os fundos são produto de crime; os provedores decidem sobre congelamentos segundo seus próprios termos de serviço e deveres legais.

Redigindo uma solicitação precisa

Os provedores pesquisam seus sistemas por identificador. Solicitações vagas causam atrasos, respostas parciais ou recusas. Uma boa solicitação tem três partes.

• Identificadores: cada endereço com sua blockchain e ativo, cada txid com seu horário e valor, IDs de conta, endereços de e-mail ou nomes de usuário, se conhecidos.
• Período: início e fim em UTC, com amplitude suficiente para abranger a abertura da conta e as atividades posteriores.
• Campos: os registros específicos desejados, em vez de “todas as informações”.

SOLICITAÇÃO DE PRESERVAÇÃO  ref CF-2026-0147/P-01  enviada 2026-03-04 11:02 UTC
Para: Exchange K, equipe de resposta a autoridades policiais
Base legal: [ordem ou poder, com referência]   Não divulgação solicitada: sim
Identificadores:
  - Endereço de depósito TQx7…4mPa (rede Tron, USDT TRC-20)
  - txid de entrada 7b2f…d9e0, 2026-03-04 07:13:52 UTC, 9.800,00 USDT
Período: 2026-02-01 00:00 UTC até a data da resposta
Preservar, para cada conta vinculada a estes identificadores:
  - Registro e documentos de KYC; registros de IP de cadastro e login, com portas
  - Identificadores de dispositivo e sessão; contas bancárias e cartões vinculados
  - Livro-razão interno: depósitos, negociações, transferências internas, saques
  - Endereços de saque e txids; dados da Travel Rule enviados ou recebidos
  - Comunicações com o titular da conta
Contato: [nome, cargo, telefone e e-mail oficiais]

A solicitação especifica a rede, além do endereço, porque o mesmo formato de endereço pode existir em várias blockchains, e fornece o txid de entrada para que o provedor encontre a conta, mesmo que o endereço tenha sido reatribuído. Ela solicita registros de IP com portas de origem, que podem ser necessárias quando os endereços são compartilhados no provedor de internet. Solicita todas as contas vinculadas, pois uma pessoa costuma ter várias. Declara explicitamente a não divulgação e fornece um contato oficial para que o provedor possa verificar quem fez a solicitação.

Erros comuns incluem endereços incorretos ou truncados, horários locais sem fuso horário, nomes de blockchain ausentes e solicitações de “todas as transações” que retornam um resumo em vez do livro-razão interno.

Portais, verificação e emergências

Muitos grandes provedores operam portais para autoridades policiais ou caixas de e-mail dedicadas e publicam orientações sobre o que precisam. Usar o canal publicado é mais rápido do que usar endereços gerais de suporte e cria um registro auditável. Os provedores verificam se a solicitação vem de uma autoridade legítima; criminosos já se passaram por policiais usando solicitações de emergência falsificadas, portanto espere verificações e envie solicitações de contas oficiais.

A maioria dos provedores tem um procedimento de divulgação de emergência para risco iminente à vida ou danos graves, e o Segundo Protocolo Adicional acrescenta ordens diretas para dados de assinantes e um canal de emergência entre Estados onde se aplica. Na maioria dos outros casos, é necessária uma ordem ou solicitação formal antes da entrega dos registros.

Não divulgação e alerta ao investigado

Alguns provedores notificam os clientes sobre solicitações de autoridades policiais, salvo quando isso é proibido, e uma conta congelada informa ao titular que algo aconteceu. Solicite a não divulgação em todas as solicitações, cite qualquer base legal para isso e peça ao provedor que informe se não puder cumprir. Programe os congelamentos e as solicitações de modo que não alertem uma pessoa investigada antes da apreensão de dispositivos ou da preservação de outras contas. Os provedores têm seus próprios deveres de não alertar clientes sobre os relatórios que apresentam, abordados na aula IDFE-CC Obrigações de comunicação de transações suspeitas.

Analisando a resposta criticamente

A resposta de um provedor é uma fonte a ser verificada, não uma conclusão.

• Autentique-a. Registre como ela chegou, calcule o hash de cada arquivo no recebimento e guarde qualquer certificado ou declaração do custodiante dos registros do provedor. A aula Contas de exchange e de nuvem como evidências aborda a autenticação em profundidade.
• Verifique os fusos horários e as unidades. As exportações misturam horário local e UTC, e os valores podem estar arredondados ou ser apresentados líquidos de taxas.
• Verifique se está completa. Compare a quantidade de linhas e os intervalos de datas com o que foi solicitado; anote o que falta e peça os dados.
• Trate a identidade como uma alegação. Os dados de KYC podem pertencer a um intermediário financeiro, a uma identidade roubada ou a uma conta comprada. Um endereço IP pode pertencer a uma VPN ou a um nó de saída do Tor.
• Concilie com a blockchain. Cada depósito e saque on-chain na resposta deve corresponder a uma transação real.

-- Saques do provedor sem transferência on-chain correspondente
SELECT w.withdrawal_id, w.txid, w.to_address, w.amount, w.completed_utc
FROM provider_withdrawals AS w
LEFT JOIN chain_transfers AS c
  ON  c.txid = w.txid
  AND c.to_address = w.to_address
  AND c.amount = w.amount
WHERE c.txid IS NULL;   -- linhas sem correspondência precisam de explicação

A consulta associa os saques listados pelo provedor às transferências decodificadas a partir dos dados do próprio nó do examinador, usando o txid, o destino e o valor. As linhas sem correspondência precisam de uma explicação. Motivos comuns são transferências internas para outro cliente, que não têm txid, valores registrados antes da dedução da taxa da rede ou um saque em uma blockchain diferente daquela consultada. Os valores devem estar nas mesmas unidades em ambos os lados; alguns mecanismos precisam de um tipo decimal explícito ou de uma pequena tolerância para que essa comparação funcione. Uma divergência sem explicação é, por si só, uma constatação e deve ser apresentada ao provedor.

Uma resposta analisada na prática

A Exchange K responde à ordem de produção do caso CF-2026-0147 três semanas depois. O examinador compara a resposta com as perguntas descritas no escopo.

1. KYC. A conta foi aberta oito dias antes do primeiro pagamento de uma vítima por um estudante de 20 anos que mora em outro país. A identidade pode ser verdadeira e, ainda assim, não pertencer à pessoa que está conduzindo o golpe: o perfil é compatível com um intermediário financeiro recrutado. Registrado como “titular cadastrado da conta”, não como “suspeito”.
2. Registros de IP. O cadastro foi feito a partir de um endereço residencial no país do titular; quase todos os logins posteriores vieram de endereços em uma faixa de hospedagem comercial. Isso sugere uma VPN ou um operador remoto e representa uma nova pista para uma solicitação à empresa de hospedagem.
3. Livro-razão. Os 9.800 USDT foram congelados após a solicitação de preservação, mas 31.200 USDT de pagamentos anteriores saíram em quatro saques. Três correspondem a transferências on-chain para novos endereços; o quarto foi uma transferência interna para outra conta da Exchange K, invisível on-chain.
4. Próximas etapas. O plano inclui uma segunda solicitação para a conta recebedora, um novo rastreamento a partir dos três endereços de saque e uma solicitação ao provedor de hospedagem.

A resposta esclareceu uma questão e abriu três. Isso é normal, e o arquivo do caso deve mostrar cada nova pista e de onde ela veio.

Foco no exame: quais registros exchanges, custodiantes, emissores de stablecoin, provedores de hospedagem, telecomunicações e outros provedores podem armazenar, e quais são suas limitações; preservar primeiro e confirmar a expiração da preservação; solicitações voluntárias de congelamento separadas; as três partes de uma solicitação precisa (identificadores com blockchain e horários, período em UTC, campos específicos); portais para autoridades policiais, verificação de quem solicita e procedimentos de emergência; solicitar a não divulgação e evitar alertar a pessoa investigada; autenticar respostas, verificar fusos horários e integridade, tratar dados de KYC e IP como alegações; conciliar registros dos provedores com dados on-chain; transformar uma resposta em novas pistas.