How to evaluate Credit Bureau Data using DecisionRules Part I

Importance of Credit Bureau Data

Credit Bureaus can provide you with valuable information about clients' current credit burden, their past credit history and payment morale, application history, and often also history of payment of energy or telco bills.

Credit Bureaus often provide you also with some form of Credit Bureau Score that “aggregates” clients' credit bureau information into a simple rating. This type of a rating is developed on data from the whole market, that may not be fully relevant to your clients' profile. As a result, it does not enable you to make the best credit decisions, utilize your credit potential fully and distinguish you from other lending companies.

Creating your own aggregation and evaluation of Credit Bureau Data is advantageous, as resulting attributes can be used not only in eligibility criteria and affordability calculations but also in your own scoring models. Examples of useful Credit Bureau aggregated parameters are listed below. In our sample DecisionRules flow, we show how to calculate some of them.

Credit History

Current indicators quantify the current credit burden which is calculated either for each type of loan separately or as a total:

Total Monthly Installment - an important input to the affordability calculation. It is pretty clear how to calculate it for loans (possibly you may want to exclude loans with just a few remaining payments), but you should also include utilized credit cards or overdraft in some way.
Remaining Principal - an input into your assessment of the total amount you are willing to provide.
Number and Structure of Loans - many small loans indicate something different than one or two big loans - potentially input to a scoring model.
Number of Financial Institutions - is the client just not “loyal” to one lender, price sensitive, or not being able to get a consequent loan from the same lender for some reason?
Current Past Due Amount, Number of Installments and/or Number of Loans - important inputs into your eligibility criteria, potentially being “softened” by shadow limits on overdue amount or number of past due days.

Historical indicators describe clients' repayment history (you may be interested in some relevant data period such as one or two years, but some “ever” indicators may be useful as well):

Maximum Delinquency status (or days) or Maximum Overdue Amount - show basically how “deep” problems with repayment the client had.
Ratio of Overdue Payments - together with low Maximum Delinquency Status can reveal a “lazy payer”, but also a person living just on the edge of insolvency.
Lending Dynamics - is the sum of monthly installment payments (or total exposure) decreasing or increasing in time? Is the client getting into a debt trap, or on a safe side?

Application History

Historical indicators encompass the frequency, structure, and outcomes of loan applications within a relevant period.

Number of Loan Applications - a large number serves as a type of warning indicator.
Ratio of Declined Applications - high ratio of declined applications indicates that other lenders consider this person as risky, while a low number can indicate a person that is just trying to get the best price, as well as a person that is trying to find a loophole in the system.

Invoice Payment History

Current Indicators include the client's living expenses, such as energy and telco bills.

Total Amount - you should include it in your affordability calculation.
Number of Invoices - does the client pay bills just for one household, or potentially more?

Historical indicators consider whether the client has ever failed to pay their bills, and if so, the extent of these failures, typically assessed within a relevant period or over their entire payment history.

Overdue Frequency - how often does this happen.
Maximum Overdue Amount - how big was the biggest problem.
Maximum Delinquency Status (Days) - how quickly was the client able to settle the overdue amount.

Evaluation of Credit Bureau Data with DecisionRules

Credit Bureau Data usually arrives in a “raw” form that is not directly suitable for usage in decision making. It needs to be precalculated and transformed to summary attributes listed above. This calculation is usually done using parameters which depend on attributes such as type of customer, known internal history, etc., therefore, it is advantageous to perform these calculations inside DecisionRules, to use its benefits in such parametrization.

Note: for retrieving external data from Credit Bureaus you can use our HTTP functions.

There are many different ways to design this task, ranging from solving everything in one large scripting rule to using a decomposed decision flow-based structure for better readability and maintenance. In this article, we will show an example of the latter approach - a design that features a clear structure of decision flows, trees and tables. This approach utilizes array functions to process sets of Credit Bureau records and calculate summary attributes based on them. This article will outline the structure of the flow, while the following article will provide details about its data structure and the calculation of the outputs.

Note: for real use, you need to adjust this design to the exact data structure of Credit Bureau Data and add handling of missing data values (if such a situation can occur).

Structure of the main flow

The main flow is split into the following parts:

CalculationSetup - this is the place where you set the parameters for the calculation based on whatever you need (typically client segment)
LoansProcessing - a rule flow for calculation loan based information
ApplicationsProcessing - a rule flow for calculation application based information
InvoicesProcessing - a rule flow for calculation invoice based information

Calculation flows

Each calculation flow processes calculation of the desired outputs for the corresponding Credit Bureau Data domain (loans, applications, invoices). For demonstration purposes, we have intentionally fragmented the flows to make the purpose of each object clear and straightforward. In a real implementation, you can streamline the flows by combining filters or even merging filters with calculations. While this approach reduces the number of flows, it increases the complexity of the individual objects within them.

Loan calculation flow

In a nutshell, we perform the following:

filter loan records by type of loan (Loans, Cards, Overdrafts)
calculation of actual data
- filter loan records by status (Open)
- filter loan records by individual types for calculation on loan type level (ie. Loans for personal loans calculation)
- calculate the summary attributes
calculation of historical data
- filter the loans by age (based on historicalDataPeriod parameter)
- calculate the summary attributes
calculation of repayment history
- flatten repayment history details of different loan records into one array
- calculate the summary attributes based on historical data period
in the end, we join together the results of actual and historical calculation to calculate “delta” attributes

Applications calculation flow

This is a very simple flow, in which we perform:

filtering application records by type of loan (to select only those loan types that are relevant for the calculations)
filtering application records by age (based on applicationsHistoryMonths parameter) to consider only recent applications
calculation of summary attributes

Invoices calculation flow

Again, a simple flow containing:

for invoices from last month: filter of current invoices + calculation
for invoices from parameterized history: filter of historical invoices + calculation

Summary

In this article, we have emphasized the importance of Credit Bureau Data for credit decisioning and shown an outline of a decision flow design that can handle evaluation of such data. In the following article, we will go into a bigger detail, showing the exact sample data structure, calculation setup and the calculation itself.