AI Agents for Fraud Detection: Designing Human-Controlled Decision Workflows

Fraud is growing in volume and sophistication. The US Federal Trade Commission reported that consumers lost more than $12.5 billion to fraud in 2024, a 25% increase on the year before, with investment and imposter scams the largest categories. Behind those numbers sit fraud teams overwhelmed by alerts, most of which turn out to be legitimate customers.

Agentic AI is often marketed as the answer: autonomous systems that detect, decide and act. The reality is more nuanced. Fraud detection already relies on well-tested machine learning and rules that make decisions in milliseconds. Where agents add real value is in the investigation work around those decisions — work that is still largely manual, slow and expensive. This guide explains how to design that combination responsibly. If you are new to the concept, start with our guide to what AI agents are.

The fraud stack: where each technology fits

Language-model agents are too slow, too costly per call and too variable to sit in the millisecond path of every card transaction. They can, however, read case notes, query several systems, compare patterns and write a clear summary — exactly the work that consumes analysts’ time.

What an investigation agent does

Consider an alert on an account: a new device, a changed email address and three high-value transfers to a new payee within an hour. An analyst would typically check the customer’s history, device and location data, recent changes to contact details, the payee’s history across the bank, whether similar patterns appeared in confirmed fraud, and any contact-centre interactions.

An investigation agent can carry out that evidence gathering through read-only tools:

1. Collect context: account age, normal transaction patterns, recent profile changes and login history.
2. Check linked entities: whether the payee, device or IP address appears in other alerts or confirmed fraud cases.
3. Compare with typologies: match the pattern against known schemes such as account takeover, authorised push-payment scams or mule activity.
4. Assess and explain: produce a structured case summary with the evidence for and against fraud, cited to the underlying records.
5. Recommend: suggest an outcome — clear, request customer verification, hold or escalate — with a confidence band.
6. Route: low-risk cases with complete evidence go to a fast review queue; high-risk or ambiguous ones go to senior analysts.

The analyst reviews the summary, checks the cited evidence and makes the decision. Time per case falls because the gathering and writing are done; accountability stays with a person.

Measure the right things

Because fraud is rare, “accuracy” is misleading. A system that labels every transaction legitimate is 99.9% accurate when 0.1% of transactions are fraud — and useless. Use these instead:

Worked example: total cost of fraud

Consider a payments business processing 1,000,000 transactions a month with a fraud rate of 0.1% — 1,000 fraudulent transactions — and an average loss of $400 per missed fraud. Manual review costs $4 per case, and each legitimate customer held for review costs $2 in support time and lost goodwill.

Option A: rules only. Rules flag 20,000 transactions and catch 600 frauds. Precision is 3% and recall 60%.

Option B: risk model plus investigation agent. A risk model flags 12,000 transactions containing 780 frauds (precision 6.5%, recall 78%). An agent investigates every alert at about $0.20 each in model and infrastructure cost. It routes 7,800 low-risk alerts with complete evidence to automatic release under agreed rules, and escalates 4,200 to analysts, who confirm 760 frauds. Twenty frauds are missed in the released group.

Three lessons stand out. Most of the saving comes from better detection and fewer false positives, not from cheaper review. The agent’s own running cost is small next to fraud losses. And the 20 frauds released automatically are the critical risk: the release rules and their monitoring deserve the most scrutiny, and many organisations start with no automatic release at all.

Typologies the agent should recognise

Fraud is not one problem. An investigation agent needs instructions and tools tuned to the schemes your business actually sees.

A structured case summary

Free-form prose is hard to check and hard to measure. Ask the agent for a structured summary that reviewers can scan and your systems can store:

Validate the structure in code: every fact must reference a record the agent actually retrieved, and a recommendation without evidence on both sides should be rejected and retried.

Building the evaluation set

Before the agent sees a live case, build a set of historical alerts with confirmed outcomes:

• Cover each typology in proportion to its importance, plus a large share of legitimate cases, because most alerts are legitimate.
• Include hard cases: legitimate customers with unusual behaviour, fraud that looked legitimate at first, and cases with missing data.
• Freeze the data as it was at the time of the alert, so the agent cannot see later information that analysts did not have.
• Score several things separately: factual accuracy of the summary, completeness of evidence, correctness of the recommendation and quality of the explanation.
• Ask experienced analysts to grade a sample and compare their grades with automated checks.

Re-run the set whenever prompts, tools, models or upstream data change, and add new confirmed cases each month so the set reflects current fraud patterns.

Data and integration requirements

The agent can only investigate what it can see. Typical integrations include the core transaction ledger, customer profile and identity verification results, device and login telemetry, case-management history, payee and merchant data, and contact-centre notes. Each should be exposed through a narrow, read-only tool that returns only the fields needed, scoped to the customer and accounts linked to the alert. Response times matter: if one system takes 30 seconds to answer, the whole investigation slows, so cache stable reference data and set timeouts.

