Regulation S-ID: Identity Theft Red Flags, at a High Level

In plain language

Regulation S-P is about keeping customer information from getting out. Regulation S-ID is about noticing when someone uses that information to impersonate your client — a changed address followed by a withdrawal request, a login from somewhere improbable, a wire instruction that arrives by email. The rule asks for a written program that identifies those patterns, detects them, responds to them, and gets updated as the patterns change.

What the rule asks for

Regulation S-ID lives at 17 CFR 248.201 and 17 CFR 248.202, adopted jointly by the SEC and CFTC in Release 34-69359. A covered firm must develop and implement a written identity theft prevention program appropriate to its size, complexity, and the nature and scope of its activities, containing reasonable policies and procedures to:

Identify relevant red flags for the covered accounts it offers or maintains, and incorporate them into the program.
Detect those red flags.
Respond appropriately to detected red flags to prevent and mitigate identity theft.
Update the program periodically to reflect changes in risk.

The program requires board, board committee, or designated senior-management approval, staff training, and oversight of service provider arrangements.

The scoping question comes first

The program obligation attaches to firms that offer or maintain covered accounts. For advisers and broker-dealers, that generally turns on whether the firm holds a transaction account — an account permitting payments or transfers to third parties.

This is where a lot of firms stop, and it is a defensible place to stop, but not silently. A firm that concludes it has no covered accounts should keep:

the periodic risk assessment the rule contemplates, considering the methods it uses to open accounts, the methods it uses to provide access to accounts, and its previous experience with identity theft; and
the determination itself, dated, with the reasoning.

The failure mode is not having no program. It is having no program and no explanation, which looks identical to having overlooked the rule.

Red flags technology can actually detect

The rule’s Appendix A offers illustrative examples across several categories. Mapped onto what a firm’s systems can see, the technically detectable ones cluster:

Changes that precede theft. An address change, a phone number change, an email change, or a new bank instruction — particularly one shortly followed by a disbursement request. This is the highest-yield detection in the set, and the control is a notification to the previously held contact method, which is what makes an account takeover visible to the real client.

Authentication anomalies. Logins from unexpected geography, new devices, impossible travel, repeated failures followed by a success, or a password reset requested through an unusual channel.

Unusual account use. A dormant account becoming active, a disbursement pattern inconsistent with the client’s history, or a request to send funds to a third party where none has been sent before.

Inconsistent identifying information. Identity documents that do not match the information on file, or information matching a known fraud pattern.

External notice. A customer reporting that they did not initiate a transaction, or a notice from a consumer reporting agency or law enforcement.

Response has to be pre-decided

The rule requires appropriate responses, and it lists options ranging from monitoring the account, to contacting the customer, to changing credentials, to closing and reopening the account, to not opening it at all, to notifying law enforcement, to determining that no response is warranted.

The operational point is that these decisions are poor ones to make live. Each red flag in the firm’s list should have a pre-agreed first response and a named decision-maker for anything beyond it. “Determining that no response is warranted under the particular circumstances” is an allowed outcome — but it needs to be a recorded determination, not an absence of action.

Where it overlaps with the rest of the program

Regulation S-ID reuses infrastructure that is already there for other reasons:

The alerting that detects red flags is the same monitoring that supports Regulation S-P breach detection.
The authentication anomalies are visible only if access control and MFA is configured to log them.
Service provider oversight for the program is the same register described in vendor oversight.
For advisers, the program’s existence and review land inside Rule 206(4)-7.

Running one detection capability with two reporting views is normally cheaper and more accurate than running two programs. The documents stay separate; the plumbing does not have to be.

Primary sources

Frequently Asked Questions

Which firms are covered by Regulation S-ID?

The rule applies to SEC-regulated financial institutions and creditors that offer or maintain covered accounts. For most advisers and broker-dealers the question turns on whether the firm holds a transaction account for a client — an account permitting payments or transfers to third parties. A firm that concludes it has no covered accounts should record that determination and the periodic risk assessment behind it rather than simply not having a program.

