Picture this. Peak dinner hours in Mumbai. You have been riding since 5 PM, orders coming in steady, a decent evening shaping up. Then the sky opens up. Rain so heavy the roads flood in twenty minutes. Restaurants disable delivery mode. Customers cancel. You pull over and watch two hours of earnings disappear in real time.
Your bike is fine. You are fine. But the income is gone, and there is no recourse, no claim to file, no number to call. You just absorb it and go home.
This is not a rare edge case. It happens to millions of delivery riders across India every monsoon season, every heat wave, every bandh, every time the app itself decides to go down during peak hours. And not a single insurance product in the market today does anything meaningful about it. Traditional insurance was designed for people with time, documentation, and stable income to absorb a weeks-long claims process. Delivery riders have none of those things.
That is the problem our team set out to solve at the Guidewire DEVTrails 2026 Hackathon. What we built is called GigShield an AI-powered parametric insurance platform purpose-built for food delivery riders on Zomato and Swiggy. It works completely differently from any insurance product you have encountered before.
No Claims. No Paperwork. Just a UPI Transfer.
GigShield is parametric, which means it does not wait for you to report anything. The platform monitors real-world disruption signals continuously, and the moment a verified trigger event hits a rider's active zone while they are on shift, a payout is initiated automatically. No forms, no calls, no adjuster review. Within 60 seconds of a trigger firing, the money is in the rider's UPI wallet.
Five parametric triggers drive the system. Rainfall exceeding 15 mm per hour for 20 consecutive minutes, verified through the OpenWeather API. Temperatures above 42 degrees Celsius with an active IMD heat advisory. AQI crossing into the Severe category above 400, sourced from CPCB. Civic disruptions curfews, Section 144 orders, verified bandhs confirmed simultaneously by a government notification feed, a verified news API, and a minimum 40% drop in platform order volume in the affected zone. And platform outages: if Zomato or Swiggy returns consistent API failures for 30 or more minutes during a peak earnings window, that is a compensable event. Riders lose income when the platform fails. We cover it the same way we cover a flood.
The dual-source validation for civic disruptions was a deliberate design decision. Social media in India moves faster than facts during politically charged events. A single unverified report of a bandh could trigger hundreds of false payouts. Requiring two independent institutional sources plus an order volume signal makes the system resilient without making it slow.
The Hardest Problem: Proving a Rider Was Actually Working
This is where the build gets technically interesting, and where most naive implementations fall apart.
Zomato and Swiggy do not expose rider activity data through public APIs. So how do you verify that the person claiming a payout was actually on shift when the disruption hit? This was the thorniest design question in Phase 1.
The answer is a multi-signal activity detection system built entirely on rider consent and independent data collection. At onboarding, riders grant location permission and consent to GPS tracking during declared shift hours only. Before each shift, the rider opens the GigShield app and declares shift start, creating a verifiable time-stamped activity window. From that point, the AI model evaluates GPS velocity patterns and network usage signals in the background. Riders can optionally upload a screenshot of their in-app delivery summary as supplementary evidence to strengthen their score.
All of this feeds into a composite activity probability score from 0 to 100. A score of 65 or above at the moment of disruption triggers an automatic payout. Between 50 and 65, the case is flagged for manual review. Below 50, no payout is issued and a verification request goes to the rider. No platform cooperation required, no proprietary data accessed, no privacy compromised.
System Architecture
The platform runs in four layers that connect continuously from signal detection through to payment execution.
The Data Ingestion Layer polls weather, AQI, civic, and platform APIs on a 5-minute refresh cycle, normalising and caching everything in Redis. The AI Detection Layer processes live GPS activity signals, runs the fraud detection model, and produces real-time activity and fraud probability scores for every rider currently on shift. The Parametric Trigger Engine evaluates three conditions simultaneously disruption confirmed, activity verified, fraud check clear and emits a payout event only when all three are satisfied at the same moment. The Payout and Notification Layer calls the Razorpay API with the rider's registered UPI ID and fires a WhatsApp confirmation the instant the transfer is confirmed.
The 60-second target from trigger to wallet is a hard product requirement, not an aspiration. A payout that arrives two hours later is functionally useless to a rider deciding right now whether to keep waiting or go home.
Pricing Built for the Gig Economy
Most insurance products are priced monthly. Delivery riders are paid weekly. That mismatch alone is enough to kill adoption before it starts.
GigShield is priced and collected weekly, Monday to Sunday, with the option to activate or pause coverage week by week. The premium is not a fixed table — it is a two-stage XGBoost model. Stage 1 produces a disruption probability for the coming 7 days based on three years of IMD historical records, CPCB AQI logs, civic disruption data, and platform order volume signals by pin code. Stage 2 adjusts that probability across 12 rider-specific features zone flood history, rider tenure, seasonal loading, real-time forecast signals to produce a personalised weekly premium clamped between Rs. 49 and Rs. 249.
A new rider in a low-risk zone during a clear week pays around Rs. 64. An experienced rider in a flood-prone zone during peak monsoon hits the Rs. 249 ceiling. Every rider also sees a plain-language explanation of their premium at onboarding, powered by a SHAP explainability layer. A rider who does not understand what they are paying for will not stay subscribed. Explainability is not a feature, it is a retention mechanism.
Where We Are After Phase 1
Phase 1 was about getting the architecture right before writing a single line of production code. By the March 20 deadline, all five parametric triggers are defined with data sources and thresholds, the premium model is fully designed with worked calculation examples across three rider profiles, the rider activity verification architecture is resolved without any dependency on platform APIs, the disruption taxonomy is expanded to cover social and civic events, and the full system architecture is documented across fifteen detailed proposal sections.
The GitHub repository is live. The 2-minute strategy video is uploaded.
What Phase 2 Looks Like
Phase 2 is implementation. The Progressive Web App goes live, API integrations go live, the XGBoost model gets initialised on simulated historical data calibrated to Mumbai, Bangalore, and Delhi delivery patterns, and we run the first full end-to-end payout simulation a disruption trigger fires, activity is verified, fraud check clears, and a rider receives a UPI transfer in under 60 seconds.
We are not building a hackathon demo. India has 3 million active food delivery riders with no meaningful safety net. We are building something that could actually change that.
More updates as the build progresses.
Top comments (0)