90 Days or 120: The Eligibility Test That Decides Which Gig Workers Actually Get Covered

Two numbers in the draft central rules under the Code on Social Security, 2020 pull in opposite directions, and the gap between them is where an aggregator's insurance spend now lives.

On the contribution side, the test is turnover. Aggregators pay 1 to 2 per cent of annual turnover into a dedicated Social Security Fund, capped at 5 per cent of the payments made to gig and platform workers. Nothing in that formula asks how long any individual worker has been on the platform. Every rupee paid to a first-week rider counts toward the base on which the levy is computed.

On the benefit side, the test is engagement time. As reported by NewsX on the draft rules, a gig worker must have been engaged for at least 90 days with a single aggregator, or 120 days across multiple aggregators, in the preceding financial year to access benefits under the scheme. The worker who joined in February and stopped in April contributed to the levy base and qualifies for nothing.

That asymmetry is the entire commercial question. The platform has already paid on the whole payout pool. The statutory scheme will answer for a subset of it. The rest of the rider base sits in an uncovered band that the platform still owns operationally, reputationally, and in most negligence claims. The Social Security Fund levy is not a group personal accident policy, and the eligibility threshold is the sharpest illustration of why.

The Press Information Bureau note on social security for gig and platform workers confirms that the Code on Social Security, 2020 came into force on 21 November 2025 and provides for life and disability cover, accident insurance, health and maternity benefits, and old age protection for gig and platform workers.

That is a wide benefit menu, and it is worth being precise about its status. The Code sets the enabling frame; the schemes that populate it are framed by the central government, and the draft rules notified on 30 December 2025 carry the contribution mechanics and the engagement test. Between the framework and a paid claim sit scheme notifications, fund administration, and registration data.

Registration is the practical gate. The PIB has said that twelve major aggregators have been onboarded, including Zomato, Blinkit, Urban Company, Uber, Amazon, Ola, Swiggy, Ecom Express, Rapido, Zepto and Porter, and that over five lakh gig and platform workers are registered on e-Shram. Against a gig workforce measured in crores, five lakh registrations is an early number, not a steady state. A worker who clears 90 days but never completed e-Shram registration is, in benefit terms, indistinguishable from a worker who never qualified.

"Uncovered riders" is too coarse a category to buy insurance against. Run the eligibility test across a live rider base and four distinct populations fall out, each with a different risk profile and a different answer.

1. Long-tenured and registered. Past 90 days with the platform, on e-Shram, inside the scheme. The statutory layer is live here, and the commercial question is what it does not reach: sum insured adequacy, income continuity during recovery, and speed of settlement.
2. Long-tenured and unregistered. Past 90 days, but never completed e-Shram. Functionally uncovered by the scheme despite qualifying on time. The cheapest fix is onboarding operations, not underwriting.
3. Multi-homing riders. Working across two or three platforms, short of 90 days on any one of them, potentially past 120 days in aggregate. Eligible in principle, but only if cross-aggregator engagement is actually captured and reconciled. This is the hardest population to evidence and the one most likely to discover its status only at claim stage.
4. Short-tenure and seasonal. Under both thresholds. Festival-season surge riders, exam-period students, monsoon-quarter joiners. In quick commerce and food delivery, where churn is high, this band is not a rounding error.

The fourth group carries a risk characteristic that matters more than its size. Riders in their first weeks are still learning routes, app handling and load management, which is the profile motor and personal accident underwriters treat as higher frequency. The population the statutory scheme excludes is the one a rider-safety programme would target first.

The obvious instinct is to fold uncovered riders into the platform's existing employee group health policy. It does not work, and the reason is structural rather than commercial.

As Plum sets out in its guidance on gig worker eligibility, gig workers are generally not eligible for an employer's group health insurance, because IRDAI group policies require a formal employer-employee relationship. The platform's entire operating model is built on the absence of that relationship. Extending the corporate group medical policy to riders either fails underwriting on group definition or, worse, is accepted at placement and disputed at claim, when the insurer examines the employment evidence behind a rider's admission.

The workable route is a group formed on a basis other than employment. Indian insurers write group personal accident and group health on non-employer groups where a genuine common bond exists and the group was not formed solely to buy insurance. A platform's active-rider register, defined by contract and refreshed monthly, is the practical basis. What matters is that the policy wording defines the insured group by the same criterion the platform can evidence at claim stage, whether that is an active service agreement, a trips-in-period threshold, or an app status flag.

The structures now appearing in the Indian market for the sub-threshold band share a common shape: commercial group personal accident as the floor, with health layered selectively above it.

Group personal accident as the universal floor

