Customer risk scoring based on business rules –IBM ODM implementation

The usual business rules are described in the form of if then, while real-life business decisions are much more complex and generally consist of multiple rules, and their complexity is difficult to solve directly through the classical Rete-based rules engine using its reasoning ability to execute multiple if then statements. Need for the design of the rule flow, the establishment of the model, the hierarchical structure of the rule has a holistic design to truly achieve the goal of agile change of the enterprise Operation decision Logic.

This article uses a common customer risk scoring scenario in the financial industry to illustrate how to leverage business rule technology (IBM Odm/jrules) to implement complex decisions.

Customer Risk scoring Requirements

The so-called customer risk scoring, is based on customer information using a specific formula rule algorithm to identify the customer risk level of the score, in the financial industry, a wide range of applications, such as bank credit card applications, personal or corporate loan approval. Automated customer risk scoring improves the timeliness of risk management, ensures consistent scoring decisions, reduces manual intervention, and automates business processes to reduce operational costs. Usually companies want the scoring mechanism can be adjusted according to the situation, including scoring parameters, calculation formula, risk factors and so on. If you implement scoring logic in a way that uses code or a database parameter table, its flexibility is often difficult to meet the user's expectations.

A customer's specific risk scoring needs are as follows:

1. Access rules

-Applicant's age is more than 18 years old, less than 60 years old

-The amount of the application must not exceed 1,000,000

-Applicants must have a legitimate job and not accept applications from unemployed persons

2. Scoring rules

The table below is a subset of the scoring criteria set by the customer's wind control department, and the actual scoring model is certainly far more complex than the example, and some factors have an association between them, and their weights or risk scores may also affect each other.

Risk Factors	Weights	Default Score	value range of risk factors	Risk Factor Score
Age	10%	10	< =25	75
			26-30	30
			31-45	10
			> =46	50
Gender	5%	20	Male	100
			Female	50
Education level	15%	20	High School	80
			Associate degree	50
			Bachelor Degree	20
			Master degree	20
			Doctor degree	50
Employment Type	10%	20	Employed	20
			Self employed	50
Corporate Type	10%	30	TOP Corporations	10
			State owned Corporations	20
			Others	30
Business Nature	5%	20	Investment	80-employed 100-self employed
			Banking	60-employed 100-self employed
			Consultancy	50-employed 100-self employed
			Agriculture	30-employed 50-self employed
			Construction	30-employed 50-self employed
			Education	10-employed 30-self employed
			Others	10-employed 20-self employed
Monthly Income	20%	20	<=5000	80
			5000-10000	40
			10000-40000	20
			>=40000	60
Position in Company	15%	20	Sole Proprietor	80
			Top Management	60
			Manager	40
			Professional	20
			Contractual	50
			Others	10
Months of Employment	10%	20	0-12	100
			12-36	60
			36-60	20
			>=60	10

How is this grading standard coming out? There are usually two basic approaches:

1) According to the experience of the financial institution's wind control business experts, determine the factor and its weight score

2) through the statistical analysis of a large number of historical data, explore the user behavior patterns, which are linked to specific risk factors,

The specific approach is not the focus of this article.

3. Grading rules

According to the risk score of grading, determine the action should be taken for subsequent systems or personnel reference.

score	Risk Level	Action
<=30	Low Risk Customer	Accept
31-50	Medium Risk Customer	Accept
51-80	High Risk Customer	Review
>80	Very High Risk Customer	Reject

Overall, customers want to be flexible to add more access rules, to increase the deletion of risk factors, modify the weight and score of each factor, adjust the grading strategy.

Model design

In Odm/jrules, the rule model consists of two tiers, the execution object model (execution object models) and the business object model, and the XOM design is similar to the Java object Model design.

For the above requirements, we design the following simple object model

Because the risk factors need to be added dynamically, we define the Riskfactor type, which includes attributes such as name, weight, default value, etc., and result uses the list to store the risk elements created by the runtime. Often we define operations in the XOM to describe the more technical logic, such as the Addriskfactor method in result creates the Riskfactor object and joins the list, which avoids exposing unnecessary complexity to the rule plane.

Next, use the rule designer to generate the BOM, the corresponding attributes and actions in the lexical model, and specify application and result as the input and output parameters of the decision service rule set, respectively.

Design and implementation of rules

Rule design generally starts with the rule flow. The rule flow is now a basic component in the rule management system, showing the decision process in a graphical and understandable way, and helping the rule engine to control the rule execution more rationally during the execution period.

One might ask, is the rule engine not able to deduce according to rules and facts? Why do I need to explicitly specify its order of execution? In fact, in the current enterprise application, it is seldom to take full advantage of the derivation ability of the rule engine to make decisions, business decisions are often interpreted, and when the pre-and post-dependencies of the rule business meaning level are obvious, we can use the rule flow to explicitly define their order of execution, which can also help business people/ Developers have a better understanding of the decision-making process, and the rule engine selects only a subset of the rule execution from the performance perspective.

Based on the previous requirements description, we designed the following rule flow to describe the decision flow:

1) The first is the inspection of eligibility, that is, according to user information to filter, if the user does not meet the eligibility requirements, the regular flow will be directly exited

2) The second step is scored using a subflow that contains two steps of definition and scoring.

3) Finally, according to the user risk score classification.

A subset of rules are referenced in each rule task, and when the rule task executes, the rule engine validates that part of the rule using the ruleset input parameters or the fact data in working memory.

Let's look specifically at the design of the rules. According to the requirements of access inspection, eligibility rules mainly check the user data, independent of each other, if the applicant violates any one of the admission rules, the results of the qualified logo will be set to false. Conversely, if no admission rules are triggered, the rule flow will enter the risk assessment shunt, or exit directly.

The root rules for user age are as follows:

We can also arbitrarily add other rules, such as

By default, all eligibility rules will be validated. A common requirement is that as long as one rule is triggered, that means that the customer does not qualify for admission, the rule task exits without the need to execute additional rules, which can be implemented by the exit criteria for the rule task ruleinstance.

Next, in the evaluation of molecular flow, the purpose of the definition task is to instantiate the necessary risk factors before scoring, set the relevant parameters, such as Name,weight, and add the risk elements to the result object.

Note that all the rules in this decision table will be executed by the rule engine, and the condition column in the example is only used as a switch (odm/jrules requires that the decision table must have a conditional column). This parameterized decision table is a common practice in rule design, allowing users to flexibly add new risk elements.

The goal of the next scoring task is to match the risk factor with the user data to determine its score. We first use the initial action of the scoring task to add the risk elements defined in the definition phase to the working momory

In the scoring decision table, we use a predefined variable to bind the corresponding risk factor object in the working memory using a unique name, and the predefined variables and decision tables used by the age score are as follows:

The score for other risk factors can be similar to a decision table definition, such as education level:

We can also use decision tables to represent more complex scoring logic, such as combining multiple user attributes:

After the scoring task finishes executing the rules, use final action to summarize the scoring for each risk factor:

Finally, we make a simple grading based on the risk score results, and still apply the decision table implementation.

Of course, we can combine the other information in the user application, such as the amount, product, etc. to define a more complex personalized grading strategy.

Summarize

The key to implementing complex decisions using business rules technology is:

1) Establish a flexible domain model suitable for rule processing

2) Logical steps to accurately describe decisions with regular flow

3) Reasonable use of rules, exposing/hiding appropriate parameter logic

Note: This article is also published in http://decisionrule.com/zh/2014/07/riskscoring, reproduced please indicate the source.

Customer risk scoring based on business rules –IBM ODM implementation