用 TigerGraph 与 11 个 AI Agent 构建智能体反欺诈调查系统

Fraud investigation is not just about detecting a suspicious transaction. A single transaction can be connected to a customer, card, device, email domain, billing region, previous fraud cases, and many other transactions. Finding these relationships manually can take significant time. For our project, we built an Agentic Fraud Investigation System powered by TigerGraph that combines a graph database, multiple specialized AI agents, and an AI chat interface into a single investigation workflow. The goal was simple: Help an analyst move from a suspicious transaction to evidence, investigation, and an actionable recommendation in one workflow. 1. What We Built The system starts with a suspicious transaction and creates an investigation case around it. Instead of giving the analyst a simple risk score, the system works through multiple investigation steps: Suspicious Transaction ↓ Create Investigation Case ↓ Collect Relevant Information ↓ Explore Graph Relationships ↓ Check Previous Cases ↓ Identify Fraud Patterns ↓ Evaluate Evidence ↓ Check if More Evidence is Needed ↓ Recommend Next Best Action ↓ Save Investigation Result Enter fullscreen mode Exit fullscreen mode The analyst interacts with the system through an AI chat interface. For example: "Why was this transaction flagged?" The system can investigate the case, retrieve relevant information, analyze graph relationships, and return a structured explanation. The interface also provides access to: Active Cases Chat History AI investigation chat Agent activity TigerGraph evidence graph Recommended actions Approval / rejection workflow 2. Why We Chose a Graph-Based Approach Traditional fraud analysis often looks at individual transactions. But fraud networks are relational. For example: Customer │ ├── Card │ ├── Device │ ├── Email │ └── Transaction │ ├── Device ├── Customer └── Previous Case Enter fullscreen mode Exit fullscreen mode A suspicious transaction becomes much more interesting when we discover that: the same device is associated with multiple customers, multiple cards are connected to the same device, an account is connected to previous confirmed fraud, several transactions form a suspicious pattern. This is where graph technology becomes useful. Instead of asking only: "Is this transaction risky?" we can ask: "What is this transaction connected to, and do those connections provide additional evidence?" 3. Architecture The system is organized into several major layers. ┌──────────────────────────────────────┐ │ React UI │ │ Chat | Cases | Agents | Graph │ │ Actions │ └──────────────────┬───────────────────┘ │ ▼ ┌──────────────────────────────────────┐ │ Investigation Application │ │ │ │ Case Management │ │ Chat Processing │ │ Agent Coordination │ │ Evidence Handling │ └──────────────────┬───────────────────┘ │ ▼ ┌──────────────────────────────────────┐ │ 11 AI Agents │ │ │ │ Investigation Coordinator │ │ Graph Analysis │ │ Transaction Analysis │ │ Fraud Analysis │ │ Evidence Analysis │ │ Case Analysis │ │ ... │ └───────────────┬───────────────┬──────┘ │ │ ▼ ▼ ┌──────────────┐ ┌──────────────┐ │ TigerGraph │ │ LLM │ │ Graph │ │ Runtime │ └──────────────┘ └──────────────┘ │ ▼ Investigation Evidence Enter fullscreen mode Exit fullscreen mode The frontend is responsible for presenting the investigation. The agent layer handles reasoning and task execution. TigerGraph provides the relationship and evidence layer. The LLM provides the natural-language interface and supports the agents in interpreting the retrieved information. 4. How TigerGraph Is Used TigerGraph is not just being used as a data storage layer. It is a core part of the investigation workflow. We model entities such as: Customer Card Transaction Device Email Domain Billing Region Closed Case and connect them through relationships. A simplified representation looks like: Customer ──owns──> Card Customer ──makes──> Transaction Transaction ──uses──> Device Customer ──uses──> Device Customer ──has──> EmailDomain Customer ──belongs_to──> BillingRegion Customer ──related_to──> ClosedCase Enter fullscreen mode Exit fullscreen mode This allows the agents to query relationships instead of relying only on isolated transaction records. Example Suppose Transaction T123 is suspicious. The investigation can explore: T123 │ ├── Customer C42 │ │ │ ├── Device D17 │ │ └── used by Customer C91 │ │ │ └── Card X92 │ └── Previous Case #102 Enter fullscreen mode Exit fullscreen mode That relationship may provide useful context that would be difficult to identify by looking at a single transaction row. 5. The 11-Agent System One of the main parts of the project is the multi-agent architecture. Instead of making one AI agent perform the entire investigation, we divided the workflow into specialized responsibilities. At a high level, the agents work as a team. User │ ▼ Investigation Coordinator │ ┌─────────────┼─────────────┐ ▼ ▼ ▼ Transaction Graph Case Analysis Analysis Analysis │ │ │ └─────────────┼─────────────┘ ▼ Evidence Analysis │ ▼ Fraud Assessment │ ▼ Action Recommendation Enter fullscreen mode Exit fullscreen mode The Investigation Coordinator manages the overall workflow and routes tasks to the appropriate specialized agents. Other agents focus on areas such as: transaction analysis, graph relationship analysis, fraud pattern identification, historical case analysis, evidence collection, risk assessment, additional evidence requirements, next-best-action generation. The important idea is that each agent has a focused responsibility instead of trying to solve the entire problem independently. 6. Evidence-Driven Investigation One of the design principles we followed was: The AI should investigate using available evidence instead of inventing facts. The agent workflow therefore focuses on retrieving relevant information from the graph and other investigation data before producing an explanation. For example: User Question ↓ Understand Investigation Context ↓ Identify Required Evidence ↓ Query Relevant Data ↓ Analyze Relationships ↓ Combine Evidence ↓ Generate Explanation Enter fullscreen mode Exit fullscreen mode This is particularly important in fraud investigation because an explanation without supporting evidence is not very useful to an analyst. The system therefore attempts to keep the final response connected to the underlying investigation data. 7. AI Chat Interface We wanted the analyst experience to feel familiar. Instead of requiring analysts to learn a complicated query language, they can communicate with the system using natural language. For example: User: Why was this transaction flagged? AI: The transaction was flagged because... - The transaction has an unusual pattern. - The associated device is connected to multiple accounts. - A related entity appears in previous investigation data. - Additional verification may be required. Enter fullscreen mode Exit fullscreen mode The chat interface also supports common AI workspace interactions such as: streaming responses, chat history, editing previous messages, regenerating responses, copying responses, feedback controls, file attachments, voice input, light/dark mode. The idea was to make a complex investigation system feel as approachable as a normal AI assistant. 8. Graph Visualization The graph is also exposed directly to the analyst. Instead of hiding all the relationships behind the AI, we provide a visual representation of the investigation. The analyst can explore relationships between: Customers ↓ Cards ↓ Transactions ↓ Devices ↓ Other Customers ↓ Previous Cases Enter fullscreen mode Exit fullscreen mode This creates an additional layer of transparency. The AI might explain that a transaction is suspicious, while the graph allows the analyst to explore the relationships that contributed to that investigation. This creates a useful combination: AI for investigation + Graph for relationships + Evidence for verification. 9. Next Best Action Another important part of the system is that investigation does not end with an explanation. The system can also recommend what should happen next. Depending on the investigation context, an action could involve: requesting additional verification, monitoring the transaction, escalating the case, blocking a card, creating or updating an investigation case. The analyst remains in control. The system provides a recommendation, and the analyst can review and approve or reject it. Investigation ↓ Evidence ↓ Analysis ↓ Recommended Action ↓ Analyst Review ↓ Approve / Reject Enter fullscreen mode Exit fullscreen mode This creates a human-in-the-loop workflow rather than allowing the AI to make unrestricted operational decisions. 10. What We Learned Building this system taught us several important lessons. 1. Graphs change how you think about fraud Initially, it is easy to think about fraud as a classification problem. But once we started modeling the relationships, it became clear that the connections between entities can be just as important as the transaction itself. 2. Multi-agent systems require clear responsibilities Adding more agents does not automatically make a system better. Each agent needs a clearly defined purpose, input, output, and place in the workflow. Otherwise, multiple agents can perform overlapping work and make the system harder to debug. 3. Retrieval quality matters as much as the LLM A powerful language model cannot compensate for poor evidence retrieval. If the system retrieves the wrong transaction, relationship, or historical case, the final explanation can also become unreliable. The investigation pipeline therefore needs strong data retrieval and validation. 4. User experience matters A technically sophisticated backend can still be difficult to use. We learned that investigators need to understand: what the system is doing, which agents are active, what evidence was found, why a recommendation was generated, and what they are expected to do next. That is why we exposed agent activity, graph evidence, and actions directly in the interface. 5. Building with graphs and agents is an iterative process The biggest learning was that the architecture evolves while building. We initially focused heavily on the AI layer. As we worked through the investigation workflow, it became clear that the graph, evidence pipeline, agent responsibilities, and user interface all needed to be designed together. 11. What We Would Improve With More Time There are several areas we would improve in the next version. Better Agent Evaluation We would build a dedicated evaluation framework to measure: agent accuracy, evidence retrieval accuracy, investigation completion rate, false positives, false negatives, latency, and consistency across cases. More Advanced Graph Algorithms We would expand the graph analysis with more advanced techniques for: community detection, suspicious subgraph discovery, graph-based anomaly detection, path analysis, entity similarity, and temporal fraud patterns. This would allow the system to detect more complex fraud networks. Stronger Evidence Tracing We would make every important AI claim traceable to a specific source record or graph relationship. For example: AI Finding ↓ Evidence ID ↓ Transaction / Entity ↓ TigerGraph Relationship Enter fullscreen mode Exit fullscreen mode This would make investigations easier to audit. Better Human-in-the-Loop Controls We would add more granular approval levels and investigation policies. For example: Low Risk → Automatic Monitoring Medium Risk → Analyst Review High Risk → Senior Approval Enter fullscreen mode Exit fullscreen mode The exact policy would depend on the organization's fraud procedures. Production-Scale Testing We would also test the system with significantly larger datasets and concurrent investigation workloads. The goal would be to understand how graph queries, agents, and LLM responses behave under realistic workloads. 12. Final Thoughts This project started with a simple question: Can we make fraud investigation more intelligent without hiding the evidence behind the AI? Our approach was to combine three technologies: AI Agents + TigerGraph + Investigation UI ↓ Evidence-Driven Investigation Enter fullscreen mode Exit fullscreen mode The AI agents provide the reasoning workflow. TigerGraph provides the relationship and graph intelligence. The interface brings everything together for the analyst. The result is an investigation system where the analyst can move from a suspicious transaction to connected evidence, investigation findings, and a recommended next step — all within a single workspace. There is still a lot more to build, especially around evaluation, scalability, graph algorithms, and production deployment. But this project gave us a practical understanding of what happens when LLMs, multi-agent systems, and graph databases are designed together around a real investigation workflow. From suspicious transactions to connected evidence, from multiple AI agents to actionable decisions — the goal is to make complex fraud investigations easier to understand, faster to investigate, and grounded in evidence.