Identity Theft Prevention Program

Regulation S‑ID requires any financial institution that offers or maintains “covered accounts” to implement a written Identity Theft Prevention Program that detects, prevents, and mitigates identity theft across account opening and existing accounts. Your fastest path to compliance is to define covered accounts, document red flags and detection methods, set response playbooks, assign governance and approval, then evidence ongoing updates. (17 CFR Part 248, Subpart C)

Key takeaways:

• You need a written program tied to covered accounts, not a generic fraud policy. (17 CFR Part 248, Subpart C)
• The program must cover red flag identification, detection, response, and periodic updates, with board or senior management approval. (17 CFR Part 248, Subpart C)
• Operationalize with mapped workflows (onboarding, account changes, call center, digital access) and retain audit-ready artifacts.

An identity theft prevention program requirement is easy to misunderstand because many organizations already have fraud controls, cybersecurity policies, and KYC/CIP procedures. Regulation S‑ID still expects a distinct, written program focused on identity theft “red flags” for covered accounts, with clear detection and response steps and a governance cadence for updates. (17 CFR Part 248, Subpart C)

For a CCO or GRC lead, the practical challenge is scoping: deciding which products and account types qualify as covered accounts, then translating “detect, prevent, and mitigate” into day-to-day actions your frontline teams actually perform. Examiners typically do not accept “we do this informally” or “our service provider handles it” without documented controls, ownership, and evidence.

This page gives requirement-level implementation guidance you can execute quickly: what to document, who must approve it, how to embed it into onboarding and servicing, what evidence to retain, and where programs commonly fail in audits. All regulatory references are to Regulation S‑ID. (17 CFR Part 248, Subpart C)

Regulatory text

Regulatory requirement (excerpt): “Each financial institution that offers or maintains covered accounts must develop and implement a written Identity Theft Prevention Program designed to detect, prevent, and mitigate identity theft in connection with the opening of a covered account or any existing covered account.” (17 CFR Part 248, Subpart C)

Operator interpretation: you must (1) decide what your covered accounts are, (2) create a written program that lists identity theft red flags relevant to those accounts, (3) implement procedures to detect those red flags in real workflows, (4) define response actions that mitigate harm, and (5) update the program periodically based on changes in risk. The program must be approved by the board of directors or senior management. (17 CFR Part 248, Subpart C)

Plain-English requirement interpretation

An Identity Theft Prevention Program is your firm’s “red flags playbook” for accounts that present identity theft risk. It is narrower than an enterprise cybersecurity program and more structured than an ad hoc fraud procedure.

A compliant program typically answers these questions in plain terms:

• What accounts are covered? (your definition and rationale)
• What are the red flags? (examples: suspicious identity documents, inconsistent customer info, unusual account activity)
• Where do we detect them? (account opening, login/access, profile changes, withdrawals/transfers, customer support calls)
• What do we do when we see them? (stop, step-up authenticate, restrict, investigate, notify, remediate)
• Who owns it and how do we keep it current? (approval, reporting, updates) (17 CFR Part 248, Subpart C)

Who it applies to

Entity scope: “Each financial institution that offers or maintains covered accounts.” Regulation S‑ID applies to financial institutions, including broker-dealers, in the SEC context reflected in the provided applicability data. (17 CFR Part 248, Subpart C)

Operational scope: any business line that opens or services covered accounts, including:

• Account onboarding and identity verification
• Customer service/call center and account maintenance
• Digital channels (customer portal, mobile app) and access management
• Payments, disbursements, transfers, or margin/settlement activities where applicable
• Third parties that support onboarding, servicing, authentication, document verification, or fraud monitoring (you still own the program outcomes)

What you actually need to do (step-by-step)

1) Define and inventory “covered accounts”

Create a list of products/accounts you offer or maintain and mark which are “covered” for identity theft risk. Keep the rationale short but explicit.

Deliverable: Covered Accounts Inventory (by product, channel, and owner) mapped to customer touchpoints (opening and ongoing servicing). (17 CFR Part 248, Subpart C)

Practical tip: Don’t stop at “retail accounts.” Include operational access paths that can change account control, such as address changes, bank instruction updates, or authorized user additions.

2) Build the written Identity Theft Prevention Program document

Write a program document that stands on its own. It can reference existing policies, but it must clearly include the required elements: identify relevant red flags, detect red flags, respond, and update periodically, with board/senior management approval. (17 CFR Part 248, Subpart C)

