Introduction

Bima Sugam Phase 2 is expected to go live in 2026, adding claims intimation, third-party integrations with hospitals and TPAs, health data APIs via ABDM, and policy portability workflows to the platform that IRDAI is positioning as India’s “UPI moment” for insurance. For a private life insurer, Tier-2 by premium volume, this is not a product decision. It is a systems architecture decision, because the question is not whether to integrate with Bima Sugam but whether your policy core can expose the APIs that Phase 2 requires. For more than 70% of Indian insurers still running legacy policy administration systems, the answer today is no, and the time to address that gap is now, not when Phase 2 audits begin.

What Bima Sugam Phase 2 Actually Requires from Your Backend

The first phase of Bima Sugam handled policy issuance and KYC through standardized APIs against India Stack. Phase 2 goes further and exposes the latency limitations of legacy batch architectures:

Claims intimation API: Accept a claim notification from a policyholder through the Bima Sugam interface, validate the policy, and return a claim acknowledgment with a reference number. The latency expectation is real-time, not batch.

TPA and hospital integration: For health insurance, route claim pre-authorization requests to TPAs via the platform’s standardized interface and receive approval or rejection within a defined SLA.

Portability workflows: Allow policyholders to initiate porting of a policy from one insurer to another through the platform, requiring your system to expose policy data in IRDAI-specified formats on request.

Health data APIs: Integrate incoming health records from ABDM-connected providers as supporting evidence for claims, requiring your system to receive structured health data and associate it with the correct policy record.

Each of these requires your policy core to respond to external API calls synchronously. If your core system runs on batch processing cycles, a claims intimation call at 11:47 AM may not be processed until the next batch window at 2:00 PM.

> Bima Sugam does not care about your batch claims processing cycle. It expects an API that returns in under two seconds.

This is the architectural mismatch that Phase 2 exposes. Legacy policy administration systems were designed around overnight batch cycles and internal screen-based access. Bima Sugam’s API model assumes real-time, event-driven policy data availability.

The Layered Modernization Trap

The standard advice for insurers who cannot afford a five-to-seven-year core replacement is layered modernization: build a digital experience platform on top of the legacy core and expose APIs from the DXP layer that translate between Bima Sugam’s expectations and the core’s batch processing reality.

This approach works for Phase 1. Phase 2 tests its limits directly.

A DXP sitting above a legacy core can make the core’s data available through an API. It cannot change the underlying processing model. If the legacy core writes a claims record to the database at the end of a batch job, the DXP can surface that record via API, but it cannot surface it before the batch job completes.

For claims intimation under Phase 2, this creates a visible SLA gap. Insurers who respond slowly will face customer complaints that aggregate on the Bima Sugam platform, visible to IRDAI. The platform’s design, like UPI, is intended to create transparent competitive pressure through published performance data across all participants.

> Layered modernization is not a strategy. It is a temporary architectural position with a deadline.

The deadline, in this case, is the first Bima Sugam compliance audit cycle after Phase 2 launch. Phase 1 compliance will not exempt you from Phase 2 performance requirements.

What Event Sourcing Changes

The modernization path that extends the useful lifetime of a layered approach is event sourcing at the core. Instead of a legacy system that writes final state to a policy record, an event-sourced system records every state transition as an immutable event. The current policy state is derived by replaying the event log.

This matters for Bima Sugam integration because: claims intimation triggers a state transition event that is written synchronously, so the claim acknowledgment can be returned immediately before downstream processing completes. Portability requests become a stream of events that can be replayed on the receiving insurer’s system to reconstruct policy history without a direct database export. IRDAI audit requirements for data lineage are satisfied by the event log itself, rather than requiring separate audit trail tables or retrofitted logging.

We worked with a private life insurer, Tier-2 by premium volume, preparing for Bima Sugam Phase 2 with approximately 3.4 million active policies on a legacy policy administration system from 2009. A full core replacement was budgeted for 2028. The Phase 2 requirement exposed a gap they could not bridge with layered modernization alone, specifically the claims processing latency SLA.

The approach: introduce an event streaming layer (Apache Kafka) between the legacy core and the DXP, instrument the legacy core to emit events on every write operation through a change data capture connector, and build the Bima Sugam integration against the event stream rather than directly against the legacy database. Claims intimation calls write to Kafka synchronously. The legacy core consumes events and updates its records in the background. The DXP reads from the event stream.

