Why a Trading Strategy Is Only 10% of a Trading System

Trading content naturally focuses on the strategy: the pattern, model or rule that decides when to buy and sell. In production, that decision is one component inside a much larger control system.

“Ten percent” is not an industry measurement. It is a useful provocation: if nearly all engineering attention goes into the signal, the system is probably ignoring the parts that prevent a good idea from becoming a bad position.

The minimum production path

At a high level, a trading system turns market data into orders:

venue data → parser → normalized state → strategy → risk → gateway → venue

Then it must close the loop:

venue responses and fills → account state → monitoring → reconciliation → strategy and risk

Headlands’ Quantitative Trading Summary outlines a similar separation across market-data parsers, strategies, order gateways, monitoring, capture, simulation and reconciliation. Its examples come from established quantitative firms rather than a retail crypto stack, and its 2017 details require current verification. The architecture remains a helpful checklist.

Market-data ingestion

The feed layer connects, authenticates where needed, subscribes, parses messages and detects continuity failures. A normalizer maps venue-specific products and event formats to internal types.

It should answer:

• Is the connection healthy?
• Which snapshot and updates define the current state?
• Has a sequence gap occurred?
• How old is the last valid event?
• Which instrument and venue does this symbol represent?

A stale feed should not quietly leave the last price on screen as though it were current.

Strategy and feature computation

The strategy reads bounded state and emits a structured proposal. It should not own unrestricted credentials or silently change risk limits.

For reproducibility, record the strategy version, parameters, feature version, model identifier, decision time and exact input version. A decision without provenance cannot be replayed reliably.

Independent risk controls

Pre-trade risk checks the proposed order against account state and policy. It may cap size, exposure, turnover, price distance, leverage and loss. It should reject malformed or stale requests by default.

Post-trade risk watches the position that actually exists, not the one the strategy intended. It detects concentration, unexpected fills, liquidation proximity and account mismatch.

The system also needs a real kill path: block new orders, cancel open orders where possible, revoke signing authority and alert an operator. Telling the strategy to “please stop” is not enough.

Order gateway and state machine

The gateway maps a validated order to venue-specific fields, signs or authenticates it and records the request. The state machine follows acknowledgment, rejection, resting, partial fill, fill, cancellation and expiration.

Network uncertainty creates ambiguous states. If a request times out, the gateway must query by a unique identifier instead of assuming failure or blindly duplicating the order.

Market-data capture and replay

Captured raw data allows the team to reconstruct what the strategy saw. It supports:

• incident analysis;
• deterministic replay;
• training/inference comparisons;
• data-quality audits; and
• testing new logic against recorded stress.

Retention must respect licensing, privacy and storage constraints. A parsed candle alone is rarely enough to diagnose an order-level failure.

Monitoring is not a decorative dashboard

Useful monitoring alerts on state requiring action:

• feed invalid or stale;
• internal and venue positions disagree;
• repeated rejects or authentication failure;
• unexpected latency;
• open orders after a strategy stops;
• loss, exposure or turnover limit reached; and
• recovery action failed.

A green status light is meaningful only if the underlying check is specific, current and independently testable.

Reconciliation closes the evidence loop

Reconciliation compares internal orders, fills, fees, balances and positions with authoritative venue records. It should run after reconnects and periodically during operation.

Consider a cancellation sent while an order is filling. The local system may record “cancelled” from its request path while a fill arrives through another stream. Only comparison with final venue state resolves the position.

Operations and recovery

Systems restart. Credentials expire. Exchanges enter maintenance. Networks partition. Production design must document startup order, safe default state, dependencies, backoff, manual intervention and recovery after partial failure.

The operator should be able to answer:

• What is running?
• What positions and open orders exist?
• Which data is valid?
• Which component owns the next action?
• What must be reconciled before restart?

What can go wrong?

• Strategy and risk calculate positions from different fill streams.
• Restart scripts place orders before account reconciliation.
• Monitoring reports process health but not data validity.
• A simulator and production gateway interpret order types differently.
• Secret rotation breaks cancellations but not market data.
• Logs omit the model or parameter version behind a decision.

What this does not prove

More components do not automatically make a safe system. Complexity creates new failure modes. The goal is explicit responsibility, narrow authority and auditable state—not architecture for its own sake.

Next: Why Bitcoin Trades Differently on Every Exchange.

Trading system FAQ

Why is a strategy only one part of a trading system?

A signal cannot trade safely by itself. Production also requires valid market data, independent risk, venue-specific execution, state tracking, monitoring, recovery and reconciliation.

What is the basic path through an automated trading system?

Venue data is parsed into normalized state, the strategy creates a proposal, risk validates it and a gateway sends it. Fills then update account state and monitoring.

What should a market-data layer detect?

It should detect disconnections, sequence gaps, stale events, invalid snapshots and incorrect instrument mappings instead of silently preserving an obsolete price.

Why should trading risk controls be independent?

Independent controls can reject malformed, stale or oversized requests even when the strategy or model is wrong, manipulated or unavailable.

What does an order state machine track?

It tracks submission, acknowledgment, rejection, resting, partial fills, fills, cancellation and expiry so uncertainty does not create duplicate or unmanaged orders.

Why capture raw market data?

Raw point-in-time data supports incident investigation, deterministic replay, data-quality audits and comparison between tested and production behavior.

What should trading-system monitoring alert on?

It should alert on stale data, account mismatches, rejects, authentication failures, abnormal latency, lingering orders, breached limits and failed recovery actions.

What is reconciliation in automated trading?

Reconciliation compares internal orders, fills, fees, balances and positions with authoritative venue records, especially after reconnects or ambiguous events.

What is a trading-system kill switch?

It is an independent path that blocks new orders, cancels open orders where possible, disables signing authority and alerts an operator.

Does adding more components make a trading system safe?

No. Extra complexity creates failure modes. Components help only when responsibilities, authority, state and recovery behavior are explicit, narrow and testable.

Risk disclosure: Automated trading systems can create or compound losses faster than manual workflows. Risk services, monitoring and kill switches reduce some operational hazards but cannot eliminate market, venue, protocol or custody risk. This article is educational and not investment advice.