Introducing AI-Powered Fraud Investigation

A fraud analyst opens a flagged transaction. The dashboard shows a risk score of 82, three triggered rules, and a timestamp. To understand why this event was flagged, she opens the rule configuration screen in one tab, the customer transaction history in another, and a raw event log in a third. She cross-references rule IDs against documentation, reconstructs the sequence of events mentally, and writes a case note. The whole process takes eight to twelve minutes — and she has 400 more alerts in the queue.

This is the investigation bottleneck that burns out fraud teams. The decision engine does its job in milliseconds, but the human work of understanding that decision still takes minutes per event. We built AI-powered investigation to close that gap.

What We Shipped: One-Click Investigation Summaries

Phase 1 is live now in the RTD Fraud Decision Engine. Every fraud event in the dashboard has a new "Investigate" button. One click, and an LLM generates a plain-language narrative explaining exactly what happened and why.

The summary covers:

• Rule triggers — which rules fired, what thresholds were crossed, and why those rules exist
• Risk signals — the specific data points that contributed to the risk score (velocity patterns, amount anomalies, device fingerprint changes)
• Transaction context — how this event relates to the customer's recent behavior, including what made it unusual
• Recommended action — whether the evidence supports escalation, review, or likely false positive

Instead of jumping between three screens and mentally reconstructing the story, the analyst reads a single paragraph that connects all the dots. An investigation that took eight minutes now takes thirty seconds to review.

Now Live: Conversational Q&A

The investigation panel now includes multi-turn conversational Q&A. After reading the AI summary, analysts ask follow-up questions directly:

• "Is this likely a false positive?" — the AI evaluates the evidence pattern against historical outcomes
• "Explain rule BK03" — returns the rule's purpose, threshold, and how this event specifically triggered it
• "Show me similar events from this week" — surfaces related events that match the same pattern
• "What would happen if I adjust the velocity threshold to 5?" — estimates the impact on detection and false positive rates

The chat is contextual — it knows which event you are looking at, which rules are configured, and what the historical data says. Every answer is grounded in your actual data, not generic fraud knowledge.

PII-Safe by Design

Sending customer data to external AI services is a non-starter for banks. We designed the investigation feature with privacy as an architectural constraint, not an afterthought.

Before any event data reaches the LLM, a preprocessing layer strips direct identifiers:

• Customer IDs, account numbers, and email addresses are replaced with opaque tokens
• IP addresses and device fingerprints are removed
• Names and phone numbers are redacted

The LLM receives the transaction pattern, rule evaluation results, risk scores, and behavioral signals — everything it needs to generate a useful investigation narrative, and nothing that identifies a specific customer. No customer PII is sent to external AI services.

For banks deploying on-premise, the entire pipeline can run within your own infrastructure using a self-hosted LLM, meaning event data never leaves your network at all.

Cost Control: Rate-Limited by Design

LLM calls are not free, and a busy fraud team reviewing hundreds of events per day could generate significant API costs without guardrails. The investigation feature is rate-limited to 20 messages per event per hour — enough for a thorough investigation, but capped to prevent runaway costs.

This limit covers both the initial summary generation and any follow-up Q&A messages in Phase 2. The cap resets hourly, so analysts can return to an event later if they need additional context. Usage is tracked per event, not per analyst, which means the limit reflects investigation depth rather than team size.

Before and After

Here is what changes in practice:

Before: Manual Cross-Referencing

1. Analyst opens flagged event, sees risk score and rule IDs
2. Opens rule configuration screen to look up what each rule does
3. Opens transaction history to check customer behavior
4. Mentally reconstructs the story — why did these rules fire for this customer at this time?
5. Writes case notes summarizing findings
6. Makes a decision: escalate, close, or request more information

Time per event: 8-12 minutes. Screens used: 3+. Context switches: constant.

After: AI-Assisted Investigation

1. Analyst opens flagged event, clicks "Investigate"
2. Reads the AI-generated summary — rule triggers, risk signals, transaction context, and recommended action in one panel
3. Optionally asks follow-up questions via Q&A chat (Phase 2)
4. Makes a decision with full context, without leaving the event screen

Time per event: 30 seconds to 2 minutes. Screens used: 1. Context switches: zero.

For a team processing 500 alerts per day, that is the difference between a full day of manual triage and completing the queue before lunch.

Agent-Native: MCP Integration

AI investigation is not limited to human analysts clicking buttons. The same capabilities are now available to AI agents via our native Model Context Protocol (MCP) server.

Four tools let AI agents operate as first-class fraud analysts: evaluate_risk for real-time scoring with SHAP explanations, submit_outcome for payment feedback, submit_fraud_label for labeling events, and check_health for service monitoring. Any MCP-compatible AI — Claude, GPT, Gemini — can connect directly with zero integration code.

This means a bank can build autonomous triage workflows where an AI agent reviews alerts, generates investigation summaries, labels obvious false positives, and only escalates edge cases to human analysts. Read more in our deep-dive on agent-native fraud detection.

What This Is Not

To be clear about scope: AI investigation is an analyst productivity tool, not an autonomous decision-maker. The AI explains and summarizes — it does not approve, block, or close cases on its own. Every decision still requires a human in the loop. The goal is to make that human faster and better informed, not to replace them.

The summary is also not a substitute for audit logs. The full rule evaluation trail, raw event data, and decision history remain in the system exactly as before. The AI summary is an additional layer that makes that data easier to understand.

Run-True Decision's Fraud Decision Engine includes AI-powered investigation — one-click summaries, conversational Q&A, and native MCP for AI agent integration. Talk to us to see it in action.