Transaktionsüberwachung zur Geldwäschebekämpfung

Banken, Zahlungsinstitute, E-Geld-Emittenten, Krypto-Anbieter und andere Verpflichtete müssen Kundentransaktionen überwachen und Verdachtsfälle an die zentrale Meldestelle melden (in Deutschland: die FIU, über goAML). Klassische Regelszenarien („mehr als X EUR Bargeld pro Woche“) erzeugen überwiegend Fehlalarme, die Analysten von Hand schließen. ML ergänzt Regeln um Risikobewertung, Netzwerkanalyse und Anomalieerkennung; LLMs helfen Analysten, Fälle zusammenzufassen und Berichte zu entwerfen. Die Entscheidung, eine Meldung abzugeben, bleibt bei einer qualifizierten Person (Geldwäschebeauftragte(r) / MLRO).

Problem & Nutzen

• Heute: regelbasierte Szenarien mit Schwellenwerten, die im Batch auf Kundensegmente angewendet werden. Große Mengen an Warnmeldungen, ein hoher Anteil an Fehlalarmen, und Analysten tragen für jeden Fall denselben Kontext erneut zusammen (KYC-Akte, frühere Transaktionen, Gegenparteien). Aufsichtsbehörden erwarten dokumentierte, risikobasierte, rückgetestete Überwachung und kritisieren zugleich übersehene verdächtige Aktivitäten.
• KI-Nutzen: (1) Warnmeldungen nach gelerntem Risiko priorisieren, sodass Analysten die wahrscheinlichsten echten Treffer zuerst sehen; (2) Muster erkennen, die Regeln übersehen (Aufteilung von Beträgen über Konten, Trichter- und Mule-Netzwerke, schnelle Durchleitung); (3) Warnmeldungen automatisch zusammenfassen und Berichtstexte entwerfen, was die Bearbeitungszeit senkt; (4) Schwellenwerte mit Evidenz statt Vermutung justieren.
• Ausmaß des Problems: eine häufig zitierte Schätzung der UN beziffert die jährliche Geldwäsche auf 2–5 % des weltweiten BIP; verlässliche Labels sind knapp, weil der Großteil der Geldwäsche nie entdeckt wird – deshalb sind öffentliche AML-Benchmarks synthetisch [3]. Von Anbietern behauptete Rückgänge bei Fehlalarmen schwanken stark je Institut und lassen sich nicht verallgemeinern; messen Sie am eigenen Backtest (siehe Kennzahlen).
• Regulatorischer Treiber: Die EU-Geldwäscheverordnung (EU) 2024/1624 gilt ab dem 10. Juli 2027; die neue EU-Behörde AMLA (Frankfurt) soll 2028 die direkte Aufsicht über ausgewählte grenzüberschreitende Hochrisiko-Institute aufnehmen, wobei im Lauf von 2027 etwa 40 Institute ausgewählt werden [1][2]. Erwarten Sie harmonisierte Regeln und mehr Aufsichtsinteresse an der Modell-Governance.

Varianten