Controls: keep humans accountable

Fraud decisions affect customers’ money and access to services, and are subject to regulatory scrutiny. Design the agent so it cannot cause harm on its own:

• Read-only by default. Investigation tools read data; they do not change it.
• Draft, do not execute. The agent can draft a hold, a customer message or a suspicious-activity narrative; trained staff approve and submit.
• Hard limits outside the model. Any automatic release rule is enforced in code with clear criteria — risk score below a threshold, evidence complete, amount below a limit — and is monitored separately.
• Cited evidence. Every claim in a case summary links to the underlying record so reviewers can verify it quickly.
• Segregation of duties. The team that tunes agent prompts and thresholds is not the team that approves outcomes.
• Full audit trail. Store the alert, every tool call, the evidence retrieved, the recommendation, the reviewer’s decision and the reasons.
• Fairness checks. Monitor outcomes by customer segment to detect unjustified disparities.
• Kill switch. Disable the agent and revert to manual investigation instantly.

Adversarial risks specific to fraud

Fraudsters adapt, and agents introduce new attack surfaces:

• Prompt injection through data. A payment reference, merchant name or customer message could contain text designed to steer an agent. Treat all case data as untrusted content and never let it change the agent’s instructions or tools (OWASP LLM01).
• Evidence manipulation. If attackers learn which signals the agent weighs, they will fake them. Keep detection logic diverse and monitor for sudden shifts in agent recommendations.
• Over-reliance. If analysts accept recommendations without checking, errors propagate. Sample accepted cases for independent review and track agreement rates; a rate near 100% is a warning, not a success.
• Data leakage. Agents with broad read access can expose sensitive data in summaries. Scope tools to the case and redact what reviewers do not need.

Model risk management and governance

In US banking, model risk management guidance shapes how institutions build, validate and govern models. In April 2026 the Federal Reserve, OCC and FDIC issued SR 26-2, Revised Guidance on Model Risk Management, which supersedes SR 11-7 (2011) and emphasises a risk-based approach tailored to each organisation’s model risk profile. Its principles — sound development and documentation, independent validation, ongoing monitoring and effective governance — apply naturally to agents that influence fraud decisions.

In practice that means keeping an inventory entry for the agent and its components, documenting purpose, limitations and data, validating performance against labelled historical cases before use, monitoring precision, recall and agreement rates in production, and reviewing changes to prompts, tools or models through the same change process as other models. Outside the US, similar expectations come from banking supervisors and from AI regulation such as the EU AI Act; check which apply to your organisation.

What changes for analysts and team leads

Introducing an investigation agent changes the job, and the operating model needs to change with it:

• From gathering to judging. Analysts spend less time collecting screenshots and copying data, and more time weighing evidence and talking to customers. Training should focus on verifying cited evidence and spotting when a summary is incomplete.
• New quality assurance. Team leads sample agent-assisted decisions as they would sample analysts’ work, including cases where the analyst agreed with the agent.
• Feedback as a job. Analysts flag wrong facts, missing evidence and poor recommendations in a structured way. Those flags feed prompt, tool and evaluation-set improvements.
• Capacity planning. If investigation time per case falls, the same team can work more alerts — which allows thresholds to be lowered to catch more fraud. Decide deliberately whether to take the benefit as cost savings, better detection or faster customer outcomes.

Build, buy or extend

Fraud platforms and case-management vendors are adding AI assistants and agents to their products. Buying makes sense when your alerts, data and workflows already live in one vendor’s platform and its assistant can see the evidence analysts need. Building or extending makes sense when evidence is spread across in-house systems, when your typologies are specific to your products, or when you need full control over prompts, models, data residency and audit records. In either case, insist on the same things: read-only tools, cited evidence, structured outputs, evaluation on your own historical cases and a complete audit trail.

Implementation roadmap

Frequently asked questions

Can an AI agent block transactions in real time?

It should not be in the real-time path for most payment flows. Use fast risk models and rules for real-time decisions, and agents for the investigation that follows alerts.

Do agents replace fraud analysts?

No. They remove repetitive evidence gathering and writing so analysts can handle more cases and focus on complex ones. Decisions and accountability remain with people.

How do we know if the agent is getting worse?

Monitor recall and precision on confirmed outcomes, recommendation agreement rates and sampled quality reviews by fraud type. Re-run your evaluation set whenever prompts, tools or models change.

Can agents help with suspicious activity reports?

They can draft narratives from case evidence for an investigator to review, edit and submit. The filing decision and content remain the investigator’s responsibility.

What data do we need to start?

Historical alerts with confirmed outcomes, access to the systems analysts use during investigation, and documented investigation procedures. Labelled outcomes are essential for evaluation.