O que preservar nas primeiras 24 h de uma fraude em cartões

Quando uma fraude em cartões é identificada, o relógio começa a correr contra a qualidade da prova. Não é a análise que fica mais difícil com o tempo — é a própria evidência que desaparece, porque a maior parte dos registros de um sistema de pagamentos foi desenhada para operação, não para retenção indefinida.

Este artigo é um guia didático sobre o que existe para preservar, onde essas informações normalmente residem e como uma preservação malfeita nas primeiras horas pode inviabilizar qualquer conclusão técnica posterior — seja para uma negociação comercial, um chargeback, uma apuração interna ou um processo judicial.

Por que as primeiras 24 horas são decisivas

Um sistema de pagamentos gera registros em várias camadas ao mesmo tempo: autorização, captura, liquidação, conciliação, antifraude e aplicação. Cada uma dessas camadas tem sua própria política de retenção, e nem todas são pensadas para durar semanas.

Logs de switch e de antifraude, por exemplo, costumam ter retenção mais curta do que os registros contábeis de liquidação, justamente porque seu volume é maior e seu propósito primário é operacional (decisão em tempo real), não histórico. Se ninguém aciona o congelamento forense logo depois de identificado o problema, é comum que justamente os registros mais detalhados — os que mostram o instante exato da decisão de autorizar ou negar uma transação — já tenham sido sobrescritos quando alguém for procurá-los.

Preservar nas primeiras 24 horas não significa concluir a análise nesse prazo. Significa apenas impedir que a matéria-prima da análise se perca antes de alguém ter a chance de examiná-la.

As fontes de evidência em uma transação com cartão

Para saber o que preservar, ajuda entender, de forma simples, por onde uma transação passa e o que cada etapa registra.

Autorização (mensagens no padrão ISO 8583)

A autorização é o momento em que se decide, em segundos, se uma transação será aprovada ou negada. Essa comunicação segue historicamente um padrão de mensagens conhecido como ISO 8583, usado entre estabelecimento, adquirente, bandeira/arranjo e emissor. Cada mensagem tem um MTI (Message Type Indicator, que identifica o tipo de mensagem — por exemplo, uma solicitação de autorização ou sua resposta) e uma série de campos de dados, entre eles:

• Código de processamento: indica o tipo de operação (por exemplo, compra, saque, estorno).
• STAN (System Trace Audit Number): um número sequencial que permite rastrear uma transação específica dentro do fluxo do sistema.
• RRN (Retrieval Reference Number): uma referência que acompanha a transação por várias etapas, útil para correlacionar autorização, captura e eventual chargeback.
• Data e hora de transmissão: o carimbo de tempo da mensagem, essencial para reconstruir a ordem dos eventos.
• Código de resposta: o resultado da autorização (aprovada, negada, e por qual motivo).

Esses campos, quando preservados, permitem reconstruir uma linha do tempo objetiva de cada transação — algo muito mais confiável do que um relato posterior de quem operou o sistema.

Captura, liquidação e conciliação

Depois de autorizada, a transação segue para captura (o fechamento da venda no estabelecimento), liquidação (o repasse financeiro entre as partes da cadeia) e conciliação (o cruzamento entre o que foi autorizado, capturado e efetivamente liquidado). Divergências entre essas três etapas costumam ser um dos primeiros sinais técnicos de que algo fugiu do padrão esperado, e por isso os relatórios de conciliação também são uma fonte relevante de evidência.

Advices de stand-in e logs de switch

Quando o emissor está indisponível, quem autoriza em seu nome segue parâmetros previamente configurados — esse mecanismo é chamado de stand-in processing. O que importa preservar aqui são os registros (advices) que informam ao emissor, posteriormente, quais decisões foram tomadas em seu nome enquanto ele estava fora do ar, além dos logs do próprio switch que processou essas mensagens.

Logs de antifraude e de aplicação

Motores de antifraude registram, para cada transação avaliada, os sinais considerados e o resultado da análise (aprovar, negar, pedir verificação adicional). Logs de aplicação — do site, do aplicativo, da API de pagamento — complementam esse quadro com informações de sessão, dispositivo e comportamento do usuário no momento da transação.

Como preservar sem comprometer a integridade

Preservar não é apenas copiar um arquivo para outro lugar. Sem alguns cuidados básicos, a cópia perde valor probatório.

