SentinelShield

Inspiration

Traditional financial fraud detection relies on static, rule-based systems. These systems are rigid and easily exploited by sophisticated fraud schemes that mimic legitimate behavior. The inspiration for SentinelShield comes from the need for a dynamic, intelligent system that can not only identify known fraud patterns but also detect new, evolving threats by analyzing the full context of a transaction, including communication and behavioral data. We wanted to build a "sentinel" that stands guard over financial systems, using a multi-agent approach to connect the dots across seemingly unrelated data points to prevent fraud before it happens.

What it Does

SentinelShield is a multi-step, multi-agent platform for real-time financial fraud detection. It works by orchestrating several specialized AI agents to collaborate in a single, automated workflow.

• Ingest & Index Data: The system continuously ingests a variety of data streams into TiDB Serverless. This includes:
  • Structured Transactional Data: Standard ledger entries, user accounts, and timestamps.
  • Unstructured Communication Data: Chat logs and emails from customer support or internal teams.
  • Behavioral Data: User login times, device information, and transaction frequencies.
• Search & Correlate: When a transaction is flagged as suspicious, an "Investigative Agent" uses TiDB's vector search to find semantically similar text within the communication logs. For example, it might find a customer support chat where the user was asking unusual questions about account transfers, and a different agent might identify that the same account recently had a login from a new, unregistered device.
• Chain LLM Calls:
  • A "Reasoning Agent" takes all the correlated data from the Investigative Agent and feeds it to an LLM.
  • The LLM analyzes the entire context—the suspicious transaction, the similar chat logs, the unusual login—and formulates a comprehensive fraud hypothesis, explaining why this pattern is suspicious and what kind of fraud it likely is.
• Invoke External Tools: A "Response Agent" takes the LLM's conclusion and triggers a final, real-world action.
  • It can automatically flag the account for immediate review by a human analyst, including the detailed report generated by the Reasoning Agent.
  • For high-confidence cases, it can use an API to place a temporary block on the account or block the suspicious transaction, effectively preventing the fraud from completing.
  • It can also send an automated, detailed alert to a Slack channel or a ticketing system for the fraud team. ## How We Built It The architecture is built around a single, unified data store: TiDB Serverless. This was the most critical decision, as it allowed us to use a single database for all data types—transactional, textual, and vector embeddings—and avoid the complexity of a multi-database solution.
• Database: We used a TiDB Serverless cluster to store all our data. The VARCHAR and other data types stored the structured transaction data, while a dedicated table with a VECTOR data type was used to store embeddings of all the communication logs and behavioral patterns.
• Data Ingestion: A Python-based ingestion service simulated real-time data streams for transactions, chat logs, and user behavior, inserting them into the appropriate tables in TiDB.
• Agent Orchestration: We used a custom agentic framework built in Python to manage the flow. The system is event-driven; a new transaction is the trigger for the initial Investigative Agent to begin its work. The agent uses a series of functions that query TiDB, call the LLM, and finally trigger the response APIs.
• Vector & Full-Text Search: We wrote specific SQL queries to leverage TiDB's built-in vector search functions (e.g., VEC_Cosine_Distance) to find the most similar communication logs. We combined this with LIKE and other SQL predicates to filter results based on structured data.
• External APIs: For the final step, we integrated with mock APIs for a payment gateway (to simulate a transaction block) and a Slack bot API (to send alerts to a #fraud-alerts channel). ## Challenges We Ran Into The biggest challenge was creating a cohesive multi-agent system that could seamlessly pass information between different agents. Ensuring that the output of one agent (the Investigative Agent's search results) provided the perfect context for the next agent (the Reasoning Agent's LLM call) required careful prompt engineering and data structuring. We also had to optimize our database queries to ensure that the entire workflow—from a suspicious transaction to a final action—could happen in near real-time, which is essential for effective fraud prevention. ## Accomplishments We're Proud Of We are most proud of the holistic nature of our solution. We didn't just build a better search engine; we built an intelligent system that can "think" and "act" by connecting disparate pieces of information. The seamless integration of TiDB's vector search with its core SQL capabilities allowed us to query different data types in a single query, which is a major technical accomplishment. Furthermore, the modular design of our agentic system means it can be easily expanded with more specialized agents for different types of financial crimes. ## What We Learned We learned that building a truly agentic solution requires thinking beyond a single task. The real value is in orchestrating multiple, specialized components to perform a complex task. TiDB Serverless proved to be the ideal platform for this, as its architecture eliminated the need for a separate vector database and a transactional database, simplifying our architecture and development. We also learned that the quality of the LLM's output is directly proportional to the quality of the context provided, highlighting the critical role of a powerful retrieval and search system like TiDB. ## What's Next for SentinelShield Our plan is to turn SentinelShield into a robust, deployable solution. Our next steps are to:
• Develop a UI for analysts: Build a dashboard that visualizes the multi-step agent's process, showing the correlated data and the LLM's reasoning for each flagged transaction.
• Integrate more data sources: We want to ingest external data streams, such as dark web forum data or public breach reports, to enrich our agent's knowledge base.
• Implement a feedback loop: Build a system where human analysts can provide feedback on the agent's decisions. This feedback can then be used to fine-tune the agent's behavior and improve its accuracy over time, creating a learning system that gets better with every interaction.

Built With

• python