ai-agents fraud-detection gemini xgboost python

Fünf Agenten, die Betrugswarnungen untersuchen anstatt sie nur zu bewerten.

Sehen Sie, wie ein System mit fünf Agenten einen XGBoost-Score mit der Sammlung deterministischer Beweise, der Korrelation von Anmeldungsprotokollen sowie Erklärungen von Gemini verbindet, die den Score niemals ändern.

Verlag: REACTAPP.TOPAuf dieser Website hinzugefügt 8. Nov. 20266 Min. Lesezeit1357 Wörter

Quellen: FraudLens AI: Building AI Agents That Investigate Fraud Like a Human Analyst

Ein Betrugsmodell ist in einer Sache gut: Es zeigt an, dass eine Transaktion verdächtig erscheint. Bei der Beantwortung der Fragen, die ein Analyst tatsächlich benötigt, um einen Fall abzuschließen, ist es jedoch weitaus schwächer. Was ist hier passiert? Warum wirkt es verdächtig? Was sollte man jetzt tun?

FraudLens AI, ein Hackathon-Projekt für den Google Cloud Hackathon 2026, ist um diese zweite Gruppe von Fragen herum konzipiert. Es versucht nicht, eine bessere Betrugsbewertung zu erzeugen. Stattdessen umhüllt es eine bereits vorhandene Bewertung mit fünf zusammenarbeitenden Agenten, die die Ermittlungen durchführen: Sie sammeln verhaltensbezogene Beweise, ordnen Authentifizierungsereignisse zusammen, erstellen eine Fallzusammenfassung und ermöglichen es Analysten, die Daten in einfachem Englisch abzufragen.

Eine Bewertung ist keine Erklärung

Viele Betrugspräventionsysteme stoppen bei einer Zahl wie 0,87. Das dahinterstehende Modell mag hervorragend darin sein, schlechtes Verhalten zu erkennen, doch ein Ermittler, der sich diese Zahl ansieht, hat immer noch keine Ahnung, was geschehen ist oder warum das Modell darauf reagiert hat.

Heute übernimmt eine Person diese Aufgabe. Sie eröffnet das Konto, durchsucht den Transaktionsverlauf, prüft, ob das Gerät bereits zuvor aufgetaucht ist, liest die Authentifizierungsprotokolle, vergleicht die jüngsten Aktivitäten mit älteren Mustern und erstellt schließlich eine Fallbeschreibung, die die Entscheidung rechtfertigt.

All das ist langsam und repetitiv und bricht zusammen, wenn die Anzahl der Alarme in die Höhe schießt. Die Idee hinter FraudLens besteht darin, das Betrugsmodell unverändert zu belassen und die Ermittlungen zu automatisieren, die nach Auslösung eines Alarms beginnen.

Fünf Agenten, fünf Aufgaben

Die Plattform verteilt die Risikobewertung und die Untersuchung auf fünf Agenten. Jeder hat eine spezifische Aufgabe, ähnlich wie Spezialisten die Arbeit innerhalb eines Betrugsbekämpfungsteams aufteilen.

Erkennungsagent

Die Bewertung erfolgt mithilfe eines XGBoost-Klassifikators. Er wurde am öffentlichen Kaggle-Datensatz zur Erkennung von Kreditkartenbetrug getestet, der 284.807 Transaktionen sowie 492 bestätigte Betrugsfälle enthält. Die Validierungsergebnisse:

Metrik	Wert	Einfache Erklärung
ROC-AUC	0.985	ordnet Betrug fast immer über legitime Transaktionen ein
Präzision bei Betrug	82,8%	etwa 1 von 6 Alarmen ist ein Fehlalarm
Rekall bei Betrug	82,1%	etwa 4 von 5 Betrügen werden entdeckt
F1 bei Betrug	82,5%	Gleichgewicht der beiden oben genannten Werte

Das reale Datensatz wird nur zur Überprüfung des Erkennungsmodells verwendet, ein Unterschied, der weiter unten erneut zur Sprache kommt.

Ermittlungsagent

Wenn eine Transaktion die Ermittlungsschwelle überschreitet, erstellt dieser Agent den Kontext dazu. Dabei werden folgende Aspekte berücksichtigt:

Verhaltensmuster des Kontos und Transaktionshistorie
Beträge, die nicht zum Kontostil passen
Verhaltensmuster des Landes und IP-Kontext
Welche Geräte mit welchen Konten verbunden sind
Abweichungen von historischen Mustern

Anstelle von Risikowert: 0,92 liefert das System Erkenntnisse, auf die man handeln kann, wie zum Beispiel „dieser Betrag liegt weit über dem historischen Durchschnitt des Kontos“ oder „dieses Gerät wurde von mehreren verschiedenen Konten verwendet“. Diese Erkenntnisse werden in eine strukturierte Aktenmappe zusammengefasst, die von den nachfolgenden Agenten verwendet wird.

Protokalanalyseagent

Die Anmeldeaktivitäten sind oft der stärkste Beweis, den man hat, insbesondere wenn ein Account-Übernahmeversuch möglich ist. Das Projekt verwendet ein synthetisches Authentifizierungsprotokoll mit Ereignissen wie LOGIN_FAILED, LOGIN_SUCCESS, OTP_FAILED, NEW_DEVICE_REGISTERED und PASSWORD_RESET, und dieser Agent vergleicht diese Ereignisse mit verdächtigen Transaktionen.

LOGIN_FAILED (Multiple) ──> OTP_FAILED ──> NEW_DEVICE_REGISTERED ──> SUSPICIOUS_TRANSACTION

Eine solche Abfolge verrät weitaus mehr als die Transaktion allein. Sie zeigt Übernahmesignale, die ein Modell, das nur auf Zahlungen achtet, niemals erkennen würde.

