Working draft, v0.1. Markovian Protocol Research. Not legal advice, not a compliance product, not an assertion that any firm is compliant with any rule. This paper describes a method for producing independently verifiable evidence of record integrity and existence-in-time that supports, but does not satisfy, a firm's own recordkeeping obligations.
Electronic recordkeeping rests on a firm attesting to its own integrity. A broker-dealer stores its records, applies retention policy, and, when a regulator, auditor, court, or insurer asks, produces them. At that boundary the outside party has no independent way to know that a produced record is the record that existed at the time claimed, and that it has not been altered, back-dated, or selectively reconstructed since.
Write-once storage (WORM) hardens the medium, but it is costly, vendor-specific, and still resolves, at the audit boundary, to "trust the firm and its vendor's attestation." The 2021-2024 off-channel-communications enforcement wave, over two billion dollars in combined SEC and CFTC penalties across more than one hundred firms, was not about trading fraud. It was about records that could not be produced or whose integrity could not be shown. The pain is provable preservation and integrity, and it is funded at the board level right now.
SEC Rule 17a-4 governs how broker-dealers preserve required records (created under 17a-3; FINRA Rule 4511(c) ties the format and media obligation directly back to 17a-4). Historically, 17a-4(f) permitted electronic storage only if records were kept "exclusively in a non-rewriteable, non-erasable format", the WORM mandate.
The October 2022 amendments (Release No. 34-96034, adopted Oct 12 2022; effective Jan 3 2023; broker-dealer compliance May 3 2023) added a technology-neutral audit-trail alternative as a co-equal option. Under 17a-4(f)(2)(i)(A), a firm may instead use an electronic recordkeeping system that maintains
"a complete time-stamped audit trail that includes ... all modifications to and deletions of the record or any part thereof [and] the date and time of actions that create, modify, or delete the record ... [in a way that will] permit re-creation of the original record if it is modified or deleted."
The amendments also replaced the mandatory Designated Third Party (D3P) with the option to designate a senior executive officer who can furnish records to the Commission.
The significance is that the SEC moved from prescribing an immutable medium to prescribing a testable outcome: prove the record's integrity and full change history over time. That outcome is precisely what cryptographic tamper-evidence plus an independent timestamp is built to deliver.
Markovian is positioned as an independent tamper-evidence and time layer that sits alongside the firm's record store, not as the store itself. It is what makes a firm's audit-trail-alternative system provably an audit trail to a party that does not trust the firm.
The components, all production-real and live:
ots client), and, optionally, an RFC 3161 timestamp from an accredited PKI Time-Stamping Authority (a format long familiar to securities examiners). Presenting both gives sovereignty and regulator legibility.| # | 17a-4 obligation (as amended) | Markovian capability | Honest gap / who else must act |
|---|---|---|---|
| R1 | Audit-trail alternative: all modifications/deletions time-stamped and tracked; original recreatable | Each version committed; a superseding version commits with an in-band reference to the prior root. The prior version's timestamp proves that exact prior state existed, so an overwrite is detectable and the history is witnessed. | Markovian witnesses and orders changes; it does not store each record version or reproduce original text. The firm's store retains every version; the commit step must be wired into the record-write path. |
| R2 | Time-stamping of each record | OpenTimestamps → Bitcoin block headers (independent, un-backdatable), plus optional RFC 3161 TSA. | Until Bitcoin-confirmed (~1 block) an OTS proof is calendar-pending; the firm's own timestamp is self-asserted, which is exactly why the independent anchor is added. |
| R3 | Verification of the quality and accuracy of the recording process | Offline verification: recompute hash, check inclusion, check timestamp. A regulator verifies with zero trust in the firm. | Verifies integrity and existence-in-time of the committed bytes, not that the recording captured the complete or correct business event. |
| R4 | Records readable, readily available, reproducible, downloadable | Portable, signed evidence bundle per record. | Central gap: Markovian stores the hash and metadata, not the human-readable record. Anchoring proves a record existed; it does not preserve or reproduce it. The firm's store must hold, index, and reproduce the actual record. This is why Markovian is a layer alongside storage, never a replacement. |
| R5 | Serialize / index | Content-addressed index (label + root) and version links. | Regulatory indexing (by type, date, account) remains the firm's store's job. |
| R6 | Retention for the mandated period | Proofs are tiny and durable: retained rows, permanent Bitcoin anchors, standalone timestamp files. | Retention of the record body for the period is the firm's duty; Markovian durably retains the proofs. |
| R7 | D3P or designated executive officer able to furnish records | Not a technical control, but Markovian-anchored, offline-verifiable proofs are what the officer hands a regulator to demonstrate integrity, lowering the burden of the undertaking. | Purely procedural. Markovian cannot be the officer or D3P. |
| R8 | Confidentiality of sensitive records | Only the SHA-256 goes on-chain; the body stays in the firm. A one-way hash leaks nothing. | A feature, not a gap: PII, order flow, and privileged communications can be anchored without exposure. |
One-line framing. Markovian does not store your records and does not make you compliant. It gives a regulator, an auditor, an insurer, or a court a way to verify, without trusting you, that the records in your own 17a-4 store are the unaltered records that existed at the time you say they did.
Record: a single trade blotter line (a 17a-3(a)(1) record). The same pattern applies verbatim to an electronic communication under 17a-4(b)(4).
{
"record_type": "trade_blotter_line",
"blotter_id": "BD-2026-0714-000883",
"account": "ACCT-4471",
"side": "BUY", "symbol": "QQQ", "qty": 500, "price": 512.34,
"capacity": "agency",
"exec_time": "2026-07-14T14:32:07.221Z",
"rep": "CRD-2233114", "venue": "NASDAQ",
"order_ref": "ORD-99A21", "settlement": "2026-07-16"
}
Commit. record_bytes = JCS(record); data_hash = sha256(record_bytes); commit the hash, receive merkle_root, timestamp; produce an OpenTimestamps proof over the root (upgraded to Bitcoin-confirmed after ~1 block); optionally an RFC 3161 token. A correction (e.g. a price bust) is a new commitment carrying an in-band reference to the prior root, producing the tracked change trail.
Offline verification transcript (regulator, no trust in the firm):
[1] Binding-valid : PASS sha256(JCS(record)) == commitment.data_hash
[2] Inclusion-valid : PASS merkle inclusion proof resolves to merkle_root
[3] Temporal-valid : PASS ots verify -> Bitcoin block 956857 @ 2026-07-14T14:35Z (stock `ots`)
[3b] TSA-valid (opt): PASS RFC 3161 token verifies against the TSA root certificate
--- change-audit ---
[4] Tamper test : mutate price 512.34 -> 512.43 => data_hash changes => [1] FAILS (alteration detected)
[5] Lineage test : trace supersede -> original; both roots Bitcoin-anchored, edge bound in the pre-image
RESULT: the record existed unaltered at a Bitcoin-attested time; the full change trail is independently reconstructable.
Every property the rule asks for is demonstrated: tamper-evident ([1],[4]), independently time-anchored ([3], a block header the firm cannot forge), verifiable by a regulator with no trust in the firm (offline, stock tooling), and change-audit-trailed ([5]).
A sidecar model, no data leaves the firm. A commit hook on the record-write path computes the canonical hash and commits it; the resulting evidence bundle is exported into the firm's existing archive alongside the record. Phase it: communications first (the enforcement hot zone), then blotters and order records. An on-premise verifier lets examiners and the firm's own auditors verify offline. Offer RFC 3161 alongside Bitcoin for dual independent timestamps.
Publish an "audit-trail-alternative attestation profile": the canonical evidence-bundle schema, the offline verification procedure, and the canonicalization / timestamp / Merkle conventions, aligned to the Markovian claim specification. Seek review by an industry body (SIFMA, FINRA) or an SEC no-action-style engagement so that a Markovian-anchored artifact is a recognized way to evidence the audit-trail alternative, never a claim of compliance by itself.
Compliance is the permission; insurance is the incentive. Tamper-evident, independently verifiable records are a hard risk-reduction control, and insurers price controls.
The throughline: the 2022 audit-trail alternative created the regulatory room; Markovian supplies the independent tamper-evidence and time that make a firm's audit trail provable to a party that does not trust it; and insurance supplies the money reason to adopt it.
Every citation in the final version is to be re-verified against Cornell LII / the Federal Register before circulation. This draft states the honest scope in the open by design: it evidences record integrity and existence-in-time; it does not preserve records, replace storage, or make any firm compliant.