Antifraude em tempo real no Pix: DAG, regras e ML no Nubank

01 · CONTEXTO

Defesa espalhada pelos produtos

No início, a detecção de fraude no Nubank era descentralizada: cada time de produto tinha de se integrar a sistemas e serviços separados para detectar e responder a atividade suspeita. Funcionava, mas não escalava, com ineficiências, inconsistências e longos atrasos para colocar uma nova defesa no ar.

A equipe imaginou um sistema unificado que lidasse com milhões de eventos por dia, integrasse fácil com novos produtos e operasse com confiabilidade em várias regiões. Ao longo de cinco anos, essa visão virou a Defense Platform, que hoje processa centenas de milhões de eventos por dia com mais de 99,98% de disponibilidade e é usada no Brasil, no México e na Colômbia.

02 · O FLUXO

O que acontece quando um Pix chega

A Defense Platform recebe o evento com todo o contexto (origem, destino, valor) e um componente chamado Flow Orchestrator assume. Ele sabe pelo que cada tipo de evento precisa passar; no caso do Pix, mais de 40 processos podem rodar em paralelo, entre regras de negócio e modelos de machine learning.

1. O evento do Pix chega à plataforma com todo o seu contexto, e o Flow Orchestrator assume.

2. O orquestrador sabe pelo que esse tipo de evento precisa passar; no Pix, mais de 40 processos podem rodar em paralelo, entre regras de negócio e modelos de ML.

3. Regras e modelos buscam dados em features, que acessam bases internas, provedores externos e outros serviços.

4. Avaliado o risco, o orquestrador decide se a transação segue ou se dispara uma ação, que pode ser em tempo real, como bloquear a transação ou mostrar um aviso no app.

5. Outras ações rodam de forma assíncrona, como abrir um caso interno para investigação.

6. Em qualquer caso o evento é registrado e enviado ao ETL distribuído, que agrega mais de 100 terabytes de logs por dia para análise e melhoria contínuas.

03 · ESCALA

Eventos aos montes, sistema em shards

A plataforma processa cerca de 450 milhões de eventos por dia e gera cerca de 5 milhões de requisições internas por minuto, porque um único evento, como um Pix, pode disparar dezenas de processos downstream.

A arquitetura é distribuída em shards: só no Brasil são 20, essencialmente réplicas completas de todo o sistema, que ajudam a espalhar o tráfego e manter baixa latência. A pilha tem raízes em Clojure, Datomic (sobre DynamoDB) e Kafka; os modelos de ML são construídos em Python, e a observabilidade está embutida em cada camada por logs, traces e métricas em tempo real.

Em outro texto, sobre limites de nuvem, o Nubank descreve o sharding como padrão geral da plataforma, não só do antifraude: o Datomic roda vários transactors em Kubernetes, cada um cuidando de um subconjunto dos dados, e há vários clusters de Kafka para diferentes shards, para distribuir a carga de mensagens. O texto aponta dois objetivos: evitar que problemas localizados se espalhem, pois cada shard é relativamente independente, e prever capacidade em unidades menores e mais previsíveis.

04 · LATÊNCIA

Gastar tempo só onde a decisão precisa

A detecção pode ser feita por regras escritas à mão ou por modelos de ML, e os modelos tendem a ser mais lentos de executar. Se uma regra já marca a transação como de alto risco com confiança, o modelo é pulado por inteiro, economizando tempo e recursos.

1. O diagrama mostra o orquestrador, o serviço de features, uma regra, um modelo de ML e o nó de decisão.

2. Modelos tendem a ser mais lentos de executar do que regras.

3. Se a regra já marca a transação como de alto risco com confiança, o modelo é pulado por inteiro, economizando tempo e recursos.

4. A primeira versão do orquestrador executava os componentes camada por camada, e até processos de baixa latência esperavam os outros terminarem.

5. A versão em DAG, com a biblioteca open-source Nodely, faz cada componente esperar só os dados de que depende.

6. Nos fluxos complexos, o tempo de processamento caiu de 550 milissegundos para cerca de 350.

05 · SHADOW TESTING

Como uma defesa nova chega à produção

Todas as defesas passam por uma fase de shadow testing antes do lançamento completo. Nessa fase, regras e modelos novos rodam em paralelo ao ambiente de produção, com entradas reais, mas sem afetar usuários reais. Assim a equipe valida acurácia e desempenho em condições reais sem introduzir risco.

1. O diagrama mostra o evento real entrando no orquestrador, a defesa em produção, a defesa nova em shadow e o registro dos resultados.

2. A defesa nova roda em paralelo ao ambiente de produção, com entradas reais, sem afetar usuários reais.

3. A equipe valida acurácia e desempenho em condições reais sem introduzir risco.

Hoje, escrever regras ainda exige trabalho de engenharia. A equipe quer mover mais da plataforma para um modelo declarativo, baseado em configuração, para que analistas de fraude e outros perfis fora da engenharia contribuam diretamente, e dar aos times de produto mais visibilidade do custo operacional de cada defesa.