The latest articles on DEV Community by Sushant Shekhar (@sushant_shekhar_c99a6b858). https://dev.to/sushant_shekhar_c99a6b858 https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4141664%2F4851b045-cabc-42e7-aefa-77f62647359a.jpg https://dev.to/sushant_shekhar_c99a6b858 en Sushant Shekhar Thu, 24 Sep 2026 17:37:12 +0000 https://dev.to/sushant_shekhar_c99a6b858/savanna-fraud-investigator-an-agentic-fraud-investigation-system-on-tigergraph-3nha https://dev.to/sushant_shekhar_c99a6b858/savanna-fraud-investigator-an-agentic-fraud-investigation-system-on-tigergraph-3nha <h1> Savanna Fraud Investigator: An Agentic Fraud Investigation System on TigerGraph </h1> <p><strong>Built for the TigerGraph Agentic Fraud Investigation HHGOA hackathon</strong></p> <h2> What we built </h2> <p>Fraud teams don't lack data — they lack time. An analyst investigating a single flagged transaction has to manually pull transaction history, trace connected cards and devices, check prior case outcomes, weigh a fraud policy, and decide what to do, often while the window to actually stop the money closes. We built <strong>Savanna Fraud Investigator</strong> to compress that loop into an agent that investigates, decides, and explains itself — without ever letting a language model be the one making the actual call on blocking a card or filing a report.</p> <p>The system ships two investigation paths on top of the same graph:</p> <ul> <li> <strong>A deterministic pipeline</strong> (<code>src/generate_cases.py</code>) that runs the identical evidence-gathering steps and a fixed policy engine over every case. This is what produced our 20 required answer files — reliable and reproducible by design.</li> <li> <strong>A genuinely agentic investigator</strong> (<code>src/mcp_agent.py</code>) that connects to a live TigerGraph MCP server and lets Gemini, through a LangGraph ReAct loop, decide for itself which graph queries to run and in what order. This path found things the fixed pipeline structurally can't — for example, billing-region velocity that looks like impossible travel — because it isn't locked into one investigation script.</li> </ul> <p>A local web dashboard sits on top of both: a case docket showing evidence, before/after next-best-action, SAR status, and case memory for all 20 cases, plus a button to run the live agent against any case and stream its real output.</p> <h2> Architecture </h2> <p>At the center is TigerGraph Savanna holding the IEEE-CIS-derived transaction graph — transactions, cards, devices, customers, and prior closed cases as first-class vertices and edges. Everything else is built to <em>never</em> replace graph analysis with model guesswork:</p> <ul> <li> <strong>GSQL layer</strong> (<code>tigergraph/</code>): schema, loading jobs, and four custom installed queries — <code>card_window</code> (transactions near a flagged one on the same card), <code>transaction_device</code> (device fingerprint lookup), <code>device_neighbors</code> (other cards sharing that device), and <code>hhg_write_case</code> (writes the finished investigation back as an <code>InvestigationCase</code> vertex — our case memory).</li> <li> <strong>Evidence layer</strong> (<code>src/evidence.py</code>, <code>src/tg_client.py</code>): a thin pyTigerGraph client that calls those four queries and normalizes results into typed evidence the rest of the system can reason over.</li> <li> <strong>Policy engine</strong> (<code>src/policy.py</code>): a fixed, non-negotiable R1–R10 rule set that owns verdicts, next-best actions, approval routes, and SAR eligibility. Neither LLM path can override it — an agent can gather evidence and explain a recommendation, but the actual decision of "block this card" or "file this report" comes from code, not a prompt.</li> <li> <strong>Synthesis layer</strong> (<code>src/synthesis.py</code>): grounds Gemini's explanations strictly in retrieved evidence, with a deterministic fallback if no API key is present — the pipeline always produces policy-compliant, non-fabricated output whether or not an LLM is in the loop.</li> <li> <strong>Contracts</strong> (<code>src/contracts.py</code>): every one of the 20 generated cases is validated against the hackathon's exact JSON schema before it's written to disk.</li> </ul> <h2> How we used TigerGraph </h2> <p>TigerGraph isn't a data store we occasionally query — it's the arbiter. Our policy explicitly treats the transaction's incoming risk score as <em>an investigation trigger, not a verdict</em>: probability of fraud only moves meaningfully once graph evidence (a burst of small authorizations on the same card, a device shared across multiple cards) actually corroborates it. A high risk score with no graph corroboration and no customer complaint gets closed as legitimate rather than escalated — we didn't want a system that just rubber-stamps the input model's score with extra words.</p> <p>The <code>hhg_write_case</code> query closes the loop by writing every finished investigation back into the graph as an <code>InvestigationCase</code> vertex, so future investigations — whether run through the deterministic pipeline or the agentic path — can retrieve prior outcomes for the same entities as case memory rather than starting cold.</p> <h2> Agentic design </h2> <p>The deterministic pipeline gives us reliability for the 20 required answer files. The agentic investigator is where the actual agentic capability lives: it's handed the TigerGraph MCP tool surface and decides for itself, case by case, what evidence it needs and in what order, rather than following one fixed script. Its tool access is deliberately restricted to read-mostly TigerGraph MCP tools plus the single write path — it can gather evidence and record a finished case, but it can't touch schema or delete data. The dashboard's "Run Live Agentic Investigation" button calls this path directly against <code>mcp_agent.py</code> and streams its real output, so the demo isn't simulated.</p> <h2> What we learned </h2> <p>Most of the real engineering work wasn't the graph queries or the policy rules — it was making sure "live TigerGraph evidence" actually <em>stayed</em> live all the way through a 20-case batch run, not just in a one-off connection test. We hit a genuinely subtle bug: our connection helper cached its result for the lifetime of the process, so if credentials weren't fully loaded at the very first call, every subsequent case in the batch silently fell back to document-only evidence with no error raised at all. It's a good reminder that "it worked when I tested it" and "it works across a full batch run" are different claims, and that a policy engine's decisions are only as trustworthy as the evidence pipeline feeding it — a silent fallback is more dangerous than a loud crash.</p> <h2> What we'd improve with more time </h2> <ul> <li>Add explicit health checks and fail-loud behavior around the graph connection, rather than allowing any case to silently fall back to document-only evidence</li> <li>Expand the agentic path's pattern coverage beyond the five documented fraud typologies, using the freedom the ReAct loop already has</li> <li>Add persistent approve/reject workflow state for analysts reviewing agent recommendations, rather than a stateless demo</li> <li>Stream the agent's reasoning to the dashboard live, rather than only showing output once a run completes</li> </ul> <p><em>Built for the TigerGraph Agentic Fraud Investigation HHGOA hackathon. Code: <a href="https://github.com/SHKsushant/savanna-fraud-investigator" rel="noopener noreferrer">https://github.com/SHKsushant/savanna-fraud-investigator</a></em></p> ai tigergraph hackathon fraud