> Disclaimer: This content is for educational and reference purposes for software builders only. It does not constitute medical, legal, financial, or regulatory advice. Consult a qualified professional before making decisions based on this content.
What is the minimum retention period for broker-dealer records under Rule 17a-4?
The general minimum retention period under Rule 17a-4(b)(1) is six years from the end of the fiscal year in which the record was created. For records in the first two of those six years, they must be readily accessible - i.e., retrievable and reproducible within a response time acceptable to examiners (typically same-day or next-business-day). Some records have longer retention periods: partnership agreements, articles of incorporation, and certain customer records must be retained for the life of the enterprise plus three years. Builders should encode each record type's retention obligation in a configuration table and drive the storage engine from that configuration. (17 CFR § 240.17a-4(b))
Does cloud object storage satisfy Rule 17a-4's WORM requirement?
Yes, cloud object storage can satisfy Rule 17a-4(f) if it is configured in Object Lock Compliance Mode, which prevents any user - including the bucket owner - from deleting or overwriting an object before the retention period expires. The key additional requirement is obtaining a third-party undertaking letter from the cloud provider stating that it will notify the broker-dealer's designated examining authority before deleting any records and provide access to records upon regulatory request. Amazon S3, Azure Blob Storage Immutable, and Google Cloud Storage Object Lock all offer Compliance Mode and can supply the required letter. SIFMA guidance confirms that properly configured cloud WORM storage meets Rule 17a-4 requirements. (17 CFR § 240.17a-4(f)(3)(vii))
What records must a broker-dealer create under Rule 17a-3?
Rule 17a-3 requires broker-dealers to create and maintain the following record categories: (1) blotters of all purchases and sales of securities, showing date, time, price, and counterparty; (2) ledgers of securities long and short; (3) ledger accounts for each customer; (4) memoranda of orders received and placed; (5) copies of all confirmation notices sent to customers; (6) records of all FINRA-required customer information (Rule 17a-3(a)(17)); and (7) records of compensation arrangements for associated persons. Software platforms serving broker-dealers must auto-generate all required record types as transactions are processed. (17 CFR § 240.17a-3(a))
How does Regulation SCI apply to an alternative trading system?
An ATS that accounted for five percent or more of the average daily dollar volume traded in any NMS stock, or one percent or more in any NMS stock in which the ATS accounted for 5%+ of aggregate volume over a specified period, is an SCI ATS subject to Regulation SCI. SCI ATSs must: adopt and enforce written SCI policies and procedures; report SCI events to the SEC; conduct annual SCI reviews; and implement robust business continuity plans with regular testing. Builders must instrument their ATS systems with capacity monitoring, automated failover testing pipelines, and SCI event classification logic that generates the required SEC notification payload within the mandated timeframe. (17 CFR §§ 242.1000–1007)
What data must be captured in an order record under Rule 17a-3?
An order memorandum under Rule 17a-3(a)(6) must contain: the account for which it was entered; the time the order was received; the time the order was entered; the price at which the order was executed; and the identity of any associated person who entered the order. Builders must ensure that the OMS stamps every order state transition - new, partial fill, full fill, cancelled, rejected - with server-side UTC timestamps (not client-side) and records the executing broker and venue. Microsecond-precision timestamps are a market best-practice for SCI entity platforms. (17 CFR § 240.17a-3(a)(6))
What is a third-party undertaking letter and when is it required?
A third-party undertaking letter (also called an undertaking letter) is a signed statement from the provider of the electronic storage medium - typically a cloud storage provider - undertaking to notify the broker-dealer's designated examining authority (DEA) before deleting any records, and to produce records to examiners upon request. It is required under Rule 17a-4(f)(3)(vii) whenever a broker-dealer uses a third-party storage system to satisfy the WORM requirement. Without this letter on file, the cloud WORM configuration alone does not satisfy the rule. Builders must automate the third-party undertaking letter procurement workflow and store executed letters as part of the broker-dealer's compliance documentation.
How should a builder implement an immutable audit log for SEC-regulated records?
An immutable audit log for SEC-regulated records must: (1) record every read, write, deletion attempt, and export of each book-or-record with actor identity, UTC timestamp, resource identifier, action type, and outcome; (2) be stored on WORM-compliant media separately from the application database (a compromised application must not be able to alter its own audit trail); (3) be covered by the same six-year retention policy as the underlying records; and (4) be indexed to allow retrieval by record ID, user ID, time range, and action type within the response-time window expected by examiners. Immutable log implementations include append-only S3 Object Lock buckets, dedicated tamper-evident logging services, and blockchain-anchored log hashes. (17 CFR § 240.17a-4(f)(2)(ii))
What is the SCI event reporting timeline?
Under Rule 242.1002, SCI entities must submit an initial report to the SEC for SCI events affecting critical SCI systems within one hour of the entity's assessment that the SCI event has or may have had a material impact on its operations or on market participants. For SCI events affecting non-critical systems, the initial report must be submitted promptly but no later than 24 hours. A follow-up report with complete information must be submitted within 30 calendar days. Builders must build automated SCI event pipelines with a classification engine (critical vs non-critical), notification payload generator, and SEC submission client within the one-hour critical window. (17 CFR § 242.1002(b))
How should AML transaction monitoring thresholds be configured for a broker-dealer platform?
AML transaction monitoring should not rely on a single fixed monetary threshold. Best practice is a tiered approach: (1) mandatory CTR filing for any cash transaction over $10,000 per FinCEN rules; (2) velocity checks that flag unusual transaction frequency for the customer risk tier (e.g., 3 or more transactions within 24 hours that collectively exceed $9,000, which may indicate structuring); (3) pattern detection for known typologies such as round-dollar transactions, layering through multiple accounts, and rapid in-and-out movements; and (4) peer-group anomaly detection that flags transactions deviating more than two standard deviations from a peer-group baseline. Builders must implement rules as configurable, auditable objects rather than hardcoded logic so that the compliance team can tune thresholds without a code release. (31 CFR § 1023.320 - broker-dealer SAR filing; 31 CFR § 1010.311 - CTR)
What are the data segregation requirements for customer funds at a broker-dealer?
Under Rule 15c3-3 (the Customer Protection Rule), broker-dealers must segregate customer funds and securities from the firm's proprietary assets. Specifically, customer free credit balances must be deposited in a Special Reserve Bank Account for the Exclusive Benefit of Customers (SEC Account). Builders of broker-dealer back-office systems must implement: separate ledger accounts for customer vs firm assets; nightly computation of the reserve formula; automated transfer to the reserve bank account; and audit trails that evidence each nightly computation. Failure to maintain segregation is a serious violation with civil and criminal consequences. (17 CFR § 240.15c3-3)
What is the difference between readily accessible and non-readily accessible records under Rule 17a-4?
Under Rule 17a-4(b)(4), records in the first two years of their required retention period must be easily accessible - the broker-dealer must be able to promptly provide a copy (hardcopy or electronic) to examiners, typically same-day or next business day. For the remaining retention period (years 3–6 for the six-year records), records may be in less immediately accessible storage (e.g., offline tape or low-tier object storage), provided they can still be retrieved within a reasonable timeframe upon examiner request. Builders should implement tiered storage: active storage for years 0–2 (high IOPS, online), and archive storage for years 3–6 (cost-optimised, offline or cold tier). (17 CFR § 240.17a-4(b)(4))
How should customer identity information be protected at a broker-dealer?
Customer identity information includes name, address, date of birth, taxpayer identification number, and copies of identity documents collected during account opening under FINRA Rule 4512 and FinCEN's Customer Identification Programme (CIP) rules. This information must be: (1) stored encrypted at rest (AES-256); (2) access-controlled to only authorised personnel; (3) retained for at least five years after account closure per CIP rules; and (4) covered by the broker-dealer's information security programme. Builders must also implement data-minimisation logic that purges unnecessary copies (e.g., onboarding document uploads not needed after identity verification) on a documented schedule.
What is structuring and how should a builder implement structuring detection?
Structuring (or smurfing) is the practice of conducting financial transactions in amounts designed to evade the CTR filing threshold of $10,000. Structuring is illegal under 31 U.S.C. § 5324. Detection logic must: aggregate all transactions by customer and day; flag any day in which aggregate cash activity approaches but does not exceed $10,000 in the absence of a plausible business explanation; apply a lookback window (typically 30 days) to catch multi-day structuring; and integrate the flag into the SAR decision workflow for analyst review. Builders should implement this as a configurable rule within the AML rules engine rather than a hardcoded threshold.
How should a builder implement books-and-records for a web-based broker-dealer?
A web-based broker-dealer's books-and-records system must capture: all electronic communications relating to the broker-dealer's business (emails, chats, SMS - under Rule 17a-4(b)(4)); trade blotters and order memoranda generated by the trading system (Rule 17a-3); customer account records (Rule 17a-3(a)(17)); and financial ledger records (Rule 17a-3(a)(2)). The implementation stack should route all regulated records through an append-only WORM storage tier at write time, with a separate index database for queryability. Communications archiving must capture all channels used for business communication, including third-party messaging platforms if authorised for use.
What is the SEC's accessible reproduction requirement under Rule 17a-4?
Rule 17a-4(f)(2)(ii)(A) requires that broker-dealers who store records on electronic storage media be able to reproduce them in a legible, hardcopy or electronic form that faithfully represents the original record. This means the storage format must be non-proprietary or, if proprietary, accompanied by the tools necessary to read it. Builders must ensure that archived records can be reproduced without dependency on any specific application version or software license. Using standard open formats (PDF/A, JSON, CSV, or plain text with accompanying schema) for archived records is the safest approach.