We are bringing a series of articles describing the application of DecisionRules to real-world situations. In this article, we present a case from the financial world.
DecisionRules can be used for solving a wide range of tasks performer by financial institutions and any company which might be an intermediary in financial services, like telco or e-commerce companies. We will focus on how to select clients and evaluate a client‘s potential to get a loan. In this particular example, we will use DecisionRules as an evaluation tool.
Let's assume that you have money and you decide to lend it. The first thing you have on your mind is „I’m lending money, I want it back!“ and it is at this point that you start to create rules for selecting who is the best client for your business.
First of all, you perform the pre-selection. You define the basic rules that cannot be breached, specifying the segment of population not to be considered at all and the segment representing your potential eligibility pool. Such rules are critical, and if you do not set them properly, you will cut down your potential and create higher risks. You need almost ongoing testing. The ability to immediately change your established rules without waiting on deployments is crucial for you.
Second, you assess whether there is a large risk that the client will not pay you back. This is usually done with scoring models, or rules which define the level of probability that the client will not pay you back. Based on the calculated level of risk, you decide if it is productive to maintain such a risk by applying the scoring cut-offs, while at the same time using this assessment as a guide for product pricing and term sustainability.
Third, based on the estimation of the client’s ability to repay (income models or similar), you will decide on the loan amount and payments for that client, and you will also set up the payment capacity.
Combining those 3 decisions, you will use the result to make a potential offer based on the perspective of the risks you are taking on.
That said, it‘s clear that there is no simple way to decide and there is a need to have a sequence of rules, which can be designed in DecisionRules.
In this model situation, we focus on the first step: pre-selection rules - eligibility rules.
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.
For better imagination JSON for all products:
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, particularly how it can be used for client financing decisions. In the next article, we will continue. Stay tuned and read our previous articles.
Thank you for your reading! 🚀
DecisionRules is constantly improving its collection of advanced functions which can be used for custom computation within decision tables and decision trees. In this article, we shall look at a specific and very useful type of functions treating arrays.