TigerGraph Agentic Fraud Investigation Hackathon 2026 Team GOA-T

srinath thota — Fri, 25 Sep 2026 05:50:15 +0000

Team

Thota Sai Eswar Srinath — Team Leader & Agentic Architecture
Nikhil Kadiri — Graph Systems & TigerGraph Traversal Engineering
Bondugula Pranav Teja — Policy Engine & GraphRAG Implementation

Project Links

Live Cockpit: https://task-4-nvan.onrender.com/
GitHub Repository: https://github.com/tsrinath2007/Task-4
Benchmark Report: docs/BENCHMARK_REPORT.md
Demo Script: docs/DEMO_VIDEO_SCRIPT.md

A Fraud Score Isn't an Investigation

Modern fraud detection systems can assign a risk score to every transaction.

For example:

Transaction Risk Score: 0.87

But a risk score alone doesn't answer the questions an investigator actually needs:

Why is this transaction suspicious?
Has this card interacted with other suspicious accounts?
Is the device being used by multiple customers?
Has this device appeared in previous fraud cases?
Is this an unusual transaction or simply legitimate travel?
Is this a recurring subscription?
What action should the bank take?
Does the action require human approval?
Should a regulatory report be generated?

The problem becomes significantly harder when fraud is not isolated to one transaction.

A fraud ring might look like this:

Customer A
    |
  Card A
    |
Transaction
    |
 Device X
   / | \
  /  |  \
Card B Card C Card D
  |     |     |
 ...   ...   ...

A single suspicious transaction can therefore be connected to dozens or even hundreds of other entities.

This is where we saw an opportunity for graphs.

Introducing SENTINEL

We built SENTINEL, a graph-native autonomous fraud investigation system designed to investigate suspicious transactions using:

TigerGraph for multi-hop relationship analysis
Model Context Protocol (MCP) for live graph investigation tools
GraphRAG for historical case retrieval
Deterministic fraud detectors for explainable pattern detection
A deterministic policy engine for action and approval decisions
LLM synthesis for human-readable explanations and regulatory narratives
An interactive analyst cockpit for investigation and visualization

The key architectural principle was:

Let the graph gather evidence, let deterministic code enforce policy, and let the LLM explain the result.

The LLM is deliberately not allowed to decide whether a card should be blocked or which approval route should be assigned.

What We Built

SENTINEL is an end-to-end investigation system composed of eight major components:

Live TigerGraph Savanna Cloud + MCP Client
Hybrid GraphRAG Memory
Eight Deterministic Fraud Detectors
Legitimacy Checklist
Deterministic Policy Engine
Dynamic Next-Best Action Engine
LLM Synthesis Layer
Interactive Analyst Web Cockpit

Our evaluation used:

590,742 IEEE-CIS / Vesta transactions
5,565 closed historical cases
20 benchmark cases (HHG-001 → HHG-020)
A live TigerGraph graph containing approximately 1.45 million transaction vertices

The benchmark validation suite produced:

20 / 20 PASS
100% policy validation pass rate

The benchmark also covered both fraudulent and legitimate behavior, allowing us to test whether the system could avoid blindly treating every anomaly as fraud.

Architecture Overview

