How to Investigate First-Party Fraud and Friendly Fraud Disputes with AI Agents
Build an AI agent that spots first-party fraud in card disputes: serial disputers, prior undisputed use, and authenticated purchases, with evidence for the analyst and no auto-denials.
First-party fraud is a judgment problem. The customer is real, the card is theirs, and the question is whether they made the purchase they now dispute. Volume makes it worse: every claim gets the same rushed look, honest customers get treated like fraudsters, and serial disputers get paid.
The fix is not a stricter rule. It is giving the analyst the full picture on every claim, quickly.
This is a guide to building a first-party fraud investigation agent with Claude Code or Codex and running it in Runtime. The agent assembles the evidence on each dispute. The analyst decides.
The short answer. For every unauthorized or not-received claim, have the agent pull authentication results, device and IP history, prior use of the same merchant, delivery data, login activity, and the customer's dispute history. It writes a short finding: what supports the claim, what contradicts it, and a recommendation. It never denies on its own.
The signals
| Signal | Points to first-party use when |
|---|---|
| Authentication | 3DS challenge passed, PIN entered, or wallet token on the customer's own device |
| Device and IP | Same device fingerprint or IP as the customer's usual logins |
| Merchant history | Prior undisputed purchases with the same merchant, same card |
| Delivery | Delivered to the customer's address on file, with proof |
| Account activity | Login or app session minutes before the purchase |
| Dispute history | Earlier disputes later found to be authorized |
Visa's Compelling Evidence 3.0 uses the same idea on card-not-present fraud claims: two prior undisputed transactions with matching data such as IP, device, or shipping address. The agent should look for that pattern on every card-not-present claim.
What it does, and what it is not
What it does. Builds a timeline of the disputed purchase and everything around it, scores each signal for and against the claim, writes the finding in plain language, and links every source.
What it is not. An auto-deny rule. Every material improvement comes from a human questioning a premise. Plan for that.
How it runs in Runtime
claim-contextReads the claim and the customer's dispute history, including earlier outcomes.
auth-and-devicePulls 3DS, PIN, wallet, device, and IP data for the disputed purchase and the customer's usual sessions.
merchant-historyFinds prior undisputed purchases with the same merchant and checks for matching IP, device, or address.
findingWrites what supports and contradicts the claim, a recommendation, and every source, for the analyst.
- Case tool
- Card processor
- Warehouse
- Slack
Create a banking ops agent that handles RFIs, hold-harmless requests, and returns of funds from our partner bank, verifies against our ledger, and drafts replies for my approval.
bank-ops-agent
Tools picked from your prompt
Step 1: Write down how your best analyst decides
List the signals your team trusts, how much each one counts, and the cases where you pay anyway, such as a first dispute from a long-standing customer under a set amount. Two habits help:
- Say why, not just what. "A passed 3DS challenge matters because the customer had to approve it on their own device."
- Name the failure you're preventing. "Never recommend denial on dispute history alone. Honest customers have bad months."
Step 2: Ask the agent to build it
Build a first-party fraud investigation agent from the procedure in this repo. For each unauthorized or not-received claim, pull authentication, device and IP, prior merchant history, delivery, login activity, and dispute history. List the evidence for and against the claim with a link to each record, then recommend pay, investigate further, or deny with reasons. If a source is missing, say so. Never deny, reverse credit, or contact the customer.
Step 3: Run it next to your analysts
Run in draft-only mode for two weeks on closed claims, then on live ones. Compare the agent's recommendation with the analyst's decision, and read every disagreement. Those disagreements are where the procedure improves.
What stays human, permanently
| Step | Why |
|---|---|
| Deny or pay | A customer's money and a regulated decision. |
| Closing or restricting the account | It affects the whole relationship, not one claim. |
| Calling a pattern fraud | Patterns suggest; evidence decides. |
Lessons that cost the most
- Separate friendly fraud from first-party fraud. A forgotten subscription needs an explanation, not a denial.
- History is context, not proof. Use it to look harder.
- Show both sides. A finding that only lists reasons to deny trains analysts to deny.
- Feed outcomes back. Representment wins and losses tell you which signals actually hold up.
Measuring it
Track analyst minutes per claim, agreement between recommendation and decision, chargeback win rate on claims the agent prepared, and complaints from customers whose claims were denied. Watch the last one closely.
For deadlines and letters, see how to automate Reg E dispute investigations. For vendors, see the best AI dispute management software.
Frequently asked questions
What is first-party fraud in disputes?
First-party fraud is when the account holder disputes a transaction they made or authorized, then claims it was unauthorized or not received. Friendly fraud is often used for the same thing, though some teams reserve it for honest mistakes, such as a forgotten subscription or a family member's purchase. The difference matters because the right response is different.
Can you deny a Reg E claim for suspected first-party fraud?
Only on the evidence. Reg E lets you conclude no error occurred after a reasonable investigation, for example when the customer authenticated the purchase or used the same merchant and device before without disputing. A pattern alone, such as many prior disputes, is a reason to look harder, not a reason to deny.
What evidence points to first-party fraud?
A passed 3DS challenge or PIN, a transaction from the customer's usual device and IP, prior undisputed purchases with the same merchant, delivery to the customer's address, logins around the time of purchase, and a history of disputes that were later found to be authorized.
Should an AI agent auto-deny suspected first-party fraud?
No. Auto-deny rules catch honest customers and create regulatory risk. Have the agent assemble the evidence and a recommendation, and have an analyst make the call.
The point
First-party fraud is decided by evidence, not volume. An agent that puts the evidence in front of the analyst on every claim makes the honest customer's claim faster and the serial disputer's harder.
Back to judging.
