Session 10: Embedded & Usage-Based Insurance

1. What is Embedded Insurance?

Embedded insurance is the integration of insurance products into the purchase journey of another product or service — at the moment the customer needs it, in the context where they need it, without requiring a separate insurance purchase process. The insurance is "embedded" into the customer experience of a non-insurance platform.

This is not simply "selling insurance through a partner." The distinction is fundamental: in a traditional partnership, the partner is a distribution channel — the customer must still actively choose to buy insurance. In embedded insurance, the insurance is part of the product experience. The customer buying a flight ticket on MakeMyTrip does not "buy travel insurance" — they check a box during checkout. The customer booking a ride on Ola does not "buy personal accident cover" — they accept a ₹5 add-on. The insurance is invisible until it is needed. This invisibility is the core innovation.

1.1 Embedded vs. Traditional Distribution

2. The Economics of Embedded Insurance

The economic advantage of embedded insurance over traditional distribution is not incremental — it is structural. Embedded models change the fundamental unit economics of insurance distribution in four ways that standalone digital channels cannot replicate.

2.1 The Four-Part Economics Advantage

1. Near-zero marginal CAC: The platform already pays to acquire its users (through marketing, product investment, brand). Adding insurance as an offer at checkout costs almost nothing — the marginal cost of displaying a checkbox on a checkout page that already exists. This compares to ₹2,000–₹5,000 CAC for a standalone digital insurance channel. The economic difference is enormous — and it is structural, not a matter of optimization.
2. Contextual conversion: Embedded insurance converts at 15–50% because the customer is already in a purchase mindset. They have already decided to spend money — the incremental decision to add insurance is psychologically easy. In contrast, a standalone insurance website requires the customer to overcome multiple cognitive barriers: "Should I buy insurance? Which one? Is this a good price? Will the claim actually work?" By the time embedded insurance offers appear, the customer has already answered most of these questions implicitly.
3. Adverse selection reversal: In standard insurance, the customers most likely to buy are those who believe they have the highest risk — a problem insurers manage through underwriting. In embedded insurance, the customer is buying the primary product (a flight, a phone, a ride) for reasons unrelated to the insurance. The insurance purchase is almost incidental. This dramatically reduces adverse selection — the insurance pool looks more like the general population, not a self-selected high-risk segment. This structural advantage can improve loss ratios by 5–15 points compared to standalone channels.
4. Trust transfer: Customers trust Amazon with their payments, their address, and their product choices. When Amazon offers insurance on a phone purchase, some of that trust transfers to the insurance product. The customer does not need to research the insurer's claim settlement ratio — they trust Amazon to have vetted the partner. This trust transfer reduces the "trust barrier" that is one of the biggest friction points in standalone insurance purchase. In marketing terms, embedded insurance turns "pull" (I need to research and decide) into "push" (here is an offer from a platform I already trust).

2.2 The Revenue Split Model

In a typical embedded insurance arrangement, the premium is split three ways:

• Platform (distribution partner): 30–50% of premium — the platform's commission for providing access to its customer base and handling the checkout experience. This is their "take rate." For platforms with thin margins (e-commerce, mobility), insurance can be a high-margin incremental revenue stream.
• Insurer (risk carrier): 40–60% of premium — after paying claims (typically 50–75% of this share) and expenses (15–25%), the insurer earns an underwriting margin of 5–20% on its share.
• Enabler (API infrastructure provider): 5–15% of premium or a SaaS fee — the technology layer connecting the platform to multiple insurers. This is Riskcovry, Zopper, and similar API enabler business models.

For the insurer, the trade-off is simple: in embedded insurance it keeps a smaller slice of each premium. Of a ₹1,000 premium, the platform takes its commission and the enabler its fee, leaving the insurer roughly ₹400–600 — versus the full ₹1,000 it would keep on a standalone policy. The key question is whether the smaller slice still produces a better business.

