← Alle Beiträge
04.06.2026 · 9 min

Fraud Detection mit Graph Neural Networks: Warum DACH-Banken 2026 Rules-Engines nur noch als Fallback brauchen

GNNs erkennen koordinierten Transaktionsbetrug, den Regelwerke strukturell übersehen. Aber die BaFin fordert Erklärbarkeit. Wie Fraud-Teams den Umstieg gestalten.

Warum klassische Regelwerke an ihre Grenzen stoßen

Regelbasierte Transaction-Monitoring-Systeme sind das Rückgrat der AML- und Fraud-Compliance in DACH-Banken. Aus gutem Grund. Sie sind transparent, auditierbar, BaFin-akzeptiert. Eine Regel wie „Bareinzahlung über 9.500 Euro innerhalb von 24 Stunden, kombiniert mit Sofortüberweisung ins EU-Ausland” lässt sich dokumentieren, begründen und im Prüfungsdialog verteidigen. Genau diese Eigenschaften haben Rules-Engines zwei Jahrzehnte überleben lassen.

Die strukturellen Schwächen sind aber inzwischen schmerzhaft. Drei davon stechen heraus.

Erstens die Latenz bei Regelupdates. Wenn ein neues Betrugsmuster auftaucht, durchläuft eine neue Regel typischerweise einen Prozess aus Spezifikation, Backtesting, Compliance-Freigabe und Produktivsetzung. Sechs bis zwölf Wochen sind in mittelgroßen Häusern Standard. Betrugsringe ändern ihre Taktik in Tagen.

Zweitens die False-Positive-Rate. In Retail-Banking-Umgebungen liegt sie bei klassischen AML-Monitoring-Systemen typischerweise zwischen 90 und 98 Prozent. Das bedeutet: Von 100 generierten Alerts sind 2 bis 10 echte Treffer. Der Rest wird manuell von AML-Analysten geprüft. Die Personalkosten für diesen Review-Aufwand sind in DACH-Großbanken einer der größten operativen Posten der Geldwäscheprävention.

Drittens, und das ist der eigentliche Punkt: blinde Flecken bei koordiniertem Betrug. Rules-Engines bewerten Transaktionen einzeln oder maximal pro Konto. Ein Money-Mule-Netzwerk verteilt Beträge gezielt unter Schwellenwerten über dutzende Konten, die untereinander durch gemeinsame Geräte, IPs oder Zeitmuster verbunden sind. Auf Einzeltransaktionsebene sieht jede Zahlung legitim aus. Das Netzwerk wird erst sichtbar, wenn man die Verbindungen analysiert.

Genau das ist das Grundproblem: Betrugsnetzwerke sind Graphen. Regelwerke sind Listen. Eine Liste kann ein Netzwerk nicht abbilden.

Wie Graph Neural Networks Transaktionsbetrug erkennen

Die Kernidee ist konzeptionell einfach. Transaktionen, Konten, Geräte, IP-Adressen, Telefonnummern und Empfänger werden als Nodes modelliert. Beziehungen zwischen ihnen sind Edges. „Konto A überweist an Konto B” ist eine Edge. „Konto A und Konto C wurden vom gleichen Gerät eröffnet” ist eine Edge. „IP-Adresse X loggt sich in 47 verschiedene Konten ein” ist eine Struktur, die im Graphen sofort sichtbar wird.

Ein Graph Neural Network lernt nun, Muster in diesen Strukturen zu erkennen. Der Mechanismus heißt Message Passing. Jeder Node aggregiert Information von seinen Nachbarn, die wiederum von ihren Nachbarn, und so weiter. Nach zwei oder drei sogenannten Hops hat ein Konto Kontextinformation über sein gesamtes Umfeld eingebettet. Wenn dieses Umfeld typische Merkmale eines Mule-Netzwerks aufweist (etwa hohe Verbindungsdichte zu kürzlich eröffneten Konten, gemeinsame Geräte-Footprints, zyklische Zahlungsströme), schlägt das Modell an.

