Ein Bias-Audit-Workflow für Kreditvergabemodelle

Ein Bias-Audit für ein Kreditvergabemodell ist eine Pipeline, die man nach Zeitplan erneut durchläuft, in vier Stufen. Messen Sie Ergebnisunterschiede zwischen geschützten Gruppen mit einem belastbaren Proxy. Erklären Sie auf Feature-Ebene, was sie antreibt. Suchen Sie nach einer weniger diskriminierenden Alternative, die ihre Vorhersagekraft behält. Überwachen Sie das produktive Modell, damit die Zahlen, die Sie freigegeben haben, wahr bleiben, während sich die Population bewegt.

Alles andere ist Dokumentation, die sich um diese vier Stufen legt. Bauen Sie es als Pipeline, denn Fairness driftet aus denselben Gründen, aus denen Genauigkeit driftet. Ihr Antragstellermix ändert sich zum Quartalsende, ein Datenlieferant gewichtet ein Feature neu, ein Auskunfteifeld kommt häufiger als Null an, und die Diskrepanz, die Sie im März ausgeräumt hatten, ist im Juli wieder da. Ein einmaliger, von der Modellrisiko-Funktion abgezeichneter Test sagt Ihnen wenig über das Modell, das Sie heute betreiben. Das Audit muss also Code sein, der erneut läuft, mit einem Audit-Trail dahinter.

Bringen Sie zuerst die Labels zur geschützten Gruppenzugehörigkeit in Ordnung

Sie können Disparate Impact nicht messen, ohne zu wissen, wer in welcher Gruppe ist, und Regulation B unter ECOA untersagt Ihnen bei Konsumentenkrediten außerhalb des Hypothekengeschäfts in der Regel, ethnische Zugehörigkeit oder Geschlecht zu erheben. Also müssen Sie es inferieren, und die Inferenzmethode ist selbst Teil dessen, was ein Prüfer sich ansieht.

• Bei Hypotheken enthält HMDA bereits ethnische Zugehörigkeit und Geschlecht des Antragstellers. Nutzen Sie es direkt und gleichen Sie die Datei mit Ihrem Loan-Origination-System ab, damit Sie dieselben Anträge testen, über die Sie entschieden haben.
• Für alles andere ist die vom CFPB standardisierte Methode Bayesian Improved Surname Geocoding (BISG), die Nachname und Demografie des Census-Tracts zu einer Wahrscheinlichkeit kombiniert, dass ein Antragsteller zu einer bestimmten Gruppe gehört. Es ist ein Proxy mit realem Fehler, der auf bekannte Weise unter- und überzählt.
• Egal aus welcher Quelle: lösen Sie Identitäten sorgfältig auf. Deduplizieren Sie Antragsteller, behandeln Sie gemeinsame Anträge explizit und stellen Sie sicher, dass eine einzelne Person, die über mehrere Produkte hinweg auftaucht, nicht zwei widersprüchliche Proxy-Labels bekommt. Fehler in der Entity Resolution verzerren hier still das gesamte Audit.

Halten Sie die Konstruktion des Proxys, seine Version und seinen gemessenen Fehler gegenüber jeder Ground Truth, die Sie tatsächlich haben, schriftlich fest. Wenn eine Diskrepanzzahl angezweifelt wird, ist die erste Frage immer, ob die Labels standhalten, und diese Frage wollen Sie vorab beantwortet haben.

Messen Sie die Diskrepanz, dann erklären Sie sie

Die zentrale Kennzahl ist die Adverse Impact Ratio: für eine geschützte Gruppe die Rate, mit der Antragsteller genehmigt (oder günstig bepreist) werden, geteilt durch dieselbe Rate für die Referenzgruppe. Die Four-Fifths-Rule schlägt bei einer Ratio unter 0,80 Alarm. Berechnen Sie sie auf Point-in-Time-Daten, mit den Scores und Cutoffs, die tatsächlich live waren. Ein neu gescorter Backtest lässt Informationen einfließen, die das Modell zum Entscheidungszeitpunkt nie hatte, und dieses Leakage schönt die Zahlen.

Die Ratio allein wird der Prüfung nicht standhalten, denn BISG-Labels sind probabilistisch. Führen Sie die üblichen Signifikanz- und Schwellenwerttests auf den gewichteten Zählungen durch, berichten Sie Konfidenzintervalle und machen Sie explizit, dass ein Wert von 0,79 mit breitem Intervall ein anderer Befund ist als ein Wert von 0,79, der eng ist. Segmentieren Sie die Analyse. Ein Modell kann das Aggregat bestehen und innerhalb eines Thin-File- oder Niedrigeinkommens-Segments deutlich durchfallen, und genau dorthin schauen Regulatoren.

