Anthid does not assume your obligations
Nothing on this page transfers a regulatory obligation from your firm to Anthid. Recordkeeping, supervision, and best execution remain yours. What Anthid provides is infrastructure designed so those obligations are practical to meet. Confirm your specific requirements with your compliance counsel.
Record retention
SEC Rule 17a-3 describes the records a broker-dealer must make. Rule 17a-4 describes how long those records must be preserved. The periods differ by record type: memoranda of brokerage orders under 17a-3(a)(6) are three-year records under 17a-4(b)(1), while blotters (the records of original entry under 17a-3(a)(1)) are six-year records under 17a-4(a). The order instruction stream Anthid keeps is source data for both. Rather than classify each record individually, Anthid retains the full order instruction stream for six years, satisfying the longer period. Retention is enforced by policy at the database, not by convention or by a cleanup job. Records are not deleted early and are not deleted on request.Two years is an accessibility window, not a retention period
Rule 17a-4 requires the first two years of a record’s life to be in an easily accessible place. That is a requirement about where a record lives, not whether it still exists. Anthid keeps records for the full six years.
What gets recorded
Every order instruction is written to an append-only event stream before Anthid acknowledges it. Each record carries:
Replaces and cancels do not overwrite the original instruction. They are appended as new sequenced actions against the same intent, so the full history of what was instructed, and in what order, is reconstructible.
Attribution is taken from the request that produced each action, never inherited. A replace or cancel carries forward the payload of the order it commands, but records the credential that sent it, so one credential amending or cancelling what another one placed is visible rather than hidden.
Attribution cannot be added retroactively
Anthid records the credential on every action because there is no way to reconstruct it later. A record that says only which organization instructed an order cannot answer which of your systems sent it, or whether it was sent with a key you have since revoked. Those are the questions a disputed order actually turns on.
Recorded before acknowledged
An order instruction is committed to durable storage in the same database transaction that queues it for execution, and the client receives a response only after that transaction commits. This ordering is deliberate. It means no order can reach a broker without a corresponding record, because the record and the execution request are written atomically. There is no window in which an instruction is in flight but unrecorded.Immutability
The order instruction stream is append-only, enforced by a database trigger that rejects any attempt to update or delete a row. This is a constraint in the database itself, not a rule the application is trusted to follow. Application code cannot modify a recorded instruction, and neither can a direct database session operating with normal application credentials. Corrections are not edits. Any subsequent action against an intent is a new sequenced record, leaving the original in place.Execution records
The instruction record answers what a client asked for. A separate append-only stream records what happened next: each state transition as the order moved to the broker, the broker’s own order identifiers, and any rejection or error returned upstream. The two streams are joinable, so an order can be reconstructed end to end, from the request that arrived at the Anthid edge, through the routing decision, to the broker’s acknowledgment.Pre-trade controls
Anthid evaluates every create instruction against your configured controls before it is accepted. Organization, account, and symbol-level controls, including risk and time-based restrictions, are resolved into an effective policy and applied at submission. This gives supervisory constraints a place to live in the infrastructure itself rather than only in the application calling it. See Controls for configuration.Changes to controls
A control decides whether an order is permitted to exist, which makes changing one a supervisory act in its own right. Every control change is appended to its own record stream, at all three levels of the hierarchy. The reason this stream exists is that current state alone cannot answer a review. Deleting a control used to erase the only copy of it, so nothing could say who disabled an account, when, or under which credential, and that is the half of a dispute a review actually turns on. Each record carries:
Setting a value and removing one are recorded as different acts, and a null never clears a limit. Removing one costs an explicit name. On a risk control, the difference between leaving
max_order_size alone and removing the max_order_size limit is the difference between an order being blocked and an order being sent, so a client that serialises its unset fields as null cannot strip every limit it never mentioned.
The current state of each control stays a directly readable row, which keeps the order path a key lookup rather than a fold over history. Each of those rows names the change that produced it, so a disagreement between a control and its history is detectable rather than silent.
Control history is retained for the same six years as the order records. A control is what allowed or blocked an order, so it belongs to the same record as the order it acted on. Expiring it sooner would leave years in which an instruction and its execution survive but the reason the platform permitted it does not.
A repeated delete is still recorded
Deleting a control that is already gone still appends a record. The second attempt was a real request made by a real principal, and a stream that silently swallowed it would be less truthful than one that shows it.
What was refused, and why
A record of what Anthid accepted only tells you half of what a supervisory review asks for. The other half is what it stopped. Refused submissions are recorded on their own append-only stream, carrying the same attribution as an accepted order and the submission exactly as it arrived. Three kinds of refusal are recorded:
That last case is worth stating plainly: an attempt to submit against an account your organization does not own is refused and recorded. The caller is told the account was not found, which does not confirm whether the identifier exists elsewhere, and the attempt is preserved with the credential behind it. A credential reaching for accounts it should not is exactly the pattern a review needs to be able to see.
Recording a refusal never affects the outcome of the request. The submission is refused on its own merits, and the record is written independently of the transaction the order would have used, so a refusal cannot be lost to the same rollback that discards the order.
Refusals are queryable through the API alongside accepted orders, filterable by account, stage, and a trailing window in days, and retained for the same six years.
Not every rejected request is recorded here
This stream records decisions Anthid made about whether a caller may trade. It deliberately does not record malformed requests. An unparseable order or an unknown identifier is a client error rather than a refusal, and mixing the two would bury the supervisory signal in ordinary integration noise.