JEVelric : An Agentic Fraud Investigation System on TigerGraph

TANMAY SAYARE — Thu, 24 Sep 2026 22:47:45 +0000

What we built

JEVelric is an AI agent that investigates card fraud the way a human
fraud analyst would: it takes a trigger — a risk score, a customer
complaint, or an analyst request — pulls the actual evidence from a
knowledge graph, weighs how confident it can be, asks for more evidence
when it can't be confident yet, and only then recommends an action —
citing exactly which policy rule justifies it.

Built for TigerGraph's HHGOA Agentic Fraud Investigation hackathon, on
the IEEE-CIS/Vesta dataset restructured as a fraud-investigation
benchmark: ~590,000 real card transactions, device/identity signals,
closed historical cases, and 20 held-out benchmark cases.

Architecture

Trigger → TigerGraph evidence retrieval (6 GSQL queries: transaction
window, device neighbors, region cluster, email cluster, closed-case
similarity, customer history) → GraphRAG context assembly → LLM signal
assessment → a deterministic policy engine (10 explicit rules, R1–R10)
→ stop-or-gather-more-evidence decision → SAR filing check → case
written back to the graph → schema-validated answer file.

The one architectural decision we'd underline: the LLM never picks an
action. It extracts signals — fraud probability, pattern match,
evidence sufficiency — and a plain, auditable, unit-tested policy engine
looks those signals up against a fixed rule table to decide what
happens. Every recommended action carries the exact rule number that
produced it. That split exists because a fraud policy needs to be
explainable to a regulator, not just plausible to an LLM.

How TigerGraph is used

Graph database: the actual relationship structure — cardholders, cards, transactions, device profiles, email domains, billing regions, and closed cases — connected as vertices and edges, not flattened rows. This is what lets a single query answer "does this card share a device with any other card in the last week" as a graph traversal instead of a full-table scan.
TigerGraph MCP: the agent's actual tool interface into the graph — schema creation, the six evidence-retrieval queries, and writing each completed investigation back as a Case vertex (case memory) all go through MCP, not a hand-rolled REST client.
Case memory: every resolved investigation is written back to the graph, connected to the transactions, cards, and closed cases it touched — so the next investigation involving a related entity has that history available.

Agentic capabilities

Uncertainty-gated evidence gathering. When the evidence is ambiguous, the agent doesn't guess — it requests specific evidence (customer verification, step-up authentication, analyst input) and re-assesses once it's available, changing its own recommendation if the new evidence warrants it.
Policy-governed, approval-routed actions. Every action carries an approval route — auto, team-lead, or fraud-manager — matching the actual operational reality that a fraud system doesn't get to unilaterally freeze someone's account.
A live investigation endpoint. Beyond the 20 batch cases, JEVelric exposes its orchestrator as both a REST endpoint and an MCP tool (investigate_case), so a new, previously unseen case can be submitted and investigated live, not just replayed from a fixed file.

What we learned

Most of the real difficulty wasn't the agent logic — it was making the
graph integration trustworthy. A few honest specifics:

TigerGraph MCP's file-loading tool expects a path on the TigerGraph server, not the machine running your agent — passing a local path fails silently with zero rows loaded and no error, which cost real debugging time until we traced it in the tool's own source.
pyTigerGraph's header-handling for programmatic loading jobs disagreed with what we assumed from the GSQL docs — headers need to be stripped for one loading path and kept for another, and getting this wrong silently loads your header row as a data record.
We evaluated an early-access GraphRAG/vector-retrieval MCP tool (grip-protocol) as an add-on for the retrieval layer. Its own status check quietly returned a fake demo-graph response instead of connecting to our real graph — good evidence for why we kept our own TigerGraph-MCP path as the default rather than trusting a 3-day-old, single-maintainer package with the benchmark.
Free-tier LLM rate limits (across three different providers, at different points) were a bigger operational bottleneck than any of the actual reasoning logic.

What we'd improve with more time

Full TigerGraph vector-backed retrieval for the policy/pattern/closed-case documents, replacing our current flat-file context assembly — the graph traversal side is solid, the document-retrieval side is still the simpler of the two.
A real human-in-the-loop approval UI for the L1/L2-routed actions, rather than routes being recommendation-only in the output.
Wiring TypeSafe's Jev as a structured, typed decision layer alongside the LLM assessment step — the architecture was built with this as a pluggable seam from day one, specifically so it could be added without touching the policy engine or state machine.

Repo

https://github.com/Tanmay-say/JEVelric

DEV Community: TANMAY SAYARE