GraphSentinel: Building an Agentic Fraud Investigation System on TigerGraph
Fraud detection systems usually fail in one of two ways: they're either black-box models that flag transactions with no explanation, or they're rule engines so rigid they miss anything novel. For HHGOA 2026, we set out t
Fraud detection systems usually fail in one of two ways: they're either black-box models that flag transactions with no explanation, or they're rule engines so rigid they miss anything novel. For HHGOA 2026, we set out to build something in between a system where every fraud decision is traceable back to evidence, and a human always has the final say.
The core idea
Fraud rarely lives in a single transaction. It lives in relationships a device shared across accounts, a card reused after a chargeback, a customer connected to a prior flagged case. Relational databases make these connections expensive to query. A graph database doesn't.
We modeled the whole domain customers, cards, devices, transactions, and investigation cases as a connected graph in TigerGraph, and let graph traversal do what SQL joins struggle with: surfacing multi-hop fraud rings in a single query.
Architecture
The system is a custom Node.js agent orchestration layer sitting between three components:
TigerGraph — holds the entity graph and runs the relationship queries that surface suspicious patterns (shared devices, repeated card usage, links to prior cases).
Deterministic fraud policy layer — a rules engine that turns graph query results into a fraud probability and a recommended action. This is intentionally deterministic, not ML-guessed, so every score is reproducible and auditable.
Gemini LLM layer — takes the structured evidence from the graph and policy layer and generates a plain-English explanation of why a case was flagged. We built in LLM failover so the explanation step doesn't become a single point of failure.
Sitting above all of that is a human approval step — the system recommends, it doesn't unilaterally act.
What a case looks like
Each of the 20 HHGOA investigation cases produces a structured JSON output containing:
Fraud probability score
Recommended action
Model consensus across evidence sources
SAR (Suspicious Activity Report) details
The full graph-derived evidence trail
That JSON is what powers the public dashboard, so anyone reviewing a case a judge, an analyst can see the graph evidence, the policy reasoning, and the LLM's explanation side by side, instead of just a verdict.
Why TigerGraph specifically
The fraud patterns that matter most (ring detection, shared-attribute clustering, multi-hop links to known bad actors) are exactly the queries graph databases are built for and relational databases are bad at. TigerGraph's query language let us express "find all transactions connected to this device within N hops" directly, instead of building brittle recursive joins.
What's next
This was built in a hackathon timeframe, so the obvious next steps are: expanding beyond the 20 seed cases with real transaction data, tightening the policy thresholds against false positives, and adding audit logging on the human-approval step itself.
Links
Live demo: https://graphsentinel-hhgoa.onrender.com/
GitHub: https://github.com/dealcetexplains-png/graphsentinel-hhgoa
Built for HHGOA 2026 with Shivprasad #Team Solora and Thanks @TigerGraphDB and @247pmstudio.
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.