The Code on Social Security and Aggregator Cover: Pricing Group Insurance Off a 1 to 2 Percent Turnover Levy

For five years the aggregator contribution under the Code on Social Security, 2020 was a clause on paper. That changed when the operational machinery caught up. The Code's provisions were brought into force in stages, and the Social Security (Central) Rules took effect in early May 2026, putting the aggregator contribution on a live footing. The operational trigger followed: the Ministry of Labour and Employment directed online aggregators to complete onboarding and API integration of platform workers on the e-Shram portal by June 21, 2026, citing penalties under the Code for non-compliance. Major platforms including Zomato, Swiggy, Uber, Zepto, Ola, Amazon and Urban Company were named among those the directive targets.

The number that matters to a broker sits in Section 114. An aggregator must contribute at a rate not less than one percent and not more than two percent of its annual turnover, subject to a ceiling that the contribution cannot exceed five percent of the amount paid or payable to its gig and platform workers. The Central Rules clarified the base: turnover excludes taxes, cess and surcharges payable to the central government, which materially shrinks the contribution pool for the largest platforms.

For brokers, the shift is structural, not cosmetic. Platform welfare used to be a voluntary group personal accident top-up an aggregator bought to look responsible. It is now a statutory, contribution-funded obligation with a defined funding source and a regulator watching the e-Shram numbers. The client's question has changed from should we buy cover to how do we deploy a fixed levy into a programme that actually pays claims, satisfies the Code, and survives an audit. That is a placement and design problem, which is where a broker earns the fee.

The single most useful reframing for an aggregator client is this: the 1 to 2 percent turnover contribution is not a tax that disappears into a government fund. Under the Code it funds a social security scheme for gig and platform workers, and the natural mechanism for life, disability, accident and health benefit is group insurance placed with IRDAI-licensed insurers. So treat the levy as a premium budget and work backwards to a benefit design that fits inside it.

Start with the arithmetic the client controls. Two figures bound the contribution: the turnover-based amount (1 to 2 percent of qualifying turnover, net of taxes and cess) and the five percent cap on amounts paid to workers. Whichever basis the client opts for, the broker should model both before designing benefits, because a marketplace where worker payouts are modest relative to turnover will hit the five percent cap and have a smaller pool than the headline turnover percentage suggests.

From the modelled pool, allocate. A defensible split for a delivery or ride-hailing fleet typically loads accident death and permanent disability first (the highest-frequency, highest-severity exposure for two-wheeler riders), then a hospitalisation or health layer, then income-replacement for temporary disability. Treat the premium as the constraint and the sum insured as the variable, not the other way round. That discipline keeps the programme inside the levy and avoids the trap of promising benefits the contribution cannot sustain across a full claims year.

Eligibility is where most aggregator programmes will trip. The Central Rules tie benefit entitlement to engagement, not headcount. A gig or platform worker qualifies only if they are at least 16 years old and have worked at least 90 days with a single aggregator in the previous financial year, or 120 days where they are associated with multiple aggregators. That single sentence creates three live underwriting issues a broker must surface before binding.

First, the insured population is a moving census. Platform fleets churn hard; a rider active in March may be gone by July. A group policy priced on a static peak headcount will over-state exposure and over-pay premium, while one priced on a trough will leave eligible workers uncovered. The fix is a declaration-basis or floater structure with monthly or quarterly census reconciliation against the e-Shram and platform engagement data the client already holds for the contribution calculation.

Second, the 90-versus-120-day split means a worker on multiple platforms can be eligible against one aggregator and not another. Brokers should press clients on whether their benefit design covers the worker or the engagement, and document it in the policy wording so a claim from a multi-app rider does not turn into a coverage dispute about which platform owed the benefit.

Third, the financial-year look-back means eligibility is determined retrospectively. A worker who crosses 90 days in FY 2025-26 is eligible in the next cycle. Build the policy period and the eligibility certification around the financial year, not the calendar year or the policy inception date, or the certificate of insurance issued to a worker will not line up with the statutory entitlement window. Aligning the census, the contribution base and the policy schedule to one financial-year clock is the cleanest way to keep all three documents telling the same story.

An aggregator does not get to treat the Code on Social Security contribution as the whole of its workforce risk transfer. Brokers must place the platform-worker programme alongside, not instead of, the employer's other statutory and common-law exposures, and explain the boundaries clearly to a client that would prefer to believe one levy buys total peace.

The contribution-funded scheme addresses gig and platform workers as defined by the Code. It does not extinguish liability toward warehouse staff, full-time employees, or anyone who falls inside an employer-employee relationship, where the Employees' Compensation Act exposure and the OSH Code employer-liability duties still bite. A quick-commerce operator running both dark-store employees and gig riders carries two distinct risk pools, and a broker who conflates them will leave a gap on one side.

The practical placement, then, is layered. The Code contribution funds the statutory group benefit. A separate workers compensation or employer liability cover sits behind the formal-employee population. And a public or third-party liability wrap addresses the harm a rider causes to the public, which the welfare scheme never touches. Selling these as one product is a disservice; mapping them as a stack is the advice a corporate risk manager is paying for.

Group policies for platform workers are being written against rules that are weeks old and certain to be amended. That argues for wordings that are statute-aware without being statute-fragile. A few drafting positions are worth fighting for at placement.

Pin eligibility to the engagement test, not to a named list. Rather than scheduling individual riders, define the insured group by reference to workers meeting the Code's 90-day or 120-day threshold in the relevant financial year, reconciled to the client's e-Shram register. This keeps the policy synchronised with statutory eligibility as the census churns, and it avoids stale schedules that exclude a newly eligible worker or cover a departed one.

