Building AEGIS: An Agentic Fraud Investigation System with TigerGraph, MCP, and GraphRAG

Kanwal Vyas — Fri, 25 Sep 2026 00:39:33 +0000

AEGIS — Agentic Evidence & Graph Intelligence System is an agentic fraud investigation platform built for the TigerGraph HHGOA challenge. It combines graph-based investigation, MCP tools, GraphRAG, uncertainty assessment, policy enforcement, Next Best Action recommendations, human approval, SAR preparation, and case-memory writeback.

🎥 Demo
💻 GitHub

The Problem

Fraud investigation is rarely just about identifying whether one transaction looks suspicious.

A useful investigation needs to answer questions such as:

What entities are connected to this transaction?
Has this customer or card appeared in previous investigations?
Are there shared devices or other relationships suggesting coordinated activity?
What evidence supports or contradicts the suspicion?
Is the available evidence actually sufficient?
What additional evidence should be collected?
What does policy permit?
What action should be recommended?
Does that action require human approval?

This led me to build AEGIS, an agentic investigation system designed around evidence rather than a single fraud score.

What is AEGIS?

AEGIS stands for Agentic Evidence & Graph Intelligence System.

The core investigation flow is:

Fraud Signal / Customer Report
            ↓
       Alert Triage
            ↓
   Agentic Investigation
            ↓
     TigerGraph + MCP
            ↓
     Evidence Gathering
            ↓
       GraphRAG Context
            ↓
 Fraud + Uncertainty Assessment
            ↓
   Evidence Sufficiency Check
            ↓
      Policy Evaluation
            ↓
   Next Best Action (NBA)
            ↓
    Human Authorization
            ↓
       Case Writeback

The important design principle is that these stages are deliberately separated.

A fraud signal is not automatically a fraud verdict.

A recommendation is not authorization.

Authorization is not execution.

Architecture

AEGIS is composed of several cooperating layers.

                    ┌─────────────────────┐
                    │      AEGIS UI       │
                    │    Live Agent       │
                    └──────────┬──────────┘
                               │
                               ▼
                    ┌─────────────────────┐
                    │ Agentic Orchestrator │
                    │  bounded 8-step loop │
                    └──────────┬──────────┘
                               │
                    ┌──────────▼──────────┐
                    │    MCP Tool Layer   │
                    └──────────┬──────────┘
                               │
                ┌──────────────┴──────────────┐
                ▼                             ▼
       ┌────────────────┐             ┌────────────────┐
       │   TigerGraph   │             │    GraphRAG    │
       │ entities +     │             │ historical     │
       │ relationships  │             │ cases/policy  │
       └────────────────┘             └────────────────┘
                │                             │
                └──────────────┬──────────────┘
                               ▼
                    ┌─────────────────────┐
                    │ Evidence + Reasoning│
                    │ Uncertainty +        │
                    │ Sufficiency          │
                    └──────────┬──────────┘
                               ▼
                    ┌─────────────────────┐
                    │ Policy + NBA Engine │
                    └──────────┬──────────┘
                               ▼
                    ┌─────────────────────┐
                    │ Case Memory /       │
                    │ Graph Writeback     │
                    └─────────────────────┘

Why TigerGraph?

The investigation needs to reason over relationships, not just individual rows.

My graph contains entities including:

Customers
Cards
Device profiles
Email domains
Billing regions
Transactions
Closed investigations
Investigation cases

Relationships connect these entities so that the investigator can move from a transaction to its customer, card, devices, related cards, and previous cases.

This becomes particularly useful for patterns such as shared-device activity.

Instead of asking only:

“Does this transaction look suspicious?”

AEGIS can investigate:

“What else is connected to this transaction, and what do those relationships tell us?”

I also implemented a TigerGraph Weakly Connected Components (WCC) algorithm as a structural graph signal. It identifies connected components in the fraud graph without treating component membership itself as a fraud verdict.

MCP as the Investigation Interface

AEGIS exposes its TigerGraph investigation capabilities through an MCP layer.

The agent can invoke tools such as:

get_transaction
detect_velocity
find_shared_devices
find_connected_cards
get_card_history
get_historical_cases

The important part is that the agent does not blindly execute every available query.

The next investigation step is selected based on evidence already collected.

For example:

Transaction
    ↓
Shared device detected
    ↓
Investigate connected cards
    ↓
Retrieve historical cases
    ↓
Compare evidence and precedent

This allows the investigation to expand dynamically when the evidence warrants it.

GraphRAG

Graph data alone isn't enough.

Fraud investigations also benefit from historical precedent and policy context.

AEGIS therefore combines:

Current graph evidence
Historical closed investigations
Policy context
Regulatory references

The GraphRAG layer retrieves relevant historical cases and contextual information and incorporates them into the investigation.

Importantly, historical precedent is treated as evidence and context, not as an automatic verdict.

Evidence, Uncertainty and Sufficiency

