Risk & governance.

The single most important design decision in an AI trading system is that risk controls do not live inside the language model. They are deterministic, version-controlled, enforceable outside the model prompt, and independently verifiable at every checkpoint.

Section IPrinciples

• Risk rules are explicit, version-controlled and enforced in code. Start conservative; modify only through a recorded governance process.
• The risk engine can approve, reduce or veto any proposed order. A language model may explain a risk decision, but never override it.
• Every decision must be reproducible from stored inputs, calculations, policies and approvals.
• Broker credentials sit only with the restricted execution service — not with research agents, not with the risk engine.

Section IISix groups of controls

Section IIIMandatory kill-switch conditions

Any one of these conditions must halt trading immediately, regardless of what the system otherwise wants to do:

1. Broker position differs materially from the internal ledger.
2. Required market data is stale or unavailable.
3. Unexpected orders or duplicate submissions are detected.
4. A daily loss, drawdown or exposure limit is breached.
5. The execution service cannot verify the active policy and approval versions.
6. System clocks, authentication or audit logging are unreliable.

Section IVAudit and reproducibility

Language-model output is not deterministic even at temperature 0 — Anthropic’s and OpenAI’s own documentation confirms this. Audit trails cannot rely on bit-exact reproducibility of LLM output. What they can rely on:

• Inputs: every market-data snapshot, filing, news article and prior state that fed a decision, with source and timestamp.
• Model version: exact model identifier, temperature, top-p, tool-list, prompt hash. When a vendor deprecates a model, snapshot the swap.
• Deterministic calculations: everything the deterministic risk engine computed — position size, drawdown check, exposure delta — recorded exactly.
• Approvals: identifiers for research, validation, risk and human approvals; each with an expiry.
• Order lifecycle: submission, acknowledgement, fills, fees, slippage, reconciliation.

An append-only decision log is the simplest way to make this real. Postgres tables with insert-only permissions, or a WORM object store, both work. The requirement is that no agent, admin or process can rewrite history.

Section VModel governance

The FSB’s October 2025 monitoring paper (P101025) named model drift and vendor-hosted deprecation as core vulnerabilities. Vendor-hosted models get silently updated or fully retired; your backtest may not re-run in six months. Practical controls:

• Pin exact model IDs in production. Watch vendor deprecation calendars. Palmyra-Fin’s July 2026 EOL is the current cautionary case.
• Log every prompt version with a hash. Never let a prompt change reach production without a review record.
• Track look-ahead bias: run backtests with pretraining cutoffs strictly before the backtest window. Sarkar & Vafa (SSRN 4754678) and Glasserman & Lin (arXiv 2309.17322) empirically show LLM predictions carry future-knowledge leakage.
• Calibrate confidence: keep a rolling record of stated confidence vs realised hit-rate per confidence band. Recalibrate quarterly.
• Version the risk policy as code, in Git. Every deployed order carries the policy version identifier it was approved under.

---

Next: Regulatory boundary →