Banken · KI-Anbieterversprechen prüfen, bevor Sie kaufen

Ein Anbieter für Fraud Detection sagt Ihrem Risikokomitee: „Unser Modell senkt False Positives um 40 %.“ Die Folie zeigt ein aufgeräumtes Balkendiagramm. Der Vertriebler hat eine Logowand mit Case Studies. Niemand im Raum fragt: 40 % im Vergleich zu was, wie gemessen, auf wessen Daten?

Sechs Monate später versinkt Ihr Fraud-Ops-Team in einer Queue, die nichts mit dem Pitch zu tun hat. Diese Lektion gibt Ihnen die Checkliste, um das zu verhindern, bevor ein Pilot überhaupt Produktionsdaten anfasst.

Warum die Aussage „40 % weniger False Positives“ allein fast nichts bedeutet

Ein False Positive (eine legitime Transaktion, die fälschlich als Betrug markiert wird) hat echte Kosten: verärgerte Kunden, abgebrochene Transaktionen, Volumen im Callcenter. Anbieter wissen, dass die Reduktion von False Positives einer der größten Schmerzpunkte ist, deshalb ist es die Headline-Metrik der Wahl.

Aber „40 % weniger“ ist eine Verhältniszahl, keine Tatsache. Sie brauchen den Nenner. Fragen Sie:

• 40 % gegenüber welcher Baseline? Dem eigenen schwächeren Modell? Ihrem aktuellen internen System? Einem Branchendurchschnitt als Benchmark, der Ihrem Portfolio vielleicht gar nicht gleicht?
• Auf welcher Population? Ein Datensatz mit 50.000 Transaktionen einer mittelgroßen US-Regionalbank oder Millionen über mehrere Issuer und Länder hinweg?
• Bei welcher Betrugserkennungsrate? False Positives lassen sich immer senken, indem man den Threshold lockert, zum Preis, dass mehr echter Betrug durchgeht. Eine verantwortungsvolle Aussage nennt False-Positive-Rate und True-Positive-Rate (erkannter Betrug) gemeinsam, idealerweise als vollständige Precision-Recall- oder ROC-Kurve, nicht als einzelnen Punkt.

Wenn der Anbieter die Confusion Matrix (die 2x2-Tabelle aus True/False Positives und Negatives) hinter der Headline-Zahl nicht vorlegen kann, behandeln Sie die Aussage als Marketing, nicht als Evidenz.

Die fünf Dinge, die Sie vor einem Piloten einfordern müssen

1. Die Beschreibung des Benchmark-Datensatzes

Fordern Sie ein Data Sheet mit: Zeitraum, Geografie, Transaktionstypen (card-present vs. card-not-present, Wire, ACH), Definition des Fraud-Labels und Class Balance (welcher Prozentsatz des Datensatzes war tatsächlich betrügerisch). Betrug ist selten, oft deutlich unter 1 % der Transaktionen, deshalb wird ein Modell, das auf einem künstlich balancierten 50/50-Datensatz getestet wurde, weit besser aussehen als es live abliefert.

2. Die exakten Metrikdefinitionen

„Accuracy“ ist für die Erkennung seltener Ereignisse wie Betrug oder Geldwäsche (AML, das regulatorische Regime, das Banken zur Erkennung und Meldung verdächtiger Finanzaktivitäten verpflichtet) fast nutzlos, denn ein Modell, das immer „kein Betrug“ vorhersagt, kann zu über 99 % „accurate“ sein und dabei null Betrug erkennen. Bestehen Sie auf:

• Precision (welcher Prozentsatz der markierten Fälle war wirklich Betrug)
• Recall / True-Positive-Rate (welcher Prozentsatz des tatsächlichen Betrugs wurde erkannt)
• False-Positive-Rate bei einem angegebenen Operating Threshold

3. Testbedingungen und Prüfung auf Data Leakage

