DEV Community: Subhojyoti Maity

Kavach, final round: a fraud investigator that shows its work, on TigerGraph

Subhojyoti Maity — Sat, 31 Oct 2026 08:13:17 +0000

TigerGraph x Hacker House Goa 2026, final round. Team PixelPaws: Subhojyoti Maity and Arni Bachhar.

In the first round we built Kavach ("shield"), an agent that investigates card-fraud alerts on a TigerGraph graph. The final round raised the bar: 18 new alerts, 650,938 transactions (July 2016 to January 2017), the bank's 5,585 closed cases, a written Fraud Policy v1.0, and 14 challenges that read like a bank's audit checklist. This post covers what we built and how TigerGraph carries the weight.

The problem: an alert is a reason to look, not a verdict

A bank's fraud model flags a transaction. Someone then has to decide: is it fraud, how far does it go, which other cards are involved, what should the bank do, and must it file a suspicious activity report (SAR)? Wrong one way, the fraud keeps running. Wrong the other, an innocent customer gets blocked.

It is tempting to paste the alert into an LLM and ask for a verdict. For a bank, that is the wrong design:

It cannot be re-run. An examiner asking "why did you block this card?" needs the queries, parameters and rows behind the answer, not a paragraph.
Free text is an attack surface. Six of the 18 alerts carry hostile text. A model that reads it can be steered by it.
It cannot be held to a policy. The policy says who may approve what, when a report is required and when to escalate. Those rules belong in code with unit tests.

So in Kavach, tools and policy decide, and the model only writes prose.

Every alert goes through nine fixed steps, in the same order every time:

Intake. The free text becomes data: quoted, redacted, zero weight. The model never sees it.
Gather. Graph tool calls (card history, device and email neighbourhoods, closed cases), each traced with its parameters and returned ids.
Detectors. One-card, network, history and typology detectors, plus grown detectors a human L2 approved.
Evidence model. Likelihood ratios calibrated on the closed cases, combined over independent evidence groups into a probability.
Policy engine. Fraud Policy v1.0 as code (R1 to R10, section 3a, approval routes): verdict, actions with routes (auto, L1, L2), evidence requests.
Episode. Affected transactions, connected cards, exposure.
Recall. Fused precedent, ring component and case memory, attested at zero weight.
Narrative. A facts JSON goes to the LLM (Google Gemini gemini-3.8-flash), which writes the summary and SAR narrative. Every id in its text is checked; on failure a template is used and recorded.
Attest and persist. Every claim records what, the evidence ids, how (query plus parameters) and when (timestamp plus dataset version). The case is written back to TigerGraph and read back before the answer may say written_to_graph: true.

A harness enforces hard bounds (80 tool calls per case, 90 s per call, 15 minutes per case) and fails closed. Tools sit behind one registry with three lanes: TigerGraph installed queries (--backend tg), the TigerGraph MCP server (--backend mcp) and a local DuckDB mirror (--backend duck).

How we used TigerGraph

The graph lives on a Savanna workspace (TigerGraph 4.2.5) at the smallest size, TG-00: 13 vertex types (from Customer, Card and Transaction to ClosedCase, InvestigationCase, CaseEvent, Approval and Detector), 650,938 transactions and about 3.6M edges, with counts checked against the source files.

Installed GSQL queries are the agent's tools. There are 45 installed queries, all read-only. Each tool is one query with typed parameters, so "who else paid this recipient email domain?" is a traversal with accumulators, not a prompt. On the TigerGraph lane there is no fallback to DuckDB: a graph failure is an incident.

Vector search fused with traversal. Closed-case notes, policy sections and investigation summaries carry 384-d embeddings searched with vectorSearch(). The interesting query is fused_precedent. It walks from the case card to its recent transactions, to the rare elements they carry (a device profile, recipient email domain or billing region used by 25 or fewer cards), to the other cards using them, to every closed case on those cards, then runs vectorSearch(..., {candidate_set: X}) over exactly that set. The fused top 5 differed from plain vector search on 13 of 13 cases with connected precedent, and from plain traversal on 9 of 13. On two legitimate alerts (HHF-014, HHF-016), traversal alone ranked five confirmed frauds first; the fused query ranked five cleared cases first.

Connected components for rings. ring_wcc runs label propagation for weakly connected components over a card graph whose edges are rare elements shared by atypical transactions in a 30-day window. Without the "atypical" restriction, the rules percolated into one 600 to 1,100 card component on every alert. With it, 8 of the 9 legitimate alerts stay single cards, and with no detector input it recovers 14 of the 16 cards in the HHF-006 ring.

