A system is bigger than its strategy

An automated trading system is the entire path that turns market state into a reconciled portfolio state. The strategy decides what it wants. The system decides whether that action is allowed, how it should be executed and whether reality matches the instruction.

This is the distinction from a generic trading bot: the bot may be one execution component. The system includes data provenance, model versions, risk policy, identity, custody, monitoring and recovery.

AData planeNormalize, timestamp and validate market and account state.
BDecision planeGenerate a typed signal or target portfolio.
CPolicy planePermit, reject or resize the proposed action.
DExecution planeRoute orders and handle venue responses.
EControl planeReconcile, monitor, alert, pause and recover.

The reference control architecture

1. Market and account state

Data must be timestamped, normalized and checked for gaps. The system also needs balances, open orders, positions, collateral and venue health. A strategy acting on market prices alone can create an order that conflicts with the portfolio it actually owns.

2. Typed intent

The decision layer should output a constrained intent—not arbitrary executable code. A typed intent might specify instrument, direction, target exposure, time horizon and confidence. Keeping decision and execution separate makes review and policy enforcement possible.

3. Independent policy

The policy layer checks venue, asset, function, size, leverage, slippage, concentration and timing. These controls should not disappear merely because an AI model is confident. Rejected intents are evidence too: they show whether the safety boundary is active.

4. Restricted execution

The executor should expose only approved actions. It handles order type, price limits, retries, idempotency and partial fills. A failed request must not be blindly repeated if the first order might already exist.

5. Reconciliation and recovery

Internal state must be compared with venue or on-chain state. Disagreement triggers a defined path: stop new risk, cancel orders, reduce exposure, alert an operator or move to a safe mode.

Minimum operational controls

  • Maximum position, order, leverage and daily-loss limits
  • Approved assets, venues, adapters and callable functions
  • Stale-data and abnormal-price rejection
  • Idempotent order creation and duplicate detection
  • Partial-fill and one-leg exposure handling
  • Emergency pause and permission revocation
  • Immutable decision, policy and execution logs
  • Versioned models, strategies and configurations

Testing sequence

StageWhat it establishesWhat it does not establish
Unit and simulationRules behave under constructed cases.Live data and venue behavior.
Historical backtestPast-data hypothesis under assumptions.Future returns or live fills.
Paper/testnetWorkflow and integration behavior.Production liquidity and capital risk.
Shadow modeReal-time decisions without execution.Order impact and actual fills.
Limited liveProduction behavior at bounded exposure.Performance at scale or in every regime.

Read backtests versus live results before treating stages as interchangeable.

How to evaluate a platform

Ask for the system boundary, not merely the model description. Who supplies the data? Where are risk limits enforced? Who holds custody? What record survives a failure? Can the user exit? Which claims are independently inspectable? If those answers are unavailable, more AI vocabulary does not repair the missing operational evidence.

That same boundary is what separates a marketing page from a real AI trading app evaluation. Strategy-specific readers can branch to trend following, AI scalping or funding-rate arbitrage.

Sources and scope

This reference architecture is an editorial control model, not a certification of any product.