Bima Sugam Operational Playbook for Indian Brokers and Insurers: Onboarding, Policy Filing, and Claims Initiation Mechanics

Bima Sugam is IRDAI's unified digital insurance marketplace, conceived as a single entry point for buying, servicing, and claiming across all insurance lines sold in India. The operational vision, articulated through the IRDAI Master Circular on Bima Sugam issued in 2024 and updated through 2025, positions the platform as neutral infrastructure that insurers, intermediaries, and policyholders interact with through published APIs rather than proprietary channels. The regulator has framed Bima Sugam as infrastructure on the same conceptual tier as UPI for payments and ONDC for commerce: a shared rail that participants connect to rather than a marketplace any single player controls.

The architectural parallels with NPCI-operated rails are explicit and deliberate. UPI succeeded because the underlying transaction protocol was standardised and open, because onboarding friction for banks and third-party applications was minimised through clear API specifications and sandbox testing, and because the consumer experience was decoupled from any specific bank's technology investment. ONDC applies the same pattern to retail commerce, creating an interoperable layer between buyer applications, seller applications, and logistics providers. Bima Sugam extends this logic to insurance: policyholders access the marketplace through the Bima Sugam consumer interface or through any participating broker, agent, or insurer portal, and the underlying product catalogue, quotation engine, policy binding, and servicing workflows are executed through standardised APIs that every participant implements.

For insurers, the practical implication is that Bima Sugam is not a distribution channel in the traditional sense. It does not originate leads, employ salespeople, or market products. It provides the plumbing through which products are listed, quoted, bound, serviced, and claimed, while distribution remains with insurers and intermediaries who build customer-facing experiences on top of the shared rail.

The phased rollout as currently published by IRDAI prioritises retail consumer lines (motor, health, term life) in the initial phase, with commercial insurance lines expected in phase 2 beginning 2026-2027. Corporate property, marine, liability, cyber, and specialty lines are not within the initial scope, which gives commercial insurers and brokers a window to observe the retail rollout, learn from early integration issues, and prepare their systems and processes before the commercial phase begins.

That preparation window is the subject of this playbook. The sections that follow walk through the operational mechanics that insurers and intermediaries need to master: board-approved participation, API integration with the Bima Sugam core, consent infrastructure built on UIDAI eKYC and the Account Aggregator framework, policy filing and sandbox testing, the one-click claims initiation workflow, dispute resolution linkage to the insurance ombudsman, and the data privacy obligations under the Digital Personal Data Protection Act, 2023.

Insurer onboarding onto Bima Sugam begins with a board-approved participation framework. The IRDAI Master Circular requires every participating insurer to secure formal board approval covering:

• The scope of participation (which product lines will be listed)
• The technology and operational investment committed
• The commission and fee structure to be honoured
• The service level commitments offered to Bima Sugam users
• The governance model for escalation and dispute handling

The board resolution must be filed with IRDAI along with the technical readiness declaration before the insurer is granted sandbox access.

The API integration layer is where most of the operational complexity sits. Bima Sugam exposes a suite of APIs covering product catalogue publishing, quotation requests, underwriting decisions, proposal submission, premium collection, policy binding, endorsement processing, renewal quotation, claims intimation, claims status tracking, and settlement confirmation. Each API has a defined request-response schema, authentication requirements, rate limits, and error handling conventions. Insurers connect to these APIs either directly from their policy administration system or through a middleware layer that translates Bima Sugam API calls into the insurer's internal system formats. Mid-sized insurers with legacy core systems typically choose the middleware approach because direct integration would require invasive changes to policy administration platforms that were not designed for open APIs.

Consent infrastructure is the second major integration layer. Policyholders interacting with Bima Sugam authenticate through UIDAI's Aadhaar-based eKYC, granting one-time or recurring consent for the insurer to fetch their identity and address details. For income and financial data relevant to life and health underwriting, consent flows through the Account Aggregator framework regulated by the Reserve Bank of India, which permits regulated financial institutions to fetch bank statements, income tax returns, and other financial data with the user's explicit consent, fulfilment of the consent, and an audit trail recorded by the Account Aggregator. For health and medical data, where available through the Ayushman Bharat Digital Mission and its Health Information Exchange (HIE-CM), the consent pattern follows the ABDM consent manager architecture.