It does, because the insurer's costs are also far smaller. Acquisition is nearly free — the platform's existing traffic is the audience, so there is no ₹1,500–5,000 CAC to recover and no aggregator commission. The pool is also better risk (the adverse-selection reversal from §2.1), so claims run lower. A standalone insurer must spend heavily to acquire each customer and then recover that spend across several years of renewals; an embedded insurer starts making money on the first policy.

The correct measure is therefore profit per policy, not premium per policy. Example, on a ₹1,000 premium: an embedded insurer keeps ₹500 after platform and enabler cuts, pays ₹300 in claims and ₹100 in expenses, and banks ₹100 profit with zero acquisition cost — immediately. A standalone insurer keeps the full ₹1,000, but after a 70% loss ratio (₹700), expenses (₹150) and a ₹1,500 acquisition cost, its first-year profit is often negative — it reaches ₹100 profit only after the customer renews for 2–3 years. And renewal is where embedded insurance compounds: embedded customers often auto-renew because the platform handles renewal as part of its ecosystem, while standalone renewal must be won again every year. Lower cost + better risk + higher retention together mean the embedded profit per policy can match or beat standalone — and it repeats every renewal.

4. Usage-Based Insurance (UBI)

Usage-Based Insurance uses data about actual behaviour — how much someone drives, how well they drive, what time of day they drive — to price insurance more accurately than traditional risk factors (age, gender, vehicle type, location). UBI is the most significant innovation in personal lines insurance pricing since the actuarial table, because it replaces inferred risk (what group you belong to) with observed risk (what you actually do).

4.1 PAYD vs. PHYD

4.2 Data Sources for UBI

UBI data comes from four sources, each with different cost, accuracy, and customer friction profiles:

• Smartphone app: Uses the phone's GPS, accelerometer, and gyroscope to track speed, braking, cornering, and phone use while driving. Lowest hardware cost (customers already have smartphones). Highest data quality challenge (phone position varies, cannot distinguish driver from passenger). Requires significant signal-processing investment to clean the data.
• OBD-II dongle: Plugs into the vehicle's diagnostic port. Reads real-time vehicle data: speed, RPM, engine load, fuel consumption, GPS. Most accurate driving data. High hardware cost (~₹2,000–₹5,000 per device) and installation friction (customer must plug it in). Widely used in early UBI programmes globally.
• Black-box / OEM integration: Some modern vehicles (Tesla, connected cars) natively capture telematics data and can share it via API. No additional hardware needed. Limited by the number of connected vehicles on the road — currently a small fraction of the Indian vehicle fleet.
• Dashcam with computer vision: Emerging — dashcam footage analysed by AI to detect driving events (hard braking, lane deviation, following distance, phone use). Combines the accuracy of OBD with the contextual richness of video. High data processing cost.

5. UBI Data Analysis in Python

In this section, we work with a synthetic telematics dataset. The data represents a month of driving behaviour for 500 policyholders, including mileage, driving events, time-of-day patterns, and claims history. The objective is to build a risk score from behavioural data and compare PAYD (Pay-As-You-Drive) Vs PHYD (Pay-How-You-Drive).

5.1 Loading the Telematics Data

import pandas as pd
import numpy as np
import matplotlib.pyplot as plt

# Load synthetic telematics data
telematics = pd.read_csv('data/telematics_data.csv')

print(f"Drivers: {telematics.shape[0]:,}")
print(f"Columns: {telematics.columns.tolist()}")
print(f"\nData types:\n{telematics.dtypes}")
print(f"\nSummary statistics:\n{telematics.describe()}")

# Key columns:
# driver_id — Unique driver identifier
# total_km — Kilometres driven in the month
# avg_speed_kmph — Average speed
# hard_braking_events — Count of hard braking events
# hard_accel_events — Count of rapid acceleration events
# night_driving_pct — Percentage of driving at night (10pm-5am)
# phone_use_events — Count of phone usage events while driving
# previous_claims — Number of claims in the last 3 years
# claim_amount_last_3y — Total claim amount in the last 3 years

