Gig and Platform Worker Social Security 2026: Aggregator Data and Contribution Readiness

By Ravi Sisodia · Reviewed by CA Divyanshu Sengar · Updated 5 October 2026

The Social Security Code recognises gig and platform workers; aggregator readiness starts with clean worker, payment and category data before any notified scheme contribution can be calculated or reconciled.

Finin2min 2-Minute Summary

• The Code on Social Security has been in force since 21 November 2025 and expressly recognises gig and platform workers.
• Aggregator obligations depend on the Code, notified schemes and implementation rules; companies should not hard-code a contribution assumption from an old draft or secondary article.
• Worker identity, platform category, payment value, active period and location are the minimum data needed for future contribution/reconciliation.
• e-Shram and scheme registration data should be captured only for lawful, defined purposes with access controls.
• Finance, product and operations should jointly own the contribution data model because transaction systems, not payroll, contain most platform-worker economics.

Define who sits in the aggregator population

Map every business model to the Code's aggregator/gig/platform-worker concepts. A delivery partner, freelance professional, reseller and employee may all interact with the same app but have different legal relationships. Do not classify solely from the label used in the app.

Preserve contracts, onboarding data and actual payment mechanics so classification can be supported if a scheme or regulator asks for the underlying population.

Build contribution-ready data before a scheme deadline

At minimum, capture unique worker identifier, engagement period, transaction/payment amount, deductions, refunds, geography and platform/business category. The data should be reproducible from source systems and reconciled to financial statements.

Where the final scheme uses turnover or worker-payment metrics, a clean historical dataset prevents rushed manual estimates.

Privacy and social-security data need separate access rules

Identity and social-security information is sensitive operationally even if the labour framework requires collection. Limit internal access and avoid using welfare registration data for unrelated marketing or scoring unless another lawful basis clearly permits it.

Create retention rules that satisfy labour/social-security evidence needs without keeping duplicated documents indefinitely.

Common data problem: platform payouts do not equal worker earnings

Platform systems can record customer price, commission, incentive, refund, tip, tax, penalty and net payout as separate fields. A future social-security contribution basis may use a measure that is not identical to the worker's bank credit. Aggregators should preserve the gross-to-net bridge instead of retaining only the final payout number.

Identity resolution is equally important. A worker can change mobile number, bank account or device while remaining the same individual. Duplicate worker IDs can inflate headcount and split contribution history. Use controlled identity matching and a process for merging verified duplicates without erasing the audit trail.

If a worker operates on more than one platform, do not infer obligations of other aggregators from your own data. Record only the relationship and amounts your entity can substantiate and follow the notified scheme's allocation/reporting process.

• Preserve gross transaction, incentive, deduction and net payout fields.
• Maintain a controlled duplicate-worker resolution process.
• Keep historic identifiers after verified profile changes.
• Reconcile aggregate worker payouts to finance records by period.

Aggregator readiness checklist

• Legal classification memo for worker populations.
• Worker identity and engagement-period data.
• Payment/transaction ledger by worker.
• Reconciliation to revenue/turnover records.
• e-Shram/scheme registration field governance.
• Contribution engine kept configurable until final scheme parameters apply.
• Worker communication and grievance route.

Questions readers commonly ask

Are gig workers covered by the Social Security Code?

Yes. The Code expressly recognises gig and platform workers.

Is there one universal aggregator contribution calculation to use now?

Use the current notified scheme/rules for the exact obligation; do not rely on an old draft assumption.

Why should finance be involved?

Because contribution calculations can depend on transaction or turnover data outside payroll.

Can platform-worker data be reused freely?

No. Collection for social-security compliance does not automatically justify unrelated uses.

Official / primary sources

• Code on Social Security, 2020 - Gig/platform worker statutory framework
• Labour Ministry Social Security FAQ 2026 - Current implementation guidance
• Ministry Labour Codes hub - Current labour-code status

Disclaimer

Important: General educational and professional-reference material. Apply the current Code, Rules, insurance contract/regulatory instrument or DPDP commencement status to the exact facts before acting. Educational and professional reference only; confirm the current law, rates and the facts of your case before relying on this page.