MCP, restricted to an allowlist. On the MCP lane the only MCP tool called is tigergraph__run_installed_query, and only for query names on an allowlist built from our own read-only GSQL files. Any other name raises PermissionError before a call. No GSQL, upsert or schema tool is reachable, and the LLM never sees a tool.

Write-back, read-back, hash chains. Each investigation is upserted as an InvestigationCase with edges to its card, transactions, devices and similar closed cases. Edges use vertex_must_exist, so a link to a missing id is refused instead of creating an empty vertex. Case events and approvals are written insert-only with new_vertex_only; approvals form a sha256 hash chain, and the graph copy is read back and compared by count, chain hash and digest. All 18 answers carry written_to_graph: true only after that read-back.

The innovation: a detective that grows its own detectors

A miner searches seven generic pattern families (258 grid points) over the 5,585 closed cases in 24 seconds, without reading the analysts' notes. It only proposes patterns that separate confirmed fraud from both normal traffic and cleared customers, with a significance test corrected for the whole search.

Searching blind, it put both of the bank's undocumented typologies on its shortlist: the just-under-$500 four-purchase burst and an anonymous-proxy device ring. It also proposed one detector nobody wrote: a fan-in spike where a rarely used recipient email domain is suddenly paid by three or more cards in one day (8 confirmed-fraud cases, 0 cleared, lift 18).

Nothing joins the toolkit until a human with the L2 role approves it. An analyst token was refused first and logged as denied; the lead then approved it with the L2 token. Here is what that detector changes on HHF-006, where the analyst asked what several affected cards have in common:

arm	HHF-006 decision
no grown detector, no typologies	uncertain, p 0.42; decline, case, monitor, escalate; no report
typologies only	fraud, p 0.96, card_not_present_fraud; block and case; no ring, no report
full system	fraud, p 0.88, undocumented ring: 3 transactions ($967.68) on the case card, 16 connected cards paying recipient domain sc.rr.com; BLOCK_CARD (L1), CREATE_CASE, FILE_REPORT (L2), MONITOR_CONNECTED_CARDS, ESCALATE_TO_ANALYST

It changes no other case in the pack, so it cannot act against a legitimate customer elsewhere. On TigerGraph it runs through 13 installed GSQL mirrors and gives the identical decision.

Resilience: fail closed

Graph or tool fails mid-run: one retry for a transient error, then an incident record, exit code 2, no answer file, nothing claimed as saved.
Model times out or returns garbage: template prose, fallback recorded, decisions unchanged.
Hostile text: parsed as data with zero weight; decisions are identical with and without it, and it never reaches a prompt.
Wrong role tries to approve: the role comes from a server-side bearer token, never the request body. The wrong role gets a 403 and a denied record in the append-only chain, and the route uses the server's own exposure, so a caller cannot lower it.
Same case twice: identical decisions and a recorded re-run event.

Each has a fault-injection drill (KAVACH_FAULT=graph:down, tool:any:5, llm:garbage).

Results

Our 18 answers: 7 fraud, 9 legitimate, 2 uncertain.

Organizer grader: 18 of 18 answered, hard 0, policy 0, warnings 0.
kavach attest --all re-runs every attested claim: 0 failing.
Decisions identical on the DuckDB and TigerGraph lanes (18 of 18, 330 of 330 identical tool outputs); the MCP lane reproduces them on the cases we re-ran through it. The same case twice gives the same answer.
361 tests passing.
Round 1 re-scored against the bank's real outcomes: 19 of 20 verdicts right, no legitimate customer blocked or reported.
On three other banks' GSQL schemas from the mentors (ISO 20022, BIAN, T24), with the answer key stripped, our mapper got the target right on 81 of 82 items (72 of 82 when the mapping kind must also match).

Honest limitations

Customer and analyst replies are simulated deterministically from the evidence. Every answer file states that assumption.
January has no labels, so we read the January risk score as near-uninformative, and some January templates cannot be backtested.
The grown-detector library is grid-bound: it searches shapes a human wrote, at grid points we chose, and the accepted detectors rest on 5 to 8 fraud cases each. One grown signal alone cannot make a verdict.
ring_wcc confirms rather than changes the six ring answers today. It also places a legitimate alert's card (HHF-013) in the same component as the HHF-006 ring, which a human reviews.

What we learned about TigerGraph

What worked first time:

vectorSearch() with a candidate_set taken from a traversal. Asking for k equal to the set size returns a distance for every candidate; the ranking matched our local cosine to 4 decimals on all 18 cases.
Label propagation with MapAccum<STRING, MinAccum<INT>> and a WHILE ... LIMIT loop compiled and ran on the first attempt.
new_vertex_only and vertex_must_exist are exactly the append-only and no-invention guarantees an audit trail needs.
CREATE OR REPLACE QUERY without INSTALL works as a quick compile check before the slow install.

