Stripe Radar: a rede neural anti-fraude que decide em menos de 100 ms e bloqueia erroneamente apenas 0,1% dos pagamentos legítimos

• How we built it: Stripe Radar — Stripe Engineering Blog (Ryan Drapeau), 2023-03-29
• A primer on machine learning for fraud detection (стоимость фрода >$20 млрд, precision/recall, +20% YoY, retrain +0,5 п.п./мес) — Stripe (официальный гайд)
• Stripe Radar — Payment and Credit Card Fraud Detection ($1,9 трлн/год, 197 стран, 92% карт знакомы сети, −32% фрода) — Stripe (страница продукта)

Contexto

A Stripe é infraestrutura de pagamentos para milhões de empresas: segundo a página do produto, a rede Stripe processa mais de $1,9 trilhão em pagamentos por ano em 197 países. Radar é seu sistema de proteção contra fraude de ML integrado diretamente no fluxo de pagamento: ele avalia o risco de cada transação antes de ser confirmada e não requer nem integração separada nem equipe anti-fraude interna do comerciante.

A principal vantagem estrutural do Radar é o efeito de rede de dados. A fraude de cartão é um jogo de informações incompletas: uma loja on-line individual vê apenas suas próprias transações e sabe quase nada sobre um cartão que aparece pela primeira vez. A rede Stripe vê centenas de bilhões de dólares em pagamentos anualmente, então um cartão 'desconhecido' geralmente acaba sendo familiar: o guia anti-fraude de ML da Stripe citou uma estimativa de 90% dos cartões tendo sido vistos pela rede antes, enquanto a página do produto atual diz 92%. Para o modelo, isso significa um histórico de sinal rico onde um comerciante independente enfrenta um cold start.

Em março de 2023, o engenheiro de Radar Ryan Drapeau publicou 'How we built it: Stripe Radar' no blog de engenharia da Stripe — uma conta incomumente franca da evolução de um sistema de ML em produção ao longo de quase sete anos: de regressão logística a uma rede neural profunda pura, com números específicos sobre precisão, latência, o custo dos erros e tempo de treinamento. Este post é a fonte primária do caso; complementamos com o guia oficial machine-learning-for-fraud da Stripe e a página do produto Radar.

Problema

Aproximadamente 1 em 1.000 tentativas de pagamento é fraudulenta. Parece pequeno, mas a economia dos erros aqui é assimétrica e dolorosa em ambas as direções. Fraude perdida se torna um chargeback: o comerciante perde o valor da transação, paga uma taxa de disputa e, com uma taxa de disputa crescente, enfrenta taxas de rede mais altas e custos operacionais; segundo a estimativa no guia da Stripe, a fraude custa aos negócios mais de $20 bilhões anualmente.

O erro oposto — bloquear falsamente um comprador honesto — afeta não a linha 'perdas por fraude' mas receita e lealdade: em uma pesquisa citada pela Stripe, 33% dos consumidores disseram que não comprariam novamente em um negócio após um declínio de pagamento falso. Um sistema anti-fraude que bloqueia 'por precaução' estrangula silenciosamente as vendas de seus clientes — e é por isso que a precisão (qual percentual do que você bloqueia é realmente fraude) importa tanto quanto o recall (qual percentual da fraude você captura).

O contexto de execução adiciona restrições difíceis. A decisão deve ser tomada no checkout, dentro do fluxo de pagamento, em uma fração de segundo — sem adicionar fricção para o comprador. E o adversário se adapta: padrões de fraude mudam constantemente, com atacantes sondando deliberadamente os pontos fracos do modelo. Um modelo retreinado uma vez por dia por um trabalho noturno cronicamente fica atrás dos atacantes por um dia — e em anti-fraude um dia pode ser caro. Daí a segunda métrica de qualidade menos óbvia do sistema: velocidade de iteração — com que rapidez a equipe pode treinar, validar e enviar uma nova versão do modelo.

Solução

Radar avalia mais de 1.000 características de cada transação — do país do cartão e do número de países em que foi usado no dia anterior ao endereço IP e embeddings de comerciante — extraindo sinais de toda a rede Stripe. A arquitetura evoluiu em etapas, cada uma respondendo a uma limitação específica da anterior.

Começou com regressão logística — simples, rápida, interpretável. Depois vieram árvores de decisão e gradient boosting: XGBoost é bom em 'memorizar' padrões de fraude específicos. O próximo passo foi um ensemble Wide & Deep — XGBoost (responsável pela memorização) combinado com uma rede neural profunda (para generalização). Esse híbrido funcionou em produção por vários anos, mas tinha um limite: XGBoost escala e paraleliza mal, desacelerando tanto o treinamento quanto a experimentação.

Desde meados de 2022, Radar funciona com uma rede neural profunda pura sem XGBoost — uma estrutura multi-branch inspirada na arquitetura ResNeXt da visão computacional. Um detalhe honesto do post: XGBoost não pode ser simplesmente descartado — isso teria custado 1,5% do recall de fraude. A equipe compensou a queda escalando: um experimento com um aumento de 10x nos dados de transação de treinamento proporcionou um ganho de qualidade significativo, e no momento da publicação uma versão 100x estava em andamento. Direções adicionais incluem transfer learning, embeddings e multi-task learning.

