Publicar sua taxa de falso positivo: o diferencial que quase ninguém tem

Em detecção de fraude, todo mundo publica o número que fica bem. “Pegamos 98% das adulterações.” Ótimo. Agora me diz de quantos documentos legítimos você desconfiou para conseguir isso, e aí sim começamos a conversar.

Recall — a fração de fraudes que você pega — é a parte fácil de medir e a parte fácil de inflar. Você aperta os limiares, dispara mais sinais, pega mais fraude e o número sobe. O que sobe junto, e ninguém mostra no slide, é a taxa de falso positivo: a fração de documentos honestos que você acusou. Vim de KYC/AML, e o falso positivo é onde a compliance de verdade sangra — cada legítimo marcado como suspeito é um cliente parado numa fila, um analista queimando hora, uma conta que não abre. Um detector que grita em tudo não é seguro; é caro e inútil, e treina a equipe a ignorá-lo.

Este post é sobre a disciplina que quase ninguém pratica: medir o falso positivo em populações separadas de documentos que você sabe que são legítimos, e publicar o resultado mesmo quando ele é feio. Vou usar números reais do Tamperlens, inclusive os que não me favorecem, porque são exatamente esses que provam o método.

O padrão que a maioria não cumpre — e o teste que mostra isso

Comecemos pelo tamanho do problema, com números que não são meus. Em 2025 o NIST publicou a SP 800-63A-4; o §3.13 exige que um sistema de validação de documento tenha uma Document False Accept Rate (DFAR) de 0,1 ou melhor — no máximo um documento fraudulento aceito a cada dez.

No mesmo ano, o DHS (a segurança interna dos EUA) rodou o Remote Identity Validation Rally (RIVR), testando sete sistemas comerciais de validação contra documentos genuínos e fraudados. A DFAR medida variou de menos de 0,88% a menos de 76,68%. Dois dos sete sistemas aceitaram cerca de sete em cada dez documentos forjados — 69,20% e 76,68%, algo como setecentas vezes o limite do padrão federal do mesmo ano.

Um avaliador neutro do governo, não um fornecedor, mostrando que “já temos verificação de documento” não é um controle resolvido. (Uma ressalva que sempre viaja com esse número: o RIVR testa documentos de identidade por captura de imagem, não extratos bancários em PDF por análise estrutural. Ele prova que a categoria de controle é não confiável; não diz nada sobre o nosso engine e os números não são nossos.)

Guarde a lição: se sistemas comerciais sérios erram assim, a única coisa que separa um produto honesto de mais um deles é ter medido o próprio erro e mostrado a conta.

A disciplina: a medição vem antes do código

No Tamperlens a regra é escrita antes da feature existir. Quando planejei a família que checa se a aritmética do próprio documento fecha (a soma das colunas bate com o total declarado? o saldo corrente é consistente? o holerite fecha?), o plano nomeou o número que decidiria se ela nasce: quantos documentos legítimos falham a checagem. Se o falso positivo em documentos reais de governo e banco passar de poucos por cento, as tolerâncias estão erradas ou a família não vai para produção.

Repare na inversão. O critério de aceite não é “a checagem pega fraude”. É “a checagem não acusa o legítimo”, medido antes de uma linha ser escrita, num número declarado no papel. Isso muda tudo, porque agora medir bem o falso positivo é a condição de existir — e um resultado ruim mata a feature em vez de virar uma nota de rodapé.

Rodei essa família contra um corpus de 3.842 PDFs — contratos de governo, PDFs de banco, documentos da web brasileira, mais os corpora de adulteração. Três checagens candidatas. O resultado decidiu cada uma:

• Soma de colunas contra total declarado. Disparou em 29 documentos publicados — documentos legítimos, de verdade. 29 falsos positivos é inaceitável para o valor que a checagem entrega. Não foi para produção. Medida, e engavetada.
• Saldo corrente. Falso positivo praticamente nulo nos extratos reais. Foi para produção, como running-balance-break, em severidade medium.
• Identidade do holerite. População de três documentos em 3.842. Amostra pequena demais para afirmar qualquer coisa. Não construída.

Uma de três embarcou, e o corpus é a razão. Não a intuição, não o que eu achava que funcionava — o que 3.842 documentos legítimos disseram sobre quantos deles cada checagem acusaria sem motivo.

Quando o falso positivo derruba um sinal que “parecia certo”

O caso mais instrutivo é o de um sinal que o próprio padrão PDF parece endossar. O trailer de um PDF tem um array /ID com dois elementos: por especificação, o /ID[0] é permanente, atribuído na criação, e o /ID[1] muda a cada save. Logo, os dois diferindo deveria significar “alterado desde a criação”. Um sinal de adulteração de graça, direto da spec.

