The Append-Only Audit Log on a Systematic Trading Desk
Pull-quote: “Limits are tunable. History is not.”
Why this matters
Ask a desk what happened during an incident and you get memories. Ask what the risk engine decided at 10:47, under which limits, and who changed what afterward, and you either get an audit log or you get archaeology. The difference decides whether the desk improves or merely survives. The remedy is a standing rule: every state-changing action lands in an append-only audit log with actor and reason attached. Every cap applied, every breach, every override. The log is not compliance decoration. It is the desk’s memory, and the improvement loop runs on it.
What append-only actually means
Append-only is a stronger commitment than keeping logs. Entries are never edited and never deleted. A correction is a new entry referencing the old one. A limit change is an entry. The review that justified the limit change is an entry. What this buys is simple: the record you review later is the record written at the time, not a version of events that survived tidying. Post-hoc reconstruction drifts toward the outcome. A contemporaneous record cannot.
What goes in
| Event class | Recorded with | Review question it answers |
|---|---|---|
| Cap applied | Strategy, cap, requested vs allowed size | Are caps set where behavior actually lives? |
| Limit breach | Limit, observed value, action taken | Which boundaries are doing real work? |
| Operator override | Actor, reason, scope, duration | Are exceptions rare, reasoned, and bounded? |
| Parameter change | Old value, new value, review reference | Did the change follow the process? |
| Promotion or demotion | Stage, criteria, evidence reference | Are strategies earning their capital? |
| Daily reconciliation | Position, cash, P&L against records | Does the engine’s world match the real one? |
The common thread: each entry captures what was known and decided at write time. That is what makes later review honest.
The loop that makes it worth the discipline
action ──► risk decision ──► append entry
│
▼
periodic review
(caps, breaches, overrides)
│
▼
process change, new limits
│
▼
logged as new entries ──► repeatThe log exists so this loop can run on evidence. Which caps fire weekly and which never fire: both are design feedback. A cap that fires constantly is mis-set, or the strategy underneath it has drifted. A cap that never fires may be theater. Overrides are the richest signal of all: requiring a reason at write time changes behavior in the moment, and patterns of overrides mark the places where the coded process and the real process disagree. That seam is where the next incident is already scheduled, and the log is how you find it first. The same record makes external scrutiny uneventful: when a counterparty or an auditor asks how the desk actually operates, the answer is a query, not a slide deck assembled from recollection.
Not the same thing as observability
Traces and metrics are for debugging: verbose, sampled, and expiring on a TTL, which is correct for their job. The audit log is the record: one entry per decision, written synchronously on the decision path, kept for the long term. The two answer different questions on different clocks, and merging them is how completeness quietly dies. The trace tells you why the system was slow on Tuesday. The log tells you who loosened the cap on Thursday, and what reason they gave.
Closing
An append-only audit log will not make any strategy smarter. It makes the desk smarter, which compounds longer. Record every cap, breach, and override with actor and reason, review the record on a cadence, change the process in writing, and let the log capture that too. Limits are tunable. History is not. That asymmetry is the entire design.