Following up on the series of articles describing the application of DecisionRules in financial sector. We will focus on the elibitility filters in Lending process.
.png)
The initial step in this process is to check whether the application is eligible for approval in the first place, based on a few very clear criteria – e.g., lenders wouldn’t offer credit to children, so Age is a very important criterion used throughout the consumer credit industry.
This check is typically done at the very start of the process to avoid wasting resources on processing an application which does not meet basic criteria, e.g., using application and internal data for these filters ensures costly bureau calls are avoided.
The use of DecisionRules to implement and manage these eligibility filters is covered in this article and covers details about usage of DecisionRules, configuring DecisionRules for usage with multiple products, and introducing a champion-challenger testing strategy.
In our case, the institution is considering 4 different sets-ups for the products and would like to run 1 standard strategy and 2 testing scenarios. They would like to pre-filter clients based on product and performance criteria.
Testing scenarios to be reached by random selection. In the end the 70% of clients will be decided based on Standard strategy, 15% by 1st testing strategy and 15% by 2nd testing strategy.
Standard strategy 70%:
Product 1: Non-purpose loan (Loan provided to the client, where the purpose is not restricted to a particular reason--contractually there can be some disbursement usage restriction).
Product 2: Purpose loan (Loan provided to the client where the purpose is specific-- does not need to have a particular contracted purpose and does not need to have a particular collateral)
Product 3: Credit card (Limit is provided to the client; a credit card or any other payment tool is issued to enable the client to pay for items or do cash withdrawals)
Product 4: Overdraft on Current account (Limit provided to the client on the account--usually a current account, can possibly be on a wallet account--to allow the client to withdraw below a zero balance)
First testing strategy 15%:
Second testing strategy 15%:
Finally you should know the rule results and rationale, and the reasons should be defined for the client and for internal purposes separately.
Starting from the basic flow of how the decision on clients' eligibility is done.
On the front end (which is usually mobile application, web form, institution internal system, third party system or third-party application) or on the back end (batch request from database) the required inputs are collected (like Age, Income source, Finance purpose, etc.), and can be enhanced by internal data (based on a back-end call, like Internal delinquency, Current account, Segmentation, etc.) and external data (based on back-end call and application data collection, like Bureau score, External delinquency, etc.). All of this information serves as Input for the DecisionRules. We send the Input data to DecisionRules through API call, and DecisionRules executes the pre-defined rules and returns the results on Client Eligibility for products (loans) to the Front End.
How is DecisionRules set up? First, we define the Input and Output.
As Input, we need the attributes for our rules (pictured below). If you examine the sample case, you will find out that some of the products can be decided without some of the attributes. The interface will be designed for all of the attributes to be used, but not all of them are required in every case.
The output will be provided for each product via API response, as seen in the picture below.
Having defined Input and Output, we can now step into the rules definition. All eligibility conditions can be prepared within one rule set of the Decision Table in DecisionRules.io, where each row then represents one condition definition for one product.
The advantage of such a setup is having one place for rule management. Based on application filters or the possibility to export/import rules into XLSx / JSON / CSV, you can easily compare the setup of product to product, rule to rule.
The Decision Table output is on the level of product and condition. For example, non-purpose loans will have separate results (result rows) for Age, Delinquency, Bureau score, Income source (JSON example below). Each row will have a defined result (Eligibility) and reasoning if needed (Reason for Result internal, Reason for Result Client). We have defined 3 types of results – Eligible (passed), Non-Eligible (not passed – with reasons for this result), and Not Possible to Evaluate (data was missing).
To get a better idea, see the JSON for one product (non-purpose loans):
And definitions of Results in DecisionRules:
For the user's comfort while editing and preparing the Decision Table, we pre-defined the allowed values for the result and the user will simply select the option best suited for their result. You can see below how we specified the allowed values for attribute eligibility.
Results from the Decision table on the level of product and condition perfectly fit for analytical purposes but on the Front end, our client expects simplified results only on the level of product. (For example Non-Purposed Loan - Eligible). To do so, we used the Scripting Rule module and simple code in JavaScript. The aggregated result on the product level we will use as the API call response performed from the front-end.
For better imagination JSON for all products:
As part of the assignment, we have defined 2 challengers (A/B tests) on conditions. We would like to select part of the population for challengers randomly. We defined the random selection in Scripting Rule as simple JavaScript - random number and connected to the Decision Table (with our conditions) through the Rule flow (SR_RCS_random is the Scripting rule with a random number result and DT_RCS_Eligibility is our Decision Table with conditions).
Random number helps to keep proportion between champion and challengers. In our case we would like to have not overlapping challengers, but it depends on business needs how to define challengers selection.
To select the proper row in the decision table, we added thecolumn Champion with ranges on champion and challengers and we reached out sets for testing.
The rest of the process remains the same, and the result on the product level (response on API call) we can expand with the champion/challenger strategy that we used.
Based on the sample case, the tool has visible flexibility and connectivity. The output structure can be enhanced based on the usage and processing which follows, and can keep all of the details of the decision made. The same goes for the decision table set-up, which can be prepared for common use by business users.
We wanted to show the use of DecisionRules.io using a real-world example, in the following and previous articles - Efficient Lending Product Approvals in Financial Services, Scoring Risk grading and Pricing, Policy Rules, Affordability calculation, Alternative Implementation, which are coming soon.
