From Suspicious Transaction to Action: Building an Agentic Fraud Investigator with TigerGraph

Shreya Pandey — Thu, 24 Sep 2026 23:55:09 +0000

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.

DEV Community: Shreya Pandey