---
title: We put TypeSafe AI's Jev to work on three fraud problems
source_page: https://www.sardine.ai/blog/typesafe-ai-jev-fraud-detection
canonical: https://www.sardine.ai/blog/typesafe-ai-jev-fraud-detection
format: text/markdown
date: 2026-11-02T14:00:00.000Z
author: Soups Ranjan
description: Sardine tested TypeSafe AI’s Jev on fraud-ring scoring, name/email mismatch and KYB checks. Jev caught 93% of a ring’s fraud at 1/25th an LLM’s cost.
---

**Quick links:** [Human page](https://www.sardine.ai/blog/typesafe-ai-jev-fraud-detection) · [Home](https://www.sardine.ai) · [Customers](https://www.sardine.ai/customers) · [Blog](https://www.sardine.ai/blog) · [Demo](https://www.sardine.ai/demo)

---

# We put TypeSafe AI's Jev to work on three fraud problems

**Author:** Soups Ranjan · **Published:** 2026-11-02T14:00:00.000Z · **Read time:** 9 · **Categories:** Fraud Prevention, Product, Engineering

Sardine tested TypeSafe AI’s Jev on fraud-ring scoring, name/email mismatch and KYB checks. Jev caught 93% of a ring’s fraud at 1/25th an LLM’s cost.

The short version: We tested Jev, TypeSafe AI’s new System One model for fast, software-to-software judgments, on three of Sardine’s fraud and compliance problems. On a real fraud ring it caught 93% of fraudulent transactions vs. 62% for Claude Sonnet (31 points higher recall), at about 1/25th the cost and ~100 ms per call.
Fraud-ring decisions: Jev caught 27 of 29 fraudulent transactions, vs. 26 for our rules-based approach and 18 for Sonnet.
Name/email mismatch: a signal that has resisted code for years is now fast and accurate enough to use in a live decision.
KYB answers for other software: Jev is now a node in Sardine Flow, turning findings into structured answers a customer’s agent can act on.
Sardine helps banks, fintechs and payment companies decide whether a login, a payment or a new business account is legitimate. Those decisions happen hundreds of times a second, and each one has to finish in a fraction of a second, because a customer is waiting.
That constraint explains why the industry runs on rules and machine learning models, and why large language models have mostly stayed on the sidelines. An LLM can reason through a suspicious transaction well, but it takes seconds to answer and costs around a cent per call, and neither works when you're deciding thousands of payments a minute.
TypeSafe AI released Jev in September as a different kind of model. It's built to be called by software, with no humans involved. You send it a block of data and a list of typed questions, and it returns one answer per question: a yes or no with a probability, a pick from a list you define, or a position on a scale you define. Each call takes around 100 milliseconds and costs a fraction of a cent.
TypeSafe AI calls it a System One model, after the fast, intuitive mode of thinking in Daniel Kahneman's Thinking, Fast and Slow. A fraud platform is full of places where software needs exactly that: a quick, consistent judgment on structured evidence. We tried Jev in three of them.
First as the final decision on a fraud ring, then as a way to compute a signal that has resisted code for years, and finally as the piece that turns a business check into answers other software can act on.
1. Detecting transactions linked to fraud rings
In September one of our customers, a stablecoin on-ramp, launched a new product and was hit by a fraud ring within days. They sent us five users they knew were bad. Our link analysis, which connects accounts that share a device, an email or a card, grew that list to 13 users and 29 fraudulent card transactions that had all slipped through.
We used this incident to compare three ways of making the fraud decision on those 29 transactions.
The first was our existing approach. Our Data Analyst Agent, an AI agent that investigates incidents by writing its own database queries, compared the ring's behavior to thousands of normal users over the same ten days. It found that the ring used an average of four cards per account against 1.8 for everyone else, and rotated through more than twice as many IP addresses.
It then proposed three velocity rules (rules that count how often something happens in a time window) based on those differences. Those rules would have caught 26 of the 29 transactions, a 90% catch rate.
The second and third both start from the same place: code computes the facts about each transaction, such as how many different customers share this card or device, and how many transactions have hit this email in the last hour. Those facts are then handed to a model to make the call. In one pipeline the model was Claude Sonnet, a general-purpose LLM. In the other it was Jev, which asked a single question: on a scale from low to very high, how much fraud-ring risk does this transaction carry?
Jev caught 27 of 29, or 93%. The LLM caught 18, or 62%.
The gap comes down to consistency. One account in the ring, registered under the name "Jedi Force", made 12 transactions in about 100 minutes. Some of those transactions used a card that another account in the ring had also used, and some used a fresh card.
One caveat: we asked Jev a single broad question, “how much fraud-ring risk does this transaction carry?” After discussing the results with TypeSafe, our next step is to decompose it into narrower questions, such as whether the account is showing a burst of activity and whether the card or device is linked to other accounts. We’ll test whether that sharpens the scores further. These results are from the single-question version.
Jev scored all 12 as high risk, in a tight band, because it treated twelve transactions in under two hours as the dominant fact and the card sharing as a small extra. Sonnet judged each transaction on its own and let the card flag swing its verdict by a full level, so the same burst of activity from the same account came out as a mix of medium and high. The lower of those two usually doesn't block a payment.
Jev was also far cheaper and faster. Its calls carried under a thousand tokens of input (roughly a page of text) and took about 100 milliseconds each, and the 29 decisions cost about a tenth of a cent in total. The LLM run cost around 25 times more, and that was with all 29 judgments bundled into a single request, which a live payment flow can't do. Scoring each transaction as it arrives, an LLM would pay for its full instructions on every call and take seconds to answer.
Jev is stateless: it has no memory between calls and can't fetch data for itself, so everything it knows about a transaction has to be computed in code first and placed in the request. That is also why the rules came so close. The account linking and the velocity counts do most of the fraud-catching, and they're identical in every pipeline. What Jev adds is a cheaper, faster and more consistent way to turn that evidence into a decision.
That consistency also pays off downstream. Our rule-recommendation agents learn from labeled cases, and a model that judges the same behavior the same way every time produces better labels than one whose answers vary from call to call, and those labels become stronger rules.
2. Identifying suspicious signals during onboarding
An account is opened under the name Krista Thomason, and the email address on it is dylan.whitman@gmail.com. A person spots the problem in a second. Code that spots it reliably has been surprisingly hard to write, and every fraud team has tried (for years).
The difficulty is that most mismatches are innocent. People use nicknames, initials and middle names, and spouses and relatives share an address. Names get transliterated, reordered and stripped of accents, and a huge share of emails carry no name at all, just a handle or a string of digits. A rule strict enough to catch Dylan also flags thousands of legitimate customers.
We have tried to solve this before, as has almost everyone who has worked in fraud for long enough, and the two problems have always been the same: accuracy and latency. The approaches that were accurate enough, including asking an LLM, took far too long to run inside a decision that has to be completed before the page loads.
So we gave the problem to Jev. The request is the name fields and the email address. The question is a three-way choice:
email is consistent with the name
email carries no usable name information
email clearly belongs to a different person.
The instructions spell out the innocent cases so the model treats them as consistent, and reserve "different person" for emails that contain someone else's name.
We iterated on that question a few times. Each version separated the mismatched accounts from the legitimate ones more cleanly than our previous approach, and even the default probabilities Jev returns, before any tuning, gave a usable split. Every answer came back fast enough to use in the live decision. In our internal test tool, "Richard Anderson" paired with a stranger's email comes back as a different person, and the same name with an email of r.anderson comes back consistent with 98% confidence.
The answer is a feature, in the machine-learning sense: a new signal that our rules and models can use alongside the thousands they already have. The plan is to make it available the way we expose any other data point. You could then write a rule such as "if the email belongs to a different person and the card was added in the last hour, ask for an extra verification step". The open edge case is married names, where a surname changes legitimately, and we're working on that before this ships. By integrating Jev into our rule engine, not only can we expose such advanced features to our customers, but we also enable our users to define their own customized features to perform fast checks on all sorts of problems.
3. Automating KYB risk checks
When we showed this third use to TypeSafe AI's team, they called it the canonical use case for Jev.
When a business applies for a merchant account or a bank account, the institution has to establish that it is a registered, operating company, understand what it does and check for red flags before approving it. The industry calls this Know Your Business, or KYB. Our Web360 product does the gathering: it checks tax ID and state registration records, reads the company's website, runs web searches and pulls online reviews. Then it lays the findings out for an investigator to weigh.
Over the last few months, a growing number of customers have asked for something else. They are building their own AI agents and automated account-opening flows, and they want what Web360 found delivered as answers their software can act on.
Does this business have serious adverse findings, such as lawsuits or regulatory actions? Does its observed activity match our onboarding policy? Is this the right legal entity? Each of those needs a fixed field with a defined set of values, every time.
Our old approach was hand-written application logic for each question. Take complaint history. We had a heuristic over Better Business Bureau reviews that tried to tell a pattern of serious complaints from ordinary grumbling, and every customer wanted it defined slightly differently. Maintaining bespoke logic per question per customer does not scale.
With Jev, we write the question once, hand it what we gathered, and get back an answer in a fixed structure. We've added Jev as a node in Sardine Flow, our workflow builder. A flow can now collect the information in its first steps, ask Jev a set of specific questions about it, and write the answers as structured labels. In a demo in our test environment, run on Sardine itself, a flow that adds a web search step and asks "is this company venture funded?" comes back with yes and the $100 million-plus figure.
The same investigation pipeline now ends in one of two ways. The investigator-facing path shows a human everything Web360 found. The API-facing path, the one other software calls, runs the same information through Jev and returns the structured answers a customer's own agent is waiting for.
We're finalizing the combined Web360 and Jev build with a Fortune 500 company as design partner. One of the world's largest digital banks also plans to use Jev-powered agents to screen its compliance alerts and feed the results into its own workflows.
Where this leaves us
Across all three uses, Jev took over one specific job: the moment where structured evidence needs a judgment call in the time a customer is willing to wait. Until now that call went to a human, a brittle heuristic or an LLM too slow for the live decision. The data gathering, the account linking and the rules all stay, because Jev only ever sees what the code puts in front of it.
First up: testing decomposed questions for fraud-ring scoring, per TypeSafe’s guidance. Event labeling, rule recommendations and risk scoring have the same structure, so those are the next places we plan to try it, and we'll publish more as the experiments repeat across more incidents. If you're building decision systems on Jev in another domain, we'd like to compare notes.