Why decision models are the next step in fraud prevention

Better tools, rising losses

I've spent almost 15 years fighting online fraud. I was at ThreatMetrix from Series C through its acquisition, working on rules-based device intelligence and digital identity. I've worked on merchant onboarding, payments and seller risk at eBay and Payrix. I also founded Spec, an anti-fraud startup that connected directly to a website's HTTP traffic, which gave us all of the request data and let us set honeypots to catch attackers. I've spent years at the front line of fraud prevention, and in that time, the industry's tools have gotten better every year.

Unfortunately fraud losses continue to go up every year. Juniper Research estimates that eCommerce fraud cost businesses $44 billion in 2024, and forecasts $107 billion by 2029. The direct loss is only part of the bill. LexisNexis Risk Solutions found that each $1 of fraud now costs US retailers and eCommerce businesses $5.13 once the cost of handling it is counted, up from about $2.40 in 2016. Each of the tools we give fraud teams has a limit we've learned to live with.12

I've watched teams wait months for a new model release to fix a specific fraud problem. When it finally shipped, it stopped the attack for about six hours. Then the attackers worked out what the model was watching and changed tactics, and the team was back to waiting for the next release. Anyone who has fought fraud knows this cat-and-mouse game, and a model that takes months to change is always a move behind.

This post is about those limits, why the obvious fix (LLMs) doesn't work for live decisions, and why I think decision models are the next step.

The two tools we've had

Almost every fraud stack is built from two pieces: rules and traditional machine learning models, usually XGBoost, either built in house or bought from vendors like Sift, Socure and Forter. Both work, and fraudsters have learned the limits of each.

Rules are fast, cheap and easy to explain, but they're brittle. At ThreatMetrix, I saw how powerful rules on device and identity signals can be. I also saw how quickly fraudsters learn them. A rule is a fixed threshold, so attackers probe it until they find the line and then stay just under it. Teams respond with more rules, and every new rule adds false positives that land on good customers.

Traditional ML models generalize better, but they're slow to change and hard to explain. An XGBoost model only sees the features someone engineered for it. It learns from labeled outcomes, like chargebacks or confirmed bad accounts, that often take months to arrive, and then it needs a retraining cycle. So the model is always learning last quarter's fraud. And a score of 742 doesn't tell an analyst, a customer or a regulator why someone was declined.

Cases that rules and models can't decide end up in manual review. That's where your best analysts read the whole picture: does this email look like it belongs to this person, does this business website look real, does this appeal make sense? That judgment is the most valuable thing in a fraud operation, and it's the one thing we've never been able to apply to every decision.

Why a traditional model can't see the context

An XGBoost model only sees a table. Each row is an event, and each column is a number or a category that someone decided to compute. Anything that isn't turned into a column doesn't exist for the model.

That works for things that are easy to count, like how many accounts share a device or how old an email domain is. It breaks down for what a good reviewer actually looks at: the meaning of text, whether details fit together, knowledge about the world, and fraud nobody has seen yet. A few examples:

These are the hardest things to turn into numbers, and each one is its own data science project. Text embeddings can capture some of it, but they're another model to build, tune and explain. So these questions go to manual review, which is exactly where the case study below found reviewers beating the model.

Why LLMs weren't the answer

When large language models arrived, they looked like the missing piece. For the first time, a model could read a case note, an email address or a merchant website the way an analyst does.

The problem was economics. Fraud decisions happen on every login, every signup and every payment. In my experience, running a frontier LLM on every event could cost ten times more in tokens than the fraud it stopped. In Finic's own benchmark, frontier models cost $7.82 to $25.46 per 1,000 decisions. They're also too slow for a login or checkout flow, and they answer in paragraphs that a rules engine can't act on.3

The math on a single event

Take a typical onboarding or login decision. To judge it the way an analyst would, a model needs the applicant's contact details, identity check results, linked accounts and recent login and transaction history. Even a modest slice of that history, 300 lines of event data, is about 12,000 tokens, because each line carries a timestamp, IP address, device ID, user agent and location, at roughly 40 tokens a line. Add the instructions and the question, and one decision is about 13,000 tokens of input.

Then the LLM has to answer, and current frontier models think before they do. Those thinking tokens are billed as output, at five times the input price. For a judgment over 300 lines, expect roughly 1,000 to 10,000 output tokens. At current list prices, that works out to:45

These are estimates. The range runs from light thinking on a shorter history (about 8,500 input tokens and 1,300 output) to heavy thinking on a longer one (about 25,000 input and 10,000 output), and the typical case is 13,000 input and 3,300 output. Prompt caching helps little because each event's data is different.

