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

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. 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: 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. Top com