5.2 Building a Behavioural Risk Score

▶ Prerequisite: run the §5.1 block first in the same notebook — telematics is defined there. This block will not run standalone.

# Define risk factor weights (these would be calibrated from claims data)
RISK_WEIGHTS = {
    'km_risk': 0.20,              # Higher mileage = more exposure
    'braking_risk': 0.25,         # Hard braking = unsafe driving pattern
    'accel_risk': 0.15,           # Hard acceleration = aggressive driving
    'night_risk': 0.20,           # Night driving = higher accident risk
    'phone_risk': 0.20            # Phone use = distraction risk
}

# Set thresholds for each risk factor
KM_THRESHOLD_HIGH = 2000       # km/month — above this is high mileage
BRAKING_THRESHOLD = 15         # events/month — above this is aggressive
ACCEL_THRESHOLD = 10           # events/month
NIGHT_THRESHOLD = 25           # % of driving at night
PHONE_THRESHOLD = 5            # events/month

# Calculate risk sub-scores (each normalised to 0–100)
telematics['km_risk'] = np.clip(
    (telematics['total_km'] / KM_THRESHOLD_HIGH) * 100, 0, 100
)

telematics['braking_risk'] = np.clip(
    (telematics['hard_braking_events'] / BRAKING_THRESHOLD) * 100, 0, 100
)

telematics['accel_risk'] = np.clip(
    (telematics['hard_accel_events'] / ACCEL_THRESHOLD) * 100, 0, 100
)

telematics['night_risk'] = np.clip(
    (telematics['night_driving_pct'] / NIGHT_THRESHOLD) * 100, 0, 100
)

telematics['phone_risk'] = np.clip(
    (telematics['phone_use_events'] / PHONE_THRESHOLD) * 100, 0, 100
)

# Composite risk score (weighted average)
telematics['risk_score'] = (
    telematics['km_risk'] * RISK_WEIGHTS['km_risk'] +
    telematics['braking_risk'] * RISK_WEIGHTS['braking_risk'] +
    telematics['accel_risk'] * RISK_WEIGHTS['accel_risk'] +
    telematics['night_risk'] * RISK_WEIGHTS['night_risk'] +
    telematics['phone_risk'] * RISK_WEIGHTS['phone_risk']
)

# Classify into risk tiers
telematics['risk_tier'] = pd.cut(
    telematics['risk_score'],
    bins=[0, 20, 40, 60, 100],
    labels=['Very Low', 'Low', 'Moderate', 'High']
)

print("Risk Score Distribution:")
print(telematics['risk_tier'].value_counts().sort_index())
print(f"\nMean risk score: {telematics['risk_score'].mean():.1f}")
print(f"Median risk score: {telematics['risk_score'].median():.1f}")
print(f"Std dev: {telematics['risk_score'].std():.1f}")

5.3 PAYD vs. PHYD Pricing Comparison

▶ Prerequisite: continues from §5.1–§5.2 — telematics must include risk_score and risk_tier. pandas 3.x note: mapping a categorical with a dict can fail on arithmetic — write telematics['risk_tier'].astype(str).map(PHYD_RISK_MULTIPLIER).astype(float) instead of .map(...) directly.

# PAYD: flat rate per km (traditional UBI)
PAYD_RATE = 1.50  # ₹1.50 per km

# PHYD: base rate + behavioural adjustment
PHYD_BASE_RATE = 0.80        # ₹0.80 per km (lower base because behaviour-adjusted)
PHYD_RISK_MULTIPLIER = {
    'Very Low': 0.60,
    'Low': 0.85,
    'Moderate': 1.10,
    'High': 1.50
}

# Calculate monthly premium under each model
telematics['payd_premium'] = telematics['total_km'] * PAYD_RATE

telematics['phyd_rate'] = telematics['risk_tier'].map(PHYD_RISK_MULTIPLIER)
telematics['phyd_premium'] = telematics['total_km'] * PHYD_BASE_RATE * telematics['phyd_rate']

