What to Build for Insurance Brokers and Agencies in India

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: Owner or COO of a mid-sized IRDAI-registered insurance broking firm in India — 10 to 80 staff, selling across life, health and general lines — whose renewal leakage and compliance burden are growing faster than headcount

For a 10–80 person IRDAI-registered broking firm in India, the right first build is not a CRM. It is a policy data spine — one database that pulls policy, premium and renewal data from carrier portals and NSDL's National Insurance Repository into a single reconciled view. Build that first, layer a renewal engine and an IRDAI compliance workflow on top of it, and only then worry about a CRM front-end. Do it in the other order and you spend eighteen months automating workflows on top of data that is quietly 20% wrong.

This piece is for the owner or COO who already knows the pain. You are hiring faster than revenue is growing. Your renewal book is leaking, and no one can tell you by how much without a two-week audit. Your compliance team dreads the end of every quarter. And every vendor who walks in wants to sell you a full suite CRM that your producers will not use.

The three operational gaps that actually cost you money

Across mid-sized broking firms selling life, health and general lines, three problems show up again and again. They are the ones worth building software for. Everything else is a nice-to-have.

1. Renewal follow-up lives in WhatsApp threads

Your producers remember their top 20 clients. The other 2,000 renewals move through a mix of WhatsApp broadcasts, forwarded carrier reminders, and whoever happens to pick up the phone that week. According to beyondsure.in, the average Indian broker loses 30–45% of their renewal book each year — not to a competitor undercutting them, but because no one followed up in time. IRDAI data cited by credgenics puts the 13th-month life persistence ratio at only 65–70%, meaning roughly a third of life policies lapse inside year one. On an industry scale, 86 lakh individual life policies lapsed in FY2024-25, erasing ₹8.7 lakh crore in sum assured.

For your firm specifically, every one percentage point of lapse reduction on a renewal book of, say, ₹40 crore in premium is roughly ₹40 lakh of recovered premium — and the commission trail on it compounds for years.

2. IRDAI returns are rebuilt from scratch every quarter

Form B, premium remittance registers, cash and bank reconciliations, business statistics returns — your compliance team pulls these together in Excel each quarter by chasing producers, downloading carrier statements, and praying the numbers tie out. The regulator has become visibly less patient. IRDAI fined UIB Insurance Brokers ₹1 crore in late 2024 for premium remittance delays ranging from 36 to 1,151 days, and in August 2025 fined Policybazaar Insurance Brokers ₹5 crore for eleven charges including remittance delays and governance lapses. Under the Insurance Act, fines can reach ₹1 crore per violation plus ₹1 lakh per day for continuing default on returns.

None of this is because brokers are negligent. It is because the data needed to file accurately lives in six different carrier portals and three internal spreadsheets, and reconciling it manually is a two-week exercise that nobody wants to do more than once.

3. Policy data is scattered until a claim forces reconciliation

Ask any producer in your firm to pull the current sum insured, premium paid date and nominee details for a specific client across their three policies with three different carriers. It takes 20 minutes, and the answer is often wrong. This is the quiet root cause of the other two problems. You cannot send a timely renewal nudge for a policy you do not know is expiring. You cannot file a clean Form B when your premium register disagrees with the carrier's. You cannot support a claim quickly when the policy document is in a producer's personal Gmail.

NSDL's National Insurance Repository now has over 3 million e-Insurance Account holders and participation from 21 life and 20 general insurers, but adoption on the broker side is still thin. Most firms are not pulling the feed. They should be.

What to build, in order

Build 1: The policy data spine

What it is. A single normalised database of every policy your firm has placed — life, health, motor, fire, marine, liability — with the fields that actually matter: policyholder, insured members, insurer, product, sum insured, premium, inception, renewal date, payment status, nominee, broker code, producer, and the raw policy PDF. One row per policy, one source of truth.

Where the data comes from. Three feeds. First, scheduled scrapes or API pulls from each carrier portal your firm has broker codes with (most carriers now expose at least a CSV download of your book; a handful have REST APIs). Second, NSDL NIR feeds for clients who have e-Insurance Accounts linked to your broker code. Third, a lightweight intake step at policy issuance so new business flows in cleanly rather than being backfilled.