DigiLocker integration provides the storage and retrieval layer for policy documents. Once a policy is bound on Bima Sugam, the policy schedule, certificate, and wordings are issued as DigiLocker-verifiable documents that land automatically in the policyholder's DigiLocker account. Claims and endorsement documents follow the same pattern. The advantage for the insurer is that DigiLocker's verification infrastructure removes the need for physical document handling at subsequent service touchpoints: when a policyholder initiates a claim, the insurer can fetch the policy document directly from DigiLocker with the policyholder's consent rather than receiving a scanned copy.

Timelines for completing insurer onboarding vary with the complexity of the insurer's existing technology estate. Large insurers with mature API gateways and modern policy administration systems have completed integration in 6-9 months. Mid-sized insurers with legacy cores typically require 12-18 months, with the policy administration integration being the longest lead item. Sandbox testing and user acceptance testing together consume 3-4 months, during which the insurer's APIs are tested against a reference Bima Sugam environment using synthetic data before the insurer is certified for production.

Intermediary onboarding follows a distinct workflow from insurer onboarding, reflecting the different roles that brokers, corporate agents, individual agents, and digital aggregators play in the distribution stack. The common thread is that every intermediary participating in Bima Sugam must hold a valid IRDAI licence in the applicable category, and the Bima Sugam profile is linked to that licence for automated verification of continuing registration.

IRDAI-licensed insurance brokers onboard by submitting their broker licence number, board-approved Bima Sugam participation resolution, key management personnel details, registered office address, and bank account for commission settlement. Once verified, the broker is issued Bima Sugam broker credentials that allow the broker to access the marketplace APIs for quotation aggregation, proposal submission on behalf of clients, and servicing. Brokers can choose to operate their own client-facing portal on top of Bima Sugam APIs or to direct clients to the Bima Sugam consumer interface while maintaining the commercial relationship through the broker-of-record function that Bima Sugam supports.

Corporate agents, governed by the Corporate Agents Regulations 2015 as amended, face the additional requirement of declaring their principal insurer relationships. Under Indian insurance regulation, a corporate agent may represent up to nine insurers across life, non-life, and health, and each principal relationship must be declared and reflected in the Bima Sugam profile. When a customer interacts with a corporate agent on Bima Sugam, the platform presents only products from the agent's principal insurers in the quotation results, respecting the regulatory boundary.

Individual agents onboard through a lighter-weight flow, submitting their IRDAI agent code and Aadhaar-based identity verification. The platform verifies the agent's licence status and associated insurer through the IRDAI agent database. Individual agents using Bima Sugam typically access the platform through a mobile application rather than a full browser portal, reflecting the predominantly field-based nature of the individual agent channel.

Commission sharing on Bima Sugam transactions follows the statutory commission caps under the IRDAI Payment of Commission Regulations 2023, with the specific commission rate determined by the insurer's filed tariff for each product. Bima Sugam itself does not charge a marketplace fee to intermediaries for transactions routed through the platform, which is a deliberate policy choice to ensure that the platform does not compete commercially with intermediaries. Commission settlement between insurers and intermediaries occurs through the insurer's normal settlement cycle, with Bima Sugam providing transaction records that feed into that settlement process.

Dispute escalation within the Bima Sugam framework operates in layers. First-level disputes between a policyholder and an intermediary are addressed through the intermediary's internal grievance redressal mechanism, which every IRDAI-licensed intermediary is required to maintain. Unresolved disputes escalate to the insurer's grievance redressal cell. Further escalation reaches the Insurance Ombudsman under the Insurance Ombudsman Rules 2017 for claims up to INR 50 lakh, with the ombudsman decision recorded in the Bima Sugam case history. Policyholders can also approach consumer forums under the Consumer Protection Act 2019, and the Bima Sugam record serves as an evidentiary artefact in those proceedings.