# Calculate savings vs. traditional flat premium (assume ₹2,500/month)
TRADITIONAL_FLAT = 2500
telematics['traditional_premium'] = TRADITIONAL_FLAT

telematics['payd_savings'] = TRADITIONAL_FLAT - telematics['payd_premium']
telematics['phyd_savings'] = TRADITIONAL_FLAT - telematics['phyd_premium']

# Aggregate by risk tier
comparison = telematics.groupby('risk_tier', observed=False).agg(
    driver_count=('driver_id', 'count'),
    avg_km=('total_km', 'mean'),
    avg_risk_score=('risk_score', 'mean'),
    avg_payd=('payd_premium', 'mean'),
    avg_phyd=('phyd_premium', 'mean'),
    avg_traditional=('traditional_premium', 'mean'),
    avg_payd_savings=('payd_savings', 'mean'),
    avg_phyd_savings=('phyd_savings', 'mean'),
).round(0)

print("=" * 110)
print(f"{'Risk Tier':12s} {'Drivers':>8s} {'Avg Km':>8s} {'Risk':>6s} {'PAYD ₹':>9s} {'PHYD ₹':>9s} {'Trad ₹':>9s} {'PAYD Save':>10s} {'PHYD Save':>10s}")
print("=" * 110)
for tier in ['Very Low', 'Low', 'Moderate', 'High']:
    r = comparison.loc[tier]
    print(f"{tier:12s} {r['driver_count']:>5.0f}   {r['avg_km']:>5,.0f}  {r['avg_risk_score']:>4.0f}  ₹{r['avg_payd']:>6,.0f}  ₹{r['avg_phyd']:>6,.0f}  ₹{r['avg_traditional']:>5,.0f}  {'+' if r['avg_payd_savings'] > 0 else ''}₹{r['avg_payd_savings']:>6,.0f}  {'+' if r['avg_phyd_savings'] > 0 else ''}₹{r['avg_phyd_savings']:>6,.0f}")

# Visualize
fig, (ax1, ax2) = plt.subplots(1, 2, figsize=(14, 5))

# LEFT: Premium comparison by tier
tiers = ['Very Low', 'Low', 'Moderate', 'High']
x = np.arange(len(tiers))
width = 0.25

ax1.bar(x - width, comparison.loc[tiers, 'avg_traditional'], width, label='Traditional (Flat)', color='#a29bfe', alpha=0.7)
ax1.bar(x, comparison.loc[tiers, 'avg_payd'], width, label='PAYD', color='#6c5ce7')
ax1.bar(x + width, comparison.loc[tiers, 'avg_phyd'], width, label='PHYD', color='#00d2d3')
ax1.set_xlabel('Risk Tier')
ax1.set_ylabel('Monthly Premium (₹)')
ax1.set_title('Premium Comparison by Risk Tier', fontweight='bold')
ax1.set_xticks(x)
ax1.set_xticklabels(tiers)
ax1.legend()
ax1.spines['top'].set_visible(False)
ax1.spines['right'].set_visible(False)

# RIGHT: Scatter — risk score vs. claims
if 'claim_amount' in telematics.columns:
    ax2.scatter(telematics['risk_score'], telematics['claim_amount'],
               alpha=0.4, color='#6c5ce7', s=20)
    # Add trend line
    z = np.polyfit(telematics['risk_score'], telematics['claim_amount'], 1)
    p = np.poly1d(z)
    x_line = np.linspace(telematics['risk_score'].min(), telematics['risk_score'].max(), 100)
    ax2.plot(x_line, p(x_line), 'r--', linewidth=2, label='Trend')
    corr = telematics['risk_score'].corr(telematics['claim_amount'])
    ax2.annotate(f'Correlation: {corr:.2f}', xy=(0.05, 0.95),
                transform=ax2.transAxes, fontsize=11,
                bbox=dict(boxstyle='round', facecolor='white', alpha=0.8))
    ax2.set_title('Risk Score vs. Claim Amount', fontweight='bold')
    ax2.set_xlabel('Behavioural Risk Score (0–100)')
    ax2.set_ylabel('Claim Amount (₹)')
    ax2.legend()
    ax2.spines['top'].set_visible(False)
    ax2.spines['right'].set_visible(False)

