Red Flag Identification and Detection

To meet the red flag identification and detection requirement, your Identity Theft Prevention Program must define which identity-theft “red flags” are relevant to your covered accounts and build repeatable detection steps into account opening, authentication, servicing, and transaction monitoring. The program must reflect your specific products, access channels, and prior identity-theft experience. (17 CFR Part 248, Subpart C)

Key takeaways:

• You must select red flags that match your covered accounts and how customers open and access them. (17 CFR Part 248, Subpart C)
• Detection is operational: embed checks in onboarding, login/reset flows, profile changes, and unusual activity reviews. (17 CFR Part 248, Subpart C)
• Examiners will expect evidence that your red flags map to processes, alerts, and training, not a static list in a policy. (17 CFR Part 248, Subpart C)

“Red Flag Identification and Detection” is the part of Regulation S-ID that forces your Identity Theft Prevention Program to move from a policy statement to a working detection system. The requirement is narrow but unforgiving: you need reasonable policies and procedures that (1) identify relevant red flags for your covered accounts and (2) detect those red flags in the places identity theft actually shows up, such as new account setup, credential changes, address updates, and unusual account activity. (17 CFR Part 248, Subpart C)

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing this requirement is to treat it as a design-and-implementation exercise with three outputs: a tailored red-flag inventory (pulled from the categories in Appendix A), a control map that shows exactly where each red flag is detected, and an evidence package that proves the controls run and escalate issues. (17 CFR Part 248, Subpart C)

If you manage broker-dealer operations or another regulated financial institution function, you will also need coordination across Operations, Client Service, Fraud/Risk, Security, and any third parties that support account opening or servicing. The goal is not to detect everything; it is to detect the right things, reliably, for your risk profile. (17 CFR Part 248, Subpart C)

Regulatory text

Regulation S‑ID requires that your Identity Theft Prevention Program “include reasonable policies and procedures to identify and detect relevant red flags for covered accounts,” and that you incorporate “applicable risk factors and sources of red flags.” (17 CFR Part 248, Subpart C)

What that means for operators

• “Identify relevant red flags” means you cannot copy a generic list. You must select red flags that match your covered accounts, your opening/access methods, and your experience with identity theft. (17 CFR Part 248, Subpart C)
• “Detect” means you must place checks where the signal exists (onboarding, authentication, servicing, and activity monitoring) and define who reviews alerts and what happens next. (17 CFR Part 248, Subpart C)
• “Incorporating applicable risk factors and sources” ties your red flags to Appendix A’s categories and to your business realities (products, channels, customer types, and operational history). (17 CFR Part 248, Subpart C)

Plain-English interpretation (what you’re being asked to do)

You must run a program that spots identity-theft warning signs in your covered accounts. The SEC expects you to:

1. Decide which warning signs matter for your covered accounts, using Appendix A’s categories as the source set. (17 CFR Part 248, Subpart C)
2. Build detection steps into workflows so those warning signs are surfaced, reviewed, and escalated. (17 CFR Part 248, Subpart C)
3. Keep records showing the red flags you selected, why you selected them, and proof that detection controls operate. (17 CFR Part 248, Subpart C)

Appendix A’s five categories you should work from are:

• Alerts/notifications from consumer reporting agencies
• Suspicious documents
• Suspicious personal identifying information
• Unusual use of, or suspicious activity related to, a covered account
• Notice from customers, victims of identity theft, law enforcement, or others (17 CFR Part 248, Subpart C)

Who it applies to (entity and operational context)

Entity types

• Financial institutions and broker-dealers that maintain “covered accounts” and therefore must maintain an Identity Theft Prevention Program under Regulation S‑ID. (17 CFR Part 248, Subpart C)

Operational contexts where detection must exist

• Account opening / customer onboarding: new account requests, identity verification, suitability/KYC intake, funding setup. (17 CFR Part 248, Subpart C)
• Account access: logins, password resets, MFA enrollment changes, device changes, call-center authentication. (17 CFR Part 248, Subpart C)
• Account maintenance: address changes, bank instruction updates, beneficiary changes, email/phone updates. (17 CFR Part 248, Subpart C)
• Account activity monitoring: unusual trading patterns, unusual transfers, repeated failed authentication, access from atypical locations/devices, rapid profile changes followed by withdrawals. (17 CFR Part 248, Subpart C)
• External notifications intake: customer complaints, law enforcement inquiries, third-party fraud notices. (17 CFR Part 248, Subpart C)

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

Step 1: Define your covered-account universe and access paths

Create a short inventory that includes:

• Covered account types (by product line)
• How accounts are opened (in person, online, mail, rep-assisted)
• How accounts are accessed (web, mobile, call center, advisor portal, API/third party)
• Material third parties involved in onboarding or servicing (17 CFR Part 248, Subpart C)

Output artifact: “Covered Accounts & Access Channels Summary” (owned by Compliance, validated by Operations). (17 CFR Part 248, Subpart C)

