How to Investigate Fraud Alerts with Codex and Claude Code

A fraud alert arrives with a score and a few transaction references. The reviewer needs to know whether the activity fits the account, what happened before it, and whether related attempts change the picture.

That context often sits outside the alert. The processor has payment states, a warehouse has the historical pattern, and another tool holds the account signals. Gathering those records is a defined job an agent can help with.

This guide shows how to build a fraud investigation agent with Codex or Claude Code and run it in Runtime. The agent traces the activity and prepares an evidence packet. Your risk team decides what to do about it.

The short answer. Give the agent an assigned alert, a bounded investigation procedure, and scoped access to transaction and account records. Require a timeline, related-activity evidence, alternative explanations, and unresolved questions. Keep refunds, restrictions, fraud labels, and rule changes outside the initial investigation agent's permissions.

Choose the pattern

Start with one alert category your analysts already understand. Possible card testing, account takeover, unusual merchant activity, and a reported bank-transfer scam involve different signals and actions.

Write down the distinction between investigating an alert and executing a payment action. Stripe's manual review documentation, for example, distinguishes approving a review from actions such as capture or refund. Confirm the semantics of your own tools before making them available to an agent.

Walk through a case

The fictional alert R-318 concerns possible card testing across three merchants. The agent checks the triggering signal, traces the relevant payment attempts, and compares the related activity. It prepares findings without changing a rule or blocking an account.

The pattern deserves review, but it isn't proof of criminal intent. The agent should show the observations and how it connected them, with the limits of that connection visible.

The stack

Connect the existing investigation systems rather than rebuilding the risk stack. These tools are illustrative. Verify connector support, permitted fields, and action permissions during setup.

Job	Example tools
Read the alert and signals	Sardine
Read payment attempts	Marqeta or your processor
Compare related activity	Snowflake
Check account context	Scoped Postgres views or an internal account service
Save the review packet	Unit21
Agent infrastructure	Runtime

Runtime supplies the controlled environment for the investigation agent. Your existing risk system retains the alert, reviewer decision, and authorized actions. See the fraud and risk review solution for the complete handoff.

Step 1: Define the boundary

Specify the triggering queue, permitted search window, allowed relationship identifiers, and maximum scope of related-account research. An open-ended instruction to "find everything connected" can expand far beyond the assigned case.

Define exactly what counts as a connection in the evidence packet. A shared device signal, matching transaction reference, or common address should retain its original meaning. The agent must not turn a weak similarity into a confirmed relationship.

Have engineering and risk review those permissions together. The team that understands the signal should help decide what evidence the agent needs. The team that owns the data should enforce what it can retrieve.

Step 2: Build the agent with Codex

Give Codex sanitized examples of alerts and completed investigations. Include one case where a suspicious-looking pattern had an ordinary explanation.

Build a fraud evidence agent for our approved card-testing review procedure. Given an assigned alert, collect the permitted payment attempts, relevant account history, and authorized related-activity signals. Preserve identifiers and timestamps. Explain each connection, list alternative explanations, and prepare a source-linked review packet. Don't label a customer as fraudulent, contact them, restrict an account, refund a payment, or change a rule.

You can use the same task brief with Claude Code. Configure the tools and security settings for the chosen implementation and test the resulting workflow on the same case set.

OpenAI's Codex security documentation and Anthropic's Claude Code permission documentation cover their respective execution controls. Keep sensitive financial actions behind your own reviewed action boundary as well.

Ask the coding agent to build small helpers for retrieving an alert, reading current payment states, searching approved relationships, and formatting findings. A reviewer should be able to inspect the query behind a connection without understanding the entire agent implementation.

Step 3: Trace the activity

Start from the alert's original references. Establish which attempts happened, when they happened, and what state each reached. Separate attempted, authorized, captured, reversed, and refunded activity according to your processor's records.

Normalize timestamps for comparison while preserving the original values. If your warehouse is delayed, show its coverage alongside the more recent processor record. A stale search can miss the very activity that prompted the alert.

Investigate R-318 within the approved review window. List each referenced payment attempt and its current state. Identify the evidence that connects activity across the three merchants. Compare the pattern with available account history. State where a connection is only a shared signal, where records are missing, and which question the risk reviewer should resolve next.

For every proposed connection, retain the identifier used, the source, and the time range. If a device signal is shared, say that. Don't expand it into a claim that the same person controlled every transaction unless the evidence supports that claim.

Step 4: Prepare the decision packet

Organize the output around the reviewer's next decision. They need a concise account of what happened, the evidence supporting concern, the evidence that weakens it, and the remaining uncertainty.

Keep the proposed disposition separate from any proposed financial action. A reviewer may agree that more investigation is needed without authorizing an account restriction. Similarly, closing an alert shouldn't imply that a payment has been refunded or canceled.

Use careful language. "These attempts share the same device signal" is inspectable. "This customer is a fraudster" makes a far larger claim than the records may support.

Step 5: Run it in Runtime

Create a dedicated template for the chosen alert category. Add the reviewed procedure, approved tools, and draft format. Supply credentials through the approved secrets interface.

Start in shadow mode. Let the agent prepare packets for a bounded set of cases while analysts continue their existing process. Compare the evidence and questions before expanding the queue.

Give every run a clear completion state. If the processor is unavailable, the run should report that the payment states couldn't be verified. If the account history is incomplete, the comparison should state its actual coverage.

Use the alert ID to link repeated events and revisions. If another payment arrives during the investigation, show whether it was included. The reviewer needs to know which version of the activity they are evaluating.

Test the false leads

Evaluate the agent on ambiguous patterns as well as obvious ones. Include repeated legitimate retries, similar merchant names, shared network signals, stale warehouse data, and an alert containing references to another tenant.

Test instructions hidden in case text or uploaded documents. A sentence asking the agent to disable the alert rule is untrusted evidence, not permission to change policy.

Check that a reviewer can trace every claimed relationship to the source data. Remove a key source from a test case and confirm that the agent becomes less certain rather than reconstructing the missing evidence from its earlier examples.

Also test the action boundary directly. Attempts to refund, block, or change rules should fail at the tool or service permission layer, even if a test prompt asks for them.

Measure the investigation

Track time to a useful packet, analyst preparation time, evidence coverage, and factual corrections. Group results by pattern type and complexity.

Count unsupported connections and wrong-account lookups separately. A high draft-acceptance rate can hide these errors if reviewers are only checking whether the summary sounds reasonable.

Keep loss rates and false-positive rates in the wider risk program's measurement process. This pilot prepares evidence. It doesn't by itself establish that a change in financial losses was caused by the agent.

If the findings raise compliance questions, link the case to the compliance investigation workflow. If a partner bank requests records or a return, use the bank request guide for that separate process.

The point

A useful risk agent makes the pattern easier to inspect. It shows the connections, preserves uncertainty, and gives the reviewer enough context to choose the next step.