Building Business Rule Engine - Designing a no-code tool for banking users to manage lending policies easier
4 mins read
Context
LOS - Loan Origination System is a product which helps banks and NBFCs automate and streamline entire life cycle of an loan including loan servicing, verification, approval, rejection reporting and disbursal.
Collaborators
PMs, Engg
Duration
2 months
What is LOS?
LOS - Loan Origination System is a product which helps banks and NBFCs automate and streamline entire life cycle of an loan including loan servicing, verification, approval, rejection reporting and disbursal.
Context
When a customer requests for a loan, every bank establishes their distinct rules or guidelines on how to evaluate, verify, and sanction the loan based on- the applicant’s eligibility. These instructions, known as lending policies, aid in decision-making.
Generally, these policies are very high in number. To understand the complexity, a bank may have to define a policy using 1000+ parameters to decide if an applicant is eligible for an loan or not.
Current Pain point
Currently, each of these policy is entered into our system through back-end coding. Picture yourself as a business individual needing to alter a policy. You would first have to alter numerous physical documents before sending them to developers then enduring a wait time of 2-3 weeks for the policy to be implemented. This inevitably complicates the process for both businesspeople and developers.
As a business, we wanted to improve this poor experience by - reducing the waiting time, remove the long process by streamlining, giving users more control over the management of policies.
Creating, managing rules are common use cases in the IT industry, so product team decided that building a BRE rule was a obvious solution for this problem.
What exactly is BRE tool?
BRE is a No-code tool which allow non-programmers change the business logic(rules) for their loan processing. This feature allow users to independently create, customise, and manage policies streamlining decision-making processes.
There are already existing BRE tools in the market. But for purposes like more flexibility, customisation and seamless integration with our product we decided to built our own BRE tool as a feature.
My role
Since problem space and what to build had already been defined, my responsibility was to take this groundwork and translate it into a user-friendly feature by visualising the solutions that align with both our product goals and user needs.
Constraints
Once I got the brief from the PM, I wanted to understand the problem space and users more such as - how they are currently making changes, what challenges are they facing, what are their needs, and also see if I can find any opportunities gaps.
However I had a constraint of not having access to direct users. So I had to rely on PM for any data and user insights. Ideally, I would have liked to get firsthand perspective from users through user interviews - which might have helped me uncover new insights.
Brainstorming with PM
The product manager on the team and I created a user flows for the list of functionalities that the PM has already defined. My first job was to map the flow so that it is clear and logical for the user to navigate.
The first step for creating a policy is create a rule. These rules are a set of predefined conditions that help you arrive at a decision. Basically Yes/No condition.
Simple eg, ‘if CIBIL score > 600, then max loan value = ₹3,00,000’, or ‘if applicant belongs to medium-risk category, then interest rate should not exceed 20%’.
Rule = condition (if) + action (then)
Most of these rules are based on if else statements. Since I had engineering background, I was able to understand this quickly and visualise the interface better.
Market research & Takeaway:
Big question was how do we convert this to simpler UI? I started looking for references point and analysed 3 major products.
I analysed the 3 primary existing BRE tools in the market to understand what functionalities they offer, their approach to design, and to identify any opportunities areas. It was evident that each BRE tool solves a very unique business problem and needs. Therefore, I cannot take any direct inspiration. So largely I took inspiration on the UI, and interaction design.
Most of the products lack good UX
Some are complex to understand and there are lot scope for improvements.
There are primarily 3 approaches I found. Creating rules in Table format, Tree structure, Field UI.
Concepts
Once I got the idea for direction, I started exploring designing by sketching rough ideas. I shared 3 ideas to PM and decided on one. We went through multiple iterations, refining the interface on how to simplify even when rules are higher and complex.
Final outcome
Creation of a first condition. Select parent IF condition and add new conditions
Click on Add condition will generate a single condition will required fields. Parameters, Operator and deciding value inputs are to be inputted by users.
Similarly Add new sub clock will enable users to create nested condition. Adding text indentation, separating the blocks & conditions with different shades of greys will help users scan it easily even when the rule becomes large.
As a final step, once the conditions are defined, ACTION part of the rule has to be defined to let the system know what to do if the rule passes.
View of how a complex policy looks
Full Prototype
Managing policies, templates and others
Creating a rule is one primary aspect of the Business Rules Engine (BRE) functionality. I also worked on designing additional workflows that helps banks to:
Create, add and customise their own rule templates,
Formulate and implement bespoke policies,
Access and review version history,
Enhance decision-making processes through tailored automation.
Creating a policy
Upon coming into the landing page, the page has two primary tabs - policies and rule templates. The policy tab will show a list of policies that are active and inactive. This page helps you manage different policies for different products, originators, asset class etc.
Creating draft and templates
Once the policy is created, the user has to add rules - either the user can create new rule or add from existing templates that is already saved. This page lets you view the active rules.
Draft is where you create, add, remove policies and make them active to be reflected on the applications.
Scheduling policy to be active
If anyone from bank wants to change policy, a draft should be created and later activated.
Through this feature we have solved for banking managers pain points where previously they had to rely on developers to write the code and wait for them to deploy. Now they can make changes and activate themselves simplifying the process much better.
Version History
Version history allows users to track what changes were made, when they were made, and who made them. This is crucial for understanding the evolution of a document, a piece of code, or any other type of content.
In regulated industry like fintech, maintaining a record of changes is often a legal requirement.
Learnings
This project was especially challenging and rewarding at the same time as this is one feature where I took full ownership and responsibilities from start to end.
While it was challenging initially, but with right feedbacks and guidance from the team, I was able to handoff this feature successfully.
Scope to improve
While creation of a rule is simplified, we don't have a functionality for users to test and see whether their policy is behaving as expected or not. This is very crucial because there is a small margin of error particularly in a domain fintech where money is involved.
While we tried to achieve the draft flow simpler, there was mixed feedbacks during internal testing as there was a confusion on why it has been separated into separate pages.
We are planning to address these issues after the first release is done.