Financial Data Science Teil 0: 7 Dinge, die Financial Data Science von allgemeinem ML unterscheiden

Ich beginne die Reihe „Grundlagen der Financial Data Science“. Dieser Artikel ist der erste Teil (Teil 0). Ab Teil 0 möchte ich der Reihe nach wie in einem Buch erklären, warum Data Science im Kreditprüfungsalltag anders funktioniert als allgemeines ML. Themen sind unter anderem Reject Inference, kausale Inferenz, Kalibrierung, Validierung, Fairness und Regulierung.
Das Original habe ich zuerst in meinem Blog veröffentlicht → https://han-co.com/ko/blog/part0-finance-ds-7-differences

Ich bin kein Veteran, der seit Jahrzehnten in diesem Bereich arbeitet. Ich habe als Ingenieur in der Fertigungsindustrie gearbeitet, bin dann in die Finanzbranche gewechselt und arbeite heute als Data Scientist im Bereich Kreditprüfung. Deshalb sollte man diesen Text nicht als „Das ist die einzig richtige Antwort“ lesen, sondern eher als eine Zusammenstellung dessen, woran ich in diesem Feld selbst hängen geblieben bin — der Dinge, bei denen ich dachte: „Moment, ich habe es doch nach Lehrbuch gemacht, warum liege ich ständig daneben?“

Interessant ist, dass ich damit nicht allein war. Selbst Menschen, die den kompletten Aufbau und die Bewertung allgemeiner ML-Modelle beherrschen, machen in der Kreditprüfung oft ähnliche Fehler. Die Validierungsmetriken sehen gut aus, aber im echten Einsatz liefert das Modell nicht die erwartete Leistung, die Accuracy liegt bei 99 %, aber niemand freut sich, und wenn man noch 0,01 Performance herausholt, blockiert plötzlich die Risikabteilung den Rollout …

Das liegt weniger an mangelndem Können als daran, dass Finance — insbesondere die Kreditprüfung — nicht einfach „ML auf Finanzdaten anwenden“ ist, sondern ein Feld mit anderen Regeln. Und fast alles, worum es in dieser Reihe gehen wird — also Reject Inference, kausale Inferenz, Kalibrierung, Validierung, Fairness — basiert letztlich auf diesen Regeln.

1. Selection Bias ist der Default

In unseren Trainingsdaten gibt es tatsächlich ein großes Loch: Wir sehen nur die Rückzahlungsergebnisse der genehmigten Kunden. Ob abgelehnte Kunden tatsächlich zurückgezahlt oder einen Ausfall gehabt hätten, können wir nie wissen. Für sie wurde von vornherein keine Karte ausgestellt.

Allgemeines ML geht meist davon aus, dass „die Daten die Grundgesamtheit repräsentieren“. In der Kreditprüfung ist diese Annahme jedoch von Anfang an verletzt. Die Trainingsdaten bestehen aus Kunden, die in der Vergangenheit bereits genehmigt wurden, während das Modell eigentlich über die gesamte Menge der noch nicht genehmigten Antragsteller entscheiden soll. Das sind zwei verschiedene Populationen.

Gesamtheit aller Antragsteller  
├─ Genehmigt (Ergebnis beobachtet)  
│   ├─ Rückzahlung  → ordnungsgemäße Rückzahlung  
│   └─ Ausfall  → Zahlungsverzug·Ausfall  
└─ Abgelehnt (Ergebnis nicht beobachtet)  → ??? unbekannt, ob Rückzahlung oder Ausfall  

Das Modell lernt nur aus „genehmigten Kunden“. Die tatsächlichen Ergebnisse abgelehnter Kunden bleiben nicht in den Daten erhalten.

Dieser eine Punkt verursacht mehr Probleme, als man denkt. Weil es keine Daten über „abgelehnte Kunden“ nach der Ablehnung gibt, kann das Modell den von ihm selbst abgelehnten Bereich nicht lernen und erbt die Verzerrungen früherer Prüfungsrichtlinien unverändert. Deshalb sind in diesem Feld Reject Inference und kausale Inferenz keine Spezialmethoden, sondern Grundlagen. (Beide Themen werde ich später jeweils in einem eigenen Teil vertiefen.)

2. Die Zeit fließt nur in eine Richtung, und Modelle altern

Wenn man die Daten zufällig mischt und K-fold laufen lässt, hat man in Wahrheit ein wenig in die Zukunft geschaut. Denn in den Validierungsdaten sind Vergangenheits- und Zukunftsdaten vermischt.

Kreditdaten verlaufen entlang der Zeit. Ein Modell, das mit Kundendaten aus 2024 trainiert wurde, bewertet Kunden im Jahr 2026. In der Zwischenzeit ändern sich Konjunktur, Zinssätze, Kundenverhalten und Produkte. Die Verteilung verschiebt sich (drift). Zufälliges K-fold mischt Vergangenheit und Zukunft zusammen und schleust damit in die Validierung Informationen ein, die es im realen Einsatz niemals geben würde.

