Usage-based insurance is replacing the guesswork in auto insurance pricing. Instead of estimating risk from demographics — age, zip code, credit score — UBI programs measure actual driving behavior and price policies accordingly.
For insurers, the shift is existential: carriers that adopt UBI attract lower-risk drivers, reduce claims costs, and build defensible pricing advantages. For insurtech teams building these programs, the challenge is technical — how do you collect driving data at scale, score it reliably, feed it into pricing models, and automate claims?
This guide covers the full UBI stack from the SDK provider perspective: what the technology does, how the data flows, and what it takes to build a production UBI program on smartphone telematics.
Table of Contents
- What Is Usage-Based Insurance?
- UBI Program Models: PAYD, PHYD, and MHYD
- The UBI Data Pipeline: End-to-End Architecture
- Telematics Data Collection
- Scoring Models for Insurance Pricing
- Integration Architecture for Insurers
- Claims Automation: From Crash Detection to FNOL
- Regulatory and Privacy Considerations
- Why Build UBI on a Smartphone SDK
- FAQ
1. What Is Usage-Based Insurance?
Usage-based insurance (UBI) is an auto insurance model where premiums are calculated from real driving data rather than statistical proxies. The core principle: drivers who drive less, drive safer, or both, pay less for coverage.
Traditional insurance pricing relies on actuarial tables built from population-level correlations — young male drivers pay more because, on average, their cohort has more claims. UBI replaces this with individual-level measurement: your premium reflects your driving, not your demographic group’s.
1.1 Why UBI Is Growing
Three forces drive adoption:
- Adverse selection pressure: Insurers using UBI attract safe drivers away from competitors still using blunt demographic pricing — improving their loss ratios
- Smartphone penetration: Every policyholder already carries the sensors needed for telematics data collection, eliminating hardware costs
- Regulatory tailwinds: Multiple jurisdictions now encourage or require behavior-based pricing transparency
1.2 The Business Case
For carriers, UBI delivers measurable results:
- 10-25% reduction in claims frequency among monitored drivers (behavior modification effect)
- More accurate risk segmentation within traditional rating tiers
- Higher retention of low-risk drivers who see premium rewards for safe behavior
- Automated FNOL reducing claims processing time from days to seconds
2. UBI Program Models: PAYD, PHYD, and MHYD
Not all UBI programs are the same. They differ in what data they use and how it affects pricing.
2.1 Pay-As-You-Drive (PAYD)
The simplest model: premiums scale with mileage. Drive less, pay less. Data requirement is minimal — just distance traveled. Low-mileage drivers benefit; high-mileage commuters may see higher premiums.
Data needed: Trip distance, odometer readings
Limitation: Doesn’t account for how you drive — a careful long-distance driver pays more than a reckless short-trip driver.
2.2 Pay-How-You-Drive (PHYD)
The most common UBI model: premiums adjust based on driving behavior. Scoring considers harsh braking, rapid acceleration, cornering, speeding, phone usage, and time-of-day driving patterns.
Data needed: Full trip telemetry — acceleration events, speed vs. limits, phone distraction, GPS traces, time of day
Advantage: Directly rewards safe driving. Creates a feedback loop where drivers improve behavior to lower premiums.
2.3 Manage-How-You-Drive (MHYD)
An evolution of PHYD that adds active coaching and real-time feedback. Beyond passive scoring, the app provides tips, gamification, and immediate alerts (e.g., “you’re speeding”) to actively improve behavior.
Data needed: Same as PHYD, plus real-time processing for in-trip feedback
Advantage: Higher engagement, faster behavior change, additional retention lever through app stickiness.
2.4 Comparison Table
| Model | What’s Measured | Data Complexity | Pricing Impact |
|---|---|---|---|
| PAYD | Distance only | Low | Linear mileage adjustment |
| PHYD | Driving behavior | High | Multi-factor score-based |
| MHYD | Behavior + coaching response | High + real-time | Dynamic, engagement-weighted |
3. The UBI Data Pipeline: End-to-End Architecture
Building a UBI program requires a complete data pipeline from sensor to pricing decision. Here’s the end-to-end architecture:
3.1 Pipeline Stages
- Data Collection — Telematics SDK on the policyholder’s smartphone captures GPS (1 Hz) + accelerometer/gyroscope (60 Hz) + screen state
- Trip Processing — Raw sensor data is assembled into trips, filtered for validity (removing GPS jumps, non-vehicle movement), and enriched with road context (speed limits, road type)
- Event Detection — Driving events extracted: harsh braking, acceleration, cornering, speeding, phone usage, crash events
- Scoring — Events converted to risk scores using configurable penalty models (per-trip and rolling aggregate)
- Data Export — Scores and trip data delivered to insurer systems via API, webhooks, or S3 batch export
- Pricing Integration — Insurer’s actuarial/pricing engine consumes scores to adjust premiums
- Claims Automation — Crash detection triggers instant FNOL with forensic sensor data
3.2 Data Flow Architecture
The pipeline operates in two modes simultaneously:
- Batch (daily/weekly): Aggregated scores and statistics exported to S3 or pulled via Statistics API — feeds actuarial models and portfolio reporting
- Real-time (event-driven): Backend notifications (webhooks) fire on trip completion, crash detection, and status changes — feeds claims systems, coaching apps, and operations dashboards
For detailed documentation of the data workflow and processing stages, see Damoov’s data workflow documentation.
4. Telematics Data Collection
The foundation of any UBI program is reliable, continuous driving data collection. The telematics SDK handles this entirely on-device.
4.1 Sensor Data Captured
| Data Source | Frequency | What It Provides |
|---|---|---|
| GPS | 1 Hz | Location, speed, route, distance |
| Accelerometer | 60 Hz | Braking, acceleration, cornering forces |
| Gyroscope | 60 Hz | Rotation, phone handling, crash dynamics |
| Magnetometer | 60 Hz | Heading, compass direction |
| Screen state | Event-based | Phone distraction detection input |
4.2 Trip Detection
The SDK automatically detects trip start and end using accelerometer patterns — no driver interaction required. It handles edge cases that would corrupt data:
- Distinguishing parking from red-light stops
- Filtering GPS drift that mimics movement
- Identifying vehicle vs. non-vehicle transport (walking, cycling, train)
- Merging trip segments interrupted by brief stops
4.3 Background Operation
For UBI, data collection must be invisible. The SDK operates entirely in the background:
- Automatic tracking mode — zero user interaction required
- Battery-optimized sensor management
- Offline buffering when connectivity is unavailable
- Background upload when trips complete
4.4 Data Volume per Driver
A typical driver generates:
- 2-4 trips per day
- ~50-100 GPS points per trip (at 1 Hz)
- 5-15 driving events per trip
- Rolling 14-day scoring aggregates
At portfolio scale (50,000+ policyholders), this produces rich actuarial datasets within 1-3 months — sufficient for stable scoring according to Damoov’s analysis of scoring model convergence.
5. Scoring Models for Insurance Pricing
Raw driving data becomes insurance-relevant through scoring models that quantify risk. This is where telematics data translates into pricing signals.
5.1 Safety Score (100-Point Scale)
The primary UBI scoring signal. Each trip receives a score based on five weighted event categories:
| Category | What It Measures | Detection Method |
|---|---|---|
| Harsh Braking | Deceleration ≥2.7 m/s², duration ≥600ms, speed ≥25 km/h | Accelerometer + ML filtering |
| Rapid Acceleration | Acceleration ≥2.7 m/s², duration ≥600ms, speed ≥25 km/h | Accelerometer + ML filtering |
| Sharp Cornering | Lateral force ≥3 m/s², duration ≥600ms, speed ≥25 km/h | Accelerometer + ML filtering |
| Speeding | Actual speed vs. posted limits (HERE/Google data) | GPS + map data |
| Phone Distraction | Phone handling while driving ≥15 km/h | ML model on accel/gyro + screen state |
Each event generates penalty points proportional to the risk level (severity × duration × speed context). Trip score = 100 minus weighted penalty total, adjusted by distance. Star ratings: 100 = 5 stars, ≥90 = 4 stars, ≥80 = 3 stars, ≥70 = 2 stars, <70 = 1 star.
5.2 Aggregate Scoring (14-Day Rolling Window)
Individual trip scores aggregate into a rolling driver score over a configurable period (default 14 days). This smooths out single-trip anomalies and provides the stable signal actuaries need for pricing:
- Distance-weighted aggregation (longer trips count more)
- Per-category breakdowns (so insurers know why a driver scores low)
- Stabilization period: 3-4 months for reliable annual mileage estimation; 1 month for driving style classification
5.3 Eco Score
A secondary signal measuring fuel efficiency, tire wear, and brake wear potential. Useful for fleet UBI programs or green driving incentives:
- Fuel sub-score: Acceleration/braking patterns, speed volatility, extreme speeds
- Tire sub-score: Cornering forces, speed, road quality, mileage
- Brake sub-score: Deceleration intensity, frequency, operating temperature
5.4 Configurable Scoring
Every scoring parameter is configurable per insurer deployment: event thresholds, penalty weights, aggregation period, speed limit buffers, and phone usage minimum speed. This lets actuarial teams tune the model to their book of business.
For full scoring methodology documentation, see Damoov’s safety score documentation.
6. Integration Architecture for Insurers
Connecting telematics data to insurance systems requires a clear integration architecture. Here’s how an insurer’s stack connects to the telematics platform.
6.1 API Endpoints for UBI
| API | UBI Use Case | Typical Consumer |
|---|---|---|
| Statistics API | Aggregate scores over configurable periods | Actuarial/pricing engine |
| Scoring API | Per-trip and per-driver safety/eco scores | Rating algorithm, renewal pricing |
| Trips API | Trip details, events, routes | Claims investigation, customer portal |
| User Management API | Policyholder registration, group assignment | Policy admin system |
| Engagement API | Leaderboards, rewards, DriveCoins | Mobile app, retention team |
6.2 Backend Notifications (Webhooks)
Event-driven integration for real-time workflows:
- Trip completed: Triggers score calculation and delivery
- Crash detected: Triggers FNOL workflow immediately
- Data processed: Signals that enriched trip data is available for API retrieval
Supported notification services: Amazon SNS, Azure Notification Hubs, custom webhook endpoints.
6.3 Batch Export (S3)
For actuarial teams that work with bulk data:
- Daily CSV/JSON exports to Amazon S3
- Configurable fields and aggregation periods
- Compatible with BI platforms (QuickSight, Google Data Studio)
- Historical data for model development and backtesting
6.4 Multi-Instance Architecture
Enterprise insurers need data isolation between products, brands, or markets. The platform supports a hierarchical structure:
Company → Application → User Group → User
Each level can have independent scoring configurations, notification endpoints, and data access policies. This lets a single carrier run multiple UBI products (personal auto, commercial fleet, rideshare) on one platform without data mixing.
For API integration details, see Damoov’s Telematics API documentation.
7. Claims Automation: From Crash Detection to FNOL
UBI’s highest-impact capability for insurers isn’t pricing — it’s claims automation. Automatic crash detection transforms the claims workflow from reactive to instant.
7.1 How It Works
- Impact detected: SDK identifies collision via accelerometer spike + multi-signal validation
- High-frequency buffer captured: 60 Hz (iOS) / 100 Hz (Android) sensor data, ±5 seconds around impact
- Instant notification: Backend receives crash event with location, speed, severity, and full sensor buffer within seconds
- FNOL created: Automated first notification of loss with objective, sensor-verified evidence
- Triage: Impact severity data enables immediate classification — minor fender-bender vs. major collision
7.2 Value for Insurers
| Traditional Claims | Telematics-Enabled Claims |
|---|---|
| Notification: hours to days | Notification: seconds |
| Evidence: self-reported | Evidence: sensor-verified, forensic-grade |
| Fraud detection: manual investigation | Fraud detection: data validates/contradicts claim |
| Severity: estimated from photos | Severity: measured from impact forces |
| Speed at impact: unknown | Speed at impact: GPS-measured |
7.3 Crash Data for Reconstruction
The sensor buffer provides forensic evidence that traditionally requires expensive accident reconstruction:
- Three-axis acceleration: direct (longitudinal), lateral, vertical
- Pre- and post-impact speed from GPS
- Direction of force (front, side, rear impact)
- Duration and severity of deceleration event
- Vehicle rotation (spin, roll) from gyroscope correlation
For a deeper technical explanation of crash detection, see our article on how automatic crash detection works. Technical documentation: crash data reference.
8. Regulatory and Privacy Considerations
UBI programs collect sensitive location and behavioral data. Regulatory compliance isn’t optional — it’s a launch requirement.
8.1 Consent and Transparency
- Explicit opt-in: Policyholders must actively consent to telematics monitoring. Most programs offer premium discounts as incentive.
- Clear disclosure: What data is collected, how it affects pricing, who has access, and how to opt out
- Right to withdraw: Drivers can stop sharing data (typically reverting to standard pricing)
8.2 Data Protection (GDPR, CCPA)
- Data minimization: Collect only what’s needed for scoring. Raw GPS traces needed for scoring can be deleted after processing.
- Purpose limitation: Data collected for pricing cannot be repurposed for marketing without separate consent
- Right to access/delete: Policyholders can request their driving data or its deletion
- Data residency: Some jurisdictions require processing within geographic boundaries
8.3 Rating Regulation
- Actuarial justification: Regulators in many states require demonstrated correlation between telematics variables and loss experience
- Non-discrimination: UBI scoring must not serve as a proxy for protected characteristics (race, disability)
- Rate filing: UBI rating plans typically require regulatory approval before deployment
8.4 Implementation Approach
The telematics platform handles the data layer; the insurer handles the regulatory layer. Clean separation:
- Platform provides: data collection, processing, scoring, secure storage, API access, data deletion endpoints
- Insurer provides: consent flows, disclosure language, regulatory filings, pricing decisions, customer communication
9. Why Build UBI on a Smartphone SDK
UBI programs have historically used OBD dongles or black boxes installed in vehicles. Smartphone-based telematics changes the economics and capabilities.
9.1 Smartphone vs. Hardware Comparison
| Factor | Smartphone SDK | OBD Dongle | Black Box |
|---|---|---|---|
| Hardware cost | $0 (uses driver’s phone) | $30-80 per device | $100-300 + installation |
| Deployment time | Minutes (app install) | Days (ship + self-install) | Weeks (schedule installation) |
| Scalability | Unlimited — app store distribution | Limited by inventory/shipping | Bottlenecked by installer capacity |
| Sensor richness | GPS + accel + gyro + screen state | GPS + OBD vehicle data | GPS + accel (varies) |
| Phone distraction | Yes (ML detection) | No | No |
| Crash detection | Yes (60-100 Hz buffer) | Basic (lower sampling) | Yes (dedicated hardware) |
| Driver identification | Inherent (tied to phone) | Needs additional logic | Needs additional logic |
| Maintenance | OTA updates via app store | Device failures, returns | Field service |
9.2 When Smartphone Wins
- Personal auto UBI: Mass-market programs where $50+ per device kills unit economics
- Try-before-you-buy: Quote-time scoring from a single trip — impossible with hardware that hasn’t shipped yet
- Multi-vehicle households: One app works across all cars; hardware needs one device per vehicle
- Young/urban drivers: Demographics most likely to adopt app-based programs and least likely to have OBD-II ports (EVs, newer cars)
9.3 When Hardware Still Applies
- Commercial fleet: Company-owned vehicles where phones aren’t always present
- High-precision requirements: Where OBD vehicle data (RPM, fuel consumption, DTCs) is needed
- Regulatory mandates: Some jurisdictions require certified tamper-proof devices
Damoov’s Telematics SDK supports iOS, Android, Flutter, React Native, and Xamarin — covering the smartphone path with cross-platform flexibility.
FAQ
1. What is usage-based insurance?
Usage-based insurance (UBI) is an auto insurance model where premiums are determined by actual driving behavior and mileage rather than demographic factors alone. Telematics technology — typically a smartphone SDK or in-vehicle device — collects driving data that feeds into scoring models used for pricing decisions.
2. How does a telematics SDK collect driving data for UBI?
The SDK uses the smartphone’s built-in sensors: GPS for location and speed (1 Hz), accelerometer and gyroscope for driving events like braking and cornering (60 Hz), and screen state for phone distraction detection. Trip detection is fully automatic — no driver action required.
3. What driving factors affect UBI pricing?
Five primary factors in most PHYD programs: harsh braking frequency, rapid acceleration, sharp cornering, speeding (compared to posted limits), and phone usage while driving. These are weighted into a composite safety score that correlates with claims risk.
4. How long does it take for UBI scoring to stabilize?
Approximately 1 month to reliably classify driving style, and 3-4 months for stable annual mileage estimation. Most programs start with a monitoring period before scores begin affecting premiums.
5. What is the difference between PAYD and PHYD insurance?
Pay-As-You-Drive (PAYD) adjusts premiums based on distance driven only. Pay-How-You-Drive (PHYD) adjusts premiums based on driving behavior — how safely you drive, not just how much. PHYD requires richer telematics data (acceleration events, speeding, phone use) but provides more accurate risk differentiation.
6. Can UBI work without hardware in the car?
Yes. Smartphone-based UBI uses the driver’s existing phone as the telematics device. Modern smartphone sensors (accelerometer, gyroscope, GPS) provide sufficient data resolution for driving behavior scoring, crash detection, and trip tracking — with zero hardware cost and instant deployment via app store distribution.