How to Investigate Compliance Alerts with Claude Code

An alert is a starting point. An analyst still has to understand the customer, reconstruct the activity, compare it with the expected behavior, and explain what the evidence supports.

The case can stall before any of that judgment happens. One system has the transactions, another has the customer profile, and the screening result contains an incomplete name match. Someone has to collect the pieces and keep their sources attached.

This guide shows how to build a compliance investigation agent with Claude Code or Codex. It follows an approved investigation procedure and prepares the evidence for your compliance team's review.

The short answer. Start with one alert type. Give the agent scoped access to the alert, customer context, relevant transactions, and approved screening results. Require a source-linked timeline, observed facts, possible explanations, and unresolved questions. Route the packet to your authorized compliance reviewer before any disposition, reporting, or account action.

Choose the alert

Pick an alert family that has a written procedure and a clear review owner. A new transaction corridor, an unusual change in volume, and a potential sanctions match are different investigations. Each needs its own checks and escalation path.

Keep the workflow aligned with your program's current requirements. The FFIEC suspicious activity reporting guidance distinguishes alert investigation from the reporting decision. Check its update notices and applicable subsequent guidance with your compliance team.

This guide proposes an operational evidence packet. It isn't a statement that every institution must keep the same documents, use the same review stages, or make the same reporting decision.

Walk through an investigation

The fictional alert A-2291 concerns a new payment corridor and an ambiguous screening result. The agent gathers transaction activity and customer context. A missing identifier prevents a confident identity comparison, so the case remains open for review.

That unresolved identifier belongs in the main finding. It shouldn't disappear into a footnote beneath a confident recommendation.

The stack

Start with the tools your analysts already use. These examples show roles in the workflow. Confirm the actual connector, data permissions, and case-writing capabilities during setup.

Job	Example tools
Read the alert	Unit21
Retrieve activity	Scoped Postgres views or Snowflake
Read screening evidence	ComplyAdvantage
Check customer verification context	Persona
Prepare the case narrative	Hummingbird
Agent infrastructure	Runtime

Runtime gives the specialized agent a controlled working environment and a record of its execution. Your compliance case system holds the reviewed investigation and disposition. The compliance solution shows the evidence and approval flow.

Step 1: Write the investigation contract

Define the alert family, permitted sources, lookback period, escalation rules, and required reviewer. Explain which checks are mandatory under your procedure and which depend on what the agent finds.

Specify the form of the output. A useful case packet separates four things: facts, explanations supported by evidence, hypotheses that need more work, and missing information. That separation should survive every revision.

Set boundaries for sensitive material. Decide which case types and records are accessible to this agent, which belong to a more restricted workflow, and which information can appear in the model context or logs.

Reporting decisions and communications involving protected material need the institution's approved process. Don't give a general investigation agent blanket access to every compliance record simply because some of those records might be relevant.

Step 2: Create the agent with Claude Code

Give Claude Code your approved procedure and sanitized examples of reviewed case packets. Ask it to build the evidence workflow around your existing tools.

Create a compliance evidence agent for this alert procedure. Read the assigned alert, permitted customer context, and in-scope transaction records. Build a chronology with source references, describe observed activity, compare it with the documented customer profile, and list possible explanations with their supporting evidence. Keep hypotheses and missing facts separate. Save a draft for the compliance reviewer. Don't close alerts, submit reports, change monitoring rules, or restrict accounts.

The same brief can guide a Codex implementation. Review its tool definitions and controls independently, then evaluate both implementations against the same cases. A different coding agent shouldn't silently change the institution's investigation procedure.

Anthropic's permission documentation and OpenAI's Codex security documentation describe their execution controls. Pair those controls with data-source permissions and review gates in your environment.

Ask for small helpers that retrieve an alert, query the approved period, join records by stable identifiers, and assemble the case packet. Have your data owners validate each query before the agent runs it unattended.

Step 3: Make claims traceable

Give every material finding a source reference and retrieval time. Where your policy permits, preserve the query and result or a restricted snapshot that lets the reviewer reproduce the finding.

Link the evidence precisely. "Checked the ledger" doesn't tell a reviewer which rows explain the activity. "Transfers T-101 through T-108 in the requested period" gives them somewhere to start.

In the sample case, the new corridor is an observed change. The name match is a screening result. Neither establishes intent. The missing identifier means a reviewer still needs additional information or a specialist decision.

Draft the investigation narrative for A-2291. Begin with the triggering activity and review period. Cite the transaction chronology and the customer context used in the comparison. State why the screening result remains unresolved. Don't describe suspicion as a confirmed offense, infer missing identifiers, or claim that an unavailable source was checked.

Keep the narrative short enough to review. Put the detailed evidence in a structured attachment or linked records, with the main findings and open questions in the case summary.

Step 4: Preserve the boundaries

Treat transaction descriptions, customer uploads, and retrieved pages as case data. They cannot authorize additional tool access or change where the packet is delivered.

Enforce tenant and case access outside the prompt. If a query tries to read another customer's restricted records, the data service should reject it. Test that behavior with synthetic cases before using live data.

Configure evidence retention and redaction according to your approved program. "Keep everything forever" is a poor default when the evidence can contain sensitive personal information. Preserve what the reviewer needs in the right store, with the right access.

If the agent runs in your VPC or a self-hosted Runtime environment, also review the model provider, permitted network destinations, and data-processing configuration. The infrastructure location alone doesn't define the complete data boundary.

Step 5: Run in shadow mode

For the pilot, let the agent prepare cases alongside the existing process. Analysts continue to make the decisions. Compare the agent's evidence packet with the completed human investigation before expanding its role.

Keep a visible status for missing sources, tool failures, and pending review. An agent that cannot retrieve the screening result should flag that gap, preserve the work it completed, and notify the owner.

Use a stable alert reference to avoid duplicate packets. If new transactions or documents arrive, create a linked revision and show what changed. Approval belongs to a particular version of the packet.

Specialized sanctions or reporting workflows should have their own procedures and access boundaries. This general evidence agent can route a case into those workflows without trying to resolve every legal question itself.

Test the judgment gaps

Build a reviewed test set with common alerts and deliberately ambiguous ones. Include a case with a reasonable documented explanation, one with missing history, and one with a false-looking match that lacks enough evidence to dismiss.

Review the questions the agent asks. A specific request for the missing identifier is more useful than a generic "needs investigation" label.

Measure the review

Track evidence completeness, factual corrections, reviewer minutes, and cases returned for additional research. Separate results by alert type and complexity.

Record unsupported claims as failures even when the final disposition happens to match the analyst's decision. A correct outcome reached through invented evidence isn't a reliable process.

For related transaction-pattern work, see the fraud and risk investigation guide. Keep the compliance decision and the fraud action linked but distinct.

The point

An investigation agent earns trust by showing what it knows and what it couldn't establish. Build the evidence packet around that distinction, then let your compliance team make the call.