How to Build a Data-Driven Fraud Prevention Strategy

A guide for fraud prevention teams that need to scale

‍

The problem every fraud manager knows

‍

Fraud prevention teams mostly operate in reactive mode.

An analyst detects a suspicious pattern. It gets escalated. A rule is created. The rule works for a few weeks until the attacker bypasses it. Another rule is created. The cycle repeats.

‍

Meanwhile, false positives increase, friction for legitimate users grows, and the more sophisticated attacks — those operating at scale, coordinated and distributed — pass under the radar until the damage has already been done.

‍

There is a second problem that fraud managers face with less visibility but equal impact: dependence on the technology team to implement changes.

‍

Adjusting a rule, adding a new signal, responding to an emerging attack vector — everything requires a ticket, prioritization, and a sprint. In an environment where attackers adapt within hours, that operational friction has a real cost.

‍

The problem is not lack of attention or effort. The problem is that traditional systems were not designed for the volume, speed, and complexity of modern digital fraud.

‍

This document describes the principles of a modern fraud prevention strategy — one that detects in real time, learns continuously, and scales without requiring manual intervention for every attack.

‍

Why traditional systems do not scale

‍

First-generation fraud systems were built on rules: if the amount exceeds X, if the country does not match, if there are more than N attempts in Y minutes, block.

‍

Rules have a structural problem: they are static in a dynamic environment. Attackers learn them, bypass them, and exploit them. Each new rule adds operational complexity without solving the underlying issue.

‍

The second problem is response latency. When an analyst detects a new pattern, the attack has already scaled. In digital fraud, the window between the start of an attack and significant damage can be measured in minutes.

The result is a team that is always one step behind — reacting to what has already happened, without the ability to anticipate what comes next.

‍

‍

‍

The six pillars of a data-driven fraud prevention strategy

‍

1. Centralization: a single source of truth

‍

• The first obstacle in any fraud strategy is not the model or the rules. It is knowing where the data is.

• In most organizations, the information required to detect fraud lives in fragmented systems: payment events in one system, onboarding data in another, support history in a third. Each team has a partial view. No one has the complete picture.

• Without a layer that consolidates these sources into a unified view by entity — user, device, card — any analysis operates with incomplete information.

• A model trained on fragmented data does not learn real patterns; it learns the limits of what each system records independently.

• Centralization does not necessarily mean migrating everything into a single storage system. It means having an architecture where signals from different sources converge at decision time, with sufficiently low latency to operate in real time.

‍

‍

‍

2. Normalization: the foundation no one sees but everyone needs

‍

• The first obstacle in any serious fraud project is not the model. It is the data.

• The same person may exist with different formats of email, phone number, or document across systems. For an algorithm, those are different entities — and that breaks the entire analysis.

• Normalization means standardizing emails, phone numbers, and documents under a consistent schema, deduplicating records, and resolving entities across sources.

• Without this step, it is not possible to build an identity graph, compute historical behavioral features, or train models with reliable signals.

• It is the least visible step and the one that most strongly impacts the quality of everything that comes afterward.

‍

‍

‍

3. Identity graph: seeing relationships that rules cannot see

‍

• Once the data is normalized, the next step is connecting it.

• The identity graph models entities — users, devices, cards, emails, IPs, phone numbers — as nodes, and the relationships between them as edges.

• Two accounts sharing a device.

• A device associated with three IP addresses within ten minutes.

• A card linked to emails created on the same day.

• Individually, none of these signals are sufficient to make a decision. In a network, the pattern becomes clear.

• This approach is especially effective in detecting organized fraud: networks of fake accounts, multi-account attacks, coordinated bot activity.

• Many fraudulent operations only become visible when the structure of relationships between identities is analyzed — not when each transaction is evaluated in isolation.

‍

‍

‍

‍

‍

4. Feature engineering: the signals that actually discriminate fraud

‍

• A model is only as good as the features that feed it.

• In fraud detection, the most effective signals capture behavior in context, not just static attributes.

• The three dimensions with the strongest predictive power in practice:

‍

‍Velocity

