FraudNet：基于 TigerGraph、MCP 与 GraphRAG 的图原生自主欺诈调查 Agent

Hacker House Goa 2026 — TigerGraph Agentic Fraud Investigation Challenge What happens after a fraud detection model flags a transaction? Usually, not much automation. A model might produce something like: Transaction: 3514030 Risk Score: 0.61 Enter fullscreen mode Exit fullscreen mode But a risk score isn't a fraud verdict. An analyst still needs to investigate the transaction, understand the customer's history, identify connected cards and devices, look for similar historical cases, evaluate applicable policies, determine whether additional evidence is required, and finally decide what action should be taken. That investigation can involve dozens of queries across multiple systems and can take significant analyst time. We built FraudNet to explore a different approach: What if a fraud risk score became the starting point for an autonomous investigation rather than the end of a machine-learning pipeline? FraudNet combines TigerGraph, TigerGraph MCP, GraphRAG, LLM reasoning, deterministic policy enforcement, and case memory into an agentic fraud investigation workflow. The result is a system that can investigate a suspicious transaction, gather multi-hop graph evidence, identify uncertainty, request additional evidence when necessary, enforce deterministic policies, and write completed investigations back into the graph as organizational memory. 1. The Problem: A Risk Score Isn't an Investigation Traditional fraud systems are generally good at answering: "How suspicious is this transaction?" They are much less capable of answering: "Why is this transaction suspicious, what is it connected to, what evidence supports that conclusion, what policies apply, and what should happen next?" Consider a transaction with a moderately high risk score. An analyst might need to investigate: Previous transactions from the card Customer travel history Other cards belonging to the customer Devices used by those cards IP addresses and device fingerprints Other transactions associated with the same device Historical fraud cases Known fraud typologies Internal bank policies Regulatory reporting requirements Aggregate exposure across connected entities The interesting part is that these aren't isolated pieces of information. They form a relationship graph. For example: Customer │ └── OWNS │ Card │ MADE │ Transaction │ FROM_DEVICE │ Device │ FROM_DEVICE │ Other Transaction │ MADE │ Other Card Enter fullscreen mode Exit fullscreen mode A suspicious transaction may become significantly more meaningful when the graph reveals that its device is shared by dozens of unrelated payment cards. This is where FraudNet starts. 2. What We Built FraudNet is an autonomous fraud investigation workstation built around a graph-native architecture. At a high level: Case Trigger (case_pack.csv) │ ▼ ┌───────────────────────────────┐ │ Investigation Workflow │ │ 12-stage deterministic graph │ └──────────────┬────────────────┘ │ ┌───────┼────────┐ │ │ │ ▼ ▼ ▼ TigerGraph GraphRAG LLM │ │ │ │ │ └── Evidence synthesis │ │ Uncertainty assessment │ │ Fraud probability │ │ │ ├── Policies │ ├── Typologies │ └── Case Memory │ └── Multi-hop evidence │ ▼ Evidence Request Loop │ ▼ Deterministic PolicyEngine │ ┌──────┴──────┐ ▼ ▼ Final Action SAR Filing │ ▼ TigerGraph Writeback │ ▼ Case Memory Enter fullscreen mode Exit fullscreen mode The important architectural principle is the separation of responsibilities: TigerGraph provides relationship-grounded evidence. GraphRAG provides contextual knowledge. The LLM performs reasoning and synthesis. The PolicyEngine controls consequential actions. This prevents the LLM from becoming the final authority. 3. Why a Graph? Fraud is fundamentally relational. Suppose we have: Card A → Device X Card B → Device X Card C → Device X ... Card AH → Device X Enter fullscreen mode Exit fullscreen mode A transaction-level model might see each transaction independently. A graph can immediately expose the relationship: ┌── Card A │ ├── Card B │ ├── Card C │ Device X ────┼── ... │ └── Card AH Enter fullscreen mode Exit fullscreen mode That relationship can become a powerful investigation signal. FraudNet uses TigerGraph to traverse relationships such as: Customer ↓ Card ↓ Transaction ↓ Device ↓ Other Transactions ↓ Other Cards Enter fullscreen mode Exit fullscreen mode This allows the investigation agent to reason about connected entities rather than isolated rows. 4. TigerGraph: The Investigation Evidence Layer The FraudNet graph runs on a live TigerGraph Cloud instance. The graph contains entities such as: Customers Cards Transactions Devices Historical cases and their relationships. Examples include: Customer ──OWNS────────> Card Card ──MADE────────────> Transaction Transaction ──FROM_DEVICE──> Device Card ──HAS_HISTORY─────> Transaction Enter fullscreen mode Exit fullscreen mode This allows FraudNet to perform investigation-specific graph traversals. Some of the primary graph operations include: get_transaction_context get_card_history get_customer_history get_connected_cards get_device_neighbors get_transaction_chain get_similar_closed_cases detect_card_testing write_case Enter fullscreen mode Exit fullscreen mode One particularly useful operation is: get_device_neighbors Enter fullscreen mode Exit fullscreen mode Instead of asking an LLM to inspect thousands of transaction records and infer relationships, TigerGraph can directly answer: "What other cards and transactions are connected to this device?" The graph does the relationship discovery. The LLM then interprets the result. That distinction is important. 5. TigerGraph MCP: Giving the Agent Controlled Graph Access We didn't want the LLM generating arbitrary GSQL. That would introduce unnecessary risks: Invalid queries Uncontrolled database access Large context responses Accidental mutations Credential exposure Difficult-to-audit behavior Instead, FraudNet uses the official TigerGraph MCP package (tigergraph-mcp v1.0.3) as the interface between the reasoning layer and TigerGraph. Conceptually: LLM │ │ MCP tool call ▼ TigerGraph MCP │ ▼ Typed investigation operation │ ▼ TigerGraph Enter fullscreen mode Exit fullscreen mode The agent can request: get_device_neighbors(device_id) Enter fullscreen mode Exit fullscreen mode rather than generating arbitrary database queries. This gives us three major benefits. 1. Controlled Access The LLM only has access to explicitly exposed investigation capabilities. 2. Smaller Context The MCP layer can return structured investigation results rather than dumping entire graph neighborhoods into the model context. 3. Better Security Boundaries Credentials and bearer tokens remain isolated inside the adapter layer rather than becoming part of the reasoning context. The LLM reasons about the result, not the database implementation. 6. GraphRAG: Connecting Graph Evidence With Institutional Knowledge Graph evidence alone isn't enough. An investigator also needs context: What does this fraud pattern mean? What policy applies? Has the organization seen similar cases? What action was taken previously? FraudNet therefore uses a GraphRAG layer containing three major knowledge collections. Policy Knowledge Bank operating policies covering: R1 – R10 Enter fullscreen mode Exit fullscreen mode These include approval thresholds, escalation requirements, and regulatory triggers. Fraud Typologies FraudNet includes documented patterns such as: card_testing card_not_present_fraud card_not_present_new_device out_of_region_use account_takeover Enter fullscreen mode Exit fullscreen mode It also supports guidance for undocumented abuse patterns. Historical Case Memory The system includes: 5,565 historical closed cases Enter fullscreen mode Exit fullscreen mode from: closed_cases_history.csv Enter fullscreen mode Exit fullscreen mode Retrieved information is tagged with its provenance: policy typology case_memory Enter fullscreen mode Exit fullscreen mode This means the reasoning layer knows where its contextual information came from. 7. The 12-Stage Agentic Workflow The core investigation logic lives in: src/agent/workflow.py src/agent/nodes.py Enter fullscreen mode Exit fullscreen mode The workflow consists of 12 stages. 1. load_case Loads the investigation trigger from case_pack.csv. The trigger can originate from a risk score, analyst request, or customer report. 2. investigate_transaction Retrieves transaction context, risk signals, and relevant transaction attributes. 3. investigate_relationships Traverses customer history, card history, connected cards, and device relationships. 4. retrieve_prior_cases Searches historical closed investigations for similar patterns. 5. assess_evidence The LLM synthesizes the collected evidence into structured findings. 6. assess_uncertainty The agent determines whether the current evidence is sufficient or whether ambiguity remains. 7. request_evidence If uncertainty is unresolved, the agent generates an appropriate evidence request. 8. reassess_case New evidence is incorporated and the investigation is reassessed. 9. apply_policy The deterministic PolicyEngine evaluates the investigation against institutional rules. 10. prepare_case The system prepares the final case package, including reporting and approval requirements. 11. write_case The completed investigation is persisted back into TigerGraph. 12. finish The system produces the final benchmark-compliant JSON output. The result is not simply: LLM → answer Enter fullscreen mode Exit fullscreen mode Instead: Trigger ↓ Graph Investigation ↓ Historical Context ↓ LLM Evidence Synthesis ↓ Uncertainty ↓ Additional Evidence (if needed) ↓ Policy Enforcement ↓ Case Writeback ↓ Final Output Enter fullscreen mode Exit fullscreen mode 8. The Important Part: Uncertainty One of the design decisions we cared about most was avoiding premature conclusions. A suspicious signal doesn't necessarily mean fraud. Consider HHG-001. The transaction had: Risk Score: 0.61 Amount: $77.07 Transaction: 3514030 Card: C12382-K1 Enter fullscreen mode Exit fullscreen mode The transaction occurred in an unusual billing region. At first glance, that looks suspicious. But the graph revealed that the customer had a history of traveling. Instead of immediately blocking the card, FraudNet recognized that the evidence was ambiguous. The agent initiated: customer_validation Enter fullscreen mode Exit fullscreen mode The simulated customer response confirmed that the cardholder had authorized the transaction. The case then went through the policy layer and resulted in: CLOSE_NO_FRAUD Enter fullscreen mode Exit fullscreen mode Exposure: $0.00 Enter fullscreen mode Exit fullscreen mode SAR: Rejected Enter fullscreen mode Exit fullscreen mode The important behavior here wasn't simply the final verdict. It was the decision to gather more evidence before acting. 9. When the Graph Changes Everything: HHG-014 Now consider a very different case. HHG-014 involved: Transaction: 3478561 Amount: $74.96 Card: C13487-K1 Enter fullscreen mode Exit fullscreen mode The investigation initially considered customer verification. Then the graph traversal revealed something much more significant. A single device profile: SM-G935F Build/NRD90M | Android 7.0 Enter fullscreen mode Exit fullscreen mode was connected to: 34 distinct payment cards Enter fullscreen mode Exit fullscreen mode The graph transformed the investigation. Instead of: Suspicious transaction Enter fullscreen mode Exit fullscreen mode the evidence now looked like: Device │ ┌──────────┼──────────┐ │ │ │ Card 1 Card 2 Card 3 │ │ │ ... ... ... │ Card 34 Enter fullscreen mode Exit fullscreen mode GraphRAG also retrieved historical syndicate cases: CC-2985 CC-3035 CC-2649 CC-2971 Enter fullscreen mode Exit fullscreen mode The evidence supported a coordinated device-based attack. The fraud probability was updated to: 0.95 Enter fullscreen mode Exit fullscreen mode The policy layer then enforced actions including: CREATE_CASE FILE_REPORT ESCALATE_TO_ANALYST MONITOR_CONNECTED_CARDS Enter fullscreen mode Exit fullscreen mode and a SAR was generated covering the immediate exposure and connected entities. Finally, the completed case was persisted back into TigerGraph. This is exactly the kind of investigation where graph technology provides information that would be difficult to derive from an isolated transaction record. 10. LLM Reasoning vs. Deterministic Policy This was one of the most important architectural choices in FraudNet. LLMs are useful for: Synthesizing evidence Explaining relationships Identifying potential patterns Assessing uncertainty Producing human-readable reasoning But they should not be trusted as the sole authority for deterministic institutional rules. Therefore: LLM Recommendation │ ▼ ┌─────────────────────┐ │ PolicyEngine │ │ │ │ R1 → R10 │ │ Exposure thresholds │ │ Approval routing │ │ SAR requirements │ └──────────┬──────────┘ │ ▼ Final Enforced Action Enter fullscreen mode Exit fullscreen mode The PolicyEngine lives in: src/policy/engine.py Enter fullscreen mode Exit fullscreen mode It controls permitted actions such as: BLOCK_CARD BLOCK_ALL_CARDS MONITOR_CONNECTED_CARDS CREATE_CASE FILE_REPORT CLOSE_NO_FRAUD Enter fullscreen mode Exit fullscreen mode It also determines approval routes: AUTO L1 L2 Enter fullscreen mode Exit fullscreen mode The system explicitly records: Initial LLM recommendation ↓ Policy evaluation ↓ Final enforced decision Enter fullscreen mode Exit fullscreen mode This separation makes the investigation trace significantly easier to audit. 11. SAR Generation FraudNet also generates structured Suspicious Activity Report data when the applicable policy rules require it. The generated report includes information such as: Filing justification Transaction sequence Relevant graph relationships Subject identifiers Connected cards Device information Aggregate exposure The important architectural distinction is that the LLM doesn't independently decide: "This should be reported." Instead: Evidence ↓ LLM recommendation ↓ Deterministic PolicyEngine ↓ SAR requirement ↓ Structured SAR output Enter fullscreen mode Exit fullscreen mode This keeps regulatory actions tied to explicit policy logic. 12. Grounding the Agent Agentic systems introduce another major problem: How do we know the model isn't inventing entities? FraudNet addresses this with two validation layers. Schema Validation Implemented through: evaluation/validate_schema.py Enter fullscreen mode Exit fullscreen mode Pydantic schemas enforce structural requirements and cross-field invariants. For example, outputs cannot contain contradictory combinations of actions, verdicts, SAR states, and approval requirements. Entity Integrity Implemented through: evaluation/check_integrity.py Enter fullscreen mode Exit fullscreen mode The system validates entity references against an in-memory registry containing: 631,219 ground-truth entities Enter fullscreen mode Exit fullscreen mode This includes: Transaction IDs Card IDs Customer IDs Device profiles Enter fullscreen mode Exit fullscreen mode Therefore, if the LLM produces an entity that doesn't exist in the underlying dataset, the result can be rejected. The goal is simple: Reason freely, but never invent the underlying facts. 13. The Investigation Control Room We also built a lightweight Flask-based Investigation Control Room under: ui/ Enter fullscreen mode Exit fullscreen mode The interface operates in replay mode over canonical benchmark outputs. It includes several views. Interactive Evidence Graph A D3.js force-directed visualization shows: Customers Cards Transactions Devices Cases Enter fullscreen mode Exit fullscreen mode and their relationships. Selecting an entity highlights the supporting evidence. Investigation Trace The UI reconstructs the 12-stage investigation timeline from stored evidence references. PolicyEngine Gate The UI visualizes: LLM Recommendation ↓ PolicyEngine Evaluation ↓ Final Enforced Action Enter fullscreen mode Exit fullscreen mode Uncertainty View The interface displays: Fraud probability Uncertainty Initial recommendation Final decision Case Memory Relevant historical investigations retrieved by GraphRAG are displayed as precedents. Benchmark Dashboard The /benchmark route provides a 20-case benchmark matrix and aggregate operational statistics. A key transparency feature is that replay-derived fields and simulated customer responses are explicitly labeled in the UI rather than presented as live external events. 14. Benchmark Results FraudNet was benchmarked across all 20 cases in case_pack.csv using live TigerGraph Cloud and Groq's openai/gpt-oss-20b endpoint. Metric Result Total cases executed 20 / 20 Output schema validation 20 / 20 passed Entity integrity validation 20 / 20 passed Ground-truth entities checked 631,219 Fraud verdicts 18 Legitimate verdicts 2 Mandatory SARs filed 10 Evidence-request loops 16 Average latency 30.0 seconds Minimum latency 19.1 seconds Maximum latency 95.0 seconds Average tool calls/case 5.6 Average token usage/case 676 Total detected fraud exposure $3,515.23 We did not report classification accuracy or F1 because official benchmark ground truth was not published. That distinction matters. A system can produce internally valid and reproducible outputs without having a verified classification ground truth. 15. Resilience and Failure Handling An autonomous investigation system also has to handle things going wrong. FraudNet includes several resilience mechanisms. TigerGraph Fallback If TigerGraph Cloud experiences a transient connection failure, the GraphAdapter can fall back to an in-memory graph mirror loaded from the raw CSV datasets. Configuration: TG_BACKEND=auto Enter fullscreen mode Exit fullscreen mode This allows the investigation pipeline to continue without depending exclusively on a live database connection. JSON Recovery LLM responses aren't always perfectly formatted. FraudNet includes recovery logic for cases such as: { ... } Enter fullscreen mode Exit fullscreen mode wrapped in Markdown fences or truncated JSON responses. The recovery layer can strip Markdown fences and repair certain incomplete structures before schema validation. Credential Scrubbing API keys, database credentials, and bearer tokens are scrubbed before timeline states are logged or persisted. Idempotent Writes Before writing a case back to TigerGraph, existing vertex IDs are checked to prevent duplicate case nodes. 16. What We Learned Graphs Let the LLM Focus on Reasoning One of the strongest lessons from building FraudNet was that the LLM should not be responsible for discovering every relationship. Asking an LLM to inspect large collections of raw transaction data and discover a device syndicate is inefficient and prone to errors. Instead: TigerGraph ↓ Find connected entities ↓ Structured evidence ↓ LLM ↓ Reason about evidence Enter fullscreen mode Exit fullscreen mode For HHG-014, the graph could directly expose the connection between one device and 34 cards. The LLM didn't need to calculate that relationship itself. It needed to understand what that relationship meant. Deterministic Rules Belong Outside the LLM Another major lesson was the importance of separating: Reasoning Enter fullscreen mode Exit fullscreen mode from: Enforcement Enter fullscreen mode Exit fullscreen mode The LLM can say: "The evidence strongly suggests coordinated fraud." The PolicyEngine determines what actions are actually permitted. This architecture makes the system easier to reason about, test, audit, and modify. 17. Current Limitations FraudNet is an engineering prototype and benchmark system, not a production financial deployment. There are several limitations. Customer Verification Is Simulated The offline benchmark uses simulated customer responses based on the underlying case context. A production implementation would connect the evidence-request layer to real systems such as: SMS Push notifications Customer portals Banking applications Webhook listeners Enter fullscreen mode Exit fullscreen mode Replay UI Instead of Live Streaming The current Control Room replays completed investigation traces. A production version could use: Server-Sent Events WebSockets Enter fullscreen mode Exit fullscreen mode to stream investigation events as they happen. Benchmark Ground Truth The benchmark does not provide official classification ground truth, so we report operational and validation metrics rather than claiming accuracy. 18. Future Roadmap There are several directions we would explore next. 1. Live Multi-Hop Graph Expansion Instead of only displaying the final graph, allow analysts to interactively expand: Transaction ↓ Device ↓ Connected Cards ↓ Connected Transactions ↓ Historical Cases Enter fullscreen mode Exit fullscreen mode during an active investigation. 2. Analyst Override Analysis Track where analysts disagree with automated recommendations and use those patterns to propose candidate policy refinements for human review. The important distinction would be: Agent proposes Compliance approves PolicyEngine enforces Enter fullscreen mode Exit fullscreen mode rather than allowing the system to autonomously rewrite compliance rules. 3. Proactive Graph Analytics Run algorithms such as: PageRank Louvain community detection Connected-component analysis Enter fullscreen mode Exit fullscreen mode to identify emerging device or account clusters before individual transactions are flagged. This could move the architecture from: Reactive Investigation Enter fullscreen mode Exit fullscreen mode toward: Proactive Fraud Intelligence Enter fullscreen mode Exit fullscreen mode 19. The Architecture in One Picture The overall FraudNet design can be summarized as: ┌────────────────────┐ │ Fraud Trigger │ └─────────┬──────────┘ │ ▼ ┌────────────────────┐ │ Agentic Workflow │ │ 12 Stages │ └─────────┬──────────┘ │ ┌──────────────────┼──────────────────┐ │ │ │ ▼ ▼ ▼ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ TigerGraph │ │ GraphRAG │ │ LLM │ │ │ │ │ │ │ │ Relations │ │ Policies │ │ Reasoning │ │ Topology │ │ Typologies │ │ Synthesis │ │ History │ │ Case Memory│ │ Uncertainty│ └─────┬──────┘ └─────┬──────┘ └─────┬──────┘ │ │ │ └──────────────────┼──────────────────┘ ▼ ┌────────────────────┐ │ Evidence Evaluation│ └─────────┬──────────┘ │ Uncertainty? / \ Yes No │ │ ▼ │ Evidence Request │ │ │ └──────┬───────┘ ▼ ┌────────────────────┐ │ PolicyEngine │ │ R1 → R10 │ └─────────┬──────────┘ │ ▼ ┌────────────────────┐ │ Final Enforcement │ │ + SAR + Approval │ └─────────┬──────────┘ │ ▼ ┌────────────────────┐ │ TigerGraph Writeback│ │ Case Memory │ └────────────────────┘ Enter fullscreen mode Exit fullscreen mode The key idea is that each component has a clearly defined responsibility. 20. Conclusion FraudNet started with a simple question: Can an AI agent investigate fraud rather than simply score it? Our approach was to combine four capabilities: Graph Intelligence + Retrieval-Augmented Knowledge + LLM Reasoning + Deterministic Enforcement Enter fullscreen mode Exit fullscreen mode TigerGraph provides the relationship structure. TigerGraph MCP gives the agent controlled access to that structure. GraphRAG provides policy, typology, and historical case context. The LLM synthesizes evidence and handles uncertainty. The PolicyEngine ensures that consequential actions remain deterministic. And the final investigation is written back into the graph as organizational memory. The result is not an LLM sitting on top of a database. It is an investigation architecture where: The graph discovers the evidence, the agent reasons over it, the policy engine controls the action, and the investigation becomes memory for the next case. Links GitHub Repository: https://github.com/aaryamanmishra/tigergraph-agentic-fraud-investigation Demo: https://youtu.be/79AmYJ6bY3o Built for: Hacker House Goa 2026 — TigerGraph Agentic Fraud Investigation Challenge Tech Stack TigerGraph Cloud TigerGraph MCP v1.0.3 GraphRAG Groq openai/gpt-oss-20b Python Pydantic Flask D3.js GSQL Enter fullscreen mode Exit fullscreen mode TigerGraph #GraphRAG #MCP #AgenticAI #FraudDetection #GenerativeAI #LLM #Python #AIEngineering #GraphDatabase #HackerHouseGoa