Business Rule Engine(No-code tool) for banking users
Contribution:
End-to-End
Team:
Me, Senior designer, 2 PMs
Duration:
1.5 months
Hard-coded lending rules were slowing down loan decisions
Lending policies change frequently, but in our Loan Origination System (LOS), every policy update required backend code changes. As lending rules became more complex, even small changes took weeks of engineering effort. This delayed loan sanctions for banks, reduced operational agility, and limited how quickly new products could be launched.
Overview:
To help banks and NBFCs manage complex lending policies without engineering dependency, we designed a no-code Business Rule Engine (BRE) within the Loan Origination System. The goal was to let non-technical users independently create, modify, and manage loan eligibility rules — reducing turnaround time, improving operational agility, and accelerating loan approvals.
My role:
I led the design of the Rule Engine builder while working closely with senior designer, engineering team to balance usability with technical feasibility. I focussed on:
Flexibility to handle complex lending logic
Scalability for future use cases
Ease of use for non-technical users
Outcome
The existing workflow: Policy updates depended on JSON and engineers
Today, policy rules are written and updated in JSON format.
This approach:
Requires technical knowledge
Limits access to a small set of client users
Still needs support and engineering help for complex changes
As a result, even routine updates involved back-and-forth with support teams, slowing down decision-making and increasing operational overhead.
Design goals:
Our primary goals were to:
Enable users to create and modify rules without engineering support
Redesign the policy management flow to handle growing complexity
Reduce time taken to roll out policy changes
Target users:
The primary users are Admin and Operational users from banks and NBFCs. They understand lending policies deeply but have little to no coding knowledge.
To go deeper, I mapped real implementation flows across 7+ client setups, involving the product manager, senior product designer, and myself. This helped us identify:
Common patterns across clients
Opportunities to design for future scalability, not just current use cases
This reframed the problem from “fixing a rule builder” to designing a foundation that could scale into a modular flow engine.
We studied multiple Business Rule Engine products to understand: Core functionality, Design patterns, Strengths and limitations
Most products looked different visually but were fundamentally similar. They followed the same underlying rule syntax, with minor UI variations.
While researching, we came across NECTED, a no-code rule engine used across domains like finance, insurance, and healthcare.
This sparked a broader vision:
A standalone rule engine
Workflow management
Integrations and entity management
A product that could potentially be sold independently
However, this was a long-term investment. We scoped the current release to solve immediate LOS needs while keeping this broader vision on the roadmap.
UI approach: Choosing scalability over visual novelty
One key question was:
How should users build and read rules?
We had two choices of block based UI and flow based UI. After multiple discussions, we opted for a text-based rule-building approach. This format proved more readable, easier to review and debug, and significantly more scalable as rule complexity increased. While chart-based or flow UIs can appear intuitive for simple cases, they tend to break down quickly in real-world lending scenarios.
Needing alignment quickly, without a mature design system
We knew this system needed careful design to scale across products. However:
Timelines were tight
Engineering needed something concrete to evaluate feasibility
We didn’t yet have a mature design system for quick high-fidelity prototyping
"We needed a fast way to align across teams."
Using AI tools to prototype faster and unblock teams
To move quickly, I used Vercel to create a functional prototype of the rule builder. This helped us:
Get early alignment with product and engineering
Validate technical feasibility
Visualize the UI in logical blocks
The prototype was strong enough that many of its ideas carried forward into the final design.
Final Designs
A single policy can contain up to 200 rules, so browsing and editing needed to be effortless. I designed interface allowing users to:
Quickly scan and switch between rules
Always know which rule they are editing
Reduce cognitive load while working with large policies
Introducing a new creation method without breaking existing habits
While we introduced a simpler block-based rule builder, we intentionally preserved the existing JSON editor.
This allowed users to:
Continue using what they’re comfortable with
Transition gradually to the new system
Avoid resistance caused by forced change
The goal was adoption through flexibility, not enforcement.
During a casual lunch discussion, we explored an idea:
What if users could create rules using plain language prompts?
Given that, we already had structured rule types and the system could be trained on existing patterns. This felt achievable.
Coincidentally, our engineering lead had already been exploring this and showed us a working demo the very next day. The output was surprisingly accurate and promising. We decided to treat this as a beta-level exploratory feature.
To prevent the idea from stalling, I quickly created a rough prototype showing how prompt-based rule creation could fit into the existing UI.
Due to its longer development effort, we parked it for a future release - but with clear intent.
Impact: What success looks like after launch
Although the Business Rule Engine is still in development, we defined clear success criteria to measure its effectiveness post-launch.
The primary indicator of success would be a significant reduction in engineering involvement for policy updates, with most rule changes handled directly by client admin users.
We also expect faster turnaround times for policy changes, improved adoption of self-serve rule management, and fewer support tickets related to policy configuration.