Building Casework: An Agentic Fraud Investigator with TigerGraph and GraphRAG

A suspicious transaction starts an investigation. The harder part is deciding what evidence to gather, what remains uncertain, and which action is justified.

We built Casework for the TigerGraph × HHGoa challenge to explore that problem.

Casework is a fraud investigation application that connects graph evidence, document retrieval, a local language model, and policy rules. It follows a case from an initial trigger to a recorded recommendation, preserving the evidence and decisions along the way.

Our aim was to make the investigation understandable to someone reviewing it afterward. An analyst should be able to see why an action was recommended, what information was missing, and what changed when new evidence was introduced.

Source code: github.com/Dhruvhash/casework-agent

01 — What we built

Casework provides a browser interface for investigating the challenge’s fraud cases.

An investigation begins with a customer, a card, and a flagged transaction. The application retrieves relevant relationships from TigerGraph, calculates transaction signals, searches historical cases and policy documents, and produces a structured investigation record.

The interface presents:

• Case progression: the current status, verdict, and investigation summary.
• Graph evidence: relationships between the transaction and connected entities.
• Uncertainty: missing information and unresolved questions.
• Recommendations: actions before and after additional evidence.
• Approval routes: which recommendations require human review.
• Report drafts: suspicious activity reports when required by the challenge policy.

The repository includes the 20 benchmark answer files in the root cases/ folder, named HHG-001.json through HHG-020.json.

Each answer contains evidence, findings, affected transactions, exposure, evidence requests, and the initial and final recommended actions. The application also records execution traces containing graph context, retrieved document identifiers, model planning output, and MCP calls.

02 — The architecture

We implemented a custom Python agent with a bounded investigation workflow.

The workflow is:

Investigation trigger
        │
        ▼
Graph evidence through TigerGraph MCP
        │
        ▼
Transaction signals and relationship analysis
        │
        ▼
Model proposes retrieval and evidence requests
        │
        ▼
Vector retrieval of policies, history, and memory
        │
        ▼
Evidence review and uncertainty assessment
        │
        ▼
Policy rules and approval routing
        │
        ▼
Validated case record and report draft
        │
        ▼
Graph persistence and versioned case memory

The language model has specific responsibilities within this flow. It receives graph facts, proposes a semantic search query, selects a permitted evidence request, and reviews the retrieved evidence.

Its output must match structured schemas. It cannot issue arbitrary GSQL or execute financial actions.

Policy code determines the action routes. This keeps recommendations traceable to explicit rules rather than leaving approval decisions to generated text.

03 — How we use TigerGraph

Fraud investigations involve relationships that are difficult to understand from an isolated transaction row.

Our graph represents customers, cards, transactions, device profiles, email domains, billing regions, historical closed cases, generated investigation cases, and supporting documents.

Starting from a flagged transaction, GSQL retrieves the customer’s history, known card activity, relevant device relationships, and connected historical evidence.

That context helps answer questions such as:

Is this amount unusual for the customer? Has this device profile appeared before? What other recent activity shares the profile? Is there relevant historical fraud evidence?

The application then performs additional analysis on the retrieved graph neighborhood. Python code calculates connected components and node degrees and checks for a shared-origin motif.

GSQL performs graph retrieval; the application performs these additional neighborhood algorithms.

The shared-origin check considers multiple attributes together, including activity across customers, new-device indicators, and anonymous or hidden proxy attributes. Sharing a generic device profile alone does not establish fraud.

A modeling decision that mattered

The dataset does not provide a card ID for every transaction.

We therefore use explicit historical and trigger anchors to establish card-to-transaction relationships. We do not assign every transaction belonging to a customer to their flagged card.

This affects the reliability of later conclusions. A card-testing pattern, for example, requires evidence that the transactions actually belong to the same card.

04 — How GraphRAG grounds the investigation

Graph evidence establishes relationships and transaction context. Retrieved documents add relevant policies and historical examples.

Casework combines both sources in its GraphRAG workflow.

After analyzing the graph, the model proposes a concise search query. The application embeds that query and calls installed TigerGraph vector search queries to retrieve:

The model reviews selected evidence with source references. It returns evidence indices and remaining uncertainties, and the application rejects indices outside the supplied evidence list.

Historical cases provide analogies. A similar earlier fraud case can explain why a signal deserves attention, but its outcome does not determine the current case.

Time constraints also matter. The workflow filters transaction context and historical cases against the investigation’s opening time so that later outcomes do not become evidence for an earlier decision.

05 — The agentic capabilities

The agent adapts parts of its investigation to the evidence it receives.