• Privat- und Firmenkundengeschäft von Banken: der Kernfall (kontenbasierte Überwachung, Korrespondenzbanken, Indikatoren für handelsbasierte Geldwäsche).
• Zahlungsinstitute, E-Geld, Neobanken, Marktplätze: Sofortzahlungen mit hoher Geschwindigkeit; Bewertung in Echtzeit oder nahezu in Echtzeit; eng verwandt mit der Erkennung von Mule-Konten ANOM-022 und Betrug ANOM-001.
• Anbieter von Krypto-Dienstleistungen: On-Chain-Analyse und Travel-Rule-Daten, behandelt in ANOM-023.
• Kapitalmarkt / Vermögensverwaltung / Versicherung: Überwachung von Wertpapierströmen, Prämienerstattungen, Einmalprämien-Produkten; Marktmissbrauch ist ein eigenes Thema (ANOM-012).
• Nichtfinanzielle Verpflichtete (KMU): Immobilienmakler, Notare, Händler hochwertiger Güter, Wirtschaftsprüfer, Steuerberater: in der Regel Risikobewertung, Checklisten zur Kundensorgfalt und Hinweise auf ungewöhnliche Transaktionen statt vollständiger Überwachungssysteme; Anbieter für dieses Segment sind meist KYC-Portal-Werkzeuge.
• Öffentlicher Sektor (FIU): Analyse eingehender Meldungen und Netzwerk-Vorsortierung auf Behördenseite. Das liegt nahe an der Strafverfolgung; siehe die Grenzen im Abschnitt zur Regulierung.
• Private Nutzung: keine; dies ist kein Anwendungsfall für Endverbraucher.
• Verwandt, aber getrennt: Sanktions-/PEP-Screening (ANOM-016), Identitätsprüfung beim Onboarding (ANOM-014), gefälschte Dokumente (ANOM-017).

So funktioniert es

1. Kernbanksystem / Zahlungsverkehr / Karten
2. Ereignisstrom + Data Lake
3. Datenaufbereitung (Kunde 360, Gegenparteiauflösung, Entitätsauflösung)
4. Erkennungsschicht a) Regelszenarien (regulatorische Basis, erklärbar) b) überwachte Modelle (Gradient Boosting auf gelabelten Warnmeldungsergebnissen) c) unüberwachte / Anomaliemodelle (Abweichung von der Vergleichsgruppe, neues Verhalten) d) Graphanalyse (gemeinsame Geräte/Adressen, Trichter, Kreisflüsse, GNN)
5. Warnmeldungserzeugung + Deduplizierung zu Fällen
6. Priorisierung der Warnmeldungen (Risikowert + Begründungscodes)
7. LLM-Assistent: Fallzusammenfassung, Beweissammlung, Berichtsentwurf
8. Prüfung durch Analysten (Vier-Augen-Prinzip)
9. eskalieren / mit Begründung schließen
10. Entscheidung der/des Geldwäschebeauftragten
11. Verdachtsmeldung (goAML) + Feedbackschleife zu den Modellen

• Regeln bleiben. Aufsichtsbehörden erwarten eine dokumentierte, szenariobasierte Grundlage. ML sitzt typischerweise als zweite Schicht darüber: Sie sortiert Regel-Warnmeldungen neu, unterdrückt einen Teil davon und ergänzt zusätzliche Warnmeldungen – mit dokumentierten Schwellenwerten und Backtesting (Below-the-Line-Tests).
• Überwachte Modelle brauchen Labels aus früheren Ergebnissen von Warnmeldungen; die Labels sind verrauscht und verzerrt zugunsten dessen, was Regeln bereits markiert haben. Gegenmittel: Stichproben aus nicht alarmierter Aktivität und regelmäßige zufällige Prüfungen.
• Graphverfahren: Entitätsauflösung und Transaktionsgraphen machen organisierte Strukturen sichtbar, die Einzelkonto-Sichten übersehen. GNNs (z. B. über PyTorch Geometric) zeigen auf synthetischen Benchmarks starke Ergebnisse [3]; im Produktivbetrieb sind erklärbare Graph-Merkmale, die in Boosted Trees eingespeist werden, üblich.
• LLMs: fassen einen Fall zusammen, extrahieren Fakten aus KYC-Dokumenten, schlagen eine Bearbeitung mit belegten Nachweisen vor und entwerfen den Berichtstext in der Struktur der Aufsichtsbehörde. Sie entscheiden nie selbst über das Schließen oder Melden.
• Mensch-in-der-Schleife (Human-in-the-Loop): Bearbeitung durch Analysten, Meldeentscheidung der/des Geldwäschebeauftragten, Freigabe von Änderungen durch das Modellrisiko-Komitee.

Datenaufbereitung

