Direct Answer
A parent order is the OMS's representation of trading intent, "buy 500,000 shares of MSFT." It is never sent directly to a venue. Instead, the EMS creates child orders from it: smaller slices routed to individual exchanges, dark pools, or algorithms. Fills from children roll up to the parent, updating its aggregated filled quantity and volume-weighted average price. Position changes occur at the account level and are driven by fills, not orders.
The parent-child model exists to solve a practical problem: large institutional orders cannot be routed in full to a single venue without causing significant market impact. Splitting them into children, each sized to blend into normal market volume, allows the aggregate order to execute at better prices while presenting a manageable size to each venue. Managing this decomposition, tracking the rollup, and maintaining accurate position records throughout the process is a core OMS/EMS responsibility.
Key Takeaways
- Parent orders are aggregation units: The parent is never routed to a venue. It exists to give the trader a single view of overall progress on a large execution mandate.
- Child orders are venue instructions: Each child is an instruction to a specific venue (or an algo that selects venues) to execute a specific quantity on specified terms.
- Fills update parents via rollup: When a fill arrives against a child, the OMS updates the child's filled quantity and average price, then recalculates the parent's aggregated view.
- Position updates use fills, not orders: Position records are updated by fills. The existence of an open order does not change the position; only an executed fill does.
- Average price is quantity-weighted: Parent average price = Σ(fill_qty × fill_price) / Σfill_qty across all children. This must recompute correctly as each new fill arrives.
- Child rejection returns quantity to parent: A rejected child does not cancel the parent. It makes that quantity available for re-routing via a new child.
- Nesting can be multiple levels deep: In some architectures (e.g., a multi-broker program trade), a buy-side parent spawns broker-level children, each of which spawns venue-level grandchildren. Each level tracks its own filled quantity and passes fills upward.
- Care orders are single-child special cases: A broker-worked order is typically represented as a single child with the broker as the counterparty; all fills the broker reports roll up to that one child, then to the parent.
Core Concepts
The anatomy of a parent order
A parent order in the OMS carries: a unique order identifier, the instrument (symbol, ISIN, or CUSIP), side (buy or sell), total quantity, order type (market, limit, or algo), an optional limit price, the set of accounts it belongs to (for block orders), the compliance status, the creation timestamp, and running totals of filled quantity, average fill price, and remaining open quantity.
The parent's state changes as children are created and filled. Initially it is "open" with zero filled quantity. As children execute, its filled quantity grows and its average price updates. When filled quantity equals total quantity, the parent transitions to "filled." At any point the trader can cancel the remaining open quantity, transitioning unfilled children to cancelled and the parent to "partially filled" or "cancelled" depending on how much was executed.
Testing the parent model means verifying that the parent's filled quantity and average price are exactly correct after every fill event, including edge cases: fills that arrive out of order (a fill for a child that was sent earlier arrives after a fill for a child sent later), fills that arrive after a child was cancelled (in-flight fills that the venue executes before the cancel reaches it), and bust events that retroactively remove a fill from the aggregate.
Evidence to retain: every change to the parent's filled quantity and average price should be logged with the triggering fill event's identifier, so the OMS can reconstruct how the parent reached its current state from its fill history.
How children are created and managed
Children are created by the EMS based on the execution strategy. A VWAP algorithm might create one child every 5 minutes, each sized to approximate the expected market volume in that interval. An implementation shortfall algorithm might create larger children when the market is moving unfavorably. Direct-to-venue routing creates one child per venue, with the size split determined by the router's real-time liquidity assessment.
Each child carries a reference to its parent order ID, a unique child order ID, the child's quantity and destination, and its own state (pending, open, partially filled, filled, cancelled, rejected). The child's FIX ClOrdID (client order ID) is what the venue and EMS use to track it. The parent order ID is the OMS's internal identifier and is not sent to venues.
Child management requires handling several concurrent states simultaneously. A parent can have multiple open children at the same time, three children routed to three different venues in parallel. If one venue fills quickly and another moves slowly, the EMS must manage the remaining quantity across the still-open children, potentially cancelling a slow venue and re-routing to a faster one without double-counting quantity.
The key invariant: at any moment, the sum of (each child's open quantity) plus the parent's total filled quantity must equal the parent's original order quantity. If this invariant is violated, the OMS has a quantity leak, some shares are neither filled nor outstanding, which will cause a position discrepancy.
Aggregating fills to the parent
Fill aggregation is the mechanical process by which child-level fills become parent-level statistics. When a fill arrives: (1) the OMS finds the matching child by ClOrdID; (2) it validates the fill, checking that fill_qty does not exceed the child's remaining open quantity and that the ExecID is not a duplicate; (3) it updates the child's filled_qty and average_price; (4) it recalculates the parent's filled_qty and average_price.
The average price recalculation: new_avg_price = (old_avg_price × old_filled_qty + fill_price × fill_qty) / (old_filled_qty + fill_qty). This incremental formula avoids recomputing the entire fill history on each event. It is mathematically equivalent to the batch formula but requires careful handling of the initial case (first fill) where old_filled_qty is zero.
In practice, the OMS stores both the running sum (Σ fill_price × fill_qty) and the running quantity separately, computing the ratio only for display or reporting. Storing the ratio directly introduces floating-point precision loss across hundreds of fills.
Position impact at the account level
Positions are not held at the parent order level, they are held at the account level. When a fill is received, the OMS must determine which account or accounts the fill belongs to and update their position records accordingly. For a single-account order. This is trivial. For a block order representing multiple accounts, it requires consulting the allocation schedule that was set up when the parent was created.
In the most common implementation, allocations for a block order are determined at order entry (before execution begins) as a set of account proportions. As fills arrive, they are allocated in real time using the predetermined proportions. The sum of shares allocated to all accounts from a given fill must equal the fill quantity, no shares can be unallocated. Rounding remainders are managed by the allocation engine, typically by assigning the remainder to the account with the largest proportional share.
The position update itself must be atomic: the fill and the position change are written in a single transaction. A system that records the fill without updating the position, or updates the position without recording the fill, creates an immediately inconsistent state that will fail reconciliation and make crash recovery non-deterministic.
Nesting and multi-level hierarchies
Some trading architectures require more than one level of parent-child nesting. A program trade (a basket of 200 securities executed simultaneously across multiple brokers) might be structured as: a program-level parent, broker-level children (one per broker handling their portion of the basket), and venue-level grandchildren created by each broker. The buy-side OMS may only see the broker-level children; the grandchildren are internal to the broker's systems.
Multi-level nesting complicates fill reporting. When the broker reports a fill, is it a fill for a specific broker-level child order, or is it a partial report that represents the aggregate of multiple venue executions? The OMS must have a clear contract with each broker about what fill granularity they will report and must process it consistently. FIX execution reports can include an "average price" fill that aggregates multiple underlying executions, the OMS must decide whether to store the aggregate or request individual fills.
Worked Scenario
A trader enters a 300,000-share buy order for NVDA in the OMS. The EMS routes it via a VWAP algorithm targeting 20% market participation over 3 hours.
- Parent created: OMS generates parent order P-001: NVDA, Buy, 300,000 shares, VWAP algo. Parent state: Open. Filled: 0. Remaining: 300,000.
- First child created: EMS creates child C-001 for 50,000 shares, routed to NYSE Arca. ClOrdID: C-001. Parent-ref: P-001.
- First partial fill: NYSE Arca fills 30,000 shares at $875.40. ExecReport arrives. OMS validates ExecID is unique. Updates C-001: filled=30,000, avg=$875.40, remaining=20,000. Updates P-001: filled=30,000, avg=$875.40, remaining=270,000.
- Second child created: EMS creates C-002 for 60,000 shares to EDGX dark pool. Parent-ref: P-001.
- C-001 completes: 20,000 more shares at $875.65. OMS updates C-001: filled=50,000, avg=(30,000×875.40 + 20,000×875.65)/50,000 = $875.50, state=Filled. Updates P-001: filled=50,000, remaining=250,000. Running Σ: 30,000×875.40 + 20,000×875.65 = $43,775,000.
- C-002 fills: 60,000 at $876.10. OMS updates C-002: filled=60,000, state=Filled. Running Σ for P-001: $43,775,000 + 60,000×876.10 = $96,341,000. P-001 filled=110,000, avg=$96,341,000/110,000=$875.83 (rounded). Remaining=190,000.
- Algorithm continues creating children: C-003, C-004 fill over the next 2 hours, ultimately bringing P-001 to 300,000 filled across 7 child orders at a final average of $876.22.
- Position update: Each fill updated the relevant account positions in real time. The block's allocation (70% Fund A, 30% Fund B) was applied to each fill, so Fund A's NVDA position increased by 210,000 shares at the weighted average across its allocated fills, and Fund B's by 90,000 shares.
Measurement Framework
| Measurement | Question it answers |
|---|---|
| Parent quantity integrity | At every point in time, does Σ(child open qty) + parent filled qty = parent original qty? Any discrepancy is a quantity leak. |
| Average price precision | Does the OMS's stored average price match the independently computed Σ(fill_qty × fill_price) / Σfill_qty across all fills? Test after every 100 fills in a load test. |
| Fill-to-position latency | How long between fill receipt and position update? Must be <100ms for equities; longer lags cause real-time risk limits to use stale position data. |
| Duplicate fill rejection rate | How many fills are rejected as duplicates per day? A nonzero rate indicates FIX session recovery issues that need investigation. |
| Orphaned child rate | How many child orders per week have no fills and no cancellation, sitting open indefinitely? These indicate missing cancel acknowledgments or FIX session drops. |
| Allocation residual frequency | How often does the allocation engine assign a fractional share residual, and to which account? Track to ensure rotation fairness and detect systematic bias. |
Common Failure Modes
Quantity over-routing
If the EMS creates children without checking the parent's remaining open quantity, it can route more shares than the parent originally specified. This happens when a child cancel is in-flight but a new child is created before the cancel acknowledgment arrives, the EMS believes the parent has X remaining, but the unacknowledged cancel means there are actually only X minus the cancelled child's quantity available.
Prevention requires the EMS to reserve quantity at child creation time, not at fill receipt time. The parent tracks "allocated to open children" separately from "filled." A new child can only be created for quantity not already allocated to an existing open child.
Average price corruption from out-of-order fills
If fills arrive out of order (fill at time T+2 arrives before fill at time T+1) and the OMS uses the arrival order to update its running average, the intermediate average price will be wrong. While the final average price after all fills arrive will be correct, any risk system or compliance check that reads the intermediate price may act on incorrect data.
The running incremental formula works correctly regardless of fill arrival order, the final weighted average is the same. The issue is intermediate consistency. If a compliance check fires between two fills and the check uses the current average price as an input, it must read a point-in-time consistent value, not a partially-updated one from a concurrent write.
Fill-without-order (phantom fill)
Occasionally the OMS receives a fill execution report for a ClOrdID it does not recognize. This can happen if a child was created by the EMS but the OMS's record of that child was lost (due to a crash or replication lag). The fill cannot be booked against a child because no matching child exists. The OMS must queue such fills for manual review and must not silently discard them, a discarded fill means a missing position entry.
Recovery: the operations team identifies the parent order, manually creates a reconciling fill record, updates the parent and position, and files an incident report. The root cause is almost always a persistence failure or replication lag in the OMS child-order creation path.
Child cancel creating negative open quantity
When a child cancel arrives after a fill for that child has already been credited to the parent, the cancel might attempt to restore quantity that no longer exists in the open state. If the OMS blindly restores the cancelled child's original quantity to the parent's remaining, it may push remaining above original quantity, allowing more children to be created than are valid.
Correct logic: a cancel only restores the child's current remaining quantity at the time of cancellation (not its original quantity). If the child partially filled before the cancel, only the unfilled portion is returned to the parent.
Broker-side care order fill discrepancy
When a buy-side order is worked by a broker as a care order. The broker may report fills as an aggregate average-price report rather than individual venue fills. If the buy-side OMS expects individual fills and the broker sends aggregate fills, the OMS's fill count, position update logic, or compliance checks may fail. The OMS and broker must agree on fill reporting granularity before any care order is placed.
Frequently Asked Questions
What is a parent order in an OMS?
A parent order is the high-level representation of trading intent in the OMS, for example, buy 500,000 shares of MSFT for a set of accounts. It is not routed directly to a venue. Instead, the EMS creates child orders from it, smaller slices that are sent to individual venues or algorithms. The parent tracks the aggregate filled quantity and average price across all its children.
How does the OMS compute average price at the parent level?
The OMS computes the weighted average fill price across all child fills: sum(fill_price × fill_quantity) / total_filled_quantity. This calculation must update atomically with each fill event. As fills arrive from multiple venues at different prices and times, the running average price converges toward the volume-weighted average execution price.
Can a parent order span multiple accounts?
Yes. Block parent orders represent aggregated intent for multiple accounts. The parent tracks total quantity and fills. After execution, the OMS allocates fills to individual accounts, each of which gets a position update at the block's average price. The parent-level view is an aggregation artifact; account-level positions are what actually feed P&L, compliance, and reporting.
What happens to a parent order if a child is rejected?
When a child order is rejected by a venue, the parent's open quantity increases by the rejected child's unexecuted quantity, returning it to an executable state. The OMS or trader can then decide whether to re-route that quantity via a different child order. The parent order does not automatically cancel if a child is rejected, it waits for instructions on the unfilled quantity.
How are child orders created, manually or automatically?
In most institutional setups, child orders are created automatically by the EMS's algorithms. The EMS receives the parent order from the OMS and applies a slicing strategy, VWAP, TWAP, POV, that determines when and how many shares to route to each venue. Traders can intervene manually to override the algorithm's slicing decisions, creating or cancelling children directly.
What is the difference between a child order and a fill?
A child order is a unit of routing intent, an instruction to a venue to execute a certain quantity. A fill is the confirmation that some quantity was actually executed at a specific price. One child order may generate multiple fills (partial executions at different prices) or no fill at all (if it is cancelled or expires). Fills are the permanent record; orders are transient.
How does parent-child nesting affect position calculation?
Position calculations use fills, not orders. The OMS updates position when a fill is received, regardless of which child order generated it. The parent-child relationship is used for aggregation and reporting (showing the trader a consolidated view) but not for position accounting. Each fill has an account designation that determines which position record it updates.
What is a care order and how does it relate to parent-child?
A care order (also called a worked order or DMA order) is a parent order that is handed to a broker for them to work, using their judgment and tools to execute at a favorable price. The broker may create their own internal child orders. From the buy-side OMS's perspective, the entire broker-worked order is a single child; fills reported back by the broker are booked against that child, which rolls up to the buy-side parent.
How should a cancel or amend request applied to a parent propagate to its children?
A parent cancel usually means canceling every working child and stopping further child generation, and the parent should not reach a terminal state until each child has confirmed. Amendments are harder: reducing a parent quantity below what children have already filled is not achievable, and reducing it below the working child quantity requires deciding which children to cut. Defining these rules explicitly avoids a parent that reports canceled while a child is still live at the venue.
References
- FIX Protocol 5.0 SP2 Specification: Defines order hierarchy, ExecType values, and fill reporting fields including CumQty, AvgPx, and LeavesQty.
- SEC Rule 10b-10 (17 CFR 240.10b-10): Confirmation of Transactions: Requires accurate average price reporting in trade confirmations for block orders.
- FINRA Rule 5310: Best Execution: Governs how broker-dealers must handle orders, including child order routing decisions.
- ESMA Report on MiFID II Algorithmic Trading: Covers order lifecycle requirements for algorithmic order-slicing under MiFID II.
Educational Disclaimer
This guide is for educational purposes only and does not constitute financial, legal, or compliance advice. OMS implementations vary significantly by vendor and firm. Consult qualified professionals before designing or modifying order management systems with regulatory implications.