Machine Learning Fraud Detection vs. Rules

Last updated: September 2026

Machine learning fraud detection scores a transaction or a customer against patterns learned from labelled historical outcomes, and returns a probability rather than a verdict. That single property is what separates it from a rule, and it is also why the question fraud teams keep arguing about — rules or models — is the wrong question. Rules and models answer different questions. Every programme operating at scale already runs both.

The useful question is narrower and much more answerable: given one specific fraud decision, which mechanism should own it? This article answers that, and it answers what you owe a regulator and a declined customer when a model made the call.

TL;DR

• Machine learning fraud detection learns from labelled outcomes and outputs a probability. A rule states a decision the institution made. They are different instruments, not competing versions of the same one.

• Models cannot learn fraud that was never caught and labelled. That limit is structural, and it is the reason novel typologies and regulatory obligations still belong in rules.

• The real axis of comparison is not accuracy. It is explainability, latency, label availability, and who can change the logic without waiting on an engineer.

• Explainability is not a model property you assert in a datasheet. It is an operational property, and the place you measure it is the review queue.

• Models degrade quietly. Rules degrade visibly. That asymmetry, not accuracy, is the argument for monitoring drift by segment.

What machine learning fraud detection is

Machine learning fraud detection is a method that scores an event — a transaction, a login, an application — by comparing its attributes against patterns learned from historical outcomes that were labelled fraud or legitimate. The output is a number: a probability that this event resembles the fraud the model was trained on.

That output is a probability, not a verdict, and the distinction matters more than anything else in this comparison. A rule returns a decision. A model returns a degree of belief. Something else still has to decide what to do with it — approve, decline, step up, or route to a human.

This is why "should we use rules or models" is malformed as a question. A model does not make decisions. It produces a signal that a decision layer consumes. Fraud detection models and fraud detection rules occupy different positions in the same pipeline.

How a model actually decides

Four things happen between an event arriving and a score coming back.

Features. The model does not see a transaction. It sees features — attributes derived from the event and the context around it. Amount, hour of day, and merchant category are the obvious ones. The ones that matter are usually relational and temporal: how this amount compares to this customer's own history, how many attempts preceded it, how long the account has existed, how the device behaved before the payment page. Feature engineering is where most of the real work in machine learning for fraud detection sits, and it is the part that generic model discussion tends to skip.

Training on labelled outcomes. The model learns by being shown historical events alongside what turned out to be true about them. Supervised learning on labelled fraud outcomes requires that someone, at some point, correctly marked a case as fraud. The model's ceiling is the quality and coverage of those labels.

Scoring in real time. In production, the same feature set is assembled live and the model returns a score in the milliseconds available before a payment authorises. Real time fraud detection is a latency constraint on the whole stack, not a property of the model alone — the features have to be computable in time, which is frequently the binding limit.

The label problem. Here is the honest limit. A model can only learn fraud that was previously caught and labelled. Fraud that ran clean is invisible to it, because nothing in the training data says it happened. That is not a flaw in any particular model. It is a structural property of learning from outcomes, and it constrains what you can reasonably ask a model to cover.

The label problem bites hardest where losses surface late or never get attributed. First-party fraud is the classic case: the customer is the perpetrator, disputes arrive months later, and many cases are written off as credit loss rather than labelled fraud at all. A model trained on those labels learns a distorted picture.

What rules still do better

Rules are not the legacy layer that models are gradually replacing. Four jobs belong to them, and will keep belonging to them.

Deterministic obligations. A regulatory threshold is not a probability. A sanctions requirement is not a probability. Where an institution is obliged to act at a specific line, that line has to be stated as a line. Modelling it would be both wrong and unexplainable.

Novel typologies with no labels yet. A new attack pattern appears on a Tuesday morning. A rule can be written that morning. A model cannot be trained on it, because the labelled examples do not exist yet and will not for weeks. Rules are how a programme responds inside the window where models have nothing to learn from.

Auditable intent. A rule says what the institution decided to do, in language a regulator reads directly. That is a different artefact from a score with a threshold attached. When the question is "what was your policy," a rule is the answer in a form the question expects.