Benötigte Daten: Transaktionen, Konto- und Kundenstammdaten (KYC), wirtschaftlich Berechtigte, Sanktions- und PEP-Listen, frühere Warnmeldungen und Fallergebnisse. Sie liegen im Kernbanksystem, in der Zahlungsplattform, im CRM, im KYC-Werkzeug und oft in gescannten Onboarding-Dokumenten und E-Mails. Typische Lücken: uneinheitliche Kundenkennungen über Systeme hinweg, doppelte Parteien, Namen und Adressen schlechter Qualität, ungelabelte historische Warnmeldungen (Fehlalarm oder SAR gemeldet), gescannte Ausweispapiere und fehlende Nachvollziehbarkeit der Entscheidungen der Analysten.

Aufbereitungsschritte: einen bereinigten Gesamtdatensatz („Golden Record“) für Kunden und Gegenparteien aufbauen (PREP-005, PREP-011), Labels aus geschlossenen Fällen und abgegebenen Verdachtsmeldungen gewinnen (PREP-020), Kategorien für Warnmeldungen festlegen (PREP-019), Papier-KYC-Akten per OCR digitalisieren (PREP-006) und mit Compliance-Fachleuten einen Testdatensatz aufbauen (PREP-018). Zweck und Rechtsgrundlage klären (PREP-025); für die Modellentwicklung pseudonymisieren (PREP-022). Siehe auch DATA-003 und DATA-008.

Grober Aufwandsanteil: 50–60 Prozent des Projekts; die Datenqualität wiegt schwerer als die Modellwahl.

Umsetzungswege

Welcher Weg für wen

• Großunternehmen: Weg B, weil große Institute eigene Datenplattformen betreiben und auf den Kernbankdaten abgestimmte Szenarien und erklärbare Modelle brauchen – bei Bedarf mit Anbieter-Engines.
• Entwickler: Weg C, weil quelloffene Graph- und Anomalie-Bibliotheken auf HW1/HW2 es erlauben, Überwachungslogik aufzubauen und zu prüfen, ohne Kundendaten nach außen zu geben.
• KMU: Weg A, weil kleine Verpflichtete (Zahlungsinstitute, Broker, Händler) ein zertifiziertes, von der Aufsicht akzeptiertes Produkt mit Aktualisierungen für Sanktionen und Typologien brauchen.
• Öffentlicher Sektor: Weg C, weil Behörden und öffentliche Einrichtungen souveränes, prüfbares Hosting in Deutschland ausländischer SaaS vorziehen.

Weg A — Kaufen (für die meisten Verpflichteten empfohlen)