Is Regulation S-ID the same thing as Regulation S-P?

No. Regulation S-P governs safeguarding, disposal, and breach notification for customer information. Regulation S-ID governs detecting and responding to identity theft involving covered accounts. They overlap in evidence — the same logs and alerts feed both — but the programs answer different questions and are written separately.

What counts as a red flag?

A pattern, practice, or specific activity indicating the possible existence of identity theft. The rule's appendix groups illustrative examples into categories including alerts from consumer reporting agencies, suspicious documents, suspicious personal identifying information, unusual account use, and notices from customers or law enforcement. A firm selects the ones relevant to its accounts rather than adopting the list wholesale.

Does the board have to approve the program?

The program must be approved by the board of directors, an appropriate committee of the board, or, if there is no board, a designated employee at the level of senior management. The rule also requires the board or senior management to be involved in oversight, development, implementation, and administration of the program.

Scheduled actions

The recurring work this section implies. Each action carries a stable action-id so it can be tracked in a compliance calendar and rolled up on all scheduled actions.

Re-assess whether the firm offers or maintains covered accounts, and record the determination with the reasoning, including for new products or account types.

Cadence:: Annually
Owner archetype:: CCO
Source:: 17 CFR 248.201
action-id:: act.reg-s-id.covered-account-determination

Update the identity theft prevention program to reflect changes in identity theft risk, the firm's methods of detection and response, service provider arrangements, and account types offered.

Cadence:: Annually
Owner archetype:: CCO
Source:: 17 CFR 248.201(d)(2)
action-id:: act.reg-s-id.program-update

Review the firm's selected red flags against actual incidents and attempted fraud from the period, and add or retire flags accordingly.

Cadence:: Annually
Owner archetype:: CCO, MSP
Source:: 17 CFR 248.201, Appendix A
action-id:: act.reg-s-id.red-flag-list-review

Train staff who handle covered accounts on the red flags relevant to their role and on the escalation path, and retain completion records.

Cadence:: Annually
Owner archetype:: CCO
Source:: 17 CFR 248.201(e)
action-id:: act.reg-s-id.staff-training

Report to the board, a board committee, or designated senior management on the effectiveness of the program, significant incidents, and recommended changes.

Cadence:: Annually
Owner archetype:: CCO
Source:: 17 CFR 248.201(e)
action-id:: act.reg-s-id.board-report

Review the alerting rules that implement technical red flags — address changes, contact detail changes, anomalous logins, unusual disbursement patterns — for false negatives and alert fatigue.

Cadence:: Quarterly
Owner archetype:: IT, MSP
Source:: SEC Release 34-69359
action-id:: act.reg-s-id.detection-rule-tuning

Configuration touchpoints

Where this section lands in a real environment. Each touchpoint is stated as a plain configuration rule — not a vendor setting — and carries a stable config-id.

Configuration rule	Applies to	config-id
Changes to a client's address, phone number, email, or bank instructions generate an alert and a notification to the client on a previously held contact method.	CRM, custodial platform, portfolio accounting	`cfg.reg-s-id.profile-change-alerting`
Disbursement or transfer instructions received by email or portal message require verbal or out-of-band verification against a previously held contact record before execution.	Operations workflow, wire approval process	`cfg.reg-s-id.disbursement-verification`
Client-facing portal and firm account logins from unexpected locations, new devices, or impossible-travel patterns generate an alert that a person sees.	Identity provider, client portal	`cfg.reg-s-id.anomalous-login-alerting`
The identity verification performed at account opening, and any later re-verification, is recorded against the account rather than remembered by the person who did it.	Onboarding system, CRM	`cfg.reg-s-id.identity-verification-record`
A triggered red flag creates a case record with the disposition, so the annual report can describe incidents rather than estimate them.	Ticketing or case management	`cfg.reg-s-id.red-flag-case-record`