Step 2: Build a tailored red-flag inventory from Appendix A categories

Start with the five Appendix A categories, then tailor. For each candidate red flag, record:

• Where it could occur (onboarding, login, servicing, transactions)
• Whether you can detect it today (yes/no/partial)
• Data source (system of record, document capture, call notes)
• Primary owner for review (Ops, Fraud, Service, Security) (17 CFR Part 248, Subpart C)

Practical examples by category (customize to your environment):

• Suspicious personal identifying information: mismatches across documents, inconsistent date of birth across systems, multiple customers sharing contact details without a business rationale. (17 CFR Part 248, Subpart C)
• Unusual account activity: sudden changes in withdrawal behavior after profile changes, repeated failed login attempts followed by successful reset, atypical transfer destinations. (17 CFR Part 248, Subpart C)
• Notice from others: customer reports of unauthorized activity, law enforcement outreach, another institution’s fraud inquiry. (17 CFR Part 248, Subpart C)

Output artifact: “Red Flag Register” with rationale and mappings to Appendix A category. (17 CFR Part 248, Subpart C)

Step 3: Map each red flag to a detection control (manual or automated)

For every red flag in the register, define:

• Detection method (system alert, exception report, manual review step, call script prompt)
• Trigger condition (what causes the alert or review)
• Timing (real-time, same-day batch, event-driven)
• Escalation path (queue, case management, ticket, supervisor review)
• Required action options (verify identity, place hold, reject request, monitor, notify affected groups) (17 CFR Part 248, Subpart C)

Control mapping table (minimum viable):

Red flag	Process step	Detection method	Owner	Escalation
Suspicious ID document	Onboarding	Manual doc review checklist	Onboarding Ops	Fraud queue + Compliance notification
Unusual account activity	Post-onboarding	Daily exception report	Fraud/Risk	Case opened; holds per procedure
Customer reports takeover	Servicing	Intake script + case logging	Client Service	Immediate escalation to Fraud

Output artifact: “Red Flag Detection & Escalation Matrix.” (17 CFR Part 248, Subpart C)

Step 4: Write procedures that a first-line operator can execute

Policies don’t detect red flags; people and systems do. Your procedures should include:

• Step-by-step checklists for onboarding and servicing teams
• Call center authentication requirements and “stop-and-escalate” triggers
• Required verification steps before fulfilling high-risk requests (address changes, bank changes)
• How to document the review in the case/ticket system (17 CFR Part 248, Subpart C)

Tip from practice: If a procedure cannot be executed during a busy queue, it will be skipped. Keep “frontline steps” short, then route complex analysis to Fraud/Risk. (17 CFR Part 248, Subpart C)

Step 5: Operationalize with training, QA, and tuning

Build a feedback loop:

• Train relevant roles on the red flags that apply to their workflows (not the whole universe). (17 CFR Part 248, Subpart C)
• Add QA sampling to confirm steps were followed (checklist completion, correct escalation). (17 CFR Part 248, Subpart C)
• Periodically review whether your red flags still match products/channels and whether detection produces actionable alerts. (17 CFR Part 248, Subpart C)

Where Daydream fits naturally If you struggle to keep the red flag register, control mapping, third-party dependencies, and evidence in sync, Daydream can act as the system of record for the requirement: link each red flag to the owning workflow, evidence, and attestations so exams do not become a document scavenger hunt. (17 CFR Part 248, Subpart C)

Required evidence and artifacts to retain

Keep evidence that shows design decisions and day-to-day operation:

Program design evidence

• Approved Identity Theft Prevention Program section covering identification and detection. (17 CFR Part 248, Subpart C)
• Covered accounts and access channel inventory, including third-party touchpoints. (17 CFR Part 248, Subpart C)
• Red Flag Register mapped to Appendix A categories with “why relevant.” (17 CFR Part 248, Subpart C)
• Detection & Escalation Matrix with owners and triggers. (17 CFR Part 248, Subpart C)

Operational evidence

• Training materials and attendance/attestations by role. (17 CFR Part 248, Subpart C)
• Samples of completed onboarding/servicing checklists (or system logs showing completion). (17 CFR Part 248, Subpart C)
• Alert/event logs and case records showing review and resolution. (17 CFR Part 248, Subpart C)
• QA results and issue remediation tickets tied back to specific red flags/controls. (17 CFR Part 248, Subpart C)
• Change records when products/channels changed and the red flag set was updated. (17 CFR Part 248, Subpart C)

Common exam/audit questions and hangups

Expect these lines of inquiry:

• Relevance: “Why are these red flags the right ones for your covered accounts and channels?” (17 CFR Part 248, Subpart C)
• Coverage: “Show me where, in the process, you detect each red flag.” (17 CFR Part 248, Subpart C)
• Consistency: “How do you know staff follow the steps, and what happens when they don’t?” (17 CFR Part 248, Subpart C)
• Escalation: “Who reviews alerts, what is the SLA, and how do you document outcomes?” Keep this qualitative if you cannot evidence timings. (17 CFR Part 248, Subpart C)
• Third parties: “Which third parties perform identity checks or handle account servicing, and how do you ensure red flags get escalated back to you?” (17 CFR Part 248, Subpart C)

Frequent implementation mistakes and how to avoid them

1. Copy-paste red flag lists with no tailoring. Fix: document “why relevant” for each selected red flag based on products, channels, and experience. (17 CFR Part 248, Subpart C)
2. Detection exists only in policy language. Fix: build a control map and embed steps into systems and scripts. (17 CFR Part 248, Subpart C)
3. No ownership model. Fix: assign a named function to each red flag for monitoring and escalation. (17 CFR Part 248, Subpart C)
4. Alert fatigue without tuning. Fix: track which alerts lead to action and refine triggers or routing. (17 CFR Part 248, Subpart C)
5. Third-party blind spots. Fix: require third parties to pass red-flag signals and supporting details back to you in a defined workflow. (17 CFR Part 248, Subpart C)

Enforcement context and risk implications

No public enforcement cases were provided in the source materials for this requirement page, so this guidance stays anchored to the rule text and Appendix A categories. (17 CFR Part 248, Subpart C)

Operationally, weak red-flag detection creates two predictable risks:

• Customer harm and remediation exposure if identity theft is not detected early in account lifecycle events. (17 CFR Part 248, Subpart C)
• Exam deficiencies if you cannot prove your red flags are relevant, detected in workflow, and supported by evidence. (17 CFR Part 248, Subpart C)

Practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Assign an accountable owner for red flag identification and detection under the Identity Theft Prevention Program. (17 CFR Part 248, Subpart C)
• Inventory covered accounts, opening methods, and access channels; list third parties involved. (17 CFR Part 248, Subpart C)
• Draft a Red Flag Register using the five Appendix A categories; prioritize high-risk lifecycle events (onboarding, access resets, bank changes). (17 CFR Part 248, Subpart C)
• Create a first-pass Detection & Escalation Matrix and socialize with Ops, Fraud/Risk, Security, and Client Service. (17 CFR Part 248, Subpart C)

Days 31–60 (Implement and evidence)

• Embed detection steps into procedures: onboarding checklists, call scripts, service request flows. (17 CFR Part 248, Subpart C)
• Stand up a basic case workflow: how alerts are logged, reviewed, escalated, and closed. (17 CFR Part 248, Subpart C)
• Train roles on the subset of red flags they will see. (17 CFR Part 248, Subpart C)
• Start retaining evidence: completed checklists, sample cases, alert logs, QA samples. (17 CFR Part 248, Subpart C)

Days 61–90 (Tune and harden)

• Run a tabletop review of several scenarios (suspicious document, takeover complaint, unusual activity) and confirm detection-to-escalation works end-to-end. (17 CFR Part 248, Subpart C)
• Close coverage gaps: red flags without a detection control, controls without evidence, third-party handoff failures. (17 CFR Part 248, Subpart C)
• Establish a standing review cadence to refresh red flags when channels/products change or when identity theft patterns shift based on your experience. (17 CFR Part 248, Subpart C)
• If evidence is scattered, centralize control mapping and artifacts in a GRC workflow tool (including Daydream) so audits can be answered from a single source of truth. (17 CFR Part 248, Subpart C)

Frequently Asked Questions

Do we need to detect red flags from every Appendix A example?

No. You must identify and detect the red flags that are relevant to your covered accounts and risk factors, using Appendix A categories as the source set and tailoring based on your products and access methods. (17 CFR Part 248, Subpart C)

What counts as “reasonable” detection procedures?

“Reasonable” means the procedures fit your covered accounts and actually operate in the workflows where identity theft occurs, with documented triggers, owners, and escalation steps. You should be able to show evidence that detection happens in practice. (17 CFR Part 248, Subpart C)

Can we rely on a third party to detect red flags during onboarding?

You can use third parties operationally, but you still need your program to define which red flags are relevant and how detection and escalation information flows back to you. Document responsibilities and retain evidence. (17 CFR Part 248, Subpart C)

Our red flags are mostly manual. Is that acceptable?

The rule does not require automation. Manual controls can work if they are specific, consistently executed, and supported by evidence such as checklists, case notes, and QA results. (17 CFR Part 248, Subpart C)

What evidence do examiners ask for most often?

They typically ask for the tailored red flag list, where each red flag is detected in your process, and proof the controls run (training records, samples of reviews, alert logs, and case outcomes). (17 CFR Part 248, Subpart C)

How often should we update the red flag list?

Update when you change covered accounts, open/access channels, or when your experience with identity theft indicates new patterns. You should also review periodically to confirm the red flags remain relevant and detectable. (17 CFR Part 248, Subpart C)