A Governed Fraud Investigation Agent on Redpanda: From Flagged Transaction to Case File in Seconds

The bottleneck is investigation, not detection

Walk the floor of most fraud operations teams and the scoring models are not the problem. Rules and machine-learning models flag suspicious card, ACH and instant-payment transactions within milliseconds. What happens next is slow, manual and expensive.

An analyst picks up the alert and starts gathering. Customer profile in one system. Account and transaction history in another. Device fingerprint and IP reputation in a third. Merchant risk profile, prior disputes and chargebacks, login history, recent changes to contact details, velocity across cards and accounts — each in its own screen. Only after all of that does the actual judgment begin: is this the customer, or is it fraud?

Three things follow from that workflow:

• Most of the analyst’s time goes to gathering, not deciding. The judgment call takes a minute; assembling the evidence takes much longer.
• Quality varies by person and by hour. A tired analyst at the end of a shift checks fewer sources than a fresh one at the start.
• False positives cost twice. Every legitimate transaction held for review is analyst time spent and a customer inconvenienced.

This is a good shape of problem for an AI agent. The gathering is repetitive and well defined, the sources are known, and the final decision can stay with a person who has the authority to make it.

Why streaming plus a governed agent

Fraud is a race against time. An investigation that starts when the analyst opens the alert is already late; one that starts the moment the transaction is flagged can have the case file waiting before anyone looks. That makes the event stream the natural place to start the agent: the flagged transaction lands on a topic, and investigation begins immediately.

Streaming alone does not make an agent safe, though. Fraud data is some of the most sensitive data a financial institution holds, and an agent that can call tools is a new kind of actor in the environment. Before a risk or compliance team approves it, they will ask:

• Whose authority does the agent act under, and can it see more than the analyst could?
• Which tools can it call, and what stops it calling the wrong one?
• How much can it spend on model calls, and who notices if it loops?
• Can we reconstruct exactly what it saw, called and concluded, months later?

Redpanda’s Agentic Data Plane (ADP), launched in October 2025 and expanded in February 2026, is a governance layer built around exactly those questions: it connects AI agents and MCP servers to live enterprise data with identity, policy, cost control and observability in the path. That is why we use it as the control plane for this pattern on Redpanda.

Reference architecture

The architecture has five parts: the event path that starts an investigation, the agent itself, the two gateways it goes through, the tools behind them, and the topics where cases, decisions and traces land.

The event path

Scored transactions above the review threshold are published to fraud.flagged. In our pattern a small Redpanda Connect pipeline (or a lightweight consumer service) consumes that topic and invokes the agent with the transaction ID and alert context. We keep this hop deliberately thin: it handles ordering, retries and deduplication, and it is where back-pressure lives if alert volume spikes.

The agent

Agents in ADP are declarative: a system prompt that defines the role and constraints, a chosen model, and attached tools, with optional subagents for focused tasks. Teams that already have agent code can bring their own framework, such as LangChain or LlamaIndex, and run it as a self-managed agent that ADP registers and routes through its gateways. For a first fraud use case we start declarative; there is less code to review and the behavior lives in configuration that risk teams can read.

The two gateways

Every model call goes through the AI Gateway, a managed proxy for LLM APIs. Providers are configured once (OpenAI, Anthropic, Bedrock, Google AI or any OpenAI-compatible endpoint), Redpanda holds the upstream credentials, and the agent calls a Redpanda-hosted URL with the provider’s native SDK. Every tool call goes through the MCP Gateway to MCP servers that are either managed from a catalog or self-managed and fronted by Redpanda. Agents can only use MCP servers that are created or registered in ADP, so there is no side door.

The topics and data contracts

Four topics carry the workflow. Each has an owner, a schema and a retention policy agreed with the fraud and compliance teams before the pilot starts.

The case file is the most important contract. It is what the analyst reads, what the decision references, and what an auditor will examine. We make every claim in it point to the tool call that produced it.

