Five agents that investigate fraud alerts instead of just scoring them
See how a five-agent fraud system pairs an XGBoost score with deterministic evidence gathering, login log correlation, and Gemini explanations that never set the score.
This article is published in English.
Sources: FraudLens AI: Building AI Agents That Investigate Fraud Like a Human Analyst
A fraud model is good at one thing: telling you a transaction looks off. It's much worse at answering the questions an analyst actually has to close the case. What happened here? Why does it look suspicious? What should someone do about it right now?
FraudLens AI, a hackathon project for the 2026 Google Cloud Hackathon, is built around that second set of questions. It doesn't try to produce a better fraud score. It wraps an existing score in five cooperating agents that run the investigation: they collect behavioral evidence, line up authentication events, write a case summary, and let analysts query the data in plain English.
A score isn't an explanation
Plenty of fraud systems stop at a number like 0.87. The model behind it may be excellent at spotting bad behavior, but an investigator looking at that number still has no idea what took place or why the model cared.
A person fills that gap today. They open the account, scroll through transaction history, check whether the device has shown up before, read the authentication logs, compare recent activity with older patterns, and finally write a case note that justifies the decision.
All of that is slow and repetitive, and it falls apart when alert volume spikes. The idea behind FraudLens is to keep the fraud model exactly as it is and automate the investigation that starts once the model fires an alert.
Five agents, five jobs
The platform splits risk scoring and investigation across five agents. Each one has a narrow responsibility, much like specialists dividing up work inside a fraud operations team.
Detection agent
Scoring is done by an XGBoost classifier. It was validated on the public Kaggle Credit Card Fraud Detection dataset, which has 284,807 transactions and 492 confirmed fraud cases. The validation numbers:
| Metric | Value | Plain reading |
|---|---|---|
| ROC-AUC | 0.985 | ranks fraud above legit almost every time |
| Precision on fraud | 82.8% | about 1 in 6 alerts is a false alarm |
| Recall on fraud | 82.1% | roughly 4 of 5 frauds get caught |
| F1 on fraud | 82.5% | balance of the two above |
That real-world dataset is used only to validate the detection model, a distinction that comes up again below.
Investigation agent
When a transaction crosses the investigation threshold, this agent builds the context around it. It looks at:
- account behavior and transaction history
- amounts that don't fit the account
- country behavior and IP context
- which devices are linked to which accounts
- departures from historical patterns
So instead of handing over Risk Score: 0.92, the system produces findings someone can act on, for example "this amount is far above the account's historical average" or "this device has been used by several different accounts". Those findings are packed into a structured case file that the next agents consume.
Log analysis agent
Login activity is often the strongest evidence you have, especially when an account takeover is possible. The project uses a synthetic authentication log with events such as LOGIN_FAILED, LOGIN_SUCCESS, OTP_FAILED, NEW_DEVICE_REGISTERED and PASSWORD_RESET, and this agent matches those events against suspicious transactions.
LOGIN_FAILED (Multiple) ──> OTP_FAILED ──> NEW_DEVICE_REGISTERED ──> SUSPICIOUS_TRANSACTION
A sequence like that tells you far more than the transaction does by itself. It exposes takeover signals that a model looking only at payments would never see.
Where Gemini fits, and where it doesn't
Explanation agent
Google Gemini only enters at this stage. The detection and investigation agents produce structured evidence first, and the explanation agent hands that evidence to Gemini to turn into a readable narrative, something like: this transaction is flagged as CRITICAL because it's well beyond the account's normal behavior and lines up with unusual device and login activity, so it needs immediate review.
The important design choice is that Gemini never sets the fraud score. It explains evidence that deterministic code has already produced. That keeps the core decision reliable and means a hallucination can't change whether a payment gets flagged.
Query agent
Analysts can type questions such as "show me critical transactions from Nigeria". The model isn't allowed to run arbitrary code or raw SQL. Instead, Gemini function calling extracts the intent and turns it into validated parameters, which ordinary code then uses to fetch the data.
Natural Language Request
│
▼
Gemini Function Calling (Intent Extraction)
│
▼
Structured Filters (risk_tier = CRITICAL, country = Nigeria)
│
▼
Application Parameter Validation
│
▼
Controlled Pandas Filtering Layer
│
▼
Filtered Transaction Results
Retrieval stays safe, predictable and easy to audit.
Architecture and data
The whole thing ships as a Flask app in Docker, hosted on Render for the live demo, with a container layout that also runs on Google Cloud Run.
One deliberate choice was to keep benchmark claims and demo capability apart. The Kaggle data is used only to validate detection, which is where the 0.985 ROC-AUC comes from. The live investigation flows run on synthetic enterprise data, because anonymized benchmarks don't include relational fields like device history, login logs or links between accounts.
┌───────────────────────────────────────┐ ┌───────────────────────────────────────┐
│ REAL KAGGLE DATA │ │ SYNTHETIC ENTERPRISE │
│ 284,807 Transactions │ │ 50,000 Transactions + Logs │
└───────────────────┬───────────────────┘ └───────────────────┬───────────────────┘
│ │
▼ ▼
┌───────────────────────────────────────┐ ┌───────────────────────────────────────┐
│ XGBoost Validation │ │ Live Investigation │
│ ROC-AUC 0.985 | Precision/Recall 82% │ │ Accounts + Devices + Auth Logs │
└───────────────────────────────────────┘ └───────────────────┬───────────────────┘
│
▼
┌───────────────────────────────────────┐
│ Interactive Dashboard │
│ Evidence + Gemini Narrative │
└───────────────────────────────────────┘
End-to-end flow
When an analyst starts an investigation, the pipeline runs in order: the detection agent scores the transaction, the investigation agent assembles behavioral evidence, the log analysis agent adds authentication context, the explanation agent writes the narrative, and the result lands on the case dashboard where the query agent can dig further.
Built to fail gracefully
AI APIs hit rate limits and network errors. To stop that from taking the app down, the Gemini narrative service is fully separated from the deterministic pipeline.
If the Gemini call fails without that separation, the page dies with a 500 error. With it, the app still returns every core risk metric, device flag, behavioral deviation and log detail, plus a non-blocking notice that the explanation narrative is temporarily unavailable. In the worst case you get a normal investigation dashboard that still does its job.
Lessons from the build
- Be upfront about data. Keeping benchmark validation separate from the synthetic demo earns trust with technical reviewers who would otherwise question every number.
- Collect evidence in code, reason with the LLM. Rules and aggregation belong in deterministic code. The model's job is turning that output into a natural explanation.
- Test the parts that don't need a live API. The suite has 53 tests aimed at the deterministic pipeline, which keeps reliability high without spending API tokens on every run.
What comes next
- streaming ingestion with Google Cloud Pub/Sub and Dataflow instead of batch processing
- native persistence on Google Cloud with BigQuery and Firestore
- graph neural networks to uncover fraud rings spread across many accounts
- multimodal evidence, feeding dispute PDFs, identity documents and chat transcripts into Gemini's context
The principle behind it
Fraud work doesn't end when a model prints a score. The value is in answering which evidence explains the alert and what the analyst should do next. FraudLens divides that up cleanly: the model detects, deterministic code gathers evidence, specialized agents investigate, and the LLM only explains.