The Indian Commercial Broker Tech Stack in 2026: CRM, Placement, Policy Admin, Claims, and AI Assistants

The technology environment for Indian commercial insurance brokers has been reshaped in three years by three forces. First, IRDAI's EoM Regulations 2024 and the Insurance Brokers (Amendment) Regulations 2023 raised the operational documentation bar, requiring brokers to maintain auditable trails for placement decisions, commission accruals, and renewal advisories. Second, Bima Sugam went live in phases through 2024-2025 and now sits as a parallel rail for retail and lower mid-market placements, forcing brokerages to expose API surfaces they previously did not have. Third, the cost of generative AI tooling collapsed: a useful policy-wording comparator that cost INR 40 lakh to build internally in 2022 can now be assembled on hosted LLM APIs for under INR 5 lakh in annual run cost.

The result is that a broker firm with INR 25 crore of annual brokerage revenue, which would have run on a single broker-management system plus spreadsheets in 2022, today operates a stack of six to nine connected applications. The fragmentation is not a fashion choice; it is a response to the fact that no single Indian insurance-software vendor covers the full broker workflow end-to-end with adequate depth. Brokers who try to force one platform to do everything end up with weak CRM, weak claims tracking, or weak placement workflow, and they pay for it during IRDAI inspections and large-claim escalations.

This post maps the seven application layers a commercial broker in India needs in 2026, where build-versus-buy lines fall, what integration spine ties them together, and at what firm-size threshold each layer becomes essential. Premium and revenue figures are 2026 calibrations; the architectural pattern is stable for the next 24 months.

The seven layers covered below are: CRM, placement platform, policy administration, endorsement workflow, claims tracker, AI document intelligence, and the integration spine that ties them together. Two of these (CRM and policy administration) are mature commodity categories with strong Indian vendors. Three (placement platform, claims tracker, AI assistants) are in active reshaping and reward investment. The remaining two (endorsement workflow and integration spine) are unglamorous infrastructure that quietly determines whether the rest of the stack actually works under load.

The stakes are concrete. A broker firm with INR 25 crore brokerage revenue that loses a single mid-market account with INR 1.8 crore of annual premium because of a botched claim experience or a missed renewal touchpoint has lost roughly INR 18 lakh of annual brokerage. Three such losses in a year erase any saving the firm might have made by skimping on the stack. The economics of stack investment are dominated by retention, not by transactional efficiency.

The CRM is the system of record for the client relationship: prospect pipeline, renewal calendar, contact graph, meeting notes, and the running log of advisory conversations. Indian brokers historically conflated CRM with their policy-admin system, treating the policy schedule as the client record. This breaks the moment a prospect with four group companies needs to be tracked across an 18-month buying cycle before a single policy exists.

