Building Business Rule Engine(No-code tool) for banking users to manage lending policies easier
4 mins read
Contribution:
End-to-End
Team:
Senior designer, 2 PMs, Engineers
Duration:
2 months
Context
This case study outlines my process for building a Business Rule Engine - a no-code tool for banking users to manage lending policies.
Context
LOS - Loan Origination System is one of our product which is being used by banks and NBFCs to manage entire life cycle of an customer loans.
When a customer requests for a loan, every bank establishes their rules or guidelines on how to evaluate, verify, and sanction the loan based on- the applicant’s eligibility. These lending policies helps in deciding if a customer is eligible for a loan or not.
Current Pain point
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.
Currently, each of these policy is configured into our system through back-end coding. But banks might want to change their policy due to various factors. Our current process is complicated which involves making changes in documents and sending it to developer and wait 2-3 weeks to get it implemented. This inevitably delays sanction of customer loans.
To solve this, product team decided to build a BRE - a no-code 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.
BRE tool will reduce the waiting time, remove the long process by streamlining, giving users more control over the management of policies.
My role
Since the 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.
Limiting factors
After the problem brief, I wanted to understand the problem space and users more deeper. 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.
Creating user flows for planned features
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.
Brainstorming flows for screens
Big question was how do we convert this to simpler UI?
I realised this is more UI heavy solution which requires understanding patterns in existing tools in the market.
I analysed multiple tools on 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/domain problem and user needs. Therefore, I cannot take any direct inspiration on. So largely I took inspiration on the UI, and interaction design.
Sketching Concepts
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 simple Yes/No condition based on if else condition. Rule = condition (if) + action (then).
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%’.
Once I got the idea for a visual 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.
Final outcome
Divided the UI into two layout, where user on left side user have context of what the rule is and the right side, the rules are created.
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.
Things to improve
Upon creation, right now we don't have a functionality for users to test the policies. This is very crucial because a small change could cause large errors. We had to reduce the scope because of time limitations.
While we tried to achieve the draft flow simpler, there was mixed feedbacks during internal testing. Users felt it was unintuitive.
Scope reduction
Due to changes in the priority, creation of policy through UI was deprioritised and users are enabled to upload policies through excel format.