Now compare that with what's at stake. If 1 in 100 events is fraud, a model that typically costs $0.06 to $0.12 per event spends $6 to $12 for every fraudulent event it sees, and up to $30 when it thinks longer, before counting a single false positive. That's more than many promo abuse, refund abuse and small-order fraud cases are worth, which is how teams end up spending more on tokens than they save in losses.

Speed is the other problem. An LLM has to read the full history, then think and write its answer one token at a time, which takes several seconds to tens of seconds, depending on how much it thinks. A login, signup or checkout flow needs an answer in a fraction of a second.

So fraud teams that use LLMs mostly use them in the back office: summarizing cases and helping investigators. Many haven't adopted them at all. The live decision, where the losses happen, has stayed with rules and models.

What a decision model is

A decision model is a small language model trained to make one kind of call: given this context, how likely is X? It keeps what made LLMs exciting, the ability to read raw context, and drops what made them impractical: the cost, the delay and the prose.

The difference is in what goes in. XGBoost learns from features you build. A decision model reads the raw context, like contact details, login events or an appeal memo, and answers questions you write in plain English.

What comes out is a calibrated probability. When Grayson says 0.8, it should be right about 8 times in 10, so a rules engine, an existing model or a review queue can use it directly.

A decision model doesn't reason step by step the way an investigator writes up a case. It makes the fast judgment call an experienced analyst makes in a few seconds, and it tells you how confident it is. That's what makes it fast and cheap enough for live decisions.

Rules and XGBoost decide from inputs someone defined in advance. LLMs and decision models read the raw context. Decision models are the only option that reads context and returns a score fast and cheap enough for every live decision.

Decision models don't win every row, and they don't need to. The strongest setup uses both: rules and XGBoost for what they already do well, and a decision model that adds the judgment of your best human reviewer to every event, in milliseconds. Rules and XGBoost are fast, but they can't read context the way that reviewer does. An LLM can, but it's too slow and expensive to run on every login, signup and payment. And your human reviewers can only get through the queue in front of them, often a day or two later. Per-call costs for rules and ML vendors come from my experience with vendor contracts. LLM costs use list prices and the data sizes in the worked example above, and Grayson's cost uses its published price.

What Grayson does for fraud teams

Grayson is Finic's decision model for fraud, risk and financial crime. Where you already run rules and XGBoost models, it adds to them: each answer is a calibrated probability you can add to your model as a feature or combine with your existing score. Where you don't, or where those models are weakest, it can stand on its own. Either way, when a new fraud pattern appears, your team writes a new question and starts scoring, without months of waiting for labels and a retraining cycle.

The proof: a top 5 global fintech

We recently tested Grayson with one of the five largest global fintechs on a hard problem: customers appealing restrictions placed on their accounts at onboarding. Each appeal went either to human reviewers, who took one to two days, or to automated rules.

We scored more than 17,000 approved events from a single month in 2026 against the customer's own bad-account label, measured over the following 90+ days. Grayson saw only the data available when each event was created. The reviewers it was compared with had one to two more days of account activity to look at.

To build the score, we asked a set of Grayson questions about each event, tested which ones predicted best and kept those, and combined their answers into a single score calibrated to the customer's outcomes. The questions and the score were chosen on separate data from the appeals we report results on. The combined score below brings together that score and the customer's own XGBoost score. A simple combination of Grayson's answers beat a production XGBoost model where that model was weakest, which shows the lift came from what Grayson reads, not from more complex modeling.

The results below use AUC, a standard measure of how well a model ranks risk. Take one account that turned out to be bad and one that turned out to be good: AUC is the chance the model gave the bad account the higher risk score. An AUC of 0.5 is a coin flip, and 1.0 means the model ranks every bad account above every good one. Because a coin flip already scores 0.5, gains that look small matter: a model at 0.55 picks the bad account just 55% of the time, barely better than guessing. The results below compare how much higher one AUC was than another.

• ✣The Grayson score beat both the human reviewers and the existing automation, despite seeing less data.
• ✣Together, the two scores beat either one alone: a combined score would cut bad accounts let through by a double-digit percentage without affecting good accounts.
• ✣Well over half of manual reviews could be automated with no higher bad rate than today's automated approvals.
• ✣Thousands of additional customers a month would become active, because customers approved within 15 minutes were about twice as likely to become active as those who waited one to two days for a review.

The activation number matters as much as the fraud numbers: every day a good customer waits in a review queue is a day they might give up and go elsewhere.

Strongest exactly where XGBoost is weakest

For accounts the customer's XGBoost model scored between 700 and 800, it was barely better than a coin flip. Those are exactly the accounts a score can't settle and a person ends up reviewing. On the same accounts, Grayson's AUC was about 20% higher, and about 14% higher for accounts the model scored below 700. Above 800, the existing model stayed slightly ahead, by about 2%.

Below 700, human reviewers made better calls than the model; above 700, the model beat the reviewers. Grayson beat the reviewers in every score band, and beat the model in every band except the most confident one, above 800, where the signals are clean and a traditional model does what it's built for.

In the gray zone, the answer lives in context: the restriction memo, the rule that triggered it, the linked accounts, and whether the login history fits the customer's story. A traditional model sees that only through features someone thought to build. A good reviewer reads all of it, a day or two later. Grayson reads it on every appeal, the moment it's filed. That's why the two work best together: the XGBoost model on the clean, confident cases, and Grayson on the gray zone where that model struggles.

Where Grayson beats what you have

Grayson is most likely to outperform your current rules, models or vendor when a decision has one or more of these traits:

The more of these traits a decision has, the bigger Grayson's advantage tends to be. Volume matters most for messaging, where scams usually start before any money moves. The next section shows what that looks like by industry.

Who Grayson is for

Grayson fits any online business that makes high-volume decisions where an analyst's read of the context would beat a score. That covers most of the companies fraud teams work for. None of the questions below is a threshold a rules engine or XGBoost model can check. Each one takes a reviewer's judgment, like reading a message or a website and deciding whether the details fit, and human reviewers can't make those calls in real time:

Marketplaces

Where Grayson helps: Seller and buyer onboarding, listing review, account takeover, payout risk

• ✣Seller onboarding: Does this seller's first listing match the business they described at signup?
• ✣Listing review: Is this listing using everyday words as code for counterfeit, prohibited or illegal goods?
• ✣Listing review: Is this price too good to be true for the item the listing describes?
• ✣Buyer onboarding: Does this new buyer's first message to a seller read like a real shopper or a scam script?
• ✣Account takeover: After this login, do the account's new messages and listing edits sound like the same seller?
• ✣Payout risk: Do this seller's messages and reviews suggest they're taking payment without shipping?

Peer-to-peer messaging

Where Grayson helps: Buyer-seller chats, dating and social apps, in-app support: scams, phishing links, off-platform payment requests, impersonation

• ✣Off-platform payments: Is this message trying to move the conversation or the payment off the platform, even without obvious words like "WhatsApp" or "Zelle"?
• ✣Spam: Is this message promoting third-party goods or services, even when it's worded as a casual question?
• ✣Phishing: Is this message pressuring the other user to click a link or share a login or payment code?
• ✣Impersonation: Is this user posing as platform support, a delivery service or another trusted party?
• ✣Romance and investment scams: Is this conversation building trust over several days before money comes up?
• ✣Overpayment scams: Is this buyer proposing an overpayment, refund or shipping arrangement that only benefits them?

Merchants and eCommerce

Where Grayson helps: New account fraud, promo and refund abuse, chargeback disputes, manual order review

• ✣New account fraud: Was this email address created just for this order?
• ✣Promo abuse: Do this new account's name, email and address look like small variations on an existing customer's?
• ✣Refund abuse: Does the customer's explanation for this refund fit their order and delivery history?
• ✣Chargeback disputes: Does the reason given for this dispute contradict the customer's own messages to support?
• ✣Manual order review: Do the order contents, shipping address and gift note fit together as a real purchase?

Payment companies and PayFacs

Where Grayson helps: Merchant onboarding and underwriting, transaction laundering, merchant monitoring

• ✣Merchant onboarding: Does this merchant's website sell what the application says?
• ✣Merchant onboarding: Does this website look built just to get approved, with template text and no real contact details?
• ✣Underwriting: Do the expected sales volume and typical order size make sense for the products on this merchant's website?
• ✣Transaction laundering: Do the product descriptions on this merchant's transactions match what it was approved to sell?
• ✣Merchant monitoring: Has this merchant's website changed in a way that suggests it's now selling something riskier?

Fintechs and neobanks

Where Grayson helps: Account opening, money mules, scams, account takeover

• ✣Account opening: Would a careful person believe this name, email, phone and address belong to one real individual?
• ✣Money mules: Does the reason the customer gave for opening the account fit the money moving through it?
• ✣Money mules: Do the payment memos on this account read like real payments or like money being passed along?
• ✣Scams: Does this customer's chat with support suggest someone else is telling them what to say?
• ✣Account takeover: Do this session's support chat and profile changes sound like the real customer?

Banks and financial services

Where Grayson helps: Onboarding, KYC and KYB review, scam and authorized push payment fraud, alert triage