Fragen Sie ausdrücklich: War das Test-Set zeitlich vollständig vom Trainings-Set getrennt (Out-of-Time-Validierung) oder nur ein Random Split? Random Splits auf Transaktionsdaten 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 →önnen Informationen leaken (spätere Transaktionen eines Kunden beeinflussen Vorhersagen über seine früheren) und die Ergebnisse künstlich aufblähen. Out-of-Time-Testing, also Training auf 2023er Daten und Test auf 2024er Daten, ist der realistische Standard.

4. Performance auf Daten, die Ihren gleichen

Ein Modell, das auf Kartendaten einer Großbank benchmarkt wurde, kann beim kleineren, anders zusammengesetzten Transaktionsmix einer Regionalbank stark abbauen, oder bei grenzüberschreitenden Wires, wenn es überwiegend auf inländischem ACH trainiert wurde. Fordern Sie einen Champion-Challenger-Piloten: Lassen Sie das Anbietermodell im Shadow Mode laufen (Scoring von Live-Transaktionen, ohne darauf zu handeln) gegen Ihr bestehendes System, über einen definierten Zeitraum, und vergleichen Sie dann die Ergebnisse auf Ihrer echten Population.

5. Offenlegung von Drift und Retraining-Kadenz

Betrugsmuster verschieben sich ständig, normales Kundenverhalten ebenso. Fragen Sie, wie oft das Modell neu trainiert wird, was ein Retraining auslöst und was mit der Performance zwischen den Retraining-Zyklen passiert (das nennt man Model Drift oder Performance Decay). Ein Anbieter ohne Antwort auf „Wie monitoren Sie Drift?“ verlangt von Ihnen, eine Momentaufnahme zu kaufen, kein System.

Ein einfaches Rechenbeispiel: warum Base Rates zählen

Nehmen wir an, Ihre Betrugsrate liegt realistisch bei 0,3 % der Transaktionen (eine plausible Größenordnung für Kartentransaktionen; die tatsächlichen Raten variieren je Issuer und Kanal). Bei 1.000.000 Transaktionen sind das etwa 3.000 betrügerische.

Anbieter verspricht: 90 % Recall (erkennt 90 % des Betrugs) und eine False-Positive-Rate von 2 %.

• Erkannte True Positives: 90 % x 3.000 = 2.700
• False Positives: 2 % x 997.000 (Nicht-Betrugstransaktionen) ≈ 19.940

Ihr Fraud-Team prüft also rund 22.640 markierte Transaktionen, um 2.700 echte Betrugsfälle zu finden. Das ist eine Precision von etwa 12 %. Die Aussage des Anbieters „40 % weniger False Positives als unser altes Modell“ kann stimmen und Ihnen trotzdem eine unbearbeitbare Review-Queue hinterlassen, weil die Base Rate von Betrug so niedrig ist, dass selbst kleine False-Positive-Prozentsätze riesige absolute Volumina erzeugen.

Das ist das Base-Rate-Problem, und es ist der häufigste einzelne Grund, warum Anbieterpiloten in der Produktion enttäuschen. Rechnen Sie Prozentaussagen immer in absolute Zahlen gegen Ihr tatsächliches Transaktionsvolumen um, bevor Sie etwas unterschreiben.

Regulatorik und Governance

In den USA setzt die SR 11-7 Guidance der Federal Reserve zum Model Risk Management die aufsichtsrechtliche Erwartung, dass Banken jedes Modell vor dem Einsatz unabhängig validieren, auch von Anbietern geliefertes, und es laufend monitoren. Sie können die Verantwortung für die Validierung nicht an den Benchmark-Report des Anbieters auslagern.

In der EU klassifiziert der AI Act (in Kraft seit 2024, mit gestuften Compliance-Pflichten bis 2026 und darüber hinaus) die meisten von Banken eingesetzten Systeme zur Kreditwürdigkeits- und Betrugsbewertung als „Hochrisiko-KI-Systeme“, was Anforderungen an Dokumentation, menschliche Aufsicht und Genauigkeits-/Robustheitstests auslöst, die Prüfer einsehen können. Europäische Banken sollten jedes Anbieterversprechen im Rahmen der Beschaffung direkt auf diese Dokumentationsanforderungen abbilden, nicht danach.

