Agentic Fraud Investigation System with TigerGraph Article

Building an Agentic Fraud Investigation System with TigerGraph

What we built

For the TigerGraph Agentic Fraud Investigation hackathon, we built an AI agent that investigates fraud cases end-to-end - from an initial risk signal all the way to a defensible, explainable action. Rather than a simple flag-and-forward system, our agent gathers evidence from a knowledge graph, assesses how confident it actually is, asks for more evidence when it isn't sure, and only then recommends a next action - routed for human approval when policy requires it.

We tested it against 20 benchmark fraud cases built on the IEEE-CIS dataset, with each case producing a full investigation record: evidence gathered, risk assessment, uncertainty before and after additional evidence, the recommended action, and the reasoning behind it.

Architecture

• Graph database: TigerGraph Cloud (Savanna), used to store transactions, cards, identities, devices, and case history as a connected graph rather than flat tables
• Query layer: GSQL, for traversing relationships - e.g. finding every other transaction linked to a flagged card, or retrieving similar closed cases
• Reasoning engine: Groq API running openai/gpt-oss-120b, used for synthesizing evidence into a risk assessment and writing human-readable explanations
• Orchestration: a custom Python implementation rather than an existing agent framework - we wrote the investigation flow (trigger → gather evidence → assess → request more evidence if needed → decide → explain → write to memory) directly, which kept the logic transparent and easy to debug
• Interface: a Streamlit dashboard showing the Case Queue, risk score, uncertainty before/after evidence, decision and approval routing, and a dedicated explainability panel

How TigerGraph is used

Every case starts with a flagged transaction. From there, the agent traverses the graph outward - finding every other transaction sharing the same card or identity, checking whether device or IP data ties them together, and pulling any similar past cases that were previously closed. This is where the graph model earns its keep: a ring of 35+ transactions linked through one card is something a relational query would take a lot more work to surface cleanly.

Closed cases are stored back in the graph too, so future investigations aren't starting from zero - the agent explicitly checks case memory before making a decision, and the number of similar cases retrieved is part of its final explanation.

Agentic capabilities

• Uncertainty-aware decisions: the agent doesn't force a decision when evidence is thin. If confidence is too low, it explicitly requests more evidence (e.g. step-up authentication, customer validation) before acting
• Two-phase decisioning: every case records a recommendation before and after additional evidence arrives, so you can see the recommendation actually update as new information comes in
• Policy-aware approval routing: actions are routed through an internal approval matrix - some execute automatically, others require analyst sign-off, based on the action's risk tier
• Explainability: each case includes a written explanation of exactly what evidence was used, what wasn't available, and why the chosen action was the safest given that gap
• Case memory: findings are written back to the graph, with a grounding check confirming the write succeeded, closing the loop for future investigations

What we learned

Getting TigerGraph's REST API authentication working took a few attempts - we tried a couple of token endpoint variants before finding the one that matched our Savanna instance's actual behavior, since some documented endpoints didn't return what we expected. Once past that, GSQL's traversal capabilities were a strong fit for the problem - following connections between transactions, cards, and identities is exactly the kind of task graphs are built for.

We also learned that uncertainty needs to be a first-class output, not an afterthought. Early in development we had the agent always output a confident recommendation, and it made the system feel less trustworthy - explicitly separating "what we know" from "what we're still unsure about" made the case explanations far more useful.

What we'd improve with more time

• Deploy the app to a live, publicly reachable URL rather than local-only, with the full transaction dataset served from cloud storage instead of a local CSV
• Add automated evaluation against the 20 benchmark cases to track accuracy changes as we iterate
• Expand case memory retrieval to weight similarity more precisely (currently pattern-based; could layer in embedding-based similarity)
• Build out more granular approval tiers instead of a flat auto-execute / analyst-approval split

---

Built by Team Future Makers (Kaushik S, Nishan M, Muthu Karthigai Selvam S - VSB Engineering College) for the TigerGraph Agentic Fraud Investigation hackathon.