O Stripe Radar é excelente naquilo que faz: pontuar uma transação no exato momento em que o dinheiro se movimenta. Mas o momento em que o dinheiro não se movimenta é precisamente onde o nosso problema vivia.
Nós operamos um teste grátis de 7 dias. Para iniciá-lo, o usuário salva um cartão, mas nunca é cobrado — nos bastidores, isso é um SetupIntent do Stripe, não um pagamento. Sem cobrança não há evento no momento da cobrança, o que significa que as regras mais poderosas do Radar não têm nada para avaliar no instante que mais importa: quando uma conta fraudulenta está sendo criada e começando a consumir os créditos do teste.
Esta é a história de como saímos de apagar incêndios de fraude em conversas avulsas para operar uma camada antifraude automatizada, minuto a minuto — construída sobre o nosso próprio produto, o Zero.
O Radar é ótimo. "Ótimo" não é "perfeito."
O Stripe Radar é genuinamente bom naquilo que faz. Treinado com mais de US$ 1 trilhão em volume anual de pagamentos, seus modelos reconhecem um cartão que já viram antes 92% das vezes, e o Stripe relata que o Radar reduz a fraude em 32% em média para as empresas que o utilizam.
Mas releia esse número: reduz, não elimina. Um corte médio de 32% é grande — mas significa que uma parcela considerável da pressão de fraude ainda chega à sua porta, e o Stripe é admiravelmente honesto sobre o motivo. Nas palavras deles, "reduzir o número de falsos positivos muitas vezes aumenta a probabilidade de que mais fraudes reais passem despercebidas." O vazamento não é um defeito do modelo; é o custo deliberado de não bloquear seus clientes de verdade. Toda equipe antifraude está escolhendo, de propósito, quanto deixar passar.
Para um produto guiado por teste grátis, esse vazamento é mais largo do que o número de destaque sugere — porque a parte mais poderosa do Radar nem sequer é executada.
Por que um portão só consegue reduzir
Há uma razão mais profunda pela qual um motor que atua no momento da cobrança consegue reduzir a fraude, mas nunca acabar com ela, e não tem a ver com os modelos do Stripe — tem a ver com tempo e informação. No instante em que um cartão é adicionado, o cliente ainda não fez nada. Sem histórico de login, sem comportamento no produto, sem padrão de uso para aprender — apenas um cartão e um punhado de sinais de rede. O Radar está tomando a melhor decisão possível com a fatia mais fina de evidências, no único momento em que tem o mínimo para trabalhar.
Esse é o teto real. Você pode ajustar um portão, mas não pode lhe dar dados que ainda não existem. A informação que de fato separa um abusador de um cliente é, em sua maior parte, criada depois que o portão já teve que decidir.
Estágio 1: Apagando incêndios na janela de conversa
Nossa primeira resposta foi inteiramente manual. Quando uma onda de abuso aparecia, alguém abria uma conversa com nosso agente e trabalhava o incidente ao vivo: puxar os cadastros recentes, olhar os cartões, encontrar o padrão, derrubar as contas na mão.
Funcionava, mas não escalava. Cada incidente começava do zero. O conhecimento — como é a cara dessa rede, quais sinais são confiáveis — vivia na cabeça de uma pessoa e em um único fio de conversa, e evaporava no momento em que a janela era fechada.
Também aprendemos uma lição cara no lado bom do funil: quando quisemos reconquistar usuários genuínos que abandonaram o checkout, um e-mail de retomada descuidado para um endereço fraudulento causa dano real — ele confirma que o endereço está ativo. Qualquer automação que construíssemos teria que distinguir um potencial cliente real de um plantado.
Estágio 2: Reforçando a porta da frente com o Radar
Nosso passo seguinte foi empurrar tudo o que conseguíamos para o início do fluxo, no Radar — listas de bloqueio e regras de velocidade na etapa de adicionar o cartão, ajustadas à pressão que estávamos vendo. É o primeiro movimento certo, e ele estancou os ataques mais grosseiros.
Mas dois tetos apareceram rápido. O primeiro é o que o próprio Stripe nomeia: um motor que atua no momento da cobrança é um botão de trade-off, não uma muralha — aumente-o e você bloqueia clientes reais, diminua-o e mais fraude passa. O segundo é estrutural e específico de testes grátis: esses 32% são conquistados no momento da cobrança, e um teste com SetupIntent não tem cobrança para pontuar. A menos que você habilite explicitamente o Radar em métodos de pagamento salvos, o motor não roda de jeito nenhum — e mesmo quando roda, apenas regras de Block, Allow e 3DS se aplicam a um SetupIntent. A ação "Review", aquela que dá a um humano uma segunda olhada, nunca dispara.
Então a melhor camada da pilha está, por padrão, fora de campo exatamente no momento em que mais precisávamos dela. O Radar é um portão na porta da frente. Precisávamos de uma patrulha atrás dele.
Estágio 3: Uma segunda camada, construída sobre o Zero
Depois do cadastro, o quadro de informações se inverte. A conta começa a deixar um rastro — e a parte mais rica desse rastro vive em um sistema que o processador de pagamentos nunca vê: nosso provedor de identidade, o Clerk.
Então demos ao Zero acesso a ele. O Clerk sabe coisas que o Stripe não pode saber: como a conta foi criada, o método de cadastro e o e-mail, a sessão e o dispositivo por trás dela, e o momento exato em relação a todos os outros cadastros daquele dia. O Stripe conhece o cartão. Nenhum dos sistemas, sozinho, conta a história inteira — mas o agente consegue ler ambos e correlacioná-los. O abuso que é invisível no portão se torna óbvio lado a lado: uma conta novinha em folha cuja identidade de login não bate com sua identidade de cobrança, criada a poucos instantes de um aglomerado de sósias. Esse cruzamento entre sistemas é exatamente o que um portão no momento da cobrança não consegue fazer — e exatamente o que um agente posicionado sobre os dois sistemas consegue.
Sobre essa base de evidências mais rica, rodamos um conjunto de tarefas agendadas do Zero a cada poucos minutos contra dados ao vivo de cadastro e cobrança. Três princípios as moldam:
1. Patrulhe, não apenas controle o portão. Em vez de avaliar um único momento, o agente varre todos os cadastros recentes em um ciclo curto, correlacionando dados da conta e metadados de pagamento para revelar contas que escaparam pela porta da frente.
2. Escalone a resposta por confiança. Nem todo sinal merece a mesma ação. Padrões de alta confiança são tratados automaticamente — a conta é suspensa e seu teste cancelado na hora, porque a ação é reversível e o custo de esperar é real. Sinais de menor confiança nunca recebem ação automática; são reunidos em um relatório para um humano revisar. Decisivo onde é seguro, conservador onde não é.
3. Mantenha uma trilha de auditoria humana. Toda ação automatizada registra o sinal exato que a disparou, para que possa ser revisada — e revertida — em segundos. Automação que você não pode auditar é automação em que você não pode confiar.
Aplicamos o mesmo rigor ao lado amigável do funil. Uma tarefa separada encontra usuários genuínos que abandonaram o checkout e rascunha um e-mail de reconquista para um humano aprovar — por trás de um filtro antifraude deliberadamente pesado, para nunca validarmos um endereço ruim. Mesmo motor, objetivo oposto.
O que isso fez com a economia
Assim que a patrulha entrou em operação, os números se mexeram imediatamente. Olhe para o cadastro no 90º percentil — as contas pesadas que causaram o dano de verdade. O custo de computação do teste que uma delas consumiu em suas primeiras horas caiu de cerca de US$ 4 para cerca de US$ 0,25 — uma queda de 94%. Na média entre todos os novos cadastros na mesma janela, a perda por conta caiu aproximadamente 85%.
O formato da mudança é o que revela tudo. A maioria dos cadastros nunca nos custou nada; a perda sempre esteve concentrada em uma cauda longa e pesada de contas que existiam apenas para drenar créditos do teste. A patrulha não encolheu o funil — ela cortou essa cauda fora. Não menos cadastros. Cadastros mais limpos.
Por que um agente, e não um script
Poderíamos ter escrito um cron job. Não o fizemos, por uma razão: a ameaça muda mais rápido do que um ciclo de release. Quando um atacante muda de tática, atualizamos as instruções de uma tarefa em linguagem comum e a nova lógica entra em operação na execução seguinte — sem deploy, sem migração de schema, sem ticket. As "regras" são um prompt, e o prompt é tão rápido de mudar quanto o atacante.
Essa é a lição de verdade. O Radar é a ferramenta certa para risco no momento da cobrança, e nos apoiamos firmemente nele. Mas um negócio guiado por teste grátis tem um ponto cego estrutural que nenhuma ferramenta de momento de cobrança consegue cobrir — e a solução não é um motor de regras maior. É uma segunda camada rápida, auditável e sempre ativa, que você pode reprogramar na velocidade da ameaça.
Lições para equipes guiadas por teste grátis
- Mapeie seus momentos sem cobrança. Qualquer ponto em que um usuário obtém valor antes de um pagamento ser pontuado é uma lacuna que uma ferramenta de momento de cobrança não consegue ver.
- Acrescente camadas, não substitua. Mantenha o Radar na porta da frente. Adicione uma patrulha contínua pós-cadastro atrás dele.
- Cruze entre sistemas. Seu processador de pagamentos e seu provedor de identidade guardam, cada um, metade do quadro. A fraude fica visível na sobreposição.
- Escalone suas ações por confiança e registre cada uma. Aja automaticamente apenas onde a ação é reversível e o sinal é forte; encaminhe o restante para um humano.
- Otimize para velocidade de adaptação. Em fraude, vence a equipe que consegue mudar suas regras mais rápido.
Curioso sobre o que um agente sempre ativo poderia automatizar na sua própria stack? Conheça o Zero.
Notas: os números do Radar são os dados publicados pelo próprio Stripe (stripe.com/radar; "A primer on machine learning for fraud detection"). Os números de perda refletem o custo de computação por novo cadastro nas primeiras horas após o registro, medidos em janelas equivalentes antes e depois do lançamento, com contas internas excluídas; a amostra pós-lançamento ainda é inicial e se consolidará ao longo do tempo.