Trading System Architecture: Market Data, OMS, Risk and Execution

System boundaries

Market data describes observations; strategy code turns observations into an intent; the OMS tracks order identity and lifecycle; the risk engine checks limits; the execution adapter translates an approved command; reconciliation compares local state with provider snapshots. Keep these boundaries visible in code and in logs.

Data flow

Quotes / bars → Strategy context → Trading intent → Risk decision → Approved command → Provider order → Receipts → Reconciliation

Every transition should carry an account, environment, instrument identity, revision, timestamp, and evidence reference.

Trade-offs

• A shared canonical model reduces application complexity but must preserve provider-native details.
• Strong consistency is expensive at the edge; use durable state and explicit eventual-consistency recovery.
• More adapters improve coverage but increase contract and conformance-test cost.

Failure modes

Do not let a missing symbol mapping silently route to another venue. Do not treat a timeout as a rejected order. Do not rebuild positions only from local events. These shortcuts create duplicate orders and silent drift.