Insights · 11 min read
Fraud detection is a requirement for any product that moves money. Here's how to build one: rules first, the signals that matter, real-time scoring, and the build-versus-buy decision.
By GGP Editorial
Every company that moves money ends up with the same problem: separating real transactions from fraudulent ones without turning away good customers. Fraud detection is not a feature you add at the end of a build. It sits inside the payment flow, returns a decision in milliseconds, and gets blamed for every dollar it misses and every legitimate customer it blocks.
This guide is for founders and product teams building a payment product, a marketplace, a digital wallet, a lending platform, or a trading system. It covers what a fraud detection system actually is, how to start, and what it takes to build and run one.
A fraud detection system takes a single event, usually a transaction or a login, and turns it into a decision. The decision is one of three things: approve, decline, or send to review.
The hard part is the middle option. Approve and decline are easy. The review queue is where the real cost lives, because every item a human reviews is time you pay for. A good system keeps the review queue small and the false declines even smaller.
There are two distinct jobs hiding inside the phrase "fraud detection." The first is stopping payment fraud: stolen cards, account takeover, chargeback abuse. The second is stopping financial crime: money laundering, sanctions violations, structuring. They share data and tooling but answer to different rules and different regulators. This guide is mostly about the first job, with notes on where the second one touches it.
New teams usually want to start with machine learning. That is the wrong order. Start with rules.
A rule is a plain statement like "decline a card that has had three chargebacks in the last thirty days" or "hold any first purchase over $2,000 from a new account." Rules are easy to write, easy to explain to a compliance officer, and easy to turn off when they misbehave.
Machine learning needs history. A model can only learn patterns that already exist in your data, and in your first few months you have almost none. You also need enough confirmed fraud labels to train on, and those labels arrive slowly. A rules engine works on day one.
The realistic path for most teams:
| Stage | What you run | What it does |
|---|---|---|
| Launch | Rules only | Fixed thresholds for amount, velocity, country, device |
| 3 to 6 months in | Rules plus simple scoring | Weighted rules produce a risk score, queue above a cutoff |
| Later | Rules plus a model | A trained model scores everything, rules handle edge cases and policy |
Most production systems are a hybrid. The model does the broad scoring, and rules sit on top for the things a model should not decide, like "always hold transfers to a new beneficiary" or "block this country outright."
The quality of your fraud system comes down to the signals you feed it. A model with bad inputs is a bad model, no matter how good the model itself is. The signals that carry the most weight in practice:
Velocity. How many transactions, card changes, or login attempts has this account, card, device, or email made in the last hour, day, and week. A card used three times in ten minutes across three merchants is a different risk than one used once.
Device fingerprint. A stable identifier for the device behind the session. Fraud rings reuse devices and emulators, and a device that has touched many accounts is a strong signal.
Account age and history. A new account making a large purchase is riskier than an established one. Chargeback history, login history, and how the account was created all matter.
Location and behavior. Where the transaction comes from, how it compares to the user's usual location, and whether the email address was verified.
Network and consortium data. What other merchants have seen from this card, email, device, or IP address. You cannot build this alone; you get it from a provider.
Amount and item risk. A $50 grocery order and a $5,000 electronics order are different risks, and the category matters as much as the number.
The work of turning raw events into these signals is called feature engineering, and it is where fraud projects live or die. It is also where most of the engineering time goes, not the model itself.
A fraud system is not one model. It is a small stack of components that have to run in order and fast.
Data ingestion. Every transaction, login, and account change lands in one place, in a usable shape.
A feature store. The computed signals, kept current so the scoring step does not have to recompute a week of history on every request.
A scoring engine. Runs the rules and the model, returns a score.
A decision engine. Turns the score plus policy into approve, decline, or review. Policy lives here, separate from the model, so a compliance person can change a threshold without touching the model.
Case management. The review queue where humans look at flagged transactions, with the context they need on one screen.
Dispute and chargeback handling. When a fraud chargeback arrives, you need the original decision trail to respond, and to feed the outcome back into the model.
Model monitoring. Fraud patterns shift. A model that worked in March can quietly fail by June. You need to watch precision, recall, and the false-positive rate continuously, and retrain on a schedule.
Most teams underestimate case management and monitoring. They are the difference between a system that catches fraud and a system that catches fraud while your ops team drowns.
Some fraud decisions are real time, some are not. A card payment has to be scored in the few hundred milliseconds before the customer gets bored and leaves. A loan or account application can be scored in seconds or minutes. A daily sweep looking for structured money movement runs overnight.
Latency changes the architecture. Real-time scoring means the feature store and the model have to be fast and always available, with a fallback decision if scoring times out. Batch scoring can afford heavier models and more data. Most teams build the real-time path first, because payments are where money is lost fastest.
Fraud prevention overlaps with authentication rules and with anti-money-laundering rules, and the three pull in different directions. This is the part founders get wrong.
In the EU and UK, the Payment Services Directive (PSD2) requires strong customer authentication on most remote card payments: two independent factors, like a password plus a one-time code, or a fingerprint in a banking app. 3D Secure 2 is the protocol that carries this. It has two flows: a challenge flow where the customer authenticates, and a frictionless flow where the card network's risk checks let the payment through without a challenge. The frictionless flow depends on transaction risk analysis, and the thresholds are tied to fraud rates.
A few facts worth knowing, because they change how you design checkout. Low-value transactions under EUR 30 can skip authentication within limits. The transaction risk analysis exemption lets low-fraud merchants skip the challenge if their fraud rate stays under the thresholds the regulator sets. And 3D Secure shifts the liability for a fraud chargeback from you to the card issuer in many cases, which is a direct financial reason to use it, not just a compliance one.
On the money-laundering side, payment and fintech products usually carry know-your-customer obligations and transaction monitoring duties. Fraud rules and AML rules share the review queue but have different reporting requirements. Get legal and compliance advice for your specific market before you build; these rules vary by country and change. The engineering point is that your data model needs to keep fraud signals and AML signals side by side from day one, because retrofitting them later is painful. Our FinTech security requirements article covers the wider security picture.
You do not always need to build. Most payment processors ship a baseline fraud tool with their checkout: Stripe Radar, Adyen's risk engine, and similar products from other processors. These catch a useful share of card fraud with no engineering work, and they are the right first step for most marketplaces and e-commerce sites.
You build when the off-the-shelf tools cannot see your data or apply your rules. That happens with marketplaces where both buyers and sellers can defraud you, with lending products where fraud is about repayment ability rather than stolen cards, with trading platforms that need custom limits, and with any product where your edge depends on data only you hold.
A common pattern is a hybrid: keep the processor's fraud checks, add a rules layer of your own, and bring in an external data provider for device and email reputation. Build the model in-house only when your volume and labels justify it. If you are at the stage of planning a payment product, our guide on payment system development walks through what else that build involves.
There is no honest single price for a fraud detection system, because it depends on how much you build and how deep you go.
A rules-only layer on top of a payment processor's built-in fraud tool is the cheapest path and can take a few weeks of engineering. A rules engine plus case management for a marketplace is a real project, usually measured in months, because the review queue and the reporting are substantial. A full in-house pipeline with a feature store, a trained model, and continuous retraining is a multi-month program and a team, not a task.
The team is the clearest signal of cost. A minimal build needs backend engineers plus someone who understands fraud. A serious build adds a data engineer and a data scientist, and the data scientist is the hardest role to hire for. The model call itself is cheap. The engineering around it, the data cleanup, the case management, and the ongoing monitoring, is where the budget goes. If you want a sense of how the AI side is priced, our AI development cost breakdown explains the drivers.
We build fraud detection as part of the payment and fintech systems we deliver, so we treat it as a first-class piece of the architecture, not a bolt-on. GlobeSoft has 40+ engineers and has delivered 300+ projects, including multi-market brokerage trading systems, payment platforms, and financial management systems. That background shapes how we work: we start with the data and the rules, we keep policy separate from the model, and we design the review queue before we pick a model.
If you are building a payment product or a fintech platform and want to know what a fraud layer should look like for your specific case, tell us what you are building and where the transactions flow. We can help you define the scope, the data model, and a build-versus-buy path that fits your volume. Our cross-border payment platform guide is a good companion if payments are moving across borders.
Do I need a fraud detection system before I launch?
If you accept card payments or hold customer funds, yes. You can start with the fraud tool built into your payment processor, but you should not launch with nothing.
Rules or machine learning first?
Rules first. Machine learning needs historical data and labeled fraud, which you will not have on day one. Add a model once the data justifies it.
How fast does a fraud decision need to be?
For card payments, a few hundred milliseconds. The decision has to fit inside the checkout without slowing the customer down, and you need a fallback if scoring is slow.
Does 3D Secure remove the need for fraud detection?
No. It shifts liability and reduces card fraud, but it does not stop account takeover, first-party fraud, marketplace abuse, or money laundering. It is one layer, not the whole system.
What is the difference between fraud detection and AML?
Fraud detection stops people from stealing money or goods. Anti-money-laundering controls stop people from moving the proceeds of crime. They share data and a review queue but answer to different rules and regulators.
Can I buy a fraud system instead of building one?
Often, yes. Start with your processor's tool, add rules and external data as needed, and only build a custom model when your data or your business model requires it.
Tell us what you are building and where you are today. We typically reply within 24 hours.
