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
TigerAttack is a fraud-investigation agent design, described in a project write-up by Rohit Sharma, that collects connected graph evidence and policy and case context before it reasons about a case or recommends an action. It was built for the TigerGraph × Hacker House Goa challenge. Its central idea is that the agent coordinates evidence gathering, deterministic calculations, policy checks and case updates, so that a language model explains and synthesizes findings rather than making a fraud judgment from a prompt alone.
What starts an investigation and what happens next
According to the write-up, an investigation can be triggered by four kinds of input: a suspicious transaction, a customer dispute, a fraud-risk signal, or an analyst-initiated investigation. Once triggered, the workflow runs through a fixed sequence of stages:
![Claude AI for Beginners Bible: [5 in 1] The Ultimate Guide to Automate Your Work, Save Hours Every Week, and Use AI for Real-World Results](https://m.media-amazon.com/images/I/415+fSJacsL._SL160_.jpg)
- Evidence collection, gathering the transaction, customer and account context for the case.
- Graph investigation, traversing related customers, cards or accounts, merchants, devices and identities.
- Historical case retrieval, pulling prior cases that resemble the current one.
- Pattern detection, identifying transaction patterns such as velocity.
- Risk and exposure assessment, quantifying the risk and the money at stake.
- Evidence-sufficiency check, deciding whether the evidence is enough to conclude.
- Additional evidence requests, if the check fails, followed by reassessment.
- Policy evaluation, applying the institution’s rules to the findings.
- Next-best action, recommending what the investigator should do.
- Case update, writing the outcome back to the case, with an audit trail and case memory.
The sequence matters because each later stage depends on evidence the earlier stages have already gathered and checked. The write-up presents the evidence-sufficiency check as a gate, not a formality.
The components and how they fit together
The application has two visible parts: a Next.js investigator interface and a FastAPI orchestration backend. The backend is the coordinator. It calls TigerGraph queries and MCP tools, runs GraphRAG retrieval, reads and writes historical case memory, performs the risk, pattern and exposure calculations, evaluates policy, issues evidence requests, produces action recommendations, updates cases, generates SAR drafts and writes audit logs.
#1 Best Overall
TigerGraph: the relationship layer
TigerGraph holds the central investigation graph. Its nodes represent customers, cards or accounts, transactions, merchants, devices, identities and prior cases. The write-up uses reusable GSQL queries for the recurring questions an investigator asks: transaction context, customer history, related entities, shared devices or identities, velocity, historical cases, exposure, and assembling an evidence pack. The value of the graph is that a shared device or identity between two accounts is a relationship to traverse, not a field to compare by hand.
GraphRAG: adding policy and case context
Graph data alone does not say what a pattern means under the institution’s rules. GraphRAG joins the structured graph evidence with contextual material: fraud policies, typologies, investigation procedures, regulatory requirements and historical case information. The combined result is the evidence pack that the reasoning layer receives. In this design, retrieval supplies the reasoning layer with the rules and precedents that a bare graph result would not contain.
MCP: the tool boundary
MCP (Model Context Protocol) sits between the agent backend and graph operations as a controlled boundary. Each graph operation is exposed as a tool, and each call returns structured results. Those structured results are what allow the system to record where a piece of evidence came from, which is the basis of the provenance claims discussed below.
Rank #2
Which parts are deterministic and which are the model
The clearest design decision in TigerAttack is the division of labor. The author assigns the calculations, rules and constraints to ordinary code, and reserves the reasoning model for work that needs judgment in language.
| Task | Assigned to |
|---|---|
| Risk calculations | Deterministic component |
| Transaction-pattern calculations | Deterministic component |
| Exposure calculations | Deterministic component |
| Policy rules | Deterministic component |
| Evidence-sufficiency decision | Deterministic component |
| Action constraints | Deterministic component |
| Evidence synthesis | Reasoning model |
| Investigation planning | Reasoning model |
| Pattern interpretation | Reasoning model |
| Explanation and uncertainty reasoning | Reasoning model |
| Natural-language case summaries | Reasoning model |
The practical effect is that a number such as exposure or a rule outcome such as a policy breach can be reproduced by running the same code on the same data, while the explanation of why the pattern matters is left to the model and can be checked against the evidence behind it. Case memory completes the picture: it keeps findings, evidence, decisions, actions, outcomes and investigation history so that later cases can retrieve them.
When the evidence is not enough
TigerAttack is designed to stop short of a conclusion when the evidence cannot support one. The write-up describes the path as follows:
- The evidence-sufficiency check runs as a deterministic step after evidence collection and graph investigation.
- If the evidence is insufficient, the workflow pauses and issues an evidence request. The write-up gives customer validation and step-up authentication as examples.
- When the requested information arrives, the workflow reassesses the case with the new evidence.
- Only then does policy evaluation and next-best action proceed.
This is the behavior that separates an evidence-gated agent from one that always produces a verdict. An investigator who reads a recommendation from this kind of system should be able to see whether it was reached after a sufficiency check passed or after a request was answered.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →What the reported results show
The author evaluated the pipeline against 20 benchmark cases and reported the counts below. These are pipeline-execution and grounding measures. The write-up states explicitly that they should not be read as a claim of 100% fraud-detection accuracy, and they do not establish real-world effectiveness, independent verification or production performance. The write-up is dated 23 September; the year is not displayed on the page and is inferred from context.
| Reported measure | Reported value | What the measure counts |
|---|---|---|
| Benchmark investigations completed | 20 of 20 | Cases that ran through the full pipeline |
| MCP calls completed | 140 of 140 | Tool calls that returned a result |
| Graph evidence items retrieved | 300 | Evidence items returned from TigerGraph |
| Historical case records retrieved | 100 | Prior case records returned by retrieval |
| Evidence requests and reassessments | 12 | Times the workflow requested more evidence and reassessed |
| Case-memory write/readbacks | 20 of 20 | Case records written and read back successfully |
| Audit events generated | 412 | Logged events in the audit trail |
| Grounding failures | 0 | Outputs flagged as not supported by the evidence |
| Automated tests passed | 94 | Project test suite results |
The figures show that the workflow runs end to end on this benchmark set, that tool calls and memory round-trips completed, and that the outputs were not flagged for grounding failures. They do not show whether the agent flags the right transactions, how often it misses fraud, or how it performs on data it has not seen.
What is still missing before production use
The author lists the following as future work, which indicates the project is not yet a fully production-hardened deployment:
- Production observability: authentication, metrics, tracing, monitoring and operational alerting.
- Evaluation breadth: broader testing on larger datasets and adversarial cases.
- Detection depth: more advanced temporal fraud detection.
- Investigator workflow: real-time investigation streaming, structured analyst feedback and richer graph visualization.
Analyst feedback in particular matters for any system like this. Without a structured record of whether investigators agreed with a recommendation, the benchmark counts cannot be turned into an accuracy measure.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Traceability as the design principle
The author states the principle that governs the design: “Every important conclusion should be traceable back to evidence.” This is the author’s own design statement from the project write-up, not an external standard. In the architecture it is supported by the structured MCP results that carry provenance, the evidence pack that the reasoning layer receives, the audit events and the case memory records.
Best Value
How to judge a system built this way
TigerAttack is useful as a reference for what to check in any graph-plus-language-model investigation tool. Ask the following questions of a design:
- Can each conclusion be traced to specific graph records or retrieved documents?
- Are risk, exposure and policy outcomes computed by code that gives the same answer on the same data?
- What happens when evidence is insufficient: does the system pause and request more information, or does it still conclude?
- Are the model’s explanations checked against the evidence they cite?
- Does the audit trail record requests, reassessments and final decisions?
- Is accuracy measured against labeled outcomes, not only pipeline completion?
- Are authentication, monitoring and alerting in place before the system touches live cases?
The write-up answers some of these questions in its architecture and leaves others open, which is a fair description of where the project stands.
Bottom line
TigerAttack is best read as a clearly reasoned reference architecture for evidence-grounded fraud investigation. Its strongest elements are the relationship-first graph model, the separation of deterministic checks from model reasoning, and the evidence-sufficiency gate. Its reported figures measure whether the pipeline runs and stays grounded, not whether it detects fraud accurately, and the author’s own list of remaining work defines the distance to production.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsQuick 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.
