Risikobasierte Bepreisung setzt die Rate jedes Kreditnehmers aus den geschätzten Kosten, ihn zu bedienen: Ausfallwahrscheinlichkeit, Loss Given Default, Fundingkosten und eine Marge. Bepreise mit einem Modell und du übernimmst zwei Aufgaben. Du bepreist genau, und du erklärst einer Aufsicht, warum ein Antragsteller mehr zahlt als ein anderer, ohne dass diese Lücke einem geschützten Merkmal folgt. Der Großteil des Engineerings fließt in die zweite Aufgabe.
Die Versuchung ist, Pricing als eine einzige Optimierung zu behandeln: maximiere die erwartete Marge unter einem Booking-Rate-Ziel, gib die Zielfunktion einem Gradient-Boosted-Modell und lass es die Rate finden. Das produziert eine Zahl, die niemand verteidigen kann. Ein Fair-Lending-Prüfer fragt nicht, wie hoch dein AUC ist. Er fragt, warum dieser Antragsteller, in dieser ZIP-Code, mit dieser dünnen Akte, 240 Basispunkte über der Shelf Rate angeboten bekam, und er erwartet, dass die Antwort sich sauber zerlegt.
Trenne den Risikopreis vom Nachfragepreis
Halte die zwei Kräfte in der Architektur getrennt, nicht nur im Bericht. Risikobasierte Bepreisung hat einen Floor, gesetzt aus erwartetem Verlust und Funding: das ist der Preis, den du verlangen musst, um auf dem Kredit die Kosten zu decken. Über diesem Floor sitzt die Nachfragefrage, nämlich wie viel Marge der Markt trägt, bevor der Antragsteller abspringt. Das sind verschiedene Modelle mit verschiedenen Eingaben. Kollabiere sie zu einer Zielfunktion, und der Ärger beginnt.
- Der Risikopreis kommt aus einem PD-Modell, einem LGD-Modell und der Fundingkurve. Seine Eingaben sind Kreditvariablen, die du Zeile für Zeile verteidigen kannst, und er ist für zwei Antragsteller mit gleichem Risiko gleich, egal wer sie sind.
- Der Nachfragepreis kommt aus einer Elastizitätsschätzung: wie die Booking-Wahrscheinlichkeit auf die angebotene Rate reagiert. Hier findet Preisoptimierung in der Kreditvergabe tatsächlich statt, und hier kann sich ein Proxy für eine geschützte Klasse einschleichen, wenn du dem Nachfragemodell rohe Geografie-, Device- oder Kanaldaten unbedacht fütterst.
Der Grund, sie zu trennen, ist rechtlich so sehr wie technisch. Unter ECOA und Regulation B werden Disparate Treatment und Disparate Impact gegen den Preis bewertet, den der Antragsteller erhält. Markiert deine Elastizitätsschicht die Rate für ein Segment auf, das mit einer geschützten Klasse korreliert, kannst du das nicht im Nachhinein heilen, indem du auf das PD-Modell zeigst. Der Aufschlag muss auf eine erlaubte, geschäftlich begründete Variable zurückführbar sein. Also constrainen wir den Feature-Satz des Nachfragemodells bewusst und protokollieren, welche Features jedes Angebot bewegten.
Bring die Trainingsdaten in Ordnung, bevor du das Modell anfasst
Point-in-Time-Korrektheit zählt beim Pricing mehr als bei einem reinen Risikoscore, weil ein Pricing-Modell auf gebuchten Krediten trainiert wird, und gebuchte Kredite sind eine zensierte Stichprobe. Du beobachtest Rückzahlung nur für Anträge, die du genehmigt und bepreist hast, zu dem Preis, den du zufällig angeboten hast. Diese Selektion ist strukturell, kein Sampling-Rauschen, das du wegmitteln kannst, und sie verzerrt Elastizitätsschätzungen zu dem hin, was deine alte Pricing-Policy tat.
Ein paar Dinge, auf die wir in der Datenschicht bestehen:
- Rekonstruiere jedes Feature zum Entscheidungszeitpunkt. Ein heute gezogenes Kreditbureau-Attribut ist ein Lookahead in das Rückzahlungsverhalten, das das Modell zur Angebotszeit nicht gehabt hätte. Leakage hier bläht Offline-Metriken auf und bricht in Produktion zusammen.
- Führe Lineage von jeder Trainingszeile zurück zum Rohantrag und zum exakt angebotenen Preis. Wenn ein Prüfer eine Entscheidung achtzehn Monate später hinterfragt, musst du die Eingaben reproduzieren, nicht annähern.
- Korrigiere für die Zensierung. Randomisierte Preistests in einem engen, genehmigten Band geben dir das sauberste Elastizitätssignal. Wo du nicht randomisieren kannst, ist Inverse-Propensity-Weighting auf der historischen Angebots-Policy der Fallback, und du dokumentierst seine Annahmen.
Quartalsend-Repreisungen und Fundingkosten-Bewegungen brechen ebenfalls naive Trainings-Splits. Verschob sich deine Fundingkurve im März, lernt ein über den Shift trainiertes Modell einen Durchschnitt, der zu keinem Regime passt. Segmentiere nach Funding-Umfeld oder füttere die Fundingkosten als explizite Eingabe, statt das Modell sie aus dem Kalender ableiten zu lassen.
Lass jedes Angebot sich zerlegen und protokolliere es
Das Pricing-System sollte eine Rate plus deren Zerlegung ausgeben: so viele Basispunkte erwarteter Verlust, so viel Funding, so viel Betriebskosten, so viel Marge, und die Marge selbst gesplittet in eine Basiskomponente und eine elastizitätsgetriebene. Kannst du diese Aufschlüsselung für ein beliebiges historisches Angebot nicht produzieren, ist das System eine Blackbox, die zufällig Zahlen ausstößt, und es wird eine Prüfung nicht überstehen.
Wir bauen die Zerlegung als erstklassiges Artefakt, bei jeder Entscheidung neben den Modellversionen und Feature-Werten, die sie erzeugten, in den Audit-Trail geschrieben. Auf diesem Datensatz läuft eine Fair-Lending-Prüfung. Er lässt dich auch die Drift überwachen, die hier zählt: ob sich die Margenverteilung für irgendein Segment über die Zeit weitet, was dir mehr sagt als eine Schlagzeilen-Genauigkeitsmetrik je könnte.
Die Monitoring-Seite verdient ihr eigenes Budget. Setze eine Toleranz für Disparität in Ergebnissen über geschützte Klassen, miss sie fortlaufend auf gebuchten Krediten, und behandle eine Überschreitung als Produktionsvorfall mit Rollback-Pfad statt als Zeile in einem Quartalsbericht. Ein Pricing-Modell, das bei Launch die Prüfung bestand, kann mit dem Wandel des Antragsteller-Mix in ein Problem driften, und das erste Zeichen steckt meist in der Margen-Zerlegung, nicht in der Schlagzeilen-Booking-Rate.
Nichts davon macht das Modell weniger profitabel. Es macht den Profit lesbar. Eine Rate, die du vor einem Prüfer auseinandernehmen kannst, ist eine Rate, die du auch vor deinem eigenen Risikokomitee auseinandernehmen kannst, wenn es fragt, warum Bookings in einem Kanal fielen. Die Zerlegung verdient sich ihren Platz auf beiden Seiten dieses Tisches.
Häufige Fragen
Können wir den Preis auf Elastizität optimieren und trotzdem Fair-Lending-konform bleiben?
Ja, wenn das Elastizitätsmodell nur aus erlaubten Variablen gespeist wird und du die Rate jedes Antragstellers in ihre Risiko- und Nicht-Risiko-Komponenten zerlegen kannst. Das Compliance-Problem beginnt, wenn ein Nachfragemodell still einen Proxy für eine geschützte Klasse lernt und den Preis daran bewegt.
Brauchen wir getrennte Modelle für Ausfallwahrscheinlichkeit und Preissensitivität?
Meist ja. Ausfallrisiko und Zahlungsbereitschaft sind verschiedene Phänomene mit verschiedenen Treibern, und sie in einen Output zu mischen macht die Rate in einer Prüfung unerklärbar. Halte PD, Loss Given Default und Nachfrageantwort als getrennte Schätzungen, die du in der Pricing-Schicht kombinierst.
Wie backtesten wir ein Pricing-Modell, das das Kundenverhalten verändert?
Offline-Backtests überzeichnen die Performance, weil die historischen Daten nur Ergebnisse für die tatsächlich angebotenen Preise zeigen. Nutze Holdout-Regionen, randomisierte Preistests innerhalb eines kontrollierten Bands und Inverse-Propensity-Weighting, um die Selektion in deiner Booked-Loan-Historie zu korrigieren.