From Fraud Alert to Governed Action: Building an Agentic Fraud Investigation System with TigerGraph

A fraud detection model can tell you that a transaction looks suspicious.

It does not necessarily tell an investigator:

• Why is it suspicious?
• What other entities are connected to it?
• Is the evidence strong enough to act?
• What evidence is still missing?
• Should the system ask for more information?
• What action is actually allowed by policy?
• Who needs to approve that action?
• Can the investigation be remembered and used in a future case?

For Hacker House Goa '26 Task #4, we built HHGOA'26 — Agentic Fraud Investigation, a graph-grounded investigation system designed to answer those questions.

The core idea is simple:

Don't treat a fraud alert as a verdict. Treat it as the beginning of an investigation.

Our system takes an initial fraud signal, investigates the surrounding graph, gathers and classifies evidence, reasons about patterns and risk, detects uncertainty, requests additional evidence when that evidence can actually change the decision, reassesses the case, and finally produces a policy-governed Next Best Action.

The investigation is then persisted back into TigerGraph as institutional memory.

The Challenge

The challenge dataset is based on the IEEE-CIS Fraud Detection dataset from Vesta Corporation.

It contains approximately:

• 590,000 card transactions
• customer and identity information
• device and connection information
• historical closed investigations
• fraud policy information
• known fraud patterns
• regulatory references
• 20 benchmark cases

The benchmark intentionally does not provide a simple Is Fraud answer for each transaction.

That changes the problem.

We are not simply building a classifier.

We are building an investigation system.

The challenge asks the agent to investigate cases, gather evidence, identify fraud patterns, progress cases as new evidence arrives, recommend actions, and maintain the required investigation records.

The submission is also evaluated heavily on:

• investigation accuracy
• Next Best Action
• explainability
• agentic design
• engineering
• innovation
• demo quality

That led us toward an architecture where the graph is not just a visualization.

The graph is part of the reasoning process.

What We Built

Our investigation flow is:

The important part is that the investigation does not have to end after the first retrieval pass.

If the evidence is insufficient, the system can determine what additional information would be useful and whether obtaining that information could actually change the recommended action.

Why TigerGraph?

Fraud is fundamentally relational.

Consider a transaction:

A transaction that looks normal in isolation can look very different when viewed through its relationships.

For example:

The interesting signal is not necessarily inside one row.

It is in the relationship structure.

Our TigerGraph graph contains eight vertex types and fourteen edge types covering entities such as:

• Customer
• Card
• Transaction
• DeviceProfile
• EmailDomain
• BillingRegion
• ClosedCase
• InvestigationCase

The investigation uses GSQL and graph retrieval to traverse those relationships.

Examples include:

• transaction history
• device neighbors
• card activity windows
• transaction identity information
• device fraud-ring relationships
• historical closed cases
• previous agent investigations
• pattern and analyst-note retrieval

This gives the agent relationship-aware context rather than isolated records.

GraphRAG: Evidence Instead of Guessing

We use TigerGraph as the authoritative graph layer for investigation evidence.

The goal is not to ask an LLM to invent an explanation for a suspicious transaction.

Instead:

Every evidence item receives an identifier and a claim type.

We use three major categories:

Observed Fact

A fact directly retrieved from the underlying data.

Example:

50 previous transactions were retrieved for the card, with an average transaction amount of $109.08.

Derived Inference

A conclusion derived from multiple observed facts.

Example:

The device is shared across multiple cards and is associated with previous confirmed fraud cases.

Model Score

An upstream fraud-model signal.

Example:

The transaction received a real-time risk score of 0.90.

This separation matters because it prevents an inferred conclusion from being presented as if it were directly observed.

Every evidence item also retains its source/query reference.

The investigation can therefore answer:

"Why do you believe this?"

with:

"Here are the graph facts, the query that produced them, and the reasoning derived from those facts."

The Agentic Part

We deliberately avoided building a workflow where every case simply executes the exact same list of queries.

Our architecture uses a hybrid planner.

The planner is deterministic and state-aware.

It starts with baseline investigation tools and then chooses additional retrieval based on the open evidence gaps.

For example:

The exact tools depend on the current case state.

A device-related evidence gap can trigger device traversal.

An online-activity signal can trigger velocity analysis.

A new-region signal can trigger region-window analysis.

This means the investigation path can differ between cases.