One of the most important design decisions in AEGIS was separating three different concepts:

Fraud assessment

How strongly does the available evidence support a fraud hypothesis?

Uncertainty

How much ambiguity or conflicting evidence remains?

Evidence sufficiency

Do we have enough evidence to justify the next decision?

These are not the same thing.

A case can have a strong fraud signal while still having insufficient evidence for a destructive action.

For example, a shared device may be suspicious, but it doesn't automatically prove that every connected account is fraudulent.

AEGIS therefore records uncertainty and evidence gaps explicitly.

Policy and Next Best Action

Once the evidence has been evaluated, the policy engine determines what actions are permitted and what approval is required.

The system separates:

Recommendation
      ≠
Authorization
      ≠
Execution

For example, the agent may recommend:

BLOCK_CARD

while policy determines:

L1 APPROVAL REQUIRED

and the actual execution state remains:

PENDING_APPROVAL

This prevents the investigation agent from silently performing destructive actions.

SAR Preparation

AEGIS also includes a SAR preparation workflow.

For applicable cases, the system can generate an auditable SAR preparation package containing the relevant investigation information and entity lineage.

The important boundary is:

The system prepares the SAR package for review. It does not autonomously file the SAR with regulators.

This keeps compliance preparation separate from regulatory execution.

Case Memory

A fraud investigation shouldn't disappear after the final recommendation.

AEGIS persists investigation information into case memory, including:

Findings
Evidence
Decisions
Actions
Outcomes
Related entities
Investigation status

In live TigerGraph mode, the system performs idempotent writeback for the investigation case and its relationships to the relevant transaction and card.

This creates a persistent investigative record that can be used by future investigations.

Live Investigation: HHG-010

The demo focuses on HHG-010, a $1,000.03 risk-score alert.

The agent begins with the alert context and then dynamically investigates the case.

The live investigation includes:

get_transaction
        ↓
detect_velocity
        ↓
find_shared_devices
        ↓
find_connected_cards
        ↓
get_historical_cases

The shared-device evidence causes the investigation to expand into connected cards and related entities.

Historical cases then provide additional context.

The reasoning stage identifies significant evidence but also records high uncertainty rather than treating the graph relationship as conclusive proof of fraud.

The policy layer then routes the case for L1 approval.

The final recommendation is:

VERIFY_WITH_CUSTOMER

with:

AUTH: L1 APPROVAL REQUIRED
EXEC: PENDING_APPROVAL

A SAR preparation recommendation is also generated, and the investigation is written back into case memory.

A Second Investigation Path

AEGIS also supports a customer-report trigger.

HHG-003 demonstrates this alternate path.

The customer-report case reaches a policy-driven:

BLOCK_CARD

recommendation.

However, the block is still subject to:

L1 APPROVAL REQUIRED

and remains:

PENDING_APPROVAL

This demonstrates that the system doesn't equate a recommendation with automatic execution.

Benchmark and Engineering Results

The final benchmark evaluation covers 20 cases.

The implementation achieved:

20/20 benchmark cases processed
20/20 investigation cases persisted
100% budget compliance
0 duplicate tool calls
0 missing-entity contamination
0 policy mismatches
0 unreferenced destructive recommendations
0 denied destructive actions
0 lifecycle inconsistencies
111 automated tests passed

The benchmark also includes explicit pre- and post-additional-evidence fields for cases where additional evidence is required.

What I Learnt

Building AEGIS highlighted an important difference between a conventional fraud classifier and an investigation agent.

A classifier can answer:

“How suspicious is this transaction?”

An investigation system needs to answer much more:

“What should I investigate next?”

“What evidence supports the suspicion?”

“What evidence contradicts it?”

“Do I have enough evidence?”

“What does policy allow me to do?”

“Does this action require approval?”

“What should happen next?”

“How do I preserve this investigation for future cases?”

That is where the combination of agentic orchestration + graph intelligence + grounded retrieval + policy controls becomes valuable.

Final Architecture Principle

The central idea behind AEGIS can be summarized in one sentence:

The agent investigates. Evidence informs. Policy governs. Humans authorize. The graph remembers.

The goal isn't to replace investigators with an autonomous black box.

The goal is to give investigators a system that can connect evidence, reason over relationships, surface uncertainty, respect policy boundaries, and maintain an auditable investigation trail.

Demo

🎥 Watch the AEGIS live investigation demo:

https://youtu.be/0oeTPoTNVy4

Source Code

💻 GitHub:

https://github.com/kanwal-vyas/agentic-fraud-investigation

Built for TigerGraph HHGOA

AEGIS was built as part of the TigerGraph HHGOA Agentic Fraud Investigation challenge, with TigerGraph at the center of the investigation and relationship-analysis layer.

Thanks to the TigerGraph team for the challenge and for creating a problem where graph technology, agentic systems, and explainable investigation come together.

DEV Community: Kanwal Vyas