Gig Worker Social Security Fund: An Aggregator's Guide

Gig Worker Social Security Fund: An Aggregator's Guide

If you run a platform business in India — ride-hailing, quick commerce, food delivery, home services, logistics, freelance marketplaces — a new compliance line item is heading for your finance and HR calendars. Under the Code on Social Security, aggregators that engage gig and platform workers are expected to contribute toward a dedicated gig worker social security fund, designed to extend benefits such as health cover, maternity support, and old-age protection to a workforce that has historically fallen outside traditional labour law categories.

This isn't a footnote change. It touches how you price your unit economics, how you onboard workers, how your finance team forecasts liabilities, and how your HR and payroll systems talk to each other. And because the rules are being operationalised in phases — with central rule-making, state-level notifications, and sector-specific guidance all moving at different speeds — aggregator compliance in this space requires more than a one-time policy update. It requires an ongoing operating discipline.

This guide walks through what the obligation means in practice, who it applies to, how to think about the money, what registration and onboarding actually look like on the ground, and how to build the record-keeping muscle you'll need when regulators or auditors come asking. Wherever this article would normally state a specific percentage, turnover slab, or effective date, it deliberately doesn't — those figures are being notified progressively by the central government and individual states, and you should treat official gazette notifications and your state labour department's circulars as the only authoritative source for exact numbers.

Why This Is Suddenly On Every Aggregator's Radar

Gig and platform work in India has grown far faster than the legal framework meant to protect the people doing it. Delivery riders, drivers, freelance service providers, and platform-based contractors have long operated in a grey zone — not quite "employees" under conventional labour law, yet economically dependent on the platforms that route work to them. The Code on Social Security was drafted specifically to close that gap without forcing platforms into a full employer-employee relationship, which would upend the flexible, on-demand model that both workers and businesses often prefer.

The mechanism chosen is a contribution-based social security fund, funded primarily by aggregators, that finances benefits gig workers can draw on regardless of which platform they're working for on a given day. That portability matters — a rider who works across two or three apps in a week shouldn't have fragmented, non-transferable benefits from each one.

A few forces are converging to make this urgent for aggregators right now:

• Phased implementation is active. Draft rules, model schemes, and state pilot notifications have been circulating, and central and state governments are moving from consultation to enforcement in stages.
• Worker registration infrastructure already exists. The e-Shram portal and related unorganised-worker databases give the government a ready mechanism to identify who these contributions are meant to benefit, which removes one of the biggest practical hurdles to rollout.
• Investor and compliance scrutiny is rising. Platform businesses preparing for funding rounds, IPOs, or strategic partnerships are increasingly asked to demonstrate labour-code readiness as part of governance and ESG diligence.
• Penalties for non-compliance under the broader Code framework are not trivial. Once provisions are notified in a state or sector, retroactive scrambling is far more expensive and reputationally damaging than early preparation.

For HR managers, founders, and payroll teams, the practical question isn't "will this apply to us" — for most aggregator-style platforms, it will. The real questions are: how much will it cost, how do we operationalise it, and how do we avoid becoming a compliance horror story.

Who Counts as an "Aggregator" Under This Framework

The Code on Social Security defines an aggregator broadly as a digital intermediary or marketplace that connects buyers and sellers of a service — which in practice sweeps in a wide range of business models, not just the household-name ride-hailing and delivery apps.

Businesses that should assume they fall within scope include:

1. Ride-hailing and mobility platforms — cab aggregators, bike-taxi apps, and shared mobility services.
2. Food and grocery delivery platforms — quick commerce, restaurant delivery, and grocery delivery apps that route orders to independent delivery partners.
3. Home services and on-demand labour marketplaces — platforms connecting customers with electricians, plumbers, beauticians, cleaners, and similar service providers.
4. Logistics and last-mile delivery aggregators — parcel delivery, courier aggregation, and freight-matching platforms.
5. Content, creative, and freelance marketplaces — platforms that match freelance writers, designers, developers, and consultants with clients, where the platform facilitates and often processes payment for the engagement.
6. E-commerce marketplaces with delivery or fulfilment networks — particularly where the platform directly engages delivery or fulfilment personnel rather than routing entirely through third-party logistics vendors.
7. Healthcare and wellness service platforms — on-demand nursing, physiotherapy, diagnostics-at-home, and similar models.
8. Any digital platform business that meets the turnover or scale thresholds set out in applicable rules, even if gig work isn't the company's primary line of business — for example, a retail brand running its own last-mile fleet through an app-based dispatch system.