Speed of change under human control. A risk owner can adjust a rule without a retraining cycle and without an engineering ticket. When the answer to "who needs to change this, and by when" is "the risk team, by Friday," that decision belongs in a rule.

None of this requires a deep treatment of rule authoring, rule lifecycle, or how a rules engine is built. The point here is narrower: rules are one half of a decision framework, and these four jobs are why the half is permanent.

The comparison nobody is actually having

The framing of rules versus machine learning describes a debate that operating institutions are not having.

In a recent conversation, a US payments company described its live architecture plainly: an internal rules engine running in production, alongside partner and vendor layers contributing machine-learning models. Both at once. It was not described as a migration in progress or a transitional compromise. It was described as the ordinary shape of the system.

That is the common case, not the exception. It is also why teams evaluating fraud detection software find the rules-or-models question already settled by the time they get to a shortlist — what they are really comparing is how well each platform runs both. Which means the axis the vendor literature argues along — which one is more accurate — is not the axis that decides anything. The real criteria are four:

• Explainability. What must you be able to account for, to whom, and how fast?

• Latency. How much time does the decision have, and can the required inputs be computed inside it?

• Label availability. Do labelled outcomes exist for this decision, in volume?

• Ownership of change. Who needs to be able to change the logic, and does that require an engineer?

The mature pattern that falls out of those criteria is rules as guardrails around probabilistic output. The model scores. The rules bound what may be done with the score — what it can trigger on its own, what it must escalate, and what it may never override.

A framework for placing a decision

Take one specific fraud decision and ask four questions in order. The first answer that resolves the decision ends the process.

1. Is this an obligation or a judgement? Obligations are rules. Always. If a regulation, a scheme requirement, or a contractual commitment specifies the action at a threshold, it is stated as a rule and it is not modelled.

2. Do labelled outcomes exist for it, in volume? No labels means no model, whatever the ambition. If losses in this category surface late, get attributed elsewhere, or were never reviewed, the training data does not describe the problem and a model trained on it will be confidently wrong.

3. What must you be able to explain, and to whom? A decline explained to a customer service agent, a regulator, and an internal model risk committee are three different bars. The bar determines how much interpretability the mechanism has to carry, and whether the explanation has to reach the analyst handling the case or only exist in a file somewhere.

4. Who needs to change it, and how fast? If the risk team must be able to adjust it this week without an engineering cycle, that is a rule — regardless of whether a model could in principle score it better.

Worked through, the framework places decisions like this:

Each row is the same four questions answered in order. The third column is the one teams most often skip, and it is the one that most often reverses the answer.

Once a decision is placed, the next problem is tuning the threshold it sits behind — how far to push a score before the review queue drowns. That is a separate discipline from placement, and one worth treating on its own.

How the two run together in practice

Detection and decisioning are separable concerns. What produces a signal need not be what decides the outcome — a distinction a financial crime compliance consultant made plainly when separating the orchestration of alerts from the engine that generates them. Once you accept the separation, the integration patterns are straightforward.

Rules bound model output. Floors, ceilings, mandatory review bands, and hard stops a score may never override. A model may push a case toward approval; a rule decides that this customer, in this jurisdiction, at this amount, gets a human look regardless.

Models enrich rule inputs. A rule does not have to fire on a raw attribute. It can fire on a learned risk score as one of its conditions, which is how a deterministic policy gets the benefit of a probabilistic signal without surrendering its determinism.

Both belong in one stack. Oscilar is a unified platform: real-time data fabric, device and behavior intelligence, rules, and case management in one stack, with agents native to it. The reason that matters here is not completeness for its own sake. It is that splitting detection from decisioning across separate systems is what produces the swivel-chair problem — an analyst reading a score in one tool and applying policy in another, reconciling by hand. Keeping the decision layer and the signal layer in the same place is also what lets risk agents act on a case with the reasoning already attached.

The same architectural argument extends one level up, to running a shared model and rule layer across fraud and AML rather than maintaining two parallel stacks. That is its own subject.

What you owe a regulator and a declined customer