• ✣Onboarding: Does the source of funds the applicant described fit their stated occupation?
• ✣KYC review: Taken together, do the identity check results show this email and phone belong to the person named on the account?
• ✣KYB review: Do this business's website, registration and stated activity describe the same real company?
• ✣Authorized push payment fraud: Does the reason the customer gave for this payment sound like a common scam story, such as a "safe account" or an urgent invoice?
• ✣Alert triage: Do the case notes on this alert describe real risk, or a situation that's already been explained?

Lenders and BNPL

Where Grayson helps: Application fraud, synthetic identities, first-party fraud

• ✣Synthetic identities: Would a careful person believe this email, phone and address belong to one real individual?
• ✣Application fraud: Does this applicant's employer look like a real business that fits the job title and income they gave?
• ✣Application fraud: Do the free-text answers on this application read like the applicant's own, or like text reused across many applications?
• ✣First-party fraud: Does the reason the applicant gave for this loan fit the amount and the rest of the application?
• ✣BNPL: Do the items, shipping address and past orders fit together, or look like goods bought to resell?

Gig economy and delivery

Where Grayson helps: Worker onboarding, account sharing, promo abuse, payouts

• ✣Worker onboarding: Do this worker's verification results, contact details and stated location fit one real applicant?
• ✣Account sharing: Do customer complaints about this worker describe someone other than the person on the account?
• ✣Promo abuse: Do this new customer's details look like small variations on an existing account's?
• ✣Payouts: Do this request to change payout details, and the chat around it, sound like the real worker?
• ✣Delivery claims: Does the customer's "not received" message fit the delivery's location data and timestamps?

Travel and mobility

Where Grayson helps: Booking and rental fraud, account takeover, loyalty fraud

• ✣Booking fraud: Do the traveler, route and timing of this booking make sense for the person paying?
• ✣Booking fraud: Does this last-minute booking for a different traveler look like someone reselling travel bought with a stolen card?
• ✣Rental fraud: Do the renter's license details, payment card and contact details fit one real person?
• ✣Account takeover: Does this request to support to change the account email sound like the real owner?
• ✣Loyalty fraud: Does this redemption, booked for someone other than the member, look like points being sold online?

Streaming and digital media

Where Grayson helps: Account takeover, account sharing beyond the household, piracy such as resold logins and restreaming

• ✣Account sharing: Do the devices, locations and viewing on this account fit one household, like a student away at college, or several unrelated people?
• ✣Account takeover: Do the changes made right after this login, like a new email and new profiles, look like the real subscriber?
• ✣Piracy: Do this account's profile names and viewing schedule look like a login being resold to strangers?
• ✣Piracy: Does this account's activity look like it's being used to rebroadcast live events?

Every question above asks whether pieces of evidence fit together, the kind of call only a person could make until now. Grayson answers it on every event, as it happens. Because each answer is a calibrated probability, it can also go straight into your XGBoost model as a new feature, and the combined score in the case study above, which cut the bad accounts let through by a double-digit percentage, shows what that pairing can do.

For lenders, Grayson works best as a fraud signal or one input to the credit model, since US lenders have to give specific reasons when they decline an applicant.

Where this fits today

Decision models don't replace everything in your stack, and I'd be skeptical of anyone who says they do. Grayson is ready for the use cases above, and like other fraud vendors, our solutions and implementation engineers help each customer set it up. It doesn't investigate cases or write explanations; it makes fast, calibrated calls. The real test is how it performs on your own data.

Can Grayson replace my vendor?

In a lot of places, yes. It helps to sort your decisions into three groups:

• ✣Decisions no vendor covers today. Appeals, listing review, scam messages, alert triage and merchant website review mostly run on manual review, because no score handles them well. Here Grayson replaces a queue, not a vendor.
• ✣Decisions where Grayson can stand on its own. When a decision depends mostly on context, as merchant onboarding, KYB review, refund and dispute review usually do, Grayson can replace a vendor score outright.
• ✣Decisions where you'll want both. Some vendors bring data from across their whole customer network, such as whether an email or device has shown up at other companies, along with device fingerprinting, chargeback guarantees or a case management tool. Grayson doesn't replace data or services you'd lose by switching. For decisions that lean on those, like card payments, pair Grayson with the vendor, the combination that beat either one alone in the case study.

The way to know which group a decision falls into is your own data. Run Grayson next to your current setup, compare them decision by decision, and cut what Grayson does better. With vendors charging $0.02 to $1.50 per call and Grayson costing less than a tenth of a cent, the comparison costs little.

Fifteen years of better rules and better models haven't bent the fraud-loss curve, and I don't think another rule or another feature will. What's been missing is an analyst's judgment on every decision, at a cost that makes sense. Decision models like Grayson add that judgment to the rules and models you already run.

If you want to see how Grayson performs on your data, reach out. We'll score a few months of your history and show you the results.