For years, business rule engines in lending looked and behaved like old-school desktop software. 

You bought a licence and IT installed it on a Windows machine. A small group of people used that application to design and run policies. That’s a classic thick client. 

It’s not very different from buying a Photoshop licence in 2010 and installing it for each designer. If someone got a new laptop, IT had to set it up again. If another team needed access, you would repeat the whole process. 

That’s how most early BREs were built. 

What a thick client looks like in day-to-day lending 
In a thick-client setup, a BRE is a programme installed on your system. The core engine runs inside your environment, but a lot of what it does is locked away from everyday users. 

A typical setup looks like this: 

• The software sits on a limited number of machines. 

• Only a few ‘power users’ can log in and change policies. 

• When the policy is ready, it’s compiled or exported as a file. 

• That file is consumed by other systems or partners to actually make the decision. 

  
  

You see the result: approve, reject, maybe a reason code.  

What you don’t see is the full path that led there. Which rule fired first? Which condition failed? What exact combination of variables pushed the application into ‘approve’ or ‘reject’? 

With a thick client, that detail often lives inside the engine,--  not in a place that risk, product, or compliance teams can easily access. You get working decisions, but you don’t always get clarity – and that’s an audit risk. 

Now let’s add the operational hurdles to this:

• New joiner? IT has to install the software. 

• New laptop? Install again. 

• Multiple locations or teams? Repeat at scale. 

It works, but it’s heavy. And it doesn’t match how teams expect software to behave today. 

Thin clients arrived. But often only in someone else’s cloud. 
As software moved to the browser, decision engines followed. Instead of installing a programme on each laptop, teams started accessing the BRE through a URL. 

That’s the thin-client model: 

• You open a browser. 

• You log in. 

• The heavy lifting happens on the server, not on your machine. 

This solved a lot of practical issues: 

• No more installations on every system 

• Easier to roll out across teams and locations 

• Faster onboarding for new users 

But there was a new catch: many of these thin-client tools were only offered as multi-tenant cloud products, hosted by the vendor. 

For a lender, that’s not always ideal. Many still want the engine: 

• Hosted on their own premise or in their own controlled environment 

• Close to their internal systems and data 

• Aligned with their security and regulatory needs 

  
  

So, you end up with an uncomfortable choice: either a thick client that you can host on-premises but is hard to scale and lacks transparency, or a thin client that’s easier to use but can’t be deployed on-premise. And neither is quite right. 

 
Sentinel AI’s architecture: thin client, on-prem, and practical 
Sentinel  AI is built in a way that lets you avoid that trade-off. It's a thin client you access through a browser, but it can still be deployed on your own infrastructure. 

What that really means: 

• No local installations on individual laptops 

• New users get access through permissions, not installs 

• Teams in risk, product, and operations can work off the same environment 

• Your IT team can keep the engine inside your network and under your control 

You get the usability of a web app without giving up the option  of hosting it on-premise. 

Moving from ‘we got a decision’ to ‘we know why and how the decision was made’. 
There is another angle to this: visibility. In an older, application-based setup, once a policy is packaged up and pushed downstream, you mainly see: 

• The decision (approve/reject) 

• A generic reason code 

The underlying logic is much harder to inspect in a structured, consistent way. With Sentinel AI, decisions are easier to trace: 

• You can see which rules were evaluated 

• You can see which ones passed, which ones failed 

• You can understand why a specific application was approved or declined 

That helps when: 

• Compliance asks you to explain a group of decisions 

• Risk wants to dig into why a certain segment underperforms 

• Product wants to fine-tune rules based on behaviour 

• 
  

Instead of poking at a black box, teams work with a system where decisions can be explained and reviewed. 

Why this matters now 
Lenders today want a browser-based experience their teams will actually use, the option to deploy on-premise when required, and clear visibility into how decisions are made — and newer data protection frameworks like India’s DPDP only reinforce that need for control, audit trails, and explainability.  
 
Thick clients belong to an earlier phase of software, and cloud-only thin clients don’t always meet regulatory or on-premise requirements. Sentinel AI is designed to bridge that gap and keep lenders on the right side of these regulations: a thin client that can be deployed on-prem, with decision flows you can clearly see, trace, and audit when it matters.