Cash-Flow-Underwriting: Kontotransaktionen in Leistbarkeitssignale verwandeln

Cash-Flow-Underwriting liest die tatsächliche Kontoaktivität eines Kreditnehmers, klassifiziert jede Transaktion, rekonstruiert Einkommen und feste Ausgaben und verwandelt das in Leistbarkeitssignale, die eine Kreditentscheidung nutzen kann. Der Rohdatenstrom ist für sich genommen fast wertlos: doppelte Zeilen, kryptische Händler-Strings, vorgemerkte Buchungen, die sich später ändern, Überweisungen, die wie Einkommen aussehen. Der Wert steckt in der Pipeline, die ihn bereinigt.

Ein einzelner Kontodatenstrom ist eine Abfolge datierter Beträge mit kurzen, uneinheitlichen Beschreibungen. Beim einen kommt das Gehalt als SALARY ACME LTD an; beim anderen als taggleiche Sofortüberweisung von einem Namen, der zufällig auch der des Mitbewohners ist. Eine Kreditrate und ein Abonnement können identisch aussehen. Ein Underwriting direkt darauf erzeugt ein Modell, das selbstsicher und falsch ist. Alles Nützliche passiert in den Schichten zwischen Datenstrom und Feature.

Vom Rohdatenstrom zu einem sauberen Kontobuch

Die Modellierung kommt später. Die erste Aufgabe ist, ein Kontobuch zu bekommen, dem man vertrauen kann. Open-Banking-APIs und geparste PDF-Auszüge liefern dieselben Kopfschmerzen, und die meisten frühen Fehler passieren hier und nicht im Klassifikator.

• Deduplizierung. Aggregatoren senden Transaktionen erneut, vorgemerkte Buchungen werden mit einer anderen Referenz als gebucht neu ausgestellt, und ein erneut abgerufener Auszug überschneidet sich mit dem letzten. Wir lösen jede Transaktion über Betrag, Gegenpartei, Datum und Konto zu einer stabilen Identität auf und kollabieren dann die Duplikate. Wer das falsch macht, zählt Einkommen doppelt oder Schulden doppelt, und beides ist gefährlich.
• Vorgemerkt versus gebucht. Eine vorgemerkte Belastung kann sich im Betrag ändern oder verschwinden. Wir entscheiden pro Feature, ob vorgemerkte Aktivität zulässig ist; Features zur Saldovolatilität nutzen sie, Features zu festen Ausgaben warten auf die Buchung.
• Abstimmung. Der laufende Saldo minus der Summe der Transaktionen sollte aufgehen. Wenn nicht, gibt es eine Lücke im Datenstrom, und eine Lücke bedeutet, dass die Einkommenszahl zu niedrig ausgewiesen wird. Wir stimmen ab, bevor irgendetwas Nachgelagertes die Daten liest, und halten Anträge zurück, bei denen das Kontobuch nicht ausgeglichen ist, statt sie trotzdem zu bewerten.
• Netting über mehrere Konten. Wer ein Girokonto und ein Sparkonto hat, verschiebt Geld zwischen beiden. Diese internen Überweisungen sind weder Einkommen noch Ausgaben. Eine Entity Resolution über die eigenen Konten des Antragstellers entfernt sie; übersieht man das, bläht jede Überweisung beide Seiten des Leistbarkeitsbildes auf.

Erst wenn das Kontobuch ausgeglichen ist und die internen Überweisungen weg sind, verdient die Kategorisierung ihren Platz.

Kategorisierung, die man verteidigen kann

Die Transaktionskategorisierung ist der Kern des Systems, und hier greifen Teams zu schnell zu einem großen Modell. Die meisten Transaktionen werden über ihre Gegenpartei kategorisiert, und Gegenparteien wiederholen sich. Ein aufgelöstes Händlerverzeichnis plus Regeln erledigt die Fälle mit hohem Volumen und ohne Mehrdeutigkeit mit nahezu perfekter Precision und ohne Kosten pro Aufruf. Das Modell verdient seinen Platz am Long Tail: unbekannte Händler, mehrdeutige Freitext-Zahlungen, Überweisungen, deren Zweck aus dem Muster abgeleitet werden muss.

Zwei Kategorien tragen den Großteil des Entscheidungsgewichts und verdienen eine eigene Behandlung.

Einkommen bedeutet wiederkehrenden, zuordenbaren Zufluss. Es kommt viel Geld an, das kein Einkommen ist, deshalb muss der Klassifikator das Gehalt von einem einmaligen Geschenk, von einer Kreditauszahlung, die als Gutschrift landet, und von einer Erstattung trennen. Wir suchen nach Periodizität, einer stabilen Gegenpartei und Beträgen, die sich clustern, und leiten dann das monatliche Bruttoeinkommen mit einem Konfidenzband ab statt mit einer einzelnen Zahl. Ein Fenster, das keinen vollen Gehaltszyklus abdeckt, bekommt ein breiteres Band und eine Kennzeichnung, keine Schätzung.