In beiden Fällen zeigen die regulatorische Erwartung und die kommerzielle Due Diligence in dieselbe Richtung: Unabhängige Validierung auf Ihren eigenen Daten, nicht Marketingmaterial des Anbieters, ist der Beweisstandard.

Die Scorecard für die Anbieterbewertung aufbauen

Eine praktische Beschaffungs-Checkliste für KI-Anbieterversprechen im Banking sollte jeden Anbieter nach folgenden Punkten bewerten:

1. Transparenz der Methodik: Legen sie die Confusion Matrix offen, nicht nur die Headline-Ratio?
2. Datenrelevanz: Wurde der Benchmark auf Daten gebaut, die Ihrem Portfolio gleichen (Geografie, Kanal, Kundensegment)?
3. Verfügbarkeit eines Shadow-Mode-Piloten: Führen sie vor Go-live ein Live-Scoring ohne Produktionswirkung auf Ihren Daten durch?
4. Explainability: Lassen sich die markierten Entscheidungen des Modells einem Kunden oder Prüfer erklären (relevant unter Fair-Lending-Gesetzen wie dem US Equal Credit Opportunity Act und unter den Vorschriften der DSGVODSGVOEU-Verordnung zur Erhebung, Speicherung und Nutzung personenbezogener Daten, mit Bußgeldern, die am weltweiten Umsatz bemessen werden.Vollständige Definition ansehen → zu automatisierten Entscheidungen in der EU)?
5. Drift-Monitoring und Retraining-SLA: Was ist vertraglich für die laufende Performance garantiert, nicht nur für den Launch-Tag?

Ein einfaches Snippet, um das intern während der Anbieterbewertung zu verfolgen:

# minimal vendor claim sanity-check
fraud_rate = 0.003          # Schätzung: an Ihr tatsächliches Portfolio anpassen
total_txns = 1_000_000
recall = 0.90                # vom Anbieter angegebene True-Positive-Rate
fpr = 0.02                   # vom Anbieter angegebene False-Positive-Rate

fraud_txns = total_txns * fraud_rate
non_fraud_txns = total_txns - fraud_txns

true_positives = fraud_txns * recall
false_positives = non_fraud_txns * fpr

precision = true_positives / (true_positives + false_positives)
print(f"Flagged for review: {true_positives + false_positives:,.0f}")
print(f"Precision: {precision:.1%}")

Rechnen Sie das mit den tatsächlich zugesagten Zahlen des Anbieters und Ihrem echten Transaktionsvolumen durch, bevor überhaupt über einen Vertrag gesprochen wird.

🎬 [VIDEO: „Model Risk Management Explained“ - https://www.youtube.com/results?search_query=model+risk+management+banking+explained - Suchergebnisse für verständliche Erklärvideos zu Modellvalidierung und Governance-Frameworks wie SR 11-7, nützlicher Hintergrund vor Meetings zur Anbieterbewertung]

Key Takeaways

• Akzeptieren Sie niemals eine Ein-Zahl-Aussage („40 % weniger False Positives“) ohne Baseline, Beschreibung des Datensatzes und die vollständige Confusion Matrix dahinter.
• Rechnen Sie jede Prozentaussage in absolute Zahlen gegen Ihr echtes Transaktionsvolumen um; niedrige Base Rates (etwa Betrug bei deutlich unter 1 %) machen kleine Prozentunterschiede in der Praxis riesig.
• Fordern Sie Out-of-Time-Testing und einen Shadow-Mode-Piloten auf Ihren eigenen Daten, bevor eine Produktionsentscheidung fällt.
• Regulatorische Rahmenwerke (Fed SR 11-7 in den USA, die Hochrisiko-Kategorie des EU AI Act) verlangen unabhängige Validierung, kein Self-Reporting des Anbieters, planen Sie diese Validierung also ab Tag eins in den Beschaffungszeitplan ein.
• Bewerten Sie Anbieter nach Transparenz, Datenrelevanz, Explainability und Drift-Monitoring, nicht nur nach der Headline-Metrik des Pitches.