Uma operação autenticada não é, por si só, uma operação atribuída inequivocamente ao titular. Em disputas bancárias digitais, a força da prova depende da reconstrução do evento: identidade, dispositivo, autenticador, sessão, autorização, transação, controles de risco e integridade dos registros.
Em uma frase A pergunta pericial mais útil não é apenas “a transação foi autenticada?”, mas o que exatamente foi autenticado, por qual mecanismo, em qual contexto e até onde os registros permitem atribuir a operação a uma pessoa específica. |
|---|
Resumo executivo
Autenticação, autorização e autoria são proposições diferentes.
Um sistema pode registrar corretamente o uso de uma credencial sem demonstrar, sozinho, quem estava operando o dispositivo.
Um indicador isolado raramente resolve a controvérsia.
IP, biometria, token, dispositivo cadastrado e score antifraude ganham força quando são correlacionados temporal e logicamente.
A preservação e a reprodutibilidade importam tanto quanto o conteúdo dos logs.
A origem, a extração, os filtros, as transformações e a integridade da evidência precisam ser documentados.
O trabalho técnico ideal começa antes do laudo.
Delimitar o objeto, identificar registros relevantes e formular quesitos capazes de distinguir hipóteses concorrentes pode alterar a qualidade da prova produzida.
Palavras-chave: fraude bancária; autenticação; Pix; logs; perícia digital; evidência digital; assistência técnica.
1. A pergunta certa não é “a transação foi autenticada?”
Em uma controvérsia bancária digital, a resposta “sim, a operação foi autenticada” pode esconder eventos tecnicamente distintos. Uma senha pode ter sido aceita; um token pode ter sido validado; uma sessão anteriormente autenticada pode ter permanecido ativa; um dispositivo já cadastrado pode ter originado a chamada; uma biometria local pode ter liberado uma chave criptográfica; ou um fluxo de recuperação de conta pode ter permitido novo acesso.
Esses eventos não têm o mesmo significado probatório. As Digital Identity Guidelines do NIST separam prova de identidade, autenticação, autenticadores, gerenciamento de credenciais e níveis de garantia.[1][2] A distinção é central para a perícia: registrar que um autenticador foi aceito não equivale, automaticamente, a identificar a pessoa que praticou o ato.
Erro comum “Credencial válida + operação concluída = operação realizada pelo titular.” Esse raciocínio é circular. A perícia deve demonstrar como a credencial foi vinculada à conta, em que condições foi utilizada, se houve recuperação ou migração, qual dispositivo participou e se a cadeia de eventos é coerente com as hipóteses discutidas no processo. |
|---|
2. A prova deve reconstruir uma sequência de eventos
Uma transação contestada pode ser analisada como uma cadeia de sete camadas. A utilidade dessa estrutura está em impedir que um único registro seja tratado como explicação completa do evento.
1. Identidade e cadastro | → | 2. Dispositivo | → | 3. Autenticação |
|---|---|---|---|---|
4. Sessão | → | 5. Autorização / transação | → | 6. Controles de risco |
7. Resposta pós-evento, contestação e preservação da evidência |
Camada | Questão técnica principal |
|---|---|
Identidade e cadastro | Como a conta foi criada? Quais dados e verificações vincularam a identidade à conta? |
Dispositivo | Qual equipamento, aplicativo, versão, sistema operacional e identificadores participaram? |
Autenticação | Quais fatores foram exigidos e aceitos? Houve fallback, recuperação ou migração de credencial? |
Sessão | Quando começou, quanto durou e quais eventos ocorreram durante sua vigência? |
Transação | Qual valor, beneficiário, canal, horário, identificadores internos e mecanismo de confirmação? |
Risco | Houve novo favorecido, mudança de padrão, alteração de limite, dispositivo incomum ou alerta antifraude? |
Pós-evento | Quando houve contestação, bloqueio, MED, atendimento e preservação dos registros? |
No ecossistema Pix, o Banco Central mantém mecanismos específicos de segurança, cadastramento de dispositivos e resposta a fraude. A Instrução Normativa BCB nº 491/2024, em sua versão vigente atualizada em 2025, disciplina o cadastramento de dispositivos para iniciação de transações Pix e limita operações em dispositivo não cadastrado.[3] Esses controles são importantes para o contexto, mas não substituem a reconstrução pericial do caso concreto.
3. O que cada evidência pode — e não pode — demonstrar
Elemento | O que pode apoiar | O que não demonstra sozinho |
|---|---|---|
Senha / PIN | Uso de um segredo aceito pelo sistema. | Quem conhecia ou inseriu o segredo. |
Token / OTP | Uso de um fator válido no fluxo de autenticação. | Controle humano exclusivo do fator no instante do evento. |
Biometria | Resultado de um processo biométrico ou de desbloqueio, conforme a arquitetura. | Identidade civil absoluta, intenção ou ausência de coerção/comprometimento. |
Dispositivo cadastrado | Vínculo técnico prévio entre um dispositivo e a conta. | Quem estava fisicamente com o equipamento durante a operação. |
Endereço IP | Contexto de rede, especialmente quando acompanhado de porta e timestamp preciso. | Identidade civil de quem operou o terminal. |
Geolocalização | Localização estimada ou medida, conforme a fonte. | Necessariamente a localização da pessoa discutida no processo. |
Score antifraude | Resultado de uma avaliação operacional de risco. | Autoria da transação ou inexistência de fraude. |
Log de sessão | Sequência de eventos registrados pelo sistema. | Conclusão confiável se origem, integridade e contexto não forem demonstrados. |
Ponto central A evidência digital costuma ser mais forte por convergência do que por isolamento. IP + porta + timestamp + sessão + dispositivo + evento de autenticação + identificador transacional formam um quadro muito mais informativo do que qualquer desses elementos sozinho. |
|---|
4. Quais registros normalmente importam
A lista depende da arquitetura e do objeto da controvérsia. Em uma análise tecnicamente madura, podem ser relevantes:
identificador único da transação e timestamps com fuso e precisão;
logs de login, autenticação e encerramento de sessão;
cadastro, troca ou exclusão de dispositivos;
redefinição de senha, PIN ou credenciais;
ativação, migração ou recuperação de token;
versão do aplicativo, sistema operacional e identificadores técnicos disponíveis;
IP, porta de origem quando disponível e contexto de rede;
alterações de limite, inclusão de novo favorecido e mudanças relevantes na conta;
alertas, scores e decisões dos mecanismos antifraude;
notificações push, SMS e e-mails associados ao evento;
fluxos de recuperação de conta;
trilhas de auditoria do backend;
atendimento, contestação e medidas tomadas após a comunicação da fraude;
metadados de extração, preservação e exportação da evidência.
Aplicação prática para o jurídico Antes de pedir “os logs”, vale especificar quais eventos precisam ser reconstruídos. Pedidos genéricos podem gerar grandes volumes de dados sem responder à questão pericial. O objetivo é ligar cada registro a uma hipótese: cadastro, comprometimento, recuperação de conta, criação de sessão, autorização, alteração de perfil, transação e resposta pós-evento. |
|---|
5. Autenticação forte melhora a evidência — mas não elimina a inferência
O NIST SP 800-63B-4, publicado em 2025, atualiza requisitos sobre autenticadores, níveis de garantia e resistência a ameaças modernas.[2] Em agosto de 2026, o W3C publicou o WebAuthn Level 3 como Recommendation, consolidando o uso de credenciais de chave pública vinculadas a autenticadores e a um relying party específico.[4]
Esses mecanismos elevam a segurança e a qualidade do registro técnico, mas a interpretação continua exigindo cuidado. Uma prova criptográfica pode demonstrar que determinada credencial participou de um protocolo. A atribuição humana do ato depende de contexto adicional: posse do dispositivo, método de desbloqueio, eventual comprometimento, coerção, engenharia social, recuperação da conta e gestão das credenciais.
Por isso, duas perguntas devem permanecer separadas:
o sistema autenticou corretamente uma credencial?
o conjunto probatório permite atribuir o ato à pessoa discutida no processo, com qual grau de suporte?
6. Biometria: evidência relevante, mas não “identidade absoluta”
Sistemas biométricos operam por comparação e possuem métricas de desempenho, incluindo falsa aceitação e falsa rejeição. A arquitetura também importa. Em muitos dispositivos, o aplicativo bancário não recebe a imagem biométrica; o sistema operacional apenas sinaliza que uma verificação local foi bem-sucedida e libera uma chave ou operação protegida.
Perguntas tecnicamente úteis
qual modalidade biométrica foi utilizada?
a verificação ocorreu localmente ou em servidor?
qual componente armazenava o template?
o aplicativo recebeu dados biométricos ou apenas uma confirmação do sistema operacional?
havia fallback por PIN ou senha?
houve recadastramento biométrico ou de dispositivo próximo ao evento?
havia mecanismo de
liveness
ou proteção contra apresentação, quando pertinente?
7. IP e geolocalização: contexto técnico, não identidade civil
Outro salto indevido é tratar o endereço IP como identificação direta de uma pessoa. Em redes com NAT e Carrier-Grade NAT, vários assinantes podem compartilhar um mesmo IPv4 público. A atribuição de uma conexão pode exigir IP, porta de origem, timestamp preciso e registros correlatos do provedor.[5][6]
Mesmo quando a conexão é corretamente associada a determinado assinante, isso demonstra uma relação de acesso à rede, não necessariamente quem operava o terminal. Redes compartilhadas, Wi-Fi doméstico ou corporativo, VPNs, dispositivos comprometidos e outros cenários precisam ser considerados.
Geolocalização também depende da fonte: GPS, rede celular, Wi-Fi e estimativa baseada em IP têm graus de precisão e características diferentes. A conclusão deve expressar o que o dado mede, não aquilo que seria conveniente inferir.
8. Antifraude é um controle operacional — não um atestado de autoria
Sistemas antifraude modernos combinam sinais como dispositivo conhecido, horário, geografia, velocidade de transações, novo favorecido, alteração de limite, reputação do dispositivo e comportamento da sessão. Em litígio, pode ser relevante saber quais sinais estavam disponíveis, quais regras foram acionadas, qual categoria de risco foi produzida e se a decisão ficou registrada de forma auditável.
Limite probatório “O sistema classificou a transação como baixo risco” não significa “a transação foi realizada pelo titular”. O primeiro enunciado descreve uma decisão do mecanismo de risco. O segundo é uma conclusão sobre autoria — e exige suporte adicional. |
|---|
9. Integridade, cadeia de custódia e reprodutibilidade
Uma trilha tecnicamente rica pode perder valor se sua origem e integridade não forem demonstradas. A ISO/IEC 27037 fornece diretrizes para identificação, coleta, aquisição e preservação de evidência digital.[7] O NIST SP 800-86 organiza atividades forenses em coleta, exame, análise e relato.[8] A ISO/IEC 27042 trata especificamente de análise e interpretação e reforça continuidade, validade, reprodutibilidade, repetibilidade e documentação suficiente para escrutínio independente.[9]
No Brasil, o STJ já destacou, em caso envolvendo prova digital extraída de celular, a necessidade de metodologia adequada, documentação das etapas e garantias de integridade; embora o precedente tenha contexto processual penal específico, ele ilustra um princípio técnico relevante: prova digital sem documentação adequada de obtenção e tratamento perde confiabilidade.[10]
Uma análise deveria registrar, sempre que possível:
sistema de origem e período coberto;
procedimento e responsável pela extração;
filtros, consultas e critérios utilizados;
formato original e formato entregue;
hashes ou outros mecanismos de verificação;
data e hora da aquisição;
transformações, normalizações e ferramentas empregadas;
versões das ferramentas relevantes;
retenção dos dados originais;
possibilidade de reprodução do resultado.
Regra de ouro Uma conclusão robusta deve poder ser rastreada de volta ao dado de origem, ao método utilizado e às transformações aplicadas. Se esse caminho não puder ser explicado, a conclusão pode até parecer plausível — mas será tecnicamente mais difícil de auditar. |
|---|
10. Como formular melhor o objeto pericial
“Houve fraude?” é uma pergunta ruim para a perícia quando mistura intenção, responsabilidade jurídica e análise técnica. Perguntas mais discriminativas ajudam o perito a separar hipóteses concorrentes:
quais mecanismos de autenticação foram utilizados na transação contestada?
quais eventos de alteração de credenciais ou dispositivos ocorreram no período anterior?
quais registros identificam a sessão e o dispositivo associados à operação?
os timestamps das diferentes fontes são consistentes?
houve inclusão de novo favorecido, alteração de limite ou mudança relevante de perfil?
quais alertas ou sinais de risco foram registrados?
os dados permitem correlação entre cadastro, sessão, autenticação, autorização e transação?
qual foi o método de preservação e extração dos registros?
quais conclusões são suportadas tecnicamente e quais permanecem indeterminadas?
Aplicação pericial O objetivo dos quesitos não é induzir uma resposta. É transformar a controvérsia em perguntas tecnicamente testáveis: quais hipóteses existem, quais registros discriminam essas hipóteses e quais limitações impedem uma conclusão mais forte. |
|---|
Conclusão
Fraude bancária digital não é adequadamente explicada por um único indicador. Senha correta, biometria aceita, token válido, IP conhecido, dispositivo cadastrado ou score antifraude são peças de uma reconstrução — não conclusões autossuficientes.
A força probatória surge da correlação entre fontes independentes, da coerência temporal, da compreensão da arquitetura de autenticação e autorização e do tratamento forense dos registros. Para o jurídico, isso significa que o trabalho técnico ideal começa antes do laudo: na delimitação do objeto, na preservação da evidência, na identificação dos registros necessários e na formulação das perguntas capazes de distinguir hipóteses concorrentes.
Ideia para levar do artigo Em controvérsias digitais, a questão decisiva costuma ser menos “há um log?” e mais: o que exatamente esse log mede, como foi produzido, com quais outros registros ele se correlaciona e até onde sua interpretação pode ir? |
|---|
Referências
NIST.
SP 800-63-4: Digital Identity Guidelines
. 2025.
NIST.
SP 800-63B-4: Digital Identity Guidelines: Authentication and Authenticator Management
. 2025.
Banco Central do Brasil.
Instrução Normativa BCB nº 491/2024
, versão vigente atualizada em 2025.
W3C.
Web Authentication: An API for accessing Public Key Credentials — Level 3
. W3C Recommendation, 25 Aug. 2026.
IETF.
RFC 6888: Common Requirements for Carrier-Grade NATs
. 2013.
IETF.
RFC 6302: Logging Recommendations for Internet-Facing Servers
. 2011.
ISO/IEC.
ISO/IEC 27037:2012 — Guidelines for identification, collection, acquisition and preservation of digital evidence
.
NIST.
SP 800-86: Guide to Integrating Forensic Techniques into Incident Response
. 2006.
ISO/IEC.
ISO/IEC 27042:2015 — Guidelines for the analysis and interpretation of digital evidence
.
Superior Tribunal de Justiça.
Provas digitais devem ser colhidas com metodologia adequada
. 2 maio 2024.
Banco Central do Brasil.
Segurança no Pix
.
Banco Central do Brasil.
Mecanismo Especial de Devolução (MED)
.
Nota editorial. Conteúdo técnico-informativo. A aplicação a um caso concreto exige exame dos autos, da arquitetura do sistema, dos registros originais e do objeto pericial efetivamente delimitado.