Audit Trail & Compliance
Every trading decision, parameter change, and system event in TRADEOS.tech is permanently recorded in a tamper-evident ledger. This is not a logging feature — it is a core architectural component.
The ledger
All position records and trading decisions are written to an HMAC SHA-256 append-only hash chain. Each entry in the ledger contains:
- A unique entry ID (ULID — time-ordered, globally unique)
- A UTC timestamp
- The event type (
POSITION_OPEN,POSITION_CLOSE,INTENT,FILL,REJECTION,SYSTEM_EVENT) - The event payload (JSON)
- An HMAC-SHA256 hash of this entry chained to the previous entry's hash
The chaining means that modifying any historical record breaks every subsequent hash in the chain — making tampering immediately detectable.
What is recorded
| Event | Ledger entry |
|---|---|
| Trade intent generated | Intent payload, signal source, confidence score |
| Feasibility verdict | Verdict (APPROVED/REJECTED), rejection reason, gate that rejected |
| Order placed | Order ID, venue, symbol, size, direction |
| Order filled | Fill price, fill size, venue, timestamp |
| Position closed | Exit reason (stop, target, timeout, manual), realized P&L |
| Risk limit breach | Which limit, current value, threshold, action taken |
| Profile change | Old profile, new profile, operator identity |
| Autonomous agent action | Parameter changed, old value, new value, trigger condition |
| Circuit breaker activation | Breaker type, trigger value, activation time |
HMAC key management
The HMAC signing key is stored in HashiCorp Vault, not in code, configuration files, or environment variables. It is a 256-bit key generated at initial deployment. Ledger writer processes have read-only access to the key. No application code ever sees the raw key value — it is retrieved from Vault at startup and held in process memory only.
Continuous verification
The ledger is not just written — it is continuously verified:
- Periodically, a rolling window of recent entries is re-verified in the background
- Full chain verification runs on a scheduled daily cycle
- Verification can be triggered on demand via
scripts/verify_ledger.py - Any chain break is immediately published to the
risk.eventsstream and surfaced on the dashboard
Regulatory posture
The ledger is designed to meet the record-keeping requirements of:
- MiFID II — immutable, time-ordered records of all trading decisions and orders
- SEC Rule 17a-4 — tamper-evident electronic records for broker-dealers
- CFTC Part 1.31 — audit trail requirements for derivatives trading
Auditors can verify chain integrity using the HMAC key escrowed to them, without requiring access to the production system.
Immutability guarantees
The ledger database schema grants no UPDATE or DELETE permissions to application users. Records can only be appended. Even an operator with database access cannot modify or delete a historical ledger entry without breaking the hash chain — and the break would be detected rapidly by continuous background verification.
On-chain attestation
For public, permissionless verification of signal activity, TRADEOS.tech also publishes a daily Merkle root of all signal outcomes to Base L2. See On-Chain Signal Attestation for how to independently verify that a specific signal existed on a specific day — without any access to the production system.
Autonomous agent audit trail
The autonomous agent is subject to additional audit requirements. Every parameter change proposed or applied by the agent is recorded with:
- The metric that triggered the proposal (e.g., a win rate or IC value that fell below the acceptable threshold)
- The current value of the metric
- The parameter being changed
- The old value and proposed new value
- Whether the change was applied or deferred
- A rollback hash that can be used to revert the change
This means every autonomous adaptation is fully traceable and reversible.