The SEC's Regulation Best Interest (Reg BI), which became fully effective in June 2020, has now generated five years of examination findings, enforcement actions, and risk alerts. The Division of Examinations has issued specific Reg BI risk alerts in 2020, 2021, 2023, and 2024. The pattern of cited deficiencies has stabilized enough that we can now say, with reasonable confidence, what the cases that get cited tend to look like.
This article surfaces twelve such cases — fact patterns examiners have repeatedly cited as Care Obligation deficiencies — and walks through the data-model implications for testing each. It's the long-tail companion to our Reg BI Care Obligation Audit Data Checklist and Generating Reg BI Test Data: A Methodology for Compliance Teams guide.
A note on what Reg BI's Care Obligation actually requires
Reg BI imposes four obligations on broker-dealers: Disclosure, Care, Conflict of Interest, and Compliance. The Care Obligation requires a broker-dealer to "exercise reasonable diligence, care, and skill to (i) understand the potential risks, rewards, and costs associated with the recommendation; (ii) have a reasonable basis to believe that the recommendation could be in the best interest of at least some retail customers; and (iii) have a reasonable basis to believe the recommendation is in the best interest of a particular retail customer based on that retail customer's investment profile and the potential risks, rewards, and costs."
The Care Obligation is structurally three sub-obligations — issuer-level diligence, reasonable-basis suitability, and customer-specific suitability — and examiners cite each separately. The twelve cases below cluster around customer-specific suitability, where the volume of cited deficiencies has been highest.
Your test corpus has to exercise each of these patterns to credibly demonstrate the supervisory engine works. Production data, even at scale, tends to under-represent each of them.
The twelve cases
Case 1 — Concentrated stock position, no diversification documentation
A retail customer has more than 30% of investable assets in a single stock — typically employer stock from RSU vesting or a long-held inheritance. The broker-dealer recommended a transaction that maintained or increased the concentration without documenting consideration of diversification.
What your engine has to detect. Per-security concentration as a percentage of investable assets, calculated correctly across taxable and tax-deferred accounts. Recommendations that change the concentration in either direction. The presence or absence of a documented diversification discussion in the customer file.
Test corpus structural requirement. Households with documented concentration ratios at multiple thresholds (10%, 20%, 30%, 50%) and recommendation events that interact with the concentration.
Case 2 — Senior client (75+) with high-cost or high-risk product
A customer over 75 was recommended a product with above-typical cost (proprietary mutual fund with elevated expense ratio, indexed annuity with high surrender charges) or above-typical risk for the customer's profile.
Detect. Customer age at recommendation date. Product cost and risk metrics calibrated to age-appropriate benchmarks. Documentation of age-and-horizon consideration.
Corpus. Households with customer ages at examination-relevant thresholds (75, 80, 85). Recommendation events for age-suitability-questionable products.
Case 3 — Recently inherited assets, no source-and-suitability documentation
A customer received a substantial inheritance and was recommended specific dispositions or product purchases without documented consideration of the inheritance's tax-cost basis, tax situation post-inheritance, or evolving investment profile.
Detect. Recent inheritance events. Recommendation timing relative to inheritance. Documentation of inheritance-context consideration.
Corpus. Households with documented inheritance events at varying scales and types (cash, securities, retirement accounts under SECURE Act rules, real property). Recommendation events at varying intervals after inheritance.
Case 4 — Documented cognitive-decline indicators
A customer's account file contains indicators of cognitive decline — repeated calls about the same topic, confusion about prior transactions, third-party requests for account changes — and the broker-dealer continued to make recommendations without elevated diligence or, where appropriate, escalation under FINRA Rule 4512(a)(1)(F) and Rule 2165.
Detect. Cognitive-decline markers in customer interaction history. Trusted-contact information (per FINRA Rule 4512). Recommendation events post-marker without elevated documentation.
Corpus. Households with documented cognitive-decline interaction patterns. Some with trusted-contact populated, some without.
Case 5 — Risk-tolerance mismatch with stated profile
The customer's stated risk tolerance on the most recent profile update is inconsistent with the recommended portfolio's actual risk metrics. Examiners cite both directions — conservative profiles holding aggressive products and aggressive profiles inappropriately conservative.
Detect. Customer risk tolerance from most recent profile. Portfolio risk metrics computed at recommendation date. Mismatch flags.
Corpus. Households with stated risk tolerances across the spectrum and portfolio compositions both consistent and inconsistent.
Case 6 — Time-horizon mismatch between goal and product
The customer's stated goal has a specific time horizon (3–5 years for a home down payment, 15–20 years for retirement) and the recommended product has a structurally different horizon (15-year surrender charges on an annuity for a 5-year goal).
Detect. Goal-specific time horizons. Product structural horizons (surrender periods, lockup periods, volatility-vs-horizon mismatch). Documentation of horizon analysis.
Corpus. Households with multiple stated goals at varying time horizons. Recommendation events for products with structural horizons that align or misalign.
Case 7 — Liquidity-need mismatch
The customer has documented near-term liquidity needs (medical, education, housing) that the recommended product does not accommodate. Locked-up products recommended to customers whose cash flow needs the lockup would impair.
Detect. Documented liquidity needs and time horizons. Product liquidity profiles. Mismatch detection.
Corpus. Households with documented liquidity events at varying intervals. Recommendation events for products with structurally different liquidity profiles.
Case 8 — Cost-comparison silence on similar products
The customer was recommended a higher-cost share class or higher-cost equivalent product without documented comparison to lower-cost alternatives.
Detect. Recommendation events with cost metrics. Reasonably-comparable alternatives in the firm's product catalog. Documentation of comparison analysis.
Corpus. Households recommended into specific product classes where lower-cost alternatives existed at the firm. Some with documented comparison, some without.
Case 9 — Product-class concentration in proprietary or affiliated products
A disproportionate share of the customer's portfolio is in proprietary or affiliate-issued products without documented consideration of independent alternatives. The Conflict of Interest obligation overlaps here, but the Care Obligation cite is about customer-specific suitability of the proprietary concentration.
Detect. Proprietary and affiliate-issued holdings as a percentage of total portfolio. Documentation of consideration of non-affiliated alternatives.
Corpus. Households with varying percentages of proprietary and affiliate products.
Case 10 — Account-type recommendation without documented analysis
The customer was recommended into a specific account type (advisory, fee-based brokerage, retirement rollover) without documented analysis of cost, service, or customer-specific best-interest determination. Account-type recommendations have been a particular focus of recent enforcement.
Detect. Account-type changes. Documented analysis specifically including cost and service comparison.
Corpus. Households with account-type changes. Both documented and undocumented analysis records.
Case 11 — Rollover without retention-versus-rollover analysis
A specific subset of Case 10: the customer was recommended to roll over an employer retirement plan to an IRA without documented analysis of plan-retention, cost differences, service differences, investment-option differences, and customer-specific circumstances. Rollover recommendations are explicitly addressed in DOL fiduciary guidance.
Detect. Rollover events. Pre-rollover plan characteristics. Post-rollover IRA characteristics. Documentation of retention-versus-rollover analysis.
Corpus. Households with documented rollover events from various source-plan types (401(k), 403(b), 457, federal TSP).
Case 12 — Variable-annuity recommendation without prospectus-content analysis
The customer was recommended into a variable annuity, including specific subaccount allocations and rider configurations, without documented analysis of the prospectus disclosures and how they apply to the customer's specific circumstances. Variable-product recommendations are subject to FINRA Rule 2330's heightened requirements.
Detect. Variable-product recommendations. Documentation of prospectus-content review specific to the recommendation. Rider configurations and the customer-specific best-interest analysis for each rider.
Corpus. Households with variable-product recommendations at varying levels of complexity.
Building a test corpus that exercises each case
These twelve cases share a structural property: each is a combination of customer-profile characteristics and recommendation characteristics. To test the supervisory engine on each, the corpus needs households whose profiles match each pattern.
A defensible Reg BI test corpus has, at minimum:
Minimum corpus composition
- 130+ households spanning the twelve cases above
- Customer ages across the regulator-relevant thresholds (especially 75+)
- Documented life events (inheritance, divorce, recent retirement, sale of business)
- Documented goals with time horizons and liquidity needs
- Stated risk tolerances at multiple levels
- Cognitive-decline interaction histories where applicable
- Trusted-contact information populated for relevant cases
- Recommendation event histories with both documented and undocumented analyses
- Portfolio compositions including proprietary, concentrated, and high-cost positions
- Rollover and account-type-change events
- Variable-product holdings with rider configurations
Our Reg BI Suitability Audit Pack is a 130-household corpus built specifically to exercise these cases. Each household carries the eligibility triggers required to fire the supervisory rules examiners cite. The methodology PDF documents how each household maps to the cited fact patterns.
What the supervisory engine should produce per case
For each of the twelve cases, a credible supervisory engine should produce:
- A flag identifying the case category
- The specific data elements that triggered the flag
- A reference to the firm's documented procedure for handling the case
- Whether the documented procedure was followed (yes / no / unclear)
- The reviewer disposition (cleared / escalated / required-additional-documentation)
- A timestamp and audit log of the review
Engines that fire flags but don't produce the supporting documentation make the firm's defense in examination harder, not easier.
What examiners look for in the corpus itself
A subtle point: when an examiner reviews the firm's testing program, they're not just looking at whether the engine fires correctly. They're looking at whether the test corpus the firm used was adequate to test the engine in the first place.
A firm that ran 200 tests against a corpus that contained no Case 4 (cognitive-decline) households has not, in any meaningful sense, tested whether the engine handles Case 4.
This is the structural argument for a purpose-built test corpus: not just because it makes the engine better, but because the corpus itself becomes part of the firm's documentation of its testing program.
Closing
The Care Obligation, in practice, is a documentation-and-coverage discipline as much as it is a substantive recommendation discipline. The supervisory engine has to fire on the right cases, the right cases have to be documented, and the firm's testing program has to demonstrate that each case was exercised before the engine ever encountered a real customer in that situation.
The twelve cases above are the ones we'd test against, derived from the pattern of cited deficiencies in published Risk Alerts and enforcement actions. Our Reg BI Suitability Audit Pack is the corpus we'd use; the methodology guide walks through the case-to-household mapping in detail.
If your supervisory engine is being built or rebuilt and you'd like to compare your corpus's case coverage against ours, the free sample on GitHub is the place to start.
Key takeaways
- Reg BI Care Obligation cited deficiencies cluster around customer-specific suitability — the twelve patterns in this article reflect five years of stable enforcement signal.
- Each pattern is a combination of customer-profile facts AND recommendation facts — testing the engine requires households whose profiles match each pattern, not just product transactions.
- Senior clients (75+), cognitive-decline markers, recent inheritance, and rollover recommendations are four pattern clusters where production data routinely under-represents the cases the engine is most likely to fail on.
- The supervisory engine must produce the SUPPORTING documentation (data triggers, procedure reference, disposition, audit log) — flags alone make examination defense harder, not easier.
- Examiners review the corpus the firm tested with, not just the engine's output. A corpus that doesn't contain Case 4 households hasn't tested Case 4 — period.
Related reading:
- Reg BI Suitability Audit Pack (Data Set)
- Reg BI Care Obligation Audit Data Checklist
- Generating Reg BI Test Data: A Methodology for Compliance Teams
- Form CRS & Reg BI Disclosure Obligation Data Checklist
- Playbook: Quarterly compliance dry-run on a synthetic customer population
This document is general guidance for supervisory engine designers and compliance testers. It is not legal advice and is not a substitute for the firm's compliance procedures. Firms with active examinations or specific regulatory questions should consult qualified counsel.