A tight program table of contents that audits well:

• Purpose and scope (covered accounts; opening and existing accounts)
• Governance (owner, approver, reporting line)
• Red flags catalog (by channel and event)
• Detection procedures (who checks what, when, in which system)
• Response and mitigation procedures (playbooks, decision points, escalations)
• Program maintenance (periodic review/update triggers, change control)
• Training and awareness (role-based expectations; evidence retained)
• Third-party oversight expectations (where third parties perform program activities)

3) Identify relevant red flags for your covered accounts

Create a red flags register that is specific to your business model and channels. Include:

• Red flag description
• Where it appears (onboarding, account change, servicing, transactions, digital access)
• How detected (system rule, manual review, customer verification step)
• Owner (team accountable)
• Expected response (mapped to playbook)

Goal: an examiner can pick a red flag and you can show exactly how it is detected and what happens next. (17 CFR Part 248, Subpart C)

4) Implement detection points in workflows (not just in a policy)

Map detection into the workflows that matter:

• Account opening: identity verification steps, document review, exception handling, how discrepancies are resolved before opening. (17 CFR Part 248, Subpart C)
• Account maintenance: step-up authentication for sensitive changes (contact info, credentials, bank instructions), service scripts, and hold/review logic.
• Existing account monitoring: alerts for anomalous activity appropriate to the account type, plus how alerts are triaged and closed.

Control design test: if a red flag happens tomorrow, can you show a ticket, alert, call log, or case file that proves detection occurred?

5) Define response playbooks that prevent and mitigate harm

Regulation S‑ID expects “respond appropriately” to detected red flags. Your response playbooks should be explicit enough that frontline teams act consistently. (17 CFR Part 248, Subpart C)

Include:

• Triage severity (low/medium/high) based on customer impact and account control risk
• Standard response actions (step-up authentication, temporary restriction, reject request, enhanced review, customer outreach, internal escalation)
• Incident documentation requirements (what gets logged, where, and by whom)
• Closure criteria (what evidence is required to clear the red flag)
• Where Legal/Compliance must be engaged

6) Set governance: approval, ownership, reporting, and periodic updates

Your program must be approved by the board of directors or senior management. Document that approval and keep it current. (17 CFR Part 248, Subpart C)

Define:

• Program owner (usually Compliance, Fraud, or a joint owner with clear RACI)
• Escalation path and management reporting (what is reported and how often, without relying on unsourced numeric cadences)
• Update triggers (new products, new channels, material fraud events, control failures, third-party changes)
• Change management process (versioning, review, approvals, training updates) (17 CFR Part 248, Subpart C)

7) Manage third-party dependencies explicitly

If third parties perform identity verification, authentication, customer support, or fraud monitoring, you still need:

• Contractual expectations for controls, cooperation, and reporting
• Your internal oversight (how you confirm the third party is performing required steps)
• Evidence intake (reports, attestations, tickets, samples)

Daydream can help here by centralizing third-party control evidence requests, tracking program artifacts, and keeping a single system of record for approvals and periodic updates across stakeholders.

Required evidence and artifacts to retain

Keep evidence that shows the program exists, was approved, operates in practice, and is kept current. Examples:

• Written Identity Theft Prevention Program (current and prior versions) (17 CFR Part 248, Subpart C)
• Board or senior management approval records (minutes, resolutions, signed approval memo) (17 CFR Part 248, Subpart C)
• Covered Accounts Inventory and scope rationale
• Red flags register mapped to products/channels (17 CFR Part 248, Subpart C)
• Workflow documentation (onboarding SOPs, servicing scripts, system control descriptions)
• Case management records showing detection → response → closure
• Training materials and completion evidence for relevant roles
• Program review/update records (change log, risk assessment inputs, lessons learned) (17 CFR Part 248, Subpart C)
• Third-party oversight artifacts (contracts, SLAs, oversight reviews, issue logs)

Common exam/audit questions and hangups

Expect examiners/auditors to probe these areas:

• Show me your covered accounts. Where is the inventory, and who owns it?
• Point to your red flags list. How did you decide which red flags are “relevant”? (17 CFR Part 248, Subpart C)
• Demonstrate detection. For two red flags, show the system rule or the manual process plus evidence it ran.
• Demonstrate response. Provide a sample case file from detection through mitigation. (17 CFR Part 248, Subpart C)
• Prove governance. Where is board/senior management approval and evidence of periodic updates? (17 CFR Part 248, Subpart C)
• Third-party reliance. If a third party performs onboarding or call center functions, show your oversight and how issues get escalated.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: treating S‑ID as “covered by cybersecurity.”
   Fix: keep a distinct written program that maps red flags to account-opening and servicing workflows. (17 CFR Part 248, Subpart C)

