JEVelric：基于 TigerGraph 的 agentic 欺诈调查系统

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