Konkret erkennen GNNs Muster, die Rules-Engines strukturell verpassen:

  • Money-Mule-Netzwerke: 50 frisch eröffnete Konten, die untereinander kleine Beträge transferieren und am Ende auf ein Sammelkonto auszahlen. Jede Einzeltransaktion unauffällig, das Gesamtmuster eindeutig.
  • Synthetische Identitäten: Konten, die zwar formal saubere KYC-Daten haben, aber im Graphen Verbindungen zu bekannten Betrugsclustern zeigen, etwa über gemeinsame Telefonnummern oder Lieferadressen.
  • Layering im AML-Kontext: Mehrstufige Strukturen, in denen Gelder über Strohfirmen, Treuhandkonten und internationale Korrespondenzbanken bewegt werden. Klassische Schwellenwertregeln greifen hier nicht, die Graphstruktur ist eindeutig.

Die Echtzeit-Anforderung ist die eigentliche technische Hürde. Für Karten-Transaktionen liegt das Latenz-Budget typischerweise unter 200 Millisekunden zwischen Autorisierungsanfrage und Entscheidung. In dieser Zeit muss das GNN nicht nur die aktuelle Transaktion bewerten, sondern den relevanten Teilgraphen abrufen und scoren. Das funktioniert nur mit vorberechneten Graph-Snapshots, Approximate Inference und einer sehr eng dimensionierten Inferenz-Pipeline. Architektonisch heißt das: Graph-Datenbank mit Real-Time-Read-Layer, Feature-Store mit aktuellen Embeddings, GNN-Modell als ONNX- oder TorchServe-Deployment hinter einem Low-Latency-Gateway.

GNN vs. Rules-Engine: Ein ehrlicher Vergleich für DACH-Fraud-Teams

Die Marketingfolien der GNN-Anbieter zeigen typischerweise nur die Accuracy-Gewinne. Das greift zu kurz. Hier ein realistischer Vergleich auf den Dimensionen, die in der Praxis zählen.

Dimension Rules-Engine GNN
Erkennung bekannter Muster sehr gut gut
Erkennung koordinierter Netzwerke schwach sehr gut
False-Positive-Rate hoch (90 bis 98 Prozent) deutlich niedriger (typisch 60 bis 80 Prozent)
Adaptionsgeschwindigkeit auf neue Muster langsam (Wochen bis Monate) schnell (Re-Training in Tagen)
Erklärbarkeit auf Einzelfall hoch eingeschränkt
Compliance-Dokumentationsaufwand etabliert hoch und teilweise ungelöst
Implementierungskosten initial niedrig hoch
Betriebskosten laufend hoch (manueller Review) niedriger (weniger False Positives)

Klar überlegen sind GNNs bei drei Szenarien: koordiniertem Betrug, neuen Angriffsvektoren ohne historische Regelbasis und Cross-Channel-Fraud (etwa wenn Online-Banking, Karten und Mobile-Wallet kombiniert missbraucht werden).

Unverzichtbar bleiben Rules-Engines 2026 in mindestens drei Bereichen. Erstens bei klaren regulatorischen Schwellenwerten (Geldwäschegesetz-Schwellen, FATF-Meldepflichten). Diese müssen deterministisch und auditierbar greifen, nicht probabilistisch. Zweitens beim Sanktionslisten-Screening. EU-Sanktionslisten, OFAC-Listen, PEP-Datenbanken werden per Exact-Match oder Fuzzy-Match abgeglichen, nicht per Embedding. Drittens bei der Ad-hoc-Reaktion auf akute Bedrohungen. Wenn das BKA am Dienstag warnt, dass eine bestimmte IBAN-Range kompromittiert ist, brauchen Sie eine Regel, die in Stunden produktiv ist, nicht einen Trainingszyklus.