A useful working test: if your platform algorithmically assigns, tracks, or manages tasks performed by individuals who are not on your payroll as employees, and you take a cut of the transaction value, you are very likely an aggregator for this purpose. Ownership of the app, control over pricing, and the ability to deactivate a worker's account are all signals regulators tend to look at when assessing aggregator status, even where the commercial contract labels the relationship as pure intermediation.

It's also worth noting that hybrid workforces are common. Many aggregators run a mixed model — a smaller pool of directly employed staff (warehouse operations, customer support, city managers) alongside a much larger pool of gig and platform workers. The social security fund obligation applies specifically to the gig/platform worker population, not to your regular payroll employees, who continue to be covered under existing employee provident fund, ESI, gratuity, and other applicable schemes.

The Contribution Obligation, Explained in General Terms

Here's the core mechanism, described without pinning down numbers that aren't yet uniformly settled across every state and sector.

The basic idea: Aggregators are required to contribute a percentage of their annual turnover — specifically, turnover derived from transactions involving gig and platform workers — into a designated social security fund. This is different from a per-worker contribution model like provident fund, where the employer pays a fixed percentage of each employee's wages. Here, the contribution is calculated at the aggregator level, based on business turnover, subject to a prescribed floor and cap set by rule-making authorities.

Key features of the mechanism as currently understood:

• It is turnover-linked, not headcount-linked. This means the contribution scales with your business volume rather than requiring you to track and remit a contribution against each individual worker's earnings, though worker-level data still matters for benefit administration.
• There is a capped range. Rules are expected to specify both a minimum and maximum percentage band, giving government some flexibility to calibrate the rate over time without requiring fresh legislation for every adjustment.
• The fund sits alongside — not instead of — other social security schemes. It's a dedicated corpus for the specific purpose of extending benefits to workers who fall outside EPFO and ESIC's conventional employee-based coverage.
• Central and state administration will likely coexist. The central government sets the overarching framework and model schemes; state governments (or union territory administrations) are expected to notify implementation specifics, collection mechanisms, and in some cases state-specific welfare boards that administer the benefits locally.
• Remittance is likely to follow a periodic cycle — expect something resembling quarterly or annual filings, similar to how other statutory contributions are structured, though exact periodicity should be confirmed through official rules once notified in your state.

Because the rate band, the definition of "relevant turnover," and the collection cadence are all elements that rules are still finalising in various states, do not rely on any number you see quoted informally, including in this article. The only safe approach is to check the latest central notification under the Code on Social Security and your state's implementing rules, ideally in consultation with a labour law advisor, before finalising your contribution model.

What "Turnover" Is Likely to Mean in Practice

One area worth watching closely is how "turnover" gets defined for contribution purposes. For an aggregator, gross transaction value, platform commission revenue, and net revenue can differ enormously. A logistics aggregator that processes a large gross transaction value but retains a thin commission has a very different contribution base under a gross-turnover definition versus a commission-revenue definition. Finance teams should track both figures and be ready to model contribution liability under multiple possible definitions until the applicable rule is confirmed for their sector and state.

Gig Worker Benefits: Before and After the Framework

The table below summarises how the landscape shifts conceptually for a typical gig or platform worker, without attaching specific figures that vary by scheme and state.

This is a directional picture, not a guarantee of implementation quality or speed. Several of the "after" outcomes depend heavily on how efficiently individual states set up welfare boards, disburse funds, and integrate registration databases — and that execution track record is still being written state by state.

Step-by-Step Compliance and Registration Checklist for Aggregators

