Compliance & Privacy · 2026-04-12

Data Residency for Identity Signals: Navigating Schrems III and Cross-Border Carrier Lookups

By J. W. Bouckaert

The transfer problem identity verification created

Every identity verification system that queries a carrier API performs a cross-border data transfer. That is the default architecture.

When a fintech in Berlin verifies a user's SIM status through a carrier API endpoint hosted in the United States, the user's MSISDN (phone number) traverses at least one jurisdictional boundary. Under GDPR Chapter V, that transfer requires a legal basis: an adequacy decision, Standard Contractual Clauses (SCCs), Binding Corporate Rules (BCRs), or one of the narrow derogations under Article 49.

Your identity verification system transfers personal data. The useful question is whether you have a lawful basis for every transfer it makes—and whether that basis will survive the next CJEU ruling.

This has been the compliance surface since Schrems I invalidated Safe Harbor in 2015. But for most identity verification providers, the problem was academic. Carrier lookups were fast, bilateral, and invisible to regulators. That invisibility is ending.

The Schrems timeline: From Safe Harbor to the DPF

To understand where Schrems III lands, you need the trajectory:

Schrems I (2015)

The CJEU invalidated the EU-US Safe Harbor framework in Schrems v. Data Protection Commissioner (C-362/14). The Court found that US surveillance programs—specifically PRISM](<https://en.wikipedia.org/wiki/PRISM_(surveillance_program)>) and upstream collection under [FISA Section 702—constituted mass, indiscriminate surveillance incompatible with EU fundamental rights under Articles 7 and 8 of the EU Charter.

Schrems II (2020)

The CJEU invalidated the EU-US Privacy Shield in Data Protection Commissioner v. Facebook Ireland and Maximillian Schrems (C-311/18). The Court additionally held that SCCs are valid in principle but require a case-by-case Transfer Impact Assessment (TIA) to verify that the destination country's laws provide "essentially equivalent" protections. If they do not, supplementary technical measures are required.

The Data Privacy Framework (2023)

In July 2023, the European Commission adopted an adequacy decision for the EU-US Data Privacy Framework (DPF), based on Executive Order 14086 and the establishment of the Data Protection Review Court (DPRC). The DPF introduced proportionality requirements for US signals intelligence activities and a redress mechanism for EU data subjects.

The Schrems III challenge

NOYB (None of Your Business), the privacy advocacy organization led by Max Schrems, filed a challenge to the DPF almost immediately after its adoption. The central arguments:

• Executive Order 14086 is an executive action, not legislation—it can be revoked or modified by any subsequent administration without Congressional approval
• The DPRC is not a "court" in the EU sense: its judges are appointed by the Attorney General, proceedings are not adversarial, and complainants cannot see the evidence against them
• FISA Section 702 was reauthorized in April 2024 with expanded scope, undermining the proportionality claims of EO 14086
• The "proportionality" standard adopted by EO 14086 uses US constitutional definitions rather than EU Charter definitions—and the two are not equivalent

The case is expected to reach the CJEU by late 2026 or early 2027.

Carrier lookups as transfers

Identity verification providers have a specific vulnerability that most data processors do not: every API call is a transfer.

Consider the data flow of a standard SIM-swap detection query:

The critical exposure is Step 2. Most carrier aggregation APIs—Twilio, Vonage, Telesign—route queries through US-based infrastructure, even when the queried number belongs to an EU subscriber served by an EU MNO. The MSISDN is personal data. The transfer is cross-border. The legal basis must exist.

Aggregators

Carrier signal aggregators compound the issue:

Even when an aggregator has EU infrastructure, the query routing is not guaranteed to remain within the EU. Load balancing, failover, and inter-datacenter replication can cause a query to traverse US infrastructure without the data controller's knowledge.

The hashed-signal architecture

PasskeyBridge's approach eliminates the transfer problem by eliminating the personal data from the transfer.

Mechanism

1. Edge hashing: The user's MSISDN is hashed with HMAC-SHA-256 using a tenant-specific secret key at the nearest edge location (Cloudflare Worker PoP). The plaintext number never leaves the edge.

1. Hash-only transit: The resulting hash—a 64-character hex string—is transmitted to the carrier correlation endpoint. This hash is not personal data under GDPR Recital 26 because it cannot be reversed without the tenant's secret key, which is stored in a separate jurisdiction-locked HSM.

1. Carrier-side matching: The carrier (or carrier aggregator) performs the same HMAC operation on their subscriber records using a shared secret established during onboarding. The correlation is a hash-to-hash match—no plaintext MSISDN is exchanged.

1. Signal return: The carrier returns a signal attestation (SIM swap detected, port-out detected, number recycled, etc.) bound to the hash alone. The attestation is cryptographically signed and timestamped.

Consequences for data residency

The architecture transforms a Chapter V transfer problem into a non-transfer. There is no personal data in transit, so there is no transfer to justify.

The supplementary measures framework

Even for organizations that cannot adopt a hashed-signal architecture immediately, the EDPB Recommendations 01/2020 on supplementary measures provide a roadmap:

Technical measures (most relevant for identity signals)

Organizational measures

• Transparency reports: Publish the number of government data access requests received, broken down by jurisdiction
• Warrant canary: Maintain a public attestation that no classified data access requests have been received
• Data Protection Impact Assessment (DPIA): Required under Article 35 for cross-border processing of identity data at scale

Data residency by jurisdiction: A compliance map

The following table summarizes the data residency posture required for carrier-signal-based identity verification across major jurisdictions:

The zero-PII advantage

Schrems III compliance was never the reason for PasskeyBridge's zero-PII architecture. The design rests on a simpler judgment: storing personal data is a liability that identity systems should not accept. But the architectural decision has a regulatory consequence: if you never transfer personal data, you never trigger Chapter V.

That is a design philosophy, and it happens to align with the direction of global privacy regulation. Every major privacy framework—GDPR, PIPL, DPDPA, LGPD—provides some form of exemption or reduced obligation for anonymized or irreversibly pseudonymized data. By hashing at the edge and never storing or transmitting plaintext identifiers, the entire Schrems compliance surface collapses.

The most compliant data transfer is the one that never happens.

A worked example

Consider a multinational bank using PasskeyBridge for SIM-swap detection across its EU, UK, and APAC operations:

1. EU user authenticates in Frankfurt: MSISDN is hashed at the Frankfurt PoP. Hash is correlated with the carrier's hash. No personal data leaves Germany.

1. UK user authenticates in London: Same process at the London PoP. Post-Brexit UK GDPR applies, but the hash exemption is identical under the UK's retained Recital 26.

1. Singapore user authenticates in Singapore: MSISDN is hashed at the Singapore PoP. Singapore's PDPA excludes data that "cannot be used to identify an individual"—the hash qualifies.

1. Indian user authenticates in Mumbai: MSISDN is hashed at the Mumbai PoP. India's DPDPA defines personal data as "data about an individual who is identifiable by or in relation to such data"—the hash, without the key, does not identify.

In all four cases, the same architecture, the same code path, and the same edge-first verification model satisfy local requirements without jurisdiction-specific routing logic.

Preparing for Schrems III: A technical checklist

For identity architects evaluating their exposure:

1. Audit every outbound API call that includes a phone number, IMSI, or MSISDN. Each is a potential Chapter V transfer.

1. Map the infrastructure of your carrier lookup providers. Where are their API endpoints physically located? Do they guarantee EU-only routing?

1. Implement pre-transfer pseudonymization. Hash identifiers before they leave your infrastructure boundary. Use HMAC with a secret key you control—not a bare SHA-256, which is vulnerable to rainbow table attacks on the limited phone number space.

1. Evaluate your Transfer Impact Assessment (TIA). Does it account for the specific risk that carrier metadata (SIM swap dates, port-out timestamps) could be compelled under FISA Section 702 or a National Security Letter?

1. Document your supplementary measures per EDPB Recommendation 01/2020. Technical measures (hashing, encryption) must be paired with organizational measures (transparency reporting, DPIAs).

1. Monitor the DPF status. If the CJEU invalidates the DPF, organizations relying on it as their sole transfer mechanism will need to fall back to SCCs + supplementary measures—or eliminate the transfer entirely.

After Schrems III

The pattern is clear. Schrems I killed Safe Harbor. Schrems II killed Privacy Shield. If Schrems III kills the DPF, the EU-US data transfer regime will have been reset for the third time in eleven years.

Each reset narrows the available mechanisms. Each reset increases the compliance burden. And each reset makes the architectural argument for zero-transfer stronger.

The organizations that will be unaffected by Schrems III are the ones that stopped transferring personal data before the ruling was issued. Not because they predicted the outcome—but because they built systems where transferring personal data was never necessary in the first place.

That is the PasskeyBridge approach. Not compliance by documentation. Compliance by architecture.

Start free · Test the API