At a high level, SENTINEL follows this pipeline:

                    ┌───────────────────────┐
                    │      ALERT TRIGGER    │
                    │ Risk Score / Dispute  │
                    │ Analyst Escalation    │
                    └───────────┬───────────┘
                                │
                                ▼
                    ┌───────────────────────┐
                    │   TIGERGRAPH + MCP    │
                    │                       │
                    │ Customer Cards        │
                    │ Card History          │
                    │ Shared Devices        │
                    │ Prior Cases           │
                    └───────────┬───────────┘
                                │
                                ▼
                    ┌───────────────────────┐
                    │   EVIDENCE ENGINE     │
                    │                       │
                    │ 8 Fraud Detectors     │
                    │ Legitimacy Checks     │
                    │ GraphRAG Retrieval    │
                    └───────────┬───────────┘
                                │
                                ▼
                    ┌───────────────────────┐
                    │ DETERMINISTIC POLICY  │
                    │       ENGINE          │
                    │                       │
                    │ Rules R1 → R10        │
                    │ Approval Routing      │
                    │ Initial Actions       │
                    └───────────┬───────────┘
                                │
                       Evidence Required?
                          /           \
                        YES           NO
                         │             │
                         ▼             │
              ┌──────────────────┐    │
              │ Evidence Loop     │    │
              │                  │    │
              │ Customer Verify  │    │
              │ Step-up Auth     │    │
              └────────┬─────────┘    │
                       │              │
                       ▼              │
              ┌──────────────────┐    │
              │ Reassessment     │◄───┘
              │ decide_after_    │
              │ evidence()       │
              └────────┬─────────┘
                       │
                       ▼
              ┌──────────────────┐
              │ LLM Synthesis    │
              │                  │
              │ Explanation      │
              │ Case Summary     │
              │ SAR Narrative    │
              └────────┬─────────┘
                       │
                       ▼
              ┌──────────────────┐
              │ Persistence       │
              │                  │
              │ Case Vertex      │
              │ Audit JSON       │
              │ SAR XML          │
              │ Audit CSV        │
              └──────────────────┘

The important architectural boundary is between evidence, policy, and language generation.

Why We Chose a Graph

Traditional relational databases are excellent at structured transactional data.

Fraud investigation, however, often becomes a relationship problem.

Consider this investigation:

Transaction
     ↓
Device
     ↓
Other Cards
     ↓
Previous Transactions
     ↓
Previous Fraud Cases

The investigator is effectively asking:

"What else is connected to this transaction?"

That is naturally represented as a graph.

Instead of treating every transaction as an isolated row, SENTINEL models relationships between:

Customers
Cards
Transactions
Devices
Billing regions
Email domains
Historical cases

TigerGraph Data Model

Our live TigerGraph graph contains vertices including:

Customer
Card
Transaction
DeviceProfile
BillingRegion
EmailDomain
ClosedCase
Case

And relationships such as:

Customer
   └── OWNS ──> Card

Card
   └── MADE ──> Transaction

Transaction
   └── FROM_DEVICE ──> DeviceProfile

Transaction
   └── BILLED_IN ──> BillingRegion

Transaction
   └── PURCHASER_EMAIL ──> EmailDomain

Transaction
   └── NEXT ──> Transaction

ClosedCase
   └── ON_CARD ──> Card

ClosedCase
   └── INVOLVES ──> Transaction

Case
   ├── CASE_ON_CARD ──> Card
   ├── CASE_INVOLVES ──> Transaction
   └── CASE_CONNECTED_TO ──> Card

This lets an investigation move through the transaction network rather than querying isolated records.

Multi-Hop Fraud Investigation

One of our important graph traversals follows this pattern:

Transaction
      │
      │ FROM_DEVICE
      ▼
DeviceProfile
      │
      │ USED_ON
      ▼
Card
      │
      │ HAS_CLOSED_CASE
      ▼
ClosedCase

In GSQL:

CREATE OR REPLACE QUERY find_shared_device_ring(STRING txnId)
FOR GRAPH Transaction_Fraud {

    StartTxn = {Transaction.*};

    TargetTxn =
        SELECT t
        FROM StartTxn:t
        WHERE t.TransactionID == txnId;

    // Hop 1: Transaction → Device
    Dev =
        SELECT d
        FROM TargetTxn:t
        -(FROM_DEVICE:e)->
        DeviceProfile:d;

    // Hop 2: Device → Cards
    ConnectedCards =
        SELECT c
        FROM Dev:d
        -(USED_ON:e)->
        Card:c;

    // Hop 3: Cards → Previous Fraud Cases
    PriorFraud =
        SELECT cc
        FROM ConnectedCards:c
        -(HAS_CLOSED_CASE:e)->
        ClosedCase:cc
        WHERE cc.outcome == "fraud";

    PRINT
        ConnectedCards.size() AS syndicate_size,
        ConnectedCards,
        PriorFraud;
}

This traversal can expose relationships that are difficult to reason about when the investigation begins from a single transaction.

In our benchmark cases HHG-014 and HHG-017, the graph revealed device relationships connecting 299 distinct card accounts.

