EPFO 3.0's Split Payment: Diverting a Slice of Qualifying Platform Transactions

Business Standard reported on 21 July 2026, citing The Indian Express, that the EPFO 3.0 framework proposes a universal pension system covering salaried employees along with gig workers, platform workers and the unorganised sector, built on a defined contribution model. The same reporting puts EPFO's own expectation at nearly 25 million gig workers and building and construction workers brought under the framework over the next five years. The Indian Express headlined its piece "What EPFO 3.0 proposes: Pension cover for all, social security for gig workers".

Two design elements in the proposal reach into an aggregator's systems rather than only its budget. The first is a split-payment mechanism for digital platforms, under which a small portion of certain transactions could be diverted toward workers' social security savings. The second is one Universal Account Number linked to multiple employers or digital platforms, so a worker's record follows the person across every app they work on.

This is a proposal. No notification, no rate, no effective date, no scheme rules on which transactions qualify. Treat what follows as preparation, not compliance. The reason to prepare early is that both elements touch parts of the stack that take quarters to change: the payment flow itself, and the member data an insurer underwrites from. Neither is a switch anyone flips in the notification-to-effect window.

The gig welfare levies aggregators already file today are collected at the settlement layer. Karnataka's welfare fee is computed on aggregator payouts, worked out periodically, and remitted from the platform's own accounts. The money moves once, from a bank account to a welfare board, on a filing cycle, and the payment rails never carry it.

A split-payment mechanism moves the deduction upstream into the transaction itself. The customer pays for an order, and at the moment of that payment a defined slice is routed to a destination that is neither the platform nor the worker. That difference has consequences the settlement model does not:

1. The split has to happen in real time, on every qualifying transaction. There is no month-end batch to correct in. A misconfigured rate is wrong on live money.
2. Refunds and cancellations reverse in two directions. When an order is refunded, the customer gets the full amount back. What happens to the slice already routed to social security is a scheme design question with no clean answer in existing rails.
3. Partial payments, wallet credits, promotional discounts and cash-on-delivery each need their own rule. "A small portion of certain transactions" is doing heavy work in the proposal text. Which transactions qualify is the whole engineering spec.
4. The routed slice is arguably never the platform's money. That is a favourable position for cash flow and a difficult one for accounting, because the platform still has to report gross transaction value it never held.

The cost question, which the gig benefit stack costing note works through layer by layer, is separable from all of this. A platform could know its exact rupee exposure and still be unable to implement the mechanism, because the constraint sits in the payments stack.

The merchant of record is the entity that appears to the customer and the card networks as the seller, bears chargeback liability, and books the gross receipt. Indian platforms sit in three broad positions, and split payment lands differently on each.

Where the platform is the merchant of record, as with most quick commerce and inventory-led models, the platform collects the full customer payment and the split is a deduction from money it legally received. The mechanism is closest to a tax collected at source in feel, and the platform carries the remittance obligation and the audit trail alone.

Where the platform is a marketplace facilitator and the restaurant, seller or driver is the underlying supplier, the customer payment already splits several ways through a payment aggregator's escrow. Adding a social security leg means a fourth or fifth beneficiary in a settlement instruction that is already governed by the RBI's payment aggregator framework, under which funds sit in an escrow account with defined permissible credits and debits. A new debit head is not something a platform configures unilaterally.

Where the worker is paid through a separate payout rail rather than out of the customer transaction at all, and many delivery fleets work this way with weekly settlement to riders, there is no natural point in the customer transaction that corresponds to a specific worker. The split would be computed against a transaction whose worker attribution is resolved hours later, after order allocation, cancellation and reassignment settle.

Today an aggregator reconciles two ledgers for worker money: the payout ledger (what each worker earned and was paid) and the statutory ledger (what welfare fee or cess was computed and remitted, usually in aggregate). Those two never have to agree at the individual level, because state welfare fees are aggregate obligations.

A UAN-linked split payment introduces a third ledger that has to agree with the other two worker by worker and transaction by transaction: the contribution ledger, showing which slice of which transaction went to which UAN on which date. Three failure modes deserve provisioning now.

Orphaned contributions. A slice is split at transaction time and the worker's UAN is missing, mismatched or under KYC hold. The money is out of the platform's account and not in a member's. Every platform will need a suspense account and an aging policy for it.

Reversal asymmetry. Refunds, chargebacks and fraud reversals unwind the customer leg. If the social security leg does not unwind on the same rule, the platform funds the gap. On a fleet doing lakhs of orders a day, a one percent unreconciled reversal rate is a real number.

Multi-platform double counting. Under one UAN linked to several platforms, the aggregate credited to a worker is the sum of contributions from every app. No single platform can see the total, which means no single platform can validate whether a statutory ceiling, if the scheme sets one, has already been reached.

The practical answer is to build the contribution ledger as a first-class system now, populated from whatever the platform already remits under state welfare fee regimes. Platforms that have been through the Karnataka welfare fee litigation and escrow provisioning cycle already have most of the accounting scaffolding; what they lack is per-worker granularity.

Group personal accident and group health policies in India are written on a single-employer assumption that runs deeper than most buyers notice. The policy wording defines the insured group by reference to the policyholder's own roster. Member data flows one way, from one employer's HR or ops system to one insurer. Eligibility, insurable interest, and the declaration basis on which premium is billed all rest on that single roster.

One UAN linked to multiple platforms does not by itself change the insurance contract. It changes what is knowable about the insured person, and that is what underwriters price on.