For brokers below INR 10 crore of annual revenue, a horizontal CRM (HubSpot, Zoho CRM, Freshsales) with insurance-specific custom fields is adequate. Above INR 10 crore, the limitation of horizontal CRMs becomes painful: no native concept of a placement opportunity that spans multiple lines, no renewal-date logic, no commission-tracking hooks. At this scale, brokers either move to an insurance-specific CRM (Salesforce Financial Services Cloud configured for broking, or Indian-built platforms from vendors like Symbo, InsureMo, or Riskcovry's broker-stack offering) or accept significant configuration debt.

The placement platform is distinct from the CRM. Its job is to manage the workflow from RFQ floated to insurer panel through quote comparison, terms negotiation, binding, and policy issuance. A serious placement platform handles:

• structured risk submission templates by line of business
• multi-insurer quote ingestion in different formats (PDF quote sheets, Excel rate cards, email-bound terms)
• side-by-side wording comparison with delta highlighting
• audit-trail capture for IRDAI inspection
• post-bind handover to policy admin

For commercial property and engineering placements above INR 5 crore sum insured, a structured placement platform pays for itself within a single renewal cycle through faster quote turnaround and reduced wording errors. Indian options include Symbo's broker placement module, RIA Insurance Brokers' internal platform (now offered to third parties), and several in-house builds at the top ten brokerages. International tools (Concirrus, Cytora) are increasingly being trialled but require heavy localisation for Indian SFSP wordings and rate-card conventions.

The critical integration line is CRM-to-placement-platform: the placement opportunity must be created in the CRM, hand off cleanly to the placement platform when an RFQ is floated, and write back placement status to keep the renewal calendar accurate. Brokers who skip this integration end up with two systems telling different stories, and a senior reviewer finding out at the IRDAI audit that the CRM shows a renewal closed while the placement file shows it pending.

Policy administration is the post-bind layer. It owns the policy register, premium accounting, instalment scheduling, endorsement processing, certificate-of-insurance issuance, and the GST and TDS treatment of brokerage receivables and recoverable taxes. In India this layer carries the heaviest regulatory load: IRDAI inspections frequently focus here, GST audits demand reconciliation between policy-admin records and books of account, and the IRDAI (Insurance Brokers) Regulations 2018 require maintenance of specific policy-and-claims registers in defined formats.

For brokers below INR 5 crore revenue, a packaged broker-management system (BMS) from an Indian vendor handles this layer adequately. Common vendors include InsureMo Broker Suite, NIIT Technologies broker module (legacy but still in use at PSU-aligned brokers), and newer cloud-native platforms from Riskcovry, Vymo, and Symbo. Above INR 25 crore revenue, brokers typically need to either heavily configure a tier-one BMS or build internal extensions, because the off-the-shelf instalment-scheduling, multi-currency handling for GIFT City placements, and consolidated invoicing for multi-policy clients break under volume.

Endorsement workflow deserves its own attention. A mid-market commercial broker processes hundreds of endorsements monthly: addition of locations, increase in sum insured, change of insured name post-merger, vehicle additions on fleet motor, employee additions on group health. Each endorsement is a small placement: it requires insurer instruction, premium calculation, endorsement schedule receipt, client notification, and accounting entry. Brokers without a structured endorsement workflow lose roughly 2-4% of monthly brokerage to leakage from delayed insurer instructions and missed premium adjustments.

The IRDAI inspection point most relevant here is the e-policy register. From the 2024 master circular onwards, brokers are expected to maintain a digital register linking every policy issued, the insurer, premium, sum insured, brokerage earned, and supporting documentation in a tamper-evident format. Spreadsheets do not satisfy this requirement at scale, and several mid-market brokers have received deficiency observations during inspections for exactly this gap.

GST treatment within the policy-admin layer is another inspection magnet. Brokerage attracts GST at the prevailing service-tax rate, and reverse-charge applies on certain placements with foreign reinsurers. The policy-admin system needs to map each placement to the correct tax treatment, generate compliant invoices, track input-tax credit on brokerage-related expenses, and reconcile quarterly with the broker firm's GST returns. Brokers running this reconciliation manually typically lose three to five working days per quarter to it, and find discrepancies that compound into penalty exposure if uncorrected.

Finally, premium-credit periods need explicit handling in the policy-admin layer. Insurers in India typically allow brokers a 15 to 30 day premium credit period during which the broker remits collected premium to the insurer. The policy-admin system must track aged premium receivables by client, generate dunning communications, and flag at-risk accounts to firm leadership before the credit period lapses, because premium not remitted within the prescribed window can trigger IRDAI enforcement and insurer suspension of the broker's authority to bind business.

The claims tracker is where brokers most consistently underinvest, and where they most consistently lose client relationships. A commercial property broker handling claims for a manufacturing client with INR 200 crore sum insured cannot run that engagement on email and a shared Excel sheet. The client expects a real-time view of FNOL status, surveyor appointment, document submission, surveyor report receipt, insurer review status, and settlement payment. Indian risk managers at listed clients are now writing this expectation into broker selection RFPs as a hard requirement.

A functional claims tracker for an Indian commercial broker handles:

• claim intake with IRDAI-mandated minimum data fields
• automated FNOL acknowledgement to insurer within the IRDAI claim-acknowledgement window
• surveyor coordination: appointment tracking, joint-survey scheduling, surveyor report receipt date
• document checklist by line of business with completion tracking
• insurer-side milestone tracking: claim file number, reserve set, surveyor report submission to insurer, settlement decision, payment date
• client-side portal with selective visibility (clients see their own claims, broker firm sees all)
• escalation timers tied to the IRDAI claim-settlement timeline circular (30 days from surveyor report receipt for non-life)

Few Indian vendors do this layer well end-to-end. Brokers above INR 15 crore revenue typically build the surveyor coordination and milestone tracking in-house or as a heavy configuration on a generic case-management tool, while pulling FNOL and document checklists from their BMS. The client portal is a frequent custom build because no off-the-shelf product handles the multi-tenant visibility model that broker firms need without expensive seat licensing.

Claims advocacy outcomes are directly tied to tracker quality. A broker who can show the client a settlement timeline graph at year-end, broken down by insurer and surveyor, with comparison to IRDAI-prescribed timelines, demonstrates value that a spreadsheet broker cannot match. For a mid-market client paying INR 2 crore of annual premium, this transparency frequently determines whether the broker retains the account at renewal.

Reserving and reserve-tracking is a second-order capability that strong brokers build into their claims tracker. The insurer sets a reserve on every reported claim, but that reserve is rarely communicated to the broker proactively. Brokers who maintain their own estimated-reserve tracking, derived from surveyor preliminary assessments and historical settlement ratios for similar claims, can flag underspecified or overspecified insurer reserves to clients early. This matters for clients managing balance-sheet provisions under Ind AS 37 for contingent liabilities.

Subrogation and salvage tracking is the third capability often missing from broker claims systems. Where the insurer pays a claim and pursues recovery from a third party (transport carrier, contractor, supplier), the recovery proceeds eventually flow back into the loss-ratio calculation that drives the client's next renewal. A broker tracking subrogation outcomes can use them in renewal negotiations to argue for retention of no-claim discount or improved terms, an argument the broker cannot make without the data.

The AI-assistant layer is the newest addition to the broker stack and the one that has changed most rapidly between 2024 and 2026. The relevant use cases for Indian commercial brokers cluster into four buckets.

First, policy-wording comparison. LLM-powered tools now ingest a stack of insurer wordings (typical Indian SFSP, IAR, commercial general liability, marine open cover) and produce structured deltas highlighting exclusions, sub-limits, conditions precedent, and warranty language. A senior placement broker who previously spent four to six hours doing this manually now reviews an auto-generated comparison in 30 to 45 minutes. The risk is over-reliance: the AI-generated comparison must be reviewed by a qualified broker before being presented to the client, because subtle interactions between wording clauses are still poorly handled by current models.

Second, risk-submission preparation. AI assistants help structure the risk-information document from raw client inputs (financial statements, plant lists, fire-protection details, COPE data) into the format insurers expect. This is most impactful at the SME end of mid-market, where client risk data quality is low and broker time per submission has historically been high.

Third, claims-document review. NLP models scan FIR reports, surveyor reports, financial documents, and policy schedules for inconsistencies and missing information before submission to insurers. This reduces the rate at which insurers reject claims for documentation deficiencies, which in turn shortens the settlement timeline.

Fourth, internal knowledge search. A broker firm with 200 employees and ten years of placement history sits on tens of thousands of internal documents: past placements, claim files, advisory notes, market commentary. RAG-based search lets a junior broker ask 'how did we structure the marine open cover for an electronics importer with cargo accumulation in Mundra in 2023' and get a coherent answer in seconds. This is the lowest-risk AI application and the one with the highest internal productivity uplift.

A fifth use case emerging through 2025-2026 is renewal-advisory generation. AI tools can draft the first version of a renewal advisory note to the client, pulling current programme structure, claims history, market conditions, and emerging risk commentary from internal data. The broker reviews and edits before sending. This compresses the renewal-cycle preparation time from days to hours for standard mid-market accounts, freeing senior brokers to focus on the complex placements where genuine advisory work is needed.

A sixth use case, still nascent in Indian broker firms but proven in the UK and US markets, is AI-assisted submission triage on the underwriting side, where insurers use AI to filter incoming submissions and prioritise underwriting attention. Brokers who understand how insurers triage their submissions can structure risk-information documents to score well in that triage, accelerating quote turnaround for the broker's clients. This is an indirect AI use case for the broker but an increasingly material one.

Governance constraints matter here. Brokers handling personal data of insured employees (group health, group personal accident) must align AI usage with the Digital Personal Data Protection Act, 2023. This requires explicit attention to which AI tools have access to which data, where data is processed, and whether tenant isolation is contractually guaranteed by the vendor. Brokers should not assume that hosted LLM APIs handle Indian personal data appropriately by default; explicit data-residency and processing-agreement terms are required.

The seven layers above only work if data flows between them. The integration spine is the unglamorous but determinative layer of the broker stack. Two patterns dominate in Indian broker firms in 2026.

The first pattern is point-to-point integration: each pair of applications integrated directly, typically through vendor-supplied connectors or custom API calls. This works for small stacks (three to four applications) but degrades quickly. A firm with seven applications has 21 possible pairwise integrations, and most do not need all of them, but the ones that exist become brittle: an upgrade to the CRM breaks the placement-platform handoff, an endorsement-workflow patch breaks the policy-admin sync, and the broker firm spends 15 to 20% of its IT budget on integration maintenance.

The second pattern is a thin integration platform sitting in the middle: a workflow tool like n8n, Zapier, or a more enterprise option like MuleSoft or Boomi, depending on scale. The integration platform standardises data formats, handles retries and error logging, and decouples the applications. The cost of the integration platform is non-trivial (INR 8-25 lakh annually for mid-market deployments) but is recovered in maintenance reduction within 18 months at firms running six or more applications.

The data model under the integration spine matters as much as the spine itself. Brokers benefit from a canonical client-and-policy data model defined once and used across applications: client legal entity, policy number, line of business, sum insured, premium, brokerage rate, renewal date, insurer, surveyor (where applicable). When each application defines its own client identifier and policy identifier, integration breaks at every change. Brokers who invest in a single source of truth for client and policy identity, typically maintained in the CRM or a dedicated master data layer, avoid the most painful integration failures.

API exposure to clients is the third element of the integration story. Listed-client risk managers and CFOs are increasingly asking for direct API access to their policy register, claim status, and premium schedules so they can pull this data into their own treasury and ERM systems. A broker firm without an externally exposed API will lose mandates to firms that provide one, particularly for clients with multi-jurisdiction operations and consolidated risk-management functions.

Observability and operational telemetry round out the spine. Brokers running six or more interconnected applications need centralised logging, error tracking, and uptime monitoring, because a silent integration failure between the placement platform and the policy-admin system can take two weeks to surface as a missed endorsement or unreconciled premium, by which time the client damage is done. Tools like Sentry, Datadog, or simpler open-source alternatives like Grafana with Loki are now standard at firms above INR 25 crore revenue, typically running at INR 6 to 12 lakh annual cost, and pay back within a single incident avoided.

Every broker firm above INR 5 crore revenue confronts build-versus-buy decisions for each layer. The 2026 calibration looks like this for an Indian commercial broker.

Buy without serious customisation: CRM, integration platform, AI document-intelligence tools (commodity now), basic e-signature and document-management tools. The risk of building these in-house is high relative to the differentiation they provide, which is near zero.

Buy with significant configuration: policy administration, broker-management system, basic claims tracker. Indian vendors have mature offerings here, and configuration to match firm workflow is the right approach. Custom builds in this layer rarely justify their cost unless the firm exceeds INR 100 crore revenue.

Build, with selective integration of external components: placement platform with insurer-specific quote ingestion, claims advocacy workflow with milestone tracking, internal knowledge-search RAG application. These layers carry meaningful competitive differentiation; the firms that build them well win mandates against firms that do not. The build does not need to start from scratch; selectively integrating components like LLM APIs, document-parsing tools, and case-management primitives is reasonable.

Build internally as table stakes for top-tier firms only: white-labelled client portals, multi-tenant claim-status visibility tools, custom analytics layers tied to firm-specific data. These projects make sense only for firms with INR 50 crore plus revenue and dedicated technology functions.

A fifth category worth naming explicitly is partnership-and-integrate: capabilities that the firm neither builds nor buys outright but accesses through deep partnerships with specialist providers. Risk-engineering survey capability often falls here, where the broker partners with an external risk-engineering firm and integrates their survey reports into the broker's own client portal. Catastrophe-modelling and exposure-aggregation analytics is another category where partnership with specialist providers (RMS, AIR Worldwide, or Indian providers like Reliance General's internal cat-modelling unit offered externally) makes more sense than internal build. The integration is what the broker invests in, not the underlying capability.

