Fraud rarely looks like fraud in a single row of data. It shows up in the connections: a shared IP address, a reused device, a chain of accounts that all trace back to one bad actor.
Investigators still find those connections by hand, cross-referencing CSVs and relational tables. One synthetic identity cluster can take hours to untangle, and by the time the ring is mapped, the money has moved.
For the Hackathon, we built FraudLens AI to close that gap. It is an agentic triage system that:
- 🔍 Investigates flagged transactions autonomously
- 🕸️ Maps the multi-hop blast radius of a threat inside TigerGraph
- ⚖️ Decides the next best action: autonomous freeze or human escalation
- 📄 Generates a compliance-ready Suspicious Activity Report (SAR) as a downloadable PDF
🎬 Demo
🏗️ Architecture
FraudLens has four layers. A React + Tailwind dashboard is the investigator's workspace. A Django backend streams the agent's reasoning live over Server-Sent Events. A LangGraph agent runs the investigation loop. TigerGraph is both the knowledge engine and the long-term case memory.
flowchart LR
classDef trigger fill:#EF4444,stroke:#7F1D1D,stroke-width:2px,color:#fff
classDef frontend fill:#3B82F6,stroke:#1E3A8A,stroke-width:2px,color:#fff
classDef backend fill:#10B981,stroke:#064E3B,stroke-width:2px,color:#fff
classDef ai fill:#8B5CF6,stroke:#4C1D95,stroke-width:2px,color:#fff
classDef db fill:#F59E0B,stroke:#78350F,stroke-width:2px,color:#fff
classDef out fill:#0EA5E9,stroke:#0C4A6E,stroke-width:2px,color:#fff
ML["ML Fraud Model<br/>flags high-risk transaction"]:::trigger
User((Investigator))
subgraph Client ["Frontend"]
React["React Dashboard<br/>Vite + Tailwind"]:::frontend
Plotly["Plotly 3D<br/>Blast-radius visualization"]:::frontend
end
subgraph Server ["Backend"]
Django["Django REST API"]:::backend
SSE["Server-Sent Events<br/>live chain of thought"]:::backend
end
subgraph Agent ["Agent Core"]
LG["LangGraph Agent<br/>investigation loop"]:::ai
LLM["LLM<br/>Gemini / OpenAI"]:::ai
T1["Tool: Blast Radius"]:::ai
T2["Tool: Policy Check"]:::ai
end
subgraph Graph ["Graph Database"]
TG[("TigerGraph<br/>entity graph + GraphRAG memory")]:::db
end
subgraph Decision ["Decision and Output"]
D{"Next Best<br/>Action"}:::out
L1["L1: Autonomous<br/>freeze"]:::out
L2["L2: Human<br/>approval"]:::out
SAR["PDF SAR<br/>report"]:::out
end
ML -->|alert| Django
User -->|opens case| React
React -->|API request| Django
Django -->|initializes state| LG
LG <-->|prompts and reasoning| LLM
LG -->|calls| T1
LG -->|calls| T2
T1 -->|GSQL queries| TG
TG -->|connected entities| T1
T1 -.->|writes embeddings back| TG
LG --> D
D -->|can act autonomously| L1
D -->|requires escalation| L2
LG --> SAR
LG -->|chain of thought| SSE
SSE -->|live updates| React
React -->|graph nodes| PlotlyData flows from trigger to decision, and memory flows back: finished cases are embedded and written into TigerGraph so later investigations have more context.
🐯 Why TigerGraph, and How We Used It
Fraud is a relationship problem. Customer A shares an IP address with Customer B, who shares a device ID with a known fraudster, Customer C. In a relational database, that is a chain of self-joins that gets slower and harder to write with every extra hop. In a graph database, it is a single traversal.
We modeled customers, accounts, devices, IPs, and transactions as a native graph in TigerGraph, then built GraphRAG on top of it.
Standard RAG retrieves text chunks by similarity. Our agent retrieves structure. It runs GSQL queries to pull the connected subgraph around a flagged entity and calculates its blast radius: every account, device, and money flow reachable within N hops. That subgraph becomes the context the LLM reasons over, so its claims are grounded in the data.
TigerGraph is also the agent's memory. When an investigation finishes, the agent embeds the case summary and writes it back to the graph, giving each new investigation more context to draw on.
🤖 How the Agent Works
We wanted an agent that does the investigation, not a chatbot that answers questions about it. LangGraph gave us the control flow to build that.
- Trigger: Our ML model flags a high-risk transaction.
- Investigate: The agent calls its tools to pull connected entities from TigerGraph and check the case against internal fraud policy rules.
- Reason in the open: Its chain of thought streams to the dashboard over Server-Sent Events, so investigators can watch it work and audit every step.
- Act: The agent chooses a next best action. When it can act on its own, it executes a freeze (L1 Execution). When the case needs human judgment, it escalates (L2 Approval).
- Report: It generates a downloadable PDF Suspicious Activity Report containing the findings and supporting evidence.
The L1/L2 split is deliberate. Autonomy handles the routine volume, and people stay in control of decisions that carry risk.
🧠 What We Learned
LLMs reason fluently, but without grounding they will confidently invent connections that don't exist. In financial crime, that matters: a fabricated link can freeze an innocent customer's account or let a real threat slip through.
Giving the agent tools that return real graph paths from TigerGraph changed how it behaves. It cites entities and relationships that exist in the data instead of guessing. The LLM is still probabilistic, but every claim it makes can be checked against an actual path in the graph, which gives investigators an evidence trail they can verify.
The LLM supplies the reasoning. TigerGraph supplies the facts. Neither is enough alone.
🚀 What We'd Build Next
- Multi-agent architecture: A triage agent that routes complex cases to specialists, such as a Synthetic ID agent or a Card Testing agent.
- Streaming ingestion: Connect TigerGraph to a Kafka stream so the agent reacts to fraud as it happens instead of waiting for batch triggers.
🔗 Links
- GitHub: github.com/HimanshurajNimse/TigerGraph-Fruad
- Demo video: youtu.be/cs-Tc8nTyoc
Built for the Hackathon.