A principal vitória operacional da nova arquitetura é a velocidade de iteração: o tempo de treinamento do modelo caiu mais de 85%, para menos de duas horas. Em vez de um trabalho noturno, a equipe pode retreinar e enviar o modelo várias vezes por dia, respondendo a novos padrões de ataque no mesmo dia. Segundo o guia da Stripe, mesmo simples retreinamento regular em dados frescos soma 0,5 pp de recall por mês — ao longo do tempo uma das fontes mais baratas de qualidade.

Uma pista separada é a interpretabilidade. As redes neurais profundas são 'caixas pretas' em maior grau do que as árvores, e para um sistema de pagamento isso é um problema de confiança: os comerciantes precisam entender por que um pagamento foi bloqueado. Em 2020, a Stripe lançou risk insights — um recurso mostrando quais fatores de transação impulsionaram a pontuação de risco. Uma camada de regras funciona no topo da pontuação: os comerciantes podem definir seus próprios limites e lógica (por exemplo, bloquear quando P(fraud) excede um limite), combinando a pontuação de ML com políticas comerciais.

Resultado

Radar toma uma decisão em cada pagamento em menos de 100 milissegundos — dentro do fluxo de pagamento, antes de a transação ser confirmada. De bilhões de pagamentos legítimos na Stripe, o sistema bloqueia incorretamente apenas 0,1% — a garantia de produto chave: anti-fraude que não estrangula a receita de clientes honestos. Cada salto de arquitetura (regressão → árvores → ensemble Wide & Deep → DNN puro) trouxe um ganho significativo na qualidade de detecção, e a migração de DNN reduziu o tempo de treinamento em mais de 85%, para menos de duas horas, transformando o retreinamento de um trabalho noturno em uma operação várias vezes por dia.

O efeito continua se agravando: segundo o guia da Stripe, novos modelos melhoram o desempenho de ML do Radar em mais de 20% ano a ano, e a página do produto atual afirma uma redução média de fraude de 32% para clientes e treinamento em mais de um trilhão de dólares de volume de pagamento anual. Observe os limites: 0,1% de bloqueios falsos e <100 ms são figuras do post de engenharia de março de 2023; 92% de cartões 'familiares' e −32% de fraude são dados de marketing da página do produto de 2026; nenhum desses valores é auditado independentemente, e a metodologia por trás da 'redução média de fraude' não é divulgada.

Em nossa opinião, o principal valor do caso é sua exibição honesta da economia de engenharia de trade-offs. Decidir descartar o ensemble pela velocidade de iteração, sabendo que custa 1,5% de recall, e compensar a perda com escala de dados é engenharia de ML madura: a equipe evidentemente julgou que a capacidade de responder aos atacantes no mesmo dia vale mais ao longo do tempo do que um percentual fixo de recall. Em anti-fraude, onde o adversário se adapta, a velocidade de aprendizado do sistema não é uma métrica operacional mas uma característica de combate.

Nossa segunda observação: o caso demonstra o poder de uma posição de infraestrutura. O efeito de rede de dados (92% dos cartões já conhecidos pela rede) é uma vantagem que um comerciante individual ou um fornecedor anti-fraude de nicho não pode replicar em princípio. O mesmo fato argumenta pela cautela ao ler os números: um agregador de pagamentos tem tanto a motivação quanto os meios para apresentar estatísticas da forma mais favorável, então os percentuais do produto devem ser lidos como ordens de magnitude, não relatórios auditados.

Lições aprendidas

1. A métrica anti-fraude chave não é apenas fraude capturada mas bloqueios falsos: uma taxa de falso positivo de 0,1% protege a receita dos clientes; 33% dos compradores nunca voltam após um declínio falso.
2. A velocidade de iteração é qualidade em si: reduzir o treinamento de um trabalho noturno para menos de 2 horas permite responder a novos ataques no mesmo dia.
3. Simplificar a arquitetura (descartar o ensemble para um DNN puro) é aceitável apenas se a queda de qualidade (−1,5% de recall) for compensada pelo dimensionamento de dados e do modelo.
4. O retreinamento regular é a fonte mais barata de qualidade: segundo a Stripe, dados frescos somam 0,5 pp de recall por mês sem mudança de arquitetura.
5. O efeito de rede de dados é a vantagem competitiva do anti-fraude de ML: 92% dos cartões já são conhecidos pela rede Stripe — um comerciante independente nunca pode reunir esse histórico.
6. A explicabilidade é um requisito de produto, não um luxo: risk insights existem precisamente porque os comerciantes devem entender por que um pagamento foi bloqueado.
7. Um blog de engenharia com especificidades (latência, recall, tempo de treinamento) é o padrão ouro de evidência para um sistema de ML — mas leia percentuais de marketing de páginas de produtos como ordens de magnitude.

Perguntas frequentes