iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A fraud alert is a starting point, not an explanation. In a project described by Kishan Vyas for the TigerGraph × Hacker House Goa hackathon, TigerGraph graph queries gather connected evidence, LangGraph coordinates an investigation workflow, an LLM interprets the evidence, and deterministic policy code gates proposed actions. The project article describes a useful architecture—not an independent audit or proof of production readiness.
What the project set out to investigate
The project aimed to turn transaction alerts into reasoned case files, produce suspicious activity reports (SARs) when the project’s criteria were met, and make recommendations both before and after additional evidence collection. Its benchmark task used six months of card transactions from the IEEE-CIS Vesta dataset alongside historical closed investigations. Vyas says the team targeted 20 cases.
The investigation is organized around four questions:
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →- What kind of fraud might be occurring?
- How far does the connected network reach?
- What is the potential financial exposure?
- Which next action is permitted by bank policy?
Possible actions named in the article include blocking an account, requesting step-up authentication, seeking managerial approval, or filing a SAR. Those are recommendations or workflow outcomes in the described project; the article does not establish that the system was connected to live banking operations.
#1 Best Overall
How the architecture divides the work
The design gives different jobs to graph queries, workflow orchestration, language-model synthesis, and policy code. That division matters: relationship calculations and authorization should not depend on a model improvising an answer.
| Component | Role described in the project |
|---|---|
| TigerGraph and custom GSQL queries | Return graph topology and calculated network signals, including relationships, paths, and counts. |
| LangGraph | Manage workflow state, evidence-gathering loops, sufficiency checks, and human-approval interrupts. |
| LLM | Synthesize the evidence returned to it into an investigation narrative and proposed next steps. |
| Deterministic policy rules | Authorize or block proposed actions and check policy before an action or simulated API call. |
| TigerGraph MCP adapter and GraphRAG precedent memory | Provide structured access to graph context and retrieve similar prior cases, as described by the author. |
| Next.js analyst dashboard, Cytoscape.js, and server-sent events | Present network information and live workflow updates in an analyst interface. |
How an alert becomes an investigation
1. Start with the alert and request relevant context
The workflow begins with a transaction alert. The agent can request targeted context through structured tools rather than treating the initial alert as a complete account of what happened.
Rank #2
2. Use graph queries for relationships and network signals
The described queries look for accounts that share devices or IP-related attributes, calculate paths from alerts to confirmed-fraud vertices, inspect money-flow patterns and cycles, and return bounded neighborhoods for visualization. These are questions well suited to database logic: whether two accounts share an entity, how many steps separate a case from a known fraud vertex, or whether a flow pattern exists.
Keeping those calculations in GSQL also makes the evidence source explicit. The model can explain what returned evidence may mean, but graph code—not free-form model reasoning—should establish the counts, paths, and connections.
3. Track risk, confidence, and evidence completeness
The project describes a triad of risk level, confidence, and evidence completeness. If risk is high but evidence is incomplete, the workflow may gather more context rather than treating an early conclusion as final. It also records next-best actions before and after evidence collection, making recommendation changes visible in the case trail.
4. Synthesize evidence, then apply policy gates
The LLM synthesizes the gathered material into a case narrative and proposed action. Deterministic bank-policy checks then constrain whether that proposal may proceed, with human approval interrupts included in the workflow design. This is a sensible separation of interpretation from authorization, but the project article does not independently verify that the controls prevent unsafe actions or model errors.
5. Record the case and surface it to analysts
The author says completed case states are written back as memory for retrieving similar investigations later. A dashboard built with Next.js and Cytoscape.js is described as displaying graph neighborhoods, with server-sent events providing live updates. The article also says SAR reports are generated when the project’s stated thresholds and pattern criteria are met.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteWhat the project reports—and what those figures establish
Vyas reports that all 20 benchmark cases ran through one workflow and that every model assertion was linked to canonical evidence identifiers. The article also reports live dashboard updates and automated SAR generation when project criteria were met. These are author-reported outcomes; the article does not provide independent validation or enough methodology to show how well the results generalize.
Best Value
The author additionally reports an 85% reduction in prompt token costs after moving graph pathfinding and counting into GSQL. The visible article publication line says “Posted on Sep 24” without a year, and no measurement method is presented in the reviewed page. Treat the percentage as a claim about this project, not an expected saving for other systems.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Practical lessons for a similar design
- Make evidence collection explicit. Treat an alert as a prompt to investigate connected identities, devices, transactions, and prior cases, not as a complete explanation.
- Use deterministic graph logic for deterministic questions. Keep entity matching, counts, path distance, and flow-pattern checks in query or application code.
- Give the workflow ownership of uncertainty. Track whether evidence is sufficient and provide a route to request more context or human review.
- Separate a recommendation from permission to act. Apply bank-policy rules outside the LLM and make approval requirements part of the workflow.
- Preserve provenance and changes. Link narrative assertions to evidence identifiers and record how recommendations change when new evidence arrives.
- Evaluate claims with reproducible methods. A case count or traceability percentage is most useful when the test set, definitions, and measurement procedure are clear.
The project is a concrete example of assigning graph computation, workflow coordination, evidence synthesis, and action authorization to separate parts of a system. Its reported benchmark and cost results remain claims by the project author rather than independently established performance.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