plt.tight_layout()
plt.show()

5.4 Interpreting the Results

The analysis reveals the core UBI insight: PAYD primarily rewards low-mileage drivers regardless of their driving quality, while PHYD rewards safe driving behaviour regardless of mileage.

• A driver who drives 500 km/month very aggressively (hard braking, phone use, night driving) gets a low premium from PAYD (₹750, saving ₹1,750 vs. traditional) — even though they are high-risk. This is an adverse selection risk for the insurer.
• A driver who drives 3,000 km/month very safely gets a high premium from PAYD (₹4,500, paying ₹2,000 more than traditional) — even though they are low-risk. This is a customer retention risk.
• PHYD solves both problems. The aggressive low-mileage driver's premium is adjusted upward by their behavioural multiplier (₹750 × 1.50 = ₹1,125). The safe high-mileage driver's premium is adjusted downward (₹4,500 × 0.60 = ₹2,700). Both are treated more fairly than under either traditional or PAYD pricing.

This is why PHYD is a better risk selection mechanism than PAYD — but it requires more data, more customer trust, and more regulatory acceptance to deploy at scale.

# ============================================================================
# Session 10 — Usage-Based Insurance: UBI Data Analysis (COMPLETE RUNNABLE SCRIPT)
# InsurTech & Digital Risk Solutions (MBA) — Woxsen University
#
# HOW TO RUN:
#   venv/bin/python session_10_ubi_analysis.py
#   (or run top-to-bottom in one Jupyter notebook — the page's §5.1–§5.4 blocks
#    are merged here in order so nothing is left undefined)
#
# DATA FILE: data/telematics_data.csv (provided) — 500 drivers, one month of
#            synthetic driving behaviour. Falls back to telematics_data.csv
#            in the current folder.
#
# OUTPUTS:   console tables + ubi_premium_comparison.png + ubi_risk_scatter.png
# ============================================================================
import pandas as pd
import numpy as np
import matplotlib.pyplot as plt

# ----------------------------------------------------------------------------
# SECTION 5.1 — Loading the Telematics Data
# ----------------------------------------------------------------------------
try:
    telematics = pd.read_csv('data/telematics_data.csv')
except FileNotFoundError:
    telematics = pd.read_csv('telematics_data.csv')

print(f"Drivers: {telematics.shape[0]:,}")
print(f"Columns: {telematics.columns.tolist()}")
print(f"\nData types:\n{telematics.dtypes}")
print(f"\nSummary statistics:\n{telematics.describe().round(1)}")

# Key columns:
# driver_id — Unique driver identifier
# total_km — Kilometres driven in the month
# avg_speed_kmph — Average speed
# hard_braking_events — Count of hard braking events
# hard_accel_events — Count of rapid acceleration events
# night_driving_pct — Percentage of driving at night (10pm-5am)
# phone_use_events — Count of phone usage events while driving
# previous_claims — Number of claims in the last 3 years
# claim_amount_last_3y — Total claim amount in the last 3 years

# ----------------------------------------------------------------------------
# SECTION 5.2 — Building a Behavioural Risk Score
# ----------------------------------------------------------------------------
RISK_WEIGHTS = {
    'km_risk': 0.20,              # Higher mileage = more exposure
    'braking_risk': 0.25,         # Hard braking = unsafe driving pattern
    'accel_risk': 0.15,           # Hard acceleration = aggressive driving
    'night_risk': 0.20,           # Night driving = higher accident risk
    'phone_risk': 0.20            # Phone use = distraction risk
}

