Für einen Chief Risk Officer ist Scoring keine analytische Fingerübung, sondern ein Hebel, der unmittelbar auf Risikokosten, Annahmequote und die Frage wirkt, ob das Portfolio einen schlechteren Zyklus übersteht. Ein gut gebautes Kreditscoring lässt Sie schneller, günstiger und wiederholbar entscheiden - und jede Entscheidung dennoch vor interner Revision und Aufsicht vertreten. Das Problem sitzt selten im Algorithmus selbst; weit häufiger liegt es in den Daten, im Prozess rund um das Modell und in der Frage, wer es über Jahre am Laufen hält.
Nach unserer Erfahrung besteht die Schwierigkeit solcher Projekte darin, drei Welten gleichzeitig zusammenzubringen: Data Engineering, Risikomodellierung und Compliance. Im Scoring führen wir keine eigene abgeschlossene Einführung, auf die wir als Referenz verweisen könnten; was wir bereitstellen, ist genauso konkret - die Menschen und die Kompetenzen, die solche Systeme bauen. Wir verbinden Data Engineers und AI/ML-Spezialisten aus der RITS Group (unsere AI/ML- und Data-Teams mit Fokus auf Daten und Machine Learning) mit unserer Erfahrung aus Projekten für den Finanzsektor.
Warum brauchen Sie Kreditscoring und Risikobewertung überhaupt?
Die Risikobewertung bringt Ordnung in eine Entscheidung, die sonst subjektiv und schwer vertretbar ist. Statt auf das Bauchgefühl eines Analysten zu setzen, führen wir das Kundenrisiko auf einen messbaren, wiederholbaren Wert zurück und bauen erst darauf die Kreditpolitik auf. Das bringt der Bank mehreres zugleich: kürzere Entscheidungszeiten, Konsistenz über Filialen und Kanäle hinweg, einen klaren Audit-Trail und die Möglichkeit, den Risikoappetit über Cut-off-Schwellen zu steuern statt über das händische Korrigieren von Anträgen. Es ist diese Wiederholbarkeit und nicht das Ergebnis einer einzelnen Entscheidung, die auf Portfolioebene den Unterschied macht.
Welche Eingangsdaten speisen Scoring-Modelle, und wie steht es um ihre Qualität?
Scoring ist nur so gut wie die Daten, aus denen es lernt und auf denen es läuft. Bevor jemand ein Modell anfasst, legen wir die Datenschicht an, denn dort verstecken sich die meisten späteren Probleme. In der Praxis arbeiten wir mit mehreren Arten von Quellen:
- internen Daten der Bank - Konto-, Transaktions-, Rückzahlungs- und Rückstandshistorie,
- externen Registerdaten - Kredit- und Wirtschaftsauskunfteien,
- Verhaltens- und Antragsdaten - Aktivität in den digitalen Kanälen, Daten aus dem Antragsformular,
- Makro- und Branchendaten - dem Kontext, in dem sich das Portfolio bewegt.
Das größte Risiko sind nicht fehlende Daten, sondern ihre Inkonsistenz, Lücken und stillen Definitionswechsel zwischen Systemen. Deshalb bauen wir Datenqualitätsprüfungen, ein Merkmalsverzeichnis und eine Vollständigkeitsüberwachung als Teil der Lösung ein und nicht nachträglich. Ein auf schmutzigen Daten trainiertes Modell sieht auf dem Papier gut aus und scheitert in der Produktion.
Regeln oder Machine Learning, und was ist mit der Erklärbarkeit?
Das ist keine Entweder-oder-Entscheidung. Geschäftsregeln geben volle Kontrolle und sofortige Interpretierbarkeit und eignen sich deshalb hervorragend für harte Richtlinien und regulatorische Cut-offs. ML-Modelle wiederum erfassen Zusammenhänge, die sich nicht von Hand aufschreiben lassen, und verbessern meist die Trennschärfe zwischen Kunden. In Scoring-Projekten verbinden wir am häufigsten beide Ansätze: eine Regelschicht für harte Bedingungen und ein statistisches oder ML-Modell dort, wo die Prognosequalität entscheidet.
Erklärbarkeit ist hier entscheidend. Im Kreditgeschäft muss eine Entscheidung gegenüber dem Kunden und der Aufsicht begründet werden, deshalb bevorzugen wir Modelle und Werkzeuge, die zeigen, warum ein Kunde einen bestimmten Score erhalten hat. In der Praxis heißt das transparente Scorecards und, wo ML ins Spiel kommt, Techniken wie SHAP sowie eine klare Beschreibung der Merkmale. Ein Modell, das Sie nicht erklären können, ist in diesem Feld eher ein Risiko als ein Vorteil.
Wie validieren und überwachen Sie Scoring-Modelle nach dem Go-live?
Ein Modell ist kein Projekt, das endet, sondern ein System, das lebt. Das Portfolio verschiebt sich, das Kundenverhalten driftet, und ein gutes Jahr kann das Team genau vor einem schlechteren in Sicherheit wiegen. Deshalb behandeln wir Validierung und Monitoring als fortlaufenden Prozess und nicht als einmalige Abnahme. In dieser Schicht beobachten wir üblicherweise:
- die Trennschärfe (Gini, KS, AUC) auf Out-of-Time-Daten und nicht nur auf dem Trainingsdatensatz,
- die Stabilität von Population und Merkmalen (PSI) über die Zeit,
- die Übereinstimmung von Prognose und Realität (Kalibrierung, Backtesting),
- Alarmschwellen, die eine Verschlechterung des Modells früh anzeigen.
Wir entwerfen das so, dass das Risikoteam den Zustand des Modells in Echtzeit sieht und eine belastbare Grundlage für eine Entscheidung zum Nachtrainieren hat, bevor die Verschlechterung auf die Risikokosten durchschlägt.
Wie gehen Sie mit Compliance, Bias und menschlicher Aufsicht um?
Scoring läuft auf Daten über Menschen, deshalb sind Compliance und Ethik keine Ergänzung, sondern eine Randbedingung. Wir stellen sicher, dass das Modell nicht auf sensible Merkmale oder deren verdeckte Stellvertreter zurückgreift, und testen es auf Bias über Kundengruppen hinweg. Parallel führen wir eine vollständige Dokumentation: woher die Daten stammen, wie das Modell gebaut und wie es validiert wurde - denn genau das geht durch die Prüfung.
Davon getrennt gestalten wir den Menschen in der Entscheidungsschleife. Das automatisierte System kann empfehlen und eindeutige Fälle freigeben, aber Grenzfälle und begründungspflichtige Ablehnungen bleiben bei einer Fachkraft, mit klarem Kontext auf dem Bildschirm. Dieses Vorgehen verbindet das Tempo der Automatisierung mit der Rechenschaft, die die Aufsicht erwartet.
Wie binden Sie Scoring in den Kreditprozess und die Banksysteme ein?
Das beste Modell liefert nichts, solange es nicht Teil eines echten Entscheidungsprozesses ist. Deshalb betrachten wir Scoring durchgängig: vom Antrag über die Entscheidungs-Engine bis zu den Core-Systemen und dem Berichtswesen. Wir stellen das Modell als Service mit API bereit, sodass die Entscheidung in Millisekunden fällt und samt Begründung in den Prozess zurückkehrt. Wir verbinden es mit der Regel-Engine, dem Antragssystem und dem Data Warehouse und behalten dabei die Modellversionierung und die vollständige Aufzeichnung jeder Entscheidung. Das Ziel ist einfach: Scoring als wiederholbarer Teil des Prozesses und nicht als Tabelle, die nebenher läuft.
Welche Kompetenzen stellen wir für ein Scoring-Projekt bereit?
Wir stellen das Team rund um die konkrete Phase und die Lücke in Ihrem eigenen Team zusammen, nicht „auf Vorrat”. In Daten- und Risikoprojekten besetzen wir meist diese Rollen:
- Data Engineers - bauen die Datenschicht, die Pipelines und die Qualitätskontrollen,
- Data Scientists / ML-Spezialisten - entwerfen, trainieren und validieren die Modelle,
- MLOps- / DevOps-Engineers - bringen Modelle und Monitoring in die Produktion,
- Backend-Entwickler - binden das Scoring in die Entscheidungs-Engine und die Banksysteme ein.
Dieses Team arbeitet im Modell Team-Verstärkung oder Dediziertes Team, unter Ihrer Aufsicht und innerhalb Ihres Compliance-Rahmens, und stockt Kompetenzen genau dort auf, wo sie fehlen.
Wie machen wir das bei RITS?
Wir tun es als Nearshore-Partner aus Polen, der Daten- und AI-Kompetenzen mit Erfahrung im Finanzsektor verbindet. Wir verkaufen keine Scoring-„Box”, denn gutes Scoring ist immer auf Portfolio, Politik und Daten einer bestimmten Bank zugeschnitten. Stattdessen besetzen wir die Rollen und bauen die Lösung gemeinsam mit Ihrem Risikoteam: Data Engineers aus der RITS Group und AI/ML-Spezialisten (unsere AI/ML- und Data-Teams) bauen die Datenschicht und die Modelle, während wir uns um Erklärbarkeit, Validierung und die Einbindung in den Prozess kümmern. Wir prüfen die Kompetenzen vor dem Start und arbeiten in einer nahen Zeitzone, sodass das Team ohne langen Anlauf an Reviews und Terminen teilnimmt.
Wo beginnen Sie mit Scoring und Risikobewertung?
Beginnen Sie mit einer einzelnen Kreditentscheidung und ihren Daten, nicht mit der Wahl eines Algorithmus. Legen Sie genau fest, was Sie vorhersagen wollen (z. B. das Ausfallrisiko bei einem bestimmten Produkt), welche Daten Sie wirklich haben und in welcher Qualität und wie die Entscheidung in Prozess und Aufsicht passen soll. Das legt den Modellumfang, die Validierungsanforderungen und die Rollen fest, die Sie brauchen. Wenn Sie abwägen, wie Sie das Team dafür am besten zusammenstellen, finden Sie einen Vergleich in unserem Artikel zu IT-Kooperationsmodellen.
Sie bauen ein Kreditscoring auf oder erneuern Ihre Risikobewertung? Sprechen wir darüber - wir finden ein Team und einen Ansatz passend zu Ihrem Portfolio und den aufsichtsrechtlichen Anforderungen.