FraudLens AI: Engineering an Agentic Fraud Investigation and Next-Best-Action Platform

Introduction

Financial institutions process millions of transactions every day. Traditional fraud detection systems are generally optimized for one primary task: identifying transactions that appear anomalous.

However, identifying an anomaly is only the beginning of a real fraud investigation.

Once a transaction is flagged, an investigator may need to determine whether the customer actually authorized it, identify connected accounts, investigate shared devices, trace transaction paths, analyze historical cases, verify applicable policies, assess the reliability of available evidence, and ultimately determine what action should be taken.

This creates a gap between fraud detection and fraud investigation.

To address this problem, we developed FraudLens AI, an agentic fraud investigation and Next-Best-Action platform designed to transform uncertain transaction anomalies into evidence-driven, policy-governed actions.

The system combines:

• TigerGraph-based relationship analysis
• GraphRAG for regulatory and policy grounding
• Agentic investigation orchestration
• Evidence sufficiency and uncertainty evaluation
• Human-in-the-loop authorization
• Role-based access control
• Automated compliance report generation
• Persistent case memory
• Benchmark-driven evaluation

The platform implements an end-to-end investigation lifecycle consisting of automated investigation, evidence gathering, reassessment, recommendation, approval, execution, auditing, and long-term case persistence.

1. The Problem: Detection Is Not Investigation

A conventional fraud detection pipeline can be represented as:

Transaction
    ↓
Fraud Detection Model
    ↓
Risk Score
    ↓
Alert
    ↓
Human Investigation

The major limitation is the final step.

A risk score can tell an analyst that a transaction is suspicious, but it does not necessarily explain:

• Which entities are connected?
• Is the account connected to other suspicious accounts?
• Is the same device associated with multiple customers?
• Is there an abnormal transaction velocity?
• Does historical investigation data contain a similar case?
• What regulatory or internal policy applies?
• Is there sufficient evidence to take action?
• Should the transaction be blocked, monitored, or allowed?
• Does the proposed action require human authorization?

FraudLens AI approaches the problem as an investigation orchestration problem rather than only a classification problem.

The system begins with a fraud signal and progressively builds an evidence-backed investigation context.

2. System Architecture

The architecture is built around an agent orchestrator that coordinates multiple specialized components.

At a high level:

                    Fraud Trigger
                         │
                         ▼
                 Agent Orchestrator
                         │
          ┌──────────────┼──────────────┐
          ▼              ▼              ▼
      TigerGraph       GraphRAG       Policies
          │              │              │
          ▼              ▼              ▼
    Graph Evidence  Document Evidence Rule Engine
          └──────────────┼──────────────┘
                         ▼
                Evidence Synthesizer
                         │
                         ▼
                 Uncertainty Engine
                         │
                         ▼
              Next-Best-Action Agent
                         │
                         ▼
                 Approval Controller
                         │
                         ▼
                  Action Execution
                         │
                         ▼
                    Case Memory
                         │
                         ▼
                Analyst Dashboard

This architecture separates three fundamentally different types of evidence:

Graph evidence

Relationships between customers, accounts, devices, transactions, and other entities.

Document evidence

Regulations, policies, historical case information, and other textual knowledge.

Policy evidence

Deterministic rules that constrain what actions are permitted.

This separation is important because an AI agent should not be allowed to make unrestricted decisions based solely on probabilistic reasoning.

3. TigerGraph as the Relationship Intelligence Layer

Fraud is frequently a network problem.

A suspicious account may not look particularly unusual when examined independently. However, relationships between entities can expose patterns that are difficult to identify using isolated transaction analysis.

FraudLens AI therefore uses TigerGraph as the primary graph intelligence layer.

The project includes graph operations for:

• Multi-hop neighborhood traversal
• Shared-device detection
• Connected-account analysis
• Transaction velocity analysis
• Fraud-cluster detection
• PageRank-based risk propagation

The TigerGraph implementation contains a production-oriented graph schema with multiple vertex and edge types, along with dedicated GSQL queries for these investigation operations.

For example, consider:

Customer A
     │
     ├── Account A
     │      │
     │      └── Device X
     │
Customer B
     │
     ├── Account B
     │      │
     │      └── Device X
     │
Customer C
     │
     └── Account C
            │
            └── Device X

A traditional transaction-centric system may analyze these customers independently.

A graph system can expose the shared relationship:

Customer A ── Account A ──┐
                          │
Customer B ── Account B ──┼── Device X
                          │
Customer C ── Account C ──┘

That relationship becomes an additional investigation signal.

The project also uses PageRank-based risk propagation to analyze graph-level risk relationships.

4. TigerGraph MCP Integration

FraudLens AI uses a TigerGraph MCP layer to expose graph investigation capabilities to the agent.

The documented tools include:

search_transaction
get_customer_profile
find_shared_devices
find_related_accounts
get_graph_risk
detect_fraud_cluster