Das vernünftige Zielbild ist deshalb hybrid: GNN als primärer Scoring-Layer, Rules-Engine als deterministischer Override und Fallback. Wenn das GNN ausfällt oder einen unsicheren Score liefert, übernimmt die Rules-Engine. Wenn die Rules-Engine eine kritische Schwelle reißt, überstimmt sie das GNN-Urteil.

Die BaFin-Frage: Explainability als regulatorisches Nadelöhr

Hier liegt der eigentlich kritische Punkt für DACH-Banken. BaFin, FMA und FINMA fordern bei Modellen, die in regulatorisch relevante Entscheidungen einfließen, drei Dinge: Nachvollziehbarkeit der Modellentscheidung, dokumentierte Modell-Governance und Backtesting-Pflichten mit definierten Performance-Schwellen. Die MaRisk-Anforderungen an Modellrisiko und das BAIT-Rundschreiben sind hier eindeutig.

Das Problem: Graph-Embeddings lassen sich nicht so erklären wie ein Entscheidungsbaum. Wenn ein GNN sagt „Konto X hat Fraud-Score 0.87”, liegt diese Bewertung in einem hochdimensionalen Vektorraum, der durch dutzende Layer Message Passing entstanden ist. Eine direkte „Wenn-Dann-Begründung” gibt es nicht.

Praktisch lösbar ist das durch Post-hoc-Erklärungen. Drei Ansätze haben sich in der Praxis etabliert:

  1. GNNExplainer und Varianten: Identifizieren den minimalen Subgraphen, der für die Modellentscheidung kausal relevant war. Das Ergebnis lässt sich visualisieren: „Diese 12 Konten und 23 Verbindungen haben den Score getrieben.”
  2. Attention-basierte Visualisierung: Bei Graph-Attention-Networks lässt sich gewichten, welche Nachbarn wie stark zur Entscheidung beigetragen haben. Compliance-tauglich, wenn sauber dokumentiert.
  3. Feature-Attribution auf Node-Ebene: Welche konkreten Eigenschaften (Transaktionsfrequenz, Geräte-Sharing, geografische Verteilung) hatten welchen Einfluss?

Die entscheidende regulatorische Frage ist: Wann reicht Erklärbarkeit auf Systemebene, wann braucht es Erklärbarkeit auf Einzelfall-Ebene? Aus meiner Sicht ist die pragmatische Linie folgende. Bei reinen Fraud-Alerts, die einen menschlichen Review triggern, reicht Systemebene-Dokumentation: Performance-Metriken, Drift-Monitoring, Backtesting. Bei Entscheidungen mit direkter Kundenkonsequenz (Kontosperrung, Ablehnung einer Transaktion, AML-Verdachtsmeldung) ist Einzelfall-Erklärbarkeit Pflicht.

Der EU AI Act, der 2026 in vollem Umfang greift, klassifiziert Fraud- und Credit-Scoring-Systeme als Hochrisiko. Das bedeutet: Risk-Management-System, Daten-Governance-Dokumentation, technische Dokumentation, Logging, menschliche Aufsicht, Genauigkeits-Robustheits-Cybersicherheits-Anforderungen. Die Dokumentationspflichten sind erheblich. Wer jetzt ein GNN-System produktiv setzt, ohne diese Pflichten von Tag eins mitzudenken, baut technische Schulden auf, die später teuer werden.

Migrationspfad: Von der Rules-Engine zum GNN-First-Ansatz

Der Big-Bang-Wechsel von Rules zu GNN ist in einer regulierten Bank weder realistisch noch verantwortbar. Sinnvoll ist ein dreistufiger Migrationspfad.

Phase 1, Parallel-Betrieb als Shadow-Model. Das GNN läuft produktiv mit, entscheidet aber nichts. Die Rules-Engine bleibt der einzige Entscheider. Sie sammeln über sechs bis zwölf Monate Daten darüber, wo GNN und Rules übereinstimmen, wo sie abweichen und welche Alerts in welcher Variante echte Treffer waren. Diese Drift-Analyse ist die Basis jeder späteren regulatorischen Argumentation.