// fraud.cases — one case file per flagged transaction (illustrative)
{
  "case_id": "c-7f3e9",
  "txn_id": "t-2210-88a1",
  "summary": "Card-not-present purchase from a new device in a new country, 40 minutes after a contact-email change.",
  "evidence": [
    { "claim": "Device first seen today", "source": "device_ip_lookup", "call_id": "tc-04" },
    { "claim": "Email changed 40 min before txn", "source": "customer_history", "call_id": "tc-02" },
    { "claim": "No prior disputes on account", "source": "dispute_history", "call_id": "tc-06" }
  ],
  "recommendation": "hold_and_contact_customer",
  "confidence": "high",
  "requires_approval": true,
  "trace_id": "<OTel trace id>"
}

The tools the agent gets, and the ones it doesn’t

Tool design is where most of the safety comes from. The agent gets read-only tools, each narrow, each returning exactly the fields the investigation needs.

Most of these are thin wrappers over services the fraud team already has. Redpanda Connect can expose pipelines and processors as MCP tools defined in YAML, served with rpk connect mcp-server; each tool starts, executes and stops, with no polling between calls. That makes it straightforward to turn an existing lookup — an API call, a database query, a cache read — into a governed tool without writing a new service.

One alert, step by step

Here is a single flagged transaction from topic to decision.

The system prompt does most of the shaping. An excerpt of the kind we write:

# Investigation agent — system prompt excerpt (illustrative)
You prepare fraud case files for human analysts. You never take action on
accounts, cards or payments, and you never contact customers.
For each alert: gather the evidence listed for its reason code, using only
the tools provided. Every claim in the case file must cite the tool call it
came from. If a tool fails or returns nothing, say so; do not infer.
Recommend exactly one action from: release, hold_and_contact_customer,
escalate_to_senior, decline_recommended. Mark requires_approval=true for
any action other than release.

Guardrails

Each control maps to a question the risk team will ask. None of them depend on the model behaving well.

Audit and replay

Fraud decisions get challenged: by customers, by internal audit, by regulators. For an agent-assisted decision, “the model said so” is not an answer. You need to show exactly what the agent saw, which tools it called, what came back and what it concluded.

ADP gives two levels of record. Transcripts are read-only execution logs of each run: prompts, responses, tool calls and token usage. Traces are emitted as OpenTelemetry data to an immutable Redpanda topic with 100% sampling, and execution logs can be materialized to Iceberg tables for long-term retention. Redpanda positions these records as support for frameworks such as ISO 42001 and the EU AI Act; for a fraud team, the practical value is simpler:

• Every case file links to a trace. The trace_id in the case points to the full record of how it was produced.
• Disputes become look-ups. When a customer challenges a hold, the team can show the evidence that existed at the time, not a reconstruction.
• Changes can be replayed. Before a new prompt or model goes live, run it against last month’s alerts and compare its case files and recommendations with the decisions analysts actually made.

Measuring it

We agree the measures with the fraud team before the pilot starts, and we measure the same things for a control group of alerts worked without the agent. The numbers are yours to discover; these are the ones that matter.

The same pattern on Confluent or Apache Kafka

The pattern — event-triggered investigation, read-only governed tools, human decision, complete trace — is not tied to one platform. What changes is how much of the governance layer you get from the platform and how much you build.

Our Kafka POD has built streaming platforms on all three. The choice usually follows the platform you already run; the governance controls in the guardrails table are non-negotiable on any of them.

The failure modes we plan for

A 30-day pilot

Readiness checklist

The bottom line

Fraud teams do not need an agent that decides. They need one that does the gathering — consistently, immediately and with every claim cited — so that analysts spend their time on judgment. Started from the event stream, limited to read-only tools, and governed by identity, tool policy, spend caps and a complete trace, that agent is something a risk committee can approve.

Redpanda’s Agentic Data Plane supplies most of that governance out of the box; the work that remains is the part specific to your institution: the evidence lists, the tools over your systems, the case-file contract and the measures. That is the part our Kafka POD builds with your fraud team, in a pilot sized to prove the value on one alert type before you scale it to the rest.