Each plan is recorded in the case's plan trace, including:

• selected tools
• evidence gap
• rationale

That makes the investigation path auditable.

The LLM is optional in this architecture.

When configured, it is used for synthesis and narrative explanation rather than being given unrestricted control over critical tool selection or policy execution.

This was an intentional design choice.

For fraud investigation, we wanted the reasoning system to be flexible while keeping critical controls deterministic and auditable.

Risk Is Not Just One Number

Another design decision was to avoid treating the fraud probability as an unexplained black box.

We implemented an explainable Noisy-OR risk decomposition.

The overall fraud probability is built from multiple risk channels.

Examples include:

• transaction velocity
• network/card linkage
• device anomaly
• geolocation distance
• fraud-ring membership
• previous agent investigation memory
• additional evidence outcomes
• historical clearing signals

The investigator can therefore see not only:

Fraud Probability: 0.94

but also the evidence channels contributing to that assessment.

This is particularly useful when a case is borderline.

A probability of 0.53 should not look identical to a probability of 0.96.

The surrounding evidence matters.

The Most Important Part: Uncertainty

One of the strongest parts of the system is the uncertainty loop.

A common failure mode in automated decision systems is:

Risk score
   ↓
Decision

We wanted:

Risk
 ↓
Is the evidence sufficient?
 ↓
If not:
What information would actually change the decision?
 ↓
Request that evidence
 ↓
Reassess
 ↓
Decision

The system therefore evaluates candidate evidence requests.

Examples include:

• customer validation
• step-up authentication
• analyst information
• external watchlist information

But it does not automatically ask for everything.

Each candidate is evaluated using expected decision impact.

The system compares plausible outcomes and asks:

If we obtain this information, could the resulting decision actually change?

If the answer is effectively no, the request can be suppressed.

This prevents unnecessary evidence collection.

A Real Example: HHG-014

HHG-014 is a good example of why uncertainty matters.

The case involved transaction 3478561 for card C13487-K1.

The graph revealed:

• a new device for the account
• an anonymous/proxy connection
• the device shared across 19 other cards
• previous cases associated with the pattern
• multiple pieces of graph-derived evidence

The initial assessment was:

Fraud Probability: 0.528
Verdict: Uncertain
Pattern: card_not_present_new_device

The system did not simply convert the graph evidence into a fraud verdict.

Instead, it identified customer validation as the highest-value additional evidence request.

Its information value was calculated as:

1.00

The alternatives had lower information values:

Step-up authentication: 0.45
Analyst information:    0.45
External watchlist:     0.40

The customer response in the benchmark execution was:

No response received within the 24-hour window.

The system then reassessed the case.

The final state remained uncertain, and the recommended actions changed.

Initial recommendations included:

CREATE_CASE
FILE_REPORT
MONITOR_CONNECTED_CARDS

After the evidence loop:

MONITOR_CARD
DECLINE_TRANSACTION

with the appropriate approval route for the decline.

The important point is not that the system became more aggressive.

The important point is:

The recommendation changed because the state of the evidence changed.

That is the behavior we wanted from an agentic investigation system.

A Strong Fraud Case: HHG-006

HHG-006 demonstrates the opposite situation.

The graph showed:

• customer-reported unauthorized activity
• four online transactions within 48 hours
• a new device
• the device shared across 20 other cards
• prior confirmed fraud cases associated with the customer/card
• the same device appearing in confirmed fraud cases
• additional customer confirmation that the purchases were not theirs

The resulting fraud probability was:

0.96

The final action set included:

BLOCK_CARD
CREATE_CASE
FILE_REPORT
MONITOR_CONNECTED_CARDS

The policy engine routed the higher-impact actions through the required approval levels.

The system also generated the required SAR record.

This illustrates the difference between:

"the model thinks this is suspicious"

and:

"the investigation has gathered enough independent evidence
to justify a governed action."

Account Takeover: HHG-019

We also wanted the system to reason beyond a single predefined fraud pattern.

HHG-019 was identified as:

account_takeover

The investigation found:

• a new device
• multiple connected cards
• prior confirmed fraud cases for the customer/card
• the same device appearing in confirmed fraud cases
• customer confirmation that the transactions were unauthorized

The final fraud probability was:

0.94

The resulting actions included:

BLOCK_CARD
CREATE_CASE
FILE_REPORT
MONITOR_CONNECTED_CARDS

The graph allowed the system to connect the current transaction with historical behavior rather than evaluating the transaction independently.

Next Best Action Is Governed

Another important architectural decision was to separate:

AI recommendation

from:

policy enforcement

The agent can recommend an action.

It cannot simply execute whatever it recommends.

Our flow is:

Actions are categorized into permission levels.

Auto

Used for lower-impact actions such as:

• creating a case
• customer notification
• monitoring

L1

Requires analyst/team-lead authorization.

Examples include transaction declines and card-blocking actions depending on policy conditions.

L2

Requires higher-level fraud/compliance authorization.

Examples include certain SAR/reporting actions.

The approval decision is revalidated against policy when the decision is made.

The system records audit events such as:

approval_granted
action_executed
approval_rejected

This creates a separation between:

what the agent recommends

and

what the organization permits.

Case Memory

A fraud investigation should not disappear when the case ends.

We therefore persist completed investigations as InvestigationCase vertices in TigerGraph.

The case is connected to relevant entities such as:

• customer
• card
• transaction
• device

Future investigations can retrieve previous agent investigations.

That means the system has a memory loop:

This is particularly valuable in fraud because repeated patterns often emerge across seemingly unrelated transactions.

Fail-Closed Graph Operation

One of the engineering requirements we considered important was preventing the UI from claiming that an investigation was performed against TigerGraph when the graph backend was actually unavailable.

In strict mode:

STRICT_GRAPH_BACKEND=1

the system fails explicitly if the authoritative TigerGraph backend cannot be reached.

It does not silently replace live graph evidence with mock data while presenting the investigation as successful.

For a competition demo, this distinction matters.

A graph investigation should either be grounded in the graph or clearly report that the graph is unavailable.

The Analyst Command Center

The backend is only half of the product.

We built an analyst-facing command center that exposes the investigation as a visual story.

The interface presents:

• trigger context
• investigation progression
• fraud probability
• detected patterns
• graph topology
• evidence and provenance
• uncertainty
• risk decomposition
• governed NBA
• approval state
• case memory
• benchmark validation

The graph is designed to answer a simple question visually:

Why is this transaction connected to suspicious activity?

Rather than forcing an analyst to understand raw graph-schema names, the visualization emphasizes:

The final visual direction uses a restrained Hacker House Goa-inspired dark-green and beige palette while keeping the interface focused on investigation rather than turning it into a festival landing page.

Benchmark Results

We evaluated the complete pipeline against the official 20-case benchmark.

The repository's benchmark report records:

Testing the System

The repository's technical validation reports:

228 tests
228 passed
0 failed
0 skipped

The test suite covers areas including:

• API behavior
• frontend/API integration
• graph backends
• GraphRAG
• LLM layer
• MCP client
• investigation hardening
• policy approval
• live TigerGraph agent behavior
• evidence provenance
• data models
• NBA explanations
• pattern reasoning
• policy engine

We also validated the application through browser-based end-to-end testing.

The tested behaviors include:

• live investigation execution
• investigation progression
• evidence provenance
• Noisy-OR decomposition
• uncertainty and reassessment
• NBA governance
• approval gating
• graph interaction
• node inspection
• responsive layouts
• browser console health

What We Learned

1. A graph is most useful when the investigation needs relationships

A fraud transaction by itself contains limited context.

The relationships around it can contain much more useful evidence.

TigerGraph made those relationships directly queryable as part of the investigation.

2. More evidence is not always better

An agent that keeps asking questions is not necessarily intelligent.

The important question is:

Will this evidence change the decision?

That led us to implement information-value-based evidence requests.

3. Risk and action should be separated

A high risk score does not automatically mean:

BLOCK CARD

The action also depends on:

• evidence
• uncertainty
• policy
• exposure
• approval requirements

Keeping risk assessment and policy enforcement separate made the architecture easier to audit.

4. Agentic systems need stopping criteria

An investigation should not continue forever.

We implemented stopping conditions around:

• sufficient confidence
• uncertainty
• evidence availability
• information value
• maximum investigation rounds

The objective is not maximum retrieval.

The objective is:

Enough evidence to make a defensible decision.

5. Memory needs to be part of the graph

If previous investigations are disconnected from current investigations, the system repeatedly solves the same problem.