Phase 2, Hybrid-Produktivbetrieb. Das GNN übernimmt das Scoring, die Rules-Engine wird zum Fallback und zum Override für definierte Hochrisiko-Schwellen. Confidence-basierte Routing: Wenn der GNN-Score zwischen 0.3 und 0.7 liegt, entscheidet zusätzlich die Rules-Engine. Bei klaren Scores oben oder unten reicht das GNN-Urteil. Diese Phase dauert typischerweise 12 bis 18 Monate.

Phase 3, GNN-First mit regelbasiertem Residual-Layer. Das GNN ist primärer Entscheider. Die Rules-Engine bleibt nur noch für Compliance-kritische Fälle aktiv: Sanktionslisten-Screening, regulatorische Schwellen, akute Bedrohungs-Patches. Das ist der Zielzustand, den realistisch wenige DACH-Häuser vor 2027 erreichen.

Die Datenpipeline-Voraussetzungen sind erheblich. Sie brauchen eine Graph-Datenbank, die produktive Read-Latenzen unter 50 Millisekunden liefert (Neo4j, TigerGraph, oder bei sehr großen Volumen verteilte Lösungen wie JanusGraph). Sie brauchen einen Feature-Store mit Real-Time-Inference-Capability (Tecton, Feast, oder Eigenentwicklung). Und Sie brauchen Label-Qualität bei extrem unbalancierten Datasets: Fraud-Quoten liegen typischerweise unter 0.5 Prozent. Ohne saubere Labels und Resampling-Strategien wird kein Modell brauchbar.

Typische Stolpersteine in der Praxis: das Cold-Start-Problem bei neu eröffneten Konten ohne Transaktionshistorie, Concept Drift bei sich verändernden Betrugsmustern (besonders nach Veröffentlichung neuer Modelle in der Cybercrime-Szene) und der erhebliche Monitoring-Overhead. Ein produktives GNN-System ohne kontinuierliches Drift- und Performance-Monitoring ist regulatorisch nicht haltbar.

Praxis-Einblick: Was in DACH-Banken realistisch ist

Realistische Zahlen für eine Retail-Bank mit drei bis fünf Millionen Kunden und einem mittelgroßen Fraud-Team von 15 bis 30 Personen: Ein produktives GNN-System inklusive Datenpipeline, Modell-Entwicklung, Compliance-Dokumentation und Go-Live liegt bei 18 bis 30 Monaten Projektlaufzeit und 4 bis 8 Millionen Euro Gesamtbudget bei Eigenentwicklung. Bei Plattform-Einsatz (Featurespace, DataVisor, ThetaRay) reduziert sich die Laufzeit auf 9 bis 15 Monate, die Lizenzkosten liegen bei 800.000 bis 2 Millionen Euro pro Jahr, je nach Volumen.

Build vs. Buy ist die zentrale strategische Frage. Mein Rat: Eine eigene GNN-Fraud-Plattform lohnt sich nur, wenn Sie mindestens zehn Data Scientists mit Graph-ML-Erfahrung halten können und wenn Sie strategisch eigene Modelle als Differenzierungsmerkmal sehen. Für die meisten Häuser im DACH-Raum ist das nicht der Fall. Spezialisierte Plattformen sind deshalb für Sparkassen, Volksbanken und mittelgroße Privatbanken der pragmatischere Weg.

Die organisatorische Voraussetzung wird unterschätzt. Data Scientists mit produktiver Graph-ML-Erfahrung sind in DACH selten. Wer 2026 starten will, muss entweder jetzt rekrutieren (mit allen Schwierigkeiten des Marktes) oder bestehende Teams gezielt upskillen. Letzteres dauert realistisch 12 bis 18 Monate, bis ein erfahrener ML-Engineer produktiv Graph-Modelle bauen und betreiben kann.

