How platforms insure workers they do not employ: group master policies, on-trip eligibility windows, and the data feed that replaces the enrolment form. The mechanics, step by step.
A courier is not an employee, so employer liability cover does not apply. They are not on a personal policy that covers commercial riding, because most personal policies explicitly exclude it. For years this left millions of gig workers in a structural gap: injured doing platform work, covered by nobody. The product that closed the gap — per-shift accident cover attached to platform activity — is now one of the most instructive designs in embedded insurance, because it insures people the buyer of the policy does not employ, for periods of time defined by an app.
Here is the direct answer to how it works: the platform (not the worker) buys a group master policy from a licensed insurer; every active worker is automatically a beneficiary; and eligibility for any given claim is determined by the platform's own activity data — was this person on a trip, or online and waiting, when the injury happened. No enrolment forms, no individual underwriting, no premium collected from the worker.
The precedents are public
This is not a theoretical design. In 2018, Uber announced free personal accident cover for its driver and delivery partners in Saudi Arabia — underwritten with AXA, funded entirely by the platform, covering injury during trips and deliveries, and applying automatically to the roughly 170,000 partners then active. The same year, Uber and AXA launched Partner Protection across Uber's European markets, which went further: alongside on-trip accident cover it added off-app benefits such as illness and parental payments for drivers meeting activity thresholds. Both programmes are public record and repay study, because they mark out the two ends of the design spectrum — pure on-trip accident cover at one end, quasi-social-protection at the other.
The mechanics, piece by piece
The group master policy. The insurer contracts with the platform, not with workers. The policy defines beneficiary classes (drivers, couriers), covered events (accidental injury, disability, death, sometimes lost earnings), limits, and — critically — the eligibility windows. Workers receive a certificate or in-app summary, but they are beneficiaries, not policyholders.
Eligibility windows. The defining idea of per-shift cover is that insurance attaches to states in the platform's system. A typical structure distinguishes three: offline (no cover), online and available (sometimes covered, sometimes not — this is the contested middle), and engaged on a trip or delivery (covered). Every design decision about fairness and cost lives in how the middle state is treated.
Premium mechanics. The insurer prices per unit of exposure — per trip, per active hour, or per online day — and the platform reports actual volumes periodically. Premium becomes a variable cost line that scales exactly with activity, which is why platforms can fund it without per-worker administration. Reconciliation between the platform's activity data and the insurer's invoice is a real operational workstream; it is where these programmes succeed or quietly rot.
Claims. The claim is where the data feed earns its keep. Instead of the worker proving they were working, the platform's trip log proves it for them: timestamps, GPS trace, order ID. A well-built programme resolves the eligibility question in seconds from system data and spends its human attention on the medical side. A badly built one makes an injured courier chase screenshots.
The platform's activity log is the underwriting file, the eligibility check and the claims evidence — one dataset doing three jobs.
Design tensions worth naming
The gaps between trips. A courier hit by a car ninety seconds after completing a delivery, while riding toward the next pickup, sits exactly on the seam of an on-trip-only design. Programmes that cover only engaged time are cheaper and cleaner to price, but they place the worst experience at the most sympathetic moment. Platforms choosing that structure should do it with open eyes.
Multi-apping. Workers commonly run several platforms at once. When two apps are online and one order is active, whose policy responds? Master policies increasingly include coordination language, but the honest answer is that the industry handles this imperfectly.
Benefit adequacy versus cost. Per-shift accident cover is not a substitute for health insurance or social insurance, and describing it as full protection over-claims. The European Partner Protection design acknowledged this by adding off-app benefits; most markets' programmes remain accident-only. Clear communication about what is and is not covered is a compliance duty, not a courtesy.
Why this matters beyond ride-hailing
Any platform that intermediates work — delivery, home services, trucking marketplaces, freelance labour — has the same three ingredients: workers with a protection gap, activity data that defines exposure precisely, and a commercial interest in worker retention and platform reputation. The mechanics above transfer almost unchanged. What varies by market is regulation: group structures, beneficiary rights and mandatory covers differ, and in Saudi Arabia any such programme runs on products filed by licensed insurers under Insurance Authority supervision. The infrastructure question — how a platform's activity feed connects to an insurer's policy admin — is exactly the class of problem embedded insurance platforms exist to solve.