Order Staging
SpiderRock Connect execution engines and OMS/EMS tools support a form of order staging (workflow staging) in which parent orders are submitted in a state in which they are initially held (activeOrderSize = 0) pending action by a user to modify and/or release them before they become working parent orders. This workflow process can be used by a user staging orders to themselves for future action or by a ControlParty user staging an order to a ModifyParty user for the ModifyParty user to later activate and release into the market.
Note that this process is separate from a StageReview sequence which allows a client firm or their sponsor to perform and automated risk review of parent orders before they become active.
Control and Modify Parties
The two primary parties involved in staging an order are the Control Party and the Modify Party.
The Control Party refers to the original account submitting the order into SpiderRock Connect’s system. The source of the order can be a SpiderRock Connect Tool (SV or TradeTool) or an order entered via MLink, SRSE, FIX. The Control Party is responsible for setting an order’s hard parameters such as:
• item or spread
• order side
• total order size
• total order duration
The control party has permissions to:
• Create a new order
• Cancel/replace and existing order
• Cancel an existing order
The Modify Party can be considered the opposite of the Control Party. They are either from the same client firm as the Control Party’s account or are a FINRA-licensed broker such as SpiderRock's Concierge Desk. The Modify Party is not capable of changing the original order’s hard parameters but they are capable of modifying:
• Active order size
• Active order duration
• The order execution algo.
When an order is received by SpiderRock Connect’s system, it will have a total order size that has been set by the Control Party but its active order size will be set to zero. The same is true for the order’s total duration and active duration. When either of these two dimensions are set to zero, the order will be in a “hold” state which allows the Modify Party to then review the order and then selectively decide when the next slice of the order should be activated, how long that slice should be live for, and when alive, which algo should determine its behavior in the marketplace.
If an order fills up to it's active size (but not to it's total order size) it will go back to a "hold" state as there is nothing more to do. Alternatively, the Modify Party can reduce the active size of an order to zero to return it to a "hold" state. If an order fills to it's entire total order size then the complete order will be closed (Filled) or if an order reaches it's total order duration it will also be closed (Expired) and a terminal order status will be returned to the Control Party.
The Modify Party can then work the order slice by slice until the original order’s size has been filled completely or until it has been terminated by the Control Party.
| Party | Summary |
|---|---|
| Control Party | Sets the original order’s parameters Responsible for creating, cancelling, or replacing orders |
| Modify Party | Has limited modification capabilities Cannot change the order item, order size, or total order duration Can adjust algorithm settings, active order size, and active order duration |
Order Workflow
Step One: Order Entry
An account submits a new order which is passed through client gateways and into SpiderRock Connect’s Execution Engine.
The order has the total order size, the activeSize set to 0, and the stageType set to Modify.
Step Two: Order Handling
A Parent Broker State Record is created and passed through the system to appear in the Trade Tool.
If the order is being sent to the Concierge Desk to be staged, a User Proxy Record will also be created so the Concierge Desk’s broker will not receive any confidential client information beyond what is necessary to complete the stage review.
Step Three: Order Modification:
Within SpiderRock Connect's Trade Tool, users belonging to the Modify Party will be able to view the actions they have permissions for and from the tool, and adjust the order parameters at their discretion.
The orders will then work within the specified active sizes and active durations until the original order is filled or terminated.
- Note: Stage Review Checks are triggered by changes in the total size of an order or during cancel/replace operations. These checks are also activated when an order previously marked as closed is reawakened.
Market Session Handling
According to client instructions, orders are assigned to market sessions (pre-market, regular market, or post-market).
SpiderRock Connect’s Execution Engine will create and submit the Market-on-Open and Market-on-Close orders before either Market Open or Market Close in order to participate in the relevant auction. Otherwise, simple orders are eligible for pre-market sessions with start times and good-till times managed by SpiderRock Connect.
Order Lifecycle and Termination
Orders have a final reaping time, typically five minutes after the regular good-till time of the relevant exchange. SpiderRock Connect aims to receive cancel acknowledgments from exchanges within this window. A Control Party can explicitly set start and good-till times which would take precedence over session-derived times.
Active and Effective Order Duration
The active duration of an order can be modified by the Control or Modify party. The Execution Engine recalculates order start and good-till times based on the effective duration, ensuring proper order handling.