Meine Einschätzung zur Adoption nach Segment: Neobanken und Direktbanken sind 2026 die treibenden Player. N26, bunq und revolut-ähnliche Häuser haben die technische Basis und den geschäftlichen Druck. Großbanken (Deutsche Bank, Erste Group, UBS) bewegen sich, aber in eigenem Tempo, oft über Innovation-Labs und mit Plattform-Lösungen. Sparkassen und Volksbanken werden 2026 mehrheitlich noch nicht produktiv sein, sondern über die Verbund-IT (Finanz Informatik, Atruvia) zentrale Lösungen pilotieren. Das ist nicht abwertend gemeint. Es ist die realistische Geschwindigkeit eines föderalen Verbunds.

Fazit: Die Rules-Engine stirbt nicht, sie wird zum Sicherheitsnetz

Graph Neural Networks sind 2026 keine Wette mehr, sie sind der State of the Art in der Fraud-Erkennung. Wer in DACH-Banken Verantwortung für AML und Fraud-Prevention trägt und nicht mindestens eine Shadow-Mode-Initiative laufen hat, ist im Rückstand. Das ist keine Frage von „ob”, sondern von „wann und wie geordnet”.

Gleichzeitig stirbt die Rules-Engine nicht. Sie wird zum regulatorisch notwendigen und operativ sinnvollen Sicherheitsnetz. Sanktionslisten-Screening, harte regulatorische Schwellen und Ad-hoc-Reaktionen auf akute Bedrohungen brauchen deterministische Logik. Das Zielbild ist ein hybrides System mit klarer Rollenverteilung: GNN als primärer Erkennungsmotor, Rules als Fallback und Override.

Drei konkrete Handlungsempfehlungen für Fraud- und AML-Verantwortliche:

  1. Jetzt mit Shadow-Mode starten. Ohne Drift-Daten aus dem Parallel-Betrieb haben Sie 2027 keine regulatorische Argumentationsbasis. Die Datensammlung beginnt nicht mit dem Go-Live, sondern Monate davor.
  2. Governance-Dokumentation von Tag eins mitziehen. EU AI Act, MaRisk und BAIT sind keine nachgelagerten Themen. Wer das Modell baut und die Dokumentation später nachzieht, baut technische und regulatorische Schulden auf, die teuer werden.
  3. Build vs. Buy ehrlich entscheiden. Eigenentwicklung nur, wenn die Personaldecke trägt. Sonst Plattform und Fokus auf Daten-Pipeline und Compliance-Integration.

Der Ausblick auf 2027 und 2028 ist klar: Temporal GNNs, die zeitliche Dynamik von Betrugsmustern besser modellieren, werden Standard. Federated Learning für Banken-Konsortien (DACH-weite Modelle, ohne dass Banken sensible Daten austauschen) ist technisch in Reichweite und regulatorisch der elegante Ausweg aus dem Datenschutz-Dilemma gemeinsamer Fraud-Erkennung. Und LLM-basierte Analyst-Copilots, die GNN-Alerts in natürlicher Sprache erklären und Ermittlungs-Hypothesen vorschlagen, werden den manuellen Review-Aufwand weiter senken.

Die Bank, die 2028 die niedrigsten Fraud-Verluste und die niedrigsten False-Positive-Raten hat, ist nicht die mit der teuersten Plattform. Es ist die, die heute mit Shadow-Mode startet und ihre Governance sauber aufbaut. Die Werkzeuge sind da. Die regulatorische Klarheit kommt. Die Entscheidung liegt bei den Verantwortlichen.

Newsletter

Ein Newsletter, unbegrenztes Wissen.

Jede Woche die aktuellsten News zum Thema künstliche Intelligenz für den Einsatz in Ihrem Unternehmen.