Antifraude com IA: como funciona um modelo próprio e quando faz sentido vs. fornecedor

Antifraude com IA é um problema de latência antes de ser um problema de modelo. A transação chega, o sistema tem uma fração de segundo para decidir se aprova, bloqueia ou manda para revisão, e essa decisão precisa ser explicável meses depois, quando o cliente contesta ou o regulador pergunta. Quem entende essa restrição desenha o sistema certo. Quem começa pela escolha do algoritmo desenha um sistema que não cabe no checkout.

Este texto abre a caixa: como um modelo antifraude decide em menos de 100 milissegundos, que dado ele precisa, quando faz sentido construir o seu em vez de contratar um fornecedor, e o que o regulador vai querer ver. No fim, o caso real que publicamos em pagamentos, com os números que já estão públicos e nenhum a mais.

Como um modelo antifraude decide em menos de 100 ms

O segredo é que quase nada é calculado na hora. Quando a transação chega, o sistema já tem pré-computado o que precisa saber sobre o cartão, o dispositivo, a conta e o estabelecimento. O que acontece em tempo real é montar um vetor de features a partir dessas leituras, passar por um modelo leve e aplicar a política de decisão. Cada etapa tem orçamento de tempo, e o orçamento total é o que o fluxo de pagamento tolera.

A arquitetura que funciona tem quatro estágios em sequência:

1. Enriquecimento. O sistema busca, em memória, os contadores e agregados já calculados: quantas transações esse cartão fez na última hora, quantos dispositivos essa conta usou nos últimos dias, qual o histórico do estabelecimento. Leitura em memória, sem consulta a banco relacional no caminho crítico.
2. Scoring. Um modelo de árvores de decisão (gradient boosting é o padrão) recebe o vetor e devolve uma probabilidade. Modelos desse tipo respondem em poucos milissegundos e são explicáveis por variável, o que importa no estágio quatro.
3. Política. A probabilidade vira decisão por meio de limiares que o negócio define: aprova abaixo de um valor, bloqueia acima de outro, manda para revisão no meio. Regras determinísticas (lista de bloqueio, limites por produto) entram aqui, não dentro do modelo.
4. Registro. Payload, features, versão do modelo, score e decisão são gravados de forma imutável e assinada. É o que permite reproduzir a decisão depois.

Modelos mais pesados, como redes de grafo para detectar conluio entre contas, não rodam no caminho crítico. Rodam em lote ou em janelas curtas e alimentam features que o modelo rápido consome. É assim que se combina profundidade analítica com resposta em tempo real sem estourar o orçamento de latência. Se você está avaliando esse desenho para a sua operação, uma consultoria de IA com experiência em pagamentos vai começar exatamente por esse orçamento, e não pela escolha de algoritmo.

Sinais, features e dado histórico necessário

Um modelo antifraude é tão bom quanto os sinais que recebe. Prevenção a fraude com inteligência artificial depende de quatro famílias de sinais que, combinadas, cobrem a maior parte dos padrões em pagamentos e serviços financeiros.

• Velocidade. Contagens e somas em janelas móveis: transações por cartão por minuto, valor acumulado por conta por hora, tentativas por dispositivo por dia. São as features mais baratas e mais poderosas.
• Dispositivo e comportamento. Fingerprint do aparelho, padrão de sessão, tempo entre telas, forma de digitação. Diferenciam o dono da conta de quem tem a senha do dono.
• Relacionamento. Quem transaciona com quem, quais contas compartilham dispositivo, endereço ou destinatário. É onde redes organizadas aparecem, e onde regras isoladas não enxergam.
• Contexto. Categoria do estabelecimento, horário, geografia, produto, canal. Sozinhos dizem pouco; combinados com os demais, mudam a probabilidade.

O dado histórico é a parte que ninguém gosta de discutir. Para treinar um modelo antifraude próprio, é preciso ter transações passadas com rótulo confiável: o que foi fraude confirmada, o que foi contestado e revertido, o que foi bloqueado por engano. Rótulo de fraude chega atrasado, às vezes meses depois, e é incompleto por natureza. Sem um processo de rotulagem que junte chargeback, contestação e revisão manual em uma base única, não há modelo próprio que se sustente.

A pergunta que fazemos antes de qualquer proposta é: quantos meses de histórico rotulado existem, e com que qualidade. A resposta define se o caminho é construir agora, construir depois de organizar o rótulo, ou usar um fornecedor enquanto a base amadurece. Pular essa pergunta é como o mercado produz modelos que parecem bons em validação e falham no primeiro mês.

Fornecedor ou modelo próprio: custo, controle e falsos positivos

A decisão de construir ou comprar antifraude com IA não é ideológica. É uma conta com três parcelas: o custo por transação, o controle sobre a decisão e o custo do falso positivo.