Build-versus-buy decisions are most often made wrong in two directions. Smaller firms over-build, attempting custom development with two-person IT teams and producing brittle products that fail at scale. Larger firms over-buy, accepting heavily configured packaged products in domains where differentiation could be created in-house. A useful filter: if the layer determines client-perceived service quality, lean toward build; if it determines internal operational accuracy, lean toward buy.

The stack a broker firm needs is a function of revenue, client mix, and lines of business. The following thresholds are rough but reflect what consistently works in the Indian market in 2026.

Below INR 5 crore revenue (typical of small regional brokers, retail-heavy firms, single-promoter operations): a horizontal CRM, a packaged BMS, email-and-spreadsheet claims tracking, and selective use of free or cheap AI tools is sufficient. Investment in stack sophistication beyond this point is hard to recover at this revenue scale.

INR 5 to 25 crore revenue (regional commercial brokers, multi-city operations, mostly mid-market clients): insurance-specific CRM, configured BMS with proper endorsement workflow, a basic placement platform (off-the-shelf or light internal build), structured claims tracker, point-to-point integrations. AI assistants for wording comparison and submission preparation start paying back at this scale.

INR 25 to 100 crore revenue (national mid-tier brokers, listed-client portfolios, multi-line capability): integration platform in place, custom placement platform components, custom claims advocacy workflow, internal knowledge-search RAG, API exposure to top clients, formal data governance and DPDP compliance programme.

Above INR 100 crore revenue (top-tier brokers, global affiliates, captive-broking arms of conglomerates): full custom stack in client-facing layers, formal IT function, dedicated platform engineering team, formal data-engineering practice, multi-region capability for GIFT City and overseas operations.

Firms that try to operate at a stack maturity level one tier above their revenue burn cash quickly and rarely achieve the operational excellence they hoped for. Firms operating one tier below their revenue lose mandates to better-equipped competitors within 24 months. The right stack is the one that matches the firm's current scale plus one rung of growth headroom, not the one that matches an aspirational position three years out.

A useful annual exercise for broker firm leadership is a stack-fit review against the firm's current revenue, client mix, and growth plan. The review evaluates each of the seven layers on three questions: does it support current operations without manual workarounds, will it support 1.5x current volume without re-platforming, and does it produce documentation defensible at IRDAI inspection. Layers failing any of the three questions warrant either configuration investment, vendor change, or build effort within the next 12 months. Layers passing all three should be left alone, because over-investment in stable layers crowds out investment in layers that genuinely need it.