Compliance & Privacy · 2026-03-05
Reg S-ID Compliance Without Storing a Single Phone Number
By J. W. Bouckaert
The regulation
SEC Regulation S-ID (17 CFR §248.201) requires financial institutions to develop and implement a written Identity Theft Prevention Program. The rule applies to SEC-registered broker-dealers, investment companies and investment advisers that are financial institutions or creditors under the Fair Credit Reporting Act and offer or maintain "covered accounts": personal accounts that permit multiple payments or transactions, such as brokerage accounts, and any other account with a reasonably foreseeable risk of identity theft. It is substantially similar to the FTC's Red Flags Rule guidance for businesses.
The mandate is clear: detect, prevent, and mitigate identity theft. But the regulation doesn't prescribe how.
The PII liability trap
The conventional approach stores phone numbers, addresses, and government IDs alongside account records. This creates a paradox: the data you collect to verify identity becomes the data attackers want to steal.
Every stored phone number is a liability. Every plaintext identifier widens your breach radius. And every DSAR (Data Subject Access Request) under GDPR or CCPA requires you to locate, export, and potentially delete that data.
There's a better way.
Zero-PII identity verification
PasskeyBridge's zero-PII architecture supports the detection and response parts of a Reg S-ID program without storing plaintext personal identifiers. The institution still owns the Program itself: board approval, staff training and oversight of service providers under §248.201(e).
Signal-based threat detection (Pillar I)
Carrier signals (SIM swap, number port, call forwarding) detect identity threats in real-time. But the phone number that triggered the signal is keyed-hashed with HMAC-SHA-256 under a server-held pepper before any persistent storage—non-enumerable, unlike a plain SHA-256 of a phone number. Your audit trail proves you detected the threat—without exposing the phone number. For the full picture of carrier signals, see The Carrier Signal Landscape in 2026.
The response is equally critical. PasskeyBridge executes your playbook inside the same request, so you can demonstrate automated mitigation, not only detection.
Verifiable credential verification (Pillar II)
When Reg S-ID requires you to verify a customer's identity, W3C Verifiable Credentials 2.0 let users prove who they are without transmitting PII. The credential issuer (a bank, government, or trusted third party) signs the claim. PasskeyBridge verifies the signature. The claim itself is never stored.
This can form part of the "reasonable policies and procedures" that §248.201(d)(2) requires, without storing the claims.
Biometric binding (Pillar III)
WebAuthn passkeys bind identity to device-level biometrics. The biometric data (fingerprint, face scan) never leaves the user's Secure Enclave. PasskeyBridge stores the credential public key, the authenticator model identifier and a counter, none of which identifies the person.
Together, the carrier signal reports recent changes to the phone line, the verifiable credential carries an issuer's signed claims about the person, and the passkey shows that someone who can unlock the user's authenticator is present. No PII stored at any step.
Mapping to Reg S-ID requirements
- Identify relevant Red Flags—carrier events such as a SIM swap or a number port-out are candidates for your Red Flag list. PasskeyBridge treats nine signal types, those two included, as hard signals
- Detect Red Flags—In-request signal processing with HMAC-SHA256 verification
- Respond to detected Red Flags—Automated playbook execution with parametric revocation
- Update the Program—event history and usage figures in the dashboard give you data for the periodic update §248.201(d)(2)(iv) requires
The audit evidence
When regulators or auditors ask for evidence of your Reg S-ID program, PasskeyBridge provides:
- Append-only audit log with actor context and timestamped action results
- Signal processing metrics (volume, response times, playbook execution counts)
- Zero-PII design documentation—no sensitive data to produce in discovery
- SOC 2 readiness: evidence collected and under review across all five Trust Service Criteria
For enterprises using AI agent delegates, delegate verifications, scope violations and trust changes are recorded as well.
Get compliant without the liability
Reg S-ID doesn't require you to store phone numbers. It requires a program that detects and responds to Red Flags. PasskeyBridge can carry the detection and response steps, with zero PII, in-request response, and a compliance-ready audit trail.