• AML-/FIU-Plattformen mit ML: Hawk (Hawk AI, München; EU/Deutschland), Lucinity (Island/EU), Feedzai, NICE Actimize, SAS Anti-Money Laundering, Oracle Financial Crime and Compliance Management, Quantexa (Entitätsauflösung und Netzwerkanalyse), Napier AI, ComplyAdvantage, Tookitaki, Unit21, Sardine, Silent Eight (Bearbeitung von Warnmeldungen), integrierte Module von Fiserv/FIS/Temenos. Prüfen Sie auch regionale Kernbank- und Sparkassen-/Genossenschaftsbank-Dienstleister (Sparkassen, Volksbanken), die die Geldwäscheüberwachung oft für ihre Mitgliedsinstitute bündeln.
• Vor dem Kauf prüfen: Datenspeicherung in der EU, Anforderungen von BaFin/EBA an Auslagerung und DORA-Drittanbieter, Modelltransparenz (Begründungscodes, Backtesting-Werkzeuge), goAML-Export, Möglichkeit, eigene Szenarien zu betreiben, Anpassung ohne Anbieter-Tickets sowie Referenzen von Instituten Ihrer Größe.
• Wählen Sie A, wenn: Sie eine regulierte Bank, ein Zahlungs- oder E-Geld-Institut sind. Eine vollständige Engine im eigenen Haus lohnt sich selten unterhalb der Größe einer Großbank. Die oben genannten Anbieterangaben sollten in einer Ausschreibungsrunde erneut geprüft werden; Produktnamen ändern sich durch Übernahmen.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Daten und ML: Data Warehouse/Lakehouse in einer EU-Region (Azure, AWS Frankfurt, Google Cloud EU oder EU-Anbieter wie STACKIT, OVHcloud, IONOS), Streaming mit Kafka/Flink, Gradient Boosting (XGBoost, LightGBM) und Graphdatenbank (Neo4j, Memgraph, Amazon Neptune).
• LLM-Schicht: Mistral (EU) oder Claude, Gemini, GPT über EU-Regionen/EU-Datengrenzen und mit Zero-Retention-Bedingungen für Fallzusammenfassungen und SAR-Entwürfe. Strukturierte Ausgabe und Verweise auf Transaktions-IDs verwenden.
• Wählen Sie B, wenn: Sie bereits eine Datenplattform haben und eine maßgeschneiderte Schicht brauchen, z. B. einen Copiloten für Alert-Triage und Berichtsentwurf über einer Anbieter-Engine. Prüfen Sie DORA (Register der IKT-Drittanbieter, Ausstiegspläne) und dass personenbezogene Daten sowie für das Verbot der Informationsweitergabe (Tipping-off) sensible Falldaten vertraglich abgedeckt sind. Falldaten zu vermuteten Straftaten sind hochsensibel; viele Institute halten SAR-Inhalte von öffentlichen LLM-APIs fern.

Weg C — Selbst betreiben (Open Source)

• Erkennung: Apache Kafka/Flink für Datenströme, scikit-learn, XGBoost, LightGBM, PyOD für Ausreißer, PyTorch Geometric / DGL für Graphmodelle, NetworkX oder Neo4j Community für die Netzwerkanalyse. Es gibt quelloffene Entscheidungs- und Überwachungs-Engines (z. B. Marble, Jube); prüfen Sie jedoch Reife, Support und regulatorische Eignung, bevor Sie sich als primäre Kontrolle darauf stützen.
• LLMs On-Premises: Open-Weight-Modelle (Mistral-Familie, Qwen3, Llama, gpt-oss), bereitgestellt mit vLLM für Fallzusammenfassungen; VLM oder OCR/Dokumenten-Parsing für KYC-Dokumente (siehe DOC-014).
• Hardware: HW2 genügt für Boosted Trees, Graph-Merkmale und ein quantisiertes LLM mit ca. 30 Mrd. Parametern für Berichtsentwürfe; schweres GNN-Training auf großen Graphen braucht HW3. Der Betriebsaufwand ist hoch: Modell-Governance, 24/7-Datenpipelines und Nachvollziehbarkeit dominieren, nicht GPUs.

Weg D — Eigenes Training

Lohnt sich für große Institute oder für Konsortien: bankspezifische überwachte Modelle auf Untersuchungsergebnissen trainieren, GNNs auf dem gesamten Zahlungsgraphen und ein kleines LLM auf den hauseigenen Berichtsstil feintunen. Benötigte Daten: mehrere Jahre an Warnmeldungen mit endgültiger Bearbeitung, SAR-Ergebnissen und Anreicherungsdaten. Datenschutzfreundliche Zusammenarbeit (Federated Learning, datenschutzfördernde Technologien, beaufsichtigte Datenaustausch-Partnerschaften zwischen Banken) ist ein aktives Feld; die rechtliche Zulässigkeit nach DSGVO und Bankgeheimnis ist je Projekt zu klären. Öffentliche Benchmarks (synthetische AMLworld-/IBM-Datensätze [3]) taugen nur für den Methodenvergleich, nicht als Ersatz für die eigene Leistung.

Stand der Technik (2026)