What multi-homing does to the risk

A rider working three apps on the same day carries a single accident exposure across three rosters. The risk does not triple; the reported exposure does. Each platform declares the same person as an active member, each pays premium on that member, and each insurer prices a frequency assumption calibrated on hours the platform believes the worker is riding for it. If the true figure is total hours on the road across all three apps, every one of those pricing assumptions is wrong in the same direction.

What it does to the claim

When that rider is injured, three group personal accident policies may respond. Benefit policies typically pay independently rather than contributing rateably, so contribution between insurers does not automatically apply the way it would on an indemnity cover. Health cover behaves differently again, because indemnity principles limit total recovery to the actual loss. The worker and the three platforms then have to establish which platform the worker was engaged by at the moment of the accident, a fact that today is proven from platform-side trip logs and nothing else.

A shared UAN creates, for the first time, a common identifier across those three records. That is useful for the worker and uncomfortable for the platform that would rather its exposure data not be joinable with a competitor's.

The proposal's UAN design invites an obvious question that has no settled answer: if social security travels with the worker, why does cover not?

Three structures are available in the Indian market today, and they place the policyholder differently.

1. Platform as policyholder, group cover. The standard model. Each platform buys its own group personal accident and group health, the worker is a member on each, and cover ends when the worker leaves the roster. Cheapest per member, and it dies at churn.
2. Welfare board or fund as policyholder. The structure the state welfare fee regimes point toward, and the one contrasted with commercial placement in our note on the social security fund versus commercial cover. One policy covers registered workers regardless of which app they are on. Portability is solved by construction; benefit design is set by the board rather than by the platform.
3. Worker as policyholder, platform-funded. A retail or micro-insurance policy in the worker's own name, with the platform paying or subsidising premium. Fully portable, but retail pricing is higher than group pricing and the platform loses control of the wording.

A UAN-anchored contribution stream makes the second structure more plausible than it was, because it creates a funded pool and a membership register that a policyholder entity could underwrite against. Group cover bought by the platform is still what pays this year, and the Code on Social Security aggregator group insurance analysis sets out why statutory schemes and procured cover have so far run in parallel.

The planning point is narrow. Do not restructure the insurance programme around a proposal, and do make sure the programme you buy in FY 2026-27 can be unwound. A portable-cover regime would change what the platform is buying, not only what it costs.

Two sets of contracts would need work, and they move at different speeds.

With the payment gateway or payment aggregator

Split payment is a change to the settlement instruction, which means the commercial terms with the gateway have to address:

• Whether the gateway can route to a statutory destination at all, and under what escrow permissions. Adding a beneficiary to a payment aggregator escrow is a regulatory question for the gateway, not a feature request.
• Per-leg pricing. Gateways price per transaction and sometimes per settlement leg. An extra leg on every qualifying order changes the payments cost line at scale.
• Reversal handling on the social security leg, spelled out separately from customer refunds, with an explicit statement of who funds an unreversed slice.
• Failure behaviour. If the social security leg fails and the customer leg succeeds, does the transaction stand? The answer decides whether a scheme outage becomes an order outage.
• Data processing terms. The gateway would handle UAN-linked identifiers, which pulls retention and breach notification obligations into scope.

With the insurer and the broker

The insurance contract changes are smaller in count and larger in consequence:

• Member data definition. If UAN becomes an available identifier, decide deliberately whether to share it. It improves member matching and duplicate detection, and it makes the platform's roster joinable with other datasets.
• Declaration basis. Multi-homing means active-member counts overstate distinct-person exposure across the market. Re-examine the basis if underwriters start pricing multi-homing explicitly.
• Scope of cover. Active-period-only wordings become harder to administer when a worker is simultaneously active on two apps. Broadening to 24x7 removes the attribution argument at claim time, at a premium cost.
• Continuity clauses. Ask the insurer now what happens to a member who leaves mid-policy under a portability regime. Getting a position in writing is cheap today and expensive after a scheme is notified.

There is no date to work back from. There is a set of things worth doing whose value does not depend on EPFO 3.0 being notified in its current shape.

1. Map every point in your payment flow where a deduction could be inserted. Customer payment, escrow settlement, worker payout. Know which of the three your architecture actually supports and what each would cost to build.
2. Build the per-worker contribution ledger. Populate it from existing state welfare fee remittances. If a transaction-level scheme arrives, you already have the data model; if it does not, you have better state-level filings.
3. Fix worker identity before it is forced on you. Reconcile your roster against eShram and UAN where workers already have one. Orphaned contributions are an identity problem, and identity clean-up on a churning fleet takes longer than any implementation window will allow.
4. Quantify multi-homing in your own fleet. Estimate what share of active workers are simultaneously active elsewhere. Your insurer will eventually ask, and the platform that can answer negotiates from a better position.
5. Get the reversal rule in writing with your gateway. Not for a scheme that does not exist, but for the split-payment products the gateway already offers. The same clause will govern the statutory leg later.
6. Keep the FY 2026-27 insurance programme unwindable. Annual placement, declaration basis, no long-tenor lock-in on group covers that a portability regime would make redundant.

EPFO expects nearly 25 million gig and construction workers inside this framework over five years. A programme at that scale will not be retrofitted onto payment stacks that cannot attribute a transaction to a worker. The preparation that matters is the part that makes attribution possible, and it pays off whether or not the split-payment mechanism survives consultation.