This is the part the comparison literature leaves out, and it is where the rules-versus-models question actually gets decided in practice.

Explainability is not a model property asserted in a datasheet. It is an operational property, and the place you measure it is the review queue.

The working test is concrete: can the analyst handling this case see why the decision was made, without reconstructing it? Not "is the model class interpretable in principle." Not "did we document the methodology." Can the person with the case open in front of them read the reason. That requires the decision to carry explainability codes and attributes into case management, so the reason arrives with the case rather than being assembled afterwards by someone with database access.

Underneath the codes sits feature attribution. A defensible explanation names which risk factors in this specific behaviour drove this specific score — the rapidity of a sequence of transactions, say, rather than the abstract statement that velocity features are part of the model. A score with no account of itself is not an explanation, whatever the accompanying documentation claims.

One common objection deserves an answer: that more capable models necessarily cost you interpretability. They need not. The same explainability discipline can apply across model classes, and treating interpretability as something automatically surrendered as models improve is a choice about how the system is built, not a law of the field.

Then there is the record. What makes a model-driven decline defensible months later is a full audit trail per decision with stored reasoning, human-in-the-loop by design, designed to fit SR 11-7. That is an expectation the platform is built to meet, not a certificate anyone holds — and the distinction is worth keeping straight, because a regulator will make it for you.

How models degrade, and what to watch

Rules decay too. The difference is that a rule decays visibly — someone notices it firing on nothing, or on everything. A model decays quietly, and that asymmetry is the strongest honest argument against leaning on models unattended.

Concept drift. Fraud adapts. The pattern the model learned stops describing the population it now scores. Nothing errors. The score distribution shifts slightly and the loss rate moves months later.

Data and feature drift. An upstream change alters an input silently — a field starts arriving null, a partner changes an encoding, a timestamp switches timezone. The features degrade, the model degrades with them, and nothing in the pipeline reports a failure because nothing failed.

The answer is monitoring that watches for both. Oscilar monitors data, feature and concept drift alongside outcome KPIs by segment. The by-segment part carries most of the weight: an aggregate that looks stable routinely hides a segment that has already failed, and aggregate monitoring is how a programme discovers a problem from its loss numbers rather than from its instruments.

Frequently asked questions

What is machine learning fraud detection?

Machine learning fraud detection scores a transaction, login, or application by comparing its attributes against patterns learned from labelled historical outcomes. It returns a probability that the event resembles known fraud, not a decision. A separate decision layer — usually rules — determines what happens to that score.

How does machine learning detect fraud?

A model is trained on historical events labelled fraud or legitimate. It learns which combinations of features — amount relative to the customer's history, transaction velocity, device behaviour, account age — separated the two. In production, those features are computed live for each new event and the model returns a risk score in milliseconds.

Is machine learning better than rules for fraud detection?

Neither is better, because they answer different questions. A model estimates how likely an event is to be fraud. A rule states what the institution has decided to do. Mature programmes run both, with rules acting as guardrails around model output rather than as a layer being phased out.

How do you decide whether a fraud decision belongs in a rule or a model?

Ask four questions in order. Is it an obligation or a judgement — obligations are always rules. Do labelled outcomes exist in volume — no labels, no model. What must you explain, and to whom. Who needs to change it, and how fast — if the risk team needs it changed this week, it is a rule.

How do you explain a machine learning fraud decline to a regulator or a customer?

By making the reason operational rather than documentary. The decision should carry explainability codes and feature attribution into case management, so the analyst handling the case sees which risk factors in that specific behaviour drove the score. Behind that sits an audit trail per decision with stored reasoning, which is what makes the explanation reconstructable months later.

Where this leaves you

Stop treating rules versus machine learning as a question about your institution's identity and start treating it as a question about each decision. Obligations, unlabelled typologies, and anything the risk team must change on its own schedule belong in rules. Judgements with dense labelled history belong in models, bounded by rules. And whichever mechanism owns the call, the explanation has to reach the analyst in the review queue, or it is not an explanation.

If you are working out how that looks against your own stack, our approach to real-time transaction fraud decisioning is the concrete version of the argument above.