What data does an AI fraud detection system need to work well?

Most fraud detection failures are not engineering problems. They are data problems. A model trained on the wrong inputs, or too little history, will miss the patterns that matter and flag the ones that do not.

If you are thinking about building an AI fraud detection system, or evaluating whether you have enough data to start, the question is not really about the algorithm. It is about what you are feeding it. The algorithm is a tool. Data is the fuel. And fraud models are particularly unforgiving when the fuel is bad.

Every time a transaction happens in your system, the model looks at dozens of signals simultaneously and outputs a single number: the probability this transaction is fraudulent. That number drives the decision to approve, flag for review, or block.

The mechanism behind that score is pattern recognition across historical behavior. The model has seen hundreds of thousands of past transactions, some legitimate and some fraudulent. It has learned that certain combinations of signals appear far more often in fraud than in normal activity. A purchase at 3 AM from a device that has never made a transaction before, in a country different from the user's registered address, spending 4x more than the account's average order, is a pattern the model has seen before in your fraud cases. It assigns a high risk score.

No single signal is enough. Fraudsters know what individual triggers look like and work around them. The model's advantage is that it evaluates all signals at once, and fraudsters cannot fake every dimension of normal behavior simultaneously. According to a 2022 study by the Association of Certified Fraud Examiners, organizations that rely on manual rule-based fraud detection catch roughly 42% of fraud cases, while machine learning systems operating on rich behavioral data catch 68% or more.

The practical implication: you need data that captures behavior across multiple dimensions, not just what happened but how, when, where, and from what device.

There are four categories of signals that consistently show up as the most predictive across fraud detection research. Not all of them require engineering work to collect. Some you likely already have.

Transaction context covers the basic facts of the payment: amount, currency, merchant category, time of day, and day of week. These sound simple, and they are, but the model uses them to establish what normal looks like for each user. A $12 coffee at 8 AM on a weekday is statistically unremarkable. The same amount at 4 AM on a Sunday is worth a second look. The 2021 Nilson Report found that transaction timing and merchant category alone account for roughly 30% of a well-trained model's predictive power on card-present fraud.

Account history gives the model a baseline. How long has this account existed? What is the typical order value? How many transactions happen in a given week? Fraud often shows up as deviation from personal norms, not deviation from population averages. A user who has made $30 purchases for two years suddenly placing a $800 order is a signal. That same $800 order from a user who regularly buys expensive items is not.

Device and location data is where fraud models find their sharpest signals. IP address, device fingerprint, whether the device has been seen before on this account, the distance between the stated billing address and the login location, these are hard for fraudsters to replicate convincingly. According to LexisNexis's 2022 True Cost of Fraud report, device-linked behavioral signals reduce false positives by 25–35% compared to transaction-only models.

Velocity signals measure how fast activity is happening. Multiple transactions in a short window, rapid account changes, a sudden spike in failed payment attempts before a successful one: these are behavioral patterns humans would spot if they were watching closely enough, and the model watches closely enough.

If you are missing any of these categories entirely, filling that gap before building the model will improve accuracy more than any algorithmic choice you make.

Yes, and this is the point where most founders underestimate the problem.

A fraud detection model learns the difference between fraud and legitimate transactions from examples of both. Without confirmed fraud cases in your training data, the model has no idea what it is looking for. You can have two years of transaction history and the model will still produce random scores if none of those transactions are labeled.

The minimum threshold to train a meaningful model is roughly 300–500 confirmed fraud examples. Below that, the model does not have enough signal to generalize. Ideally, you want at least 1,000 confirmed cases, which gives the model enough variety to learn that fraud does not always look the same.

The labeling challenge is real. Most businesses have fewer confirmed fraud cases than they think, because fraud that was not explicitly caught and flagged does not appear in the training data. Chargebacks, disputed transactions, and manual review outcomes are your most reliable sources. If you have been collecting chargebacks for 18 months, start there.

If you genuinely do not have enough labeled cases, there are two paths forward. You can use semi-supervised learning, where the model learns primarily from legitimate transactions and flags outliers, without needing fraud labels. This produces lower accuracy than a fully supervised model but works as a starting point. Alternatively, you can work with a vendor that supplies a pre-trained model and fine-tune it on your data, which requires fewer of your own fraud examples because the base model was trained on millions of cases from other businesses. According to McKinsey's 2022 payments risk report, companies with fewer than 500 labeled fraud cases see 40–55% higher false-positive rates when using fully supervised models trained only on internal data.

12 months is the floor. 24 months is where models become reliable.

The reason for the 12-month minimum is seasonality. Fraud patterns shift across the calendar year. Holiday spending spikes create cover for fraud that looks like normal gift purchases. Back-to-school periods, tax season, and promotional events all change what normal looks like. A model trained on only three or six months of data has not seen the full range of legitimate behavior, which means it will flag seasonal spikes as suspicious even when they are not.

At 24 months, the model has seen each seasonal pattern twice. That repetition is what lets it distinguish between a real holiday spending surge and an account takeover that happens to coincide with December. The difference between 12 and 24 months of training data typically produces a 15–20% improvement in precision, meaning fewer legitimate transactions get blocked.

Data volume matters too. A model trained on 10,000 transactions is not very good. A model trained on 500,000 is much better. A model trained on 5 million is where accuracy stabilizes. If you process fewer than 50,000 transactions per month, reaching 24 months of history before building the model is even more important, because you need time to accumulate enough volume.

One more consideration: data freshness. Fraud patterns evolve. A model trained entirely on 2020 and 2021 data will underperform in 2023 because fraudsters adapt. The model needs to be retrained periodically on recent data, usually every three to six months, to stay accurate. This is not a one-time build. It is an ongoing system.

Building a fraud detection model without auditing your data first is how you spend $30,000–$60,000 on an engineering project and end up with a system that performs worse than a set of manual rules. The data audit takes a few days. The model build takes weeks. Do the audit first.

If you want to know whether your current data is ready for a predictive fraud system, or how to fill the gaps before building, that conversation takes about 30 minutes. Book a free discovery call