Building an Agentic Fraud Investigation System with TigerGraph
From a Risk Score to a Defensible Fraud Decision
Fraud investigation is rarely a simple classification problem.
A suspicious transaction can be triggered by a high risk score, but the score alone does not explain what happened, which entities are connected, whether the activity matches a known fraud pattern, what evidence is still missing, or what the investigator should do next.
For Hacker House Goa, we built an Agentic Fraud Investigation System powered by TigerGraph that treats fraud investigation as a continuously evolving workflow rather than a one-time prediction.
The system starts from an investigation trigger, gathers evidence from connected transaction and entity relationships, evaluates uncertainty, requests additional evidence when necessary, recommends policy-aware next actions, explains those decisions, and stores the completed investigation as case memory for future investigations.
The core idea was simple:
A fraud signal should start an investigation, not end it.
What We Built
Our solution is an analyst-facing fraud investigation console backed by an agentic investigation workflow.
The system supports the complete investigation lifecycle:
Trigger → Investigate → Gather Evidence → Assess Uncertainty → Gather More Evidence → Take Action → Explain → Update Memory
The agent can be triggered by:
- A fraud risk score
- A customer report
- A fraud analyst request
Once triggered, the agent creates or opens a case and investigates the relevant transactions, cards, customers, devices, regions, and historical cases.
Instead of relying on a single model output, the agent builds a case from multiple independent evidence sources.
The final decision can result in actions such as:
- Allowing or declining a transaction
- Monitoring or blocking a card
- Warning a customer
- Creating a fraud case
- Requesting additional verification
- Filing a report
- Escalating to an analyst
The important part is that the agent does not simply return an action. It also records why that action was selected, what evidence supported it, what uncertainty remained, and whether human approval is required.
Why TigerGraph?
Fraud is fundamentally relational.
A transaction is rarely suspicious in isolation. The useful signal can exist several hops away:
Customer → Card → Transaction → Device → Other Cards → Other Transactions → Prior Cases
This makes a graph database a natural fit for fraud investigation.
TigerGraph became the relationship and investigation layer of our architecture.
We use the graph to represent entities and relationships such as:
- Customers
- Cards
- Transactions
- Device profiles
- Email domains
- Billing regions
- Closed fraud cases
- Active investigation cases
Relationships include connections such as:
OWNS, MADE, FROM_DEVICE, PURCHASER_EMAIL, BILLED_IN, INVOLVES, ON_CARD, CONNECTED_TO, USES_DEVICE
This allows the investigation agent to move from a flagged transaction to its surrounding context instead of looking at a flat row of transaction data.
TigerGraph's graph capabilities are used for:
- Graph traversal
- Relationship analysis
- Fraud pattern detection
- Connected-entity investigation
- Prior-case retrieval
- Case memory
The challenge specification also requires GSQL and TigerGraph graph algorithms for investigation and pattern analysis, together with TigerGraph MCP and GraphRAG for exposing graph capabilities to the agent and grounding its reasoning.
High-Level Architecture
Our architecture can be thought of as five major layers.
┌─────────────────────────────┐
│ Analyst Console │
│ React + TypeScript + UI │
└──────────────┬──────────────┘
│
▼
┌─────────────────────────────┐
│ Agent Orchestrator │
│ Investigation + Reasoning │
└──────────────┬──────────────┘
│
┌───────────────────┼───────────────────┐
│ │ │
▼ ▼ ▼
TigerGraph MCP GraphRAG Policy Engine
│ │ │
└───────────────────┼───────────────────┘
▼
┌─────────────────────────────┐
│ TigerGraph │
│ Graph + relationships │
│ + case memory │
└──────────────┬──────────────┘
│
▼
┌─────────────────────────────┐
│ Dataset + Policies + Cases │
│ Transactions / Devices │
│ Historical investigations │
└─────────────────────────────┘
The frontend was designed as a separate layer around a stable interface contract, allowing the investigation engine and UI to be developed independently and joined later. The static version reads generated JSON artifacts, while the architecture also supports a live API mode.
The Investigation Agent
The central component is the investigation agent.
Instead of using the LLM as a replacement for fraud analytics, we use it as the reasoning and orchestration layer.
The agent decides:
- What should be investigated next?
- Which tool or graph query should be executed?
- What evidence does the returned information provide?
- Is the current evidence sufficient?
- Should more evidence be requested?
- What action is allowed by policy?
- Does the action require human approval?
- When should the investigation stop?
- How should the final reasoning be explained?
This separation was important.
The graph performs structured relationship analysis.
The agent performs reasoning and tool selection.
The policy layer determines what actions are permissible.
The UI makes the complete investigation auditable.
TigerGraph MCP as the Agent's Graph Interface
A major part of the design is the use of TigerGraph MCP.
Instead of giving the model unrestricted access to the underlying graph, graph capabilities are exposed through controlled tools.
The agent can invoke investigation operations such as:
- Looking at transaction windows
- Finding connected devices
- Discovering related cards
- Traversing relationships
- Retrieving historical cases
- Collecting graph evidence for the current case
This creates a tool-driven investigation loop:
Agent
↓
Select investigation tool
↓
TigerGraph MCP
↓
TigerGraph query / traversal
↓
Structured result
↓
Agent evaluates evidence
↓
Next tool or action
This is important because the graph remains the source of structured evidence instead of forcing the LLM to infer relationships from raw text.
GraphRAG for Evidence-Grounded Reasoning
Graph data alone is not enough for a real fraud investigation.
The agent also needs contextual information such as:
- Fraud policies
- Known fraud patterns
- Investigation procedures
- Regulatory references
- Historical case outcomes
We therefore use a GraphRAG-style approach to combine connected graph evidence with relevant contextual information.
Instead of passing large amounts of unrelated data to the model, the system retrieves the most relevant context and gives the agent a focused evidence package.
Conceptually:
Graph relationships
+
Transaction evidence
+
Prior cases
+
Fraud policy
+
Fraud pattern context
↓
Relevant investigation context
↓
Agent reasoning
↓
Next best action
This keeps the LLM grounded in evidence while allowing it to reason over the investigation state.
Policy-Aware Decision Making
One of the hardest parts of the project was making the agent capable of acting under constraints instead of simply producing a classification.
We implemented an explicit policy-driven decision model.
For example, the policy includes thresholds for:
- When verification is required before blocking
- When a customer confirmation closes a case
- When no response should result in monitoring or escalation
- How card-testing patterns should be handled
- How shared devices and connected cards should be handled
- When an uncertain case should be escalated
- When a report should be filed
- Which actions require L1 or L2 approval
The agent therefore does not operate as:
Fraud = Yes → Block
Instead, the flow becomes:
Evidence
↓
Risk + Uncertainty
↓
Applicable policy rules
↓
Allowed actions
↓
Approval route
↓
Recommended / executed action
This was essential for making the system explainable and safe to operate.
The documented policy model separates automatic actions from L1 and L2 approval routes, including explicit rules for blocking cards, filing reports, handling uncertainty, and stopping investigations.
The Agent Can Change Its Mind
One of the most important design decisions was making the investigation explicitly stateful.
A case can begin as uncertain.
New evidence can increase or decrease the fraud probability.
The agent can request more evidence.
The customer response can change the decision.
The final recommended actions can therefore be different from the initial recommendation.
The frontend makes this transition visible through a Before vs After action comparison.
For example:
INITIAL
DECLINE_TRANSACTION
VERIFY_WITH_CUSTOMER
↓
More evidence
↓
Customer denies transaction
Shared device discovered
Policy conditions satisfied
↓
FINAL
BLOCK_CARD
CREATE_CASE
FILE_REPORT
MONITOR_CONNECTED_CARDS
This makes the agentic behaviour visible instead of hiding the entire process behind a final answer.
The frontend contract explicitly models initial and final actions and requires the final action state to match the final recommendation in the answer file.
Evidence Is First-Class Data
Every important conclusion is tied back to evidence.
An evidence record contains information such as:
- The claim
- Evidence source
- Query or document reference
- Related entity IDs
- Evidence family
- Direction toward fraud, legitimate activity, or neutral evidence
- Contribution to the probability update
This gives us a traceable chain:
Claim
↓
Evidence
↓
Source / Query
↓
Graph entities
↓
Risk update
↓
Policy decision
↓
Action
The UI exposes this evidence directly rather than displaying a black-box explanation.
A Concrete Investigation Example
The documented reference fixture demonstrates the complete flow using a card-testing scenario.
The case begins with a risk-score trigger:
Transaction: T0412883
Amount: $259.98
Risk score: 0.72
At the start, the investigation probability is represented as 0.50 and the case is uncertain.
The graph investigation then discovers:
- Three online authorizations under $3
- The activity occurring within a short time window
- A larger purchase following those authorizations
- A product code the card had not previously used
This becomes a graph-backed card-testing evidence event.
The probability moves to 0.65.
The investigation then continues with graph-based device-neighbour analysis and additional evidence gathering.
In the documented fixture, the case ultimately reaches:
Fraud probability: 0.86
Exposure: $264.43
Affected transactions: 4
Tool calls: 9
Latency: 18.7 seconds
The final actions represented in the fixture are:
- BLOCK_CARD
- CREATE_CASE
- FILE_REPORT
- MONITOR_CONNECTED_CARDS
The fixture also demonstrates approval routing, with blocking requiring L1 approval and filing the report requiring L2 approval.
These numbers are from the documented reference case, not an aggregate result across the full benchmark.
Case Memory
Fraud investigations should not start from zero every time.
Once an investigation is completed, the important findings, actions, outcomes, and relationships become part of the case memory.
A future investigation can retrieve similar historical cases and use them as additional context.
The graph therefore serves two purposes:
Investigation graph
Used to understand the current suspicious activity.
Case memory graph
Used to connect the current investigation with previously resolved cases and recurring patterns.
This allows the system to reason over patterns that span multiple customers, cards, devices, and historical cases.
Frontend: The Fraud Investigation Console
We built the frontend as an analyst-oriented investigation workspace rather than a generic chatbot.
The console is designed around a central principle:
Show the investigation changing over time.
The main screens include:
Case Queue
Provides a high-level view of all investigations, including:
- Verdict
- Fraud probability
- Trigger type
- Exposure
- Pattern
- Final actions
- Reports
- Approval requirements
Case Workspace
The main investigation screen combines:
- Workflow stepper
- Trigger information
- Event timeline
- Evidence
- Transactions
- Graph view
- Prior cases
- Suspicious Activity Report
- Decision panel
- Approvals
Replay Mode
The complete investigation can be replayed event by event.
This allows the demo to show:
Trigger
↓
Investigation
↓
Evidence
↓
Probability update
↓
Evidence request
↓
Customer response
↓
Updated recommendation
↓
Approval
↓
Memory update
The frontend architecture uses a static-first data model so that the demo remains usable without depending on a live backend connection.
Why We Chose a Static-First Demo Architecture
For a fraud investigation demo, a broken backend connection can completely destroy the story.
So we deliberately designed the console to work from recorded investigation traces.
The backend produces structured artifacts for:
- Cases
- Investigation traces
- Graph subgraphs
- Prior cases
- Metrics
The frontend then reads those artifacts directly.
A live API can be connected when available, but the recorded trace provides a deterministic fallback.
This means the exact same investigation can be replayed consistently during a demo.
The architecture supports both static data files and live HTTP/SSE execution through a common data interface.
Technology Stack
The main stack behind the system includes:
Graph & Investigation
- TigerGraph
- GSQL
- TigerGraph graph capabilities
- TigerGraph MCP
- GraphRAG
Agent Layer
- Agent orchestration
- Tool calling
- Evidence synthesis
- Policy-aware reasoning
- Case memory
Frontend
- React
- TypeScript
- Vite
- Tailwind CSS
- Zustand
- Cytoscape.js
- Recharts
- Zod
The frontend architecture was specifically designed for deterministic graph rendering, investigation replay, evidence visualization, and validation against the backend interface contract.
Engineering the Investigation Trace
We did not want the frontend to guess how the agent reached a conclusion.
Instead, the backend trace records each investigation event.
A trace contains:
- Step
- Event type
- Timing
- Tool invocation
- Evidence
- State snapshot
- Recommendation changes
- Approval records
Every event also carries the current state of the investigation.
This made the UI significantly simpler because the frontend can render any point in the investigation directly from the selected event rather than reconstructing the entire state through complicated reducer logic.
The same trace powers:
- Static viewing
- Replay mode
- Live streaming
- Probability timelines
- Evidence history
- Before/After action comparison
The documented architecture explicitly uses a snapshotAt() model and an diffActions() function to keep all three modes consistent.
What We Learned
1. Fraud detection is a graph problem
A suspicious transaction can only tell part of the story.
The strongest clues often come from relationships between transactions, cards, devices, customers, and historical cases.
2. An agent needs tools, not just prompts
A language model becomes much more useful when it can investigate through structured tools.
Instead of asking the model to "figure out the fraud", we give it controlled access to evidence and let it decide what to investigate next.
3. Uncertainty is a feature
A strong fraud agent should know when it does not have enough evidence.
The correct behaviour is sometimes:
Ask → Verify → Reassess
rather than immediately blocking an account.
4. Explainability must be designed into the architecture
Explainability cannot simply be added after the model produces its answer.
We therefore made evidence, policy references, tool calls, uncertainty, approvals, and action changes first-class parts of the investigation record.
5. Deterministic replay is extremely valuable
For a complex agentic system, reproducibility matters.
Recorded traces allow the investigation to be demonstrated exactly as it occurred while still keeping the architecture ready for live execution.
What We Would Improve Next
With more development time, we would extend the system in several directions.
Larger-scale graph investigation
The graph could be expanded with more entity types and deeper relationship analysis to uncover more complex fraud rings.
Better case retrieval
Case memory could evolve into a stronger semantic retrieval layer combining graph similarity with vector-based historical case retrieval.
More sophisticated uncertainty estimation
The probability update mechanism could be improved with stronger calibration and more formal uncertainty modelling.
More real integrations
The simulated actions could be replaced with controlled integrations for customer verification, authentication systems, CRM workflows, and reporting systems.
Continuous learning from investigator feedback
Analyst approvals, rejections, and final outcomes could be fed back into the case-memory layer to improve future recommendations.
Final Takeaway
The main lesson from building this project was that agentic fraud investigation is not simply:
LLM + database = fraud agent
The useful architecture is closer to:
Graph + Evidence + Policy + Tools + Memory + Agent Reasoning + Human Approval + Explainable UI
TigerGraph provides the relational intelligence needed to understand how suspicious activity is connected.
The agent coordinates the investigation.
GraphRAG provides grounded context.
The policy layer constrains decisions.
Case memory makes previous investigations reusable.
And the investigation console makes the entire reasoning process visible to the analyst.
The result is a system designed to move from:
"This transaction looks suspicious."
to:
"Here is the evidence, here is the connected activity, here is what is still uncertain, here is what policy allows us to do, and here is the next best action."
That shift — from prediction to investigation — is what makes an agentic fraud system useful in practice.
Repository
The complete implementation, including the investigation console, graph-oriented investigation flow, case artifacts, replay structure, and supporting components, is available in our GitHub repository.
Built for Hacker House Goa
This project was built for the TigerGraph Agentic Fraud Investigation challenge at Hacker House Goa.
TigerGraph #HackerHouseGoa #FraudDetection #AgenticAI #GraphRAG #GraphDatabase #AI #FraudInvestigation #GSQL #MCP
#agents #ai #database #software #coding #development #engineering #inclusive #community
LOCK 1:- Tiger Graph Project
![WIRED - The Latest in Technology, Science, Culture and Business [Unofficial]](https://files.mastodon.social/cache/accounts/avatars/112/821/340/319/123/013/original/1161ef87d57f89cb.jpg)