Deshalb ist die Standardvalidierung im Finanzbereich OOT (out-of-time), also eine Bewertung auf einem Zeitraum, der nach dem Trainingszeitraum liegt. Nach dem Deployment muss laufend überwacht werden, wie stark sich die Verteilung bewegt und wie sich Kunden im Zeitverlauf verändern. In dem Moment, in dem ein Modell ausgerollt wird, beginnt es zu altern.

3. „Wer ist riskanter?“ reicht nicht — man braucht „genau wie viel Prozent?“

Bei allgemeinen Klassifikationsproblemen reicht es oft, wenn nur das Ranking stimmt. Es genügt, die Personen nach Risiko korrekt zu ordnen, und AUC misst genau diese Fähigkeit.

Im Kreditbereich kann man dort jedoch nicht stehen bleiben. Man braucht absolute Wahrscheinlichkeiten, also kalibrierte PDs (calibrated PD). Es muss eine Zahl geben wie: „Die Ausfallwahrscheinlichkeit dieses Kunden beträgt genau 3,2 %.“ Nur dann kann man Preise festlegen (risk-based pricing), Rückstellungen bilden (provisioning) und erwartete Verluste berechnen. Mit einem reinen Ranking geht nichts davon.

Deshalb kommt im Kreditbereich erstaunlich oft Folgendes vor: Das AUC ist hervorragend, aber die PD liegt daneben. Trennschärfe (discrimination) und Kalibrierung (calibration) sind zwei unterschiedliche Achsen, und man muss beides im Griff haben. (Ich habe einen eigenen Teil nur zur Kalibrierung vorbereitet. Erstaunlich oft wird genau das übersehen.)

4. Kosten sind asymmetrisch, kommen viel später und werden in Geldbeträgen gemessen

Accuracy behandelt alle Fehler gleich. Im Kreditbereich ist das Gewicht von Fehlern jedoch überhaupt nicht gleich.

Mit einem einzigen guten Kunden verdient man nur die Marge (einige tausend Yen), die Kosten eines Ausfalls betragen dagegen LGD × EAD (mehrere hunderttausend Yen). Eine Seite wiegt also um ein Vielfaches schwerer. Optimieren sollten wir deshalb nicht Accuracy, sondern erwarteten Gewinn und erwarteten Verlust.

Erwarteter Gewinn = (1 − PD) × Marge − PD × LGD × EAD  

Der erwartete Verlust (EL) im Ausfallfall zerfällt wiederum in das Produkt aus drei Komponenten.

EL = PD × LGD × EAD  

• PD: Ausfallwahrscheinlichkeit
• LGD: Verlustquote bei Ausfall
• EAD: Exposure bei Ausfall

Jede dieser drei Komponenten ist ein eigenes Modellierungsproblem. Der Kern des Scorings ist die PD.

Hinzu kommt, dass das richtige Label erst sehr viel später eintrifft. Ob ein heute genehmigter Kunde ausfällt oder nicht, steht oft erst 12 bis 24 Monate später fest. Dass Labels so spät kommen, kollidiert erheblich mit einer ML-Denkweise, die an schnelles Feedback gewöhnt ist. Man muss fortlaufend Entscheidungen aufbauen, obwohl die Ergebnisse noch unbekannt sind.

5. Stabilität schlägt Grenzperformance

In ML-Wettbewerben gilt es als Tugend, noch 0,001 AUC herauszuquetschen — etwa in Wettbewerben wie Kaggle. In produktiven Kreditmodellen ist das jedoch oft ein Nachteil.

Wenn man für einen Tropfen mehr Performance ein instabiles Modell in Kauf nimmt, wird das im Betrieb schnell teuer. Gemeint sind Modelle, deren Scores schon bei kleinen Änderungen der Inputs stark schwanken, die sich nicht reproduzieren lassen oder in denen merkwürdige Bereiche entstehen wie: „Je höher das Einkommen, desto niedriger der Score.“ Betriebsstabilität, Reproduzierbarkeit und Monotonie (monotonicity) sind oft wichtiger als Performance im Nachkommabereich. Das ist auch ein Grund, warum die logistische Regression selbst im GBM-Zeitalter als Scoring-Standard überlebt hat.

6. Interpretierbarkeit ist keine Option, sondern Pflicht

In anderen Feldern ist es ein netter Bonus, wenn man erklären kann: „Warum ist diese Vorhersage herausgekommen?“ Im Kreditbereich ist das jedoch oft ohne diese Erklärung entweder rechtswidrig oder nicht deploybar.

