AI in lending is mostly being bolted onto the wrong architecture

Every lender in India is doing something with AI right now. Fraud models. Eligibility automation. Collections prioritisation. Voice agents for first-touch underwriting. The decks are full of it.

A smaller number are getting real value from it. The difference isn't the model. It's what sits underneath.

The model isn't the bottleneck

Most lending AI conversations start with the wrong question. Which model? Which vendor? Build or buy? Open-source or hosted?

These are real questions, but they're downstream. The upstream question is whether your lending stack can actually feed a model the data it needs, at the latency it needs, and act on the output without a human re-keying it into a different system.

For a lot of lenders, the honest answer is no. Not because the engineering team isn't capable, but because the LOS or LMS underneath was designed in a world where decisions happened in batches, integrations were point-to-point, and every product change went out on a quarterly release train.

You can build a beautiful intra-day risk model on top of a system that produces an end-of-day data extract. It just won't do anything useful intra-day.

Three places the architecture decides whether AI works

1. Event availability. AI in lending is mostly reactive — a model fires when something changes. A drawdown happens. A bureau pull updates. A market price moves. An EMI bounces. If your core publishes those as events on a stream, models consume them in real time. If your core only writes them to a database that gets ETLed overnight, you have batch AI no matter what you bought.

2. Decision surface. A model output is a number. Getting that number into a lending workflow — to auto-approve, auto-decline, route to a credit officer, trigger a margin call, change a limit — requires the BRE, the workflow engine, and the LMS to accept it and act. Lenders running monolithic cores often end up with a model producing scores that get exported to a CSV and reviewed by an analyst the next morning. The model works. The system around it doesn't.

3. Release velocity. Models drift. Underwriting policy changes. Regulators publish new norms. If pushing a new rule, new policy, or new scorecard into production takes ten weeks because every change requires a full regression of the core, the AI roadmap will move at the speed of the legacy release train. Not at the speed of the model.

What the better-architected lenders are doing differently

The lenders getting real returns from AI aren't running better models. They're running their lending stack in a way that lets the model matter.

Concretely: their LOS, LMS, risk, and collateral systems are decomposed into independent components, with clean APIs and event streams between them. New models plug in as services. Policy changes ship without retesting the entire platform. Data flows from the operational system to the analytics layer in near real time, not overnight. And the system stays up while it processes — no daily downtime window during which models, dashboards, and decisions all go cold.

This is the composable, coreless architecture conversation that's been ongoing in BFSI infrastructure for the last few years. It used to be an aesthetic preference. AI is now making it an operational one.

A blunt test

Before the next AI vendor pitch, three questions worth running internally:

• Can our core publish a state change as an event within seconds, or only as a row in a database that gets read tomorrow?
• If a model produces a score, can the next workflow step act on it without a human in the loop?
• How long does it take to push a new rule or scorecard into production?

If the answers are "no", "no", and "weeks", the AI conversation is happening at the wrong layer. Fix the lending stack first. The models will work when they have something to work with.

The author works in lending infrastructure at SwiffyLabs, which builds composable lending and payments systems for banks, NBFCs, and fintechs.