Bima-ASBA Is Live. Your Policy Issuance Workflow Isn’t.

A mid-size life insurer in western India with 2 million active policies called us in with a specific complaint: customer support ticket volume had increased 40 percent since they enabled Bima-ASBA on their direct channel in March 2025. The most common ticket type: “I applied for a policy, the money was blocked from my account, but I never received my policy documents.” The payment was working. The workflow wasn’t. IRDAI mandated Bima-ASBA — the UPI-based application-supported-by-blocked-amount mechanism — with effect from March 1, 2025. Every life and health insurer had to offer it. Most of them implemented it by connecting a new payment API and routing customers through a UPI mandate creation screen. The policy issuance workflow behind that screen remained unchanged. Eighteen months later, the gap between a compliant payment screen and a compliant workflow is producing customer experience failures, regulatory scrutiny, and customer support costs that erode the efficiency gains the digital channel was supposed to provide.

The Mismatch IRDAI Created When It Changed the Payment Sequence

The traditional insurance payment sequence is linear: customer submits proposal, pays premium, insurer reviews proposal, policy is issued or rejected, premium is refunded in the rejection case. Payment and proposal submission happen together. The insurer receives funds before underwriting begins.

Bima-ASBA changed this sequence in a specific way. The customer submits a proposal and authorizes a UPI mandate to block the premium amount in their bank account. The block is created immediately. The insurer completes underwriting. If the proposal is accepted, the insurer debits the blocked amount and issues the policy. If the proposal is rejected, the block is released and no debit occurs. NPCI’s mandate infrastructure supports a block duration of up to 6 months, but IRDAI’s guidelines expect debit or release within the underwriting completion window, typically 24 to 48 hours.

This sequence has four distinct states: proposal submitted, premium blocked, underwriting completed, and policy issued or proposal rejected. Between proposal submitted and policy issued, 24 to 48 hours can pass during which the customer has a block on their bank account but no insurance coverage. The customer experience during this window is entirely determined by notification design and state transparency. Most insurers provided no intermediate state visibility. The customer checked their bank app, saw a blocked amount with a label they did not recognize, and called support.

Why Patching the Payment Screen Was the Wrong Response

The payment screen change was necessary but not sufficient. A policy issuance system that was built for simultaneous payment and approval has a state machine that looks like this: submitted, paid, issued, or rejected. There is no state for “premium blocked, underwriting pending.” There is no state for “debit ready, awaiting policy document generation.” There is no state for “underwriting rejected, release pending.”

When Bima-ASBA introduced a 24 to 48 hour gap between block creation and debit or release, the patched systems had no state to put the proposal in during that gap. Different insurers solved this differently, and most of the solutions produced edge cases. Some put the proposal in a generic “processing” state with no expected completion time. Some left the proposal in “submitted” state even after the payment block was created, making the payment confirmation invisible to the customer. Some created a custom “mandate created” state but did not wire it to customer notifications because the notification workflow did not have a handler for that state.

The insurer we worked with had three separate cases where the mandate block was created, underwriting completed in favor of issuance, but the automated debit failed because the NPCI debit request was sent after the mandate block had expired due to an internal processing delay. The customer’s premium block was released. The policy was never issued. The customer was not notified. They discovered it when they tried to file a claim.

Redesigning the Policy Issuance State Machine

A production-grade Bima-ASBA-compliant policy issuance workflow requires a formal state machine with explicit transitions, timeouts, and notification triggers at each state boundary.

The states in a correctly designed system are: **Draft** (proposal started, not submitted), **Submitted** (proposal submitted, mandate creation initiated), **Mandate Created** (UPI block confirmed, awaiting underwriting), **Underwriting In Progress** (proposal under review), **Approved Pending Debit** (underwriting approved, debit authorization ready), **Policy Issued** (debit completed, policy documents generated and delivered), **Rejected Pending Release** (underwriting rejected, release request sent), **Released** (mandate released, refund confirmation delivered to customer), and **Expired** (mandate block expired before processing completed, recovery workflow triggered).

Each state transition has a defined trigger (event or timeout), a notification payload (what the customer receives), and an escalation path if the transition does not complete within its expected window. The “Expired” state is critical: it captures the failure mode where the system did not process the proposal within the block window, triggers an internal alert for manual recovery, and sends the customer a specific notification that is different from a rejection notification.

The insurer rebuilt this state machine with us over eight weeks. Customer support tickets related to Bima-ASBA dropped 78 percent. The average time between proposal submission and policy document delivery dropped from 31 hours to 14 hours because the state machine made processing delays visible in real time and triggered escalations when SLAs were at risk.

The Insurance Workflow State Machine Model (IWSMM)

The IWSMM is a design framework for auditing and rebuilding insurance policy lifecycle workflows to handle regulatory state changes without creating edge case failures. It has four components.

State inventory. Document every state a proposal or policy can be in across your current system. Include states that are not formally named but exist in the database as status field values. Most insurers find 40 to 60 percent more states than their technical documentation describes.

Transition completeness check. For each state, list every possible next state and the trigger that causes the transition. Mark transitions that are not handled explicitly. Unhandled transitions default to inaction — the proposal stays in its current state indefinitely. Bima-ASBA created at least three new transitions in every insurer’s workflow that most did not handle explicitly.

Notification coverage audit. For each state transition, identify what the customer, agent, and operations team are notified about, through what channel, at what point in the transition. Transitions without notifications produce support tickets. Transitions with incorrect notifications produce complaints and regulatory risk.

Timeout and recovery mapping. For each state, define the expected maximum time before the next transition must occur. Define what happens when that timeout is exceeded: customer notification, internal escalation, automatic recovery action, or manual queue routing. Bima-ASBA’s block expiry creates hard timeouts that most policy issuance systems were not designed to handle.

Use this framework before implementing any IRDAI regulatory change, not after support tickets reveal the gaps.

IRDAI’s “Insurance for All” Direction and the Next Workflow Changes

Bima-ASBA is one part of IRDAI’s broader “Insurance for All by 2047” initiative. Bima Sugam, the centralized digital insurance marketplace, has been in development since 2022 and continues to evolve. The Bima Vahak rural distribution program expands the agent workflow requirements for policy issuance in low-connectivity environments. Each of these initiatives changes the policy issuance workflow in ways that a patched legacy system cannot absorb.

The insurers building correctly now are those who recognized that Bima-ASBA was not the last IRDAI workflow mandate. They rebuilt their state machines to be modifiable: each state is a configurable record, each transition is a configurable rule, and each notification is a template that can be changed without a code deployment. When the next regulatory change arrives, the workflow can absorb it in days rather than months.

This is the compounding advantage of a state machine architecture over a patched monolith. The first rebuild is expensive. The second regulatory change is cheap. The third is nearly free.

What This Means for Insurance Leaders

IRDAI’s digital transformation agenda is not slowing. Every initiative in the Insurance for All roadmap introduces workflow state changes. The cost of building a state-machine-capable policy issuance platform now is lower than the cumulative cost of patching it through four more regulatory cycles.

Three things you can do this week. First, pull your customer support ticket data and identify tickets related to premium payment status, policy document delays, and blocked amounts. The volume and type of these tickets maps directly to state machine gaps. Second, test your own Bima-ASBA flow by submitting a test proposal and documenting every notification you receive and when, from mandate creation to policy issuance. If you cannot trace the customer’s experience in your own system, your customer cannot either. Third, ask your engineering team to name every state a proposal can be in between submission and policy issuance. If the answer has fewer than seven states, your state machine is not modeling the full workflow.