• Mehrschichtige Erkennung (Regeln + überwachtes ML + Graph + Anomalie) ist der Branchenstandard; Aufsichtsbehörden in der EU und anderswo akzeptieren ML, wenn es validiert, erklärbar und gesteuert ist, erwarten aber, dass die regelbasierte Abdeckung vorgeschriebener Szenarien bestehen bleibt.
• Netzwerk- und Graphanalyse sind die Hauptquelle für neuen Erkennungsnutzen, besonders bei Mule-Netzwerken und Verschleierung; die Qualität der Entitätsauflösung ist oft der eigentliche Engpass.
• Agentische Bearbeitung von Warnmeldungen: LLM-Agenten sammeln Kontext (KYC, Transaktionshistorie, negative Medienberichte), erklären ihre Überlegungen und schlagen Bearbeitungen der Stufe 1 vor; Anbieter stellen das als Weg dar, Analystenzeit zu senken. Behandeln Sie die Angaben als vom Anbieter berichtet, bis sie sich in Ihrem Backtest bestätigen, und behalten Sie die menschliche Freigabe bei.
• Synthetische Daten und Benchmarks: Der AMLworld-Generator [3] hat dem Fachgebiet vergleichbare Datensätze mit vollständigen Labels geliefert; reale Daten bleiben für die offene Forschung unzugänglich.
• Grenzen und Fehlerbilder: Label-Verzerrung durch regelgetriebene Alarmierung; Konzeptdrift, wenn Kriminelle sich anpassen; nicht erklärbare Scores, die Aufsichtsbehörden ablehnen; Fehler bei der Entitätsauflösung, die falsche Verbindungen zu unbeteiligten Dritten erzeugen; LLM-Halluzinationen in Berichtstexten (erfundene Transaktionen); und das Risiko der Informationsweitergabe (Tipping-off), wenn kundennahe Systeme den Verdacht offenbaren.

Gemeinsame Bausteine & Kombinationen

• Gleiche Bausteine (tabular-ml, graph-ml, anomaly-detection, streaming): ANOM-001 (Karten-/Zahlungsbetrug, nahezu identische Merkmals-Pipeline), ANOM-022 (APP-Betrug und Geldkuriere/Mules), ANOM-023 (Krypto-Überwachung), ANOM-012 (Handelsüberwachung) und ANOM-006 (Hauptbuch-Anomalien). Ein Feature Store und eine Graphdatenbank können alle bedienen.
• Vorgelagert: ANOM-016 (Screening auf Sanktionen/PEP/negative Medienberichte erzeugt Risikosignale und Warnmeldungen), ANOM-014 (Identitätsprüfung beim Onboarding), ANOM-017 (gefälschte Gehaltsabrechnungen und Kontoauszüge), DOC-017 (Auswertung von Kontoauszügen) und DOC-014 (Dokumenten-Parsing für KYC-Akten).
• Gemeinsamer LLM-Server: Das Modell für Berichtsentwürfe kann dasselbe On-Premises-LLM (HW2/HW3) sein, das für andere Compliance-Copiloten genutzt wird.
• Workflow-Engine und Fallbearbeitung: gemeinsam mit anderen Untersuchungswarteschlangen (Betrug, Sanktionen).

Aufwand, Kosten & Kennzahlen

• Weg A: 6–18 Monate für eine bankentaugliche Einführung, einschließlich Datenmigration, Szenario-Feinabstimmung und aufsichtsrechtlicher Validierung; die Lizenz skaliert typischerweise mit dem Transaktions- oder Kontenvolumen.
• Weg B: 4–12 Monate für eine Ergänzungsschicht (Triage + Copilot für Berichtstexte); Kostentreiber sind Datenengineering, Integration und Modell-Governance, nicht API-Gebühren.
• Weg C/D: ein mehrjähriges Programm mit eigenem Team für Data Science und Modellrisiko.
• Kennzahlen: Trefferquote der Warnmeldungen (Umwandlungsquote von Warnmeldung zu SAR), Fehlalarmrate bei fester Recall (rückgetestet), mittlere Zeit bis zur Bearbeitung, Alter des Rückstaus, Rechtzeitigkeit der SARs, Anteil der SARs mit nützlicher Rückmeldung der FIU, Übersteuerungsquote der Analysten bei Modellvorschlägen, Kennzahlen zu Modelldrift und Stabilität, Fairness-Prüfungen über Kundengruppen.