Feste Ausgaben sind das Spiegelbild. Miete, bestehende Kredit- und Kartenraten, Nebenkosten, Versicherungen, Kinderbetreuung und jede andere Verpflichtung, die der Kreditnehmer nicht ohne Weiteres fallen lassen kann. Diese treiben die Leistbarkeitsprüfung weit stärker als diskretionäre Ausgaben. Nach den Leistbarkeitsvorschriften der FCA für Verbraucherkredite muss der Kreditgeber prüfen, ob die Raten ohne übermäßige Schwierigkeiten tragbar sind, und diese Prüfung hängt unmittelbar davon ab, wie gut man Festes von Diskretionärem trennt.

Jeder Klassifikator braucht ein zurückgehaltenes Eval-Set aus dem realen Zahlungsmix, mit einem pro Kategorie festgelegten Budget für False Positives. Precision bei Glücksspiel, Kreditraten und Gehalt zählt mehr als Precision bei Lebensmitteln, weil diese Kategorien die Entscheidung bewegen. Wir verfolgen Precision und Recall nach Kategorie, nicht eine einzelne gemischte Genauigkeitszahl, die die entscheidenden Fehler verdeckt.

Features, die zum Entscheidungszeitpunkt standhalten

Kategorisierte Transaktionen werden zu Leistbarkeits-Features, und hier hört Point-in-Time-Korrektheit auf, ein nettes Extra zu sein. Jedes Feature wird zum Entscheidungs-Zeitstempel berechnet und nutzt nur Buchungen, die auf diesen Zeitpunkt oder davor datiert sind. Labels stammen aus einem späteren, nicht überlappenden Fenster. Wenn ein Feature versehentlich eine Transaktion liest, die nach der Entscheidung gebucht wurde, lernt das Modell, die Zukunft aus der Zukunft vorherzusagen, glänzt im Backtest und bricht in Produktion zusammen. Das ist Lookahead-Leakage, und es ist der häufigste Weg, auf dem ein Cash-Flow-Modell offline besser aussieht, als es live je performt.

Die Features, die überleben, sind meist die langweiligen:

• Abgeleitetes monatliches Brutto- und Nettoeinkommen, mit angehängtem Konfidenzband.
• Verfügbares Einkommen nach festen Ausgaben und dessen Stabilität von Monat zu Monat.
• Schuldendienstquoten, berechnet aus beobachteten Raten, nicht aus angegebenen.
• Saldoverhalten: Tage im Dispo, Puffer zum Monatsende, Volatilität rund um das Quartalsende, wenn Steuern und Jahresgebühren anfallen.
• Negativsignale: zurückgegebene Lastschriften, Glücksspielintensität, ein Gehalt, das vor drei Monaten aufgehört hat.

Diese liegen in einem Feature Store, damit die exakten Werte, die für eine Entscheidung verwendet wurden, reproduzierbar sind und Training und Serving dieselben Definitionen lesen. Wenn eine Aufsichtsbehörde, ein interner Model-Risk-Prüfer oder ein Ombudsmann fragt, warum ein Antrag abgelehnt wurde, rekonstruiert man das Kontobuch, die Kategorisierung und den Feature-Vektor so, wie sie zum Entscheidungszeitpunkt standen. Diese Lineage ist auch das, was eine Adverse-Action-Erklärung wahrheitsgemäß statt nachträglich konstruiert macht.

Cash-Flow-Features driften. Namenskonventionen von Händlern ändern sich, eine Bank ändert ihr Auszugsformat, ein neues Zahlungsverfahren verschiebt, wie Gehälter ankommen, und die Kategorisierung verschlechtert sich unbemerkt. Wir überwachen Kategorienverteilungen und Einkommenserkennungsraten gegen die Eval-Baseline und alarmieren bei Bewegung, denn ein Klassifikator, der still von gut auf mittelmäßig abrutscht, verschiebt die Annahmequote leise, bevor es jemand in den Verlustzahlen bemerkt.

Der technische Gewinn ist Straight-Through Processing bei den sauberen Fällen und eine Prüf-Queue für Menschen für den Rest: kurze Fenster, nicht abgestimmte Kontobücher, Einkommen mit geringer Konfidenz, widersprüchliche Signale. Die Pipeline sollte die eindeutigen Anträge selbst entscheiden und die wirklich unsicheren an einen Menschen weiterleiten, mit dem Kontobuch und den abgeleiteten Zahlen vor Augen.