Wie man DecisionRules für Kredite im Finanzdienstleistungssektor - Berechtigung verwendet

‍Schritt 1: Berechtigungsfilter

Der erste Schritt in diesem Prozess besteht darin, zu überprüfen, ob der Antrag überhaupt für eine Genehmigung in Frage kommt, basierend auf einigen sehr klaren Kriterien – z. B. würden Kreditgeber Kindern keinen Kredit anbieten, daher ist das Alter ein sehr wichtiges Kriterium, das in der gesamten Verbraucherkreditbranche verwendet wird.

Diese Überprüfung erfolgt typischerweise zu Beginn des Prozesses, um zu vermeiden, Ressourcen für die Bearbeitung eines Antrags zu verschwenden, der nicht den grundlegenden Kriterien entspricht. Die Verwendung von Antrags- und internen Daten für diese Filter stellt sicher, dass kostspielige Anfragen bei Auskunfteien vermieden werden.

Die Verwendung von DecisionRules zur Implementierung und Verwaltung dieser Berechtigungsfilter wird in diesem Artikel behandelt und umfasst Details zur Nutzung von DecisionRules, zur Konfiguration von DecisionRules für die Verwendung mit mehreren Produkten und zur Einführung einer Champion-Challenger-Teststrategie.

‍Die Berechtigungsfilter

In unserem Fall erwägt die Institution 4 verschiedene Setups für die Produkte und möchte 1 Standardstrategie und 2 Testszenarien durchführen. Sie möchten die Kunden basierend auf Produkt- und Leistungsmerkmalen vorfiltern.

Die Testszenarien sollen durch zufällige Auswahl erreicht werden. Am Ende werden 70 % der Kunden basierend auf der Standardstrategie entschieden, 15 % durch die 1. Teststrategie und 15 % durch die 2. Teststrategie.

Standardstrategie 70 %:

Produktparameter

Produkt 1: Konsumkredit (Kredit, der dem Kunden gewährt wird, wobei der Zweck nicht auf einen bestimmten Grund beschränkt ist – vertraglich kann es einige Einschränkungen bei der Verwendung der Auszahlung geben).

• Alter 18-60
• Rückstände – 0
• Auskunftei-Score > 500
• Einkommensquelle: außer „arbeitslos“
• Der Kunde hat ein Girokonto: nicht erforderlich
• Segment des Kaufverhaltens des Kunden: nicht erforderlich

Produkt 2: zweckgebundener Kredit (Kredit, der dem Kunden gewährt wird, wobei der Zweck spezifisch ist – es muss keinen bestimmten vertraglich festgelegten Zweck haben und es muss keine bestimmte Sicherheit vorhanden sein)

• Alter 18-65
• Rückstände < 10
• Auskunftei-Score > 500
• Einkommensquelle: außer „arbeitslos“
• Der Kunde hat ein Girokonto: nicht erforderlich
• Segment des Kaufverhaltens des Kunden: nicht erforderlich

Produkt 3: Kreditkarte (Limit wird dem Kunden gewährt; eine Kreditkarte oder ein anderes Zahlungsmittel wird ausgegeben, um dem Kunden zu ermöglichen, Artikel zu bezahlen oder Bargeldabhebungen vorzunehmen)

• Alter 21-50
• Rückstände < 5
• Auskunftei-Score > 550
• Einkommensquelle: nicht erforderlich
• Der Kunde hat ein Girokonto: Ja
• Segment des Kaufverhaltens des Kunden: „Fließender Käufer“

Produkt 4: Überziehung auf dem Girokonto (Limit, das dem Kunden auf dem Konto gewährt wird – normalerweise ein Girokonto, kann möglicherweise auch auf einem Wallet-Konto sein – um dem Kunden zu ermöglichen, unter einem negativen Kontostand abzuheben)

• Alter 15-55
• Rückstände < 7
• Auskunftei-Score > 450
• Einkommensquelle: nicht erforderlich
• Der Kunde hat ein Girokonto: Ja
• Segment des Kaufverhaltens des Kunden: nicht in „Schlafend“

Pilotstrategien

Erste Teststrategie 15 %:

• Alle Rückstände < 3 ausrichten

Zweite Teststrategie 15 %:

• Alter für Kreditkarten auf 18-55 ändern

Erwartete Ergebnisse

Schließlich sollten Sie die Regel Ergebnisse und die Begründung kennen, und die Gründe sollten für den Kunden und für interne Zwecke separat definiert werden.

Lösung

Ausgehend vom Basisfluss, wie die Entscheidung über die Berechtigung der Kunden getroffen wird.

An der Frontend-Seite (die normalerweise eine mobile Anwendung, ein Webformular, ein internes System der Institution, ein Drittanbietersystem oder eine Drittanbieteranwendung ist) oder an der Backend-Seite (Batch-Anfrage aus der Datenbank) werden die erforderlichen Eingaben gesammelt (wie Alter, Einkommensquelle, Finanzierungszweck usw.) und können durch interne Daten (basierend auf einem Backend-Aufruf, wie interne Rückstände, Girokonto, Segmentierung usw.) und externe Daten (basierend auf Backend-Aufruf und Antragsdatensammlung, wie Auskunftei-Score, externe Rückstände usw.) ergänzt werden. All diese Informationen dienen als Eingabe für die DecisionRules. Wir senden die Eingabedaten über einen API-Aufruf an die DecisionRules, und DecisionRules führt die vordefinierten Regeln aus und gibt die Ergebnisse zur Kundenberechtigung für Produkte (Kredite) an das Frontend zurück.

