Guidewire DEVTrails 2026 — University Hackathon
Team: Caffeine N Commits | Parul University, Vadodara
Team Members: Anjali Mulchandani · Sujal Jethwani · Parth Sudani · Garv Patel · Dhruvi Dhakan
Persona: Q-Commerce Delivery Partners (Zepto, Blinkit, Swiggy Instamart)
🌐 GigShield Live App
🎬 Phase 1 Strategy Video
🎬 Phase 2 Demo Video
Every time it rains heavily in Vadodara, we see Zepto and Blinkit riders still out on the road — because they have no choice. If they stop, they lose the day's income. If they keep going, they risk themselves. But here's the part nobody talks about: even when platforms pause operations due to weather or local disruptions, the rider still loses that income with zero compensation and zero protection.
These riders earn roughly ₹600–₹900 a day. A single bad weather day wipes out 10–15% of their weekly earnings. A flood or curfew can mean 2–3 lost days in a row. There's no insurance product in India today that specifically covers this gap for Q-Commerce workers.
That's what GigShield is trying to fix.
GigShield is a parametric income protection platform built specifically for Q-Commerce riders. The core idea is simple — instead of asking riders to file claims, we monitor their delivery zone in real-time using weather and civic data APIs. When a verified disruption crosses a threshold (say, rainfall above 20mm/hr), the system automatically triggers a payout to the rider's UPI.
No forms. No waiting. No rejection risk. Just money when they need it most.
Persona: Ravi, 26 — Blinkit Delivery Partner, Vadodara
Ravi works 10–12 hours a day, 6 days a week. His weekly earnings are around ₹4,500–₹5,500. He operates in 2–3 zones across the city depending on demand. During the monsoon season (June–September), he loses roughly 1–2 working days per week to heavy rain and waterlogging. That's nearly ₹1,000–₹1,500 gone every week with no way to recover it.
Ravi doesn't have time to research insurance products. He's not going to fill out a form or wait 7 days for a claim to process. He needs something that works automatically and costs less than what he spends on chai in a week.
Key scenarios GigShield covers for Ravi:
-
It's monsoon season. Heavy rain hits his zone for 3 hours. Blinkit pauses operations. Ravi loses ₹300 in that window. → GigShield detects the rainfall threshold breach, validates it, and credits ₹300 to his UPI automatically.
-
A local bandh is called in his area with 2 hours notice. He can't reach his pickup zone. → GigShield's civic disruption trigger fires based on news/alert API data. Payout processed.
-
AQI in his zone crosses 400 (Severe). Platform reduces active delivery slots. → Air quality trigger activates. Partial payout based on estimated lost hours.
STEP 1 — ONBOARDING
Rider opens GigShield on phone browser (no app install needed)
→ Registers via mobile OTP
→ Selects their platform (Blinkit / Zepto / Swiggy Instamart)
→ Marks their primary delivery zones on a map
→ AI generates their Zone Risk Profile instantly
STEP 2 — WEEKLY POLICY
AI calculates a weekly premium based on zone risk + season + forecast
→ Rider picks a coverage tier
→ Premium auto-deducted every Monday via UPI/Razorpay
STEP 3 — BACKGROUND MONITORING (Always On)
GigShield checks weather, AQI, and civic alert APIs every 30 minutes
→ Monitors all active riders' registered zones
STEP 4 — DISRUPTION DETECTED
System detects: Rainfall > 20mm/hr in Rider's zone for 2+ hours
→ Parametric trigger threshold crossed
→ No action needed from rider
STEP 5 — AI CLAIM VALIDATION
AI cross-checks: Is this disruption genuine?
→ Verifies across 2+ data sources
→ Checks rider's GPS activity vs disruption zone
→ Screens for fraud patterns → APPROVE / FLAG / REJECT
STEP 6 — INSTANT PAYOUT
Payout calculated: Lost hours × Average hourly wage
→ Credited to rider's registered UPI within minutes
→ Rider gets WhatsApp/SMS notification:
"₹350 credited for 3 hours lost due to heavy rain in your zone."
We chose weekly pricing deliberately. Q-Commerce riders get paid weekly by their platforms — monthly insurance feels expensive and disconnected from how they actually manage money. Weekly pricing also means lower commitment risk for riders who are new to insurance.
| Tier | Weekly Premium | Max Weekly Payout | What's Covered |
|---|---|---|---|
| 🟢 Basic | ₹29/week | ₹500 | Weather disruptions only |
| ⭐ Standard | ₹49/week | ₹1,000 | Weather + Civic disruptions |
| 🔶 Premium | ₹79/week | ₹2,000 | Weather + Civic + Platform outages |
Note: All tiers cover INCOME LOSS ONLY. Vehicle repairs, health, and accidents are strictly out of scope.
Every Sunday night, our risk model recalculates each rider's premium for the coming week. It considers:
- Zone flood/waterlogging history — Is this zone historically prone to disruptions?
- 7-day weather forecast — Is a heavy rain week predicted?
- Rider's claim history — Clean record = small loyalty discount
- Season — Monsoon months carry a higher base risk multiplier
- Upcoming civic events — Festivals, election days, known bandh dates
Example: Ravi's base Standard premium is ₹49/week. During the first week of monsoon with a high-rain forecast for Vadodara, his AI-adjusted premium becomes ₹56/week. He gets notified in advance and can choose to upgrade or stay on his tier.
| # | Trigger | Data Source | Threshold | Payout Rate |
|---|---|---|---|---|
| 1 | 🌧️ Heavy Rainfall | OpenWeatherMap API | >20mm/hr for 2+ hrs | ₹120/hr lost |
| 2 | 🌡️ Extreme Heat | OpenWeatherMap API | >43°C for 3+ hrs | ₹100/hr lost |
| 3 | 🌊 Flood / Waterlogging | IMD alerts + mock civic API | Official warning issued | ₹150/hr lost |
| 4 | 😷 Severe Air Quality | AQICN API (free tier) | AQI > 400 | ₹100/hr lost |
| 5 | 🚫 Civic Disruption | NewsAPI + mock alerts | Curfew/Bandh in zone | ₹130/hr lost |
All triggers are objective and verifiable — no subjective judgment involved. This is what makes parametric insurance powerful and fraud-resistant.
A risk scoring model trained on simulated historical disruption and weather data mapped to Vadodara and other Tier-1/2 Indian cities. Outputs a weekly risk score per zone (0–100) which directly adjusts the base premium.
Common fraud patterns the system detects:
- Rider claims disruption but GPS shows active movement in unaffected zone
- Multiple claim attempts for the same disruption event
- Newly registered rider claiming on Day 1 during a known disruption
The AI validation layer analyzes claim context — cross-referencing rider location history, registration age, zone data, and API-verified disruption data — and returns an APPROVE / FLAG / REJECT decision with reasoning logged for audit.
Using 7-day forecasts, the system proactively notifies riders the night before a predicted disruption: "Heavy rain expected in your zone tomorrow. Your coverage is active."
| Layer | Technology | Why |
|---|---|---|
| Frontend | React.js + Tailwind CSS | Responsive, works on mobile browser without app install |
| Backend | Node.js + Express | Lightweight, fast REST APIs |
| Database | MongoDB Atlas | Free tier, no billing required, reliable cloud storage |
| Auth | Mock OTP (Phase 2) | Phone-number login — familiar to riders |
| AI/ML | Claude API | Fraud detection scoring — APPROVE / FLAG / REJECT |
| Weather | OpenWeatherMap API | Free tier, reliable, covers Indian cities |
| AQI | AQICN API | Free, real-time air quality data |
| News/Civic | NewsAPI (mock fallback) | Civic disruption detection |
| Payments | Razorpay Test Mode | Simulated premium collection + payouts |
| Hosting | Render (frontend + backend) | Free tier, live deployment |
- No Play Store approval needed — faster to ship and demo
- Riders can access via a WhatsApp link or SMS — zero install friction
- Single codebase for mobile + desktop (responsive design)
- Can be added to home screen as a PWA later
- Define persona, triggers, and pricing model
- Complete README and project documentation
- Set up GitHub repository structure
- Record 2-minute strategy video
- Respond to DEVTrails 24-hour Market Shift Challenge (Anti-Spoofing Strategy)
- Rider registration + OTP login flow
- Platform selection (Blinkit / Zepto / Swiggy Instamart)
- Zone input and AI Risk Score generation
- Dynamic weekly premium calculator (AI-backed)
- Policy creation and management UI — all 3 tiers
- Weather + AQI API integration with trigger simulation
- Parametric trigger engine — Rain, Heat, AQI, Bandh
- Claims dashboard — APPROVED / FLAGGED / REJECTED states
- AI fraud scoring integrated
- MongoDB Atlas database connected
- Full app deployed live on Render
- 2-minute demo video recorded and submitted
- Advanced fraud detection (GPS spoofing detection, duplicate claim prevention)
- Instant payout simulation with Razorpay
- Rider dashboard — active coverage, earnings protected, claim history
- Admin/Insurer dashboard — loss ratios, zone-level disruption analytics
- Final pitch deck + 5-minute walkthrough demo video
Our response to the Guidewire DEVTrails 2026 — 24-Hour Market Shift Challenge
When we read the challenge brief, our first reaction was — we already thought about this. Not fully. Not formally. But the question of "what if riders fake their location" came up in our very first brainstorming session when we were designing the fraud layer.
The challenge made us formalize it. Here's our thinking.
500 riders. Organized via Telegram. Using GPS spoofing apps to fake their location inside a disruption zone while sitting safely at home. The trigger fires. Mass false payouts drain the liquidity pool.
The scary part is not the GPS spoofing — that's a solved problem in isolation. The scary part is the coordination. A single spoofer is easy to catch. A synchronized ring of 500 is a different threat entirely.
The key insight we kept coming back to: a genuine rider in a flood zone is inconvenienced in ways a spoofer at home is not.
Their battery is draining faster. Their GPS signal is drifting. Their network is unstable. Their phone is being used differently — no social media, no YouTube, because they're stressed and stuck. These are weak signals individually. Together they paint a picture.
We cross-reference 8 signals for every flagged claim:
| Signal | Genuine Stranded Rider | GPS Spoofer |
|---|---|---|
| GPS location | Inside disruption zone | Faked inside zone |
| Cell tower match | Tower matches GPS zone | Often mismatches — towers can't be spoofed |
| GPS movement | Erratic, micro-movements, slow drift | Suspiciously static or perfectly placed |
| Mock location flag | Off | Android exposes this in device metadata |
| Platform activity | Recently active in that zone | Zone is unfamiliar or no recent activity |
| Claim timing | Filed during or shortly after disruption | Filed within seconds of trigger firing |
| Device consistency | Same device since registration | New device, changed device, or emulator |
| Cluster pattern | Isolated claim | Part of a geographic spike of 20+ simultaneous claims |
No single signal is definitive. The combination is.
A spoofer can fake GPS. They cannot fake all 8 simultaneously without physical presence in the zone.
Device & Network
- Cell tower triangulation vs GPS claim — the most reliable mismatch signal
- Android mock location developer flag — cheap to check, often overlooked by amateur spoofers
- Device fingerprint — same hardware ID as registration? Emulator signatures detectable?
- IP geolocation — weak signal alone, but useful when combined with others
Behavioral
- Time-to-claim — a genuine rider doesn't file 3 seconds after the trigger fires. That's a bot.
- Order history in zone — has this rider ever actually delivered here before?
- Movement velocity during claim window — static for 45 minutes in a flood zone is suspicious.
- Platform-side disruption confirmation — if the platform paused ops in that zone, that's independent corroboration
Syndicate / Coordination Detection
- If 50 claims arrive from a 2km radius within 4 minutes of a trigger firing — that is not a natural disaster response pattern.
- We flag geographic claim spikes above a threshold as a coordinated ring signal and hold the entire batch for review.
- Device model homogeneity — a ring using the same spoofing app on the same phone model shows up in aggregate even when individual claims look clean.
Tier 1 — Invisible verification (low suspicion) Background check only. Rider never knows. Auto-approves if cell tower matches.
Tier 2 — One tap (medium suspicion) Single WhatsApp message: "Tap to confirm you're in [Zone] right now." One tap. No form. Takes 3 seconds.
Tier 3 — Passive photo (high suspicion — coordinated ring indicators) 5-second video or photo. Only triggered when cluster + device + timing signals all align.
Friction should scale with suspicion — not with weather conditions.
A rider in a flood already has a hard enough day.
| What the syndicate can do | Why it doesn't work against us |
|---|---|
| Spoof GPS location | Cell tower data can't be spoofed — requires physical presence |
| Coordinate on Telegram | Geographic claim spike detection flags the batch, not just individuals |
| Use the same spoofing app | Device fingerprint homogeneity shows up in aggregate analysis |
| File immediately after trigger | Time-to-claim pattern flags bot-like behavior |
| Use 500 different phones | Cluster + movement + tower mismatch still catches them |
| Target a genuine disruption zone | Tower, behavior, and timing still flag the ring |
This section was added on March 19, 2026 in response to the DEVTrails 24-hour market shift challenge.
India has 5+ million Q-Commerce delivery workers across Zepto, Blinkit, and Swiggy Instamart — a segment growing at 40%+ YoY. None of them have income protection against external disruptions. Traditional insurance companies ignore them because they're informal workers without salary slips or credit history.
GigShield works for them because it's parametric — no paperwork, no proof of loss, no claim rejection. The trigger is the data. The payout is automatic. At ₹49/week, it's affordable. At ₹2,000/week max payout, it's meaningful.
We're starting with Q-Commerce in Tier-2 cities like Vadodara because the disruption frequency is high, the rider density is growing fast, and the insurance penetration is essentially zero.
One question we kept asking ourselves while building GigShield: who actually sends the money?
Here's how it works end to end.
GigShield doesn't pay from its own pocket. It works the same way every insurance company in the world works — collect premiums from many, pay out to few.
Example week in Vadodara:
1,000 active riders × ₹49/week = ₹49,000 collected
Normal disruption week — ~50 riders trigger a claim
50 riders × ₹300 avg payout = ₹15,000 paid out
₹49,000 collected − ₹15,000 paid out = ₹34,000 surplus → goes to reserve pool
The math works because not every rider faces a disruption every week. Riders who don't claim that week fund the riders who do. That's how all insurance works. Parametric just removes the paperwork.
Layer 1 — Weekly Premium Pool (routine payouts)
All active rider premiums flow into a pooled reserve. This covers individual weather events, AQI alerts, and small civic disruptions. GigShield maintains a 40% liquidity reserve before any payout is released — ensuring even a 3× claims spike during a major flood week doesn't drain the pool. Dynamic premium recalculation the following Sunday rebuilds the reserve automatically.
Layer 2 — Reinsurance Partner (catastrophic events)
For large-scale events — a city-wide flood triggering thousands of simultaneous claims — GigShield partners with a reinsurance company such as Munich Re, Swiss Re, or Indian player GIC Re. They cover excess claims beyond what the premium pool can handle. This is standard practice — every insurance company in the world operates this way.
Layer 3 — Platform Partnership Revenue
Zepto, Blinkit, and Swiggy Instamart benefit directly when their riders are protected. Protected riders show lower attrition, higher availability in marginal weather, and stronger platform loyalty. Platforms can co-subsidize rider premiums as a retention tool — reducing the effective cost to riders further. This model is already operating in gig economy insurance markets across Indonesia and Brazil.
To collect premiums and pay insurance claims in India, an IRDAI licence is required. GigShield operates on two realistic paths:
Path A — Licensed Insurer Partnership (near-term)
GigShield acts as the technology and distribution layer on top of an existing IRDAI-licensed insurer — Digit Insurance, Acko, or New India Assurance. GigShield owns the tech, triggers, fraud detection, and UX. The partner insurer handles policy underwriting, capital, and regulatory compliance. Revenue model: per-policy distribution fee to GigShield.
Path B — IRDAI InsurTech Regulatory Sandbox (pilot)
IRDAI operates a regulatory sandbox programme specifically for InsurTech startups. GigShield can run a limited live pilot — defined geography, capped number of policies — without a full licence. This is exactly how Acko and Digit began.
| Revenue Stream | Description |
|---|---|
| Per-policy distribution fee | Fixed fee earned per active policy issued through partner insurer |
| Platform co-subsidy | Zepto / Blinkit / Swiggy pay to co-fund rider premiums as retention spend |
| Data licensing | Anonymised zone-level disruption risk data sold to logistics platforms |
| Premium margin | Difference between collected premiums and actual claims plus reserves |
The working demo covers the complete technology layer — parametric trigger engine with real weather and AQI APIs, AI fraud scoring returning APPROVE / FLAG / REJECT, dynamic premium calculator per zone, and a full claims dashboard with APPROVE / FLAG / REJECT claim states and payout amount display.
In a live deployment, UPI payout rails connect through the licensed insurance partner's payment infrastructure. Razorpay integration for automated premium collection and payout disbursement is planned for Phase 3. The core technology is production-ready. The regulatory wrapper is the next step.
GigShield is not just a hackathon project — it is a viable InsurTech model addressing a gap that 5 million workers fall into every monsoon season. The triggers are real. The math works. The path to production is clear.
🎬 Phase 1 — Strategy Video: Watch here
🎬 Phase 2 — Demo Video: Watch here
gigshield/
├── frontend/ # React.js + Tailwind CSS app
├── backend/ # Node.js + Express API
│ ├── routes/ # auth, policy, trigger, claim
│ ├── models/ # MongoDB schemas
│ └── config/ # DB connection
├── docs/ # Architecture diagrams, wireframes
└── README.md
Team Caffeine N Commits — Parul University, Vadodara
Guidewire DEVTrails 2026