Menschen & Veränderung

Binden Sie von Anfang an die Geschäftsleitung (verantwortlich für das Geldwäsche-Regelwerk), die/den Geldwäschebeauftragte(n) und Compliance als Prozessverantwortliche, IT und IT-Sicherheit, die/den Datenschutzbeauftragte(n) und die Analysten ein, die die Warnmeldungen bearbeiten; ihre Rückmeldungen als Labels entscheiden über die Modellqualität. Informieren Sie die aufsichtsnahen Funktionen früh, denn Modelländerungen müssen dokumentiert werden.

Betriebsrat: in der Praxis ja. Warteschlangen für Warnmeldungen, Fallwerkzeuge und Leistungsberichte über Analysten sind technische Einrichtungen, die zur Verhaltensüberwachung geeignet sind (§ 87 Abs. 1 Nr. 6 BetrVG), und § 90 Abs. 1 Nr. 3 sowie § 80 Abs. 3 (externer Sachverständiger) kommen zum Tragen; in öffentlichen Stellen ist der Personalrat nach BPersVG oder Landesrecht beteiligt.

Datenschutz: Umfangreiches Profiling von Kunden macht eine DSFA wahrscheinlich (Art. 35 DSGVO); gesetzliche Geldwäschepflichten liefern die Rechtsgrundlage, doch Aufbewahrungs- und Zweckbindungsgrenzen gelten weiterhin; AVV mit jedem Anbieter. KI-Kompetenz: Unterstützen Sie Analysten beim Lesen von Modellerklärungen und -grenzen (Art. 4 KI-Verordnung). Pilotieren Sie parallel zu den bestehenden Regeln, vergleichen Sie Trefferquoten und Fehlalarme und stellen Sie dann Szenario für Szenario um. Typische Sorgen: „Ersetzt das Modell mein Urteil?“ und die aufsichtsrechtliche Verantwortung; begegnen Sie ihnen, indem Menschen die Meldeentscheidung behalten und jede Übersteuerung dokumentiert wird. Siehe GUIDE-004, GUIDE-005 und GUIDE-011.

Risiken, Regulierung & Compliance