Wie sind die DecisionRules eingerichtet? Zuerst definieren wir die Eingabe und Ausgabe.

Als Eingabe benötigen wir die Attribute für unsere Regeln (siehe unten). Wenn Sie den Beispiel-Fall untersuchen, werden Sie feststellen, dass einige der Produkte ohne einige der Attribute entschieden werden können. Die Benutzeroberfläche wird so gestaltet, dass alle Attribute verwendet werden können, aber nicht alle in jedem Fall erforderlich sind.

Die Ausgabe wird für jedes Produkt über die API-Antwort bereitgestellt, wie im Bild unten zu sehen.

Nachdem wir Eingabe und Ausgabe definiert haben, können wir nun in die Regeldefinition eintauchen. Alle Berechtigungsbedingungen können innerhalb eines Regelsets der Entscheidungstabelle in DecisionRules.io vorbereitet werden, wobei jede Zeile dann eine Bedingungsdefinition für ein Produkt darstellt.

Der Vorteil eines solchen Setups besteht darin, dass es einen Ort für das Regelmanagement gibt. Basierend auf Antragsfiltern oder der Möglichkeit, Regeln in XLSx / JSON / CSV zu exportieren/importieren, können Sie das Setup von Produkt zu Produkt, Regel zu Regel leicht vergleichen.

Die Ausgabe der Entscheidungstabelle erfolgt auf Produkt- und Bedingungsebene. Zum Beispiel werden Konsumkredite separate Ergebnisse (Ergebniszeilen) für Alter, Rückstände, Auskunftei-Score, Einkommensquelle haben (JSON-Beispiel unten). Jede Zeile wird ein definiertes Ergebnis (Berechtigung) und gegebenenfalls eine Begründung haben (Begründung für das Ergebnis intern, Begründung für das Ergebnis Kunde). Wir haben 3 Arten von Ergebnissen definiert – Berechtigt (bestanden), Nicht berechtigt (nicht bestanden – mit Gründen für dieses Ergebnis) und Nicht möglich zu bewerten (Daten fehlten).

Um eine bessere Vorstellung zu bekommen, sehen Sie sich das JSON für ein Produkt (Konsumkredite) an:

Und Definitionen von Ergebnissen in DecisionRules:

Für den Komfort des Benutzers beim Bearbeiten und Vorbereiten der Entscheidungstabelle haben wir die zulässigen Werte für das Ergebnis vordefiniert, und der Benutzer wählt einfach die Option, die am besten zu seinem Ergebnis passt. Unten sehen Sie, wie wir die zulässigen Werte für die Attributberechtigung festgelegt haben.

Die Ergebnisse aus der Entscheidungstabelle auf der Ebene des Produkts und der Bedingungen eignen sich perfekt für analytische Zwecke, aber im Frontend erwartet unser Kunde vereinfachte Ergebnisse nur auf der Ebene des Produkts. (Zum Beispiel: Nicht-zweckgebundener Kredit - Berechtigt). Um dies zu erreichen, haben wir das Scripting Rule-Modul und einfachen Code in JavaScript verwendet. Das aggregierte Ergebnis auf der Produktebene werden wir als API-Antwort verwenden, die vom Frontend ausgeführt wird.

Zur besseren Vorstellung JSON für alle Produkte:

Im Rahmen des Auftrags haben wir 2 Herausforderer (A/B-Tests) unter bestimmten Bedingungen definiert. Wir möchten einen Teil der Bevölkerung zufällig für die Herausforderer auswählen. Die zufällige Auswahl haben wir in der Skriptregel als einfaches JavaScript definiert - Zufallszahl und verbunden mit der Entscheidungstabelle (mit unseren Bedingungen) durch den Regelablauf (SR_RCS_random ist die Skriptregel mit einem Zufallszahl-Ergebnis und DT_RCS_Eligibility ist unsere Entscheidungstabelle mit Bedingungen).

Die Zufallszahl hilft, das Verhältnis zwischen Champion und Herausforderern aufrechtzuerhalten. In unserem Fall möchten wir keine überlappenden Herausforderer haben, aber es hängt von den geschäftlichen Anforderungen ab, wie die Auswahl der Herausforderer definiert wird.

Um die richtige Zeile in der Entscheidungstabelle auszuwählen, haben wir die Spalte Champion mit Bereichen für Champion und Herausforderer hinzugefügt und wir haben Sets für Tests erreicht.

Der Rest des Prozesses bleibt gleich, und das Ergebnis auf Produktebene (Antwort auf API-Aufruf) können wir mit der Champion/Herausforderer-Strategie erweitern, die wir verwendet haben.

Basierend auf dem Beispiel hat das Tool sichtbare Flexibilität und Konnektivität. Die Ausgabestruktur kann basierend auf der Nutzung und der folgenden Verarbeitung verbessert werden und kann alle Details der getroffenen Entscheidung beibehalten. Das Gleiche gilt für die Einrichtung der Entscheidungstabelle, die für die gemeinsame Nutzung durch Geschäftsbenutzer vorbereitet werden kann.

Weitere Details folgen in Kürze

Wir wollten die Verwendung von DecisionRules.io anhand eines realen Beispiels zeigen, in den folgenden und vorherigen Artikeln - Effiziente Genehmigungen von Kreditprodukten im Finanzdienstleistungssektor, Risikobewertung und Preisgestaltung, Richtlinienregeln, Berechnung der Erschwinglichkeit, alternative Implementierung, die bald verfügbar sein werden.