• ‍‍Transaction volume per user, device, or IP within windows of 1, 5, or 60 minutes. Bot and coordinated attack velocity patterns are structurally different from human behavior — this signal alone separates a large portion of fraud.

‍

Historical behavior

‍

• Number of retries, recent declines, accounts linked to the same device, deviation from the user’s historical pattern. A legitimate user with 15 declines in an hour is a very different signal from a new user exhibiting the same behavior.

‍

Geographic context

• ‍‍Country of the IP vs country of the card vs the user’s historical location. Impossible travel — transactions occurring in incompatible geographies within short time windows — can be detected directly through these features.

‍

The most effective features are precisely those that translate identity-graph relationships into quantifiable signals over time windows:

‍

‍

The technical challenge is computing these signals in real time, over sliding windows, with low latency.

This requires a feature store designed for fraud, not a traditional analytical warehouse.

It also requires that the fraud team be able to create and adjust features without relying on a development cycle — because when a new attack vector appears, response speed is determined by who controls the tool, not who controls the code.

‍

5. Real-time decisions: the architecture problem

‍

In digital payments and onboarding, the decision window is less than 100 milliseconds.

A system that cannot operate within that range must choose between being too conservative — blocking legitimate users — or too permissive — letting fraud through.

The architecture that solves this combines streaming event ingestion, a low-latency feature store for pre-computed features, and a scoring engine that consolidates model, rules, and graph signals into a single decision.

‍

‍

One point often underestimated: most latency issues in production are not in the model itself.

They are in how the system retrieves contextual data at decision time.

But another bottleneck appears even earlier: dependence on the tech team to implement operational changes.

When the data is properly modeled and the system is designed for it, the fraud team can adjust rules, incorporate new signals, and respond to emerging threats autonomously — without tickets, without sprints, without friction.

‍

6. Labels and continuous monitoring: the silent ML problem in fraud

‍

There is a challenge that ML teams in fraud face and that is rarely discussed openly: labels arrive late.

A chargeback can take 60, 90, or even 120 days to be confirmed.

If that delay is not explicitly handled in the training process, systematic noise is introduced into the model — transactions that appeared legitimate at the time but later turned out to be fraud, or vice versa.

More mature organizations operate with multiple sources of truth, combined with different weights depending on reliability and latency.

‍

‍

They also keep models in shadow mode before deployment, and monitor performance continuously to detect drift before it impacts production.

Without this level of rigor in labeling, a model that shows good offline metrics can silently deteriorate in production.

‍

How it looks in practice

‍

Consider the following scenario, typical in digital payment platforms.

Anomaly monitors detect an unusual increase in friction for a group of merchants.

When analyzing the underlying pattern, an atypical volume of payment attempts concentrated within a short period becomes evident — the classic profile of a bot attack testing cards at scale.

In a system without the pillars described above, this scenario requires manual intervention: an analyst must detect the pattern, build or adjust a rule, and deploy it — all while the attack continues.

In a system with normalized data, an active identity graph, pre-computed velocity features, and a model trained with reliable signals, the scoring engine detects the anomaly in real time and acts automatically.

Without manual intervention.
Without allowing the attack to scale to the point of generating significant losses.

The next step — and where the most advanced systems are heading — is automating the post-attack analysis: reconstructing the attack network, identifying the entry vector, and documenting patterns in minutes rather than hours.

This becomes possible through the combination of orchestrated queries and reasoning based on LLMs applied to attack data.

‍

What you can start evaluating today

‍

Before thinking about models or architectures, it is worth conducting an honest diagnosis of the current situation.

Data

Are key entities normalized across systems?
Is there a unified user view that consolidates identity, devices, and transactional behavior?

Detection

Does the current system detect network patterns, or does it only analyze individual transactions?
What proportion of fraud cases are detected in real time versus post-hoc?

Operations

How much of the team’s time is spent building and maintaining rules versus strategic analysis?
How long does it take, on average, to respond to a new attack?
How many of these changes required intervention from the technology team?

‍

The answers to these questions define where the most critical gaps are  and where it makes sense to start.

‍

‍