Treat this as a working checklist to adapt once your state's specific rules are notified. The sequencing below reflects a sensible operational order, not necessarily a legally mandated one.

1. Confirm Your Aggregator Classification

• Map every business line and app-based dispatch model you operate against the aggregator definition in the Code and any sector-specific clarifications.
• Don't assume a single legal entity determination covers all your business lines if you operate multiple platforms or subsidiaries — check each one.

2. Establish Your Contribution Base

• Identify which revenue streams count as turnover "derived from" gig/platform worker transactions, separating this from any unrelated business revenue.
• Build a finance model that can flex against different possible rate bands and turnover definitions until your state's rule is finalised.

3. Register as an Aggregator With the Relevant Authority

• Register with the central or state authority designated for aggregator compliance under the Code, once the registration portal or process is live in your operating states.
• Maintain proof of registration (certificates, acknowledgement numbers) centrally — ideally within your HRMS or compliance management system, not scattered across individual team inboxes.

4. Set Up Worker Registration Support

• Facilitate registration of your gig and platform workers on the applicable unorganised worker database (such as e-Shram or successor systems), since benefit eligibility is likely to be tied to a worker's registration status.
• Capture and store each worker's registration/unique ID reference in your internal systems for cross-referencing.

5. Build a Contribution Calculation and Remittance Process

• Define an internal calendar for computing turnover-linked contributions in line with the periodicity your state prescribes.
• Assign clear ownership — typically a joint responsibility between finance (calculation and remittance) and HR/compliance (worker data accuracy).
• Build in a review/approval step before every remittance, similar to how you'd handle EPF or TDS payments.

6. Integrate With Your Payroll and Vendor Payment Systems

• Even though gig workers are typically paid through a vendor-payment or wallet mechanism rather than payroll, your systems should be able to produce the transaction and payout data needed to substantiate your turnover calculations.
• Ensure your finance systems can separate "worker-linked transaction revenue" from other revenue at a reporting level.

7. Document Your Compliance Position

• Maintain a compliance file (physical or digital) containing your aggregator registration, contribution calculation methodology, remittance records, and any correspondence with regulators.
• Update this file every time a new state notification or central clarification is issued.

8. Set Up Periodic Internal Audits

• Schedule a quarterly or half-yearly internal review of your contribution calculations against actual filings.
• Reconcile worker registration counts against your active worker base to catch gaps early.

9. Train Relevant Teams

• HR, finance, legal, and city/regional operations teams should all understand their role in this compliance chain — this isn't a "legal team only" obligation given how operational the worker registration piece is.

10. Monitor for Rule Changes

• Assign someone (or a small compliance group) to track central notifications and state-specific rules on an ongoing basis, since this is an evolving area rather than a one-time regulatory event.

Worker Onboarding and Self-Registration Considerations

The worker-facing side of this framework is arguably the more operationally demanding part for aggregators, because it involves touching a large, distributed, often low-digital-literacy workforce.

Getting Registration Right at Onboarding

Many aggregators will find it efficient to fold worker registration into their existing onboarding flow — the same moment you collect a driving licence, bank account details, or background verification documents is a natural point to also guide a worker through self-registration on the applicable unorganised worker database.

Practical considerations:

• Assisted registration matters. Not every gig worker will be comfortable completing a government portal registration unassisted. Consider building an in-app nudge, a physical onboarding-centre assist desk, or a partnership with local registration facilitators.
• Avoid mandatory-linkage traps. Be careful not to make platform access contingent on registration in a way that could be read as coercive; the intent of self-registration is that it benefits the worker, and aggressive gating can create both compliance risk and worker trust issues.
• Language and accessibility. Registration flows should be available in regional languages and designed for low-bandwidth, low-literacy contexts — a significant share of gig workers access platforms primarily through mobile apps with limited data plans.
• Data consistency. Names, phone numbers, and ID details used during platform onboarding should match what's used during government registration to avoid mismatches that could delay benefit eligibility later.

Handling Workers Already Active on Your Platform

For your existing active worker base, plan a retrofit registration drive rather than assuming registration only applies to new joiners:

1. Segment your active worker base by tenure, activity level, and last-known contact details.
2. Run a phased communication campaign (in-app notifications, SMS, regional-language messaging) explaining what the registration is for and why it benefits them.
3. Track registration completion rates as an internal KPI, similar to how you'd track any other compliance completion metric.
4. Escalate low-completion segments (e.g., older accounts with outdated contact information) for manual outreach.

Multi-Platform Workers

Because many gig workers are active on more than one platform simultaneously, expect that registration and benefit eligibility will eventually be designed around the worker, not the platform. Aggregators shouldn't build closed, platform-specific registration systems that create friction if a worker later needs their record recognised elsewhere. Wherever possible, route worker registration through the official, portable government database rather than a proprietary internal system alone.

Budgeting Contributions Into Financial Planning

This is the part finance leaders and founders will feel most directly, so it deserves a disciplined approach rather than a wait-and-see posture.

Treat It as a Structural Cost of Doing Business, Not a One-Off

The contribution should be modelled as an ongoing percentage-of-turnover cost line, similar to how you already budget for payment gateway fees, cloud infrastructure costs, or statutory dues. Bolting it on as an afterthought once rules are finalised in your state creates unnecessary scramble.

Build a Scenario Model

Because the exact rate band and turnover definition aren't uniformly settled, build a simple scenario model with at least three cases:

• Conservative case — contribution calculated at the lower end of any plausible rate range, against the narrowest plausible turnover definition.
• Base case — your best current estimate, updated as soon as your state issues clearer guidance.
• Stress case — contribution calculated at the higher end of the plausible range, against the broadest plausible turnover definition (e.g., gross transaction value rather than net commission).

Run your unit economics and city-level profitability models against all three so that a final, higher-than-expected notification doesn't blindside your board or investors.

Where This Money Should Sit in Your P&L

Most finance teams will want to treat this as a statutory compliance cost, sitting alongside other regulatory contributions rather than being buried inside generic "operating expenses." This gives leadership better visibility and makes it easier to track the true cost of engaging gig workers versus alternative staffing models over time.

Provisioning Cadence

• Set up a monthly provisioning entry even if actual remittance is quarterly or annual, so the liability doesn't hit as a lump-sum surprise at filing time.
• Reconcile provisions against actual filings each cycle and adjust the run-rate forecast accordingly.

Pricing and Commercial Implications

Depending on your margin structure, this contribution may need to be factored into:

• Commission rates charged to workers or merchants on your platform.
• Pricing passed through to end consumers.
• Investor conversations around unit economics and contribution margin per transaction, particularly for platforms preparing for fundraising or listing.

Founders should be upfront with investors and boards that this is a structural, not transitional, cost — it isn't going away once initial rollout friction settles.

Record-Keeping and Audit Readiness

Given that this obligation blends turnover-based finance calculations with worker-level HR data, your record-keeping needs to bridge both domains cleanly.

What to Maintain

• Aggregator registration documentation — certificates, registration numbers, renewal records.
• Turnover computation workpapers — the underlying data and methodology used to calculate the contribution base for each filing period, including how "relevant turnover" was defined and sourced.
• Remittance proof — challans, payment confirmations, and acknowledgement receipts for every contribution filed.
• Worker registration records — a record of each active gig worker's registration status on the applicable government database, along with the date registration was completed or last verified.
• Onboarding communication logs — evidence that workers were informed about and supported through the registration process, useful in case of grievance disputes.
• Correspondence with regulators — any queries, clarifications, or notices received and your responses.
• Internal audit reports — records of your own periodic reconciliation exercises.

Retention and Access

