Real-time fraud prevention on Pix: DAG, rules, and ML at Nubank

01 · CONTEXT

Defense scattered across products

At first, fraud detection at Nubank was decentralized: each product team had to integrate with separate systems and services to detect and respond to suspicious activity. It worked, but did not scale, with inefficiencies, inconsistencies, and long delays to get a new defense live.

The team imagined a unified system that would handle millions of events per day, integrate easily with new products, and operate reliably across multiple regions. Over five years, that vision became the Defense Platform, which today processes hundreds of millions of events per day with more than 99.98% disponibilidade and is used in Brazil, Mexico, and Colombia.

02 · THE FLOW

What happens when a Pix arrives

The Defense Platform receives the event with all its context (origin, destination, amount) and a component called Flow Orchestrator takes over. It knows what each type of event needs to go through; for Pix, more than 40 processes can run in parallel, among business rules and machine learning.

1. The Pix event arrives at the platform with all its context, and the Flow Orchestrator takes over.

2. The orchestrator knows what this type of event needs to go through; for Pix, more than 40 processes can run in parallel, among business rules and ML models.

3. Rules and models fetch data from features, which access internal databases, external providers, and other services.

4. Once the risk is assessed, the orchestrator decides whether the transaction proceeds or triggers an action, which can be real-time, such as blocking the transaction or showing a warning in the app.

5. Other actions run asynchronously, such as opening an internal case for investigation.

6. In any case the event is logged and sent to the distributed ETL, which aggregates more than 100 terabytes of logs per day for continuous analysis and improvement.

03 · SCALE

Events by the heap, system in shards

The platform processes about 450 million events per day and generates about 5 million internal requests per minute, because a single event, such as a Pix, can trigger dozens of downstream processes.

The architecture is distributed in shards: in Brazil alone there are 20, essentially complete replicas of the entire system, which help spread traffic and keep latency low. The stack has roots in Clojure, Datomic (on top of DynamoDB), and Kafka; the ML models are built in Python, and observability is built into every layer through real-time logs, traces, and metrics.

In another text, about cloud limits, Nubank describes sharding as a general pattern of the platform, not just of antifraud: Datomic runs several transactors on Kubernetes, each handling a subset of the data, and there are several Kafka clusters for different shards, to distribute the message load. The text points to two goals: preventing localized problems from spreading, since each shard is relatively independent, and forecasting capacity in smaller, more predictable units.

04 · LATENCY

Spending time only where the decision needs it

Detection can be done by hand-written rules or by ML models, and models tend to be slower to run. If a rule already flags the transaction as high risk with confidence, the model is skipped entirely, saving time and resources.

1. The diagram shows the orchestrator, the feature service, a rule, an ML model, and the decision node.

2. Models tend to be slower to run than rules.

3. If the rule already flags the transaction as high risk with confidence, the model is skipped entirely, saving time and resources.

4. The first version of the orchestrator ran the components layer by layer, and even low-latency processes waited for the others to finish.

5. The DAG version, with the open-source Nodely library, makes each component wait only for the data it depends on.

6. In complex flows, processing time dropped from 550 milliseconds to about 350.

05 · SHADOW TESTING

How a new defense reaches production

All defenses go through a shadow testing phase before full launch. In this phase, new rules and models run in parallel with the production environment, with real inputs but without affecting real users. This way the team validates accuracy and performance under real conditions without introducing risk.

1. The diagram shows the real event entering the orchestrator, the production defense, the new defense in shadow, and the logging of results.

2. The new defense runs in parallel with the production environment, with real inputs, without affecting real users.

3. The team validates accuracy and performance under real conditions without introducing risk.

Today, writing rules still requires engineering work. The team wants to move more of the platform to a declarative, configuration-based model, so that fraud analysts and other non-engineering roles can contribute directly, and to give product teams more visibility into the operating cost of each defense.