CIPT study materials
CIPT study resources

40,000 Vehicles, Three Purposes, One Telematics Stream

CIPT · Put your knowledge to work in context.

All case studies

40,000 Vehicles, Three Purposes, One Telematics Stream

An insurer and a carmaker run a 40,000-policyholder telematics pilot. Each vehicle streams 1 Hz telemetry: GPS, speed, hard-brake events, and paired-phone identifiers. Three uses compete. Per-trip scoring needs detail to price a discount. A city road-safety contract pays for counts by census block by hour - no individual vehicles. Claims reconstruction needs 30-second resolution, but only for the roughly 2% of vehicles in an open claim each year. The scoring model needs 90 days of history; the claims team is contractually bound to keep records for seven years. Participants consented to "driving behavior analysis for insurance pricing" and may withdraw at any time.

1. Choose an architecture. Where do you minimize - at collection or downstream - and what does each purpose get?

Read the worked answer

Minimize at collection wherever the purpose allows, because downstream controls only constrain people who cooperate. The scale argument is decisive: 40,000 vehicles at 1 Hz is roughly 3.5 billion location points per day. Retaining that raw stream for everyone is a privacy liability the size of the business.

Design by purpose:

  • Scoring. Compute on the edge, in the vehicle: trip distance, harsh-event rate, time-of-day band, urban/highway mix. Upload summaries only. The model needs behavioral features, not a trace - and a trace is what reveals home, workplace, and everything else.
  • City analytics. Generate block-hour counts inside the trusted boundary from summaries, with minimum cell suppression (suppress cells below a threshold) or calibrated noise added. The city receives aggregates under an agreement forbidding re-identification or linkage. They never receive rows, so there is nothing to re-identify.
  • Claims. Keep raw 30-second resolution in an edge ring buffer that is overwritten unless a trigger fires - a crash signal, a claim opening, or the policyholder's request. Triggered extracts are then uploaded, encrypted, and tied to the claim.

Net effect: near-zero raw traces stored at rest for 98% of vehicles, purpose-adequate data for all three uses, and a much smaller breach surface. The 90-day scoring history lives as summaries, not locations.

2. The city wants raw data "just in case," and claims wants full-resolution history for all 40,000 vehicles. What do you give each, and what do you refuse?

Read the worked answer

Refuse both as stated, for the same reason: a purpose that is undefined cannot be tested for necessity.

City - refuse raw rows. "Just in case" describes no analysis, so there is no basis for deciding which fields are adequate and relevant - the test purpose limitation imposes. Give them block-hour counts, a documented method (so the numbers are defensible in a public meeting), suppression rules, and a use agreement barring re-identification and joins to vehicle registration data. If they want more flexibility, offer a query interface over aggregates, not a dump. If you use differential privacy, publish the parameter so results are reproducible and the budget auditable.

Claims - refuse full-resolution retention for the whole fleet. The purpose is real, and the contract's seven-year clock is real, but both attach to claim files, not to every vehicle's daily movement. Store triggered extracts keyed to an open claim, retained for the claim period under a legal-claims basis, access-controlled and audited. Do not turn claims defense into a blanket archive.

Also watch the phone identifiers. Paired-phone IDs reveal who else is in the car and can link a vehicle to a person who never consented. Unless a use genuinely requires them, drop them at the edge. Passive collection of bystander data is where a defensible pilot becomes indefensible.

3. A participant withdraws consent while an injury claim from their policy is open. What happens to their data?

Read the worked answer

Stop the consented processing; keep only what the claim requires, under a different basis, and document the switch.

  • Prospective effect. Withdrawal ends telematics collection for pricing immediately. The app must make withdrawal as easy as consent and must not degrade service punitively in ways the terms don't permit.
  • The claim is a separate basis. Data needed to establish, exercise, or defend a legal claim can generally be retained and processed on that footing rather than consent. So the claim-relevant extract survives - the crash window, the policy terms, the correspondence - and the basis changes from consent to claims defense.
  • But apply necessity per data element. "Claims defense" does not license keeping seven years of commute patterns. The retained set should be what an adjuster or court would actually need; everything else goes, including the scoring summaries, which have no claims function.
  • Firewall the retained data. It is not available for model training, product analytics, or the city contract. Write that restriction down and enforce it in access control, because in practice the easy thing is to keep using it.
  • Record the reasoning. Note the withdrawal date, what was deleted, what was retained and under which basis, and who decided. This is the answer you will need if the claimant later disputes the handling.

Expect the adversarial case. An open injury claim means the data may be examined by the other side; handle it as potential evidence from the moment of withdrawal, not after a dispute notice arrives.