Audit trail architecture

Background

Rule 17a-4(f) is the broker-dealer electronic-records rule. It historically required records to be stored in WORM (Write Once, Read Many) format — media that physically prevents modification. The 2022 amendment opened a second compliant path: an audit-trail alternative where records may be modifiable, but changes are cryptographically detectable and logged.

A registered investment adviser is not a broker-dealer, so Rule 17a-4(f) does not apply to you. Your rule is Advisers Act Rule 204-2, which requires true, accurate and current books and records but prescribes no storage technology. We use the 17a-4(f) audit-trail approach as a design reference because it describes a well-understood way to make changes to records detectable. Whether your recordkeeping meets your own obligations is a judgement for you and your counsel. This document gives you what you need to make it.

Mechanism

Every email message archived by Turret receives a SHA-256 cryptographic hash computed at the moment of archival. The hash covers the canonical content of the record:

• Subject line
• Body text (compressed bytes, base64-encoded in canonical form)
• HTML body, if present
• Sender email address
• Recipient and CC addresses (sorted for determinism)
• Original sent timestamp
• Attachment metadata — filename, media type and size (attachment contents are not extracted or scanned in production, and captured files are stored outside the hashed record)
• Mailbox identity (which inbox the message was captured from)

Fields that legitimately change after creation — retention expiry date, search index vectors, operational metadata — are excluded from the hash.

Hashes are stored in a dedicated audit log table (ArchivedMessageActivity) that is append-only at the application layer. The table has no FK constraint on the archived message it describes, so audit log rows persist even after the original record is purged at end of retention.

One qualification, stated plainly because it bounds the claim above: the audit log is keyed to the firm, with a cascading foreign key. Deleting a firm's account outright removes its audit log along with its records. Turret therefore blocks the hard deletion of any firm that still holds archived messages inside its retention window — the records and their proof come out together, or not at all.

Tamper detection

Verification runs across the whole archive. Each record's current content is re-hashed and compared against its original hash from the audit log. Any mismatch is logged as an INTEGRITY_FAILED event and surfaced in the operator dashboard.

Verification runs are started by Turret, and each completed run’s report appears in Reports.

A completed run produces a PDF attestation: how many records were examined, how many verified intact, every record that did not, and a statement of which records the run covered. The latest Archive Integrity Verification Report is downloadable from Reports.

Retention and deletion

While a firm subscribes, records are retained for 7 years under SEC Rule 204-2. After a cancellation, the archive is kept for 60 days (a full export is available on request) and then deleted by a reviewed manual step; an account left unpaid for 90 days from the first missed payment may be deleted the same way. When a record's retention period expires, it is deleted via an automated nightly process.

Every retention-expiry deletion is logged in the audit trail with the deletion timestamp, the reason, and the SHA-256 hash of the record at deletion time. For those deletions the audit trail outlives the records it describes: after a record is purged, the log proves it existed, documents its content hash, and records exactly when it was destroyed.

Two other ways records can be removed are not individually hash-logged today, and we would rather say so than imply a proof we cannot produce. An operator-initiated reset of a firm's data deletes the archived messages without writing a per-record deletion entry. Deleting a firm's account cascades its audit log away with its records — which is why Turret refuses that deletion while the firm still holds archived messages inside its retention window. Per-record logging for both paths is on the roadmap.

What this establishes

For an SEC examiner, this architecture provides:

1. Cryptographic evidence of integrity — verification establishes that an archived record has not been altered since archival, or that it has. A mismatch is detected and logged; it does not name who changed the record, because nothing in Turret changes an archived record.
2. A permanent creation record — every archived message is logged at creation with its content hash, and every retention-expiry deletion is logged with the hash of what was destroyed.
3. Documented retention enforcement — automated cleanup logged per-record with hashes.
4. Point-in-time evidence — each verification run produces a dated Archive Integrity Verification Report, downloadable from Reports.

What this does not provide

• Physical immutability. Turret’s archive is tamper-evident, not write-once. The WORM approach stores records on media that cannot be changed; Turret instead detects and records change.
• Cryptographic non-repudiation — hashes verify content integrity but do not provide digital signatures proving authorship.
• Real-time tamper alerts — verification is a point-in-time check, not continuous monitoring. Real-time monitoring is planned for a future release.
• A per-modification log — no Turret code path edits an archived record, so the integrity check proves whether one changed rather than narrating how. A dedicated modification entry, for the day an editing path exists, is on the roadmap; it is not written today.
• Proof for every deletion path — retention-expiry deletion is hash-logged per record. Operator resets and account deletion are not, which is why account deletion is blocked while records remain in retention (see above).

Technical reference

Hash algorithm

SHA-256

Canonical serialization

JSON with alphabetical key order, compressed buffers as base64

Audit log table

ArchivedMessageActivity

Write pattern

Append-only — no application code path updates or deletes rows

Retention window

7 years, while the firm subscribes.

Deletion logging

DELETED activity, with the record's hash, logged before every retention purge. Operator resets and account deletion are not per-record logged — see Retention and Deletion.