The trade execution workflow is the sequence of steps an order follows once it leaves the Order Management System (OMS) — the system of record for order state — and enters the Execution Management System (EMS), the front-office platform traders use to route, monitor and complete that order in the market. This article follows that sequence step by step, from order staging through to the fill data that closes the loop into Transaction Cost Analysis (TCA), and focuses on what a trader actually does, decides and controls at each point.
Executive Summary
What: the execution workflow covers everything that happens to an order between its arrival in the EMS and its return to the OMS as a completed or partially completed fill, including staging, market data enrichment, tactic selection, slicing, monitoring, exception handling and post-trade review.
How: the order is validated, enriched with real-time market data, worked according to a chosen execution method (manual, Direct Market Access, algorithmic, or Smart Order Routing), and reconciled back against the parent order before it is handed back for allocation and settlement.
Who: execution traders, algorithmic desks and compliance teams rely on this workflow being visible, controllable and auditable, since each step feeds the best-execution record required under frameworks such as MiFID II.
This piece assumes familiarity with what an EMS is and how its core components work. For a definition of the platform itself, see What Is an Execution Management System (EMS)? A Complete Guide; for a broader look at EMS mechanics, see How Execution Management Systems Work. What follows is the order’s actual journey through those components, from the trader’s chair.
How Does an Order Move From the OMS to the EMS?
An order moves from the OMS to the EMS as a FIX message: the Financial Information eXchange (FIX) protocol is the industry-standard messaging format used to transmit order instructions, amendments and execution reports between trading systems. The OMS releases the order once it has passed portfolio-level checks (cash, position limits, mandate restrictions), and the EMS receives it as a staged order awaiting execution. On arrival, the EMS runs its own pre-trade validation, typically pre-trade risk controls such as maximum order size, price collars and duplicate-order checks, before the order becomes visible on the trader’s blotter. This staging step is where the audit trail begins: the timestamp of receipt, the instructing OMS, and the state of any risk checks applied are logged as the first entries in the order’s execution record.
Enriching the Order With Real-Time Market Data
Once staged, the order is enriched with the market data needed to make an execution decision: current bid/ask, depth of book, recent trade prints, and, for algorithmic strategies, historical or real-time volume curves. This enrichment step is what separates a static order sitting in a blotter from a workable order a trader can act on. An EMS built for multi-asset flow needs venue-level and instrument-level data across every market it connects to. Quod’s EMS connects to 80+ execution venues and exposes 150+ configurable variables, and the breadth of that connectivity footprint determines how much market context an order can carry before it is worked.
Choosing an Execution Tactic: Manual, DMA, Algo or SOR
With the order staged and enriched, the trader selects how it will be worked. Four broad tactics cover most institutional flow:
- Manual execution: the trader places and manages individual orders directly, typically for smaller size or illiquid names where automated slicing offers little benefit.
- Direct Market Access (DMA): the order is sent straight to a chosen venue under the trader’s control, with pre-trade risk checks applied but no algorithmic pacing logic involved.
- Algorithmic execution: a pre-built or custom execution algorithm, such as a Volume-Weighted Average Price (VWAP), Time-Weighted Average Price (TWAP), Percentage of Volume (POV) or Implementation Shortfall strategy, takes over pacing and sizing according to a defined objective.
- Smart Order Routing (SOR): a routing engine decides, order by order or slice by slice, which venue to send each piece to, based on configurable rules and real-time liquidity conditions rather than a single destination chosen upfront.
These tactics are not mutually exclusive: an algorithmic strategy typically hands each child order to an SOR layer for venue selection, so the choice a trader makes is really about which combination fits the order’s size, urgency and liquidity profile. Whichever tactic is selected, the reasoning behind it (urgency, benchmark, venue preference) becomes part of the best-execution record for that order.
What Does a Trader Actually Control During Execution?
A trader working an order through an EMS controls three things directly: how the order is sliced, what happens while it is in flight, and how exceptions are resolved. Everything else (market data delivery, venue connectivity, fill reconciliation) is handled by the platform.
Parent and Child Orders
Once a tactic is chosen, the original instruction becomes the parent order, and the EMS or algo engine splits it into smaller child orders sized and timed according to the selected method. The trader sets or confirms the parameters that govern this slicing, such as urgency, participation rate or a fixed schedule, but the mechanical splitting itself is automated. Every child order retains a traceable link back to its parent. That link is what allows the full order to be reconstructed later for reporting.
Monitoring and In-Flight Intervention
While child orders are being worked, the trader monitors progress against the chosen benchmark: how much has filled, at what average price, and how the order is tracking against its objective. This is the point where trader judgment matters most. A trader can pause an order, adjust its parameters — for example increasing urgency ahead of an anticipated news event — or switch to a different algorithm entirely if market conditions no longer match the original assumptions. None of this happens automatically; it requires the trader to read the market and intervene, and each intervention is time-stamped as part of the order’s record.
Fills, Amendments and Exceptions
As child orders execute, fills come back from venues and are reconciled against the parent order in real time. Not every fill is clean: partial fills, rejects, and amendments (a price or size change on a working order) are routine, and the trader is responsible for resolving them, whether that means re-routing an unfilled remainder, cancelling a stale child order, or escalating a venue-side reject. This exception handling is where fragmented or poorly integrated setups tend to create the most friction, since resolving an exception often requires visibility the trader does not have if order state, market data and routing logic sit in separate, loosely connected systems.
The Trade Execution Workflow Step by Step
| Workflow step | Trader action | System action | Best-execution control point |
|---|---|---|---|
| Order staging | Reviews the order as it arrives from the OMS | EMS receives it via FIX and applies pre-trade risk checks | Timestamped receipt anchors the audit trail |
| Market data enrichment | Reviews live quotes, depth and volume context | EMS attaches real-time price, liquidity and volume-curve data | Market conditions at decision time are captured |
| Tactic selection | Chooses manual, DMA, algorithmic or SOR-driven execution | EMS surfaces available venues, algos and routing options | Rationale for the chosen method is logged |
| Parent/child slicing | Sets or confirms slicing parameters (size, pace, urgency) | Algo engine or EMS splits the parent order into child orders | Parent-to-child links preserved for reconstruction |
| In-flight monitoring and intervention | Watches progress; can pause, re-parameterize or switch algo | EMS streams live execution status and flags deviations | Each intervention is time-stamped and attributed |
| Fills, amendments, exceptions | Resolves partial fills, rejects and amendments | EMS reconciles fills against the parent order in real time | Exception handling is documented for compliance review |
| Hand-back to OMS | Confirms the completed or partially completed order | EMS returns fill data to the OMS for allocation and settlement | Fill data is matched to the original order instructions |
| TCA feedback loop | Reviews execution quality against the chosen benchmark | TCA module benchmarks fills against Arrival Price, VWAP or other references | Outcome is measured against a documented best-execution benchmark |
Closing the Loop: From Hand-Back to Transaction Cost Analysis
Once an order is complete, or the trader closes out a partially filled remainder, the EMS hands fill data back to the OMS. This hand-back is what lets the order proceed to allocation across underlying accounts and, ultimately, settlement. It depends on fill records being matched cleanly to the original order instructions, and that match is only reliable if parent-to-child links were preserved throughout execution. Quod’s OMS supports 1,800+ configurable workflows, which is where a desk models how completed and partially completed orders are handed back, matched and allocated.
The workflow does not end at settlement. Fill data also feeds Transaction Cost Analysis, which benchmarks the realized execution against reference points such as Arrival Price — the market price at the moment the order was released for trading — VWAP or the pre-trade estimate, and produces the evidence a desk needs to demonstrate best execution under MiFID II or equivalent regimes. This is the step that turns a single order’s execution record into a pattern the desk can review, question and improve over time.
Where Does the Trade Execution Workflow Break Down in Fragmented Setups?
The workflow described above assumes order state, market data, routing logic and post-trade analysis all reference the same underlying order record. In practice, that assumption fails most often at the seams between systems: when a trader has to reconcile fills manually across an OMS, a separate EMS and a standalone TCA tool, each with its own view of the order, or when a change made mid-execution — such as switching algorithms or amending an order — does not propagate cleanly to every system tracking that order.
Common failure points include:
- Broken audit continuity: if the parent-child link is not preserved across systems, reconstructing an order’s full history for a best-execution review becomes manual and error-prone.
- Delayed exception visibility: a reject or partial fill that surfaces late, because it has to travel between disconnected systems, gives the trader less time to react.
- Stale market data at handoff points: if enrichment happens in one system and tactic selection in another, the data informing the decision can be seconds or more out of date.
- Inconsistent TCA benchmarks: when execution data and TCA run on separate platforms, reconciling which fills belong to which order can introduce gaps in the evidence trail.
None of these failure points are guaranteed outcomes of using multiple systems; they are risks that grow with the number of handoffs and the quality of the integration between them.
Important: The workflow itself does not guarantee a particular execution result or price; outcomes depend on prevailing market conditions, the parameters chosen at each step, and how well the underlying systems stay synchronized, and nothing in this article should be read as investment advice or a promise of execution outcome.
How Quod Supports the Trade Execution Workflow
Quod Financial’s Unity architecture is designed to keep the steps described in this article inside a single, auditable workflow rather than split across systems that each hold a partial view of the order. Orders staged from the Order Management System (OMS) arrive in the Execution Management System (EMS) with the same order identifiers preserved end to end, so parent-to-child relationships, in-flight interventions and exception resolutions stay traceable back to the original instruction. Tactic selection draws on the same environment as Algorithmic Trading, with 20+ pre-built algorithms configurable through 150+ parameters, and Smart Order Routing (SOR), configurable across 450+ parameters and 80+ connected venues, so a trader can move between manual, algorithmic and SOR-driven execution without leaving the platform or losing order context. For a closer look at how routing decisions are made once an order is being worked, see How Smart Order Routing Works Inside an EMS.
When execution is complete, fill data hands back into the OMS for allocation, with order identifiers preserved from staging through to allocation, and flows through to TCA and Best Execution Reporting for post-trade review. Because staging, execution and reporting run on the same Unity integration layer, desks get one execution record per order instead of reconciling several. That supports the kind of audit trail regulators expect under MiFID II best-execution requirements.
Run the Full Execution Workflow as One Auditable Record
To see how Quod’s OMS, EMS, SOR and algorithmic execution run as one auditable workflow on Unity, contact the Quod Financial team or request a demo.
Frequently Asked Questions
What is the difference between an OMS and an EMS in the execution workflow?
The OMS is the system of record for order state, mandate compliance and allocation; it holds the order before and after execution. The EMS is the front-office platform where the order is actually worked in the market, from tactic selection through fills. In the workflow described here, the order moves from OMS to EMS at staging and back to OMS at hand-back.
What is a parent order and a child order?
A parent order is the original instruction released for trading. A child order is one of the smaller pieces that instruction is split into during execution, whether by an algorithm, an SOR engine, or manual slicing. Each child order retains a traceable link back to its parent, which is what allows the full order to be reconstructed for reporting.
Can a trader change the execution tactic mid-order?
Yes. A trader monitoring an order in flight can pause it, adjust its parameters, or switch to a different algorithm if market conditions no longer match the original assumptions. This kind of intervention is a normal part of the monitoring step, not an exception, though it is logged as part of the order’s execution record.
What happens when a child order is only partially filled?
A partial fill is reconciled against the parent order in real time, and the trader decides how to handle the unfilled remainder, whether that means re-routing it, adjusting its parameters, or leaving it working. Partial fills are routine in execution, particularly for larger orders worked over time.
How does the FIX protocol fit into the execution workflow?
FIX, the Financial Information eXchange protocol, is the messaging standard used to transmit order instructions, amendments and execution reports between the OMS, the EMS and external venues. It is the transport layer underneath most of the steps described in this article, including staging, routing and fill reporting.
Why does the hand-back from EMS to OMS matter?
The hand-back is what allows a completed or partially completed order to proceed to allocation across underlying accounts and settlement. It depends on fill data being matched cleanly to the original order instructions, which in turn depends on parent-to-child links being preserved throughout execution.
How does Transaction Cost Analysis fit into the execution workflow?
TCA is the step that closes the loop after hand-back: it benchmarks the realized execution against reference points such as Arrival Price or VWAP and produces the evidence a desk uses to review execution quality and demonstrate best execution to regulators or clients.
Does following this workflow guarantee best execution?
No. The workflow structures how an order is staged, worked and reviewed, and produces the audit trail needed to demonstrate a best-execution process, but it does not guarantee a specific price or outcome. Results depend on market conditions, the parameters selected at each step, and the quality of the underlying execution tools.