Compliance · Broker-dealer recordkeeping
SEC 17a-4 audit-trail-alternative.
Last updated 2026-05-02. KumoKodo, Inc. asserts that Kodori satisfies the audit-trail-alternative criteria established by the November 2022 amendment to SEC Rule 17a-4(f) (87 FR 66412). The amendment, effective January 3, 2023, modernized the rule’s historic Write-Once-Read-Many (WORM) requirement to permit electronic recordkeeping systems that maintain a complete time-stamped audit trail with appropriate verification controls.
Scope
This claim addresses the technical substrate Kodori provides to broker-dealers, registered investment advisers under SEC Rule 204-2 (which incorporates 17a-4 by reference), and Municipal Securities Rulemaking Board members under MSRB Rule G-9. As with all SEC recordkeeping rules, the regulated entity remains responsible for procedural conformance — designation of the Third Party (DTP), retention-period configuration, and inspector cooperation are the customer’s scope.
Audit-trail-alternative posture
Pre-2022, Rule 17a-4(f) required broker-dealer electronic records to be stored on non-rewriteable, non-erasable WORM media. The 2022 amendment retained that path but added an equivalent audit-trail-alternative: an electronic recordkeeping system may instead maintain a complete, time-stamped audit trail that meets the criteria in §240.17a-4(f)(3)(i). Kodori’s hash-chained audit architecture is purpose-built for this alternative.
§240.17a-4(f)(3) criteria — section-by-section conformance
| Section | Requirement | Kodori control |
|---|---|---|
| §240.17a-4(f)(2)(i) | Preserve a complete time-stamped audit trail that includes, at a minimum: (A) all modifications to and deletions of a record or any part thereof; (B) the date and time of actions that created, modified, or deleted the record; (C) information that identifies the individual creating, modifying, or deleting the record; and (D) any other information necessary to maintain an audit trail of the original and revised record in a complete, true, and legible manner. | Hash-chained audit log: every consequential mutation appends an event to the per-tenant log with `actorId` (identity), `actorKind` (user / agent / system), `eventType`, `subjectId`, `payload` (before/after for modifications), and a server-clock `createdAt` timestamp. The chain itself preserves order via `prev_hash`. Document version history preserves every prior version of every document. |
| §240.17a-4(f)(2)(ii) | The electronic recordkeeping system must be capable of being readily downloaded and transferred in both human readable format and a reasonably usable electronic format and evidence to that effect must be available at all times. | Audit log CSV export with date + actor filters. Document blobs available via /api/v1/documents/[id]/blob (original bytes) and /api/v1/documents/[id]/text (extracted text). Bulk export of an entire tenant available via the /api/v1/users/me/data-export endpoint and tenant-admin export request. |
| §240.17a-4(f)(2)(iii) | A complete time-stamped audit trail must be readily available and able to be readily provided to the Commission and other regulators upon request. | On-demand `verifyAuditChain` MCP tool walks the chain end-to-end and reports the verification result in real time. The /audit dashboard surfaces filterable views of every event by date / actor / event-type / subject. Designated Third Party (DTP) access can be provisioned for regulator inspection. |
| §240.17a-4(f)(3)(i)(A) | Maintain and preserve in a manner that prevents the alteration, deletion, or destruction of records that are required to be maintained pursuant to the rule throughout the period that the records are required to be maintained. | Hash-chained audit log: tampering with any prior event invalidates the SHA-256 chain at the next verification. Object Lock / WORM on the underlying R2 / S3 bucket lands for retention-tagged blobs. Tombstone status precedes hard purge by the retention-class window; legal-hold-bound documents refuse all destructive operations. |
| §240.17a-4(f)(3)(i)(B) | Be able to recreate an original record if it is altered, over-written, or erased. | Document version history: every modification creates a new version with a monotonic version number and preserves the prior version’s SHA-256 content hash + bytes. The original is retrievable as long as it is within the retention window. Side-by-side diff at /doc/[id]/versions. |
| §240.17a-4(f)(3)(i)(C) | Verify automatically the completeness and accuracy of the process for recording records. | Weekly Inngest cron `audit-chain-verify-weekly` runs every Sunday 02:00 UTC and verifies the chain end-to-end per tenant. Result emits `audit.verification.completed` to a sister stream. On failure, the host’s `onFailure` notifier (Resend email broadcast to every workspace owner) fires immediately. The verifier shares code with the on-demand verifier so behavior is identical. |
| §240.17a-4(f)(3)(i)(D) | Serialize the original and, if applicable, duplicate units of storage media, and time-date for the required period of retention the information placed on such electronic storage media. | Content-addressable storage keyed by SHA-256 of the document content. The hash IS the storage key — uniqueness and serialization are properties of the addressing scheme. Every blob carries a `createdAt` timestamp, the originating event ID, and the immutable chain reference. |
| §240.17a-4(f)(3)(i)(E) | Have the capacity to readily download indexes and records preserved on the electronic recordkeeping system to any medium acceptable under this paragraph (f) as required by the Commission or the self-regulatory organizations of which the broker-dealer is a member. | Bulk export endpoints (audit CSV, document bytes, full-tenant JSON via /api/v1/users/me/data-export). Output formats include CSV, JSON, original blob bytes, Markdown / text for AI conversation transcripts. Custom-format export coordination available via security@kumokodo.ai. |
| §240.17a-4(f)(3)(ii) | Designation of a Third Party (DTP) to access and download records on the Commission’s behalf at the request of the Commission staff. | Customer-side responsibility — the broker-dealer designates the DTP. Kodori provides the technical mechanism (a designated DTP user account with audit-export-only permission scope can be provisioned by the workspace owner from /api-keys + /admin/permissions). |
Retention periods
Rule 17a-4 retention varies by record type (e.g., 6 years for customer account records, 3 years for general business records, lifetime-of-account-plus-6 for some trade records). Kodori’s retention-class system supports arbitrary retention periods per document type, with an enforced disposal review queue at retention-class expiry — review-disposition documents land at /retention/review for human confirmation; auto-tombstone dispositions run via the daily retention cron.
FINRA notification
A broker-dealer using an audit-trail-alternative system under 17a-4(f)(3) must furnish the Commission and the firm’s self-regulatory organization with a representation describing the system. KumoKodo provides a customer-firm-letter template and the underlying technical-architecture document on request to support this filing — email compliance@kumokodo.ai.
Designated Third Party (DTP)
The 17a-4(f)(3)(ii) DTP designation is the customer’s scope. Kodori supports DTP access via:
- A dedicated user account provisioned by the workspace owner with read-only + audit-export permission scope.
- An API key with `search:read` scope only (no write scopes) for programmatic audit retrieval.
- Optional DTP-specific webhook subscription to mirror audit events to a DTP-controlled endpoint in real time.
Cross-references
- Security & compliance overview
- 21 CFR Part 11 conformance claim (overlapping audit-substrate controls)
- How the audit log works
- Audit CSV export
Questions
Email compliance@kumokodo.ai or security@kumokodo.ai.