O fornecedor faz sentido quando o volume é baixo, o histórico rotulado não existe e a operação precisa de proteção agora. A maioria das empresas começa assim, e está certa em começar assim. O modelo próprio faz sentido quando o custo por transação do fornecedor já supera o custo de um time, quando o falso positivo virou problema de receita, ou quando regulação e propriedade do dado exigem controle sobre a decisão.

Falso positivo merece atenção especial. Um cliente legítimo bloqueado no checkout é venda perdida e, com frequência, cliente perdido. Fornecedores otimizam o limiar para a média dos clientes deles; o seu negócio não é a média. Ter o controle do limiar por segmento é, sozinho, um dos maiores ganhos de um modelo antifraude próprio, porque permite aceitar mais risco onde a margem compensa e menos onde não compensa.

Audit log e explicabilidade para o regulador

Bloquear uma transação por IA é uma decisão automatizada. A LGPD garante ao titular o direito de pedir revisão e de entender os critérios. O BACEN espera gestão de risco e continuidade sobre qualquer pipeline crítico de uma instituição financeira. O PCI DSS impõe controle sobre qualquer sistema que toque dado de cartão. Nenhum desses exige um algoritmo específico. Todos exigem que a instituição consiga responder, para qualquer decisão, o que entrou, o que saiu e por quê.

Na prática, isso define quatro requisitos que precisam estar na arquitetura desde o primeiro dia, e não em um relatório montado depois:

• Registro imutável de cada decisão, com payload, features, score, versão do modelo e política aplicada, assinado e retido pelo prazo regulatório.
• Explicação por decisão: quais variáveis mais contribuíram, em formato legível para o analista de contestação e para o titular.
• Reprodutibilidade: dado o registro, é possível reexecutar o modelo daquela versão e obter o mesmo resultado.
• Canal de contestação com fluxo de revisão humana e prazo, integrado ao sistema, não a uma caixa de e-mail.

Esses requisitos são o principal argumento técnico contra scoring opaco de terceiro em instituição regulada. Se o fornecedor não devolve a explicação por decisão, a instituição está assumindo o risco de não conseguir responder ao regulador sobre um bloqueio que ela mesma não entende. E esse risco não aparece na proposta comercial do fornecedor.

O caso real em pagamentos

Publicamos o caso completo em Antifraude com modelos próprios: caso real em pagamentos. Resumindo o que está lá: uma processadora de pagamentos com centenas de milhões de transações por mês dependia de um fornecedor externo de scoring, com latência alta, falsos positivos crescentes e nenhuma explicabilidade. O ponto de partida era chargeback em 0,38% do volume, falsos positivos em 12% e latência média de 220 ms.

O desenho seguiu o que este texto descreve: um classificador rápido para a grande maioria dos casos, um modelo de grafo para redes de mulas e um modelo de anomalia multivariada para comportamento atípico, com um agente que prepara o caso para o investigador humano. Noventa dias depois da entrada em produção, o chargeback estava em 0,12%, os falsos positivos em 5,5% e a latência média em 78 ms. O modelo próprio entrou em produção em 14 semanas.

A lição que tiramos do caso não está nos números. Está na última frase daquele texto: modelo próprio só vale a pena quando a equipe interna consegue mantê-lo. Foi nisso que o projeto investiu, e é por isso que ele continua rodando sem a gente.

Perguntas frequentes sobre antifraude com IA

Antifraude com IA funciona para PIX e transações em tempo real?

Funciona, desde que o sistema seja desenhado para o orçamento de latência do canal. PIX exige resposta em fração de segundo, o que impõe features pré-computadas em memória e modelo leve no caminho crítico. Modelos pesados rodam fora desse caminho e alimentam o modelo rápido.

Quanto dado histórico é preciso para treinar um modelo antifraude próprio?

Mais importante que a quantidade é a qualidade do rótulo: fraude confirmada, contestação e bloqueio indevido em uma base única. Sem isso, o modelo aprende o viés do processo anterior. Operações com meses de histórico bem rotulado têm base para começar; as que não têm devem organizar o rótulo antes de modelar.

É possível usar fornecedor e modelo próprio ao mesmo tempo?

É, e muitas vezes é o caminho de transição. O modelo próprio roda em sombra, recebendo as mesmas transações sem decidir, até que a comparação com o fornecedor mostre ganho consistente. Depois assume por segmento, e o fornecedor vira camada de segurança ou é desligado.

Como o regulador avalia um bloqueio feito por IA?

Ele quer saber se a instituição consegue explicar e reproduzir a decisão, se o titular tem canal de contestação e se há gestão de risco sobre o modelo, incluindo monitoramento e retreino. A resposta precisa vir do sistema, com registro por decisão, e não de um documento escrito depois.

Para ver como esse desenho se traduz em arquitetura, latência e requisitos de compliance para a sua operação, a página de IA para antifraude detalha o que fazemos em pagamentos, bancos e marketplaces.