DEV Community: Praveen Kumar

Bima Sugam is not a one-time integration project. The teams who treated UPI that way are still paying for it.

Praveen Kumar — Mon, 06 Apr 2026 20:02:10 +0000

Bima Sugam is the biggest digital shift Indian insurance has ever seen.

If you haven't heard of it - think UPI, but for insurance. One platform where anyone can compare, buy, manage, and claim any policy from any insurer in the country. No paperwork. No jumping between websites. And because it cuts out the middlemen sitting between insurers and customers, the promise is lower premiums and faster claims for everyone.

IRDAI is driving it. Every insurer has to integrate. Non-compliance is not an option.

When UPI launched, every bank said they were ready. The go-live date told a different story.

I have watched this pattern play out enough times to know it is not random. Every time India rolls out infrastructure that changes how digital products reach people, three types of teams show up. Same three. Every time.

The teams that captured the market

They figured it out early. Not because they had more budget or more people. Because they understood what the change meant for their business before the deadline started feeling close. Architecture decisions got made while others were still in planning mode. Data got in order. They showed up ready.

When go-live hit - partners chose them first. Distribution opened. The ground they captured in that first window took competitors years to recover.

The teams that got there late

They were working on it. Just not ready for it. The final months became a fire drill. Decisions that needed weeks got made in days. What they built under that pressure held up just long enough - and then spent the next year being quietly taken apart and rebuilt properly.

They got there. But they paid for it twice.

The teams that got caught

Not from lack of effort. The gap between what integration looks like on paper and what it looks like under real compliance and partner pressure is bigger than most teams realise until they are already inside it. Audits flagged things. Architecture that cleared internal review broke under pressure nobody had stress-tested for. Expensive to fix. Slow to recover from.

Here is what stings. The teams that ended up in the second and third buckets thought they were in the first one. Right up until go-live made it clear they weren't.

The part nobody tells you about revolutions like UPI

Here is something most post-mortems leave out. UPI did not arrive as a finished, stable integration kit that teams could build to once and then forget about.

It kept changing.

Spec updates. New mandates. API version changes. Compliance requirements that landed after teams had already built to the previous version. The banks that struggled were not always the ones who were slow to start. Some of them started early, built to the spec they had, and then found out mid-flight that the spec had moved.

The teams that came out ahead were not just the ones who integrated first. They were the ones who built in a way that could absorb change. One layer of their architecture could be updated without pulling apart everything underneath it. When NPCI pushed a change, they pushed an update. When others were rebuilding, they were moving forward.

I think Bima Sugam will work the same way. IRDAI has already flagged that the platform will evolve in phases. The spec today is not the spec at full rollout. The teams treating this as a one-time integration project are building for a version of Bima Sugam that will not exist by the time their customers are actually using it.

The ones who will look good on go-live day - and the year after - are building for a platform that keeps moving. Not just for the deadline.

The question worth asking before your next sprint

Not: are we integrated? That question has a clean answer that feels reassuring and misses the point.

The real question is: when Bima Sugam changes next month, how long does it take us to absorb it?

If the answer involves a full re-scoping, a new project plan, and three rounds of sign-offs - that is the risk. Not whether the integration works today but if it holds in future.

The teams in the best position right now are not the ones with the most complete integration. They are the ones whose architecture treats change as a given, not an exception.

On April 29 I am running a free live session for insurance tech and product leaders to work through exactly this - which lane your team is in, and a checklist you can take into your next team meeting to validate it. Spots are limited. Register here

Five reasons why most AI pilots don't make it to production in Indian BFSI

Praveen Kumar — Tue, 31 Mar 2026 12:57:12 +0000

Most technology leaders in Indian BFSI approved the budgets, sat through the demos, and watched the pilots deliver. The numbers were good. The room was pleased.

And somewhere between that room and production, the work stopped moving.

Not because the technology failed. Not because the team lost interest. But because five things were never scoped during the pilot, and all five arrived as surprises after it succeeded.

The data was never ready for production

The pilot ran on clean data. Someone spent weeks preparing it - pulling records, fixing gaps, making it consistent.

Production means live data from a core banking system that has been running for years. Duplicate records. Missing fields. Customer profiles split across systems that were never meant to talk to each other.

Reconciling that data was always going to take time. It just was not on the plan.

That work is still sitting in someone's backlog right now.

The model has not cleared model risk management

Any model that touches a credit decision, a collections workflow, or a fraud flag needs to clear model risk management before it goes anywhere near a real customer.