GPA is the layer that goes to every active rider from day one, because it is the layer the eligibility threshold most obviously leaves exposed and the one most closely tied to the actual hazard of the work. Structuring decisions that recur:

• Declaration basis rather than named lives. Monthly declaration of active rider counts, with premium adjusted at period end. Named-life schedules cannot keep pace with churn on a delivery or quick-commerce rider base.
• Sum insured banded by engagement tier, so cover starts at a floor for every active rider and steps up with tenure rather than switching on at a cliff edge.
• Cover triggered by app state, not by shift roster, with the on-duty definition written to the platform's own logs.
• Temporary total disablement as a weekly benefit, since income interruption, not medical cost, is what a rider off the road for six weeks actually faces.

Health above the floor

Group health is where the eligibility line is doing real economic work. Extending indemnity health to a workforce with high churn is expensive per covered day when the average engagement is short, so the common pattern is a lower-cost benefit for the whole base (accident hospitalisation, daily cash, OPD or teleconsultation) with fuller indemnity health reserved for riders past a tenure trigger, often set to match or slightly precede the statutory 90-day mark.

Where the statutory scheme becomes live and reliable for the long-tenured band, the commercial health layer above it can be re-cut rather than removed. That renegotiation, not duplication, is what a platform should be preparing for at its next renewal. The structuring detail sits in the GPA structuring guide for gig platforms.

The 120-day cross-aggregator route is the most generous branch of the eligibility test and the least likely to be exercised, because no single party has both the incentive and the data to prove it.

A rider doing four days a week on one platform and two on another may comfortably exceed 120 days across the financial year while never approaching 90 on either. Establishing that requires engagement records from two or more aggregators, keyed to the same worker identity, and reconciled without double counting a day worked on both platforms. e-Shram registration is the natural spine for that identity, which is one more reason registration coverage matters beyond compliance box-ticking.

For the aggregator, the practical consequences are narrower than the policy question but immediate:

• Multi-homing riders should not be assumed into the statutory-covered band when sizing commercial cover. Model them as uncovered until aggregate engagement is demonstrably being captured.
• Engagement records should be produced in a form a worker can actually use, since the burden of proving 120 days falls on the person least equipped to assemble it.
• Claim-stage surprises are the reputational risk. A rider who believed the scheme covered him, discovers at hospital admission that his days were never aggregated, and finds the platform's commercial policy also excludes him is the scenario that generates the news story.

The cleanest defensive position is a commercial floor that does not ask whether the statutory scheme applies. Cover the active rider, settle the claim, and treat any statutory recovery as a downstream reconciliation rather than a precondition.

One risk the eligibility test does not touch at all is the platform's own liability, and it is worth separating cleanly because it is frequently conflated with rider welfare in board discussions.

The Code's benefits, where they apply, run to the worker. They do nothing about a third party injured by a rider, a consignment lost in transit, a service performed badly in a customer's home, or a claim that the platform's dispatch algorithm or incentive design contributed to unsafe riding. Those are claims against the aggregator, brought by someone who never had a relationship with the Social Security Fund.

That exposure is unaffected by whether the rider had cleared 90 days. A first-week rider and a three-year veteran generate identical liability profiles from the platform's perspective, and arguably the newer rider generates a higher one. Public liability, third-party motor beyond the statutory minimum, professional indemnity for services-led platforms, and goods-in-transit cover for the delivery leg belong on a separate track from the welfare stack. The detail is in the note on aggregator liability insurance.

A platform that reads the Code's arrival as a reason to reduce liability cover has read the wrong half of the document. The Code allocates worker benefits. It does not allocate fault.

The eligibility test looks backward at the preceding financial year, which makes the current year the one being scored. A sequence that fits the calendar:

1. Run the eligibility split on your own data. Take the last twelve months of engagement records and count how many active riders clear 90 days with you. That single percentage sets the size of the commercial layer, and most platforms guess it high.
2. Measure the e-Shram registration rate inside the qualifying band. Time-eligible but unregistered is the cheapest gap to close and the most embarrassing to discover at claim stage.
3. Read your group definitions against reality. Confirm the insured-group clause in every rider-facing policy matches a status your systems can produce, dated, at claim stage.
4. Set the commercial GPA floor at day one, not at a tenure trigger. The uncovered band is skewed toward newer riders, and newer riders are the ones on unfamiliar routes.
5. Separate the welfare stack from the liability stack in your renewal papers. They respond to different claimants and should not be traded off against each other in a single budget line.
6. Preserve engagement records in a worker-usable format. For multi-homing riders, the platform's record is one of the two or three inputs that make the 120-day route real.

An aggregator that has filed its contribution and stopped there has bought a levy, not a cover programme. The band below the threshold is where the claims will land first.