KM_THRESHOLD_HIGH = 2000       # km/month — above this is high mileage
BRAKING_THRESHOLD = 15         # events/month — above this is aggressive
ACCEL_THRESHOLD = 10           # events/month
NIGHT_THRESHOLD = 25           # % of driving at night
PHONE_THRESHOLD = 5            # events/month

telematics['km_risk'] = np.clip((telematics['total_km'] / KM_THRESHOLD_HIGH) * 100, 0, 100)
telematics['braking_risk'] = np.clip((telematics['hard_braking_events'] / BRAKING_THRESHOLD) * 100, 0, 100)
telematics['accel_risk'] = np.clip((telematics['hard_accel_events'] / ACCEL_THRESHOLD) * 100, 0, 100)
telematics['night_risk'] = np.clip((telematics['night_driving_pct'] / NIGHT_THRESHOLD) * 100, 0, 100)
telematics['phone_risk'] = np.clip((telematics['phone_use_events'] / PHONE_THRESHOLD) * 100, 0, 100)

telematics['risk_score'] = (
    telematics['km_risk'] * RISK_WEIGHTS['km_risk'] +
    telematics['braking_risk'] * RISK_WEIGHTS['braking_risk'] +
    telematics['accel_risk'] * RISK_WEIGHTS['accel_risk'] +
    telematics['night_risk'] * RISK_WEIGHTS['night_risk'] +
    telematics['phone_risk'] * RISK_WEIGHTS['phone_risk']
)

telematics['risk_tier'] = pd.cut(
    telematics['risk_score'],
    bins=[0, 20, 40, 60, 100],
    labels=['Very Low', 'Low', 'Moderate', 'High'],
    include_lowest=True
)

print("Risk Score Distribution:")
print(telematics['risk_tier'].value_counts().sort_index())
print(f"\nMean risk score: {telematics['risk_score'].mean():.1f}")
print(f"Median risk score: {telematics['risk_score'].median():.1f}")
print(f"Std dev: {telematics['risk_score'].std():.1f}")

# ----------------------------------------------------------------------------
# SECTION 5.3 — PAYD vs. PHYD Pricing Comparison
# ----------------------------------------------------------------------------
PAYD_RATE = 1.50  # ₹1.50 per km
PHYD_BASE_RATE = 0.80        # ₹0.80 per km (lower base because behaviour-adjusted)
PHYD_RISK_MULTIPLIER = {
    'Very Low': 0.60,
    'Low': 0.85,
    'Moderate': 1.10,
    'High': 1.50
}

telematics['payd_premium'] = telematics['total_km'] * PAYD_RATE
# pandas 3.x: map a categorical with a dict can return a non-arithmetic dtype,
# so cast to str first, then to float.
telematics['phyd_rate'] = telematics['risk_tier'].astype(str).map(PHYD_RISK_MULTIPLIER).astype(float)
telematics['phyd_premium'] = telematics['total_km'] * PHYD_BASE_RATE * telematics['phyd_rate']

TRADITIONAL_FLAT = 2500
telematics['traditional_premium'] = TRADITIONAL_FLAT
telematics['payd_savings'] = TRADITIONAL_FLAT - telematics['payd_premium']
telematics['phyd_savings'] = TRADITIONAL_FLAT - telematics['phyd_premium']

comparison = telematics.groupby('risk_tier', observed=False).agg(
    driver_count=('driver_id', 'count'),
    avg_km=('total_km', 'mean'),
    avg_risk_score=('risk_score', 'mean'),
    avg_payd=('payd_premium', 'mean'),
    avg_phyd=('phyd_premium', 'mean'),
    avg_traditional=('traditional_premium', 'mean'),
    avg_payd_savings=('payd_savings', 'mean'),
    avg_phyd_savings=('phyd_savings', 'mean'),
).round(0)