It can:

1. Plan retrieval from the current transaction and graph facts.
2. Propose additional evidence through permitted request types.
3. Review retrieved context and identify unresolved questions.
4. Update recommendations when an explicit simulated response is supplied.
5. Record a stopping reason when available evidence cannot settle the question.
6. Retrieve prior investigation memory as context for subsequent cases.

The evidence request types include customer validation, step-up authentication, and analyst information.

The workflow is bounded. It does not keep retrieving information indefinitely or assume that another graph query will resolve every uncertainty.

For example, transaction history can establish that a purchase is unusual. It may still be unable to establish whether the customer authorized it. Customer verification is then a meaningful next step.

Simulation boundary: The prototype records evidence requests and supports explicitly simulated responses. It does not contact customers or connect to banking authorization systems.

06 — Following a case: HHG-010

The saved HHG-010 investigation provides a concrete example of case progression.

These observations justify investigation, but they do not establish whether the purchase was authorized.

Before verification

After a simulated customer denial

For the demonstration, we explicitly simulate the customer denying the transaction. The policy engine then updates the recommendations:

The case retains both recommendation sets and records why they changed.

The denial is labeled as simulated throughout the investigation. The block is a recommendation, and the report is a draft awaiting review. No real card block or regulatory filing occurs.

07 — Policies, explanations, and uncertainty

We implemented the challenge’s action rules in a deterministic policy module.

Each recommendation contains three essential fields:

{
  "action": "BLOCK_CARD",
  "route": "L1",
  "reason": "R2: simulated customer denial; recommended block requires human approval."
}

This structure lets an analyst inspect the proposed action alongside its approval requirement and policy basis.

When the challenge policy requires a suspicious activity report, Casework creates a draft containing the subjects, activity dates, exposure, and supporting narrative. It also states the evidence limitations and identifies simulated information.

The displayed probabilities are heuristics. They are not calibrated predictions from a trained fraud model.

Missing information also limits which conclusions are defensible. For example, the available data does not establish merchant identity or settlement status, so recurring-merchant and cleared-purchase conclusions require further verified evidence.

08 — Case persistence and memory

Casework keeps generated investigations separate from the supplied historical outcomes.

The persistence code writes an investigation vertex to TigerGraph and connects it to the customer, relevant transactions, and cited documents. It checks the server acknowledgment and reads back the submitted case payload before marking the case as written to the graph.

The memory module creates versioned snapshots containing:

• The case record.
• A revision identifier.
• Recording and case-context timestamps.
• A statement identifying generated conclusions and simulated responses.

These snapshots can be retrieved as context during later investigations.

This supports continuity between cases without treating earlier generated conclusions as confirmed ground truth. It also does not retrain the language model.

That distinction prevents uncertain findings from becoming stronger merely because the application has repeated them.

09 — What the current results show

The local project contains all 20 benchmark answer files.

In the saved set inspected for this article:

The fraud case includes the explicit simulated customer denial described above.

These counts describe the saved outputs, not investigation accuracy.

Many cases remain uncertain because the available transaction evidence cannot establish customer authorization. Generating all required files demonstrates workflow coverage; measuring accuracy requires verified outcomes and a separate evaluation.

The prototype includes graph retrieval, evidence review, policy routing, case generation, and graph persistence. Reliable operation also depends on service availability, MCP connectivity, and accurate failure reporting.

10 — What we learned

Graph modeling determines the quality of the investigation.

An incorrect card relationship can lead to a convincing but unsupported fraud pattern. Getting entity attribution right matters before any model writes an explanation.

Uncertainty needs to be visible throughout the product.

It belongs in the evidence record, case status, recommendation, and interface. Analysts need to understand what is unresolved while they are making decisions.

Memory needs provenance.

A confirmed historical outcome, a generated hypothesis, and a simulated customer reply have different evidential value. Retrieval should preserve those differences.

Operational failures affect trust.

A slow graph service or failed MCP process can prevent an investigation from completing. The interface must distinguish a saved result from a successful new run and report failures clearly.

A smaller model benefits from a well-defined role.

Keeping planning and review bounded makes outputs easier to validate. Graph analysis and policy code provide structure around the model’s contribution.

11 — What we would improve with more time

Casework gave us a practical way to bring graph evidence, retrieval, language models, and policy code into one investigation workflow.

The part we want to keep developing is the case record: a clear account of what is known, what remains uncertain, and why the next action is justified.

Explore the project

View Casework on GitHub →

Built for the TigerGraph × HHGoa challenge using the organizer-provided benchmark and policies.