{"slug": "building-casework-an-agentic-fraud-investigator-with-tigergraph-and-graphrag", "title": "Building Casework: An Agentic Fraud Investigator with TigerGraph and GraphRAG", "summary": "A developer built Casework, an agentic fraud investigation application that combines TigerGraph graph evidence, document retrieval, a local Llama 3.2 3B model via Ollama, and policy rules to trace a case from an initial transaction trigger to a recorded recommendation. The system uses GSQL and TigerGraph MCP to pull transaction context and connected evidence, while the language model is restricted to structured schemas for planning retrieval and reviewing evidence, with policy code determining action routes. The project was created for the TigerGraph × HHGoa challenge, and its source code and 20 benchmark case files are publicly available.", "body_md": "A suspicious transaction starts an investigation. The harder part is deciding what evidence to gather, what remains uncertain, and which action is justified.\n\nWe built **Casework** for the **TigerGraph × HHGoa challenge** to explore that problem.\n\nCasework is a fraud investigation application that connects graph evidence, document retrieval, a local language model, and policy rules. It follows a case from an initial trigger to a recorded recommendation, preserving the evidence and decisions along the way.\n\nOur aim was to make the investigation understandable to someone reviewing it afterward. An analyst should be able to see why an action was recommended, what information was missing, and what changed when new evidence was introduced.\n\n**Source code:** [github.com/Dhruvhash/casework-agent](https://github.com/Dhruvhash/casework-agent)\n\nCasework provides a browser interface for investigating the challenge’s fraud cases.\n\nAn investigation begins with a customer, a card, and a flagged transaction. The application retrieves relevant relationships from TigerGraph, calculates transaction signals, searches historical cases and policy documents, and produces a structured investigation record.\n\nThe interface presents:\n\nThe repository includes the 20 benchmark answer files in the root `cases/` folder, named `HHG-001.json` through `HHG-020.json`.\n\nEach answer contains evidence, findings, affected transactions, exposure, evidence requests, and the initial and final recommended actions. The application also records execution traces containing graph context, retrieved document identifiers, model planning output, and MCP calls.\n\nWe implemented a **custom Python agent** with a bounded investigation workflow.\n\n| Component | Responsibility | \n|---|---|\n| **TigerGraph Savanna** | Stores graph entities, relationships, document vectors, and investigation records | \n| **GSQL** | Retrieves transaction context and connected evidence | \n| **TigerGraph MCP** | Exposes graph query capabilities to the investigation workflow | \n| **Ollama + Llama 3.2 3B** | Plans retrieval, proposes evidence requests, and reviews supplied evidence | \n| **nomic-embed-text** | Generates embeddings for semantic retrieval | \n| **Python analysis and policy modules** | Calculate signals, analyze graph neighborhoods, and assign action routes | \n| **FastAPI and browser UI** | Present cases and allow investigations to be initiated | \n\nThe workflow is:\n\n```\nInvestigation trigger\n        │\n        ▼\nGraph evidence through TigerGraph MCP\n        │\n        ▼\nTransaction signals and relationship analysis\n        │\n        ▼\nModel proposes retrieval and evidence requests\n        │\n        ▼\nVector retrieval of policies, history, and memory\n        │\n        ▼\nEvidence review and uncertainty assessment\n        │\n        ▼\nPolicy rules and approval routing\n        │\n        ▼\nValidated case record and report draft\n        │\n        ▼\nGraph persistence and versioned case memory\n```\n\nThe language model has specific responsibilities within this flow. It receives graph facts, proposes a semantic search query, selects a permitted evidence request, and reviews the retrieved evidence.\n\nIts output must match structured schemas. It cannot issue arbitrary GSQL or execute financial actions.\n\nPolicy code determines the action routes. This keeps recommendations traceable to explicit rules rather than leaving approval decisions to generated text.\n\nFraud investigations involve relationships that are difficult to understand from an isolated transaction row.\n\nOur graph represents customers, cards, transactions, device profiles, email domains, billing regions, historical closed cases, generated investigation cases, and supporting documents.\n\nStarting from a flagged transaction, GSQL retrieves the customer’s history, known card activity, relevant device relationships, and connected historical evidence.\n\nThat context helps answer questions such as:\n\nIs this amount unusual for the customer? Has this device profile appeared before? What other recent activity shares the profile? Is there relevant historical fraud evidence?\n\nThe application then performs additional analysis on the retrieved graph neighborhood. Python code calculates connected components and node degrees and checks for a shared-origin motif.\n\n**GSQL performs graph retrieval; the application performs these additional neighborhood algorithms.**\n\nThe shared-origin check considers multiple attributes together, including activity across customers, new-device indicators, and anonymous or hidden proxy attributes. Sharing a generic device profile alone does not establish fraud.\n\nThe dataset does not provide a card ID for every transaction.\n\nWe therefore use explicit historical and trigger anchors to establish card-to-transaction relationships. We do not assign every transaction belonging to a customer to their flagged card.\n\nThis affects the reliability of later conclusions. A card-testing pattern, for example, requires evidence that the transactions actually belong to the same card.\n\nGraph evidence establishes relationships and transaction context. Retrieved documents add relevant policies and historical examples.\n\nCasework combines both sources in its **GraphRAG workflow**.\n\nAfter analyzing the graph, the model proposes a concise search query. The application embeds that query and calls installed TigerGraph vector search queries to retrieve:\n\n| Retrieved context | Purpose | \n|---|---|\n| **Historical cases** | Find comparable investigations and their recorded outcomes | \n| **Policy passages** | Supply relevant procedural context | \n| **Generated investigation memory** | Recover earlier case records and reasoning | \n\nThe model reviews selected evidence with source references. It returns evidence indices and remaining uncertainties, and the application rejects indices outside the supplied evidence list.\n\nHistorical cases provide analogies. A similar earlier fraud case can explain why a signal deserves attention, but its outcome does not determine the current case.\n\nTime constraints also matter. The workflow filters transaction context and historical cases against the investigation’s opening time so that later outcomes do not become evidence for an earlier decision.\n\nThe agent adapts parts of its investigation to the evidence it receives.\n\nIt can:\n\nThe evidence request types include customer validation, step-up authentication, and analyst information.\n\nThe workflow is bounded. It does not keep retrieving information indefinitely or assume that another graph query will resolve every uncertainty.\n\nFor example, transaction history can establish that a purchase is unusual. It may still be unable to establish whether the customer authorized it. Customer verification is then a meaningful next step.\n\n**Simulation boundary:** The prototype records evidence requests and supports explicitly simulated responses. It does not contact customers or connect to banking authorization systems.\n\nThe saved HHG-010 investigation provides a concrete example of case progression.\n\n| Observation | Recorded value | \n|---|---|\n| Flagged transaction | `3506725` | \n| Channel | Online | \n| Transaction amount | **$1,000.03** | \n| Earlier customer transactions in the baseline | **33** | \n| Baseline median amount | **$68.98** | \n| Signals identified | Unusual amount and new device | \n\nThese observations justify investigation, but they do not establish whether the purchase was authorized.\n\n| Recommendation | Reason | \n|---|---|\n| `VERIFY_WITH_CUSTOMER` | Authorization remains unresolved | \n| `CREATE_CASE` | Preserve the investigation and supporting evidence | \n| `ESCALATE_TO_ANALYST` | Uncertainty remains at the recorded exposure level | \n\nFor the demonstration, we explicitly simulate the customer denying the transaction. The policy engine then updates the recommendations:\n\n| Recommendation | Approval route | \n|---|---|\n| `BLOCK_CARD` | **L1** | \n| `CREATE_CASE` | **Auto recommendation** | \n| `FILE_REPORT` | **L2** | \n\nThe case retains both recommendation sets and records why they changed.\n\nThe denial is labeled as simulated throughout the investigation. The block is a recommendation, and the report is a draft awaiting review. No real card block or regulatory filing occurs.\n\nWe implemented the challenge’s action rules in a deterministic policy module.\n\nEach recommendation contains three essential fields:\n\n```\n{\n  \"action\": \"BLOCK_CARD\",\n  \"route\": \"L1\",\n  \"reason\": \"R2: simulated customer denial; recommended block requires human approval.\"\n}\n```\n\nThis structure lets an analyst inspect the proposed action alongside its approval requirement and policy basis.\n\nWhen the challenge policy requires a suspicious activity report, Casework creates a draft containing the subjects, activity dates, exposure, and supporting narrative. It also states the evidence limitations and identifies simulated information.\n\n**The displayed probabilities are heuristics.** They are not calibrated predictions from a trained fraud model.\n\nMissing information also limits which conclusions are defensible. For example, the available data does not establish merchant identity or settlement status, so recurring-merchant and cleared-purchase conclusions require further verified evidence.\n\nCasework keeps generated investigations separate from the supplied historical outcomes.\n\nThe persistence code writes an investigation vertex to TigerGraph and connects it to the customer, relevant transactions, and cited documents. It checks the server acknowledgment and reads back the submitted case payload before marking the case as written to the graph.\n\nThe memory module creates versioned snapshots containing:\n\nThese snapshots can be retrieved as context during later investigations.\n\nThis supports continuity between cases without treating earlier generated conclusions as confirmed ground truth. It also does not retrain the language model.\n\nThat distinction prevents uncertain findings from becoming stronger merely because the application has repeated them.\n\nThe local project contains all **20 benchmark answer files**.\n\nIn the saved set inspected for this article:\n\n| Saved verdict | Number of cases | \n|---|---|\n| Uncertain | 18 | \n| Legitimate | 1 | \n| Fraud | 1 | \n\nThe fraud case includes the explicit simulated customer denial described above.\n\n**These counts describe the saved outputs, not investigation accuracy.**\n\nMany cases remain uncertain because the available transaction evidence cannot establish customer authorization. Generating all required files demonstrates workflow coverage; measuring accuracy requires verified outcomes and a separate evaluation.\n\nThe prototype includes graph retrieval, evidence review, policy routing, case generation, and graph persistence. Reliable operation also depends on service availability, MCP connectivity, and accurate failure reporting.\n\n**Graph modeling determines the quality of the investigation.**\n\nAn incorrect card relationship can lead to a convincing but unsupported fraud pattern. Getting entity attribution right matters before any model writes an explanation.\n\n**Uncertainty needs to be visible throughout the product.**\n\nIt belongs in the evidence record, case status, recommendation, and interface. Analysts need to understand what is unresolved while they are making decisions.\n\n**Memory needs provenance.**\n\nA confirmed historical outcome, a generated hypothesis, and a simulated customer reply have different evidential value. Retrieval should preserve those differences.\n\n**Operational failures affect trust.**\n\nA slow graph service or failed MCP process can prevent an investigation from completing. The interface must distinguish a saved result from a successful new run and report failures clearly.\n\n**A smaller model benefits from a well-defined role.**\n\nKeeping planning and review bounded makes outputs easier to validate. Graph analysis and policy code provide structure around the model’s contribution.\n\n| Area | Improvement | \n|---|---|\n| **Evaluation** | Test graph attribution, policy boundaries, retrieval relevance, and outcomes against verified labels | \n| **Retrieval** | Rank policy passages by applicability as well as semantic similarity | \n| **Approvals** | Add authenticated analyst roles and an auditable approval queue | \n| **Evidence collection** | Integrate controlled customer verification with recorded responses and permissions | \n| **Case progression** | Show a clearer timeline of evidence, recommendations, approvals, and revisions | \n| **New data** | Add validated transaction ingestion with schema checks, duplicate detection, and entity mapping | \n| **Reliability** | Strengthen service health checks, failure reporting, and recovery behavior | \n\nCasework gave us a practical way to bring graph evidence, retrieval, language models, and policy code into one investigation workflow.\n\nThe part we want to keep developing is the case record: a clear account of what is known, what remains uncertain, and why the next action is justified.\n\n**Explore the project**\n\n*Built for the TigerGraph × HHGoa challenge using the organizer-provided benchmark and policies.*", "url": "https://wpnews.pro/news/building-casework-an-agentic-fraud-investigator-with-tigergraph-and-graphrag", "canonical_source": "https://dev.to/dhruv_ghosal_019265a175ed/building-casework-an-agentic-fraud-investigator-with-tigergraph-and-graphrag-nnl", "published_at": "2026-09-23 15:35:21+00:00", "updated_at": "2026-09-23 15:58:50.306908+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "ai-tools", "large-language-models", "ai-infrastructure"], "entities": ["Casework", "TigerGraph", "TigerGraph Savanna", "TigerGraph MCP", "Ollama", "Llama 3.2 3B", "nomic-embed-text", "FastAPI"], "alternates": {"html": "https://wpnews.pro/news/building-casework-an-agentic-fraud-investigator-with-tigergraph-and-graphrag", "markdown": "https://wpnews.pro/news/building-casework-an-agentic-fraud-investigator-with-tigergraph-and-graphrag.md", "text": "https://wpnews.pro/news/building-casework-an-agentic-fraud-investigator-with-tigergraph-and-graphrag.txt", "jsonld": "https://wpnews.pro/news/building-casework-an-agentic-fraud-investigator-with-tigergraph-and-graphrag.jsonld"}}