print("=" * 110)
print(f"{'Risk Tier':12s} {'Drivers':>8s} {'Avg Km':>8s} {'Risk':>6s} {'PAYD ₹':>9s} {'PHYD ₹':>9s} {'Trad ₹':>9s} {'PAYD Save':>10s} {'PHYD Save':>10s}")
print("=" * 110)
for tier in ['Very Low', 'Low', 'Moderate', 'High']:
    r = comparison.loc[tier]
    print(f"{tier:12s} {r['driver_count']:>5.0f}   {r['avg_km']:>5,.0f}  {r['avg_risk_score']:>4.0f}  ₹{r['avg_payd']:>6,.0f}  ₹{r['avg_phyd']:>6,.0f}  ₹{r['avg_traditional']:>5,.0f}  {'+' if r['avg_payd_savings'] > 0 else ''}₹{r['avg_payd_savings']:>6,.0f}  {'+' if r['avg_phyd_savings'] > 0 else ''}₹{r['avg_phyd_savings']:>6,.0f}")

# Visualize
fig, (ax1, ax2) = plt.subplots(1, 2, figsize=(14, 5))

tiers = ['Very Low', 'Low', 'Moderate', 'High']
x = np.arange(len(tiers))
width = 0.25

ax1.bar(x - width, comparison.loc[tiers, 'avg_traditional'], width, label='Traditional (Flat)', color='#a29bfe', alpha=0.7)
ax1.bar(x, comparison.loc[tiers, 'avg_payd'], width, label='PAYD', color='#6c5ce7')
ax1.bar(x + width, comparison.loc[tiers, 'avg_phyd'], width, label='PHYD', color='#00d2d3')
ax1.set_xlabel('Risk Tier')
ax1.set_ylabel('Monthly Premium (₹)')
ax1.set_title('Premium Comparison by Risk Tier', fontweight='bold')
ax1.set_xticks(x)
ax1.set_xticklabels(tiers)
ax1.legend()
ax1.spines['top'].set_visible(False)
ax1.spines['right'].set_visible(False)

if 'claim_amount' in telematics.columns:
    ax2.scatter(telematics['risk_score'], telematics['claim_amount'],
               alpha=0.4, color='#6c5ce7', s=20)
    z = np.polyfit(telematics['risk_score'], telematics['claim_amount'], 1)
    p = np.poly1d(z)
    x_line = np.linspace(telematics['risk_score'].min(), telematics['risk_score'].max(), 100)
    ax2.plot(x_line, p(x_line), 'r--', linewidth=2, label='Trend')
    corr = telematics['risk_score'].corr(telematics['claim_amount'])
    ax2.annotate(f'Correlation: {corr:.2f}', xy=(0.05, 0.95),
                transform=ax2.transAxes, fontsize=11,
                bbox=dict(boxstyle='round', facecolor='white', alpha=0.8))
    ax2.set_title('Risk Score vs. Claim Amount', fontweight='bold')
    ax2.set_xlabel('Behavioural Risk Score (0–100)')
    ax2.set_ylabel('Claim Amount (₹)')
    ax2.legend()
    ax2.spines['top'].set_visible(False)
    ax2.spines['right'].set_visible(False)

plt.tight_layout()
plt.savefig('ubi_premium_comparison.png', dpi=120)   # artifact for submission
plt.show()

# ----------------------------------------------------------------------------
# SECTION 5.4 — Interpreting the Results (worked examples from the page)
# ----------------------------------------------------------------------------
print("\n" + "=" * 70)
print("SECTION 5.4 — Interpretation examples")
print("=" * 70)

aggressive_low_km = 500     # km/month, aggressive driving (High tier)
payd = aggressive_low_km * PAYD_RATE
phyd = aggressive_low_km * PHYD_BASE_RATE * 1.50
print(f"Aggressive low-mileage driver (500 km, High tier):")
print(f"  PAYD = ₹{payd:.0f}  |  PHYD = ₹{phyd:.0f}  |  Traditional = ₹{TRADITIONAL_FLAT}")
print(f"  -> PAYD underprices the risk; PHYD adjusts it up by the behavioural multiplier.")

