Natan Oliveira Martins

← Voltar ao índice
01 Finanças · baixa latência Em construção

Detecção de fraude em tempo real

Milhares de transações de cartão por segundo, cada uma pontuada e bloqueada ou aprovada dentro de uma meta de 20 ms.

  • Redpanda
  • Apache Flink
  • Redis
  • XGBoost → TL2cgen
  • Prometheus

Código e roteiro no GitHub →

Demo interativa

Arraste para girar · role para aproximar · Cada ponto é uma transação amostrada; as métricas usam o fluxo simulado completo.

Vazão––
Latência p50–
Latência p99––
Precisão–
Recall–
Clientes legítimos bloqueados–
Latência p99, últimos 60 s

Bloqueadas recentemente

    O que experimentar

    1. Leve as transações além de ~80% de utilização e veja o p99 estourar o SLO muito antes do sistema estar “cheio”. Filas não são lineares.
    2. Aumente o paralelismo para recuperar latência: essa é a resposta de arquitetura, não um modelo mais rápido.
    3. Baixe o limiar: o recall sobe, mas também sobe o número de clientes legítimos bloqueados. Escolha pelo custo de cada erro.
    4. Dispare o ataque: as primeiras cobranças pequenas passam, depois a janela de velocidade de 60 segundos alcança.

    O problema

    Uma decisão de fraude só serve se vier antes do pagamento ser aprovado. Isso transforma um problema de modelagem num orçamento de latência: features calculadas em janelas deslizantes, perfil do usuário buscado em memória e modelo avaliado, tudo dentro de uma única ida e volta da autorização.

    Como funciona

    1. As transações chegam num tópico particionado do Redpanda, com chave pelo cartão, para que os eventos de cada cartão fiquem em ordem.
    2. O Flink mantém estado por cartão: velocidade de transações em 60 s, z-score do valor contra o histórico do cartão, distância da última localização.
    3. O Redis guarda o perfil de longo prazo (comerciantes habituais, região de origem), então o job de streaming nunca toca um banco de dados.
    4. Um modelo de gradient boosting, compilado para código nativo, transforma as features numa probabilidade de fraude. Um limiar, ajustado pelo custo de bloquear à toa versus deixar passar fraude, toma a decisão.
    POS / API passagens de cartão Redpanda log particionado Flink features em janela Redis perfil do usuário XGBoost scorer compilado Approve p ≤ limiar Block p > limiar
    Fig. 01 — Como funciona

    O que é real, o que é simulado

    Real

    • A função de pontuação e a lógica de limiar da demo rodam ao vivo no seu navegador.
    • Precisão, recall e percentis de latência são calculados ao vivo a partir de todas as transações simuladas, não só das desenhadas.

    Simulado nesta demo

    • As transações são sintéticas, geradas a partir de duas distribuições (legítima e fraude).
    • As latências das etapas vêm de um modelo de filas, não de um cluster medido.
    • O modelo da demo é um score logístico com pesos manuais, no lugar do XGBoost.

    Ainda não construído

    • Pipeline Redpanda + Flink + Redis (docker-compose)
    • XGBoost treinado num dataset público de fraude
    • Teste de carga com p99 medido