When the pilot arrives at the MRM review, three things are usually missing.

No way to see if the model in production is behaving the way it did in the pilot. No record of which version is running and when it was last updated. And nothing stopping the model from producing the wrong output when it encounters something it was not trained for.

These are not new requirements. Every regulated institution knows they are coming. They just never get scoped during the pilot because the pilot is focused on proving the model works, not preparing it for production.

The MRM review comes back with gaps. The team that built the pilot has moved on. Nobody owns the list.

That list is sitting in someone's inbox right now.

The model is live but nobody can see what it is doing

Some teams get past MRM. The model goes to production. And then a quieter problem starts.

The model was validated on data from six months ago. Production data has shifted. Customer behaviour has changed. But nobody has a clear view of whether the outputs are still accurate.

No dashboard. No alerts. No record of what the model did when a customer complained.

This is the problem that surfaces at the worst time - when an examiner asks, or when something goes wrong, and nobody in the room can explain what happened.

The teams that avoided this built three things before go-live: a way to watch the model in production, a log of every version and every change, and clear boundaries on what the model is allowed to do. Before something went wrong. Not after.

The integration queue is longer than the plan shows

The pilot sat cleanly outside the real systems. Production means connecting to the core banking platform, the CRM, the collections workflow, and the reporting layer.

Each connection is a separate project sitting behind everything else IT is already committed to.

Picture week nine of a twelve-week plan. The team flags that one connection needs a change request. The change request queue is committed through the end of the quarter. The go-live date the MD has been told is now sitting in a queue nobody is managing.

That conversation is already happening in some organisations right now.

Nobody owns the full path

The pilot was built by the digital team. Production belongs to the business unit. Technology is owned by IT. Compliance sits with risk.

When something breaks, there is no single person whose job it is to fix it. It gets escalated. Then parked. Then it becomes the line that has said progressing for two quarters.

Each team is reporting accurately on the piece they own. Read together, the updates describe a relay race where the baton has been on the ground for four months. Nobody is lying. Nobody has the full picture.

The vendor conversation your team is not having

At some point recently a vendor showed your team an agentic workflow. The demo was good. Someone in the room said this is where we need to go.

The question nobody answered: are we actually ready for it?

An agent makes a series of decisions across a single customer interaction. That is genuinely more capable than the automation you already run. It also sits differently inside RBI's model risk framework, which was built around models that make one traceable decision at a time.

If something goes wrong in an agentic collections workflow, what does the audit trail look like? That is the question an examiner will ask.

Good vendors will welcome this conversation. Before any pilot agreement, one question is worth asking: can we map the governance requirements and the data readiness gap together, in writing, before we start?

You have an AI inventory. Not an AI program.

When the board asks for a view of the full AI program, the answer in most Indian BFSI organisations is a slide from every business unit.

That is not a program view. That is an inventory count.

Pick any two AI initiatives running right now. Are the teams sharing infrastructure? Did they start from the same governance assumptions? Do they know enough about each other to avoid duplicating work?

In most organisations the answer is no. Every initiative approved separately, budgeted separately, reported separately. The board sees twelve things running. Not a direction.

Adding a thirteenth does not make the program stronger. It makes the inventory more expensive.

The organisations that have moved from inventory to program have one thing in common. One named person - not a committee, a person - with a view across all the initiatives, making active decisions about what runs next and what stops. The board hears one coherent update from one owner.

That person does not need to sit at the Chief level. But they need to exist.

The question that shows you where you actually are

Put every active AI initiative on one page. Pilots, proofs of concept, live deployments, vendor commitments.

Does that page tell a coherent story? Or does it tell you things have been approved without anyone watching the whole?

If it is the second, that is not a failure of the individual teams. It is a structural gap. And it is the right question to bring into the room before the people above ask it first.

What the session covers

In 45 minutes we will work through the five gaps, what is causing them, and what a realistic path forward looks like for each one. Every registered attendee gets a checklist they can take into their next team meeting.

Most teams who read this far already know which gap they are sitting in. That is where we start.

The teams winning Bima Sugam aren't waiting for the deadline

Praveen Kumar — Sat, 28 Mar 2026 05:29:53 +0000

UPI took something that was broken, paper-heavy, and out of reach for most Indians and turned it into one system that everyone could use. Bima Sugam is trying to do the same thing for insurance. One platform where anyone can compare, buy, manage, and claim any policy from any insurer in the country.

