Cross-Vertical Patterns

The four verticals in this chapter — telco, retail, financial services, and energy — look different on the surface. CDRs (Call Detail Records), shopping carts, wire transfers, kilowatt-hours. But they share structural patterns that transfer directly. Recognizing these patterns saves engagement time: instead of designing from scratch for each client, adapt a proven pattern to the vertical's data shape and regulatory constraints.

The recurring data types

Five data types appear across every vertical. Each has the same anonymization characteristics regardless of industry:

Data type	Appears in	Re-identification risk	Standard treatment
Location data	Telco (cell ID), retail (store/IP), finance (ATM/branch), energy (meter/charger)	Very high — a small number of spatio-temporal points can uniquely identify most individuals (4 points → 95% in one cellphone mobility study; transferability varies by dataset resolution and population density)	Generalization to area/cluster + temporal bucketing; DP for aggregates
Transaction sequences	Telco (CDR sequences), retail (purchase history), finance (transaction history), energy (consumption profiles)	High — behavioral fingerprints from sequences of 3–4 events	Sequence-level aggregation or DP; per-event generalization is insufficient
Device identifiers	Telco (IMEI, IMSI), retail (cookie, device fingerprint), finance (device binding), energy (meter ID, EV ID)	Medium to high — persistent cross-session linkage	HMAC or FPE per domain; suppress when cross-session linking isn't needed
Temporal patterns	All — timestamps on every event type	Medium — temporal regularity (commute times, purchase habits, consumption patterns) enables re-identification	Bucketing (15-min → hourly → daily); precision depends on use case
Account/subscriber profiles	All — the slowly changing dimension linking events to individuals	High — direct identifiers + quasi-identifiers	Direct ID pseudonymization; QI generalization; access-controlled zones

The four-zone model adaptation

The four-zone architecture from Module 06 (Raw → Pseudonymized → Structurally Anonymized → DP-Guaranteed) applies to every vertical. What changes is:

Dimension	Telco	Retail	Financial services	Energy
Zone 0 retention	Days for traffic/location data (ePrivacy); longer for billing-related fields under legal obligation	Days to weeks (varies by purpose and national rules)	Years (AML/MiFID retention mandates)	Days for operational metering (varies by purpose and national regulation)
Zone 1 anchor identifier	MSISDN	Resolved canonical customer ID	Account number	Meter ID / customer ID
Zone 1 primary technique	HMAC for MSISDN; FPE if format needed	Deterministic encryption (cross-domain joins)	Tokenization (PCI for payment data); HMAC for accounts	HMAC for meter ID
Zone 2 structural approach	k-anonymity on CDR attributes (k ≥ 50 for meaningful protection)	k-anonymity on customer profiles; sequence aggregation	k-anonymity on transaction summaries	Temporal aggregation + location generalization
Zone 3 primary use	Mobility analytics, network planning, data monetization	Marketing analytics, partner data sharing, benchmarking	Risk modeling, market research, regulatory aggregate reporting	Grid planning, demand forecasting, carbon accounting
Hardest anonymization problem	Mobility sequence uniqueness	Cross-domain identity + purchase sequence uniqueness	AML retention preventing anonymization of operational data	NILM inference from temporal consumption patterns

Transferable architecture decisions

Three architecture decisions made early in any engagement have the same shape across verticals:

1. Pipeline-integrated vs. query-time. Does anonymization happen during data ingestion (pipeline-integrated, using SDP de-identification templates in Dataflow) or at query time (BigQuery DDM with policy tags)? The answer depends on who accesses Zone 1 data: if most consumers need pseudonymized data, pipeline-integrated anonymization avoids per-query overhead. If different teams need different masking levels on the same dataset, query-time DDM provides flexibility. Most production architectures use both — pipeline-integrated for the raw→pseudonymized transition, DDM for within-zone access control. This pattern is the same in every vertical.

2. Key architecture. HMAC (irreversible), FPE (format-preserving, reversible), deterministic encryption (joinable, reversible), or vaulted tokenization (random, reversible via vault)? The decision depends on whether re-identification is needed (right-to-erasure design — Module 07), whether format compatibility is required (legacy systems), and whether cross-system joins are needed. The decision tree from Module 07 applies directly in every vertical — swap MSISDN for customer ID or account number or meter ID, and the logic is identical.

3. DP budget allocation. How much privacy budget (ε) to allocate across analytical queries on Zone 3 data? This is a governance decision, not a technical one — it determines how many aggregate queries can be run before the cumulative privacy budget for that dataset version is consumed (the data still exists, but further DP-guaranteed releases must stop or use a newly justified accounting boundary). The approach from Module 04 (sequential composition, parallel composition, Renyi DP for tighter accounting) is the same in every vertical. What changes is the budget split: telco clients typically allocate most budget to mobility analytics; retail clients to conversion and basket analytics; financial services to risk reporting; energy to demand forecasting.

---

Next: Module 12 examines what happens when anonymization fails — real-world re-identification attacks, implementation mistakes that create vulnerabilities, and the testing and validation methodology that catches these problems before a regulator or adversary does.

---

Created by Claude Opus with ❤️ for the Aliz Data Engineering team.