Blocklist interna: quando bloquear um documento e por quanto tempo

Toda operação que sofreu fraude cria, cedo ou tarde, uma lista interna de bloqueio. Alguém anota o CPF que usou documento adulterado, o sistema passa a barrar aquela tentativa e o custo por checagem é praticamente zero: uma consulta a uma tabela própria, sem chamar ninguém de fora. É o antifraude mais barato que existe, e por isso mesmo o mais fácil de envenenar.

O envenenamento acontece por acúmulo: uma entrada colocada numa madrugada de incidente, outra derivada de uma reclamação de cliente irritado, outra de uma reprovação isolada que ninguém investigou. Dois anos depois a lista tem milhares de linhas sem justificativa registrada, e ninguém remove nada porque ninguém sabe o que cada linha significa. Deixou de ser controle e virou dívida.

Este texto trata do que separa uma lista útil de um depósito de suspeitas: critério de entrada, prazo de saída, como guardar o identificador sem criar um repositório de CPF em claro, os deveres legais de quem bloqueia por sistema e a diferença entre a sua lista e a do setor.

O que justifica uma entrada, e o que não justifica

O critério precisa ser escrito antes do primeiro caso, porque na urgência todo mundo inclui. A regra que se sustenta é simples: entra na lista o que foi confirmado, com evidência guardada.

Justifica entrada:

• Fraude comprovada com prejuízo apurado, como documento adulterado identificado em análise ou uso de identidade de terceiro com registro do fato.
• Confissão, decisão judicial ou determinação de autoridade competente.
• Padrão confirmado depois de investigação, como uma série de cadastros ligados ao mesmo esquema, com o vínculo documentado.

Não justifica entrada:

• Suspeita do analista sem apuração concluída.
• Reprovação isolada de uma verificação, que na maior parte das vezes é foto ruim, luz ruim ou documento gasto, e não fraude.
• Reclamação de cliente ou disputa comercial, que é assunto de atendimento e não de antifraude.
• Score alto de risco, que é sinal para investigar e não conclusão sobre a pessoa.

A distinção importa porque os dois tipos de entrada se parecem no banco de dados e são radicalmente diferentes na consequência. Uma delas barra um fraudador; a outra barra para sempre um cliente que só tinha uma câmera velha, e a diferença entre esses dois casos é exatamente o assunto do falso positivo em verificação. Confundir suspeita com confirmação é o erro que também alimenta a fila de vítimas de fraude com CPF de terceiro: quem teve o documento usado por um golpista é a parte lesada, e mandá-la para a blocklist pune duas vezes a mesma pessoa.

Entrada sem evidência vira dívida invisível

Uma entrada precisa carregar, no mínimo, quatro coisas: o motivo em texto legível, a referência à evidência (o caso, o chamado, o processo), quem incluiu e quando. Sem isso, a linha é irreversível na prática. Ninguém remove o que não entende, e o volume só cresce.

O sintoma clássico aparece na análise de conversão, meses depois: uma fatia de cadastros bloqueada por uma tabela que ninguém audita, com falsos positivos que nunca voltam para reclamar porque simplesmente foram embora. Como o custo é invisível, a lista nunca é revista.

Duas práticas cortam a espiral pela raiz. A primeira é tornar a evidência obrigatória no momento da inclusão, no formulário e no esquema do banco, de modo que não exista caminho para criar uma entrada órfã. A segunda é a trilha de auditoria da própria lista: cada inclusão, alteração e remoção registrada de forma imutável, com autor e horário. Auditar quem bloqueou importa tanto quanto auditar quem aprovou, porque uma lista interna também é alvo de abuso interno.

Prazo e revisão: bloqueio eterno é pena perpétua

Nenhuma entrada deveria nascer sem prazo. Bloqueio permanente decidido por uma tabela é pena perpétua, e há um argumento prático além do moral: a informação envelhece. Um documento envolvido em fraude há seis anos diz pouco sobre quem tenta se cadastrar hoje.

Um desenho razoável tem três elementos. Prazo por tipo de caso, mais longo para fraude grave e mais curto para casos limítrofes, definido pela política de risco e não pelo analista da vez. Revisão periódica agendada, na qual entradas vencidas expiram sozinhas e as que permanecem exigem confirmação explícita. E um caminho de contestação com prazo de resposta, porque bloqueio errado sem canal de saída é o pior atendimento possível. Sair da lista precisa ser tão operacional quanto entrar: se remover exige três aprovações e uma reunião, ninguém remove.

