Telematics driving-behaviour scoring & usage-based motor insurance

Traditional motor tariffs price drivers by proxies such as age, postcode and vehicle type. Telematics measures how a person actually drives. Sensors in the phone, a small beacon, a plug-in device or the car itself produce trips; ML segments the trips, detects events and condenses them into a risk score that rewards safe drivers with a discount, coaches risky ones, and detects crashes within seconds. Because location and behaviour data are highly sensitive, the GDPR design (consent, pseudonymisation, on-device processing) is as important as the model.

Problem & value

• Today: premiums are set from static rating factors (see PRED-010). Safe young drivers or low-mileage drivers subsidise others; fleets learn about unsafe driving only after claims; claims start with a phone call.
• AI value: behaviour-based risk differentiation (a stronger predictor of claims than static factors in insurer experience), behavioural feedback that reduces risky driving, faster crash handling, and customer engagement between renewals.
• Vendor-reported effects (not independently audited): Cambridge Mobile Telematics (CMT) states on its site that its DriveWell Engage programmes yield 20 % less distracted driving, 9 % less hard braking and 5.5 % fewer injury-related claims, that programmes can let drivers save up to 50 % on auto insurance, and that DriveWell has helped prevent over 100,000 crashes [1]. Treat these as marketing claims and test them in your own portfolio via a control group.
• Concrete German tariff example: HUK-COBURG's Telematik Plus gives a 5 % start bonus on liability and comprehensive cover and a driving-based follow-up bonus of up to 30 % per year; a 0-100 score is built from speed, acceleration, braking and steering, the first evaluation needs at least two months and 20 hours of driving, and the bonus can never be negative [2].

Variants