What changes once it exists. Your renewal pipeline for the next 90 days becomes a database query instead of a spreadsheet exercise. Your compliance team can generate the premium register for a quarter in minutes. When a claim comes in on a Saturday, your producer has the policy wording, endorsement history and claim contact in two clicks instead of two days.

What it takes. This is a six-to-twelve week build for a firm with 10–20 carrier relationships, depending on how many carriers expose clean feeds versus how many need scrapers that have to be maintained. The hard part is not the database — it is the integration surface and the data cleanup from historical policies. Expect the first month to be mostly schema design and reconciling three years of back-book data. Expect to keep two engineers busy on carrier connector maintenance in perpetuity, because carrier portals change without notice.

What it is bad at. It is not a sales tool. Producers will not log in to it daily. It is plumbing. Its value shows up in the systems built on top of it, which is why vendors do not pitch it — there is nothing to demo.

Build 2: The renewal engine

What it is. A workflow that queries the spine every morning, identifies every policy expiring in the next 30, 7 and 1 days, and triggers a structured outreach sequence per client segment. WhatsApp Business API for the volume tier, assigned producer outreach for high-value accounts, email with the renewal quote and payment link for self-service clients. Every touchpoint is logged against the policy row.

Why this specific shape. A regional motor broker running 48,000 policies across 12 branches cut lapse from 28% to 18.5% — a 34% reduction in one season — by replacing phone-only outreach with a T-30 / T-7 / T-1 WhatsApp sequence. The lesson is not that WhatsApp is magic. It is that structured, timed, logged outreach beats ad-hoc effort, and WhatsApp happens to be the cheapest channel with 90%+ open rates in the Indian market.

What changes. Lapse rate drops. The size of the drop depends on where you are starting — a firm at 40% lapse has more to gain than one at 20% — but every point back on a mature book is almost pure margin because the acquisition cost is already sunk.

What it takes. Four to eight weeks on top of the spine, assuming WhatsApp Business API is already approved (which itself takes two to three weeks with Meta). The real work is not the automation — it is designing the segmentation and the escalation rules with your senior producers so that the system does not spam your top accounts with templated messages.

Build 3: The IRDAI compliance workflow

What it is. Scheduled generators for Form B, premium remittance statements, cash/bank books, and the quarterly business statistics returns, pulling directly from the spine. A dashboard that flags premium that has been collected but not remitted beyond, say, 7 days — the single most common trigger of IRDAI action. A document locker for KYC, policy copies and endorsement records with retention policies that match the regulator's requirements.

What changes. Quarter-end goes from a two-week scramble to a two-day review. More importantly, the premium remittance ageing dashboard means you catch a delay at day 10 instead of day 110. Given that recent IRDAI penalties have specifically cited remittance delays stretching from 36 to over 1,100 days, this one dashboard is probably the highest insurance-value feature in the entire stack.

What it takes. Six to ten weeks, mostly spent getting the output formats exactly right and walking your compliance officer through edge cases. A qualified compliance consultant or your statutory auditor should review the generated returns before you file against them — software formats the data, it does not take legal responsibility for what you submit.

Build 4 (only now): The CRM layer

After the spine, the renewal engine and the compliance workflow are live, a CRM for producers becomes genuinely useful — because the data under it is finally trustworthy. At this stage the question is often whether to extend what you have built or integrate a packaged tool. For most mid-sized Indian brokers, a thin custom CRM wrapping the spine beats configuring Salesforce Financial Services Cloud, mainly on licensing economics at 30–80 seats and on the fact that you already own the data model.

What is not worth building yet

Three things vendors will try to sell you that you should decline until the first three builds are live and used:

• A customer-facing portal or app. Indian retail insurance customers overwhelmingly transact over WhatsApp and phone. A portal is a cost centre until you are at 100,000+ active policies with a self-service segment that actually wants one.
• An AI underwriting or risk-scoring engine. As a broker you do not underwrite. You place. Spend AI budget on claims document extraction and renewal-propensity scoring instead, both of which pay back inside a year.
• A full BI stack. Looker or Power BI on top of the spine is fine. A custom analytics product is not, until you know which three dashboards your leadership actually opens weekly.

What this costs and how long it takes

Honest answer: it depends on four things, and anyone who quotes you a number before asking about them is guessing.

