Lehnt ein Kreditgeber einen Antrag ab, verlangt ECOA, umgesetzt durch Regulation B in 12 CFR 1002.9, innerhalb von 30 Tagen eine sogenannte Adverse Action Notice. Diese Mitteilung muss die konkreten Hauptgründe nennen, die die Entscheidung getragen haben, bis zu vier davon. Keine Kategorie. Kein “entsprach nicht unseren Kriterien”. Sondern die tatsächlichen Faktoren, die das Ergebnis für genau diesen Antragsteller bewegt haben.
Die meisten Teams behandeln das als Compliance-Aufgabe, die nach dem Modell ansetzt. Das ist sie nicht. Es ist eine Vorgabe dafür, was das Modell überhaupt sein darf. Die CFPB hat klargestellt, dass ein Kreditgeber eine Nichteinhaltung nicht damit entschuldigen kann, seine Technologie sei zu komplex oder zu undurchsichtig, um konkrete Gründe zu benennen. Im Klartext: Ein Modell, das zu undurchsichtig ist, um eine Ablehnung zu erklären, darf für diese Ablehnung nicht verwendet werden. Die Erklärungspflicht steht nicht hinter der Modellierungsentscheidung, sie steckt mitten in ihr.
Begründungscodes am Modell ausgerichtet, nicht nachträglich erfunden
Das Versagensmuster, das wir sehen: Ein Modell wird auf Genauigkeit trainiert, ohne an die Erklärbarkeit zu denken, und anschließend wird ein zweites System angeflanscht, das die Gründe für die Mitteilung produziert. Dieses zweite System erzählt eine Geschichte darüber, warum der Antragsteller abgelehnt wurde. Die Geschichte klingt plausibel. Das Problem ist, dass nichts garantiert, dass sie zu dem passt, was das Modell tatsächlich bewertet hat.
Begründungscodes müssen die Faktoren widerspiegeln, die das Modell für diesen Antragsteller wirklich gewichtet hat. Stützt sich das Modell auf ein bestimmtes Signal und nennt die Mitteilung ein anderes, ist der Begründungscode falsch, auch wenn er sich gut liest. Diese Lücke lässt sich mit bloßem Auge nur schwer erkennen, gerade weil die nachträgliche Erklärung darauf ausgelegt ist, lesbar zu sein. Die Aufgabe lautet deshalb:
- Begründungscodes aus dem Modell ableiten, das die Entscheidung getroffen hat, mit einer Attribution, die das Modell tragen kann, nicht über eine separate Erzählschicht, die sein Verhalten errät
- Alternative Datenfaktoren abdecken, denn Regulation B erfasst alles, was das Modell tatsächlich bewertet hat; Cash-Flow-Signale, Telekommunikations- oder Versorgungsdaten und Ähnliches müssen als Gründe auftauchen, wenn sie das Ergebnis bewegt haben
- Prüfen, dass die Codes korrekt sind, anhand von zurückgehaltenen Fällen, bei denen Sie wissen, welche Faktoren den Score verschoben haben, genauso wie Sie ein Eval-Set für jede andere Aussage des Systems aufbauen würden
- Den Prüfpfad lückenlos führen, sodass Sie für jede Ablehnung die Eingaben, den Score und die vier versendeten Gründe rekonstruieren können
Den dritten Punkt überspringen die Teams. Ein Generator für Begründungscodes ist eine Modellausgabe wie jede andere, und eine ungeprüfte Modellausgabe ist eine Vermutung. Sie brauchen Fälle, in denen Sie die genannten Gründe gegen die Faktoren prüfen können, die die Entscheidung tatsächlich verändert haben, und eine Kennzahl, die Ihnen sagt, wie oft beide übereinstimmen.
Erklärbarkeit einplanen, bevor Sie das Modell auswählen
Am günstigsten erfüllen Sie diese Anforderung bei der Modellauswahl. Ein Modell, dessen Ablehnungen Sie auf konkrete bewertete Faktoren zurückführen können, ist ein Modell, das Sie im Kreditgeschäft einsetzen dürfen. Ein Modell, das Sie nicht zurückführen können, ist eines, das Sie später wieder abwickeln werden, nachdem es bereits Mitteilungen verschickt hat, die Sie nicht verteidigen können. Diese Reihenfolge ist entscheidend, denn die Alternative ist, im Produktivbetrieb festzustellen, dass Ihr genauestes Modell genau jenes ist, das Sie für die Entscheidung, für die es gebaut wurde, nicht einsetzen dürfen.
Erklärbarkeit muss hier sowohl unter ECOA als auch unter FCRA ausreichen. FCRA bringt eigene Offenlegungspflichten mit sich, wenn eine Kreditentscheidung auf einer Verbraucherauskunft beruht, und ein Schema für Begründungscodes, das die eine Vorschrift erfüllt, erfüllt nicht automatisch die andere. Wir behandeln beide von Anfang an als Designvorgaben, nicht als Einschränkungen, die erst im Review auffallen.
Technisch betrachtet ist daran nichts Exotisches. Es ist dieselbe Disziplin wie Point-in-Time-Korrektheit oder Data Lineage: vorab festlegen, was das System belegen können muss, und so bauen, dass es das kann. Für ein Kreditmodell heißt “belegen”: Für jede Ablehnung liegen hier die konkreten Faktoren, die sie ausgelöst haben, hier ist der Nachweis, dass es die echten Faktoren sind und kein plausibler Ersatz, und hier ist der Pfad von der Eingabe bis zur Mitteilung.
Dieser Maßstab schließt manche Modelle aus. Ein Modell, das Sie auf der Ebene einer einzelnen Ablehnung nicht befragen können, ist ein Modell, das die Anforderung an die Adverse Action Notice nicht erfüllen kann, und kann diese Ablehnung daher nicht treffen. Besser, Sie erfahren das während der Auswahl als nachdem die Mitteilungen bereits draußen sind.
Dies ist eine allgemeine Branchenanalyse, keine Rechtsberatung. Die konkreten Pflichten für ein bestimmtes Kreditprogramm sollten mit qualifizierten Rechtsbeiständen abgeklärt werden.