Market-data layer
Normalise symbols, timestamps, sessions, missing data, corrections, and live-feed behavior before strategy logic consumes the input.
Start a project ↗Trading Technology / Published 2026-09-06
Architecture of an Algorithmic Trading System: Research to Live Execution
A practical architecture for separating market data, research, strategy logic, risk, execution, state reconciliation, and monitoring.
01 / Direct answer
Separate research, decisions, execution, and supervision.
A robust algorithmic trading platform should make market data, strategy decisions, risk controls, execution state, and monitoring explicit. Combining all responsibilities into one opaque process makes both validation and live incident handling harder.
Strategy layer
Encapsulate the rules, models, state, and parameters that transform validated inputs into proposed trading decisions.
Risk layer
Apply pre-trade and runtime limits independently of strategy intent so invalid size, exposure, session, loss, or system states can stop an action.
Execution layer
Translate approved decisions into broker or venue instructions while tracking acknowledgements, fills, rejections, cancellations, and reconciliation.
02 / Research parity
Backtests are useful only when assumptions are visible.
Historical results depend on data quality, timestamps, fill logic, cost assumptions, parameter selection, and the way the research environment represents live behavior. Those assumptions should be documented and challengeable.
Data provenance
Record provider, dataset, schema, symbol mapping, trading calendar, and any cleaning or transformation applied before the strategy sees the data.
Execution model
State how orders are filled, how spread and fees are represented, and which latency, liquidity, or queue effects are excluded from the simulation.
Evaluation separation
Keep development, calibration, and final evaluation data appropriately separated so strategy choices are not repeatedly optimized against the same evidence.
Reproducibility
Persist code version, configuration, input-data identifiers, and result artifacts so an experiment can be rerun and audited later.
03 / Live operations
The production system must handle states the strategy never predicted.
Live automation can encounter stale data, disconnects, broker rejections, partial fills, mismatched positions, delayed messages, or infrastructure failure. Operational design determines whether those events become controlled incidents or uncontrolled exposure.
State reconciliation
Compare internal order and position state with the execution provider and define how mismatches are detected, escalated, and resolved.
Kill conditions
Define conditions that stop new risk when data, connectivity, account state, loss, or system health falls outside approved limits.
Monitoring
Expose feed health, decisions, orders, positions, risk events, provider errors, and infrastructure health to authorised operators.
No performance guarantee
Correct engineering can improve reproducibility and operational control, but it cannot guarantee that a strategy will remain profitable as markets, execution, and relationships change.
Related and sources
Continue into the capability or supporting primary sources.
Use these related pages to understand the capability in more detail and move through the site by subject rather than by generic navigation.
Need this applied to a real project?
OPEQ can help translate the engineering principles into a project-specific architecture, implementation plan, validation approach, and production workflow.
Discuss your project ↗