Claims acknowledgment latency dropped from batch-cycle hours to under 800 milliseconds. The legacy core continued to operate unchanged. The core replacement project continued in parallel on its original timeline.

This is not a permanent solution. It is a structural bridge that achieves Phase 2 compliance while the replacement program runs in parallel.

The Insurance Core Modernization Sequence (ICMS)

This is the four-phase sequence we use with insurance clients facing simultaneous Bima Sugam compliance pressure and longer-term core replacement plans:

Phase 1: API Façade (2 to 4 months): Build a managed API gateway above the legacy core. Expose policy inquiry, claim status, and KYC verification endpoints that Bima Sugam Phase 1 requires. No changes to the core system. This phase delivers Phase 1 compliance and provides the integration surface that Phase 2 will extend.

Phase 2: Event Bridge (3 to 6 months): Introduce an event streaming layer. Instrument the legacy core to emit events on write operations, using change data capture where direct instrumentation is not feasible. Build the Bima Sugam Phase 2 integration against the event stream for low-latency claims intimation and portability flows. This phase achieves Phase 2 API latency compliance without core replacement.

Phase 3: Strangler Fig Migration (12 to 36 months): Migrate core policy administration capabilities to a modern system, one product line or functional domain at a time. Route traffic to the new system as each domain is validated. The event stream becomes the integration backbone between old and new systems during migration.

Phase 4: Legacy Decommission

Retire the legacy core when all traffic has migrated. The event log becomes the long-term archive for historical policy data, satisfying IRDAI record retention requirements.

> A core replacement takes five to seven years. A Bima Sugam integration built on a legacy core can be rendered obsolete in the first Phase 2 audit.

The ICMS delivers immediate Bima Sugam compliance through Phases 1 and 2 while building toward decommission through Phases 3 and 4, rather than treating them as programs that compete for budget and attention.

IRDAI Data Governance Requirements Add Compliance Pressure

Beyond Bima Sugam, IRDAI’s data governance mandates are tightening in parallel. The “Insurance for All by 2047” vision requires standardized data across rate regulation, claims governance, and coverage design. IRDAI mandates around data storage, consent, and auditability require insurers to adopt compliant digital architectures with unified data foundations.

For legacy system insurers, this translates to a concrete requirement: every policy operation must be auditable, with a record of who made what change, when, and why. Legacy systems built for internal screen-based access do not always produce the audit trail granularity that IRDAI digital compliance requires. Retrofitting audit logging to a legacy core is expensive and often incomplete.

The event sourcing layer in the ICMS serves double duty: it enables real-time Bima Sugam integration and produces the immutable audit trail that IRDAI compliance requires, as a structural property of the architecture rather than a separate logging system bolted on.

Reading the Bima Sugam Phase 2 Rollout for Engineering Signals

Bima Sugam Phase 2 is adding third-party integrations with hospitals and TPAs, health data API connections through ABDM, and policy portability workflows. Each of these integration categories has specific technical implications:

Hospital and TPA integration requires your claims routing logic to map procedure codes to the correct TPA based on policy type and network agreements. If this logic lives in a legacy system with no API surface, it cannot be called in real time from the Bima Sugam platform.

ABDM health data integration requires your system to accept structured health records in the FHIR format that ABDM-connected providers generate. Legacy systems that store claims supporting documents as scanned PDFs have no mechanism to ingest structured health data without a purpose-built integration layer.

Policy portability requires your system to export a complete, structured policy history in IRDAI-specified formats within a defined response time. This is not a report that runs overnight. It is an API call that must complete in seconds.

What this means for Insurance and InsurTech leaders

Bima Sugam Phase 2 is not the last API surface IRDAI will require. It is the first one with a hard latency test that legacy batch architectures fail by design.

The step you can take this week: ask your policy administration team how long it takes your system to acknowledge a claims intimation request, from the moment a policyholder submits to the moment your system returns a reference number. If the answer is measured in minutes or hours, or if no one knows the precise answer, that gap is the ICMS Phase 2 problem stated in concrete terms.

More Blogs: DIKSHA 2.0 Added Offline Downloads Last Week. Building What Comes Next Takes More