The Individual Advisor's Tech Stack in 2026

Ask an individual advisor in India what they run their book on and the polite answer is a spreadsheet. The truthful answer is visible on their home screen within about ten seconds.

There is WhatsApp, carrying most of the day's actual work. There is a photo gallery holding several hundred policy PDFs and screenshots of RC books, all named things like IMG_20260612_113402.pdf. There are three or four insurer portals, each with a separate login, one of which has locked them out and stayed locked out since March. There is a spreadsheet, either on the phone or on a laptop at home, that was accurate about six weeks ago. There is a bank SMS thread that is doing duty as commission confirmation. Somewhere there is a physical diary, and it is often the most reliable object in the list.

And if the advisor is engaged by an aggregator or a large intermediary, there is a principal's app: the place they run quotes, submit proposals and read whatever commission statement the principal chooses to show.

That inventory is not a failure of discipline. It is what happens when a distribution channel scales faster than the tooling built for it, and when the person doing the distributing has no procurement budget, no integration team, and roughly forty minutes a day that is not spent talking to clients or chasing an insurer's operations desk. It is worth mapping honestly before anyone recommends a fix, because most recommendations aimed at advisors are quietly written for someone else.

There is a well-trodden way of writing about insurance technology in India, and it does not apply here. The firm-level version of this article, The Indian Commercial Broker Tech Stack in 2026, maps a CRM, a placement platform, a policy administration system, an endorsement workflow, a claims tracker, document intelligence, and an integration spine tying them together. That stack is real, it is correct for the firm it describes, and it is the wrong mental model for one person with a phone.

The difference is not size. It is structure.

• A firm's stack assumes a division of labour. Somebody owns the CRM, somebody else owns claims, and the integration spine exists because those people need to hand work to each other. An advisor hands work to nobody. Every layer terminates in the same person, so the integration problem is not a data problem, it is an attention problem.
• A firm buys. An advisor is given. The firm decides between build, buy and hybrid. The advisor discovers what the principal decided.
• A firm can absorb a tool that takes three weeks to learn. An advisor abandons anything that does not work on the first attempt, in the middle of a call, on a mid-range Android handset, while the client waits.
• A firm measures cost per account. An advisor measures whether they remembered the renewal.

So the useful question is not which of the firm's seven layers an advisor can afford. It is: what does one person actually need to keep track of, and where does that tracking currently live?

The system of record answers one question: what policies does this book contain, and what is true about each one right now. Cover, insured, dates, premium, insurer, and the POS Code the proposal went out under.

This is the layer most individual advisors have no answer for, and it is the one that matters most.

The common substitutes each fail in a specific way. The insurer portal knows only that insurer's policies, so it can never show the book. The principal's app knows only the business placed through that principal, which is closer, but it belongs to the principal. The spreadsheet knows everything the advisor last typed into it, which is a description of the advisor's memory rather than the book. The WhatsApp thread knows everything and can retrieve nothing.

The practical test is not a technology question. Name a client and ask what they hold, across every insurer, with dates. If the answer takes longer than a minute, or requires opening a portal, there is no system of record. There is a search.

Every policy generates a PDF, and that PDF arrives through whichever pipe the insurer prefers: an email nobody reads on the phone, a portal download, or a WhatsApp forward from the principal's operations desk. It then lands in the gallery, joins several hundred siblings, and is functionally gone.

The collapse is not at the point of storage. It is at the point of retrieval. The document exists. The advisor simply cannot find it in the ninety seconds a client on the phone will tolerate, so they open the portal instead, and if it is a policy from an insurer they are no longer actively placing with, they call the operations desk and wait.

Two things make this layer worse than it looks. The first is that the phone is the only copy. Handsets are lost, sold, water-damaged and factory-reset, and a book of documents that lives in one gallery lives one accident away from nothing. The second is that the schedule contains the fields the record layer needs (dates, sums insured, the POS Code line), so a document that cannot be found is also a record that never gets populated. The two layers fail together.

The fix is unglamorous and mostly behavioural: pull the fields out at the moment the PDF arrives, not at the moment the client asks, and keep a second copy somewhere the handset cannot take with it.

Renewal dates are the only thing in this entire stack that move without being touched. Everything else waits. A due date does not.

This is the layer where the low-tech option genuinely outperforms, and it is worth being honest about why. A paper diary is consulted every morning. A spreadsheet is consulted when the advisor remembers to consult it, which is precisely the failure the spreadsheet was supposed to fix. A reminder is not a data structure, it is an interruption, and any tool that requires the advisor to go and look has already lost to the diary that is open on the desk.

