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
Casevertex (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.