Products listed on Bima Sugam must be filed with IRDAI under the applicable file-and-use, use-and-file, or certification regime and must be published to the Bima Sugam catalogue through the product publishing API. Each listed product carries a standardised metadata schema covering product name, insurer, product type code (aligned with IRDAI's product classification), policy wording document reference, coverage summary, minimum and maximum sum insured, premium calculation rules or rate table, underwriting rules (acceptance conditions, exclusions by risk factor), servicing features (endorsements permitted, renewal terms), and claims procedure.

The product publishing workflow has two modes:

• Declarative mode, used for simple retail products with published tariffs, where the insurer publishes the full product definition including premium rates and underwriting rules, and Bima Sugam can compute quotations for end customers without calling the insurer's systems in real time. This minimises quotation latency and reduces load on the insurer's underwriting engine.
• Callback mode, used for products requiring real-time underwriting decisions, where the product definition includes placeholders for dynamic pricing, and Bima Sugam calls the insurer's quotation API with the customer's risk profile to return a priced quote.

Most life and health products use callback mode because of underwriting complexity; most motor and simple property products use declarative mode.

The sandbox environment replicates the production Bima Sugam core but uses synthetic data and insulated test infrastructure. Insurers and intermediaries use the sandbox for two distinct purposes. First, for initial integration testing: verifying that their API implementations conform to the published specifications, handle error conditions correctly, and meet the performance targets (typical latency budgets are 500ms for product catalogue queries, 2 seconds for quotation, 5 seconds for proposal submission). Second, for ongoing regression testing: when the insurer updates its policy administration system, pricing algorithms, or claim processing logic, the sandbox provides a non-production environment to validate that Bima Sugam integrations still function correctly.

User acceptance testing (UAT) timelines typically span 8-12 weeks for a new insurer onboarding, broken into four stages. Stage 1, functional testing, verifies that each API endpoint returns correct responses for valid requests and appropriate errors for invalid requests. Stage 2, scenario testing, walks through end-to-end customer journeys: a motor policy purchase with online payment and immediate policy binding, a health policy with underwriting callback and medical evidence requirements, a claims intimation with DigiLocker document retrieval. Stage 3, performance testing, subjects the insurer's APIs to load at expected production volumes to confirm that latency targets hold under realistic traffic. Stage 4, security testing, verifies authentication, authorisation, data encryption in transit and at rest, and resistance to common attack patterns.

Once UAT is passed, the insurer receives a production certification from the Bima Sugam operating entity and is whitelisted for live transactions. The first 30 days of production operation are typically observed closely, with transaction volumes ramped up gradually from a small percentage of overall traffic to full volume as operational confidence is established.

The claims workflow is the feature that most materially changes the policyholder experience under Bima Sugam, and it is also the area where insurers need to invest the most in process redesign to realise the intended customer benefit.

First Notification of Loss (FNOL) through Bima Sugam is designed as a one-click operation from the policyholder's perspective. The policyholder, authenticated through their Bima Sugam profile, selects the policy against which the claim is being filed from their policy list (which is automatically populated from their DigiLocker and from insurers that have published policy ownership records to the Bima Sugam claims registry). The platform pre-fills claim form fields from the policy data, requires the policyholder to enter loss details (date, location, nature of loss, estimated quantum), and accepts supporting documents uploaded from DigiLocker or the device.

Once submitted, the FNOL is routed to the insurer's claims management system through the claims API. The insurer acknowledges receipt within a defined SLA (typically 15 minutes for retail claims), assigns a claim number, and returns the next-step workflow to the policyholder through the Bima Sugam status tracker. For motor claims, the next step may be cashless repair at a network garage, with the Bima Sugam platform showing nearby empanelled garages based on the policyholder's location. For health claims, the next step may be pre-authorisation for cashless treatment at a network hospital, routed to the Third Party Administrator (TPA) managing the insurer's health portfolio. For property claims, the next step may be survey appointment scheduling with an IRDAI-licensed surveyor.

TPA routing deserves specific attention because TPAs sit between the insurer and the healthcare provider network for most group health and retail health claims. Bima Sugam integrates with the TPA's claims processing system through a separate set of APIs, so that a cashless pre-authorisation request submitted through the platform reaches the TPA's authorisation engine directly, and the TPA's decision (approve, request additional information, decline) flows back to the policyholder in real time. Insurers using multiple TPAs across different regions need to configure the claim routing logic so that each claim reaches the correct TPA based on policy type, geography, and network coverage.

Document handling through DigiLocker removes much of the friction in Indian claims processing. When a policyholder submits a claim for a motor accident, the policy document, driving licence, vehicle registration certificate, and FIR copy can all be fetched from DigiLocker with the policyholder's consent, eliminating the repeated scanning and uploading that characterised pre-Bima Sugam claims workflows. The insurer receives verified documents with cryptographic signatures from the issuing authority, which reduces fraud risk and speeds downstream verification.

Settlement tracking is maintained as a state machine visible to the policyholder in real time. The Bima Sugam claims tracker shows the current claim status (intimated, under investigation, approved, partially approved, declined, settled), the next action expected from the insurer or the policyholder, and the SLA clock for each stage. Insurers that fail to meet SLA commitments published in their Bima Sugam profile can be flagged by the platform, with repeated breaches surfaced to IRDAI as a supervisory data point.

For retail lines, the workflow is largely complete as designed in the 2024 Master Circular. For the commercial lines expected in phase 2, additional workflows will need to be built out: multi-party claims involving joint property ownership, claims against contract works insurance requiring engineer assessments, marine claims with surveyor and salvage coordination, and liability claims requiring defense counsel engagement. The operational complexity of commercial claims is materially greater than retail, and insurers should invest in claims process redesign now rather than waiting for phase 2 activation.

Bima Sugam operates in a data-intensive environment where personal data of policyholders, including sensitive financial and health data, flows between the platform, insurers, intermediaries, TPAs, and service providers. The Digital Personal Data Protection Act, 2023, which received Presidential assent in August 2023 and whose Rules were notified in 2024-2025, sets the legal framework within which this data processing must occur, and every Bima Sugam participant needs to align their operations with its requirements.

Under the DPDPA, the data principal is the policyholder, and the data fiduciaries are the insurer, the intermediary, and the TPA, each of which determines the purposes and means of data processing within their respective operations. Bima Sugam itself operates as a data processor for the transactional data flowing through the platform and as a data fiduciary for the platform's own records such as user profiles and transaction history. Consent must be obtained for each purpose of processing, must be free, specific, informed, unconditional, and unambiguous, and must be capable of being withdrawn with equivalent ease.

The consent architecture built into Bima Sugam reflects these requirements. When a policyholder grants consent for an insurer to fetch their Aadhaar KYC data, the consent is scoped to the specific insurer, the specific purpose (policy issuance or claims processing), the specific data categories (identity, address, photograph), and a specific time horizon. The consent record is stored in the Bima Sugam consent registry and is accessible to the policyholder for review and withdrawal. Similar consent flows exist for Account Aggregator data and ABDM health data.

Data localisation under the DPDPA requires that personal data processed in connection with the rights of Indian data principals be stored within India unless specifically permitted to be transferred outside. For Bima Sugam participants, this means that policy administration systems, claims databases, and intermediary CRM systems holding Indian policyholder data must be hosted on Indian cloud infrastructure or on-premises data centres located in India. Most Indian insurers have already moved to domestic cloud hosting for this and other regulatory reasons, but intermediaries and TPAs using global SaaS platforms may need to verify the hosting configuration of their systems.

Breach notification under the DPDPA requires that data fiduciaries notify both the Data Protection Board and affected data principals within prescribed timelines when a personal data breach occurs. Bima Sugam participants need to have incident response procedures integrated with their normal security operations, including runbooks for identifying a breach, assessing its scope, notifying the Data Protection Board, and communicating with affected policyholders. The penalty ceiling of INR 250 crore for serious breaches makes this a board-level risk that demands operational maturity.

Implementation governance for Bima Sugam participation should be owned by a named executive, typically the Chief Digital Officer or an equivalent role, with a cross-functional steering committee covering technology, operations, legal and compliance, claims, underwriting, and customer service. The steering committee should meet at defined intervals during the integration phase, with monthly board reporting on progress against the committed timeline. Key implementation milestones to report on include API integration completion by module, sandbox UAT pass, production certification, first production transaction, and operational metrics such as API uptime, latency, and claim SLA adherence.

Mid-sized insurers targeting the commercial lines phase 2 should assume an 18-24 month end-to-end implementation timeline from board approval to full operational readiness. The most common reasons for slippage are legacy core system integration complexity, underestimation of data quality issues that only surface during UAT, and insufficient attention to claims process redesign for the one-click FNOL experience. Commercial insurers that complete readiness before phase 2 activation will have a meaningful operational advantage when commercial products go live on the platform, and brokers serving commercial clients should be similarly preparing their servicing platforms to interoperate with Bima Sugam APIs.

Bima Sugam is not designed to replace existing intermediary channels. The IRDAI Master Circular is explicit that the platform operates alongside the traditional agent, broker, bancassurance, and direct channels, and that policyholders and intermediaries can choose whether to transact through Bima Sugam or through established channels. The practical effect is that Indian insurers and intermediaries will operate hybrid distribution models for the foreseeable future, with Bima Sugam taking an increasing share over time but not displacing other channels entirely.

For retail lines, the early evidence from phase 1 suggests that Bima Sugam is winning share in categories where policyholders were already shopping digitally: two-wheeler motor, standalone health, and term life. In categories where offline distribution remains dominant, such as first-time health policy purchases by older customers or commercial motor fleet policies for small transport operators, the traditional channels continue to drive most volume. Insurers need to manage both channels, which means maintaining parallel pricing, servicing, and commission structures while avoiding channel conflict.

Commercial insurance in phase 2 presents a different set of questions. Commercial lines are characterised by advisory complexity, customisation of cover, multi-location or multi-entity risk, and long-term relationships between risk managers and brokers. Whether a unified marketplace can support that advisory-heavy model without becoming a commodity price comparison tool is an open question, and the design of Bima Sugam for commercial lines will need to accommodate features that retail products do not require: broker-of-record continuity across renewals, complex quote-slip workflows with multiple insurer participations, policy bespoke endorsements, and claim handling that often extends over years.

The current expectation, based on IRDAI working group discussions and the phase 2 roadmap as publicly outlined, is that commercial products on Bima Sugam will initially focus on standardised SME covers where the product complexity is bounded: shopkeeper and office package policies for small businesses, standardised commercial motor fleet covers, group health for SMEs, and standardised cyber covers for small and mid-sized enterprises. Larger corporate risks (major property accounts, complex liability towers, specialty covers) are likely to remain primarily on traditional channels even after phase 2, with Bima Sugam potentially providing administrative infrastructure such as policy record-keeping and claim tracking without being the primary transaction channel.

For brokers serving commercial clients, the strategic implication is that Bima Sugam readiness is a complement to, not a substitute for, their existing capabilities. Brokers should invest in the API integration and operational capability to serve clients who prefer Bima Sugam workflows, particularly for SME segments where that preference is likely to emerge first, while continuing to build the advisory depth that large corporate clients value. The broker-of-record function within Bima Sugam, which allows a broker to retain servicing rights on a policy even when the transaction touches the marketplace, is the key commercial protection that brokers should ensure is in place before commercial lines activation.

For insurers, the operational readiness work is not optional. IRDAI has signalled that participation in Bima Sugam will become effectively mandatory for insurers offering the covered product lines, and supervisory expectations around SLA adherence, data quality, and customer experience metrics will be enforced through the normal supervisory review process. Insurers that treat Bima Sugam as a discretionary project risk finding themselves behind the readiness curve when commercial lines activate, and playing catch-up on regulator-facing technology delivery is an expensive and reputationally risky position. The window between retail phase 1 and commercial phase 2 is a preparation window, and the insurers who use it effectively will find the phase 2 transition manageable rather than disruptive.