The portals do send renewal notices, but they send them to the policyholder, and the advisor learns about the renewal by not learning about it. The principal's app may send the advisor a list, but only for that principal's business, which means an advisor who has moved between principals has a reminder layer with holes in it shaped exactly like their own history.

There is a related clock worth tracking on the front end. Under the POS-Life master circular, policy issuance turnaround for a POS-Life product must not exceed four working days. That is a commitment the insurer carries, not the advisor, but the advisor is the one the client calls on day six, and only an advisor who wrote the submission date down knows that day six is late.

A POSP is remunerated by the entity that engages them, under the contract of engagement, and not as an independent commission earner facing the insurer. That single structural fact shapes this whole layer, because it means the advisor's payout is computed somewhere else, by someone else, and arrives as a statement to be accepted.

So the arithmetic the advisor needs is not forecasting. It is verification. What was placed, at what premium, at what rate under the engagement contract, and did the statement pay it. That is a per-policy comparison against a per-policy expectation, and it is the reason a bank SMS is not a commission record: the SMS confirms that money arrived, not that the right money arrived.

Most advisors do this at the total level, if at all. Total received against total roughly expected, eyeballed, monthly. That reconciles nothing. A short-paid line and a missing line produce the same shortfall, and only one of them is worth a phone call. A book of 300 policies has a long tail of small discrepancies that individually are not worth chasing and collectively are.

This is also the layer where the ground may move. As of mid-July 2026, IRDAI had signalled a consultation paper on distribution remuneration expected by the end of the month, with ideas reported to include trail or staggered commission spread across the policy life rather than concentrated upfront, effort-based remuneration, product-wise caps differentiated by complexity and tenure, and tighter disclosure. None of that is a rule. All of it is at proposal stage, and the paper itself had not been published. But an advisor whose commission arithmetic is a monthly eyeball is poorly placed for any structure that pays smaller amounts across more years, because trail income is precisely the kind that goes missing quietly.

The communication layer is the only part of the advisor's stack that is genuinely solved, and it was not solved by the insurance industry. It was solved by WhatsApp, and the advisor adopted it without being asked, trained or licensed to.

It is worth stating plainly why this layer holds while the other four leak. The client is already there. There is nothing to install, nothing to explain to a 58-year-old policyholder, and no handset it fails on. It carries the PDF. It survives a bad signal on the way to the client's shop.

The consequence for every other layer is the part advisors underrate. Because the communication layer is where the advisor already is, any tool that lives elsewhere is competing against a chat thread that is already open. That competition is not close. This is why the principal's app is usually opened once at proposal and never again, why the portal login expires unused, and why the spreadsheet is six weeks stale: none of them are where the work is happening.

One conduct line belongs here, because the ease of the channel hides it. Prior approval of both the engaging entity and the insurer is required before an advisor issues any advertisement or sales material. A message that is servicing is not the same as a message that is selling, and the channel makes both feel identical to type.

Every stack article assumes the reader chooses their stack. For a POSP, that assumption is usually false, and pretending otherwise is what makes most advice for this audience useless.

A POSP is tied to one insurer or intermediary at a time. Where the tie is to an intermediary, the multi-insurer reach an advisor enjoys flows from that intermediary's licence and not from the advisor's own status. The tooling follows the same line. The principal chooses the app, decides what the commission statement shows and at what granularity, controls which portals the advisor is provisioned on, and owns the data those systems hold. The advisor gets a login.

This has consequences that no feature list fixes:

1. The advisor cannot compare the app against alternatives, because there is no procurement decision to make.
2. Requests for a better renewal export are one advisor's request among many, weighted accordingly.
3. Data portability at the end of a tie-in is a contractual question, not a technical one.
4. Two principals means two systems, and nothing joins them except the advisor.

The honest conclusion is narrow but real. The layers an advisor cannot control are the transactional ones: quoting, submission, issuance, the statement. Those belong to the principal and always will. The layers an advisor can control are the ones that describe their own book: what they sold, to whom, when it renews, what it should pay, and where the document is. Those are the layers with no owner today.

That is also why the advisor's own record has to be principal-agnostic. Tie-ins end. Aggregators change their app. Bima Sugam, whose information hub is live with transactions expected around end-September 2026, will add another surface rather than replace the existing ones, and what it will mean for an individual advisor's economics is not yet established. Through every one of those changes, the client book is the only asset that stays with the advisor, and it is currently the layer held together with a gallery, a diary and a thread.