Persisting InvestigationCase back into TigerGraph allows future investigations to use previous cases as structured evidence.

6. Deterministic controls are valuable in high-impact workflows

We deliberately kept critical tool-planning and policy decisions controlled rather than giving an LLM unrestricted authority.

The system can use AI for synthesis and explanations while deterministic components handle:

• evidence calculations
• policy evaluation
• permission routing
• approval enforcement
• persistence rules

This gives us a useful balance between flexibility and control.

What We Would Improve With More Time

The current system is a competition prototype, not a production fraud platform.

There are several areas we would improve.

1. More diverse fraud patterns

The benchmark contains a finite set of cases and documented patterns.

A production system would need broader coverage of:

• emerging fraud typologies
• cross-account attacks
• mule networks
• synthetic identities
• coordinated campaigns

2. More external evidence sources

The current system focuses heavily on TigerGraph and controlled investigation evidence.

A production deployment could integrate additional:

• identity signals
• authentication telemetry
• device intelligence
• merchant information
• threat intelligence
• external watchlists

3. Better graph visualization

The current graph demonstrates the topology, but a production analyst interface could provide:

• semantic graph layouts
• relationship filtering
• temporal graph playback
• fraud-ring highlighting
• path explanations
• saved investigation views

4. More sophisticated action optimization

The current NBA system is policy-governed and benchmarked.

A future version could optimize actions using:

• expected financial loss
• customer friction
• operational cost
• intervention success rate
• historical action outcomes

while still keeping policy enforcement independent.

5. Production-grade authentication and deployment

The competition prototype focuses on the investigation workflow.

A production version would require:

• identity and access management
• role-based permissions
• audit retention
• secrets management
• deployment automation
• observability
• high availability
• data governance
• compliance controls

The Architecture in One Picture

The entire system can be summarized as:

Final Takeaway

The biggest lesson from building this system was that fraud investigation is not simply a classification problem.

It is a reasoning problem over connected evidence under uncertainty and policy constraints.

The system needs to know:

What happened?
      ↓
What is connected?
      ↓
What evidence supports it?
      ↓
What is still uncertain?
      ↓
What information would resolve that uncertainty?
      ↓
How does the decision change?
      ↓
What action is appropriate?
      ↓
Is that action permitted?
      ↓
Who must approve it?
      ↓
What should the system remember?

That is the role we designed TigerGraph to play.

The graph provides the connected context.

The investigation engine determines what to investigate.

The evidence layer makes the reasoning traceable.

The uncertainty loop determines when more information is valuable.

The policy engine constrains actions.

The approval layer keeps humans in control of consequential decisions.

And TigerGraph becomes more than a database: it becomes the persistent memory and relationship layer of the investigation system.

Fraud detection gives you a signal.

Investigation turns that signal into evidence.

Agentic reasoning turns evidence into a decision.

Governance turns the decision into a controlled action.

Project

HHGOA'26 — Agentic Fraud Investigation

Task #4 — TigerGraph Agentic Fraud Investigation + Next Best Action

Built with:

• TigerGraph Savanna Cloud
• GSQL
• GraphRAG
• Python
• FastAPI
• HTML/CSS/JavaScript
• D3.js
• SQLite
• pytest

The complete implementation, benchmark artifacts, architecture documentation, demo walkthrough, and test suite are available in the project repository.

Repository: github.com/shaikmohammedyasin-create/HHGoa26-Agentic-Fraud-Investigation

Acknowledgements

This project was built for Hacker House Goa '26 and the TigerGraph Agentic Fraud Investigation challenge.

The challenge gave us an opportunity to explore what happens when graph databases, agentic investigation, evidence-driven reasoning, uncertainty handling, and policy governance are combined into one workflow.

The result is not intended to replace human investigators.

It is designed to give them a better investigation trail:

connected evidence, explicit uncertainty, governed actions, and persistent memory.

© 2026 SK MD Yasin. All rights reserved.

This article and the accompanying HHGOA'26 — Agentic Fraud Investigation project were created for the Hacker House Goa '26 TigerGraph Agentic Fraud Investigation challenge. Content, architecture diagrams, and case examples are original work unless otherwise credited. Third-party trademarks (TigerGraph, IEEE-CIS, Vesta, etc.) belong to their respective owners and are referenced here for descriptive purposes only.