safe_high_km = 3000        # km/month, safe driving (Very Low tier)
payd = safe_high_km * PAYD_RATE
phyd = safe_high_km * PHYD_BASE_RATE * 0.60
print(f"\nSafe high-mileage driver (3000 km, Very Low tier):")
print(f"  PAYD = ₹{payd:.0f}  |  PHYD = ₹{phyd:.0f}  |  Traditional = ₹{TRADITIONAL_FLAT}")
print(f"  -> PAYD overcharges the safe driver; PHYD rewards them with a discount.")

print("\nCharts saved: ubi_premium_comparison.png")

7. Privacy, Ethics & UBI

Usage-Based Insurance sits at the intersection of two powerful trends — data-driven personalisation and consumer privacy — that are increasingly in tension. As UBI expands, the privacy and ethics questions it raises become not peripheral concerns but central strategic issues that will determine how quickly and how broadly UBI can be adopted.

7.1 The Data Collection Question

A PHYD programme may collect: GPS location every few seconds, speed, acceleration on three axes, braking force, cornering G-force, time of day, phone usage events, and — if the smartphone app is used — background location data even when not driving (to distinguish driving from other travel modes). For a customer, the question is: what does the insurer know about me, when, and for how long do they keep it? For the insurer, the question is: can we build a commercially viable UBI programme without collecting data that customers and regulators find intrusive?

The tension is real. Studies consistently show that 40–60% of consumers say they are "very concerned" about sharing driving data with their insurer — but 60–80% say they would share data for a meaningful premium discount. The "privacy premium" — how much discount a customer demands in exchange for sharing data — varies by demographics, product type, and cultural context. Indian customers have generally shown less privacy sensitivity than European customers (where GDPR imposes strict limits), but sensitivity is rising with awareness.

7.2 The Fairness Question

Usage-based pricing raises three fairness questions that regulators and insurers are actively debating:

• Segregation of risk pools: If the lowest-risk drivers all migrate to UBI programmes (where they get lower premiums), the traditional pool retains a higher proportion of higher-risk drivers. Their premiums must rise. Is society comfortable with a two-tier insurance system where data-rich customers pay less and data-poor customers pay more — even if the data-poor customers are not poor by choice but by privacy preference? This is the "privacy tax" problem.
• Behavioural discrimination by price: If an insurer charges a 50% higher per-km rate for night driving, it is effectively saying: "if you cannot avoid driving at night (because you work night shifts, have a family emergency, or live in an area with poor public transport), you will pay more." Is this fair? The customer may not have a choice about when they drive. Pricing based on behaviour that customers cannot easily change functions more like a penalty than a risk-reflective price.
• Data ownership and portability: Driving data belongs to the customer, but only the insurer that collected it can use it to price the risk. If a customer wants to switch insurers, their accumulated safe-driving data stays with the old insurer. The new insurer starts from scratch — either requiring a new tracking period or reverting to traditional pricing. Data portability — the ability for customers to take their driving data to any insurer — would create a more competitive UBI market but raises significant technical, privacy, and competitive challenges.

7.3 The DPDP Act and UBI

India's Digital Personal Data Protection Act (DPDP Act, 2023) has direct implications for UBI programmes. Key requirements: explicit consent for data collection (separate from the insurance contract), purpose limitation (UBI data cannot be used for other purposes without fresh consent), data minimisation (collect only what is necessary), and the right to withdraw consent (the customer can stop sharing data at any time — which would require the insurer to revert to a non-UBI pricing mechanism).

For UBI providers in India, the DPDP Act means: (a) the consent form for telematics data must be written in clear, simple language — not buried in the policy terms, (b) data collection should be limited to what is actually used for pricing — collecting GPS location continuously when the purpose is mileage calculation may violate the data minimisation principle, and (c) the option to opt out of data sharing must be as easy as opting in. UBI programmes designed with the DPDP Act in mind from the start will have a significant regulatory advantage over those that treat privacy compliance as an afterthought.