Telco
Telco is where anonymization problems are the sharpest. The data is high-volume (billions of CDRs (Call Detail Records) per day for a national operator), high-dimensionality (each record carries direct identifiers, quasi-identifiers, and behavioral signals), and structurally resistant to anonymization (mobility patterns are uniquely identifying even after identifiers are removed). Add the ePrivacy Directive's strict requirements on top of GDPR, and you get an industry where "we hashed the phone numbers" is both the most common approach and the most dangerous one.
The data landscape
A typical telco data platform holds several categories of subscriber-related data, each with distinct sensitivity profiles:
| Data category | Examples | Volume | Privacy sensitivity |
|---|---|---|---|
| Call Detail Records (CDRs) | Calling/called party, timestamp, duration, cell tower, call type | Billions/day (national operator) | Very high — behavioral fingerprint |
| Network events | Cell handovers, data sessions, signaling events | 10–100× CDR volume | High — fine-grained location trail |
| Location data | Cell ID, sector, timing advance, GPS (LTE/5G) | Continuous | Critical — movement patterns |
| Subscriber profiles | Name, MSISDN (phone number), IMSI (SIM identifier), address, tariff plan, device type | Millions of records, slowly changing | High — direct identifiers |
| Billing and usage | Invoice amounts, payment history, top-up patterns | Monthly cycle | Medium — financial behavior |
| Customer interactions | Call center notes, complaints, chat logs | Unstructured, variable | High — may contain any PII in free text |
The engineering challenge is that these categories don't exist in isolation. CDRs reference subscriber profiles via MSISDN. Network events link to CDRs via timestamp correlation. Billing records tie to subscriber profiles via account ID. Any anonymization strategy that treats one category in isolation will fail when the categories are joined — and they will be joined, because cross-domain analytics is the entire point of a modern telco data platform.
High-sensitivity identifiers
Telco data carries a layered set of identifiers, each requiring a different treatment based on its domain size, linkability, and downstream use:
| Identifier | What it is | Domain size | Treatment | Rationale |
|---|---|---|---|---|
| MSISDN | Phone number (E.164) | ~10 billion globally; ~10⁷–10⁸ per country | FPE or HMAC-keyed hash | Direct identifier; finite domain makes plain hashing trivially reversible (Module 03) |
| IMSI | SIM subscription ID | ~10¹⁵ (MCC+MNC+MSIN) | Deterministic encryption or HMAC | Correlates to MSISDN; used for roaming joins |
| IMEI | Device serial number | ~10¹⁵ (TAC+serial+check) | HMAC or suppression | Device-level; typically no re-identification need |
| Cell ID | Base station sector | Thousands per operator | Generalization to cluster | Location quasi-identifier; precision directly impacts re-identification risk |
| IP address | Subscriber session IP | Dynamic, NAT-shared | FPE (IPv4) or truncation to /24 | May be direct or indirect depending on NAT context |
The critical insight: MSISDN is a finite-domain identifier. A national numbering plan contains at most a few hundred million valid numbers. An attacker with a plain SHA-256 hash of an MSISDN can precompute the hash of every valid number in the numbering plan in minutes on commodity hardware. This is why Module 03 emphasized HMAC with a secret key — without the key, the precomputation attack fails. This is also the single most common vulnerability in legacy telco anonymization systems.
The first thing to check in any telco anonymization assessment: how are MSISDNs transformed? If the answer is "SHA-256" or "MD5" without a key, that's a P0 finding — the pseudonymization is reversible by anyone with access to the national numbering plan.
The re-identification problem: mobility uniqueness
Even with perfect identifier treatment — every MSISDN replaced by an HMAC pseudonym, every IMSI encrypted — CDR data remains dangerously identifiable. The reason is structural: mobility patterns are almost as unique as fingerprints.
The landmark result comes from de Montjoye et al. (2013): as few as 4 spatio-temporal data points uniquely identify 95% of individuals in a mobility dataset of 1.5 million people. Later works have shown this holds even with spatial and temporal coarsening — reducing location granularity to cell-tower clusters and time to hourly buckets brings the number up, but not enough to provide anonymity in any meaningful sense for dense urban areas.
What makes this so difficult for CDR anonymization:
- Each CDR is a spatio-temporal point. A single day's CDRs give a subscriber 10–50 location-time pairs — far more than the 4 needed for uniqueness.
- Behavioral regularity amplifies the risk. People commute the same routes, visit the same cell towers at the same times. This regularity makes mobility patterns stable over time, so even partial overlap with auxiliary data (a social media check-in, a known workplace) is enough to anchor identity.
- Generalization has diminishing returns. Coarsening cell IDs to large geographic clusters destroys the spatial resolution needed for network planning and site analytics — the primary analytical use cases for CDR data. The privacy-utility trade-off hits a wall: sufficient generalization for anonymity makes the data useless for its intended purpose.
This is the fundamental tension in telco anonymization: identifier substitution is necessary but not sufficient, and structural privacy techniques have a narrow operating range before destroying utility.
The practical resolution — used in the telco reference architecture — is to accept that CDR-level data cannot be truly anonymized for most use cases. Instead, use layered pseudonymization (identifiers) + structural controls (generalization, bucketing) in the pseudonymized zone for internal analytics under an applicable ePrivacy basis (billing necessity, consented value-added services, or legal obligation — see The ePrivacy layer below), and reserve true anonymization (differential privacy, k-anonymity with high k, or synthetic data) for the aggregated analytics zone used for external sharing.
Quantifying the re-identification gap
To understand how far generalization gets you, consider a simplified model. A CDR record has three quasi-identifier dimensions: location (cell tower), time (hour), and call pattern (number of calls). With 5,000 cell towers, 24 hourly buckets, and 10 call-count buckets, the quasi-identifier space has 5,000 × 24 × 10 = 1.2 million distinct combinations. For a national operator with 10 million subscribers, the average equivalence class size is ~8 records per combination — marginal for k-anonymity. Now consider that a single subscriber generates multiple CDRs per day: a sequence of 3 CDRs has an effective space of 1.2M³ ≈ 1.7 × 10¹⁸ combinations, making each subscriber's daily pattern almost certainly unique even after generalization.
This is why the research literature converges on differential privacy or synthetic data for publishable telco mobility analytics — k-anonymity over raw CDR sequences requires such aggressive generalization (k ≥ 50, location generalized to large regions, time bucketed to multi-hour windows) that the result has too little resolution for most analytical purposes.
The tools for measuring this: ARX computes prosecutor risk, journalist risk, and marketer risk metrics on any tabular dataset. Run these on the pseudonymized output before committing to a generalization strategy — the numbers often surprise.
Dictionary-based legacy and the modernization path
Some telco clients that come to Aliz for anonymization modernization are running some variant of a dictionary-based pseudonymization system: a lookup table that maps real MSISDNs to pseudonyms, maintained alongside the CDR pipeline. This was the standard approach for two decades, and it has four systemic weaknesses:
-
Single point of compromise. The dictionary table is a complete re-identification key for the entire CDR dataset. Compromise of that one table — through access control failure, backup exposure, or insider threat — deanonymizes everything.
-
No structural privacy. The dictionary substitutes identifiers but leaves behavioral patterns intact. Linkage attacks succeed without ever needing to reverse the pseudonym — the call patterns themselves are the fingerprint.
-
Scale brittleness. Dictionary tables for a national operator hold hundreds of millions of entries. At CDR ingestion rates (tens of thousands of records per second), the lookup becomes a throughput bottleneck — especially when the dictionary is on legacy RDBMS infrastructure.
-
No formal privacy model. Dictionary substitution offers no mathematical guarantee. You cannot quantify the re-identification risk, which means you cannot demonstrate compliance to a regulator — you can only assert that "we replaced the identifiers."
The modernization direction separates identifier treatment from structural privacy:
Legacy: Dictionary lookup (identifiers only)
↓
Modern: Layer 1 — Identifier pseudonymization
HMAC/FPE for MSISDNs, det. encryption for IMSI
(Module 03 techniques, Module 07 key management)
+
Layer 2 — Structural privacy for quasi-identifiers
Cell-ID generalization, temporal bucketing
k-anonymity or DP for analytical outputs
(Module 04 privacy models)
+
Layer 3 — Access control
Policy tags, DDM, zone boundaries
(Module 06 architecture)
Layer 1 replaces the dictionary with cryptographic transforms — HMAC-keyed hashing for irreversible pseudonymization, FPE for format-compatible reversible pseudonymization, deterministic encryption for joinable reversible pseudonymization. The choice depends on whether re-identification is needed (Module 07's transform decision tree).
Layer 2 addresses what the dictionary never did: the quasi-identifier structure. Cell-ID generalization, temporal bucketing, and formal privacy models (k-anonymity for tabular outputs, differential privacy for aggregate statistics) reduce the structural re-identification risk.
Layer 3 ensures that different consumer groups see different views — raw access for pipeline debugging, pseudonymized access for analytics, aggregated DP outputs for external sharing — through the four-zone architecture.
The ePrivacy layer
Telco is the only vertical where a dedicated EU directive — the ePrivacy Directive (2002/58/EC) — layers additional restrictions on top of GDPR. As noted in Module 01, the ePrivacy Directive specifically governs traffic data and location data:
- Traffic data (CDRs, signaling records) must be erased or anonymized when no longer needed for transmission. Retention is permitted only for billing (limited period), subscriber consent for value-added services, or legal obligations.
- Location data other than traffic data requires explicit, informed consent before processing for value-added services. There is no "legitimate interest" fallback — consent or anonymization, period.
- Communication content (SMS text, voice content if captured) has the highest protection — interception requires specific legal basis (typically law enforcement).
The practical impact for pipeline design:
| ePrivacy requirement | Pipeline implication |
|---|---|
| Traffic data erasure after transmission | Raw zone retention policy: days, not weeks. Enforce with automated lifecycle management (GCS lifecycle rules, BigQuery table expiration). |
| Location data consent requirement | Pipeline must filter on consent status before location-bearing records enter the pseudonymized zone for value-added services. |
| Anonymized data exits ePrivacy scope | The aggregated/DP zone (Zone 3) is the boundary — data that meets the anonymization standard can be used freely for analytics and sharing. |
| Billing retention exception | Billing-related CDR fields can be retained in identifiable form for the billing period — but only the billing-relevant fields, not the full CDR. |
The ePrivacy Directive was supposed to be replaced by the ePrivacy Regulation (which would have had direct effect across EU member states, like GDPR). The European Commission withdrew the stalled proposal in February 2025 after years of failed negotiations. Cookie and electronic communications privacy rules are being folded into GDPR instead, via the Digital Omnibus proposal (new Articles 88a, 88b) — earliest adoption end-2026, enforcement ~2027. Until then, the 2002 Directive remains in force, implemented through varying national transpositions — which means the specifics differ by country. For multi-country telco engagements, always check the national transposition for each market.
Data sharing and monetization
Anonymized telco data has significant commercial value — location analytics for urban planning, mobility insights for transport operators, aggregate demographics for advertising. But each sharing model carries a different threat profile:
| Sharing model | Risk level | Recommended approach | Zone source |
|---|---|---|---|
| Internal analytics (same org, authorized teams) | Low | Pseudonymized data + DDM + RBAC | Zone 1 |
| Non-production / dev environments | Medium | FPE-pseudonymized subset or synthetic data | Zone 1 (subset) or synthetic |
| Third-party partners (roaming, MVNOs) | High | Aggregated DP outputs or structural anonymization with high k | Zone 3 (or Zone 2 with contractual controls) |
| Open data / academic research | Very high | DP + k-anonymity + suppression; or synthetic data | Zone 3 |
| AI/ML model training | High | Synthetic CDR data with DP guarantees; or pseudonymized with access controls | Synthetic or Zone 1 |
The critical distinction: not all telco data faces the same legal constraints. Traffic data and location data are each covered by the ePrivacy Directive, but with different permitted bases. Traffic data (Art. 6) must be erased or anonymized after transmission, but retention is also permitted for billing, interconnection charges, consented value-added services, and legal obligations — these are narrower than GDPR's six lawful bases but broader than "consent or anonymization" alone. Non-traffic location data (Art. 9) is stricter: processing for value-added services requires explicit consent, with no legitimate-interest fallback (Module 01). In neither case does GDPR legitimate interest independently override the ePrivacy restrictions. For subscriber profile analytics, billing-derived aggregates, and other non-traffic/non-location data, GDPR Article 6(1)(f) legitimate interest can provide the legal basis for internal analytics on pseudonymized data with access controls — subject to a documented Legitimate Interest Assessment (Module 09). External sharing almost always requires true anonymization or DP guarantees regardless of data category — the risk that a recipient could combine the shared data with their own datasets to re-identify subscribers is too high for pseudonymized data.
For data monetization specifically, synthetic CDR generation is increasingly viable. Tools like Synthetic Data Vault (SDV) and Gretel can produce synthetic CDR datasets that preserve statistical properties (call volume distributions, temporal patterns, geographic coverage) without containing any real subscriber data. Synthetic data can exit GDPR and ePrivacy scope — but only if the generation process does not memorize training records. If the model overfits and reproduces near-real records, the output may still constitute personal data. Membership inference testing (Module 02) is essential before treating synthetic output as non-personal. The trade-off is fidelity: synthetic data captures aggregate patterns but loses individual-level correlations that might be valuable for certain analyses.
Next: Retail and e-commerce — multi-domain identity resolution, purchase history re-identification, cookie landscape, PCI-DSS tokenization, and consent complexity.
Created by Claude Opus with ❤️ for the Aliz Data Engineering team.