Nubank's Secret: How We Block 450M Fraud Attempts Daily!

So, we're Jairo and Daniel from the Defense IO team at Nubank. And today, we're going to show you how we are scaling fraud detection to more than 450 million events on a daily basis. So, a lot of conversations today are talking about agents, a lot about AI agent core. So, today we're going to show you a little bit more on how we're adapting an old service to the new AI era.

So, first, let's talk a little bit about Nuke. Maybe not everybody here knows about Nuke. So, Nuke is one of the largest financial digital services platform in the whole world. We're changing a little bit the industry, especially in Brazil. We're adapting to a new digital era where we are providing a different way of servicing um our customers as a bank. And the biggest demonstration of it is that we're impacting more than 131 million customers all around the world.

How are we currently distributed? We're very known in Latin America. Uh we are we have more than 113 million customers in Brazil. So, more than 62% of the adult population of Brazil is a customer of Nubank. In Colombia, released 5 years ago, we have we have more than 4 million customers. And in Mexico, we just recently hit the 15 million customer line. But it's it's not all about the numbers. We have some of like some licenses around the countries that we work as well. In Brazil, we're a financial institution and we are have already signaled that we want to become a bank in there. In Mexico, we were as a people and this year we're getting the banking license approved by the CNBV in April in in in April of 2026. Then, in in the US in January, We got approval to be a national bank. So this year we're also going to be releasing here in the United States. If you haven't registered, you can go to new.co and pre-register as well to be one of the first customers here. And then What is our team? The biggest difference between other banks is that we're 10,000 newbankers around the world. So where other banks require a lot of employees to operate, we operate on a very lean way. So we're more than 10,000 newbankers with over 50 nationalities around the world and around 30 to 40% of the newbankers are working in in the tech side.

And then how do we solve the financial problem to all of these millions of customers? In terms of technology, we use Clojure as a language, which is a functional version of Java. From AWS, we use a layer called Datomic over DynamoDB. For asynchronous communication, we use Kafka. For the machine learning models that we use for the protection of our customers, we are using Python. And for observability, we use a lot of tools to make sure that we validate the machine learning models and the rules that we have for our customers. But then how do we ensure the quality for all of our customers? We have a strategy called global sharding where all of our services have different replicas to make sure that the quality is met for all of the different pieces of customers and every service has a copy on each shard. So the bottleneck is the volume of users that we can provide our service and the same logic that we have will be replicated for all of them. Today we're going to be talking on how

we manage the fraud in the bank and we are members of a team called Defense IO, which has more than eight engineers, four ML engineers, four data scientists, and a product manager. And we're working together to protect our customers all around the globe. So, what do we do in DefenseIO? Basically, we are the base of the fraud business unit inside of the bank. And then, all of the different fraud teams, like know your customers, first-party fraud, they create rules to protect the transactions inside of the bank. So, we are the owners of a service called the Defense Platform, where all of the different teams inside the business unit create machine learning models and rules to protect a specific transactions. So, we apply the defenses, and we do real-time scoring, and we take the decisions to see if a transaction is going to be safe or not. But, it's not only for the fraud business unit. There are other services around the bank, like the card issuing team, the lending team, the e-commerce team, but they also create protections for their movements. And we are the engine that executes the the protections. And in the end, we release a decision. So, are we going to approve, decline, or are we going to ask for a challenge to make sure that our customer is the one doing the movement. So, without further ado, I'm going to leave it for Jairo to talk a little bit more about our theory and the numbers that we handle in DefenseIO. >> Hey everyone, I'm Jairo. So, to start, I'm going to share with you a couple of our numbers. So, current our platform produce 100 terabytes of blocks per day with a volume of 500 millions events every day with a volume of 5 million requests per minute. We have about 400 policies and models running in production using about 300 features. And we have about 100 internal customer interacting with the platform daily. So, to start, what is a defense?

Conceptually, a defense is a end-to-end pipeline from input to actions. It takes inputs from transactions or events that could be the amount of the transaction, information about the customer, or even information that doesn't come with the transaction, like a customer's past transactions or past reports. That's what we call features. We run them through a decision that is a policy that based on thresholds and and business rules it results on a decision score. And from there, the system can trigger side effects that could be live actions that the user feels right away, like a challenge or a block, or even backstage actions, like creating a report so our internal team can later analyze. So, how can we make our customer really

feel safer? We use real intervention real-time interventions, as we call live actions, and we have a couple of them. Starting with challenge, we use it to verify a customer identity. So, we can use tools like biometrics and facial recognition, and this help us against account takeovers. We also have uh delays. So, if we notice that a transaction is suspicious, we can hold this transaction for a period amount of time, allowing the customer allowing the customer to notice a mistake and decide if if they want to proceed or not with the transaction. We also have warning that there are suspicious alerts. So, if we notice that a transaction is going to a suspicious destination, we know that it it can be possibly a scammer, we can let the user know on the app and they can decide if they want to go through the transaction or not. We have to continuously create and modify defenses. So, how can we do that without affecting our customer base? We use shadow mode.

It's a separate flow that receives the same transactions and events from production, but it runs then asynchronously. So, there is no customer impact. On this flow, we run policies and models that are being tested and validated. All of the results are stored and logged on our ETL, so we can validate later the performance and business metrics. And if the results are satisfied, we can promote the defense to production. And this lets us learn in production while we keep on very safe and conservative posture.

So, let's talk now about the evolution of fraud in new. At the start, we had decentralized defenses. With about With about 10 defense builders, as we call our customer, taking 3 to 5 weeks to release a new policy production, and having about 20 policies running. For the clarity of our ecosystem, with more than 50 defense builders, taking 1 to 2 days to release a new policy, and having more than 300 policies in production. So, starting on the past, each business unit had its own fraud logic. It was usually embedded directly into the product service. There was no unified infrastructure, so policies was mostly duplicated, sometimes inconsistent, and often hard to coordinate. That setup didn't clear didn't scale with our growth. So, how did we fix that? We created a cold cold centric

infrastructure based on closure from scratch to centralize fraud across product services. It gave us a single place to define policies and models, but each defense still required significant engineer heavy lifting. And we had to manually translate analytical models into code. So, we gained in consistency and reliability, but iteration speed but iteration speed and autonomy for fraud teams were still limited. So, looking at the first version architecture on the left, we have the product service. This is where the transaction and events come from. And on the on the center, we have our platform starting with the flow orchestrator that decides if the transaction will go through the main flow or the shadow flow. And we have our main service that runs the policies and models. It's a shared code base where policies are defined in code by our engineers. And the if every change required uh deployment life cycle. Alongside that, we have our live action and backstage action manager that handles the side effects and they are backed by the atomic and Dynamo databases. And all of our platform, the decision and results are stored on our ETL so we can later on use it to help with the decisions and performance of new defense. So, how do we manage increase the autonomy and integration speed?

We move it towards a declarative ecosystem where business owners and fraud teams can configure themselves the defense without relying to code. We can do real-time configuration changes without full deployment cycles, improving how fast we can respond to new fraud patterns while still keeping guardrails in place. So, looking at the second version of the architecture, the main difference here is that we introduced it a new service, our policy engine, that runs our new policy DSL. This DSL is stored on our policy registry. And our policies are no longer uh coded in a code base where they are entities stored in a database. So, we no longer need the full deployment life cycles to deploy new policies or change them. Everything is so much faster. We also introduced a uh feature registry that's a catalog of all the features we have at new. And a configuration manager that our users can create or change configurations. They can be thresholds or any kind of of configuration that a policy may need. And all of these can be interacted by a user interface. So, our customer can easily create the new policies, features, or configurations from the UI much more easier and faster. So, now So, now then you can continue the presentation talking more of the future and AI. >> So, how are we transforming our platform

to adapt into a new AI era? So, the first thing is that we want to continue the declarative growth. We have realized that of course you can use an AI agent to create the rules that we were creating before in closure, but we want to have more control. We don't want to rely on maybe a model hallucinating or other actions like that. We want to make sure that they follow the rules that we have created and the set of actions that we have defined for our rules. So, to ensure that we want to continue in the declarative growth not not only for our rules, but in general make sure that we can change configurations and we have more control over the protections that we have for our customers. This would also mean an optimized way of using the tokens. So, instead of having to create multiple lines of code to create the logic, we could use configuration to make sure it's less volume. We also want to create unified interfaces. Instead of having a user interface where our final customers can go, see the rules, the configurations, and the mapping that they have, we also want to create an AI interface to deliver a superior experience for our customers and make sure that they can create stuff with the AI client that they are using and validate the result. I will later talk a little bit more on how we're working on that. And finally, we want to have a clear domain segregation between the different customers that use our platform. So, we have two main roles. First, are the business analysts that analyze the rules, create data sets, and understand the behavior of our customers. We want BAs to focus on the rules. We want to make sure that they are doing their job. They can optimize the the rules, and they can go faster. And second, we want engineers to focus on the data. How are we optimizing the data and the big volumes of data that we have in the bank to make sure that the data is enabled for the business analysts to take the best decisions. So, how are we currently tackling the creation of rules with natural language? First, we want to enable this for any AI interface. Could be Kiro, Cursor, whatever tools that your developers are using. And how can we do this? We created

something that called the Defense IO agent plugin, which is nothing more than a combination of prompts and an MCP. So, what are the skills that we created? In the past, our customers had to go through five different articles of documentation, how to authenticate, how to configure your environment, which are the steps that you need to follow. And this was annoying and everybody And in the case we had any update in the platform, everyone had to go, update documentation. It was very tricky. So, now with the skills, we make sure that our customers follow these steps without having to open different articles, and not only that, but that when they are using the different AI tools, they are following the instructions. Doesn't matter which one they are using. Second, Second, our server, which is the MCP. So, currently, today, we have seen a lot of agent core. So, we created our own version of of agent core by enabling tools for the AI interfaces. Our service is also a service in AWS, which is connected to our old provider, hence enabling all of the different customers inside of new to use their own authentication inside of our platform as well. So, So, in the past, what they interacted with a user interface to create different features, policies, and configurations, and now they can do the same through any AI interface. So, we enabled new tools in our service where our customers could bring the current features that we have, create new versions of the policies, and adapt them very fast, and edit any configuration that would allow us to optimize rules. So,

So, what are the challenges that we have faced during the creation of these interfaces? As anyone As all of you probably have seen today, security is one of the biggest ones. How can we make sure that we know who is the person that is creating [clears throat] the rules. Is Is this an agent? Is this a person? Who is doing it? So, we have to make sure that we have control over anyone that is interacting with the platform, and we can stop them from using it, and we can adapt to any of the new rules created. So, as as you have seen, if we create a rule the wrong way, we might be stopping millions of customers from being able to do transactions. So, we want to make sure that all of the protections that we have make sense, and everyone that's using the platform are using it in the more secure way. Second one is a scalability. Our solution for scalability is using declarative configuration for our protections, but then, how are we going to make this to work instead of millions of transactions on a daily basis to billions of transactions and billions of customers? As of now, we think that declarative is a way to achieve this, but everyone's currently facing the challenge of what happens if our customers are creating thousands of rules on a daily daily daily basis. How are we making sure that the new rules that we are creating are indeed protecting our customers? So, scalability is always going to be a challenge, especially the more we open in different places of the world. And finally, quality. How are we going to scale our global operation? If we mess one of these things, maybe thousands of customers could try to reach out to us and hey, something is failing in in my application. I cannot use my money. So, quality should be very important. So, to solve this, we're measuring, measuring a lot. How is our rule behaving? What is the business impact? What's the operational impact that we have? As a bank, we have to make sure that our transactions fulfill a specific time window to operate and and answer the requirement that our clients have. So, the quality output of the rules that we're creating has to be has to be top level. top level. So, in the end of the day,

um we know that a lot of you might be facing the same AI challenges. So, we would be very fun to discuss with any of you guys the solutions that you are currently using and if you want to know a little bit more about the solutions that we're building. So, that's what we had prepared for today.