Dann erklären Sie die Lücke. Eine Diskrepanzzahl ohne Attribution gibt Ihnen nichts an die Hand, das Sie beheben könnten, und unter den Adverse-Action-Regeln bleibt sie hinter dem zurück, was Sie offenlegen müssen. Setzen Sie Feature-Attribution-Methoden auf der Entscheidungspopulation ein, um zu sehen, welche Inputs die geschützte Gruppe Richtung Ablehnung drücken. Sie jagen Features, die demografisches Signal tragen, ohne eine saubere Underwriting-Begründung: eine geografisch abgeleitete Variable, ein Geräte- oder Kanalfeld, eine Schuldenquote, die so berechnet wird, dass sie unregelmäßiges Einkommen bestraft. Ordnen Sie Features nach ihrem Beitrag zur Diskrepanz, nicht nach globaler Wichtigkeit, denn das sind unterschiedliche Listen.

Suchen Sie nach einer weniger diskriminierenden Alternative

Eine Diskrepanz zu finden ist der Punkt, an dem die Verpflichtung erst beginnt. Die Fair-Lending-Doktrin erwartet von einem Kreditgeber, nach einem alternativen Modell zu suchen, das im Wesentlichen dasselbe Geschäftsziel mit geringerem Disparate Impact erreicht, und die Suche zu dokumentieren. Das ist der Teil, den die meisten Teams überspringen, und der Teil, den Prüfer zunehmend sehen wollen.

Konkret heißt das, eine constrained Suche über Modellvarianten zu fahren:

• Entfernen oder transformieren Sie die Features, die Ihr Attributionsschritt markiert hat, und messen Sie sowohl die Änderung der Impact Ratio als auch den Verlust in AUC oder Genehmigungsrate bei festem Verlust. Sie bewegen sich entlang einer Frontier, und Sie müssen die Frontier zeigen.
• Trainieren Sie mit Fairness-Constraints oder Adversarial Debiasing neu, wo der Feature-Weglass-Ansatz zu viel Vorhersagekraft kostet, und halten Sie fest, warum das constrained Modell übernommen wurde oder nicht.
• Bewahren Sie die abgelehnten Alternativen auf. Ein Modell, das die Diskrepanz reduzierte, aber nicht ausgeliefert wurde, ist genau das, was Sie erklären können müssen, mit der zum Zeitpunkt der Entscheidung notierten geschäftlichen Begründung statt einer später rekonstruierten.

Das Ergebnis dieser Stufe ist eine dokumentierte Entscheidung: Entweder haben Sie eine weniger diskriminierende Alternative übernommen, oder Sie haben einen konkreten, belegten Grund, warum es zu vertretbaren Kosten keine gab. Beides hält in einer Prüfung stand. Was durchfällt, ist eine unerklärte Lücke ohne jeden Beleg dafür, dass Sie überhaupt gesucht haben.

Verdrahten Sie das Monitoring in den Scoring-Pfad

Das Audit, das Sie bei der Validierung bestanden haben, zerfällt. Backen Sie dieselben Tests in die Produktion ein, damit sie bei jedem gescorten Batch laufen statt einmal im Jahr.

• Berechnen Sie die Adverse Impact Ratio und die Genehmigungs- und Preisraten je Gruppe bei jedem Batch, mit den beim Scoring angehängten Proxy-Labels, und alarmieren Sie, wenn eine Gruppe ein Warnband überschreitet, bevor sie die 0,80-Linie erreicht.
• Verfolgen Sie die Ablehnungsgrund-Codes je Gruppe. Wenn die häufigsten Ablehnungsgründe zwischen geschützten Gruppen stark auseinanderlaufen, ist das ein Frühsignal, dass sich etwas in der Feature-Pipeline verschoben hat, und es fließt zugleich direkt in die Frage ein, ob Ihre ECOA-Mitteilungen noch korrekt sind.
• Beobachten Sie den Input-Drift bei den Features, die das meiste demografische Signal tragen, denn dort wird eine Lieferantenänderung oder ein Sprung in der Null-Rate die Fairness zuerst bewegen.
• Legen Sie ein False-Positive-Budget für die Alerts fest. Ein Monitor, der bei jeder Quartalsend-Mischungsverschiebung anschlägt, wird stummgeschaltet, und ein stummgeschalteter Monitor ist schlimmer als keiner.

Halten Sie das Ganze unter Lineage: welche Modellversion, welche Proxy-Version, welche Cutoffs, welcher Batch. Wenn ein Prüfer oder ein interner Reviewer fragt, ob das Modell eine Gruppe im vergangenen März fair behandelt hat, sollte die Antwort eine Abfrage gegen gespeicherte Ergebnisse sein, reproduzierbar bis auf die Zeile, statt ein Projekt, das Sie aus dem Gedächtnis neu durchspielen.