TigerGraph MCP

We didn't want the agent to directly manipulate the graph using arbitrary queries.

Instead, we exposed a controlled set of specialized investigation tools through MCP.

Our MCP client provides:

query_customer_cards(customer_id)

query_card_history(card_id, limit)

query_shared_devices(txn_id)

query_prior_cases(card_id)

write_case(case_data)

This creates a controlled interface between the agent and the graph.

Conceptually:

Agent
  │
  ├── query_card_history()
  │
  ├── query_shared_devices()
  │
  ├── query_prior_cases()
  │
  └── write_case()
  │
  ▼
TigerGraph

The agent doesn't need to understand the entire TigerGraph schema.

It only needs to know:

"I need the cards connected to this device."

The MCP tool handles the graph-specific implementation.

The Evidence Layer

After graph retrieval, SENTINEL runs deterministic detectors against the collected evidence.

We implemented eight primary detectors.

1. Recurring Merchant Detection

We look for repeated transactions with:

Similar merchant
Similar amount
Periodic intervals
Consistent historical behavior

For example:

Day 1    → $49.00
Day 30   → $49.00
Day 60   → $49.00
Day 90   → $49.00

A simplistic fraud detector might repeatedly flag these transactions.

Our detector can instead recognize the recurring pattern as potential legitimate subscription behavior.

2. Card Testing Detection

Card testing can produce small authorization attempts before a larger purchase.

For example:

$1.23
$2.11
$4.80
$7.42
$450.00

We look for rapid sequences of micro-authorizations followed by larger transactions.

3. Shared Device Detection

We investigate whether a device is associated with multiple cards.

For example:

Device D123
   ├── Card A
   ├── Card B
   ├── Card C
   ├── Card D
   └── Card E

A shared device alone does not prove fraud.

It becomes one piece of evidence that is combined with other signals.

4. New Device Detection

We determine whether the device is:

New to the customer
First seen in the customer's history
Previously associated with other suspicious activity

5. Out-of-Region Detection

We compare transaction regions against the cardholder's historical baseline.

We deliberately don't treat every out-of-region transaction as fraud.

For example:

Bengaluru
   ↓
Mumbai
   ↓
Delhi
   ↓
Bengaluru

may simply represent legitimate travel.

A single unexpected transaction combined with other anomalies can be more meaningful.

6. Card-Not-Present Burst Detection

We identify bursts of card-not-present transactions that significantly exceed historical transaction velocity.

7. Account Takeover Detection

We look for changes in digital identity signals such as:

Previous OS
Previous Browser
Previous Device
        ↓
Sudden change
        ↓
Transaction

Combined with additional identity inconsistencies, this can indicate possible account takeover activity.

8. Shared Region Detection

We identify clusters of otherwise unrelated cards originating from the same suspicious region or infrastructure.

Legitimacy Checklist

Fraud detection is not only about finding suspicious evidence.

It is also about finding evidence that explains why a transaction could be legitimate.

Our legitimacy checks consider patterns such as:

Recurring subscriptions
Historical merchant relationships
Consistent transaction amounts
Travel patterns
Customer history
Previously cleared disputes
Stable device behavior
Historical transaction velocity
Known customer behavior

This prevents the investigation engine from interpreting every anomaly as fraud.

GraphRAG: Combining Semantics With Structure

This was one of the most interesting parts of the project.

Traditional RAG primarily asks:

"Which previous cases sound similar to this case?"

Fraud investigation also needs to ask:

"Which previous cases are connected to the same entities?"

Those are different questions.

So we combined both.

Our Hybrid GraphRAG Pipeline

Historical cases are embedded using:

sentence-transformers/all-MiniLM-L6-v2

Each case becomes a 384-dimensional vector.

We then perform semantic similarity search.

At the same time, we query graph relationships.

Conceptually:

                    Historical Cases
                           │
             ┌─────────────┴─────────────┐
             ▼                           ▼
      Semantic Search             Graph Search
             │                           │
             │                           │
             └─────────────┬─────────────┘
                           ▼
                    Relevance Fusion
                           │
                           ▼
                    Ranked Evidence