1. How many carrier integrations you need on day one. Five is a different project from twenty-five. Each carrier with no API means a scraper that needs ongoing maintenance.
2. The state of your back-book data. A clean three years of policy data in a single AMS is a two-week migration. The same data across five Excel files, a legacy desktop tool, and producers' email folders is a two-month cleanup before you can even start.
3. Whether you have WhatsApp Business API already approved and a template library green-lit by Meta.
4. How much of the compliance workflow needs to be fully automated vs. assisted. A "generate draft, compliance officer reviews, files manually" workflow is cheaper and faster to build than a fully automated filing pipeline, and for most mid-sized firms it is the right first version.

Illustrative shape, not a quote: a firm with 15 carrier relationships, roughly 30,000 active policies spread across two legacy tools, no WhatsApp API yet, and a compliance team willing to review generated returns before filing — would typically see the spine + renewal engine + compliance workflow sequenced across roughly nine to fourteen months of build, with the renewal engine starting to pay back inside the first renewal cycle after it goes live. Change any of those four variables and the shape changes. For a scoped number for your firm, the questions that need answering are: carrier count, back-book state, current compliance process, and the WhatsApp readiness. A digital transformation conversation with a build partner will scope those in a week.

Sequence matters more than the tech stack

The temptation, when you finally decide to invest, is to buy a big suite and switch everything over. Do not. The suite will fail on your data — because your data is in bad shape and the suite does not know that. Build the spine first, prove the data is clean and complete on one line of business (motor is usually the easiest; health is the hardest because of endorsements and member additions). Layer the renewal engine on that line, measure the lapse delta over one renewal cycle, then roll both out to the rest of the book. Add the compliance workflow in parallel once the spine is stable.

This order works because each build de-risks the next one. The spine makes the renewal engine possible. The renewal engine produces the first clear ROI number you can show your board. The compliance workflow then uses the same data to remove your largest regulatory exposure. A CRM, if you still want one after all of that, becomes a cosmetic layer on a system that already works.

For context on how fast this market is moving — India's insurance brokerage sector was valued at roughly USD 27.4 billion in FY2024 and is projected to reach USD 59.1 billion by FY2032, with 751 IRDAI-licensed brokers competing for the same book. The firms that will be meaningfully larger in five years are the ones whose operational cost per policy drops while headcount stays flat. That curve is a software problem, and it is a solvable one.

Frequently Asked Questions

Can we just use an off-the-shelf insurance agency management system instead of building custom?

For a 10–15 person firm with one or two lines of business, yes — a packaged AMS is probably faster and cheaper. For a 40+ person firm selling across life, health and general with 10+ carrier relationships, off-the-shelf tools tend to break on the integration surface and on IRDAI reporting formats specific to Indian regulation. Most mid-sized brokers end up with a hybrid: a packaged tool for one line, custom plumbing for carrier integrations, and custom compliance generators.

How much does custom software for an Indian insurance broker cost?

The honest answer is that the range is wide because the four variables that drive it — carrier integration count, back-book data quality, compliance automation depth, and WhatsApp/channel readiness — move the number by 3-4x between a lean build and a full one. Rather than a figure, think in phases: the policy data spine is the largest upfront investment, the renewal engine is the fastest to pay back, and the compliance workflow is the one that reduces regulatory exposure. A scoping conversation that walks through your current carrier list, your existing data, and your compliance process is what turns a range into a quote.

How long before we see ROI on the renewal engine?

Renewal cycles are the natural measurement window. If your motor book renews annually and you deploy the engine in Q1, you have your first clean lapse-rate comparison by the end of Q4. The Ominiflow case cited above saw a 34% lapse reduction in one season, but the starting point matters — a firm already at 20% lapse has less headroom than one at 40%. Measure baseline lapse per line of business before you deploy, so the delta is defensible to your board.

Does the software handle IRDAI filing on our behalf?

No, and it should not. Software generates the returns and flags the anomalies. A qualified compliance officer or your statutory auditor should review and sign off before anything is filed with IRDAI. The regulator holds the principal officer personally accountable, not the vendor. Any software partner who claims otherwise is overselling.

What about data security — we hold sensitive policyholder PII?

IRDAI's information and cyber security guidelines, combined with India's DPDP Act, mean broker systems need encryption at rest and in transit, role-based access, audit logs, and a documented breach response. These are not optional and should be in the architecture from day one, not bolted on after. A security review by an independent CERT-In empanelled auditor before go-live is standard practice and worth budgeting for.