From Fraud Alert to Defensible Action: Building an Agentic Fraud Investigation System with TigerGraph

How we combined a temporal knowledge graph, GraphRAG, agentic investigation, and deterministic policy controls to turn suspicious transactions into auditable next‑best actions.

Every fraud team already has a way to generate alerts - a risk model scores a transaction, a rule fires, a customer calls in. That part is not the hard problem anymore.

The hard problem starts one step later: given an alert, what do you actually look at, when do you have enough to act, what do you do if you don’t, and what are you allowed to do once you decide?

Those four questions are what our system for the TigerGraph × Hacker House Goa fraud investigation challenge is built around.

This post covers the architecture, temporal safety, GraphRAG, the deterministic decision authority, a real benchmark case (HHG‑014), and what an actual LLM‑orchestration experiment told us about where a model does and doesn’t belong here.

Every number below comes from the repository, not from memory.

Live demo: https://hhgoa-fraud-investigation.onrender.com
GitHub: https://github.com/arvind-555/hhgoa-fraud-investigation

1. Fraud investigation is not classification

The challenge dataset (IEEE‑CIS, anonymized, 590,742 transactions with a risk score in place of a label) makes the temptation obvious: train a classifier, threshold the score, done - not what the challenge asks for, and not what a fraud analyst does.

An analyst who opens a flagged transaction doesn’t output fraud: 0.83.

They ask: is this card connected to anything else I should worry about? Do I have enough to act, or do I need to check with the customer first?

The output isn’t a probability - it’s a decision about what happens next, and who has to sign off on it.

Our system answers that question, not the classification one: it investigates the transaction’s neighborhood, gathers evidence, decides whether that evidence is sufficient, and - only under fixed policy - recommends an action with an approval route.

2. Why relationships matter

A single transaction row tells you an amount, a channel, a merchant category.

It does not tell you that the device behind it was used by eleven other customers last month, or that its device profile matches one that funded a confirmed‑fraud case three months ago.

Those facts only exist as relationships: Customer owns Card, Card made Transaction, Transaction came from Device, Device seen on other Cards, other Cards belong to other Customers.

Fraud rings are almost never visible in one row - they’re visible in the shape of the graph around it.

3. Why TigerGraph is central

We built one graph, FraudInvestigation, on TigerGraph 4.2.5 (Savanna), separate from the pre‑existing Transaction_Fraud graph - the code refuses to run against anything else by construction (the graph name is checked and hard‑fails otherwise).

The schema has 9 core vertex types and 18 relationship types (each with an automatic reverse edge):

• Vertices: Customer, Card, Transaction, DeviceProfile, EmailDomain, BillingRegion, ClosedCase, FI_Case, TextChunk
• Edges:
  • OWNS / OWNED_BY (Customer → Card)
  • MADE / MADE_BY (Card → Transaction)
  • NEXT / PREV (Transaction → Transaction)
  • FROM_DEVICE / DEVICE_OF (Transaction → DeviceProfile)
  • SEEN_ON / SEEN_BY (DeviceProfile → Card)
  • PURCHASER_EMAIL, RECIPIENT_EMAIL (→ EmailDomain)
  • BILLED_IN (Transaction → BillingRegion)
  • CLOSED_ON_CARD, CLOSED_ON_CUSTOMER, CLOSED_INVOLVES, CLOSED_CONNECTED_TO (ClosedCase → …)
  • CASE_ON_CARD, CASE_TXN, CASE_CONNECTED_TO, CASE_CITES_DEVICE, SIMILAR_CASE (FI_Case → …)
  • DESCRIBES (TextChunk → ClosedCase / FI_Case)

To be precise about the division of labor: TigerGraph stores the connected facts and answers traversal queries. It does not reason about fraud.

Every query (fi_shared_devices, fi_connected_entities, fi_card_history, fi_prior_cases, fi_txn_context, fi_customer_history, fi_text_chunks) returns raw, time‑bounded neighborhoods and counts.

Interpreting them happens entirely in application code (src/fraud_tools/, src/agent/).

The graph answers “what’s connected to what, as of when”; it doesn’t decide anything.

One detail worth calling out: fi_shared_devices hub‑gates by design.
A device profile shared by an implausible number of customers (a null/default fingerprint, say) is never expanded -