Cases that are graph-adjacent receive an additional priority boost.

Our implementation uses:

semantic_score + adjacency_boost

with an adjacency boost of:

+0.15

for relevant graph relationships.

This means a case isn't ranked highly merely because its text sounds similar.

It can also be ranked highly because it shares important graph structure.

Why Negative Evidence Matters

This was one of our biggest lessons.

Fraud systems naturally focus on confirmed fraud.

But investigators also need to know:

"Have we seen this behavior before and determined that it was legitimate?"

So we indexed historical cleared cases as well.

Our historical dataset contained:

5,565 closed historical cases

including approximately:

900 cleared cases

These became negative evidence.

For example, in benchmark case HHG-003, historical cleared cases such as CC-4922 and CC-4718 helped establish that recurring disputes associated with that merchant category had previously been resolved as legitimate billing behavior.

This is important because:

A good fraud investigation system should not only find reasons to say "fraud."

It should also find evidence that says:

"We've seen this before, and it was legitimate."

The Most Important Design Decision

The LLM Does Not Control Policy

One of our earliest architectural lessons was that giving an LLM complete control over security actions creates unnecessary risk.

An LLM can generate a convincing explanation.

That doesn't mean it should have authority to execute:

BLOCK_CARD
FILE_REPORT
BLOCK_ALL_CARDS

So we separated:

Reasoning

from:

Authority

The LLM can:

Summarize evidence
Explain detected patterns
Generate case narratives
Format regulatory narratives
Explain why a policy rule was triggered

The deterministic policy engine decides:

What action is allowed
Which approval level is required
Whether blocking is permitted
Whether a report should be filed

The architecture therefore becomes:

                  Evidence
                     │
          ┌──────────┴──────────┐
          ▼                     ▼
   Policy Engine              LLM
          │                     │
          │                     │
      Authority             Explanation
          │                     │
          └──────────┬──────────┘
                     ▼
               Final Case

This separation became one of the defining design principles of SENTINEL.

Deterministic Policy Engine

Our policy engine contains rules R1–R10.

R1 — Weak Evidence

Weak isolated signals require additional verification rather than immediately blocking a card.

Weak Signal
    ↓
VERIFY_WITH_CUSTOMER
or
STEP_UP_AUTH

R2 — Customer Denial

If the customer denies the transaction:

Customer Denial
       ↓
BLOCK_CARD
       +
CREATE_CASE

If exposure exceeds the configured threshold or the transaction is connected to a fraud ring, escalation includes the required reporting route.

R3 — Customer Confirmation

If the customer confirms the transaction:

Customer Confirmation
       ↓
ALLOW_TRANSACTION
       +
CLOSE_NO_FRAUD

R4 — No Response

If the customer does not respond within the configured 24-hour window:

No Response
    ↓
MONITOR_CARD
    +
DECLINE_TRANSACTION

R5 — Card Testing

Card testing triggers additional protection:

Card Testing
    ↓
DECLINE_TRANSACTION
    +
STEP_UP_AUTH

R6 — Shared Origin

A sufficiently large shared-origin cluster triggers:

CREATE_CASE
+
FILE_REPORT
+
MONITOR_CONNECTED_CARDS

with the appropriate approval route.

R7 — Recurring Disputes

Recurring merchant disputes require verification.

Importantly:

Recurring Dispute
      ↓
VERIFY_WITH_CUSTOMER
      +
WARN_CUSTOMER

Blocking is prohibited by this rule.

R8 — Uncertain High-Exposure Cases

Uncertain cases above the configured exposure threshold are escalated to a human analyst.

R9 — Undocumented Patterns

Unknown patterns are escalated rather than silently handled.

R10 — Global Blocking

Blocking all connected cards is prohibited unless the required number of cards have independently confirmed fraud.

Approval Routing

Another important part of the policy layer is approval routing.

Actions can be assigned to:

AUTO
L1 — Lead
L2 — Manager

For example:

BLOCK_CARD
    ↓
L1 approval

and:

FILE_REPORT
    ↓
L2 approval

This prevents the model from simply saying:

"This looks dangerous. Block everything."

Instead, the system must follow the defined authorization hierarchy.

