How to use Decision Rules for Lending in Financial Services

In this article, we will showcase the use of DecisionRules in a financial services environment, more specifically in the approval process for applications for lending products. Unlike in the sale of consumer goods, when customers want to “buy” a credit product they need to be accepted by the institution providing the funds – the approval process is made up of a series of go/no-go decisions based on the perceived level of risk of the customer, suitability of product, and pricing (commensurate with level of risk).

In this article, we will showcase the use of DecisionRules in a financial services environment, more specifically in the approval process for applications for lending products. Unlike in the sale of consumer goods, when customers want to “buy” a credit product they need to be accepted by the institution providing the funds – the approval process is made up of a series of go/no-go decisions based on the perceived level of risk of the customer, suitability of product, and pricing (commensurate with level of risk).

At a high level, the credit approval process can be described using the structure below.

  1. Eligibility filters
    Filtering performed based on application data and internal data only, before bureau data is retrieved. Applications can be customer-driven or lender-driven (e.g., when offering additional products to existing customers). DecisionRules can easily and efficiently manage this step, resulting in the first go/no-go decision.
  2. Scoring filter
    Run scoring on eligible applications. The orchestration system receives the response from DecisionRules for Step 1 and manages the bureau call(s). The score calculation can be designed in DecisionRules or in a separate scoring service (as it is common to use the Python or similar tools for the score calculations). With the score calculated, DecisionRules can filter out applications based on the score cut-off and assign a risk grade (which can be used for pricing and for defining policy-rule-set for approval).
  3. Pricing
    Based on risk grade and application parameters (e.g., loan amount requested), the pricing for the financial product is set. Based on pricing, key parameters can also be calculated e.g., monthly repayment amount for an instalment loan product, APR, etc. Sample loan application
  4. Policy Rules
    Policy rules establish additional rules, in addition to the risk score, that need to be met for approval. Rules can be simple (e.g., no CCJs on file) or more complex (if risk grade is X or worse, Debt-to-Income ratio needs to be under Y%). There can be a large number of rules, but we will keep this example simple for illustrative purposes.
  5. Affordability
    Final step for automated approval process. Affordability calculations assesses whether customer can afford the new financial commitment based on information available. This is a crucial step to ensure responsible lending and something regulators are very keen to see well demonstrated. Affordability calculation also feeds into the credit limit that can be offered to a customer for different products (per product and aggregated). Output can be approval, decline (possibly indicating an alternative lower amount customer would be able to afford), or referral to manual underwriting (if part of lender’s process); in case of referral, full logic flow can be shown to manual underwriter for assessment focused on key decision-making elements.

End to End rules management

All of those steps can be achieved in the DecisionRules as the one process or as the individual services. DecisionRules have the capability to keep the versions for regulatory and re-applicability requirements.

In addition to the above, before opening the account and making funds available, the lender should also verify the applicant’s income and perform fraud and compliance checks, processes which can also use DecisionRules.

Moreover, the lending process could be designed to cater for champion-challenger testing, to allow variations to the process for different customer acquisition channels, and to allow customers to obtain a non-binding quote before finally submitting their application.

For illustrative purposes, we have designed a sample credit approval process using DecisionRules – the Rule Flow diagram below (Figure 1) provides a high-level picture of the building blocks of this process.

Figure 1: RuleFlow implementing a simplified credit approval process for illustrative purposes. DecisionRules manages the logic of the different steps, illustrating how they would be implemented. The building blocks forming each step will be detailed further below.

Simple Interface management

The inputs and outputs (I/O) used in the process are shown in Figure 2. This process is a simplified version of a real-world example, showing a single-product (instalment loan) use-case. However, DecisionRules is able to manage the logic for different products in an efficient way, using the same structure (the same Decision Tables within this Rule Flow could be expanded to cater for multiple products

Figure 2: Input/Output model used for Rule Flow in Figure 1. Variables can be grouped in categories for greater clarity. Outputs include approval decision, risk grade, and price.

Sample Layout
Illustration 1
Open for integration

In a real-world scenario, DecisionRules would manage the building blocks and some of the integration between them, while an orchestration system would handle the collection of loan application data and other internal data, calls to DecisionRules via Rest API requests, calls to other internal services (e.g., income verification service), and calls to external services (e.g., calls to credit bureau).

Illustration 2
Fully flexible and scalable

It is important to note that this is only one possible example of implementation setup, as DecisionRules is flexible and capable of catering for processes designed in different ways. It is possible to separate processes for each step (with the external orchestration system calling DecisionRules multiple times). As an example, you can handle separate process setups for quoting and providing a final decision, sharing the same building blocks (and thus same rules). Each rule can be called as a separate endpoint or can be combined in multiple chains of rules. In DecisionRules, you can build the solution which best suits your needs, rather than align your needs to the tool.

Illustration 3
Strong compliance, under the control of policy owners

DecisionRules brings the definition and management of the parameters and rules directly under the control of the credit policy owner. The tool is designed to allow rules and decisions to be created without the need for coding, while deployments can be done to the production system simply on click. It is a strongly business-oriented tool with the ability to deploy changes to policy without delay. Robust history and version management, along with configuration of adequate roles, ensure appropriate governance is followed at all times and allow business stakeholders at different levels of seniority to peek into the rules used for lending and understand the logic being used if they so desire.The process of developing the initial design of the logic within DecisionRules and the integration into the business’s software environment is simple. Even if it is typically done by technical specialists, credit policy owners can be closely involved in the design of rules thanks to DecisionRules’s user-friendly interface, and they can later take full control of rule design and setup.

More details comming soon

The different steps in the sample process shown above will be further detailed in the following articles - Eligibility filters, Scoring Risk grading and Pricing, Policy Rules, Affordability calculation, Alternative Implementation, which are coming soon.

More reading