Wo Gemini passt und wo nicht

Erklärungsagent

Google Gemini tritt erst in dieser Phase ein. Zunächst erzeugen die Erkennungs- und Untersuchungsagenten strukturierte Beweise, und der Erklärungsagent übermittelt diese Beweise an Gemini, damit diese in eine verständliche Darstellung umgewandelt werden können – etwa so: Diese Transaktion wird als KRITISCH markiert, weil sie weit über das normale Verhalten des Kontos hinausgeht und mit ungewöhnlicher Geräte- und Anmeldedatenaktivität übereinstimmt, weshalb sie umgehend überprüft werden muss.

Die wichtige Gestaltungsoption besteht darin, dass Gemini niemals eine Betrugsbewertung festlegt. Dadurch werden Belege dafür erläutert, dass bereits deterministischer Code Ergebnisse erzeugt hat. Das sorgt dafür, dass die Kernentscheidung zuverlässig bleibt, und bedeutet, dass eine Halluzination nicht darüber entscheiden kann, ob eine Zahlung markiert wird.

Abfragen

Analysten können Fragen wie „Zeigen Sie mir kritische Transaktionen aus Nigeria“ eingeben. Dem Modell ist es nicht gestattet, willkürlichen Code oder rohen SQL-Code auszuführen. Stattdessen extrahiert die Funktionsaufruf-Logik von Gemini die Absicht und wandelt sie in validierte Parameter um, die anschließend von herkömmlichem Code verwendet werden, um die Daten abzurufen.

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

Die Datenabfrage bleibt sicher, vorhersehbar und leicht zu prüfen.

Architektur und Daten

Das Ganze wird als Flask-Anwendung in Docker bereitgestellt, auf Render für die Live-Demo gehostet, wobei die Containerarchitektur auch auf Google Cloud Run läuft.

Eine bewusste Entscheidung war es, die Angaben zu Benchmark-Ergebnissen von den Demo-Funktionen zu trennen. Die Kaggle-Daten werden ausschließlich zur Überprüfung der Erkennungsgenauigkeit verwendet, wovon der Wert von 0,985 im ROC-AUC resultiert. Die Live-Untersuchungsflüsse laufen mit synthetischen Unternehmensdaten, da anonymisierte Benchmarks keine relationellen Felder wie Gerätehistorie, Anmeldeprotokolle oder Verbindungen zwischen Konten enthalten.

┌───────────────────────────────────────┐      ┌───────────────────────────────────────┐
│           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      │
                                               └───────────────────────────────────────┘

Von Anfang bis Ende

Wenn ein Analyst eine Untersuchung startet, läuft der Prozess in der richtigen Reihenfolge ab: Der Erkennungsagent bewertet die Transaktion, der Untersuchungsagent sammelt verhaltensbezogene Beweise, der Protokalanalyseagent fügt Authentifizierungsinformationen hinzu, der Erklärungsagent verfasst die Zusammenfassung, und das Ergebnis wird auf dem Fall-Dashboard angezeigt, wo der Abfragenagent weiter recherchieren kann.

So konzipiert, dass Fehler sanft abgefangen werden

AI-APIs stoßen auf Rate-Limits und Netzwerkfehler. Um zu verhindern, dass dies die App lahmlegt, ist der Gemini-Erklärungsdienst vollständig vom deterministischen Prozess abgetrennt.

Falls der Anruf über Gemini ohne diese Trennung fehlschlägt, stirbt die Seite mit einem 500-Fehler ab. Mit dieser Trennung liefert die App dennoch alle wichtigen Risikometriken, Geräteinformationen, Verhaltensabweichungen sowie Protokolldetails, zusätzlich zu einer nicht störenden Meldung, dass die Erklärung vorübergehend nicht verfügbar ist. Im schlimmsten Fall erhält man ein normales Untersuchungs-Dashboard, das seine Funktion dennoch erfüllt.

Lektionen aus der Entwicklung

Sprechen Sie offen über Daten. Die Trennung der Benchmark-Validierung von der synthetischen Demo gewinnt das Vertrauen technischer Prüfer, die sonst jede Zahl in Frage stellen würden.
Sammeln Sie Beweise im Code und arbeiten Sie mit dem LLM zusammen. Regeln und Aggregationen gehören in deterministischen Code. Die Aufgabe des Modells ist es, diese Ausgabe in eine natürliche Erklärung umzuwandeln.
Testen Sie die Komponenten, die keine Live-API benötigen. Die Testsuite umfasst 53 Tests, die auf dem deterministischen Verarbeitungsweg basieren und eine hohe Zuverlässigkeit gewährleisten, ohne bei jedem Ausführungsvorgang API-Tokens verbrauchen zu müssen.

Was kommt als Nächstes

Streaming-Eingabe mit Google Cloud Pub/Sub und Dataflow anstelle von Batch-Verarbeitung
Native Persistenz in Google Cloud mit BigQuery und Firestore
Graphneuronale Netze zur Aufdeckung von Betrugsringen, die sich über mehrere Konten erstrecken
Multimodale Beweismittel – Einbindung von Streit-PDFs, Identitätsdokumenten und Chat-Transkripten in Geminis Kontext

Das Prinzip dahinter

Die Arbeit im Bereich Betrugsprävention endet nicht, sobald ein Modell eine Bewertung ausgibt. Entscheidend ist vielmehr die Beantwortung der Frage, welche Beweise die Warnung erklären und was der Analyst als Nächstes tun sollte. FraudLens teilt diese Aufgaben klar auf: Das Modell erkennt den Betrug, deterministischer Code sammelt Beweise, spezialisierte Agenten untersuchen den Fall, und das LLM erklärt lediglich.