Get the disability definitions right. The highest-volume claims for delivery and ride fleets are accident-driven permanent and temporary disability, not death. Insist on clear permanent total, permanent partial and temporary total disablement triggers, a stated sum insured ladder, and an income-replacement basis that reflects gig earnings rather than a notional salary. Vague disability language is where these claims get litigated.

Kill the silent exclusions. Two-wheeler riding, third-party app use and multi-platform work are the operating reality of this population. Any exclusion for hazardous conveyance or for off-platform activity needs to be examined and, where possible, bought back, because a delivery rider injured between two app jobs should not fall into a coverage no-man's-land. Equally, define what counts as an insured engagement so a claim is assessed against the worker's actual activity.

Finally, build in an amendment hook. A short endorsement clause allowing mid-term realignment of benefits if the Central or a State government revises contribution rates or benefit floors lets the programme track the law without a fresh placement. Given how fast this area is moving, an endorsement mechanism is not a nicety, it is risk control.

Pricing a platform-worker group scheme is genuinely hard, because the actuarial history insurers rely on for conventional group personal accident does not map cleanly onto a churning two-wheeler delivery fleet. Brokers who walk into the market with the right data set will get sharper terms; those who do not will absorb a loading for uncertainty.

The insurer's underwriting team will want exposure measured in engagement, not just headcount. Active-rider counts by month, average days worked, two-wheeler versus four-wheeler split, urban versus highway mix, and night-shift proportion all move the accident frequency. A platform that can show its e-Shram and engagement telemetry, the same data feeding the contribution calculation, is handing the underwriter a credible rating base instead of a guess.

Claims experience is the other lever. Where an aggregator already ran a voluntary group personal accident programme, three years of loss runs are worth real basis points. Where it did not, the broker should benchmark against published delivery-sector accident data and price conservatively, then renegotiate at renewal once genuine experience exists.

There is a negotiating angle here worth pressing. Because the levy caps the premium pool at a known percentage of turnover or worker payments, an insurer knows the scheme cannot be hollowed out by under-funding. Framed well, that statutory floor is a selling point that should compress the rate, not a constraint that inflates it.

Watch the moving parts that distort pricing: the turnover base nets off taxes and cess, the five percent cap can bind before the turnover percentage does, and any deductible or co-pay on the health layer changes the net premium the levy must fund. Model the net premium against the modelled contribution pool and leave a margin for census growth, because a fleet that doubles riders mid-term will blow a tightly-priced scheme.

A platform-worker programme is judged at the claim, and this population claims differently from a conventional corporate group. The claimant is often a low-income rider or that rider's family, frequently after a road accident, with patchy documentation and limited ability to chase paperwork. A scheme that pays slowly is, for these claimants, a scheme that did not exist.

Design for that reality. Push for cashless hospitalisation on the health layer and for a fast-track accident-death and permanent-disability process with a documentation list the worker can actually produce: e-Shram registration, platform engagement record, FIR and medical reports. The broker should pre-agree the evidence standard with the insurer so a claim is not stalled because a gig worker cannot produce an employment letter that never existed.

Nominee and beneficiary capture is the quiet failure point. If a rider dies and there is no recorded nominee, a valid death benefit can sit unpaid for months. Brokers should make nominee registration part of the e-Shram onboarding flow the client is building anyway, so the beneficiary is known before the claim, not discovered after a dispute.

Get the surveyor and adjuster posture right for volume. Conventional loss adjuster processes built for a handful of large industrial claims do not scale to thousands of small accident claims across a national fleet. Agree a streamlined assessment protocol and clear authority limits for routine disability claims, escalating only the contested or high-value ones. Track the indemnity outcomes and turnaround times, and bring that data to renewal. A demonstrably fast-paying scheme is both better compliance and a stronger negotiating position, because it proves the levy is buying benefit that reaches workers rather than premium that funds an unused policy.

The compliance clock has already turned. With the e-Shram onboarding deadline of June 21, 2026 now behind us and the Central Rules live since early May, an aggregator that has registered its workers but not yet structured the welfare benefit is exposed and knows it. This is the moment for a broker to convert a regulatory obligation into a placed programme, and the conversation should be specific.

Lead with the funding model. Show the client the two contribution bases side by side, the turnover percentage net of taxes and cess against the five percent cap on worker payments, and identify which one actually sets their premium budget. That single piece of analysis reframes the whole engagement from compliance cost to benefit design.

Then propose the stack, not a single policy:

1. A statutory group life, accident and disability benefit for eligible gig and platform workers, funded from the contribution and priced inside the cap.
2. A health or hospitalisation layer, ideally cashless, sized to the residual pool.
3. A separate employer liability or workers compensation cover for the formal-employee population the Code does not reach.
4. A third-party and public liability wrap for harm riders cause to others.
5. An endorsement mechanism to track rate and benefit changes as the rules evolve.

Close on governance. Offer to align the policy period, the eligibility certification and the contribution calculation to a single financial-year clock, build the nominee-capture and claims-evidence process at onboarding, and schedule a renewal review once real claims experience exists. An aggregator does not need a broker to recite the Code back to it. It needs someone to turn a 1 to 2 percent levy into a programme that pays, complies and holds up when a state government or a tribunal moves the goalposts. That is the deliverable, and it is available to whichever broker shows up with the model built.