This creates a structured interface between the agentic reasoning layer and the graph database.

Conceptually:

Agent
  │
  ▼
MCP Tool
  │
  ▼
TigerGraph
  │
  ▼
Graph Query
  │
  ▼
Structured Evidence
  │
  ▼
Agent Context

Instead of giving the language model unrestricted access to the database, the MCP layer exposes purpose-built investigation operations.

This improves modularity and makes the investigation process easier to test and audit.

5. GraphRAG for Regulatory Grounding

Graph relationships alone are insufficient.

An investigation must also consider the regulatory and policy context surrounding a transaction.

FraudLens AI therefore combines graph-based evidence with GraphRAG.

The system is documented as being grounded in banking regulations and compliance material including:

• FinCEN 31 CFR § 1020.320
• CFPB Regulation E
• FFIEC guidance

The purpose of this layer is to retrieve relevant policy and regulatory context before generating an action recommendation.

The conceptual pipeline becomes:

Graph Evidence
       +
Regulatory Evidence
       +
Historical Case Evidence
       +
Policy Rules
       ↓
Evidence Synthesis
       ↓
Investigation Reasoning

This is significantly different from asking a general-purpose LLM:

"Is this transaction fraudulent?"

Instead, the system attempts to provide the agent with structured evidence and relevant policy context before producing an investigation recommendation.

6. The Uncertainty and Evidence Sufficiency Engine

One of the important architectural components of FraudLens AI is the uncertainty engine.

An investigation should not treat every available piece of information as equally reliable.

The system evaluates what is:

Known
Likely
Uncertain
Missing

This distinction matters because the correct action may depend on evidence that has not yet been obtained.

For example:

Suspicious transaction detected
          ↓
Customer authorization unknown
          ↓
Evidence insufficient
          ↓
Request additional verification
          ↓
Customer response received
          ↓
Recalculate investigation

The documented workflow specifically supports controlled additional evidence requests when customer authorization cannot be verified.

This makes the investigation iterative instead of treating the first model output as final.

7. Interactive Evidence Simulation

FraudLens AI includes an interactive evidence simulator designed to represent customer verification.

For example:

Investigator
     ↓
Customer Challenge
     ↓
"Did you authorize this transaction?"
     ↓
Customer Response
     ↓
Evidence Update
     ↓
Risk Reassessment
     ↓
Next-Best Action

The important architectural characteristic is that new evidence does not simply get displayed to the investigator.

It feeds back into the investigation process.

This creates a closed-loop investigation:

Evidence
   ↓
Reasoning
   ↓
Uncertainty
   ↓
Evidence Request
   ↓
New Evidence
   ↓
Reassessment

8. Risk Scoring and Next-Best Action

FraudLens AI uses transparent, factor-weighted risk scoring rather than treating the final score as a black box.

The investigation then proceeds to a Next-Best-Action agent.

Conceptually:

Risk Assessment
       +
Evidence Sufficiency
       +
Policy Constraints
       +
Investigation Context
       ↓
Next-Best-Action

Possible actions in the benchmark environment include:

ALLOW_TRANSACTION
MONITOR_TRANSACTION
BLOCK_TRANSACTION

The key architectural distinction is that the AI recommendation is not automatically equivalent to authorization.

9. Human-in-the-Loop RBAC

Fraud investigations can involve high-impact actions.

For that reason, FraudLens AI implements a policy-governed human-in-the-loop architecture.

The system defines different authorization levels including:

• Junior Analysts
• Senior Analysts
• Fraud Managers
• System Agents

with strict approval tiers.

The resulting workflow is:

AI Investigation
      ↓
Recommendation
      ↓
Policy Validation
      ↓
RBAC Check
      ↓
Human Approval
      ↓
Action Execution

This creates an important separation between:

Reasoning

and

Authorization

The agent can investigate and recommend an action, while the policy and authorization layers control whether that action can actually be executed.

10. Deterministic Policy Enforcement

A purely LLM-driven architecture would introduce unnecessary uncertainty into a compliance-sensitive workflow.

FraudLens AI therefore includes an independent deterministic policy engine.

Its role is to enforce:

• Banking constraints
• Action rules
• RBAC permissions
• Approval requirements

The policy engine operates independently from the agent's reasoning layer.

This creates a defense-in-depth architecture:

             AI Agent
                │
                ▼
        Action Recommendation
                │
                ▼
        Deterministic Policy
                │
                ▼
          RBAC Controller
                │
                ▼
        Authorized Action

This architecture reduces the possibility of an unconstrained AI response directly triggering a sensitive operation.

11. Case Memory

Another important component is long-term investigation memory.

Fraud cases should not always be treated as isolated events.

FraudLens AI retrieves historical similar cases during investigations and stores completed investigation information for future use. The architecture includes a dedicated Case Memory component.

