{"slug": "building-fraudgraph-ai-agentic-fraud-investigation-with-tigergraph-and-graphrag", "title": "Building FraudGraph AI: Agentic Fraud Investigation with TigerGraph and GraphRAG", "summary": "A hackathon team built FraudGraph AI, an agentic fraud investigation platform that combines TigerGraph's graph database with GraphRAG to trace relationships between transactions, cards, customers, and merchants. The system separates fraud probability, confidence, and uncertainty, and splits next-best-action recommendations from a policy layer that authorizes or blocks actions with human-in-the-loop approval.", "body_md": "Fraud investigation is rarely about looking at a single transaction in isolation.\n\nA suspicious transaction can be connected to a customer, multiple cards, previous transactions, devices, and historical cases. The challenge is not only detecting that something looks unusual, but also understanding the relationships behind it, gathering supporting evidence, assessing uncertainty, deciding what to do next, and ensuring that the action follows policy.\n\nFor our recent hackathon project, we built FraudGraph AI, an agentic fraud investigation platform designed around this problem.\n\nThe Core Idea\n\nInstead of treating fraud detection as:\n\nTransaction → Fraud Score → Decision\n\nwe designed the system as an investigation workflow:\n\nTransaction → Investigation → Graph Evidence → Risk & Uncertainty → Next Best Action → Policy/HITL → Execution → Case Memory\n\nThe goal was to make the investigation process explainable and structured rather than relying on a single opaque score.\n\nArchitecture\n\nThe system is divided into several stages.\n\nThe investigation starts with a flagged transaction and its trigger information.\n\nThe Investigation Engine gathers relevant evidence and normalizes it into a structured evidence model. Evidence is classified so that the system can distinguish between directly observed facts, observations, and inferences.\n\nThis gives the later reasoning stages a clear evidence base instead of passing around unstructured investigation output.\n\nThe graph layer is one of the most important parts of FraudGraph AI.\n\nFraud relationships are naturally graph-shaped:\n\nCustomer → Card → Transaction → Merchant/Entity → Related Transaction\n\nA graph allows the investigation to move across these relationships and identify connections that may not be obvious from a single transaction.\n\nTigerGraph is used as the graph investigation layer, while GraphRAG provides structured context from the graph for downstream reasoning.\n\nThis allows the system to ask questions such as:\n\nWhich transactions are connected to the flagged transaction?\n\nWhich cards are associated with the customer?\n\nWhat other activity is connected to those entities?\n\nAre there related entities or previous cases that provide additional context?\n\nWhat evidence supports the suspected fraud pattern?\n\nThe graph context is then passed into the reasoning pipeline rather than treating the transaction as an isolated record.\n\nAfter evidence collection, FraudGraph AI evaluates risk.\n\nAn important design decision was to separate fraud probability, confidence, and uncertainty.\n\nA high fraud probability does not automatically mean that the evidence is complete or that the system should immediately take an irreversible action.\n\nThe reasoning layer aggregates independent evidence signals while attempting to avoid double-counting correlated evidence.\n\nThe result contains:\n\nFraud probability\n\nConfidence\n\nUncertainty\n\nEvidence-derived risk signals\n\nThis gives the investigation a more complete picture than a single binary fraud/not-fraud classification.\n\nThe next stage answers:\n\nWhat should the investigation do next based on the current evidence and risk?\n\nThe Next Best Action engine produces a deterministic and explainable recommendation based on the investigation and risk assessment.\n\nPossible actions can include monitoring, blocking, declining, verification, or other investigation actions supported by the system.\n\nAn important architectural distinction is that Next Best Action is not the same thing as policy authorization.\n\nThe NBA engine recommends an action.\n\nThe policy layer determines whether that action is actually permitted.\n\nThe recommended action then passes through the policy layer.\n\nThe policy engine evaluates the action against the configured policy rules and determines:\n\nWhether the action is permitted\n\nWhich policy rules apply\n\nWhether approval is required\n\nWhat approval level is required\n\nWhether the case should be blocked\n\nThis creates a separation between:\n\nRecommendation → Authorization\n\nFor actions requiring human review, the workflow can move into a Human-in-the-Loop approval state rather than executing automatically.\n\nThis is particularly important for fraud investigations where an automated system should not blindly perform every high-impact action.\n\nThe final stage handles execution and investigation persistence.\n\nWhere policy permits automatic execution, the action is passed to the execution layer.\n\nThe system also stores the investigation as case memory, allowing the resulting case information and execution references to become part of the investigation record.\n\nThis creates a complete workflow:\n\nInvestigate → Reason → Recommend → Authorize → Execute → Remember\n\nrather than ending the process after generating a fraud score.\n\nBenchmarking\n\nWe also built a benchmark evaluation harness around the authoritative 20-case benchmark.\n\nEach case is processed through the same production pipeline:\n\nInvestigation\n\nRisk and uncertainty assessment\n\nNext Best Action\n\nPolicy evaluation\n\nExecution or approval handling\n\nCase-memory persistence\n\nThe benchmark runner records information including evidence count, detected pattern, affected transactions, connected cards, exposure, fraud probability, confidence, uncertainty, recommended actions, policy results, execution state, and case-memory status.\n\nThis allows the complete investigation workflow to be evaluated rather than measuring only whether a fraud classifier produced a particular score.", "url": "https://wpnews.pro/news/building-fraudgraph-ai-agentic-fraud-investigation-with-tigergraph-and-graphrag", "canonical_source": "https://dev.to/prathamesh_deshmukh_737d6/building-fraudgraph-ai-agentic-fraud-investigation-with-tigergraph-and-graphrag-3hfb", "published_at": "2026-09-24 18:16:36+00:00", "updated_at": "2026-09-24 18:29:45.892028+00:00", "lang": "en", "topics": ["ai-agents", "generative-ai", "large-language-models", "ai-tools"], "entities": ["FraudGraph AI", "TigerGraph", "GraphRAG"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/building-fraudgraph-ai-agentic-fraud-investigation-with-tigergraph-and-graphrag", "markdown": "https://wpnews.pro/news/building-fraudgraph-ai-agentic-fraud-investigation-with-tigergraph-and-graphrag.md", "text": "https://wpnews.pro/news/building-fraudgraph-ai-agentic-fraud-investigation-with-tigergraph-and-graphrag.txt", "jsonld": "https://wpnews.pro/news/building-fraudgraph-ai-agentic-fraud-investigation-with-tigergraph-and-graphrag.jsonld"}}