• Pay-how-you-drive (PHYD) for private motor insurance: score → discount at renewal (HUK-COBURG Telematik Plus [2], Allianz BonusDrive, Generali's telematics offer built with Octo/Jeniot, and many insurers in IT, UK, US). Typically discount-only in Germany/EU so that bad driving is not penalised directly.
• Pay-as-you-drive / pay-per-km: price follows mileage and time of day; needs odometer or trip data.
• Young-driver and novice programmes: parental feedback, curfew and graduated-licence incentives.
• Fleet telematics (non-insurance): safety coaching, driver ranking and insurance negotiation for logistics and company-car fleets; works council co-determination applies (see Risks).
• Crash detection & automated FNOL: event detection triggers emergency call, claim opening and total-loss triage (CMT DriveWell Crash/Claims [1]; Octo Crash and Claims Management [3]).
• OEM / connected-car data: manufacturer data accessed with driver consent via the EU Data Act and OEM APIs, avoiding extra hardware.
• Private use: drivers can get a score and tips through a free app or insurer app; no self-built consumer product is sensible beyond using the insurer's app.

How it works

1. sensors (phone IMU+GPS | BLE beacon | OBD dongle | OEM signals)
2. on-device pre-processing (sampling, filtering, trip start/stop, compression)
3. upload (pseudonymised, Wi-Fi or mobile)
4. stream ingest
5. trip segmentation + transport-mode (car/train/bike) + driver-vs-passenger detection
6. map matching (road type, speed limit) + event detection (braking, cornering, distraction, speeding)
7. trip risk features
8. risk model (GBM/GLM calibrated on claims)
9. rolling driver score
10. tariff engine (bonus/premium, floor at 0 %) | coaching feedback | crash alert
11. FNOL
12. human review of disputes; actuarial monitoring of drift and fairness

• Event detection combines physics-based rules and ML on accelerometer/gyroscope streams; phone-distraction uses screen/handling events from the OS. Newer vendor systems use sensor foundation models (CMT markets DriveWell Atlas for risk, crash detection and coaching [1]).
• Driver vs. passenger is the hardest labelling problem: the score must belong to the policyholder, not to whoever carried the phone (bus, taxi, passenger seat). Fixed beacons (HUK uses a windshield sensor paired with the app [2]) solve most of it.
• Risk model: tabular models (LightGBM, GLMs) on aggregated features such as events per 100 km, night share, speed excess and mileage; the claims target is sparse, so insurers usually blend telematics scores with classical factors in the tariff (PRED-010).
• Human-in-the-loop: customers can dispute scores; actuaries approve score-to-price mapping; claims staff confirm crash-triggered FNOL for serious cases.

Data preparation

Needed data: GPS traces, accelerometer and gyroscope signals, OBD or connected-car signals, trip metadata, and for insurers policy, claims and tariff data from the policy-administration system. Fleets add vehicle master data from fleet or ERP systems and driver assignments from HR. Typical gaps are noisy or missing GPS, sensors mounted in different orientations, phones used by passengers, vehicles without driver assignment, claims records without reliable crash labels, and consent or purpose records scattered across systems. Location data is personal and highly sensitive.

Steps: (1) inventory sources and map them to the use case (PREP-001, PREP-002); (2) pull claims, policy and fleet master data via exports or APIs (PREP-005); (3) clean trips (map matching, orientation calibration, passenger filtering) in a streaming or batch pipeline, for example with Python, Kafka and a time-series database; (4) harvest labels such as claims and harsh events from existing records (PREP-020); (5) pseudonymise driver IDs and check legal basis and purpose (PREP-022, PREP-025). SMBs buying a product mainly need clean driver and vehicle master data. Roughly 30 to 40 percent of effort goes into data work for a build; much less for Path A. See GUIDE-003.

Implementation paths

Which path for whom

• SMB (fleet operators): Path A, because mature EU-hostable fleet telematics and driver-coaching products exist at SMB prices and the process is standard.
• Enterprise (insurers, large fleets): Path C, because the scoring model is core to pricing, location data is highly sensitive and volume makes per-vehicle or API fees expensive.
• Developer: Path C, because open-source time-series and tabular ML plus map-matching give full control over scoring logic.
• Private (drivers): Path A, because insurer or fleet apps and smartphone-based tools are the only practical route for individuals.

Path A — Buy (recommended for fleets and SMBs)

• Telematics platforms / scoring-as-a-service: Cambridge Mobile Telematics (DriveWell; US/EU) [1], Octo Telematics (Italy; DriveAbility score, crash and claims management) [3], Sentiance (Belgium, EU), and Arity/Verisk-type providers outside the EU. Check: EU data residency, raw-data access for your actuaries, score transparency, driver/passenger accuracy, and who is controller or processor.
• Fleet telematics: Webfleet (Bridgestone), Geotab, Samsara, Trackunit-style vendors; coaching and tachograph integration.
• Choose A when: you need production quality in months, lack a data-science team for sensor ML, or you are an MGA/small insurer. Model dependency and score opacity are the main trade-offs.

Path B — Build on cloud APIs

• Mobile SDK + cloud pipeline: vendor or in-house SDK for sensor capture, ingest via managed streaming (Kinesis/Event Hubs/Pub/Sub or Kafka) in EU regions, feature store, managed ML (SageMaker, Azure ML, Vertex AI) for the risk model.
• LLMs are secondary: use general LLMs for customer-facing explanation of scores, coaching texts and claims-call summarisation, not for the score itself.
• Choose B when: you want your own score and tariff logic but no on-prem constraint.

Path C — Self-host (open source)

• Stack: Kafka (Apache-2.0) [7] for streaming, Valhalla/Meili (MIT) [6] for map matching on OpenStreetMap, MovingPandas (BSD-3) [5] for trajectory analysis and stop detection, LightGBM (MIT) [4] or scikit-learn for risk models, ONNX Runtime/Core ML/TFLite for on-device inference, PostgreSQL/TimescaleDB for storage.
• Hardware: mostly CPU (HW1); a GPU only if you train deep sequence models for event detection or driver identification. The real engineering is the mobile SDK (battery drain, OS background limits).
• Effort: high; plan a team with mobile, data and actuarial skills.

Path D — Custom training

• Worth it for proprietary event-detection and driver-vs-passenger models, trip-level risk models trained on your own claims linked to telematics, and crash-severity estimation. Needs months of trips for tens of thousands of policies plus claims with 12+ months of development; labelled crash events are rare, so use synthetic/replayed data and vendor datasets for pre-training.

State of the art (2026)

• Smartphone-first telematics has largely displaced dedicated devices for new programmes, with hardware beacons remaining for accuracy and driver identification (HUK-COBURG is an example [2]).
• Foundation-model style sensor models (e.g. CMT's DriveWell Atlas [1]) are used for risk, crash detection and personalised coaching; independent public benchmarks do not exist, so performance claims rest on vendor and insurer data.
• Engagement programmes (feedback, gamified rewards) are now treated as part of the product, not just scoring; the vendor-reported effects above come from them [1].
• Connected-car data via OEM interfaces and the EU Data Act (applicable since September 2025) makes hardware-free scoring possible if the driver consents; access conditions differ by OEM.
• Limits and failure modes: passenger vs. driver confusion; phone-handling false positives; poor GPS in tunnels/urban canyons; battery and OS permission drop-outs; self-selection (safe drivers opt in), which biases portfolio-level lift; scores that proxy for road type or shift work and thereby discriminate indirectly; score gaming; sparse claims limiting validation.

Shared resources & combinations

• PRED-010 (insurance risk pricing): the telematics score becomes a rating factor in the same tariff and pricing engine; shares tabular-ml and causal-inference (uplift of coaching).
• PRED-037 (claims severity & reserving) and crash-triggered FNOL; VIS-023 damage assessment from photos downstream of FNOL.
• VIS-028 (driver & in-cabin monitoring): camera-based fleet safety is a complementary, far more intrusive signal and has its own legal limits.
• PRED-018 (ETA prediction), PRED-041 (used-vehicle valuation from usage), OPT-021 (EV fleet charging) reuse the same trip, GPS and map-matching pipeline.
• ANOM-003 (insurance fraud) can use trip data to check claimed accident circumstances where contractually agreed; ROBO-005 shares vehicle sensor modelling.
• Shared building blocks: streaming ingest, time-series feature store, map matching on OSM, edge inference on phones (edge-runtime), consent-management platform, pseudonymisation service. Hardware stays HW1 for all of these.

Effort, cost & KPIs

• Path A: 3-6 months incl. app branding, tariff approval and consent flows; per-active-driver SaaS fees.
• Path B: 6-12 months; costs are SDK development, cloud streaming/storage and mobile support.
• Path C/D: 12+ months and a dedicated team; justified at large portfolios.
• Cost drivers: SDK maintenance across iOS/Android releases, support for permission and battery issues, devices and shipping (for beacons), storage of high-frequency data.
• KPIs: opt-in and retention rate, loss ratio of scored vs. unscored matched control group, score-to-claims Gini/lift, driver-vs-passenger accuracy, crash-detection precision/recall and time to FNOL, change in distraction and hard-braking events per 100 km, complaint/dispute rate.

People & change

Management and the department lead (fleet manager, underwriting) decide goals and limits; IT connects vehicles and apps; the data protection officer is needed early because location data is personal and often reveals behaviour. A DPIA (Art. 35 GDPR) is likely (systematic monitoring, new technology at scale), plus AVV with the telematics provider (Art. 28). Works council: depends. For fleets with employed drivers the system is clearly suited to monitor behaviour and performance, so co-determination under §87(1) no. 6 BetrVG applies and a works agreement is needed (no individual ranking, limited retention, no use for dismissal); for insurers it applies to internal tooling that logs staff activity. Inform the council early under §90(1) no. 3.

AI literacy: the AI Act (Art. 4) requires measures to support staff literacy; train fleet managers and underwriters on what a score means and its limits. Communicate openly what is measured and why, pick a pilot group of volunteer drivers, and present coaching, not punishment. Typical concerns: surveillance (fix data scope, share the driver's own view), unfair scores (appeal path). Keep a human in the loop for consequences. See GUIDE-004, GUIDE-005, GUIDE-008.

Risks, regulation & compliance

• EU AI Act: Annex III 5(c) lists AI for risk assessment and pricing for natural persons in life and health insurance as high-risk [8]; motor insurance is not named there, so a motor telematics score is usually not high-risk, but classification depends on use (e.g. if the score feeds life/health pricing, or if it is used for employee evaluation, which falls under employment high-risk rules). Art. 5 prohibits social scoring and certain manipulative practices; do not mix driving scores with unrelated behavioural data. Fleet camera-based emotion recognition at work is prohibited (see VIS-028). AI literacy (Art. 4) applies.
• GDPR / ePrivacy: location and trip data are personal data and highly revealing. The EDPB's Guidelines 01/2020 on connected vehicles require valid consent or another legal basis, purpose limitation, data minimisation, local processing where possible, and state that telemetry collected for other purposes may not be passed to insurers for driver profiling without the user's consent [9]. Reading device sensors also triggers ePrivacy Art. 5(3). A DPIA (Art. 35) is expected; joint-controller arrangements between insurer and platform vendor must be documented (Art. 26) [9].
• Automated decisions: a score that sets a price may fall under GDPR Art. 22; ensure human review, disputes and meaningful explanation. HUK-COBURG's design (pseudonymised data, insurer without raw-trip access, no negative bonus) is an example of privacy-friendly structuring [2].
• Insurance supervision: tariff changes need actuarial justification; avoid indirect discrimination (gender-neutral pricing since the Test-Achats ruling) and keep records for BaFin/EIOPA review.
• Employment: fleet scoring of employees needs works-council agreement (§87 BetrVG in Germany) and clear private-use rules.
• Mitigations: opt-in with a no-penalty design, on-device processing of raw data, short retention of raw GPS, driver-identification controls, regular fairness and drift reviews, human appeal path.

Getting started

1. Define the product: discount-only PHYD, mileage-based, young-driver or fleet coaching, and agree with legal on the legal basis, DPIA and controller roles.
2. Run a vendor pilot (CMT, Octo, Sentiance or a fleet vendor) with 1,000-5,000 volunteers and a matched control group; demand raw-feature access and driver/passenger accuracy figures.
3. Link scores to claims over at least one full policy year and calibrate the score-to-tariff mapping with actuaries (floor at zero penalty if you want a consumer-friendly design).
4. Build consent, withdrawal and dispute flows into the app before launch.
5. Add crash detection / FNOL only after false-alarm rates are measured on your population.

Sources

1. Cambridge Mobile Telematics — DriveWell products and results (accessed 2026-10) — https://www.cmtelematics.com/
2. HUK-COBURG — Telematik Plus tariff description (accessed 2026-10) — https://www.huk.de/fahrzeuge/kfz-versicherung/telematik-plus.html
3. Octo Telematics — OCTO Motor Insurance, DriveAbility, crash and claims management (accessed 2026-10) — https://www.octotelematics.com/
4. LightGBM (MIT) — https://github.com/microsoft/LightGBM
5. MovingPandas (BSD-3) — https://github.com/movingpandas/movingpandas
6. Valhalla routing engine with Meili map matching (MIT) — https://github.com/valhalla/valhalla
7. Apache Kafka (Apache-2.0) — https://github.com/apache/kafka
8. EU AI Act Annex III (point 5 essential services) — https://artificialintelligenceact.eu/annex/3/
9. EDPB Guidelines 01/2020 on connected vehicles and mobility-related applications — https://www.edpb.europa.eu/system/files/documents/2021-03/edpb_guidelines_202001_connected_vehicles_v2.0_adopted_en.pdf
10. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj