TwinShield: Echtzeit-Betrugserkennung mit Digitalen Zwillingen und MongoDB

Betrug im Bankensektor findet selten isoliert statt. Meist verrät erst das Muster verdächtiger Transaktionen im Kontext des gesamten Nutzerverhaltens die wahren Absichten. Genau hier setzt TwinShield an: Das System nutzt digitale Zwillinge, um jeden Nutzer als dynamisches Profil abzubilden und verdächtige Aktivitäten in Echtzeit zu erkennen.

Ein zentrales Element des Ansatzes ist die kontinuierliche Anpassung. Jede Transaktion – ob legitim oder verdächtig – aktualisiert automatisch das digitale Abbild des Nutzers. Statt statischer Scores liefert TwinShield so kontextbasierte Risikobewertungen, die sich aus dem Vergleich aktueller Handlungen mit der historischen Normalität ergeben. Diese Methode ermöglichte es dem Team um die Entwickler Tupurani Sree Rama Akshaj, Bhuvanesh Naidu, Aakash Samudrala und Chandravadan Rao, ein System zu schaffen, das nicht nur reagiert, sondern lernt.

Die Architektur: Zwei Sammlungen für maximale Effizienz

TwinShields Datenmodell folgt dem Prinzip der Einfachheit: Zwei Hauptsammlungen reichen aus, um das gesamte System am Laufen zu halten. Die erste Sammlung, transactions, speichert jede finanzielle Transaktion als einzelnes Dokument. Darin enthalten sind:

• Nutzer-ID
• Transaktionsbetrag und -zeitstempel
• Geräteinformationen (inkl. Vertrauensstatus)
• Standort und IP-Adresse
• Risikoscore und Anomalie-Klassifizierung (HIGH, MEDIUM, LOW)

Sobald die KI-Engine eine Transaktion bewertet hat, werden die Ergebnisse direkt in diesem Dokument hinterlegt. Das ermöglicht es Dashboards, verdächtige Aktivitäten ohne aufwendige Joins abzurufen – ein entscheidender Vorteil für die Performance.

Die zweite Sammlung, user_profiles, bildet den digitalen Zwilling jedes Nutzers. Dieses Dokument ist alles andere als statisch: Nach jeder Transaktion berechnet das System automatisch neue Metriken wie:

• Durchschnittliche Transaktionshöhe
• Häufig genutzte Geräte und Standorte
• Kumulative Anomalie-Zähler
• Dynamische Risikobewertungen

Die Aktualisierung erfolgt in Echtzeit, sodass das System stets auf dem neuesten Stand ist. Dank dieser Architektur entfällt die Notwendigkeit separater Tabellen für Geräte oder Standorte – in MongoDB werden sie einfach als Arrays innerhalb des Nutzerprofils gespeichert.

Warum MongoDB die bessere Wahl als relationale Datenbanken war

Die Entscheidung für MongoDB statt MySQL oder PostgreSQL fiel nicht ohne Grund. Während relationale Datenbanken für komplexe Joins optimiert sind, punktet TwinShield mit schnellen Lese- und Schreiboperationen auf einzelnen Dokumenten. Besonders deutlich wird dies bei der Verwaltung typischer Geräte oder Standorte eines Nutzers:

In einer relationalen Datenbank müsste jedes Gerät in einer separaten Tabelle gespeichert und bei jeder Anfrage per Join abgefragt werden. In MongoDB hingegen sind diese Listen direkt im Nutzerprofil als Array integriert. Die Prüfung, ob ein Gerät bekannt ist, und die Aktualisierung der Liste erfolgen in einem einzigen Dokument – ohne zusätzliche Datenbankzugriffe.

Ein weiterer entscheidender Vorteil ist die Schema-Flexibilität. Während der Entwicklung wurden mehrfach neue Felder hinzugefügt, etwa der peakAnomalyScore. In MongoDB reichte es, das Feld zu definieren – alte Dokumente erhielten automatisch einen null-Wert, bis sie aktualisiert wurden. Keine Migrationsskripte, keine Downtime. Eine solche Agilität wäre in einer relationalen Datenbank nur mit erheblichem Aufwand umsetzbar gewesen.

Auch die Integration mit dem Backend gestaltete sich dank Spring Data MongoDB unkompliziert. Statt komplexer SQL-Abfragen oder XML-Konfigurationen reichen einfache Methodenaufrufe, die Spring Data in MongoDB-Queries übersetzt. Das reduziert nicht nur den Wartungsaufwand, sondern macht den Code auch leichter verständlich.

Die KI-Engine: Isolation Forest für präzise Anomalie-Erkennung

Für die Betrugserkennung setzt TwinShield auf Isolation Forest, einen Algorithmus aus dem Bereich des unüberwachten Lernens. Das Prinzip ist einfach: Normalerweise werden Datenpunkte in zufällige Partitionen unterteilt. Anomale Datenpunkte – also solche, die sich strukturell von der Mehrheit unterscheiden – werden dabei schneller isoliert. Die Geschwindigkeit, mit der ein Punkt isoliert wird, dient als Maß für seine Anomalie.

Für die Anwendung im Finanzbereich ist dieser Ansatz ideal, denn Betrug zeichnet sich durch Untypizität aus. Statt roher Transaktionsdaten nutzt das System sechs vorgefertigte Merkmale, darunter:

• Abweichung der Transaktionshöhe vom Nutzer-Durchschnitt
• Häufigkeit der Nutzung unbekannter Geräte
• Abweichung des Standorts von historischen Mustern
• Zeitliche Unregelmäßigkeiten (z. B. nächtliche Transaktionen)

Der Modell-Score wird auf einen Wert zwischen 0 und 1 normalisiert. Ab 0,65 gilt eine Transaktion als mittelhoch riskant, ab 0,80 als hochriskant. Um von Anfang an eine Baseline zu haben, wurde das Modell zunächst mit 600 synthetischen Normaltransaktionen vortrainiert. Im Betrieb kann es jederzeit über eine /train-Schnittstelle nachjustiert werden.

Ein zentraler Vorteil von Isolation Forest ist seine geringe Rechenlast, was für Echtzeit-Anwendungen entscheidend ist. Zudem ist der Algorithmus robust gegenüber Ausreißern in den Trainingsdaten – ein wichtiger Faktor, da Betrüger ihre Methoden ständig anpassen.

Ausfallsicherheit: Ein Notfallsystem für kritische Momente

Trotz aller Vorsorge kann es vorkommen, dass die KI-Engine ausfällt. Um die Systemstabilität zu gewährleisten, implementierte das Team einen Java-basierten Regelmechanismus als Fallback. Dieser greift ein, wenn die Anfrage an die Flask-basierte KI-Engine fehlschlägt und übernimmt die Bewertung nach einfachen, aber wirksamen Regeln:

• Transaktionen von unbekannten Geräten werden als hochriskant eingestuft.
• Extrem hohe Beträge oder ungewöhnliche Uhrzeiten lösen Alarm aus.
• Geografisch abweichende Standorte führen zu einer erhöhten Risikobewertung.

Obwohl diese Regeln weniger präzise sind als der Isolation-Forest-Algorithmus, sorgen sie dafür, dass das System auch bei Ausfällen weiterläuft. Die Devise: Lieber eine leicht ungenauere Entscheidung als ein komplett ausgefallenes System.

Simulationen: Praxistests für maximale Zuverlässigkeit

Ein oft unterschätzter Aspekt der Systementwicklung ist das Testen unter realistischen Bedingungen. TwinShield setzt daher auf eine Simulation Engine, die gezielt vier Angriffsmuster nachstellt:

• Große nächtliche Transfers: Hohe Beträge zu ungewöhnlichen Zeiten
• Unbekannte Geräte: Transaktionen von noch nicht registrierten Devices
• Geografische Auffälligkeiten: Standorte, die der Nutzer nie zuvor genutzt hat
• Kombinierte Angriffe: Mehrere Warnsignale gleichzeitig

Jede simulierte Transaktion durchläuft denselben Pipeline wie echte Daten: Bewertung durch die KI, Speicherung in MongoDB und Aktualisierung des digitalen Zwillings. Diese Tests waren nicht nur für die technische Validierung entscheidend, sondern auch für die Demonstration der Systemfähigkeiten gegenüber Stakeholdern.

Die Kombination aus digitalen Zwillingen, flexibler Datenbankarchitektur und adaptiver KI macht TwinShield zu einem vielversprechenden Ansatz für die Betrugsprävention. Während andere Systeme oft statische Regeln oder starre Datenmodelle nutzen, passt sich TwinShield kontinuierlich an – und wird dadurch mit jedem Nutzerverhalten intelligenter. Die nächsten Schritte könnten in der Integration weiterer Datenquellen wie Verhaltensbiometrie oder der Erweiterung um maschinelle Lernmodelle für noch präzisere Vorhersagen liegen.