> ## Documentation Index
> Fetch the complete documentation index at: https://docs.anthid.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Compliance
> How Anthid records and preserves order instructions, control changes, and refusals, and what that means for broker-dealer and registered adviser clients
Anthid is trading infrastructure, not a broker-dealer. We do not take custody of customer assets, we do not make recommendations, and we do not exercise discretion over any order. We act on instruction: every order that reaches a broker through Anthid originates from an authenticated client request, and we keep a durable record of that request.
For clients who are themselves registered, whether as a broker-dealer or as a registered investment adviser, that recordkeeping matters, because your own obligations follow the order flow even when the infrastructure is ours. This page describes what we record, how it is protected, and how long we keep it.
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.
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:
| Field | What it establishes |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------ |
| Resolved order payload | The exact instruction as Anthid understood it: symbol, side, type, quantity, limit and stop prices, time in force, and routing strategy |
| Organization and account | Which client instructed the order, and which trading account it was for |
| Action type and sequence | Whether the instruction was a create, replace, or cancel, and its ordered position in that intent's lifecycle |
| Ingress timestamp | When the instruction arrived at the Anthid edge, recorded independently of when it was written to storage |
| Write timestamp | When the record was committed |
| Client reference | Your own correlation identifier, carried through unchanged |
| Credential | Which of your credentials instructed the order, and of what kind: an API key, a signed-in user, or an Anthid service acting on your behalf |
| Request identifier | Correlates the record to the single request that produced it |
| Client address | The calling address as reported by the edge proxy |
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.
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](/pages/controls/overview) 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:
| Field | What it establishes |
| -------------------------------------- | ---------------------------------------------------------------------------------- |
| Scope and kind | Which level the control sits at, and whether it is a manual, risk, or time control |
| Sequence | The change's ordered position in that control's history |
| Fields set | The values the change asserted, exactly as you supplied them |
| Fields cleared | The limits the change removed, each named explicitly |
| Credential | Which of your credentials made the change, and of what kind |
| Request identifier and idempotency key | Correlates the change to the request that carried it |
| Client address | The calling address as reported by the edge proxy |
| Arrival and write timestamps | When the request reached the edge, and when the record committed |
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.
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:
| Stage | What it means |
| --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `CONTROLS` | Your own configured trading controls stopped the order. The record carries the specific controls that triggered, which is the same detail the caller received. |
| `ENTITLEMENT` | The caller was permitted, but the plan does not cover what was attempted, such as live trading on a live account. |
| `AUTHORIZATION` | The caller lacked permission to submit, or named a trading account belonging to a different organization. |
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.
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.
## Changes to connections and credentials
Connecting a broker account, disabling one, rotating a key, and deleting a connection are recorded the same way, on append-only streams carrying the same attribution as an order.
A connection's current state is derived from those events rather than held as a row that each change overwrites, so its history is not lost to its latest state. Deletion is a tombstone on the stream rather than the removal of a row. The secret itself is destroyed, while the record that the connection existed, and of who removed it and when, remains.
The same separation applies to organizations. Deletion is recorded distinctly from an administrative suspension, so a deleted organization and a temporarily disabled one are no longer indistinguishable after the fact.
## Data protection
Order records are scoped to the organization that created them, and that scoping is enforced by row-level security policies in the database rather than by application code alone. Broker credentials are held encrypted, separately from trading workflows, and are never stored in plaintext by Anthid.
See [Security](/pages/about/security) for the platform's security model, including how credentials are encrypted, how tenant isolation is enforced, and what is captured about the caller behind every change.
## Questions
Compliance requirements vary by firm, registration type, and business model. If your firm needs specifics about Anthid's recordkeeping to complete a vendor review or satisfy a supervisory requirement, contact [support@anthid.com](mailto:support@anthid.com).