OMS / EMS
OMS / EMS Architecture & Reconciliation
Manage order state, fills, and position integrity.
Order management and execution management systems sit at the operational core of any institutional trading desk. This curriculum covers the full lifecycle: how orders are created, routed, filled, allocated, and reconciled, and what happens when any step goes wrong. From the OMS/EMS boundary to end-of-day break management, every concept is grounded in how production systems actually behave.
What this hub covers
An Order Management System tracks portfolio intent, compliance state, allocations, and the full audit trail of every order. An Execution Management System routes those orders to venues, applies algorithms, and receives execution reports in real time. Together, they must maintain a consistent, auditable view of positions, cash, and open orders, a view that must match what the broker, custodian, and exchange each independently report.
This curriculum walks from the conceptual boundary between OMS and EMS through the mechanics of parent-child order models, state machines, average price calculations, and the reconciliation workflows that keep internal records aligned with the outside world. It covers what happens when trades are busted or amended, how systems recover deterministically after outages, and what regulators require in an audit trail. Each guide is written for practitioners who need to build, operate, or audit these systems, not just understand them in the abstract.
Key principles
- System of record clarity: Every position, fill, and order must have exactly one system of record. Ambiguity about which system is authoritative is the root cause of most reconciliation problems.
- State machines over ad-hoc logic: Order lifecycle logic implemented as a formal state machine is auditable, testable, and recoverable. Ad-hoc conditional logic drifts over time and produces ghost orders, phantom positions, and unexplained P&L.
- Reconciliation is not optional: Internal position records will diverge from broker records. The question is whether you discover the break before or after a risk limit is breached or a regulatory report is filed incorrectly.
- Event logs enable determinism: Persisting every order event, not just current state, makes crash recovery deterministic. The OMS replays the log and arrives at identical state, then reconciles against the broker for any fills received during the outage window.
- Fills update positions atomically: A fill and the corresponding position update must succeed or fail together. Partial application, where the fill is recorded but the position is not updated, or vice versa, is among the hardest bugs to detect and correct in production.
- Break classification drives resolution: Not all breaks are equal. A timing break that will self-resolve by end of day requires different handling than a quantity break that indicates a missing fill. Classification at detection time prevents over-escalation and under-escalation.
- Audit trails are distinct from logs: A system log records what the software did. An audit trail records what the business did, order intent, amendments, routing decisions, executions. Regulators want the business audit trail; ops teams want both.
- Corrections propagate retroactively: A trade bust or amendment does not just change today's P&L. It may require restatement of yesterday's positions, cash balances, and risk metrics. The OMS must support retroactive correction, not just append-only recording.
Curriculum: OMS / EMS Architecture & Reconciliation
Ten guides cover the theory and practice of order and execution management from system design through daily operations. Three interactive tools let you simulate reconciliation scenarios, generate operations runbooks, and check OMS state consistency.
Guides
-
OMS vs. EMS: Responsibilities and Boundaries
The conceptual boundary between an order management system (portfolio intent, allocation, compliance) and an execution management system (smart order routing, execution algorithms, venue selection).
Guide
-
Parent and Child Order Models
How institutional OMS systems split a high-level parent order into child orders for routing to venues, tracking aggregated fills and position impact at both levels.
Guide
-
Order, Fill, and Position State Models
The canonical state machine for orders (new, pending, open, partially filled, filled, cancelled, rejected) and how fills update position records atomically.
Guide
-
Average Price, Allocations, and Partial Fills
Computing VWAP across multiple fills, allocating fills across accounts, handling partial fills in a position system, and ensuring allocation fairness.
Guide
-
Intraday Position Reconciliation
Comparing internal OMS position records to broker-reported positions throughout the trading day, detecting breaks early, and the cost of reconciliation delay.
Guide
-
Cash and Buying-Power Reconciliation
Reconciling internal cash ledger against broker-reported settled cash, unsettled proceeds, margin utilization, and buying power, and why these can legitimately differ.
Guide
-
End-of-Day Reconciliation and Break Management
The EOD reconciliation process: position matching, cash matching, pricing differences, break classification, and escalation rules for unresolved breaks.
Guide
-
Corrections, Busts, and Trade Amendments
How exchange-initiated trade busts, DK'd trades, and broker corrections propagate through the OMS, requiring retroactive position and P&L adjustments.
Guide
-
Deterministic Recovery After Outages
Designing OMS recovery to reproduce exact state after a crash or restart: event log replay, idempotent state reconstruction, and broker reconciliation at startup.
Guide
-
Audit Trails and Regulatory Recordkeeping Concepts
What an audit trail must capture (order intent, route, execution, amendments, cancellations), retention requirements, and the difference between an audit trail and a system log.
Guide
Interactive Tools
-
Reconciliation Break Simulator
Simulate a position reconciliation process: enter OMS and broker position snapshots, identify breaks, classify by type, and generate a resolution checklist.
Tool
-
Operations Runbook Generator
Answer prompts about your trading system's architecture to generate a structured operations runbook covering key failure modes and response procedures.
Tool
-
OMS State Consistency Checker
Enter a set of order events and verify that the resulting position and cash state is internally consistent, detecting common OMS state-machine bugs.
Tool
Frequently Asked Questions
What is the difference between an OMS and an EMS?
An Order Management System (OMS) handles the lifecycle of orders from portfolio intent through compliance checks, allocation, and recordkeeping. An Execution Management System (EMS) focuses on the real-time mechanics of how orders reach venues, smart order routing, execution algorithms, and venue selection. The OMS owns the "what to trade and for whom"; the EMS owns the "how and where to execute".
What is a parent-child order relationship?
A parent order represents high-level trading intent, for example, buy 500,000 shares of AAPL across multiple accounts. The OMS breaks this into child orders routed to individual venues or execution algorithms. Fills at the child level roll up to update the parent's filled quantity and average price. Position updates happen at the account level, not the parent level.
What does intraday position reconciliation check?
Intraday reconciliation compares the OMS's internally tracked positions against broker-reported positions throughout the trading day. Breaks, mismatches, can arise from fills that arrived at the broker but were not acknowledged by the OMS, from trade busts, or from timing differences. Catching breaks early reduces the cost and risk of correction.
What is a reconciliation break?
A reconciliation break is a mismatch between what one system believes the position or cash balance to be and what a counterparty or custodian reports. Breaks are classified by type, quantity break, price break, cash break, and by urgency. Some breaks are timing artifacts that resolve by end of day; others indicate real errors requiring manual correction.
What is deterministic OMS recovery?
Deterministic recovery means the OMS can restart after a crash or outage and reproduce exactly the same position, order, and fill state that existed before the failure. This is achieved by persisting every order event to a durable log and replaying that log on startup, combined with a reconciliation check against the broker's current state to catch any fills received during the outage window.
What must an audit trail capture under regulatory requirements?
A compliant audit trail captures the full lifecycle of every order: the original intent, any amendments, routing decisions, execution reports from venues, allocations to accounts, and any corrections or busts. It must be timestamped to microsecond precision where required (e.g., MiFID II clock synchronization rules), immutable once written, and retained for the applicable regulatory period, typically five to seven years depending on jurisdiction and instrument type.