Token models versus decision models for fraud detection

Two kinds of model, two kinds of output

Large language models are token models. Given some text, they predict the next token, a word or part of a word, then the next, until they have written an answer. That makes them flexible: the same model can summarise a document, draft an email or explain a chart.

A decision model works the other way round. It receives a structured state, a set of typed facts about one event, and a fixed list of questions. Each answer comes back in a shape agreed in advance: a probability for a yes/no question, one option from a list, or a position on an ordered scale. Nothing is written, so nothing needs to be parsed.

Both are useful. For a real-time fraud decision, the differences matter more than the similarities.

Free text is hard to act on

A fraud decision ends in one of a few outcomes: approve, challenge, review or decline. To get there from a token model, you ask in natural language and then extract the outcome from whatever comes back. If the reply is phrased differently, hedged or wrapped in an explanation, your parser has to cope. OWASP's guidance for applications built on language models recommends defining strict output formats and validating them with deterministic code, which tells you free text needs a guard around it.

A decision model removes that step. The answer to a choice question is one of the options you listed. Anything else is a malformed response, and the code can reject it.

Confident and wrong

Token models can produce fluent text that is false. The research literature calls this hallucination; the NIST Generative AI Profile calls it confabulation and lists it among the risks that are specific to, or made worse by, generative AI. A survey by Ji and colleagues describes how the problem shows up across many text generation tasks and how hard it is to measure.

In fraud work, an invented reason such as “this device was linked to an earlier chargeback” is worse than no reason, because an analyst may act on it. A decision model cannot invent a reason in prose, because it does not produce prose. Its explanation is the state it was given and the answers it returned, both stored with the event.

Instructions hiding in the data

Fraud data is partly written by the person you are trying to assess. Names, email addresses, delivery notes and user agents are all typed by the customer, or by a fraudster. If that text goes into a prompt, it can carry instructions. OWASP puts prompt injection first in its list of risks for these applications, and Greshake and colleagues showed that instructions planted in content an application retrieves can change its behaviour and leak data, without the attacker ever touching the model directly.

OWASP also notes that prompt injection may have no fool-proof prevention, so the practical defence is to limit what untrusted text can reach. A decision model fed from a whitelist of typed fields does exactly that: free-text fields are left out, numbers are numbers, and every enum is checked against its allowed values before anything is sent.

Privacy and leakage

Sending raw customer records to any model widens the set of places personal data can end up. Carlini and colleagues showed that large language models can memorise and reproduce parts of their training data, including personal information. The safest design keeps personal data out of the model's input in the first place.

A structured state makes that checkable. You can list every field that is sent, drop identifiers such as full IP addresses or email addresses, and scan each request for anything that looks like a card number or a secret before it leaves.

Repeatability, calibration and audit

Token models usually sample their output, so the same prompt can produce different wording, and sometimes a different conclusion. Turning the sampling down helps, but it does not turn a paragraph into a calibrated probability. A fraud team needs to say “above this value, send to review” and know what that value means.

Closed answers can be measured. You can compare a decision model's probabilities with confirmed outcomes, track how they shift over time, and replay past events against a new version before switching over. That is the kind of validation and outcomes analysis US bank supervisors describe in their model risk guidance. Their April 2026 revision, SR 26-2, applies to traditional models and non-generative AI, and leaves generative and agentic AI outside its scope because those models are new and still changing quickly.

Time and cost

A real-time decision has a fixed time budget. A token model writes its answer one token after another, so a longer answer takes longer, and a long prompt costs more to process. A decision model returns a handful of numbers and choices, so the response is small and its shape never changes.

Whichever kind of model you use, calling it only for the events your rules cannot settle keeps both waiting time and spend under control.

Where token models still help

Token models still have a place in fraud operations. They are good at work where a person reads the output and decides what to do with it. Summarising a long case history for an analyst, drafting a note to a customer for someone to check, or explaining a set of reason codes in plain language are all sensible uses, provided the input is minimised and nobody treats the generated text as evidence.

A workable rule of thumb: if the output feeds an automated decision, use a model whose answers are typed, validated and calibrated. If the output is read by a person who stays accountable for what happens next, a token model can save that person time.

How FRAPE uses this

FRAPE Decision Core is a decision model. It receives typed facts about one event, never card numbers, secrets or raw personal data, and answers closed questions: a fraud probability, a recommended outcome from approve, challenge, review or decline, and a risk level on an ordered scale. Answers that do not match the questions asked are rejected and treated as a failure.

It runs only in the grey zone, after your rules, your own data and data providers have had their turn. Its answer is advice, and your policy makes the final decision. If it fails or times out, your fallback applies, and the event is never approved automatically.

• How a FRAPE decision is made
• Decision Core features