Aí você mede. Contra 1.728 documentos que ninguém curou — uma amostra aleatória de PDFs .gov e uma amostra aleatória da web brasileira — o /ID divergente disparou em 44,7% e 36,7% deles. E, o mais revelador: 83,4% e 88,6% desses arquivos tinham uma única revisão. Um arquivo escrito uma vez só não pode ter sido “salvo de novo depois de criado”. A conclusão inescapável é que uma montanha de geradores de PDF simplesmente produz os dois elementos do zero na primeira gravação, ignorando a spec. O que a especificação diz e o que os escritores fazem são coisas diferentes.

O que fazer com um sinal desses? A resposta preguiçosa é mantê-lo em medium e conviver com ~40% de falso positivo. A resposta covarde é apagá-lo. A resposta honesta é a que adotamos: o /ID divergente só reporta medium quando a própria estrutura do arquivo concorda que ele foi escrito mais de uma vez. Quando não concorda, a observação é mantida — continua sendo um fato real sobre o trailer, e esconder fato é como uma ferramenta forense vira inauditável — mas emitida em info, que pontua zero e fica de fora da contagem de sinais. O fato sobrevive; o peso, não.

Populações separadas, e por que isso importa

Repare que eu não disse “medi o falso positivo”. Disse “em populações separadas”: contratos do PNCP, PDFs de banco, PDFs .gov americanos, web brasileira. Isso não é firula estatística. Um gerador de PDF domina um mercado (o Word domina o governo brasileiro; o iText domina banco). Se você mede o falso positivo num pote só, o viés do gerador dominante te dá um número que despenca no primeiro cliente cujo fornecedor de software é diferente. Medir por população é o que revela que um sinal é robusto ou só sortudo com o Word.

E há um limite honesto que a estatística impõe. Quando validei a família que lê identificadores brasileiros (CNPJ, e afins que carregam dígito verificador), o resultado foi zero falso positivo sobre 156 números reais, de contratos do PNCP (53), PDFs da web brasileira (16) e dos corpora de adulteração (34). “Zero” soa perfeito, mas 156 é uma amostra finita: pela regra de três, zero erros em 156 casos limita o falso positivo em torno de 1,9% com 95% de confiança. A estimativa pontual é nada; o teto honesto que posso afirmar é ~1,9%. Dizer “zero por cento” seria mentir sobre o que a amostra suporta. Um número sem denominador não é uma medição — é uma alegação.

Por que publicar o feio é o diferencial

Volto ao PNCP, que já contei em outro post pela ótica da estrutura, agora pela ótica da medição. Rodamos o engine sobre 1.317 contratos públicos e 77% dos assinados pontuam high — por causa da contra-assinatura, não de fraude. Esse é um falso positivo do nosso produto, no documento legítimo mais comum daquele mercado. E está escrito na nossa própria página de evidências.

Pense em quantos fornecedores de “verificação de documento” publicam o cenário em que a própria ferramenta erra feio. A resposta é: quase nenhum, porque o incentivo comercial é o contrário. Mas é exatamente por isso que publicar é o diferencial. Quem compra um controle de risco está comprando calibração, não otimismo. Um fornecedor que te diz onde a ferramenta é ruidosa te deu a informação de que você precisa para operá-la; um que só te mostra o recall te vendeu um número e escondeu a conta.

A assimetria vale a pena repetir para quem trabalha com compliance e KYC: o custo de um falso negativo é uma fraude que passou — real, doloroso, mas raro e, em geral, coberto por outras camadas. O custo de um falso positivo é estrutural: multiplica pelo volume inteiro de documentos legítimos, todo dia, e é onde a operação inteira trava. É por isso que a taxa de falso positivo é o número que decide se um detector é utilizável, e é por isso que não publicá-la é a maior bandeira vermelha que um fornecedor pode hastear sem perceber.

O que levar disto

Se você avalia uma ferramenta de detecção — de fraude documental, de identidade, de qualquer coisa — a pergunta não é “quanto você pega?”. É:

1. Qual é a sua taxa de falso positivo, e sobre qual população? Sem denominador, o número é propaganda.
2. Você mediu em populações separadas ou num pote só onde o gerador dominante te salvou?
3. A medição veio antes ou depois de decidir embarcar a feature? Medição que só serve para confirmar uma decisão já tomada não é medição.
4. Você me mostra um caso em que a ferramenta erra feio? Se não mostra, ou não mediu, ou está escondendo.

Medir recall é a parte fácil. Medir, publicar e agir sobre o falso positivo — matar uma feature de 29 falsos positivos, rebaixar um sinal de 40%, admitir um teto de 1,9% em vez de cantar “zero” — é a disciplina inteira. É o trabalho chato que não cabe no slide. E é a única coisa que separa um controle de risco de um teatro de segurança.