{"slug": "building-fraudgraph-investigator-an-ai-powered-graph-based-fraud-investigation", "title": "Building FraudGraph Investigator: An AI-Powered Graph-Based Fraud Investigation System", "summary": "A team competing in the TigerGraph × Hacker House Goa challenge built FraudGraph Investigator, an AI-powered fraud investigation system that turns a flagged transaction into a structured investigation workflow. The system combines TigerGraph's connected-data graph, a LangGraph-orchestrated agent workflow, and MCP-exposed investigation tools to collect and analyze evidence, assess uncertainty, and evaluate evidence sufficiency before a policy engine selects a next-best action such as BLOCK_CARD, VERIFY_WITH_CUSTOMER, or ESCALATE. A key design principle separates AI-assisted investigation and reasoning from the final operational decision, which is governed by explicit policy rules.", "body_md": "How we combined TigerGr\n\n[aph, LangGraph, MCP, evidence analysis, case memory, and policy-based decisions to investigate suspicious transactions.](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Faq1io2sv3i7o5pbvcsjr.png)\n\nIntroduction\n\nFraud detection is often treated as a classification problem: given a transaction, determine whether it is suspicious or legitimate.\n\nBut real fraud investigation requires more than a risk score.\n\nWhen a transaction is flagged, an investigator needs to understand the context around it:\n\nWho is the customer?\n\nWhich card was used?\n\nWhich device was involved?\n\nAre there related transactions?\n\nWhat historical information is available?\n\nWhat evidence supports the suspicion?\n\nWhat evidence contradicts it?\n\nIs the available evidence sufficient?\n\nWhat action should be taken?\n\nFor the TigerGraph × Hacker House Goa challenge, our team built FraudGraph Investigator, an AI-powered fraud investigation system that combines connected-data investigation, agentic workflows, evidence analysis, uncertainty assessment, and policy-governed actions.\n\nWhat We Built\n\nFraudGraph Investigator takes a suspicious transaction and turns it into a structured investigation.\n\nInstead of simply treating a high-risk transaction as fraud, our system follows a complete investigation workflow:\n\nSuspicious Transaction → Investigation Planning → Evidence Collection → Evidence Analysis → Hypothesis Evaluation → Uncertainty Assessment → Evidence Sufficiency → Policy Evaluation → Next-Best Action → Case Memory\n\nThe system can produce three main actions:\n\nBLOCK_CARD\n\nVERIFY_WITH_CUSTOMER\n\nESCALATE\n\nA key design principle was to separate AI-assisted investigation from the final operational decision. The investigation produces evidence and reasoning, while explicit policy rules govern the final action.\n\nSystem Architecture\n\nOur system consists of several layers:\n\nInvestigator UI\n\n↓\n\nFastAPI API\n\n↓\n\nLangGraph Investigation Workflow\n\n↓\n\nMCP Investigation Tools\n\n↓\n\nTigerGraph / Dataset\n\n↓\n\nEvidence Analysis\n\n↓\n\nPolicy Engine\n\n↓\n\nNext-Best Action\n\nThe architecture separates the data layer, investigation workflow, reasoning, policy enforcement, and user interface.\n\nThis makes the system easier to test, inspect, and extend.\n\nWhy We Used TigerGraph\n\nFraud rarely exists as an isolated transaction.\n\nA transaction can be connected to several entities, including:\n\nCustomer → Card → Transaction → Device → Location → Related Transactions\n\nIt can also connect to historical investigation information.\n\nThis is where graph-based investigation becomes useful.\n\nInstead of looking at only one transaction, our system can investigate the relationships surrounding that transaction.\n\nTigerGraph provides the graph-oriented foundation for this approach, allowing connected entities and their relationships to become part of the investigation.\n\nThe key question changes from:\n\n\"How risky is this transaction?\"\n\nto:\n\n\"What else is connected to this transaction, and what does that context tell us?\"\n\nUsing MCP for Investigation\n\nWe used Model Context Protocol (MCP) to expose investigation capabilities as structured tools.\n\nThe agent does not directly manipulate the underlying data. Instead, it requests specific investigation operations through MCP.\n\nThe general flow is:\n\nLangGraph Agent → MCP Tool → Data/Graph Layer → Structured Evidence → Investigation Workflow\n\nThe investigation tools provide targeted information such as:\n\nTransaction details\n\nCustomer information\n\nConnected entities\n\nShared devices\n\nHistorical fraud information\n\nRelated activity\n\nTemporal patterns\n\nGeographic/contextual signals\n\nThe returned information becomes evidence that can be used during the investigation.\n\nLangGraph Investigation Workflow\n\nWe used LangGraph to orchestrate the investigation as a structured workflow instead of relying on a single LLM call.\n\nThe workflow moves through several stages.\n\nThe suspicious transaction and case information are loaded.\n\nThe system determines what evidence needs to be collected.\n\nMCP tools retrieve the required information from the available data sources.\n\nThe collected information is organized and classified.\n\nPossible explanations for the transaction are considered, such as:\n\nCard-not-present fraud\n\nNew-device activity\n\nCard testing\n\nOut-of-region usage\n\nThe workflow evaluates how uncertain the investigation remains.\n\nThe system determines whether enough evidence exists to support an operational decision.\n\nThe investigation state and evidence are evaluated against deterministic policy rules.\n\nThe system produces the next-best action.\n\nThe investigation result is stored so that future investigations can use historical context.\n\nEvidence Sufficiency vs. Uncertainty\n\nOne of the important design decisions in our system was to separate evidence sufficiency from uncertainty.\n\nThese are not the same thing.\n\nA case can have enough evidence to support a decision while still having significant uncertainty.\n\nFor example:\n\nEvidence Sufficiency: SUFFICIENT\n\nUncertainty: HIGH\n\nThis distinction prevents the system from treating a high risk score as the only factor in determining the final action.\n\nThe investigation considers both the available evidence and the remaining uncertainty.\n\nHHG-010 Case Study\n\nOne of our benchmark cases is HHG-010.\n\nThe investigation produced:\n\nCustomer: C10434\n\nTransaction: 3506725\n\nRisk Score: 0.90\n\nAmount: $1,000.03\n\nStatus: COMPLETE\n\nEvidence: SUFFICIENT\n\nUncertainty: HIGH\n\nRecommended Action: ESCALATE\n\nThe system identified both supporting and contradictory evidence.\n\nFor example, the investigation found:\n\n$0 confirmed fraud + $1,000.03 pending exposure\n\nThe transaction used a desktop/Windows device\n\nThe customer had no prior confirmed fraud cases\n\nThe result was therefore not simply:\n\nHigh Risk → BLOCK\n\nInstead, the investigation resulted in:\n\nHigh Risk + Sufficient Evidence + High Uncertainty → ESCALATE → Senior Analyst Approval\n\nThis demonstrates an important principle of our system:\n\nInvestigate first, then act based on evidence and policy.\n\nHistorical Case Memory\n\nFraud investigations should not always start from zero.\n\nFraudGraph Investigator includes a case memory layer that stores information from previous investigations.\n\nThis provides historical context such as:\n\nCustomer history\n\nPrevious transactions\n\nPrevious investigation outcomes\n\nCards involved\n\nPrevious actions\n\nApproval information\n\nThe goal is to make future investigations more context-aware while keeping the information structured and traceable.\n\nPolicy-Governed Decisions\n\nAnother important component is the deterministic policy layer.\n\nThe LLM assists with investigation and reasoning, but operational actions are controlled through explicit policy rules.\n\nThe overall decision flow is:\n\nEvidence + Investigation State + Uncertainty + Risk/Exposure\n\n↓\n\nPolicy Engine\n\nBLOCK_CARD / VERIFY_WITH_CUSTOMER / ESCALATE\n\nThis separation helps keep the final operational action governed rather than allowing an LLM to directly make an unrestricted decision.\n\nInvestigator Dashboard\n\nWe built an interactive FastAPI-based investigator dashboard to make the investigation results accessible through a single interface.\n\nThe dashboard provides:\n\nCase navigation\n\nInvestigation reports\n\nRisk information\n\nSupporting evidence\n\nContradictory evidence\n\nHypotheses\n\nCase memory\n\nInvestigation workflow\n\nRecommended action\n\nBenchmark results\n\nValidation status\n\nAn investigator can move from the overall benchmark view into an individual case and inspect the evidence and reasoning behind the result.\n\nBenchmark Results\n\nWe evaluated the complete workflow across 20 benchmark investigations.\n\nThe expected action distribution was:\n\nAction  Cases\n\nBLOCK_CARD  15\n\nVERIFY_WITH_CUSTOMER    4\n\nESCALATE    1\n\nTotal   20\n\nOur benchmark dashboard showed:\n\n20 total cases\n\n20 reports loaded\n\n20/20 cases with sufficient evidence\n\n0 benchmark errors\n\n0 benchmark warnings\n\nThe end-to-end validation also checked the expected action invariants across the benchmark cases.\n\nTechnology Stack\n\nTechnology  Role\n\nTigerGraph  Connected graph investigation\n\nLangGraph   Agent/workflow orchestration\n\nMCP Structured investigation tools\n\nPython  Core implementation\n\nFastAPI API and investigator dashboard\n\nCase Memory Historical investigation context\n\nPolicy Engine   Deterministic action governance\n\nWhat We Learned\n\nThe biggest lesson from this project was that building an AI investigation system is not only about choosing an LLM.\n\nA practical system also needs:\n\nConnected Data + Investigation Tools + Agent Workflow + Evidence + Uncertainty + Policy + Testing + User Interface\n\nGraph technology was particularly useful because fraud investigations naturally involve relationships between entities.\n\nWe also learned the importance of separating:\n\nWhat the model reasons about → What evidence exists → What the policy allows → What action is finally taken\n\nFuture Improvements\n\nThere are several areas we would explore in a production version.\n\nReal-Time Graph Integration\n\nThe system could be connected to continuously updated transaction streams and a production TigerGraph environment.\n\nAdvanced Graph Analytics\n\nAdditional graph algorithms could help identify:\n\nFraud rings\n\nSuspicious communities\n\nEntity similarity\n\nCoordinated transaction patterns\n\nSuspicious subgraphs\n\nImproved Case Memory\n\nA larger historical investigation repository could provide richer contextual reasoning.\n\nHuman-in-the-Loop Investigation\n\nInvestigators could approve, reject, or request additional evidence before a final action.\n\nProduction Monitoring\n\nA production deployment would also require monitoring for data drift, model drift, investigation latency, policy violations, false positives, and changing fraud patterns.\n\nConclusion\n\nFraudGraph Investigator was built around a simple idea:\n\nFraud investigation should be evidence-driven, connected, and governed — not just a prediction from a single transaction.\n\nBy combining TigerGraph, LangGraph, MCP, case memory, evidence analysis, and deterministic policy rules, we created an end-to-end investigation workflow that moves from a suspicious transaction to an explainable next-best action.\n\nThe project gave us hands-on experience building an AI system where graph relationships, agentic workflows, evidence, uncertainty, and governance work together.\n\nThanks to TigerGraph and Hacker House Goa for providing the challenge and the opportunity to build around connected-data intelligence.", "url": "https://wpnews.pro/news/building-fraudgraph-investigator-an-ai-powered-graph-based-fraud-investigation", "canonical_source": "https://dev.to/arshu-1104/building-fraudgraph-investigator-an-ai-powered-graph-based-fraud-investigation-system-55hc", "published_at": "2026-09-24 17:39:44+00:00", "updated_at": "2026-09-24 17:59:18.658638+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "artificial-intelligence", "ai-tools", "mlops"], "entities": ["TigerGraph", "Hacker House Goa", "FraudGraph Investigator", "LangGraph", "Model Context Protocol", "FastAPI"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/building-fraudgraph-investigator-an-ai-powered-graph-based-fraud-investigation", "markdown": "https://wpnews.pro/news/building-fraudgraph-investigator-an-ai-powered-graph-based-fraud-investigation.md", "text": "https://wpnews.pro/news/building-fraudgraph-investigator-an-ai-powered-graph-based-fraud-investigation.txt", "jsonld": "https://wpnews.pro/news/building-fraudgraph-investigator-an-ai-powered-graph-based-fraud-investigation.jsonld"}}