The goal is big. So is the work. Sixty plus insurers, thousands of middlemen, decades of old systems, and a brand new digital platform all need to work together before a single customer can log in and do anything useful. The Insurance Regulatory and Development Authority of India (IRDAI) has set a rollout schedule by product type, starting with motor, then health, then life.

And the deadline has already moved before.

But something happens inside companies every time the date shifts. Something quiet. And quietly expensive.

You're not wrong to feel relieved. But relief has a price.

When a deadline moves, the first reaction is to slow down. Shift focus. Deal with what's in front of you. That's human. That's normal.

But here's what years of Bima Sugam delays have quietly taught teams. The deadline will probably move again. So there's no real urgency. And that's where things start to go wrong.

Some teams don't work to the IRDAI date at all. They work to their own. How long does this actually take? That's their question. Every extension just gives them more breathing room. It doesn't change what they're doing or how fast.

Other teams are tied to the calendar. When the date moves, everything moves with it. Clean-up work slips. Partner calls get rescheduled. Contingency plans get shelved. There's still time, after all.

Both teams are working. But not at the same pace. And that gap gets wider every time the deadline shifts.

The clock on the actual work doesn't reset when IRDAI moves the date.

Four things that have to be true before you go live

Ask your team the honest question: what would we be unable to finish if the current IRDAI deadline held? The answer shows up in four places. Each one looks like a workstream. Each one decides whether that workstream means anything.

Customer data clean-up

Pehchan ID mapping is in most project plans. What is not in most plans is the work that has to happen before mapping can even start. Cleaning up broken customer records across old core systems, CRM (Customer Relationship Management) tools, and partner databases that were never built to talk to each other is not a small job.

The plan assumes the data will be ready when the mapping layer needs it. That assumption is rarely checked. When it breaks, it breaks late, at the point where everything else is built and waiting. Fixing it at that stage is not a quick technical patch. It is weeks of clean-up work that was always going to take weeks, just left to happen at the worst possible time.

Bank partner readiness

Your plan shows your internal readiness date. Your actual go-live date is decided by the slowest partner in your bank network.

For large insurers that network spans dozens of relationships, each with its own tech team, its own sign-off process, and its own idea of what ready means. Picture week eleven of a twelve-week timeline. A partner's internal approval is held up. Their API environment is not certified. The date you have been telling the board is now sitting in someone else's hands. The partner lagging the most rarely gets mentioned in status calls. But they are the one who decides whether your launch date is real.

Bima Sugam India Federation (BSIF) sign-off

Sign-off appears in most plans as a single box between build and go-live. What most plans don't have is a backup for what happens when the first attempt fails. Failing on the first try is not unusual. Most teams only find out how long the retry actually takes when they are already in the middle of it.

The build choice your team is making right now

The first three are readiness risks. This one is different, and in my view the most important. It is a technical implementation choice being made right now, without being flagged up, that will decide what Bima Sugam costs you to run in year two.

Teams connecting bank partners to the platform have two options. One central connection point means one place to fix things when the platform changes. A separate connection for each bank is faster to set up today. Which makes it the easy choice when a deadline feels far away.

Bima Sugam has already changed since it was first set out. IRDAI has flagged roughly a dozen more changes coming in the next few months. An insurer running twenty separate connections at that point has twenty separate fixes, twenty timelines, twenty sets of sign-offs. The Bima Vistaar rollout, which got stuck as insurers tried to coordinate through a single shared change, is a live example of what that looks like in practice.

The cost of that architecture lands on whoever runs the platform in year two. This decision belongs with the technology leader, because the long-term cost is theirs to carry. And the window to change it closes when the build is done.

The question worth asking in your next team meeting

Not: are we on track? That question gets a confident answer that reflects what each team owns individually, not the gaps between them. The gaps live between teams. They only show up when someone asks across all of them at once.

For each of the four things above, who is the named person accountable, what is their current status, and when does their work need to be done for your timeline to hold?

If you can answer that for all four without being passed to another team first, you are managing the risk. If the answer needs a hand-off before it can be given, that is where the risk sits, whether or not the deadline moves.

The window that is still open

The tech leaders in the best position right now didn't start earlier because they saw something others didn't. They started because someone decided, before the pressure arrived, to treat the actual time the work takes as the real limit, and the IRDAI calendar as secondary to that.

The work has a floor that doesn't move just because the deadline does.

The gap is real. The person who exhaled when the last deadline moved is now two months behind the one who didn't. That distance is still closeable. But not for much longer.

If any of the four questions don't have a clean answer yet, that's what the webinar is for. Register here