• Geldwäscherecht: EU-Geldwäscheverordnung (AMLR) (EU) 2024/1624 (gilt ab dem 10. Juli 2027), das AMLD-Regelwerk sowie das deutsche Geldwäschegesetz (GwG) mit BaFin-Auslegungshinweisen und FIU-Meldung über goAML [1][4]. Die FATF-Empfehlungen setzen den globalen Standard. Zu den Pflichten gehören risikobasierte laufende Überwachung, Aufzeichnungspflichten und rechtzeitige Verdachtsmeldung; die Informationsweitergabe an Betroffene (Tipping-off) ist verboten.
• KI-Verordnung (AI Act): Die Einstufung hängt vom Einzelfall ab. Anhang III Nr. 5 Buchst. b stuft KI zur Bewertung der Kreditwürdigkeit oder zum Kredit-Scoring natürlicher Personen als Hochrisiko ein, nimmt aber ausdrücklich KI-Systeme aus, die zur Aufdeckung von Finanzbetrug verwendet werden [5]. Reine Transaktionsüberwachung zur Geldwäschebekämpfung ist in der Regel nicht als Hochrisiko aufgeführt, doch die Grenze ist nicht scharf: Ein AML-System, dessen Scores in Entscheidungen über Kredit, Kontoeröffnung oder Kontoschließung bei Einzelpersonen einfließen, oder jede Nutzung durch Strafverfolgung oder eine FIU beim Profiling von Einzelpersonen kann unter Anhang III fallen (Kredit-Scoring, wesentliche Dienste, Strafverfolgung). Individuelle Risikobewertungen natürlicher Personen, die ausschließlich auf Profiling beruhen, um Straftaten vorherzusagen, sind nach Art. 5 Abs. 1 Buchst. d verboten; ein Überwachungssystem muss die menschliche Beurteilung objektiver, überprüfbarer Tatsachen daher unterstützen, nicht ersetzen. Holen Sie die rechtliche Einstufung je Einsatz ein.
• DSGVO: Die Verarbeitung beruht auf rechtlicher Verpflichtung (Art. 6 Abs. 1 Buchst. c), doch Profiling und automatisierte Entscheidungen erfordern Sorgfalt (Art. 22: Kontokündigung oder -sperrung dürfen nicht allein auf automatisierter Bewertung beruhen); erforderlich sind eine Datenschutz-Folgenabschätzung, Datenminimierung, Löschfristen und strenge Zugriffskontrolle auf Falldaten.
• Branchenregeln: DORA (IKT-Risiko und Drittanbieter), EBA-Leitlinien zu ML und Auslagerung, Erwartungen der BaFin an das Modellrisiko (MaRisk), aufsichtliche Standards zur Modellvalidierung, Bedenken zu De-Risking und finanziellem Ausschluss (EBA).
• Typische Risiken und Gegenmaßnahmen: diskriminierende Stellvertretermerkmale (Nationalität, Postleitzahl) → Fairness-Tests; übermäßiges Vertrauen in LLM-Entwürfe → verpflichtende Quellenangabe und Prüfung durch Analysten; Modelldrift → Überwachung und regelmäßige Neuvalidierung; Abhängigkeit vom Anbieter → exportierbare Regeln und Daten.
• Hinweis zu sensiblen Themen: Diese Seite beschreibt ausschließlich defensive Compliance-Überwachung. Sie gibt keine Anleitung, wie man der Erkennung ausweicht.

Erste Schritte

1. Aktuelle Szenarien, Mengen an Warnmeldungen, Schließungsquoten und SAR-Umwandlung je Szenario erfassen; eine messbare Ausgangslage festlegen.
2. Das Datenfundament aufbauen: einheitliche Kunden- und Gegenpartei-Entitäten sowie eine saubere Historie der Ergebnisse von Warnmeldungen als Labels.
3. Einen Backtest (Below-the-Line) einer ML-Priorisierungsschicht mit den eigenen historischen Warnmeldungen durchführen, bevor Schwellenwerte im Produktivbetrieb geändert werden.
4. Einen Assistenten für Fallzusammenfassung und Berichtsentwurf für Analysten der Stufe 1 pilotieren – mit Verweis auf die zugrunde liegenden Transaktionen und verpflichtender menschlicher Freigabe.
5. Die Modell-Governance jetzt aufsetzen (Dokumentation, Validierung, Erklärbarkeit, DSFA, Einstufung nach KI-Verordnung), damit sie trägt, wenn die AMLR im Juli 2027 gilt.

Quellen

1. EU Anti-Money Laundering Regulation (EU) 2024/1624 (EUR-Lex) — https://eur-lex.europa.eu/eli/reg/2024/1624/oj
2. AMLA, Authority for Anti-Money Laundering and Countering the Financing of Terrorism — About AMLA (timeline: direct supervision from 2028) — https://www.amla.europa.eu/about-amla_en
3. Altman et al., "Realistic Synthetic Financial Transactions for Anti-Money Laundering Models" (AMLworld) — https://arxiv.org/abs/2306.16424
4. Geldwäschegesetz (GwG) — https://www.gesetze-im-internet.de/gwg_2017/
5. AI Act Annex III (high-risk systems; point 5(b) fraud-detection exclusion) — https://artificialintelligenceact.eu/annex/3/
6. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj