Fraud investigation is rarely about looking at a single transaction in isolation.
A suspicious transaction can be connected to a customer, multiple cards, previous transactions, devices, and historical cases. The challenge is not only detecting that something looks unusual, but also understanding the relationships behind it, gathering supporting evidence, assessing uncertainty, deciding what to do next, and ensuring that the action follows policy.
For our recent hackathon project, we built FraudGraph AI, an agentic fraud investigation platform designed around this problem.
The Core Idea
Instead of treating fraud detection as:
Transaction → Fraud Score → Decision
we designed the system as an investigation workflow:
Transaction → Investigation → Graph Evidence → Risk & Uncertainty → Next Best Action → Policy/HITL → Execution → Case Memory
The goal was to make the investigation process explainable and structured rather than relying on a single opaque score.
Architecture
The system is divided into several stages.
- Investigation Engine
The investigation starts with a flagged transaction and its trigger information.
The Investigation Engine gathers relevant evidence and normalizes it into a structured evidence model. Evidence is classified so that the system can distinguish between directly observed facts, observations, and inferences.
This gives the later reasoning stages a clear evidence base instead of passing around unstructured investigation output.
- TigerGraph + GraphRAG
The graph layer is one of the most important parts of FraudGraph AI.
Fraud relationships are naturally graph-shaped:
Customer → Card → Transaction → Merchant/Entity → Related Transaction
A graph allows the investigation to move across these relationships and identify connections that may not be obvious from a single transaction.
TigerGraph is used as the graph investigation layer, while GraphRAG provides structured context from the graph for downstream reasoning.
This allows the system to ask questions such as:
Which transactions are connected to the flagged transaction?
Which cards are associated with the customer?
What other activity is connected to those entities?
Are there related entities or previous cases that provide additional context?
What evidence supports the suspected fraud pattern?
The graph context is then passed into the reasoning pipeline rather than treating the transaction as an isolated record.
- Risk and Uncertainty Engine
After evidence collection, FraudGraph AI evaluates risk.
An important design decision was to separate fraud probability, confidence, and uncertainty.
A high fraud probability does not automatically mean that the evidence is complete or that the system should immediately take an irreversible action.
The reasoning layer aggregates independent evidence signals while attempting to avoid double-counting correlated evidence.
The result contains:
Fraud probability
Confidence
Uncertainty
Evidence-derived risk signals
This gives the investigation a more complete picture than a single binary fraud/not-fraud classification.
- Next Best Action Engine
The next stage answers:
What should the investigation do next based on the current evidence and risk?
The Next Best Action engine produces a deterministic and explainable recommendation based on the investigation and risk assessment.
Possible actions can include monitoring, blocking, declining, verification, or other investigation actions supported by the system.
An important architectural distinction is that Next Best Action is not the same thing as policy authorization.
The NBA engine recommends an action.
The policy layer determines whether that action is actually permitted.
- Policy Compliance and Human-in-the-Loop
The recommended action then passes through the policy layer.
The policy engine evaluates the action against the configured policy rules and determines:
Whether the action is permitted
Which policy rules apply
Whether approval is required
What approval level is required
Whether the case should be blocked
This creates a separation between:
Recommendation → Authorization
For actions requiring human review, the workflow can move into a Human-in-the-Loop approval state rather than executing automatically.
This is particularly important for fraud investigations where an automated system should not blindly perform every high-impact action.
- Execution and Case Memory
The final stage handles execution and investigation persistence.
Where policy permits automatic execution, the action is passed to the execution layer.
The system also stores the investigation as case memory, allowing the resulting case information and execution references to become part of the investigation record.
This creates a complete workflow:
Investigate → Reason → Recommend → Authorize → Execute → Remember
rather than ending the process after generating a fraud score.
Benchmarking
We also built a benchmark evaluation harness around the authoritative 20-case benchmark.
Each case is processed through the same production pipeline:
Investigation
Risk and uncertainty assessment
Next Best Action
Policy evaluation
Execution or approval handling
Case-memory persistence
The benchmark runner records information including evidence count, detected pattern, affected transactions, connected cards, exposure, fraud probability, confidence, uncertainty, recommended actions, policy results, execution state, and case-memory status.
This allows the complete investigation workflow to be evaluated rather than measuring only whether a fraud classifier produced a particular score.
Top comments (0)