Guardar o identificador sem criar um repositório de CPF

A lista precisa comparar documentos, não exibir documentos. Guardar CPF em claro numa tabela consultada por todo o sistema cria um repositório de dado pessoal atraente, quando o que a função exige é apenas responder "este documento está na lista?".

O reflexo comum é guardar o hash do CPF, e ele é insuficiente sozinho. O espaço de CPFs válidos é pequeno o bastante para ser percorrido inteiro: quem obtiver a tabela pode calcular o hash de todos os números possíveis e recuperar a lista completa, e a conta é banal: cerca de um bilhão de combinações válidas, que hardware comum percorre inteiro em pouco tempo. Hash sozinho, num domínio tão pequeno, não esconde nada. Salgar por linha resolve o vazamento em lote, mas quebra a comparação, porque cada valor teria um sal diferente.

O caminho usual é o hash com pimenta, no sentido que o OWASP Password Storage Cheat Sheet dá ao termo: um segredo único da aplicação, guardado fora do banco, em cofre de segredos ou módulo de hardware, combinado ao documento antes do hash. A tabela continua comparável, já que todas as linhas usam o mesmo segredo, e quem obtiver apenas o banco não consegue enumerar nada sem também obter a pimenta. A rotação precisa ser planejada desde o início, e aqui está a armadilha: se a tabela guarda só o hash, o documento em claro não existe mais e não há o que recalcular. Ou se aceita uma transição, conferindo contra a pimenta velha e contra a nova durante uma janela e re-derivando cada linha na próxima vez que aquele documento aparecer, ou se guarda o identificador cifrado de forma reversível, com a chave no cofre, em vez de resumido.

A sua lista, a lista do setor e o que a lei cobra

Lista própria e lista compartilhada são coisas diferentes em natureza e em regime jurídico. A sua lista reflete a sua experiência: você viu o caso, guardou a evidência e responde por ela. A lista compartilhada entre instituições envolve receber e enviar informação sobre pessoas que nunca tentaram se cadastrar com você, e no sistema financeiro brasileiro esse compartilhamento tem regra própria, a Resolução Conjunta CMN/BCB nº 6, de 23 de fevereiro de 2023, que trata do compartilhamento de dados e informações sobre indícios de fraude entre instituições autorizadas a funcionar pelo Banco Central, com requisitos que valem ler antes de aderir a qualquer arranjo, como detalha a análise da Resolução Conjunta nº 6.

Dos dois lados, a Lei 13.709/2018, a LGPD, impõe deveres concretos. É preciso ter base legal para o tratamento, e a prevenção à fraude costuma ser sustentada pelo legítimo interesse do artigo 7º, inciso IX, ou pelo cumprimento de obrigação legal ou regulatória do inciso II do mesmo artigo, com a avaliação registrada por escrito. Os princípios do artigo 6º cobram necessidade e qualidade do dado, o que em bom português significa não guardar mais do que a função exige e manter a informação exata e atualizada, exigência que uma lista sem revisão viola por definição. O artigo 18 assegura ao titular a confirmação do tratamento, o acesso e a correção, e a eliminação prevista no inciso VI alcança o dado tratado com base no consentimento, não o que se conserva sob outra base: uma lista sustentada em legítimo interesse não se apaga a pedido nos termos daquele inciso. O artigo 20 lhe dá o direito de solicitar revisão de decisões tomadas unicamente por tratamento automatizado, tema desenvolvido em direitos do titular em KYC.

Há uma tensão real aqui: transparência total sobre os critérios entrega o mapa da fraude a quem quer contorná-lo. A saída praticada é responder ao titular sem detalhar o método, informando que houve restrição interna por análise de risco, oferecendo contestação e colocando uma pessoa, e não a mesma regra que bloqueou, para examinar o caso. Vale registrar que essa última parte é escolha de desenho, e não imposição do artigo 20: o parágrafo que obrigaria revisão por pessoa natural foi vetado, e o que a lei garante é a revisão, sem dizer por quem.

Fontes citadas

• Resolução Conjunta CMN/BCB nº 6, de 23 de fevereiro de 2023, sobre o compartilhamento de dados e informações sobre indícios de fraude entre instituições autorizadas a funcionar pelo Banco Central, citada por nome e número no texto.
• Lei 13.709/2018 (LGPD), artigos 6º, 18 e 20, citada por nome e número no texto.
• OWASP Password Storage Cheat Sheet, definição de pimenta como segredo da aplicação guardado fora do banco, citada por nome no texto.