Risk-based decision making

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.

What are the key points?

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.

The Use Case

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 parameters

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).

  • Age 18-60
  • Delinquency – 0
  • Bureau score > 500
  • Income source: except for “unemployed”
  • The client has a current account: not needed
  • Client purchase behavior segment: not needed

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)

  • Age 18-65
  • Delinquency < 10
  • Bureau score > 500
  • Income source: except for “unemployed”
  • The client has a current account: not needed
  • Client purchase behavior segment: not needed

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)

  • Age 21-50
  • Delinquency < 5
  • Bureau score > 550
  • Income source: not needed
  • The client has a current account: Yes
  • Client purchase behavior segment: “Fluent shopper” 

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)

  • Age 15-55
  • Delinquency < 7
  • Bureau score > 450
  • Income source: not needed
  • The client has a current account: Yes
  • Client purchase behavior segment: not in “Sleeping” 

Pilot strategies

First testing strategy 15%:

  • Align all delinquency < 3

Second testing strategy 15%:

  • Change Age for credit cards 18-55

Expected output

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. 

Chart: The basic model of communication

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.

Input JSON in DecisionRules.io - Decision Table

The output will be provided for each product via API response, as seen in the picture below.

Output JSON in DecisionRules.io - Decision Table
Why not to try it yourself?

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.

Rule setting in DecisionRules: Decision Table for non purpose loan

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:

Rule results in DecisionRules for non-purposed loan

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.

Allowed values in DecisionRules: Result 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).

Rule Flow from DecisionRules

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.

Examples how to set up random number

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.

DecisionTable with champion/challenger from DecisionRules

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! 🚀

More reading