Table of contents
The risk and credit decisioning team at a lending organisation grapples with numerous decisions everyday such as ‘Should this loan application be approved?’, ‘How much interest should be charged?’, or ‘Should a loan application be reserved for further manual assessment?’ There can be as many answers to these questions as there are employees in your organisation, which is why there are lending policies to govern everyday decision-making. These policies are represented and defined by business rules. But, what are these rules and what do they look like?
What are business rules?
Business rules are a set of predefined conditions that help draw inferences to arrive at a decision. For eg, ‘if bureau score > 600, then max loan value = ₹3,00,000’, or ‘if applicant belongs to medium-risk category, then interest rate should not exceed 20%’. As you can see, a rule sets conditions that determine actions.
[Rule = condition (if) + action (then)]
A series of such actions make up a lending process or a workflow. But who or what is taking all these rule-based actions? Humans? Computers?
Well, now that the digital era is upon us, a loan application should ideally take three minutes to apply, one minute to approve, and zero human intervention. But this can only be possible if decisioning systems are automated. Such automated systems have an all-encompassing name — business rules engine (BRE).
BRE — what is it and how does it work?
A BRE is a piece of software that interacts with databases to access business rules set by the lender and execute them whenever the application requires them to.
Now this needs logical reasoning — which has for long been thought as uniquely human. Since the dawn of computing, things have changed rather drastically. Today, it’s possible to mechanise logic, which is what a BRE does. A systematic method of reasoning is applied to large amounts of data in accordance with strict principles of validity to make inferences for everyday decision-making. Perplexed? Let’s break it down.
See the basic ‘lending process model’ depicted in the figure below.
The whole end-to-end process goes through key decision points — whether it is determining the applicant’s eligibility or deciding the loan value, interest, and tenure. The rule engine assesses millions of data points against these predefined conditions (rules) and takes an action based on whether the condition is satisfied or not. The workflow is triggered based on inferences drawn at these decision points. Basically, business rules (the cause) trigger a set of tasks that cumulate into a process (the effect) to produce a specific outcome (application approved / rejected).
To put things in perspective, an automated decisioning system enabled by FinBox, for instance, processes millions of data points — from bureau data to alternative data — and assesses them based on 5000+ parameters to aid in deciding if an applicant is eligible for a loan or not.
Why do you need a bespoke BRE?
A standard BRE offers all the benefits that automation does such as speed, accuracy, cost reduction and heightened performance. In comparison to a manual paper-based process, a standard BRE may seem like God-given manna. However, one major limitation is that it can present a certain measure of process rigidity that can get lenders vexed.
If there’s one thing that lenders consistently need, it’s the ability to change or tweak business rules — whether it is to reduce delinquency, reach out to new borrower segments, optimise the lending funnel, fine-tune their risk-based pricing strategy, or to adapt to macroeconomic/regulatory changes.
The need for flexible rules is rather conspicuous. But what usually happens is that business rules get buried in application code. If you have to add, delete, or edit a rule, you are forever fettered to developers who may have to comb through the entire programme code. This is time-consuming and can take a minimum of 3-4 weeks.
Such process rigidity can be catastrophic for a business — especially a lending business. But process rigidity has little to do with the process itself — it has more to do with the underlying business rules. This is why the architecture of your business rules environment must be seen as paramount.
The key to achieving flexibility lies in treating business rules distinctly from business processes.
A lender should be able to define, manage, and deploy business rules and decision logic without having to rewrite the source code — that is, consider business rules as a resource in itself. To be able to do this, the very approach to building a BRE should realign with the principles of design thinking.
To delve deeper into this concept, watch out for Part II of our three-part series on Business Rules Engine.