Explore the scoring processes in Financial Services with DecisionRules, orchestrating data enrichment and seamlessly integrating diverse scoring models for efficient risk assessment in lending.
In our previous articles, we have presented the Lending process in Financial Services, processes focused on eligibility criterions, and now we shall follow up with the scoring processes.
Once the initial eligibility filters have been applied, applications typically go through a data enrichment phase, i.e., credit bureau data is retrieved to form a complete picture of the customer’s credit position and past behaviour across different lenders in the market.
Data request is usually done by the orchestration system. The orchestration system begins the process; in the first step the system receives the eligibility assessment from DecisionRules and manages the API call to pull bureau data (from one or more credit bureaus) - data enrichment. After the data is enriched, the orchestration system calls DecisionRules for a full evaluation of the case.
DecisionRules is capable of calling the external API call by REST API to enrich the data through external sources (The external sources are used if the orchestration system is not applicable; a set up using the orchestration system is always preferable.). The API calls from DecisionRules are limited to REST API synchronous calls with a bearer token.
Such setup optimises the costs and time of calculation and DecisionRules plays a key role in the decision to use or not the enhanced (paid) data.
Having retrieved the bureau data, it can be combined with internal and application data through simple rules or chains of rules, so that the lender’s displayed credit score can be calculated. DecisionRules is able to manage the credit score calculation.
The scoring module can be a fully independent part, called as a separate service, and it can be segregated into a different DecisionRules Space with the separation of user roles for managing this module.
DecisionRules can handle the score calculation using a Decision Table (if the score has been obtained through a linear model, for instance), or it can handle more complex model types through the use of a chain of rules, Scripting Rules (where the scorecard implementation can be coded using JavaScript) or working in cooperation with f.e. Python (using SDK).
In the sample process shown here, we have considered a simple implementation for ease of visualisation, with the score calculation done within a Rule Flow – this option is very flexible, making it easy to update the score calculation following a recalibration exercise: a business analyst can quickly and easily update the calculations and coefficients, with a clear audit trail, within a well-controlled environment.
First of all, the attribute calculation is defined in the decision table or decision tree. I.e. calculation of income to sales in case of entrepreneurs.
By versioning or chaining different rules, we can achieve the A/B testing structure for new scoring models or coefficients or model variants, as all of them can be available for usage at the same time.
Assigning the score can be simply defined by each attribute with a single decision table.
Selecting the attributes and selection of the final model can be defined in the decision tree.
The calculated score is then used to assign a risk grade and decline applications which are beyond the institution’s risk appetite (i.e., applications with a score beyond a cut-off threshold). The cut-offs set by the institution to decline and assign risk grades to applications can be easily and clearly managed by DecisionRules. In the example below, the cut-offs are set within a Decision Table as DNQ and evaluated in policy rules. Cut-offs can be managed for different purposes, with the setup involving one or multiple Decision Tables – this allows the appropriate management of cut-offs, making the whole history available and enabling re-applicability, as required by regulators.
The risk grade is an output of a specific rule or chain of rules and can be used downstream in the process to e.g., set pricing or feed into the policy rule logic. Risk grades are also critical for monitoring and understanding portfolio performance. Risk grade calculation follows the pricing logic which can be implemented using Decision Rules.
The matrix of the pricing usually reflects multiple dimensions starting from the risk which defines the costs and probability of default, but also the term which defines how long the risk is taken and what is the residual risk, product reflecting the product behaviour. Based on those factors, inputs can be defined as matrix of available pricings limiting the risk and term from the perspective of the client and financial institution f.e.
With this step we have defined risk grades, pricing grades using the DecisionRules.io. We already know that each step can be orchestrated externally or internally, called independently or as a flow of the rules, each step can be reused in multiple flows (e.g. pre-scoring, scoring, offering processes), each rule keeps its version and can be A/B tested, which makes DecisionRules.io a flexible tool for lending processes.
Lending process is a set of decisions which can be strongly automated. We have already pointed out the whole process in our article Efficient Lending Product Approvals in Financial services, preliminary filters for decision making in article How to use Decision Rules for Lending in Financial Services - Eligibility, and we will follow with the details on Policy Rules, Affordability Calculations in our upcoming articles soon.
%20(1).svg){kind=logo}