• Apply a retention policy consistent with how you handle other statutory records (many organisations default to a minimum of several years, but confirm the specific retention period once your state's rules are notified).
• Ensure records are retrievable by worker ID, filing period, and business unit — an auditor or inspector is unlikely to accept "we'll have to check with three different teams" as an answer.
• Restrict access appropriately since these records combine financial data with personal worker information; align your access controls with your broader data protection practices.

Preparing for Inspection

• Run a mock audit at least annually: pick a random filing period and worker registration batch, and see how quickly your team can produce a complete, consistent record trail.
• Identify gaps proactively — missing worker IDs, unreconciled turnover figures, delayed remittances — before an actual inspection surfaces them.
• Keep a single point of contact (or small compliance team) who owns the full record set, rather than distributing ownership so thin that no one has the complete picture.

How This Interacts With Your Existing HR and Payroll Systems

A common mistake is treating this obligation as something that lives entirely in the finance or legal function. In practice, it touches core HR and payroll infrastructure in several ways.

Gig Workers Aren't Employees — But They Still Need a System of Record

Your payroll system is built around employees: fixed salary structures, statutory deductions like PF and ESI, TDS on salary, and so on. Gig workers typically sit outside that system, paid through a separate vendor or wallet mechanism. That said, you now need a parallel system of record for your gig workforce that tracks:

• Active worker rosters by city, business line, and tenure.
• Registration status on the applicable government worker database.
• Transaction volume/value attributable to each worker (feeding into your turnover calculations).
• Any benefit-related communications or grievances raised.

This is exactly the kind of structured workforce data that a modern HRMS platform should be able to hold, even for a non-payroll workforce segment, so that HR, finance, and compliance are looking at the same source of truth rather than three different spreadsheets.

Distinguish Worker Categories Clearly in Your Systems

Misclassification is a real risk here. Your HRMS should clearly tag:

• Employees — full payroll, PF, ESI, gratuity as applicable.
• Gig/platform workers — covered under the social security fund contribution mechanism, tracked separately.
• Traditional contractors/vendors — who may fall under entirely different compliance obligations.

Blurring these categories in your systems — for instance, treating a city-level gig rider the same as a corporate vendor in your records — makes it much harder to produce a clean audit trail when regulators ask you to demonstrate how you've classified your workforce.

Reporting That Serves Multiple Stakeholders

Your systems should be able to generate, ideally on demand:

1. A turnover-linked contribution report for finance and statutory filing.
2. A worker registration completion report for HR/compliance.
3. A consolidated compliance dashboard for leadership and board reporting.

Platforms that already use an HRMS for their core employees have an advantage here if that same system can be extended to hold gig workforce compliance data — it avoids building an entirely separate, disconnected tracking mechanism from scratch.

Common Pitfalls Aggregators Should Avoid

• Waiting for "final" rules before doing anything. Given the phased rollout, waiting for perfect clarity before building any internal process means you'll be building under time pressure later. Start with a flexible framework now and adjust as rules firm up.
• Using a single national assumption when rules vary by state. A platform operating in ten states should not assume a single rate or process applies uniformly — track state-specific notifications separately.
• Conflating gross transaction value with commission revenue without checking which one applies. This can lead to significant under- or over-provisioning.
• Treating worker registration as a one-time onboarding checkbox. Worker rosters change constantly in gig platforms; registration tracking needs to be a living, continuously updated process, not a point-in-time exercise.
• Letting finance and HR run separate, disconnected compliance trackers. This is the fastest way to end up with mismatched numbers when a regulator cross-checks your turnover-based contribution against your worker registration counts.
• Ignoring multi-platform worker portability. Building closed internal registration systems that don't route through the official government database can create friction and rework later.
• Underestimating the communication effort with workers. Low registration completion rates among your active workforce can become a compliance gap that's hard to explain during an inspection.
• Not budgeting conservatively enough. Platforms that model only the lowest plausible contribution rate risk unpleasant surprises to their margins once the final notified rate lands.

Rules Are Still Rolling Out — Verify Before You Finalise Anything

It bears repeating clearly: implementation of the gig worker social security fund mechanism under the Code on Social Security is happening in phases, with the central government setting the overarching framework and individual states notifying their own implementation timelines, welfare board structures, and in some cases procedural specifics.

This means:

• The exact contribution rate band, the definition of "turnover," and the filing periodicity may differ by state and may change as rules are finalised.
• Registration portals, forms, and authorities may vary depending on where you operate.
• Effective dates for enforcement are not uniform across the country.

Before finalising your contribution model, registration process, or budget projections, confirm the current position through:

• Official notifications published by the central Ministry of Labour and Employment.
• Your state labour department's specific rules and circulars.
• Guidance from a qualified labour law advisor familiar with the Code on Social Security and its state-level implementation in your operating geographies.

Treat every number, timeline, or process described in this article — or in any other general guide — as directional, not definitive.

Frequently Asked Questions

Q: Does this obligation apply only to large platforms, or does it cover smaller aggregators too? Applicability generally depends on turnover and scale thresholds set out in the rules, which may create exemptions or lighter obligations for very small platforms. Smaller aggregators should still check the applicable thresholds for their state and sector rather than assuming automatic exemption.

Q: Is the contribution paid instead of GST, income tax, or other business taxes? No. The social security fund contribution is a separate, distinct obligation tied specifically to gig/platform worker welfare. It does not replace or offset any other statutory tax or compliance obligation your business already carries.

Q: What happens if a gig worker hasn't registered on the government database — does the aggregator still owe the contribution? The aggregator's turnover-linked contribution obligation is generally independent of individual worker registration status — you're expected to contribute based on your business turnover regardless. However, unregistered workers may not be able to access benefits funded by the scheme, which is exactly why supporting worker registration is in the aggregator's interest as much as the worker's.

Q: Can aggregators pass this cost directly onto gig workers by deducting it from their earnings? The contribution is structured as an aggregator-level obligation based on turnover, not a worker-level payroll deduction. Aggregators should review this carefully with legal counsel before attempting any direct pass-through to worker earnings, since doing so could raise separate compliance and worker-relations concerns.

Q: How is this different from ESI or EPF, which some platforms already contribute to for their employees? ESI and EPF are employee-based schemes tied to an employer-employee relationship and calculated against individual wages. The gig worker social security fund contribution is calculated against aggregator turnover and is specifically designed for workers who are not classified as employees, filling the gap those employee-based schemes don't cover.

Q: Do we need to register gig workers even if they work only occasionally on our platform? Best practice is to support registration for anyone actively engaging with your platform, including part-time or occasional workers, since benefit eligibility criteria (minimum work thresholds, for instance) are determined by the scheme rules rather than by how your platform internally categorises worker activity levels.

Q: What records should we be able to produce if a labour inspector visits with limited notice? At minimum: your aggregator registration proof, recent contribution remittance records, your turnover calculation methodology, and a current worker registration status report. Having these centralised and exportable from a single system, rather than scattered across teams, will make any inspection significantly smoother.

Q: Is this obligation likely to increase over time? Given that the framework allows for a rate band rather than a single fixed number, and that welfare board infrastructure is still being built out in many states, it's reasonable to expect calibration over time. Budgeting conservatively and reviewing your model at least annually is a sensible approach.

Bringing It All Together

The gig worker social security fund obligation reflects a genuine shift in how India is approaching platform-based work — treating gig and platform workers as a workforce segment that deserves structured, portable benefits, funded by the businesses that build on their labour, without collapsing the flexible engagement model that makes gig work attractive in the first place.

For aggregators, the practical challenge isn't philosophical — it's operational. You need a finance model that can flex as rates get notified, an onboarding process that gets workers registered without friction, and a record-keeping system robust enough to withstand scrutiny. None of that happens well if it's split across five disconnected spreadsheets and a compliance folder nobody updates.

This is precisely the kind of cross-functional compliance and workforce data challenge that a well-configured HRMS can absorb — tracking your gig workforce roster, registration status, and compliance documentation alongside your regular employee records, so your HR, finance, and legal teams are working from the same numbers instead of reconciling different ones after the fact.

If you're starting to build out your compliance process for gig worker social security contributions, worker registration tracking, or general labour code readiness, CozyHR is built to help HR and payroll teams keep workforce records, compliance documentation, and reporting organised in one place — worth a look as you get ahead of this rollout rather than reacting to it later.