Mitteilungen über Ablehnungsgründe (adverse action, 否決理由), Erklärungen gegenüber Aufsichtsbehörden und interne Governance verlangen alle eine Antwort auf die Frage: „Warum genau dieser Score?“ Deshalb sind Black Boxes nicht cool, sondern an sich schon ein Risiko. Darum werden in der Praxis Strukturen wie WOE oder Scorecards bevorzugt, aus denen Gründe natürlich ableitbar sind, und selbst wenn Boosting eingesetzt wird, schafft man meist zusätzlich Mechanismen, um etwa mit SHAP Begründungen herauszuziehen.

7. Regulatorischer und Governance-Overhead ist immer mit dabei

Zum Schluss: Modelle können nicht einfach frei ausgerollt werden.

Es reicht nicht, ein Modell fertig gebaut zu haben. Model Risk Management (MRM), unabhängige Validierung, Dokumentation und Audit Trail sind Teil des Entwicklungsprozesses. Entwickler und Validatoren sind getrennt, und neue Modelle laufen in der Regel erst lange im Shadow Mode parallel mit, bevor sie überhaupt echte Entscheidungen beeinflussen. Die Startup-Intuition „Wir haben ein starkes Modell, also schnell deployen“ funktioniert hier nicht besonders gut. Die Langsamkeit hat Gründe. Ein einzelnes Modell wirkt bis in Rückstellungen und Kapitalberechnungen hinein.

(Wenn man in Japan arbeitet, spürt man das noch unmittelbarer. Bei Kartenausgabe und Limits greift nach dem Gesetz über den Ratenverkauf (割賦販売法) die Pflicht zur Berechnung des voraussichtlichen zahlbaren Betrags (支払可能見込額), sodass das Modell direkt zur rechtlichen Grundlage wird. Darauf gehe ich im Teil zur Regulierung gesondert ein.)

Macht das nicht sowieso alles die AI?

Diese Frage höre ich in letzter Zeit oft. Generative AI und Agenten entwickeln sich so schnell — muss man sich solches Modellierungswissen dann überhaupt noch aneignen? Meine ehrliche Antwort ist: eher noch mehr als bisher (zumindest im Moment).

Die sieben Punkte oben sind keine Frage eines bestimmten Algorithmus, sondern der Problemstruktur dieses Feldes. Unbeobachtete Counterfactuals, Daten, die in zeitlicher Reihenfolge fließen, asymmetrische Kosten, absolute Wahrscheinlichkeiten, Stabilität, Erklärungspflichten, Regulierung. Diese Probleme verschwinden nicht, nur weil man ein LLM daraufsetzt. Im Gegenteil: Es braucht jemanden, der weiß, dass es diese Probleme gibt, damit ein automatisch erzeugtes Modell nicht selbstbewusst falschliegt.

Besonders Punkt 6 und 7 sind entscheidend. Ablehnungsgründe müssen erklärt werden, Modelle müssen unabhängig validiert werden, und ihre Ergebnisse dienen als Grundlage für Rückstellungen und Kapitalberechnungen. Black-Box-Modelle stoßen an diesen Anforderungen strukturell an Grenzen. Deshalb wird generative AI die Kreditprüfung nicht vollständig übernehmen. Stattdessen bleiben Menschen wichtig, die verstehen, warum Erklärbarkeit nötig ist und wie validiert wird — und die die von der AI erzeugten Ergebnisse beurteilen können.

Natürlich verändert sich trotzdem einiges. Wiederholbare Codearbeit und grundlegende Analysen werden zunehmend Aufgaben der AI. Deshalb verschiebt sich der Schwerpunkt in der Praxis von der Fähigkeit, Modelle von Hand zu schreiben, hin zur Urteilsfähigkeit, Probleme korrekt zu formulieren, zu validieren und zu überprüfen. Genau um Letzteres soll es in dieser Reihe gehen.

Also, worin besteht Können in diesem Feld?

Wenn man diese sieben Punkte in einem Satz zusammenfassen will, dann so:

Financial Data Science ist kein „Wettbewerb um Vorhersagegenauigkeit“, sondern die Aufgabe, unbeobachtete Counterfactuals in einer Umgebung mit fortschreitender Zeit und asymmetrischen Kosten erklärbar und stabil zu schätzen.

Bewertungsmetriken und Scorecards sind eher so etwas wie die Eintrittskarte. Die wirklichen Unterschiede im Können zeigen sich bei Selection Bias, Kausalität, Validierung und Governance.

In dieser Reihe möchte ich diese sieben Punkte Stück für Stück in Ruhe aufgraben. Wie löst man Reject Inference, warum liegen so viele bei der Kalibrierung daneben, warum ist kausale Inferenz der Kern der Kreditprüfung und wie validiert man so, dass ein Modell in Produktion überlebt? Ab dem nächsten Teil gehen wir das gemeinsam an.

---

Dieser Artikel wurde zuerst auf han-co.com veröffentlicht und erscheint parallel auf Koreanisch und Japanisch. Das Original mit handgezeichneten Diagrammen und E-Mail-Abo gibt es hier → https://han-co.com/ko/blog/part0-finance-ds-7-differences