How to Use Jev with Claude Code and Codex for Fraud and Transaction Monitoring

Jev is a model from TypeSafe AI that reads text, like a fraud alert summary, a dispute claim, or an analyst's case note, and returns typed decisions instead of prose: a category, a score, or the probability that a statement is true. It answers in well under a second at a fraction of a cent, so you can run it on every alert your monitoring system produces.

Fraud teams don't lack alerts. They lack an order. A card testing burst, a takeover in progress, and a dozen alerts from a rule that fires on every payday all land in the same queue, and an analyst works them in the order they arrived. The one where money is leaving right now waits.

This is a guide to fixing that with two layers: Jev as a pre-trigger that sorts and ranks every fraud and transaction monitoring alert, and a Claude Code or Codex agent running in a Runtime sandbox that prepares the evidence for the alerts Jev puts first. Your fraud team makes every decision.

The short answer. Compute the numbers in code, then send each alert to Jev with a few questions your fraud team wrote: which pattern is this, how urgently does it need review, do the notes mention a detail that changes the priority. Code applies thresholds and decides which alerts an agent prepares first. The agent builds a source-linked timeline from your processor, device, and account data and drafts a case. Jev never blocks, freezes, refunds, or closes anything.

What it does. The takeover in progress reaches an analyst first, already traced, instead of sitting behind forty alerts from a noisy velocity rule.

What it is not. It isn't a fraud model, a rules engine, or a replacement for your vendor's real-time scoring. Every material improvement comes from a human questioning a premise. Plan for that.

What Jev returns

Jev answers three kinds of questions: a choice from a list you define, a score across levels you describe (numbered from 0), and a noul, the probability that a statement is true. For a fraud alert, the difference looks like this:

result = client.system_one(alert_facts, {
  "pattern": Choice(
    instructions="Which fraud pattern is this?",
    criteria={"account_takeover": None, "card_testing": None,
              "mule_activity": None, "unclear": None}),
  "funds_leaving_now": Noul(instructions=
    "Money is still moving out of the account"),
})

What comes back is a pick with a probability for each option and a single number for the noul. Your code can act on both. A chat model asked the same thing would answer "this looks like it could be account takeover," which you then have to parse.

TypeSafe launched Jev in early access on September 15, 2026, and lists 70 to 500 milliseconds end to end and $0.042 per million input tokens, with output free. These are the vendor's numbers, so benchmark them on your own alerts. For the full introduction, see how to use Jev with Claude Code and Codex for triage.

The rule that matters most

Jev ranks. It never acts. In fraud this is tempting to forget, because the cost of a slow block is real money. Hold the line anyway, for four reasons.

No rationale. Jev returns probabilities, not reasons. A frozen account, a declined claim, or a closed alert needs a reason a reviewer, a customer, and sometimes a regulator can follow. A score of 0.88 isn't one.

The input is written by the other side. Fraudsters write the dispute claims, the support messages, and sometimes the merchant descriptors Jev reads. TypeSafe's model notes say Jev doesn't treat state as hostile by default, and that injected instructions or misleading framing can shift answers. A ranking can absorb that. A block decision can't.

Fair treatment. Freezing an account cuts someone off from their money. Simon Willison's early review of Jev raised bias concerns for sensitive ranking. Keep Jev's questions on the activity and the case, never on personal characteristics, and check for skew across customer segments before you rely on the ranking.

Real time is already solved. Your rules engine and fraud vendor make the approve or decline call at authorization, with models trained on transaction data. Jev reads text. Put it after the alert fires, not in front of the payment.

A ranking mistake delays a case by minutes. A wrong freeze reaches a customer. Keep Jev on the ranking side.

How the investigation runs

# risk-opsIllustrative

PS

Priya Shah

@Risk Risk case R-318 shows a burst of declined authorizations. Can you investigate whether other merchants saw the same pattern?

RiskAgent

Three merchants show a similar burst of low-value declined authorizations. The pattern warrants a card-testing review, but the records alone do not confirm fraud. I attached the queries and affected accounts. No blocks or rules were changed.

Approval neededPossible card-testing activity for reviewApproveRequest changes

Run #1047 · on record

