What a decision model is, and how it helps fraud teams

The grey zone problem

Most fraud decisions are easy. A card on your blocklist, or a sign-up from a device already linked to dozens of accounts, is a clear decline. A returning customer buying what they always buy, from the device they always use, is a clear approve. Rules handle these well. Nobody needs a model to block a card that is already on the list.

The hard part is the middle: events where the signals point in different directions. A new account with a verified phone number, an IP address in a different country from the card and an ordinary basket. Rules written for cases like this tend to multiply, overlap and contradict each other, and every new rule is one more thing an analyst has to reason about. This is the grey zone, and it is where a decision model is worth calling.

What a decision model is

A decision model is a model built to answer a fixed set of questions about a structured description of one situation. The input is a state: typed facts such as the event type, the amount in minor units, the country that issued the card, the age of the account, or how many times this device has been seen in the last hour. The output is a set of answers to closed questions, each in a shape agreed in advance.

Three answer shapes cover most fraud needs. A yes/no question returns a probability between 0 and 1, for example how likely this event is to be fraud. A choice question picks one option from a fixed list, for example approve, challenge, review or decline. An ordered score places the event on a scale, for example low, medium, high or critical risk. There is no free text in either direction: the model never reads a prompt and never writes a paragraph.

Because the inputs and outputs are typed, everything around the model can be ordinary, testable software. The state is built from a whitelist of fields, the answers are checked against the questions that were asked, and anything that does not fit is rejected.

How it differs from rules, scorecards and classifiers

Rules are explicit if-then logic written by people. They are transparent and quick to run, and they are the right tool for known patterns. They do not weigh evidence: a rule either fires or it does not.

Scorecards add points for each risk factor and compare the total with a cut-off. They are easy to read, but the weights are fixed, and interactions between factors (a new device matters more on a new account) have to be written in by hand.

A classic machine-learning classifier learns weights from labelled history and returns one number, usually a fraud probability. It can capture interactions a scorecard misses, but it answers a single question, and it depends on labels. In card fraud those labels arrive late and are skewed toward the transactions investigators chose to check. Dal Pozzolo and colleagues describe both problems, verification latency and the alert-feedback loop, in their study of card fraud detection on real transaction data.

A decision model sits alongside these tools rather than replacing them. It takes the same kind of structured facts a classifier would, answers several related questions in one call, and returns each answer in a form your policy can act on directly.

Calibrated answers you can set thresholds on

A probability is only useful if it means what it says. If a model gives a group of events a probability of 0.8, about four in five of them should turn out to be fraud. That property is called calibration, and it does not come for free. Guo and colleagues showed that modern neural networks are often overconfident, and that a simple post-processing step called temperature scaling corrects much of the gap.

Calibrated answers let a fraud team write plain thresholds: send to review above one value, decline above another. They also make drift visible. When the share of confirmed fraud at a given probability moves, you know that the model, or the fraud, has changed.

Explainable and consistent

Every answer from a decision model is tied to the facts that produced it. You can store the state, the questions and the answers with the event, and anyone reviewing the decision later sees exactly what the model was told and what it said. There is no hidden conversation to reconstruct.

Answers always come back in the same shape, which makes testing straightforward. You can replay last month's events against a new model version, compare the answers question by question, and see where they diverge before anything goes live.

Cheaper when it only runs where it matters

A model call costs time and money, so it should run only when its answer could change the outcome. If a hard rule has already declined the event, or the rules are confident either way, there is nothing for the model to add. Calling it only in the grey zone keeps clear cases quick and ties the bill to the events that need judgement.

People stay in the loop

A decision model advises. It does not decide. Its answers become signals in a policy that your team writes and owns, next to rule results and data from providers. Analysts see the model's view beside each event, marked as advisory, and the cases they resolve are the evidence for whether its answers hold up over time.

When the model is unavailable, the policy needs a defined fallback. The safe options are review, a challenge or a decline. Approving because the model did not answer turns an outage into an opening for fraud.

Governance: treat it like any other model

Banking supervisors have long expected models to be validated, monitored and challenged. In April 2026 the Federal Reserve, the OCC and the FDIC replaced their 2011 guidance, SR 11-7, with revised model risk management guidance, SR 26-2. It describes validation as covering conceptual soundness and outcomes analysis, which compares model outputs with real-world results, alongside ongoing monitoring as products, customers and data change. It also expects firms to understand and monitor vendor models even when the vendor does not share its code or data.

The revised guidance applies to traditional statistical models and to non-generative, non-agentic AI, and places generative and agentic AI outside its scope. A decision model with typed inputs and closed answers fits that familiar framework: you can document what goes in, test what comes out and set performance thresholds. The NIST AI Risk Management Framework points the same way, listing validity and reliability, accountability and transparency, explainability and privacy among the characteristics of trustworthy AI.

How FRAPE uses this

FRAPE Decision Core is a decision model. Hard rules run first, then FRAPE checks the cache and local data, then calls data providers only for what is still missing. Decision Core is consulted only when the rules score is uncertain. It receives a minimised summary of typed facts, never card numbers, secrets or raw contact details, and answers a fixed set of closed questions in one call: how likely the event is to be fraud, which outcome it would recommend and how serious the risk is.

Its answers feed your policy as signals, and your policy makes the final call: approve, challenge, review or decline. If Decision Core fails or times out, your fallback applies, and that fallback can never be an automatic approval. New accounts start in watch mode, so you can see what it would have said before it plays any part in a live decision.

• How a FRAPE decision is made
• Decision Core features