git repo: https://github.com/Shreya860/-Agentic-Fraud-Investigation.git
Introduction
Fraud detection is not just about identifying a suspicious transaction.
When a transaction is flagged, a real fraud investigator needs to answer several questions:
1.Why is this transaction suspicious?
2.What other transactions are connected to the customer?
3.Are there suspicious devices, cards, or identities involved?
4.Is there evidence of a known fraud pattern?
5.Is the available evidence strong enough to take action?
6.Should the transaction be blocked, monitored, verified, or escalated?
7.Does the proposed action require approval?
For the TigerGraph Agentic Fraud Investigation HHGOA challenge, we built an AI-powered agentic fraud investigation system that attempts to answer these questions through a structured investigation workflow.
Our goal was to move beyond simple fraud scoring and build a system that can investigate evidence, reason about uncertainty, identify relationships, and recommend a policy-aware next-best action.
The Problem
Traditional fraud detection systems often produce a risk score indicating that a transaction may be suspicious.
However, a risk score alone does not provide enough context for an investigator.
For example, a transaction with a moderate risk score could be:
- a legitimate purchase,
- part of a card-testing attack,
- associated with a new device,
- connected to suspicious activity on another card,
- or part of a larger coordinated fraud pattern.
This means that an investigation requires context and relationships, not just individual transaction records.
That is where our approach comes in.
Our Solution
We built an Agentic Fraud Investigation Agent that follows an investigation workflow rather than immediately making a decision.
The system follows this general process:
Fraud Signal
↓
Investigation
↓
Evidence Gathering
↓
Relationship Analysis
↓
Fraud Pattern Analysis
↓
Risk & Uncertainty Assessment
↓
Historical Memory
↓
Next-Best Action
↓
Policy Check
↓
Decision / Escalation
The agent can investigate a customer and flagged transaction, gather relevant evidence, identify suspicious patterns, evaluate uncertainty, and recommend an action.
The important idea is that the agent does not treat the initial fraud signal as the complete investigation.
Why We Used TigerGraph?
Fraud is fundamentally a relationship problem.
A transaction is connected to a customer.
The customer is connected to cards.
Cards are connected to transactions.
Transactions can involve devices and identities.
Devices can potentially connect multiple customers or cards.
Representing these relationships as a graph makes it possible to investigate connections that are difficult to understand from isolated rows in a traditional table.
We created a dedicated:
FraudInvestigationGraph
with entities including:
- Customer
- Transaction
- Card
- Identity
- Device
- FraudCase
- HistoricalCase and relationships such as:
- Customer → Transaction
- Transaction → Card
- Transaction → Identity
- Transaction → Device
- FraudCase → Transaction
- FraudCase → Customer
- HistoricalCase → Customer
This gives the investigation agent a graph-based view of the evidence surrounding a suspicious event.
Agentic Investigation
The core of our system is the investigation workflow.
When a benchmark case is triggered, the agent investigates the customer and flagged transaction instead of immediately producing a binary fraud result.
It gathers information such as:
- flagged transaction details
- transaction history
- high-risk transactions
- transaction channels
- customer activity
- device-related information
- connected entities
- suspicious patterns
- historical investigation context
- uncertainty and missing evidence
The investigation then feeds this information into the assessment and planning stages.
Fraud Pattern Analysis
Our system includes a dedicated fraud pattern analysis component.
It looks for patterns including:
Card Testing
Multiple small transactions or authorization attempts followed by a larger transaction can indicate card-testing behavior.
Card-Not-Present Fraud
The system analyzes transaction characteristics and risk signals to identify suspicious card-not-present activity.
Card-Not-Present New Device
A suspicious card-not-present transaction associated with a new or unusual device can provide additional evidence.
Out-of-Region Use
Unexpected geographic or regional transaction behavior can provide another fraud signal.
Account Takeover
The system can consider changes and unusual behavior associated with customer activity when investigating potential account compromise.
The pattern analysis is used as one part of the overall investigation rather than being treated as the only source of truth.
**Evidence and Uncertainty
**
One of the important parts of our implementation is that the agent explicitly represents uncertainty.
A fraud investigation should not automatically become a blocking decision simply because one signal looks suspicious.
The system therefore keeps track of evidence such as:
- high-risk transaction activity
- unusual device activity
- connected entities
- customer validation availability
- step-up authentication availability
- historical matches
- other supporting or missing evidence
For example, when the available evidence is not conclusive, the agent can recommend:
VERIFY_WITH_CUSTOMER
instead of immediately taking a stronger action.
This makes the investigation process more explainable and policy-aware.
Policy-Aware Decision Making
Another major component of our system is the decision engine.
The agent does not simply choose an action based on a risk score.
It considers the investigation result and maps it to actions defined by the HHGOA policy.
Our system supports actions such as:
ALLOW_TRANSACTION
-
DECLINE_TRANSACTION
-
MONITOR_CARD
-
MONITOR_CONNECTED_CARDS
-
WARN_CUSTOMER
-
VERIFY_WITH_CUSTOMER
-
STEP_UP_AUTH
-
BLOCK_CARD
-
BLOCK_ALL_CARDS
-
CREATE_CASE
-
GENERATE_REPORT
-
FILE_REPORT
-
ESCALATE_TO_ANALYST
-
CLOSE_NO_FRAUD
The system also tracks whether an action requires approval and the corresponding approval route.
This gives the agent a controlled decision-making layer rather than allowing unrestricted actions.
Investigation Memory
Fraud investigations can become more useful when previous cases are available as context.
Our system includes a memory component that stores and retrieves investigation information so that previous cases can contribute to future investigations.
This allows the architecture to move toward a system where the agent can reason not only about the current transaction, but also about patterns observed during previous investigations.
Benchmark Evaluation
We tested our complete investigation pipeline against the 20 HHGOA benchmark cases.
The benchmark contains cases such as:
- risk-score triggered investigations
- customer-reported cases
- analyst-requested investigations
For each case, the system runs the investigation workflow and generates an individual JSON result.
The final repository contains:
cases/
├── HHG-001.json
├── HHG-002.json
├── HHG-003.json
├── ...
└── HHG-020.json
We also generate the consolidated benchmark output:
evaluation/
└── benchmark_results.json
The benchmark pipeline successfully processes all 20 cases.
What Makes Our Approach Agentic?
The key difference between our system and a simple fraud classifier is the investigation workflow.
Instead of:
Transaction → Risk Score → Fraud / Not Fraud
our approach is:
Transaction
↓
Investigate
↓
Gather Evidence
↓
Analyze Relationships
↓
Identify Patterns
↓
Assess Risk
↓
Assess Uncertainty
↓
Determine Whether More Evidence Is Needed
↓
Plan Next Action
↓
Apply Fraud Policy
↓
Recommend Action
This allows the system to provide both a decision and the reasoning context behind that decision.
Technology Stack
Our implementation combines several technologies:
TigerGraph
- Fraud investigation graph
- Relationship analysis
- Customer, transaction, device, card and identity relationships
Python
- Investigation orchestration
- Evidence processing
- Pattern analysis
- Risk assessment
- Decision engine
- Benchmark execution
CSV / Data Processing
- Transaction data
- Customer and identity information
- Benchmark case data
- Historical investigation information Agent Architecture
- Investigator
- Evidence gathering
- Pattern analyzer
- Assessment
- Memory
- Planning
- Decision engine
Frontend
- Investigation-oriented user interface
- Fraud investigation results
- Visualization of project functionality
**Challenges We Faced
**
One of the biggest challenges was connecting different parts of the system into a single investigation workflow.
We had to make sure that:
- Data could be loaded and accessed correctly.
- TigerGraph represented the required relationships.
- Python could communicate with the graph.
- The investigation could gather useful evidence.
- Evidence could be transformed into meaningful findings.
- Uncertainty was explicitly represented.
- Actions followed the HHGOA policy.
- The complete workflow could run across all 20 benchmark cases.
Another important challenge was avoiding decisions based on a single signal.
Fraud investigation requires combining multiple pieces of evidence, which is why the system was designed around investigation, assessment and policy-aware decision making.
**What We Learned
**
Building this project taught us that fraud investigation is fundamentally different from simple fraud classification.
A model can tell us:
"This transaction has a high risk score."
But an investigator needs to know:
"What evidence supports that risk, what other entities are connected to it, what uncertainty remains, and what action should be taken according to policy?"
We also learned the importance of:
- graph-based relationship analysis
- explainable evidence
- explicit uncertainty
- policy-controlled actions
- investigation memory
- structured agent workflows
- reproducible benchmark evaluation
**Future Improvements
**
Although the current system is complete for the hackathon, there are several directions we could explore further:
- deeper graph algorithms for fraud-network detection
- more advanced historical-case matching
- richer GraphRAG capabilities
- expanded TigerGraph MCP integration
- improved investigation visualizations
- stronger automated evaluation metrics
- real-time fraud investigation pipelines
- more sophisticated multi-agent investigation workflows
Conclusion
Our project started with a simple question:
What if an AI system could investigate a suspicious transaction instead of simply labeling it?
We built an agentic fraud investigation workflow that combines TigerGraph relationships, transaction evidence, fraud-pattern analysis, risk assessment, uncertainty handling, investigation memory, planning, and policy-aware decisions.
The result is a system designed to move from:
"This transaction looks suspicious."
to:
"Here is the evidence, here are the relationships and uncertainties, and here is the next action supported by the investigation policy."
For us, that is the value of an agentic approach to fraud investigation.
Investigate first. Understand the evidence. Then act.
Top comments (0)