Where we lost time:

A query result containing the text "Runtime Error:" came back as HTTP 400 with a correct body, so a good result looked like a failed query. That cost us a debugging hour.
A missing numeric value loads as 0, so null and 0 cannot be told apart afterwards.
The MCP server defaults to ports 9000 and 14240, while Savanna serves everything on 443.

On our wish list: an offline GSQL lint, nullable attributes, and a bulk vector loader.

Kavach: building a fraud investigator that knows when a risk score is lying

Subhojyoti Maity — Wed, 23 Sep 2026 18:44:22 +0000

Kavach: building a fraud investigator that knows when a risk score is lying

TigerGraph x Hacker House Goa 2026, Task 4: Agentic Fraud Investigation. Team PixelPaws.

A bank's fraud model gives every card transaction a risk score. The task handed us 590,742 transactions, 5,565 closed investigations and 20 open alerts, and one warning in capitals: a risk score is a reason to look, never a verdict. Half of the 20 alerts are legitimate. The job is to decide which half, how far each fraud goes, and what the bank should do next under a written fraud policy, and to write each case back into the graph so the next investigation can find it.

We built Kavach ("shield"). This post covers what we built, how TigerGraph fits in, and the handful of things the data taught us that no amount of prompt engineering would have.

The shape of the problem

Every answer has three parts: an internal case (verdict, pattern, affected transactions, connected cards, exposure, evidence), a suspicious activity report when the policy calls for one, and the next best action before and after the evidence the agent asks for. Everything is scored against a hidden key, and every ID has to exist in the data.

That rules out letting an LLM decide anything. In Kavach, tools and Python decide, and the LLM writes. Verdicts, amounts, IDs, actions and approval routes come from detectors, a calibrated evidence model and a policy engine. The LLM (Groq openai/gpt-oss-120b) writes the summary, the SAR narrative and the description of new fraud patterns from a facts JSON. Every ID it writes is checked against those facts, and a template takes over if it slips.

Architecture

case -> GATHER -> DETECT -> ASSESS -> initial actions -> ask the customer? -> simulated reply
     -> ASSESS -> final actions -> RECALL similar cases -> NARRATE -> write back to TigerGraph -> answer file