This enables a feedback loop:

Past Cases
    ↓
Current Investigation
    ↓
Investigation Outcome
    ↓
Case Memory
    ↓
Future Investigations

Over time, the system can therefore build a reusable knowledge base of previous investigation patterns.

12. Benchmark-Driven Evaluation

Rather than evaluating the system only through a demonstration, FraudLens AI includes a 20-case benchmark suite.

The benchmark contains scenarios ranging from routine transactions to complex fraud-network patterns.

Examples include:

BENCH-01
Routine Grocery Purchase from Trusted Device

BENCH-02
Shared Mule Device Wire Exfiltration Attempt

BENCH-06
Suspected Synthetic Identity New Line Bust-Out

BENCH-15
Simultaneous In-Person and E-Commerce Transacting

BENCH-18
Rapid Funneling Across 3 Intermediate Accounts

BENCH-20
Mule Ring Master Node Inter-Account Liquidation

The benchmark records transaction amount, risk score, recommended action, and SAR status.

The system also supports JSON and CSV export of benchmark results.

This makes the platform testable beyond a single manually demonstrated scenario.

13. Technology Stack

The implementation uses a modern full-stack architecture.

Frontend

React 19
TypeScript
Vite
Tailwind CSS v4
Lucide React
Recharts
Cytoscape.js

Backend

Python 3.12
FastAPI
SQLAlchemy
Pydantic v2
SQLite / PostgreSQL

Graph and AI

TigerGraph
GSQL
NetworkX
GraphRAG

Testing and Infrastructure

Pytest
Docker
Docker Compose

These components form the production-style application stack documented by the project.

14. Dual-Engine Graph Architecture

A practical problem with graph-dependent applications is local development and deployment complexity.

FraudLens AI addresses this through a dual-engine graph adapter.

The system can connect to:

TigerGraph Savanna
        OR
TigerGraph Community Edition
        OR
In-memory fallback

The fallback enables local execution without requiring every developer environment to have a fully configured TigerGraph deployment.

This approach separates the application logic from the infrastructure dependency.

15. Containerized Deployment

The application can also be started as a complete stack using Docker Compose.

The documented architecture includes:

PostgreSQL
    +
Backend API
    +
Nginx Frontend

and can be started through:

docker compose up --build

This provides a reproducible deployment approach for the application stack.

16. End-to-End Investigation Flow

Putting all components together, a complete FraudLens investigation can be represented as:

1. Fraud Signal
       ↓
2. Case Initialization
       ↓
3. Multi-Hop Graph Discovery
       ↓
4. Transaction Anomaly Analysis
       ↓
5. Device & Identity Linking
       ↓
6. Connected Account Detection
       ↓
7. Historical Case Retrieval
       ↓
8. Regulatory / Policy Retrieval
       ↓
9. Risk Scoring
       ↓
10. Uncertainty Evaluation
       ↓
11. Additional Evidence Request
       ↓
12. Evidence Incorporation
       ↓
13. Next-Best-Action
       ↓
14. RBAC Approval
       ↓
15. Action Execution
       ↓
16. Audit Explanation
       ↓
17. SAR Generation
       ↓
18. Case Memory

This workflow is the core engineering idea behind FraudLens AI: investigation should be an iterative evidence pipeline rather than a single prediction.

17. What Makes the Architecture Interesting?

The most important aspect of FraudLens AI is not simply the use of an LLM.

It is the combination of multiple reasoning and control mechanisms:

Graph Intelligence
       +
Retrieval-Augmented Reasoning
       +
Uncertainty Evaluation
       +
Deterministic Policies
       +
Human Authorization
       +
Persistent Memory
       +
Automated Compliance

Each component addresses a different limitation.

Graph intelligence provides relationships.

GraphRAG provides contextual knowledge.

Uncertainty evaluation identifies evidence gaps.

Policy enforcement constrains possible actions.

Human-in-the-loop authorization controls sensitive decisions.

Case memory provides historical context.

Automated reporting converts investigation outcomes into structured compliance artifacts.

Together, these components form an agentic investigation architecture rather than a simple fraud classification model.

Conclusion

FraudLens AI explores a different approach to financial fraud systems: moving from alert generation toward autonomous investigation with controlled decision execution.

The architecture combines TigerGraph's graph capabilities with agentic orchestration, GraphRAG, uncertainty evaluation, deterministic policy enforcement, RBAC, interactive evidence collection, case memory, and compliance reporting.

The broader engineering lesson is that deploying AI in sensitive domains requires more than making a model capable of reasoning.

It requires building the surrounding system that determines:

what evidence the AI can access, how uncertainty is handled, which actions are permitted, when human authorization is required, and how every investigation can be explained and audited.

That is the engineering foundation behind FraudLens AI.

Deeper graphs. Smarter agents. Evidence-driven investigations.