2. Mistake: a generic red flags list with no operational tie-in.
   Fix: add “where detected,” “evidence produced,” and “required response” per red flag.

3. Mistake: unclear covered accounts scope.
   Fix: create a product-by-product inventory with a clear owner and change control for new products/channels.

4. Mistake: response steps that depend on tribal knowledge.
   Fix: publish playbooks and require case notes that show which step was performed and why.

5. Mistake: no proof of periodic updates.
   Fix: maintain version history, review notes, and approvals showing the program changes as risks change. (17 CFR Part 248, Subpart C)

Enforcement context and risk implications

No public enforcement cases were provided in the authorized source catalog for this page, so this guidance focuses on meeting the text of Regulation S‑ID and producing audit-ready operational evidence. (17 CFR Part 248, Subpart C)

From a risk perspective, gaps in identity theft red flag detection and response usually show up as: account takeovers, unauthorized changes to customer credentials or disbursement instructions, inconsistent treatment across channels, and weak documentation that prevents you from proving controls worked. Regulation S‑ID’s “written program” and “update periodically” expectations are designed to prevent those failures. (17 CFR Part 248, Subpart C)

Practical execution plan (30/60/90-day)

Below is a practical rollout plan. Treat the phases as gates; move to the next phase once evidence exists, not when a draft is written.

First 30 days: scope + baseline program

• Assign program owner and build a RACI across Compliance, Fraud, Operations, and Technology.
• Inventory products and define covered accounts; document rationale.
• Draft the written Identity Theft Prevention Program with required sections. (17 CFR Part 248, Subpart C)
• Create a first-pass red flags register tied to workflows.
• Identify top workflow evidence sources (case tool, ticketing, CRM notes, onboarding platform logs).

By 60 days: embed controls + prove operation

• Implement detection checkpoints in onboarding and servicing SOPs.
• Publish response playbooks and escalation paths; train frontline managers.
• Start capturing sample cases end-to-end (detection through closure) to validate evidence quality.
• Put third-party oversight asks in writing and collect initial artifacts.

By 90 days: governance + durability

• Obtain board or senior management approval and file it with the program artifacts. (17 CFR Part 248, Subpart C)
• Run a tabletop test for at least one account-opening scenario and one existing-account scenario; log gaps and remediation actions.
• Establish the periodic update mechanism (review agenda, change log, risk triggers) and document the first review cycle. (17 CFR Part 248, Subpart C)
• Centralize evidence collection (for example, in Daydream) so audit requests do not become a scramble across teams.

Frequently Asked Questions

Do we need a separate policy document, or can we point to existing fraud procedures?

Regulation S‑ID requires a written Identity Theft Prevention Program with specific elements (red flag identification, detection, response, updates, and approval). You can reference existing procedures, but the program should stand on its own and clearly map those procedures to the requirement. (17 CFR Part 248, Subpart C)

What exactly is a “covered account”?

The requirement applies to financial institutions that offer or maintain covered accounts, and your first operational step is to define which of your accounts fall into that scope. Keep the inventory and rationale written and maintain it as products and channels change. (17 CFR Part 248, Subpart C)

How do we prove we “detect” red flags in practice?

Keep artifacts that show detection happened: system alerts, manual review checklists, onboarding exception notes, call logs, and case management records. Auditors typically want to trace a red flag from trigger to closure with evidence at each step. (17 CFR Part 248, Subpart C)

Can we outsource red flag detection or identity verification to a third party?

You can use third parties to perform activities, but you still need a program that defines what must happen and how you oversee performance. Keep contracts, oversight reviews, and evidence outputs so you can demonstrate the control worked. (17 CFR Part 248, Subpart C)

Who must approve the Identity Theft Prevention Program?

The program must be approved by the board of directors or senior management. Retain minutes, a resolution, or a signed approval memo that matches the current program version. (17 CFR Part 248, Subpart C)

How often do we have to update the program?

Regulation S‑ID requires periodic updates to reflect changes in risks, but it does not specify a fixed interval in the provided text. Define practical update triggers (new products, incidents, control failures, third-party changes) and document each review and resulting change. (17 CFR Part 248, Subpart C)