GATHER pulls the card's history, the customer's cards, the device profile and every other card on it, the billing region, closed cases touching any of these, and the history of the underlying account.
DETECT runs general detectors in three families: single-card (sequence, device, region, match flags, score, the customer's words), cross-card (device rings, fixed-amount templates, repeated bursts) and history (repeat compromise, device precedents).
ASSESS combines the strongest signal from each independent evidence group into a log-odds, so ten correlated device signals count once.
The policy engine is Fraud Policy v1.0 as code: rules R1 to R10, the approval table, and "a case is not a report" (section 3a). It is unit-tested rule by rule.

How we used TigerGraph

The graph holds customers, cards, transactions, device profiles, email domains, billing regions, the bank's closed cases, and the agent's own InvestigationCase vertices. Every agent tool is an installed GSQL query: card_history, device_neighbors, region_activity, holder_fraud_history, closed_cases_for, amount_peers. The agent runs the same code against TigerGraph (through pyTigerGraph or the TigerGraph MCP server) and against a DuckDB copy used for analysis. A parity test checks that both lanes give the same answers.

The question "what else happened on this device?" is a two-hop traversal, Transaction to DeviceProfile to Transaction to Card. It is the question that cracks the hardest cases.

Numbers from our Savanna (4.2.5, free tier) run:

Load: 590,742 transactions, 202,440 underlying accounts, 9,705 device profiles, 5,565 closed cases and about 3.3M edges, posted to a GSQL loading job in 50k-line chunks in about 6 minutes, every line valid.
Queries: 20 installed queries (17 graph tools plus 3 vector searches); the graph tools answer in about 100 ms each.
MCP: the same installed queries also run through the TigerGraph MCP server, and the agent's decisions are identical on both paths.
TigerVector: 384-d embeddings of every closed-case analyst note and of the policy text live on the vertices; vectorSearch() finds, for a sub-$500 burst, exactly the closed cases the analysts labelled undocumented.
Case memory: every investigation is written back as an InvestigationCase vertex with edges and an embedding, read back before we mark it written, and found again by the next investigation on the same card.

Two things tripped us. proxy is a reserved word in attribute lists, but only when another attribute follows it. And a fresh workspace came with a sample solution whose global Card type collided with ours, so we build our graph with graph-local types in a schema change job.

What the data taught us

1. A card id is not a person. customer_id is derived from the card issuer field, so a single card id can pool thousands of real accounts; one of ours had 10,332 transactions across dozens of regions. "This region is familiar to the card" means nothing on such a card. We rebuilt the underlying account as card1 | billing region | account start day (the start day comes from D1, days since the account opened) and moved every baseline to that account.

2. The closed cases are a nearly complete label set. Confirmed-fraud transactions are 3.4% of July to October traffic. An account with an earlier confirmed-fraud case turned out to be fraud in 1,059 later cases and cleared in none.

3. The same score means different things. Calibrated on the closed months, a score above 0.8 is 97% fraud for product C without an identity record, and 9% for product R. Kavach reads the score through that calibration instead of at face value. That single change turned several "high score, looks scary" alerts into correct legitimate closes.

4. Selection bias hides in the labels. Every cleared closed case was a high-score false alarm (0.82 to 0.94). Compare fraud with cleared naively and a new device looks exculpatory. We fit every signal's likelihood ratio within each product, against both the whole population and the cleared cases.

5. Other cards solve cases. A device profile seen on only 5 cards in six months paid about $100 on five customers' cards in six days. Nothing on any single card looks wrong. In the closed months that shape was 7 to 11 times more common in fraud than in normal traffic, and Kavach links the cards and recommends monitoring them under R6.

6. Some fraud has no name. Two patterns fit none of the five documented typologies: four online purchases in 30 minutes, each priced just under $500, repeated across a dozen cards; and a scripted phone profile, always new to the account and always behind an anonymous proxy, buying small amounts on 28 cards. Kavach labels both undocumented, describes them in its own words, and files a report under R9.

Results

Eleven cases came out as fraud, eight as legitimate and one as uncertain (escalated with the evidence), and all 20 files pass our validator. Every investigation is in TigerGraph.

Case	Verdict	Pattern	p	Exposure	SAR
HHG-001	legitimate	none	0.06	$0.00	no
HHG-002	uncertain	card_not_present_fraud	0.53	$292.36	no
HHG-003	fraud	out_of_region_use	0.93	$165.93	no
HHG-004	fraud	card_not_present_new_device	0.88	$128.33	no
HHG-005	legitimate	none	0.09	$0.00	no
HHG-006	fraud	undocumented	0.97	$1,906.07	yes
HHG-007	fraud	account_takeover	0.97	$228.88	no
HHG-008	fraud	card_not_present_fraud	0.93	$166.97	no
HHG-009	fraud	card_not_present_fraud	0.89	$30.02	no
HHG-010	legitimate	none	0.03	$0.00	no
HHG-011	fraud	card_not_present_new_device	0.96	$131.30	yes
HHG-012	legitimate	none	0.03	$0.00	no
HHG-013	legitimate	none	0.03	$0.00	no
HHG-014	fraud	undocumented	0.97	$439.61	yes
HHG-015	legitimate	none	0.03	$0.00	no
HHG-016	fraud	card_not_present_new_device	0.95	$59.67	yes
HHG-017	legitimate	none	0.04	$0.00	no
HHG-018	fraud	out_of_region_use	0.97	$124.08	no
HHG-019	fraud	card_not_present_new_device	0.96	$99.92	yes
HHG-020	legitimate	none	0.03	$0.00	no

Knowing when to ask

When the evidence is short of a decision, Kavach does what the policy says: it verifies before blocking (R1), opens a case (section 3a), and simulates the customer's reply from the evidence it gathered without the customer. Fraud-leaning evidence leads to a denial, legitimate-leaning evidence to a confirmation, and balanced evidence to no reply within 24 hours (R4, then escalation under R8). Every answer records the initial actions, the assumed reply, the final actions, and what changed.

Lessons

Hand-investigate before you automate. We wrote 20 SQL dossiers before any agent code, and almost every detector traces back to one of them.
Measure every weight. Three of our intuitions were wrong: new devices, high scores, and region familiarity.
Keep the LLM on prose. It is very good at writing a FinCEN-style narrative from facts, and it should never be the thing deciding.

Code: https://github.com/MONSTERBOY110/hhgoa-tigergraph. Built for TigerGraph x Hacker House Goa 2026. Thanks to @TigerGraphDB and @247pmstudio.

DEV Community: Subhojyoti Maity

Kavach, final round: a fraud investigator that shows its work, on TigerGraph

The problem: an alert is a reason to look, not a verdict

How we used TigerGraph

The innovation: a detective that grows its own detectors

Resilience: fail closed

Results

Honest limitations

What we learned about TigerGraph

Links

Kavach: building a fraud investigator that knows when a risk score is lying

Kavach: building a fraud investigator that knows when a risk score is lying

The shape of the problem

Architecture

How we used TigerGraph

What the data taught us

Results

Knowing when to ask

Lessons