1. SardineLow-value authorization burst
2. MarqetaHigh decline rate in a short window
3. SnowflakeSimilar sequence across 3 merchants
4. PostgresRecent onboarding · no prior case
5. Unit21Evidence and proposed checks attached

Every query, tool call, and approval is saved with the run.

Jev reads every alert and orders the queue. The agent traces the alerts that cleared your threshold. The fraud analyst sees a finished case and makes the call.

The stack

Job	Tools
Fast decisions	Jev by TypeSafe
Investigating agent	Claude Code Codex
Fraud alerts and signals	Sardine Or SEON, Sift, Feedzai, or your own rules engine
Payments and cards	Stripe Marqeta Lithic
Account history and relationships	Snowflake Or scoped Postgres views
Cases	Unit21 Or your case manager
Approvals and handoff	Slack
Agent infrastructure	Runtime

How it runs in Runtime

Runtime is an operating system for coding agents like Claude Code and Codex. The investigating agent is built from three pieces: a template (the agent's computer, with its secrets, network rules, and triggers), skills (the runbooks it follows, one per fraud pattern), and tools (what it can reach). Every run leaves a record of what it read, so when an analyst asks why a case was prepared the way it was, you can show them.

Where Jev fits in fraud

The last row is the second use for Jev. TypeSafe's guidance for coding agents includes checking whether a statement is true of a document or record before taking an action. A draft case that claims a link without citing the record goes back to the agent before it reaches an analyst.

Step 1: Write the questions (fraud team)

The fraud team writes these, not engineering. Jev answers exactly what you ask, literally, and TypeSafe's build guidance is to ask narrow questions that each evaluate one property and combine the answers in code.

Write the level descriptions carefully. "Funds have left the account in the last hour and more transfers are queued" beats "Critical."

Compute numbers and dates in code. TypeSafe's documentation is blunt: Jev "is not a calculator," it doesn't count reliably, and it reads dates as text rather than ordered quantities. Velocity, amounts, time windows, and "how long after the phone number changed" all belong in code. Pass the result as a sentence: "14 inbound transfers from 11 senders in 6 hours. 92% sent out within 20 minutes to 2 payees added today."

Don't ask it to detect. Your monitoring rules and fraud vendor already decide what's suspicious, on data Jev never sees. Jev reads their output and helps decide what an analyst looks at first.

Combine in code. The pattern, the urgency score, and the nouls are separate answers. Weight them in a short function your fraud team can read, and change the weights when the ranking looks wrong. TypeSafe documents this as composite scoring.

Step 2: Set thresholds, then prove them

Your fraud team writes the routing rules as plain policy anyone on the team can read.

Keep the sensitive thresholds low. A false alarm costs an analyst two minutes. A takeover that waits an hour costs the customer their balance.

Then run it in shadow mode. Send several weeks of past alerts through Jev, compare its ranking with what your analysts actually escalated and confirmed, and pay most attention to confirmed fraud that Jev ranked low. That comparison tells you whether the ranking is good enough before anything depends on it.

Sample the bottom of the queue every week once it's live. The risk with any ranking system is that real cases sink quietly.

Step 3: Build the triage with Claude Code or Codex

Put your TypeSafe API key in an environment variable and ask your coding agent to build it. TypeSafe has Python and TypeScript SDKs and publishes an agent skill that gives Claude Code and Codex context on the Jev API, and community projects like jev-code register Jev as a tool inside both.

"Build a triage service for our fraud alert queue. For each new alert, pull the alert facts and compute velocity, amounts, counts, and time windows in code. Write them as plain sentences. Send those sentences and any case notes to Jev using the TypeSafe SDK with the questions in fraud-questions.md. Combine the answers with the weights in routing-policy.md. Log the input, every Jev answer, the model field in the response, and the rule that fired. Never block, freeze, refund, or close anything. Write tests from the labeled alerts in /fixtures and report every confirmed fraud case that would have been ranked in the bottom half."

Two habits make these prompts work harder:

• Say why, not just what. "Log the model field, because the jev-latest alias moves when TypeSafe ships a new version and we need to re-test" gets you an audit trail instead of a debug log.
• Name the failure you're preventing. "An alert that mentions law enforcement must never start an agent, even with a low urgency score" exists because that's the case that hurts.

Step 4: Create the Runtime template

The template is what the investigating agent boots into every time Jev hands it an alert: the skills, tools, and secrets it can use, and the hosts it can reach.

"Create a Runtime template for fraud case preparation. Connect Sardine, Marqeta, and Unit21 with read-only access. Add a read-only connection to the masked account and device views in Snowflake. Allow network access only to those hosts and Slack. Load every credential from secrets. The agent can save draft cases and post to #risk-ops but can't change an account, a card, a payment, or a rule."

Add credentials through the template's secrets in the dashboard, never by pasting them into chat. Give the agent its own identity in each vendor so your access logs show exactly what it read. Then test the limits: ask it to freeze an account or refund a payment and confirm the request fails at the permission layer.

Attach your runbooks as skills, one per pattern. When Jev says "account takeover," the agent loads the takeover runbook first instead of rediscovering it.

Decide what reaches Jev separately from what reaches the agent. Jev needs alert facts, case notes, and claim text. It rarely needs card numbers, account numbers, or identity documents, so leave them out and review TypeSafe like any other third-party processor.

Step 5: Let Jev start the agent, then check its work

When a rule says "prepare now," the triage service starts a Runtime session with the alert, Jev's answers, and the rule that fired.

"When the routing rule is 'prepare now,' start a session from the fraud template with the alert, the Jev scores, and the matched pattern. Load the skill for that pattern. Build the timeline from read-only sources and cite every record. Look for linked accounts one hop out, using only the approved identifiers, and say how strong each link is. Separate facts, possible explanations, and missing records. Save a draft case in Unit21 and post a summary to #risk-ops. Don't label the customer, and don't recommend blocking. List the questions the analyst needs to answer."

Before the case reaches a person, send the draft back to Jev with a short rubric: does it state what happened and when, does every link name the identifier behind it, and does every claim cite a record. Drafts that fail go back to the agent.

What stays human

Where it breaks

Numbers and dates. Velocity, structuring-style amounts, and "within 48 hours of a phone change" all fail if you ask Jev directly. Compute them first and send sentences.

Fraudsters write the input. Claims, chat messages, and notes can be written to steer a model. Treat Jev's answers as routing hints. No score should ever grant the agent more access, skip an approval, or shorten a review.

Literal reading. "Is this account takeover" and "did someone other than the account holder log in" get different answers. TypeSafe also notes double negatives and complex indirection are answered less reliably. When routing looks wrong, fix the question before blaming the model.

Language. TypeSafe says English is where Jev's accuracy is currently best. If your case notes are in Spanish or Portuguese, shadow-test on those cases specifically. The Spanish fraud monitoring guide covers the agent side for LATAM payment rails.

New model versions. Every response names the versioned model that answered. When it changes, run your shadow set again before trusting the new ranking.

Measuring it

• Time to first review for confirmed fraud. The number a pre-trigger exists to move.
• Confirmed fraud found in the bottom of the queue. From your weekly sample. The target is zero.
• Analyst minutes per alert. Split by pattern, since a mule trace and a card testing burst aren't comparable.
• Cases returned for missing evidence. Before and after the QA check.
• Alerts closed without action, by rule. From the rule review row. It tells you where the noise comes from.

Keep loss rates in your wider risk program's measurement. This setup changes the order and preparation of work. On its own it doesn't prove a change in losses.

Measure the current queue first, or you won't be able to show what changed.

A realistic timeline

The point

Fraud teams don't lack judgment. They spend it in arrival order. When ranking an alert costs almost nothing, every alert can be ordered the moment it fires, and the analyst's first minutes go to the account where money is still moving.

Jev ranks, the agent prepares, and your fraud team decides. Keep those three jobs separate and the speed comes without the wrong freezes.

Back to the queue.

For the same pattern in onboarding, sanctions, and AML, see how to use Jev for KYC, KYB, and AML. For the investigation agent itself, see how to investigate fraud alerts with Codex and Claude Code and the compliance alert guide. If you're choosing a monitoring platform, see the best AI agents for AML alert triage.