The Agent State Machine

SENTINEL is not a single LLM prompt.

It is an investigation state machine.

1. TRIGGER
      ↓
2. INVESTIGATE
      ↓
3. GATHER_EVIDENCE
      ↓
4. ASSESS_UNCERTAINTY
      ↓
5. GATHER_MORE_EVIDENCE
      ↓
6. REASSESS
      ↓
7. RECOMMEND_ACTION
      ↓
8. UPDATE_CASE_MEMORY

Each state has a specific responsibility.

This makes the system easier to debug and audit than an open-ended agent loop.

Dynamic Next-Best Action

A particularly important feature is that the recommended action can change after new evidence arrives.

Consider:

Initial Investigation
        ↓
VERIFY_WITH_CUSTOMER

The customer then denies the transaction.

The system reassesses:

Customer Denial
        ↓
BLOCK_CARD
        +
CREATE_CASE
        +
MONITOR_CONNECTED_CARDS

The system also records:

what_changed

This creates an audit trail explaining why the action changed.

The goal is not simply:

"What did the system decide?"

but:

"What evidence caused the system to change its decision?"

Stopping Rule

Autonomous systems need to know when to stop.

Otherwise an agent can continuously gather evidence without improving the decision.

SENTINEL stops when one of the configured stopping conditions is met.

For example:

Fraud probability ≥ 0.85

or:

Fraud probability ≤ 0.15

provided sufficient independent evidence exists.

Other stopping conditions include:

Customer verification settles the dispute
Authentication settles the transaction
Additional graph traversal cannot change the permitted policy action

This turns investigation into a bounded process rather than an open-ended agent loop.

LLM Synthesis Layer

Once the deterministic investigation is complete, the LLM is used for synthesis.

We used:

Groq
LLaMA 3.3 70B

for:

Executive case summaries
Evidence explanations
Policy-rule explanations
FinCEN SAR narrative generation

The important architectural boundary remains:

LLM
  ↓
Explanation

Policy Engine
  ↓
Authority

If the LLM produces an explanation that doesn't match the deterministic evidence, the explanation can be regenerated without changing the underlying policy decision.

Interactive Analyst Cockpit

We also built an interactive web cockpit for investigators.

The dashboard includes:

Fraud case overview
Live graph visualization
Multi-hop relationship exploration
Evidence timeline
Next-best-action display
Watchlist management
SAR generation
Audit logs
CSV exports
AI Copilot
Live MCP investigation

The cockpit is available at:

https://task-4-nvan.onrender.com/

Live MCP Investigation

The MCP investigation modal allows an analyst or evaluator to select a case and execute the complete investigation against the live TigerGraph environment.

The pipeline becomes:

Case
 ↓
MCP Tools
 ↓
TigerGraph
 ↓
Evidence
 ↓
Policy Engine
 ↓
LLM Explanation
 ↓
Case Write-back

The fast-path investigation completed in approximately 1.2 seconds in our benchmark environment.

This is a project runtime measurement, not a production SLA.

Benchmark: 20 Ground-Truth Cases

We evaluated SENTINEL against 20 benchmark cases:

HHG-001 → HHG-020

Our validation suite produced:

20 / 20 PASS

The benchmark included both fraudulent and legitimate cases.

Complete Benchmark Results

Case	Trigger	Verdict	Fraud Probability	Primary Pattern	Exposure	SAR	Validation
HHG-001	Risk Score 0.61	Legitimate	0.07	None / Recurring	$77.07	No	PASS
HHG-002	Risk Score 0.79	Fraud	0.95	CNP Fraud	$292.36	No	PASS
HHG-003	Customer Report	Legitimate	0.07	None / Recurring	$49.00	No	PASS
HHG-004	Customer Report	Fraud	0.90	Card Testing	$55.89	Yes	PASS
HHG-005	Risk Score 0.54	Fraud	0.94	CNP New Device	$100.07	Yes	PASS
HHG-006	Customer Report	Fraud	0.93	Card Testing	$1,906.07	Yes	PASS
HHG-007	Risk Score 0.87	Legitimate	0.08	None / Subscription	$111.92	No	PASS
HHG-008	Customer Report	Legitimate	0.07	None / Recurring	$55.68	No	PASS
HHG-009	Customer Report	Fraud	0.95	CNP New Device	$30.02	Yes	PASS
HHG-010	Risk Score 0.90	Fraud	0.96	CNP New Device	$1,000.03	Yes	PASS
HHG-011	Customer Report	Legitimate	0.08	None / Recurring	$131.30	No	PASS
HHG-012	Risk Score 0.55	Legitimate	0.07	None / Recurring	$30.91	No	PASS
HHG-013	Risk Score 0.76	Fraud	0.95	CNP New Device	$35.66	Yes	PASS
HHG-014	Analyst Request	Fraud	0.95	CNP New Device	$74.96	Yes	PASS
HHG-015	Risk Score 0.77	Fraud	0.92	CNP New Device	$599.94	Yes	PASS
HHG-016	Customer Report	Fraud	0.94	CNP New Device	$59.67	Yes	PASS
HHG-017	Risk Score 0.57	Fraud	0.93	Card Testing	$300.14	Yes	PASS
HHG-018	Customer Report	Legitimate	0.07	None / Recurring	$39.08	No	PASS
HHG-019	Risk Score 0.90	Fraud	0.91	CNP New Device	$99.92	Yes	PASS
HHG-020	Risk Score 0.52	Fraud	0.95	CNP New Device	$125.08	Yes	PASS

Aggregate Benchmark Metrics

Metric	Result
Benchmark Cases	20
Validation Pass Rate	20 / 20 — 100%
Fraud Cases	13
Legitimate Cases	7
Regulatory Filings	12
Dynamic Policy Progression	20 / 20
Total Fraud Exposure Managed	$5,174.77
Average Fraud Probability — Fraud Cases	93.5%
Average Fraud Probability — Legitimate Cases	7.3%
Live Fast-Path Investigation	~1.2 seconds

These are results from our project benchmark and should not be interpreted as production fraud-detection performance.

Benchmark Examples

HHG-003 — Legitimate Recurring Behavior

The system identified recurring transaction behavior and retrieved historical cleared cases with similar patterns.

Result:

Verdict:
Legitimate

Fraud Probability:
0.07

Final Actions:
ALLOW_TRANSACTION
CLOSE_NO_FRAUD

This case demonstrated why negative evidence matters.

HHG-017 — Card Testing

The system detected a card-testing pattern.

Result:

Verdict:
Fraud

Fraud Probability:
0.93

Primary Pattern:
card_testing

The system updated its recommended actions after evidence evaluation.

HHG-014 — Shared Device Network

The investigation exposed a large connected-card structure through graph traversal.

The important evidence wasn't isolated to the transaction itself.

It came from:

Transaction
    ↓
Device
    ↓
Multiple Cards
    ↓
Historical Cases

This is exactly the type of relationship that motivated the graph-native architecture.

What We Learned

1. Policy and Reasoning Should Be Separated

Our biggest architectural lesson was simple:

Don't give an LLM authority just because it can reason about the problem.

The model is useful for language and synthesis.

The policy engine is better suited for deterministic authorization.

2. Negative Evidence Is Extremely Valuable

A fraud system that only remembers fraud can become biased toward finding fraud.

Cleared historical cases provide an important counterweight.

They answer:

"Have we seen this pattern before and cleared it?"

3. Graph Context Improves Retrieval

Semantic similarity answers:

"What sounds similar?"

Graph adjacency answers:

"What is connected?"

Combining both gives us a richer retrieval signal.

4. Agentic Does Not Mean Uncontrolled

We initially thought of an agent as something that could freely decide which actions to execute.

Our final architecture was different.

The agent has freedom to:

Investigate
Retrieve
Compare
Request evidence
Reassess
Explain

But it operates inside deterministic boundaries for:

Policy
Approval
Actions
Auditability

That distinction became one of the most important design principles of SENTINEL.

Engineering Challenges

Deterministic Card Reconstruction

The source transaction dataset required deterministic reconstruction of card relationships from partially masked identifiers.

The ordering of missing and sequential card identifiers mattered for maintaining consistent mappings across the dataset.

This was not a glamorous problem, but it was critical.

Small preprocessing inconsistencies can propagate into:

Card Mapping
      ↓
Graph Relationships
      ↓
Fraud Detection
      ↓
Benchmark Results

Deterministic preprocessing therefore became part of the investigation pipeline rather than a separate data-cleaning concern.

Asynchronous UI Orchestration

The frontend initially relied on independent timers and asynchronous operations.

That introduced race conditions.

For example:

Graph Loading
       ↓
Evidence Animation
       ↓
Policy Result
       ↓
Case Write-back

could appear out of order.

We replaced this with sequential asynchronous orchestration so each stage completed before the next stage began.

The result was a much more predictable investigation experience.

What We Would Build Next

1. Graph Neural Networks

We would investigate GCN/RGCN-based models for learning structural fraud representations directly from the transaction graph.

The goal would be to complement deterministic detectors with learned graph-level features.

2. Real-Time Streaming

A production-oriented version could integrate streaming ingestion such as Kafka:

Transaction Stream
        ↓
Kafka
        ↓
TigerGraph
        ↓
Investigation Agent
        ↓
Policy Engine

This would allow investigations to begin immediately after authorization events.

3. Human Approval Webhooks

L1 and L2 reviewers could receive actionable notifications through systems such as Slack or Microsoft Teams.

For example:

Fraud Investigation

Exposure: $1,906
Connected Cards: 299
Required Approval: L2

[Review Case]
[Approve]
[Reject]

This would connect the autonomous investigation pipeline with real human governance.

4. Regulatory Submission Integration

The current system can generate structured regulatory output.

A future implementation could integrate directly with an appropriate regulatory filing environment after the necessary security, compliance, authorization, and certification requirements are satisfied.

Project Structure

A simplified view of the implementation:

Task-4/
│
├── src/
│   ├── agent/
│   │   ├── orchestrator.py
│   │   └── llm_adapter.py
│   │
│   ├── graph/
│   │   └── mcp_client.py
│   │
│   ├── detectors/
│   │   └── ...
│   │
│   ├── memory/
│   │   └── retriever.py
│   │
│   └── policy/
│       └── policy_engine.py
│
├── cases/
│   └── generated/
│
├── scripts/
│   ├── embed_cases.py
│   └── validate_answers.py
│
├── docs/
│   ├── BENCHMARK_REPORT.md
│   └── DEMO_VIDEO_SCRIPT.md
│
└── README.md

Reproducibility

The project source code and implementation are available here:

GitHub:

https://github.com/tsrinath2007/Task-4

The live investigation cockpit is available here:

SENTINEL Cockpit:

https://task-4-nvan.onrender.com/

The benchmark validation can be reproduced using the project's validation tooling:

python scripts/validate_answers.py

Hackathon Rubric Alignment

The architecture was designed to address the major evaluation dimensions of the hackathon.

Rubric Category	Weight	How SENTINEL Addresses It	Evidence
Investigation Accuracy	25%	8 deterministic detectors + legitimacy checklist	`src/detectors/`, generated cases
Next Best Action	25%	Pre-evidence and post-evidence action gating	`src/policy/policy_engine.py`
Case Summary & Explainability	10%	LLM synthesis, policy explanations, SAR narratives	`src/agent/llm_adapter.py`
Agentic Design & Engineering	15%	8-stage state machine + MCP + graph write-back	`src/agent/orchestrator.py`
Innovation	15%	GraphRAG + adjacency boost + negative evidence	`src/memory/retriever.py`
Demo Quality	10%	Interactive cockpit + graph visualization + MCP modal	Live cockpit

The benchmark validation suite produced:

20 / 20 PASS

Key Takeaways

Building SENTINEL taught us that autonomous fraud investigation isn't simply about adding an LLM to a fraud detector.

The more interesting engineering problem is combining several different forms of intelligence:

                    SENTINEL
                       │
        ┌──────────────┼──────────────┐
        │              │              │
        ▼              ▼              ▼
     GRAPH          RULES          MEMORY
   TigerGraph     Policy Engine    GraphRAG
        │              │              │
        └──────────────┼──────────────┘
                       │
                       ▼
                    AGENT
                       │
                       ▼
                  LLM SYNTHESIS
                       │
                       ▼
                HUMAN-READABLE
                  EXPLANATION

The graph provides relationships.

The detectors provide evidence.

GraphRAG provides historical context.

The policy engine provides authority.

The agent provides orchestration.

The LLM provides explanation.

That separation is what makes SENTINEL more than a chatbot sitting on top of a database.

Conclusion

Fraud rarely exists as a single suspicious transaction.

It exists as a network.

A device connects cards.

Cards connect transactions.

Transactions connect customers, regions, merchants, and historical cases.

That is why we built SENTINEL around a graph.

Our goal was not to create an LLM that simply says:

"This looks like fraud."

We wanted to build an investigation system that can answer:

What happened?

What is connected to it?

What evidence supports the conclusion?

What historical cases are relevant?

What policy permits us to do next?

And why did the recommended action change?

The resulting architecture combines TigerGraph, MCP, GraphRAG, deterministic policy enforcement, agentic orchestration, and LLM synthesis into a single investigation workflow.

And most importantly, we learned that in high-impact systems:

Agentic doesn't have to mean uncontrolled.

The most useful autonomous systems may be the ones where the model has enough freedom to investigate—but enough constraints to remain auditable and predictable.

Built by Team GOA-T

Thota Sai Eswar Srinath

Team Leader & Agentic Architecture

Nikhil Kadiri

Graph Systems & TigerGraph Traversal Engineering

Bondugula Pranav Teja

Policy Engine & GraphRAG Implementation

Project Links

🚀 Live Cockpit:

https://task-4-nvan.onrender.com/

💻 GitHub Repository:

https://github.com/tsrinath2007/Task-4

SENTINEL — Investigate the transaction. Understand the network. Enforce the policy.

DEV Community: srinath thota

TigerGraph Agentic Fraud Investigation Hackathon 2026 Team GOA-T

Team

Project Links

A Fraud Score Isn't an Investigation

Introducing SENTINEL

What We Built

Architecture Overview

Why We Chose a Graph

TigerGraph Data Model

Multi-Hop Fraud Investigation

TigerGraph MCP

The Evidence Layer

1. Recurring Merchant Detection

2. Card Testing Detection

3. Shared Device Detection

4. New Device Detection

5. Out-of-Region Detection

6. Card-Not-Present Burst Detection

7. Account Takeover Detection

8. Shared Region Detection

Legitimacy Checklist

GraphRAG: Combining Semantics With Structure

Our Hybrid GraphRAG Pipeline

Why Negative Evidence Matters

The Most Important Design Decision

The LLM Does Not Control Policy

Reasoning

Authority

Deterministic Policy Engine

R1 — Weak Evidence

R2 — Customer Denial

R3 — Customer Confirmation

R4 — No Response

R5 — Card Testing

R6 — Shared Origin

R7 — Recurring Disputes

R8 — Uncertain High-Exposure Cases

R9 — Undocumented Patterns

R10 — Global Blocking

Approval Routing

The Agent State Machine

Dynamic Next-Best Action

Stopping Rule

LLM Synthesis Layer

Interactive Analyst Cockpit

Live MCP Investigation

Benchmark: 20 Ground-Truth Cases

Complete Benchmark Results

Aggregate Benchmark Metrics

Benchmark Examples

HHG-003 — Legitimate Recurring Behavior

HHG-017 — Card Testing

HHG-014 — Shared Device Network

What We Learned

1. Policy and Reasoning Should Be Separated

2. Negative Evidence Is Extremely Valuable

3. Graph Context Improves Retrieval

4. Agentic Does Not Mean Uncontrolled

Engineering Challenges

Deterministic Card Reconstruction

Asynchronous UI Orchestration

What We Would Build Next

1. Graph Neural Networks

2. Real-Time Streaming

3. Human Approval Webhooks

4. Regulatory Submission Integration

Project Structure

Reproducibility

Hackathon Rubric Alignment

Key Takeaways

Conclusion

Built by Team GOA-T

Thota Sai Eswar Srinath

Nikhil Kadiri

Bondugula Pranav Teja

Project Links