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.
Top comments (0)