Hash criptográfico e cadeia de custódia (ISO/IEC 27037)

A norma ISO/IEC 27037 descreve como identificar, coletar, adquirir e preservar evidência digital de forma que sua integridade possa ser comprovada depois. Na prática, isso envolve calcular um hash criptográfico (como SHA-256) no momento da coleta de cada arquivo de log ou extração de banco de dados, e documentar quem coletou, quando, de qual sistema e com qual ferramenta. Qualquer alteração posterior no arquivo, por menor que seja, muda o valor do hash — o que permite provar, matematicamente, que a cópia preservada é idêntica ao que foi coletado.

Sincronização de relógio (NTP) e fuso horário

Uma transação de pagamento pode atravessar vários sistemas — switch, antifraude, aplicação, banco de dados — cada um potencialmente com seu próprio relógio. Se esses relógios não estiverem sincronizados por um protocolo como o NTP (Network Time Protocol), a ordem dos eventos entre sistemas diferentes pode ficar distorcida. Ao preservar logs, é importante registrar também o fuso horário de cada fonte (muitas gravam em UTC, outras em horário local) para que a reconstrução da linha do tempo não misture referências diferentes por engano.

Isolar a cópia de trabalho do original preservado

Toda análise deve ser feita sobre uma cópia de trabalho, nunca sobre o artefato original preservado com hash. Isso garante que, se for necessário validar a integridade da evidência mais adiante — inclusive por uma contraparte técnica —, o original intacto ainda existe para conferência.

Quem guarda cada tipo de registro

Numa cadeia de pagamento, diferentes participantes guardam diferentes pedaços da história. O estabelecimento normalmente tem os logs de aplicação e, dependendo do arranjo, os registros de captura. O adquirente e o subcredenciador (quando existe um) costumam guardar logs de switch, roteamento e antifraude próprio. O emissor guarda os registros do lado da conta e do cartão, incluindo o histórico de decisões de autorização e os advices de stand-in recebidos. Nenhum participante isolado tem, normalmente, a visão completa — por isso a reconstrução de um incidente quase sempre exige solicitar e cruzar registros de mais de uma fonte.

Erros comuns nas primeiras 24 horas

• Esperar a conclusão da apuração interna para preservar: preservar e apurar são etapas diferentes. Esperar terminar a segunda para começar a primeira é o erro mais comum e o mais custoso, porque nesse intervalo os logs mais voláteis podem já ter expirado.
• Confiar apenas em relatórios administrativos: um extrato ou painel de gestão resume dados, mas normalmente não preserva os campos brutos de autorização (MTI, STAN, RRN, código de resposta) nem garante hash de integridade.
• Não anotar o fuso horário das fontes: comparar carimbos de tempo de sistemas diferentes sem saber se estão em UTC ou horário local é uma fonte frequente de erro na reconstrução da linha do tempo.
• Misturar a cópia de trabalho com o original: editar, filtrar ou reformatar o próprio arquivo preservado, em vez de trabalhar sobre uma cópia, compromete o hash e a cadeia de custódia.
• Não definir um responsável único pela preservação: quando várias pessoas acham que "alguém já deve ter salvo aquilo", frequentemente ninguém salvou.

Checklist das primeiras 24 horas

• Definir um responsável único pela preservação de evidências no incidente.
• Identificar todas as fontes envolvidas: switch, antifraude, aplicação, banco de dados de transações.
• Congelar (exportar com hash) os logs de autorização (ISO 8583) antes de qualquer rotação automática.
• Preservar os advices de stand-in processing, se houver indicação de indisponibilidade do emissor no período.
• Exportar relatórios de conciliação do período relevante, não apenas o dia do incidente.
• Registrar o fuso horário de cada fonte de log coletada.
• Calcular e documentar o hash criptográfico de cada arquivo ou extração no momento da coleta.
• Registrar quem coletou, quando, de qual sistema e com qual ferramenta (termo de cadeia de custódia).
• Copiar os artefatos originais para armazenamento seguro e trabalhar apenas sobre cópias.
• Comunicar as áreas jurídica e de compliance para avaliar prazos contratuais e regulatórios aplicáveis.

Perguntas frequentes sobre preservação de evidências em fraude de cartões