Banken · Eine Build-Buy-Partner-Entscheidung für eine zentrale KI-Fähigkeit treffen

Eine mittelgroße US-Bank (rund 30 Milliarden Dollar Bilanzsumme) steht unter Zeitdruck. Ihr System zum AML-Transaktionsmonitoring (AML, Anti-Money Laundering, das regulatorische Regime, das Banken zur Erkennung und Meldung verdächtiger Finanzaktivitäten verpflichtet) ist neun Jahre alt, produziert false positives in einem Ausmaß, das die Compliance-Mitarbeiter als „nicht mehr handhabbar" bezeichnen, und eine kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →ürzliche Aufsichtsprüfung hat Lücken in der Modelldokumentation beanstandet. Der CIO hat drei Optionen auf dem Tisch: ein neues System intern mit dem Data-Science-Team bauen, eine Vendor-Plattform kaufen oder gemeinsam mit einem Fintech-Partner entwickeln. Der Vorstand will in sechs Wochen eine Empfehlung. Genau diese Entscheidung können Sie nach dieser Lektion führen.

Warum diese Entscheidung schwieriger ist, als sie aussieht

AML-Transaktionsmonitoring nutzt AI/ML (machine learning), um Transaktionen auf verdächtige Aktivität zu scoren, und ersetzt oder ergänzt statische Regeln („jede Überweisung über 10.000 Dollar flaggen") durch Mustererkennung, die sich an neue Geldwäschetechniken anpasst.

Das Risiko läuft in beide Richtungen. Erkennen Sie zu wenig, drohen Sanktionen nach dem Bank Secrecy Act (BSA, dem zentralen US-Geldwäschegesetz) und MaMaEinsatz von Software, um wiederkehrende Marketingaufgaben und Kampagnen zu automatisieren und Personalisierung in großem Maßstab über Kanäle wie E-Mail, Web und Social zu ermöglichen.Vollständige Definition ansehen →ßnahmen von FinCEN (Financial Crimes Enforcement Network) oder, in Europa, von nationalen Aufsichtsbehörden, die die EU-Geldwäscherichtlinien anwenden. Erkennen Sie zu viel, ertrinken Ihre Ermittler in false positives, Branchenschätzungen nennen häufig false-positive-Raten über 90% für regelbasierte Altsysteme, eine Näherung, die man als Richtungsangabe und nicht als exakten Wert behandeln sollte.

Dies ist keine generische „KI-Einführungs"-Entscheidung. Es geht um ein System innerhalb einer stark geprüften Compliance-Funktion mit hoher Haftung. Das verändert die Rechnung gegenüber, sagen wir, der Einführung eines KI-Tools für Marketingtexte.

Die drei Wege, ehrlich bewertet

Intern bauen

Sie behalten die volle Kontrolle über das Modell, die Data PipelineData PipelineETL (Extract, Transform, Load) ist ein Datenintegrationsprozess, der Daten aus Quellsystemen extrahiert, in ein konsistentes Format bringt und in ein Zielsystem schreibt.Vollständige Definition ansehen → und die Logik, was zählt, wenn die Aufsicht fragt: „Warum hat das Modell diese Transaktion geflaggt?" (eine Anforderung, die häufig als Modell-Explainability bezeichnet wird).

Die Kosten sind real und laufend: Data Scientists, ML-Engineers, MLOpsMLOpsMachine Learning Operations: die Verbindung von ML- und DevOps-Praktiken, um Modelle zu industrialisieren, auszurollen, zu überwachen und in der Produktion zuverlässig neu zu trainieren.Vollständige Definition ansehen →-Infrastruktur und, entscheidend, das Compliance- und Validierungspersonal, das das Modell nach aufsichtlichen Vorgaben wie der SR 11-7 der Federal Reserve zum Model Risk Management dokumentieren muss. Die meisten mittelgroßen Banken unterschätzen diesen zweiten Kostenblock.

Build ergibt Sinn, wenn Sie über ein differenzierendes Data Asset verfügen (eine wirklich ungewöhnliche Kundenbasis oder Transaktionsstruktur) oder wenn Standardmodelle in Ihrem Segment schlecht abschneiden. Als erster Schritt für eine mittelgroße Bank mit schlanker Data-Science-Mannschaft ergibt es selten Sinn.

Eine Plattform kaufen

Anbieter wie NICE Actimize, Oracle Financial Services, SAS und Feedzai verkaufen AML-Plattformen mit vortrainierten Erkennungsmodellen, Case-Management-Workflows und, besonders wichtig, vorgefertigtem Regulatory Reporting.

Der Vorteil ist Geschwindigkeit bis zur Compliance und eine geteilte Last bei der Modellvalidierung, da diese Anbieter bereits mehrere Bankenprüfungen durchlaufen haben. Der Nachteil ist die Passung: ein Vendor-Modell, das über Hunderte Institute hinweg trainiert wurde, erkennt womöglich keine Muster, die für Ihre Kundenbasis spezifisch sind (eine Bank mit starkem Trade-Finance- oder Korrespondenzbankgeschäft hat andere Risikomuster als eine retaillastige Bank).

Buy bedeutet außerdem Vendor-Lock-in-Risiko und weniger Transparenz über das Modellinnere, was das Erklären von Entscheidungen gegenüber Prüfern erschweren kann. Sie sind compliant, aber abhängig.

Partnerschaft oder Co-Development mit einem Fintech

Dieser hybride Weg (die Bank liefert Daten und Compliance-Expertise, ein Fintech liefert ML-Engineering und eine leichtgewichtigere Plattform) wird zunehmend üblich für Fähigkeiten wie Alert-Triage und Transaction Scoring, wo Firmen wie Hawk AI oder ThetaRay tätig sind.

Eine Partnerschaft kann fachliche Passung mit schnellerer Iteration als beim Build und mehr Anpassbarkeit als beim Buy verbinden. Der Haken: Governance. Wem gehört die Modelldokumentation, wenn die Aufsicht fragt? Wer haftet, wenn das Modell einen Sanktionstreffer übersieht? Das muss vertraglich geregelt und nicht unterstellt werden.

Ein wiederholbares Scoring-Framework

Bewerten Sie jede Option von 1 bis 5 in diesen Dimensionen, gewichtet nach dem, was für Ihr Institut am wichtigsten ist:

Für den AML-Fall: Wenn die Prüfungsfeststellung auf Dokumentationslücken zielte, sollten regulatorische Verteidigbarkeit und Explainability das größte Gewicht tragen, was oft in Richtung Buy oder Partner zeigt, wo Anbieter prüfungserprobte Dokumentation mitbringen, statt in Richtung Build, wo die Bank diese Last von Grund auf übernimmt.

Eine durchgerechnete Mini-Kalkulation

Nehmen wir an, das aktuelle System der Bank erzeugt 100.000 Alerts pro Jahr bei einer false-positive-Rate von 90% (eine branchenübliche Schätzung, als Näherung zu behandeln), und jeder Alert kostet einen Analysten 20 Minuten Prüfzeit.

• Aktuelle Analystenstunden: 100.000 × 20 Minuten = 33.333 Stunden/Jahr
• Bei vollbelasteten Kosten eines Compliance-Analysten von rund 60 Dollar/Stunde (eine plausible US-Schätzung für 2026, nicht anbieterspezifisch) sind das etwa 2 Millionen Dollar/Jahr allein an Prüfarbeit.

Wenn ein neues KI-gestütztes System (build, buy oder partner) die false positives auf 70% senkt und dabei dieselben true positives erkennt, sinkt das zu prüfende Alert-Volumen proportional: grob 100.000 → etwa 70.000 relevante Alerts, was knapp 10.000 Analystenstunden spart, also rund 600.000 Dollar/Jahr.

Stellen Sie diese Einsparung den Kosten jedes Wegs über einen Horizont von 3 Jahren gegenüber (Lizenzgebühren liegen für mittelgroße Banken typischerweise jährlich im hohen sechs- bis niedrigen siebenstelligen Bereich, Build-Kosten konzentrieren sich vorab auf Talente und Infrastruktur, Partnerkosten sind meist eine Mischform). Der ROI-Case (Return on Investment) funktioniert nur, wenn Sie den Rattenschwanz aus Compliance und Validierung mitmodellieren, nicht nur die Lizenz- oder Entwicklungskosten, ein Fehler, den viele Banken machen, wenn der Business Case auf dem Slide-Deck eines Anbieters gut aussieht, aber den internen Umsetzungsaufwand ignoriert.

Worauf Prüfer tatsächlich achten

Welchen Weg Sie auch wählen: US- und EU-Aufsichtsbehörden nähern sich ähnlichen Erwartungen an: nachweisbare Model Governance, nicht unbedingt eine bestimmte Vendor- oder Build-Entscheidung.

Das SR-11-7-Framework der Fed (auch 2026 noch der Referenzstandard) verlangt unabhängige Validierung, laufendes Monitoring und eine klare Dokumentation der Modellgrenzen. Der sich entwickelnde EU AI Act legt zusätzliche Pflichten für „hochriskante" KI-Systeme fest, und AML-Transaktionsmonitoring gerät angesichts seiner Auswirkungen auf den Finanzzugang von Personen plausibel in den Fokus, wobei Banken die finalen Leitlinien der European Banking Authority verfolgen sollten, statt eine Einstufung zu unterstellen.

Praktisch gesehen: Eine „Buy"-Entscheidung lagert die regulatorische Verantwortung nicht aus. Die Bank bleibt verantwortlich, auch wenn der Anbieter das Modell gebaut hat. Das ist das mit Abstand häufigste Missverständnis bei Build-Buy-Partner-Entscheidungen in der Banken-KI, nicht nur bei AML.

🎬 [VIDEO: "How Banks Use AI to Fight Money Laundering" - youtube.com/results?search_query=how+banks+use+ai+to+fight+money+laundering - suchen Sie nach aktuellen Erklärinhalten von Banking-Technology-Kanälen zu AML-Transaktionsmonitoring und KI, nützlich für einen visuellen Durchgang durch Alert Scoring und Case-Management-Workflows]

Anwendung auf die Entscheidung der Bank

Da die Prüfungsfeststellung die Dokumentation betraf und nicht die Erkennungsgenauigkeit, ist der stärkste erste Schritt wahrscheinlich Buy oder Partner, nicht Build. Eine Vendor-Plattform bringt prüfungserprobte Dokumentation ab Werk mit; eine Fintech-Partnerschaft lässt sich später für segmentspezifisches Tuning ergänzen, sobald die grundlegende Compliance-Lücke geschlossen ist.

Build bleibt die langfristige Option, falls die Bank nach zwei oder drei Jahren mit einer Vendor- oder Partnerlösung einen wirklich differenzierten Erkennungsbedarf identifiziert, den der Markt nicht bedient, denn dann hat sie sowohl die Daten als auch die interne Erfahrung, um glaubwürdig zu bauen.

Key Takeaways

• Build-Buy-Partner-Entscheidungen in der Banken-KI müssen regulatorische Verteidigbarkeit und Explainability genauso stark gewichten wie Kosten oder Geschwindigkeit, besonders bei compliance-kritischen Systemen wie AML-Monitoring.
• Der Kauf einer Vendor-Plattform überträgt die regulatorische Verantwortung nicht; die Bank haftet weiterhin für Ergebnisse unter Frameworks wie SR 11-7.
• Modellieren Sie bei der ROIROIReturn on Investment: das Verhältnis von Nettogewinn zu den Kosten einer Investition. Ein ROI von 300 % bedeutet, dass jeder investierte Dollar 3 Dollar zurückbringt.Vollständige Definition ansehen →-Rechnung immer den vollständigen Kostenschwanz (Validierung, Dokumentation, Wartung), nicht nur Lizenz- oder Baupreis.
• Partnerschaften funktionieren am besten, wenn Governance und Haftung vorab vertraglich definiert und nicht unterstellt werden.
• Nutzen Sie ein gewichtetes Scoring-Framework (regulatorische Passung, Datenpassung, Time to Compliance, TCO, Talent, Explainability), um die Entscheidung strukturiert zu halten statt vom Vendor-Pitch treiben zu lassen.