Order Management
Execution Engine Overview
SpiderRock Connect Execution Engines are at the center of order and execution management within the SpiderRock Connect trading platform. Each engine is responsible for parent and child order handling and adjacent tasks for a subset of the SpiderRock Connect product universe. At present, this product universe is divided into 10 US Equity/Option stripes, 1 CME Future/Option stripe, 1 CFE Future/Option stripe, and 1 EUX Future/Option stripe with stripes and their associated engines located near the relevant exchange matching engine. All execution engines process all of the market data for their product subset regardless of whether resting parent order or client interest exists for a specific product within a subset. As a result, our execution engine topology reflects both geography as well as market data load balancing considerations and is subject to change over time.
Parent Orders
All client orders that enter the SpiderRock Connect execution engines are considered parent orders (from our perspective) regardless of the order source (Tools, SRSE, MLink, or FIX).
All SpdrParentOrders have a primary key (parentNumber:long) that is assigned by SpiderRock Connect and is globally unique (for about 6 months). A new parent order (and its new parentNumber) will start a parent order chain that can have one or multiple "links". Modifying an order will add a new "link" to its parent order chain and each "link" (order modification) will have its own unique parentNumber. Each SpdrParentOrder has a corresponding SpdrParentReport record that is published by the execution engine handling the parent order. This record, along with any SpdrParentExecution associated with the same parentNumber, contains the complete state for one link in a parent order chain. These records, in combination, contain all of the details necessary to (re)create either a FIX parent order drop replay stream or a FIX execution only drop stream. They also contain all of the details necessary to generate the SpiderRock Connect side's CAT reports.
On arrival, a SpdrParentOrder message will create (or modify, if it already exists) a ParentBroker and its' parent order chain. If a ParentBroker does not exist already, a new arriving SpdrParentOrder will be considered as the beginning of an order chain. If a parentBroker does exist, the new SpdrParentOrder will update the existing ParentBroker, thus creating a addition parent order link in the order chain. The parent number of the first link in the chain become the baseParentNumber for the chain and is used to represent the entire chain. SpdrParentOrders contain the ParentBroker primary key fields (accnt, clientFirm, secKey, secType, orderSide, spdrSource, and groupingCode) within the body of the SpdrParentOrder message.
For clients that wish to operate longer running algos, SpiderRock Connect provides SpdrParentLimit messages. These records contain many of the same fields that are found in the SpdrParentOrder messages. If a SpdrParentOrder allows for 'delegation' to a SpdrParentLimit (uses a SpdrLimitType=Aux) then fields in the SpdrParentLimit record will take precedence over those found in the SpdrParentOrder message. This is advantageous because SpdrParentLimit records can be accepted and processed at much higher rates that SpdrParentOrder records and do not cause excessive FIX cancel/replace transactions when creating downstream drop copies.
Child Orders
The execution engine, upon receiving a SpdrParentOrder message, will then create a set of child orders according to the parameters set in the original and corresponding SpdrParentOrder. All child orders are limit orders and SpiderRock Connect controls all cancel/replace actions for child orders. The SpdrParentOrder is the set of instructions that will dictate the limits of the child orders and the child orders themselves are the orders sent to the exchange.
Spreads vs Singles
SpiderRock Connect execution engines are capable of handling parent order for single items (stock, future, or option) or spread (up to 6 legs + 1 stock leg). The algos for handling spreads are slightly different than those for single instruments but are roughly analogous in most respects.
Arrival Actions
A ParentBroker goes through a number of steps to validate the newly arriving parent order and activate it for child order generation including:
| Action | Description |
|---|---|
| Validation | Check user permissions for the account and clientFirm of the parent order. |
| Arrival Risk | Check MAR, supervisory (client), and global/soft arrival limits. |
| Route Check | Check for available market routes and build child order routing trees. |
| StageReview | (Only valid for stage review clients.) Initiate any stage review sequence with the appropriate client or sponsor order routing gateway. |
| Cancel/Replace | If necessary, cancel any open child orders that are no longer valid and promote remaining to the new parent order / parent report pair. |
| Activate | When all pending actions complete (if any) attach appropriate algo handler(s) and activate the ParentBroker. If part of a risk group and arrival staging is active wait until the group is complete and activate the entire group as an arrival optimized package. |
When successfully activated, a ParentBroker will begin generating child orders according the instructions attached to the most recent parent order in the order chain.
ParentBrokers will close on user cancel, order expiry, or if/when filled.
Cancelling Orders
ParentBrokers and all associated child orders can be cancelled by sending one of the following:
| Message | Description |
|---|---|
| SpdrParentCancel | Cancels a ParentBroker by parent number. Can be any parent number in the chain, including the baseParentNumber |
| SpdrFixParentCancel | Message generated by FIX gateways when a client cancels a FIX order |
| SpdrBrokerCancel | Cancels a ParentBroker by ParentBroker primary key (accnt, clientFirm, secKey, secType, orderSide, spdrSource, and groupingCode) |
| SpdrAccntCancel | Cancels all ParentBrokers by SpiderRock accnt/clientFirm |
| SpdrUserCancel | Cancels all ParentBrokers by SpiderRock user ID |
| SpdrRiskGroupCancel | Cancels all ParentBrokers by riskGroupID |
ParentBroker State Records
In addition, at regular intervals, execution engines publish SpdrParentBrkrState and SpdrParentBrkrDetail records that contain current state for each active (single instrument) ParentBrokers as well as SpdrMLegBrkrState records that contain state and markup details for all active (multi-leg) ParentBrokers. These records contain information (eg. current effective limit prices, TCA execution markup, risk control state, etc) not usually found in simpler FIX execution reports.
Order Execution
Execution Algorithms
SpiderRock Connect's execution algorithms, or more specifically, parent order handling frameworks, are the engine components primarily responsible for creating and canceling child orders. The most commonly utilized frameworks are ActiveTaker and ActiveMaker which can operate either individually or in combination. The ActiveTaker framework will generate child orders that take liquidity only and ActiveMaker will generate child orders that provide liquidity only. Some parent order instructions are designed to generate at most one child order while others can create and cancel many child orders over time as related markets move around.
These frameworks can be used for equities, futures, and options as well as spreads and are the underlying handlers for our longer running progression algo family.
With the introduction of the SpiderRock ATS, active taker handlers are also capable of initiating flash auctions in some circumstances. In addition, both our active maker and active taker frameworks are capable of responding to a SpiderRock ATS auction as well as all exchange or other ATS originated auctions.
We also have special purpose order handling frameworks that can place child orders in exchange open/closing auctions, perform coordinated cross market sweeps, and execute other specialized order actions.
At a higher level, our engines also feature several types of multi-step progression algos that work parent orders over time utilizing single purpose frameworks at each step. Examples include the VWAP, TWAP, and SpiderPulse as well as Seeker and Legger (spreads) algo families.
See our ExecutionAlgo guide for more details.
Street Gateways
SpiderRock Connect operates street-side order gateway servers located between our execution engines and the various exchange and market access points. These street gateways are responsible for routing child (exchange or broker) orders and quotes either directly to exchange matching engines and other alternative trading systems or to other market access brokers for forwarding.
These gateways can also preemptively cancel (contingent cancel) child orders in exchange order books if market data based signals breach a contingent trigger threshold. Similarly, they can send pre-cached child order to take liquidity (contingent create) based on either related market data or child fill events. All contingent triggers are set and managed by SpiderRock Connect systems and are transparent to users. Contingent trigger based pathways are the fastest latency paths in the SpiderRock Connect platform and are generally only used in situations where latency of action is of high importance.
The latency hierarchy of actions that might occur with respect to the handling of child orders in exchange order books is:
| Action Source | Typical Latency Range | Range of possible actions |
|---|---|---|
| Parent Orders (External Systems) | 1 - 100 ms | Almost any type of trading strategy that has a time horizon of seconds or longer |
| Parent Orders (Internal Systems) | 1.0 - 2.0 ms | Specific trading strategies coded into SpiderRock Connect systems |
| Child Orders (Execution Engine) | 0.25 - 1.0 ms | Child order create and cancel events associated with execution engine algo handlers |
| Child Orders (Contingent Triggers) | 5 - 10 us | Child order trigger-cancel or trigger-create buffer flush operations |
Child Order Flow Control
SpiderRock Connect execution engines are usually capable of generating child orders (much) faster than downstream systems can consume them. This is especially common when simultaneously managing large numbers of orders in option markets with active/volatile underlying securities and tight cancel/replace child order thresholds.
In order to successfully manage orders in this type of environment SpiderRock Connect utilizes a sophisticated child order flow control design that classifies and prioritizes child order flow to ensure that immediate high priority cancel bandwidth is always available under normal operation at the potential cost of delaying creation of new child orders. This acts to protect down stream systems from queuing or rejecting child orders and cancels during market bursts, both of which can adversely affect execution quality.
To mitigate the impacts of this type of flow control, SpiderRock Connect monitors its own exchange connectivity pool and adds capacity as necessary and also works with downstream brokers to ensure sufficient capacity on order handling sessions in which SpiderRock Connect does not control the last leg of the exchange routing path.
Legging Orders
Spread orders (multiple stock, future, or option legs) can be worked as a spread legging package with a common limit price. There are two forms of order legging within the SpiderRock Connect trading platform:
(a) The first is directly implemented in our execution engines but has a restriction that all legs in the spread package must be from a common product group (ticker).
(b) The second moves the order legging activity out of our executions engines into a specialized strategy server that generated parent orders targeting any of our execution engines. This second form can manage spread legging packages with legs from any product group, including product groups that are in different global geographies.
With either form of legging clients can specify a lead leg as well as whether any of the legs should be posted in exchange order books and worked 'out loud' or held in SpiderRock Connect systems until leg alignment is observed. Clients are also able to specify a specific amount of slippage to be used, only if necessary, to complete a leg package.
Contingent Pair Trading
In the near future, SpiderRock Connect is planning to introduce contingent pair trading (a form of fast legging) in which a child order is placed in an exchange order book and 'tied' to the market of a dependent leg. If the depended leg market moves, the 'leaning' child order will be cancelled using our contingent cancel trigger. Similarly, fills that arrive for the 'leaning' child order will trigger a corresponding contingent order to be created. Both cancel and create latencies should be less than 10 μs (plus exchange latency) if both legs are targeting the same exchange matching engine. We plan to introduce this new type for order handling for any pair (stock vs stock, stock vs future, future vs future, options vs any) across all SpiderRock Connect integrated markets.
Exchange Auction Responding
SpiderRock Connect is capable of processing auction notices from a number of exchanges and venues, including SpiderRock's own ATS. Clients with resting (usually active making) parent orders can be set to auto-respond to these auction notices. Clients can also listen for notices from our MLink/Websocket API and directly respond by sending parent orders set to respond to a specific auction notice IDs. Clients can also respond by establishing auction auto-responders (eg. AutoResponderVegaDir) that will generate automatically generate parent orders in response to auction notices.
For more information see our AuctionResponder guide.
Away Order Routing
SpiderRock Connect's execution engines can also route child orders to away systems and algorithms on client request.
AutoHedging
Option executions (whether from our execution engines or away systems) can be configured for auto-hedging. In general, auto-hedging falls into one of two categories:
(a) Strategies that hedge each individual option fill immediately and minimize any slippage (typically used with dynamic order limits that 'lean' on one side or the other of a hedge target market), or
(b) Auto-hedging strategies that act somewhat slower and simultaneously hedge groups of option orders with a common hedge target.
The first strategy will typically result in small and consistent slippage between option fill and hedge target fill but will also (usually) trade the maximum quantity of the hedge target and have a high percentage of take fee paying executions. The second strategy will have more variation in slippage (sometimes positive, sometimes negative) but will trade less of the hedge target and have a better blend of make, take, and lower cost dark pool executions.
Either strategy can be implemented with the SpiderRock Connect platform.
See our AutoHedging Guide for more details. The AutoHedging Guide is coming soon.
TCA Metrics
We have an extensive set of TCA metrics that we capture for all parent and child orders. These metrics include PnL from parent arrival to fill, PnL from fill to fill+1m, fill+10m, and fill+EOD, underlier and hedge target slippage and order handling metrics such as total seconds active at SpiderRock Connect, seconds on exchange, child create and cancel latencies, percentage time on market, percentage time alone, total shares, or contracts traded (from print reports) while active, etc.
These metrics (and others) are available in our SpdrParentExecution and SpdrParentBrkrState records as well as our SpdrChildOrderSummary records.
See our TCA Metrics Guide for more details. The TCA Metrics Guide is coming soon.
Execution Risk Controls
Execution Risk Counters
The SpiderRock Connect execution engines maintain a collection of risk counters for all orders and executions handled by the engine. These risk counters are used with MAR and Supervisory risk controls as well as parent order RiskGroupID controls to constrain the generation of child orders. ParentBrokers continually check all risk counters and their associated risk controls to establish a Minimum Available Risk Size (size to the most restrictive risk limit) while they are active. This available risk size value becomes an upper bound on the size of any child order generated by the system and can potentially result in a resting child order being immediately cancelled if they no longer have enough risk size to fill the balance of the child order.
Integrated MAR Risk Controls
Up to four sets of MAR risk control records typically exist for each clientFirm and account in the system. The first of these record sets is under the exclusive control of SpiderRock Connect and its existence is required for any order handling to proceed. Any MAR risk control record following the first record is optional. The second level of MAR risk controls can be set and controlled by the client and the third and fourth levels of MAR risk controls can be under the control of the client's prime broker or sponsor.
MAR risk control records contain restrictions on the parent order size as well as an account's or a ticker's total margin and contracts.
Parent orders are rejected if they violate a parent order arrival constraint from any of the MAR risk control sets. Once an associated ParentBroker is active, all potential child orders are constrained by all related MAR risk control records.
Integrated Supervisory Risk Controls
Clients can, in addition to MAR risk controls, establish firm specific supervisory risk controls. These controls focus on accounts and product groups and allow share-, contract-, and greek-based constraints.
Parent orders are rejected if they violate a parent order arrival constraint from a supervisory risk record. Additionally, the size of all associated child orders will also be constrained by the relevant supervisory risk controls (if any).
Risk Group Controls
Parent orders and associated ParentBrokers can be part of an account RiskGroup (RiskGroupID + Accnt). If associated with a RiskGroup, all child orders that would be generated by a ParentBroker are constrained by the RiskGroup controls established by the parent order.
RiskGroup control values can be supplied on individual parent orders (RiskGroupID and the risk group control fields are parent order parameters) or they can be established by SpdrRiskGroupControl live-data objects (parent order contains a RiskGroupID and the associated SpdrRiskGroupControl message contains the control levels).
For more information on the above topics, please see our Execution Risk Control documentation.
Compliance Controls
Integrated Compliance Controls
The SpiderRock Connect execution engines have integrated compliance controls that minimize the risk of most types of compliance mistakes. We force all child orders selling stock short to have valid locates (or be sent to a downstream broker that is performing a locate check).
Self-Trade Checks
SpiderRock Connect monitors to ensure no client firm is trading with itself.
Selling Stock
We have three methods of determining whether a stock child order should be marked long or short.
(a) The first method is simply that the client directly tells us that a parent order is to sell stock either long or short. In this case, we will mark all child orders according to client instructions.
(b) The second method is automated and requires clients to load and maintain positions (or at least 'stub' positions if actual positions are large) within our platform. Clients can notify us with their chosen automation method of away trading and order activity and we will keep track of all SpiderRock Connect facilitated executions and exchange child orders. We will then mark each individual child order as either long or short based on our records at the time of the child order generation.
(c) A third method is built into our StageReview handling of parent orders. With this method, when a parent order arrives we initially place it in a stage review hold state and send a simple equity child order to either a client or sponsor order routing gateway. This gateway then performs both a risk check and short sale check on the order. If successful, the order is forwarded (back) to SpiderRock Connect and acts to both release the parent order from its stage review hold state and transfer its sell long/sell short markup to the parent order. Any child orders generated from this reviewed parent order are then marked long or short as instructed.
Regardless of the underlying technique used, any child order deemed a sell short order will be required to have a locate or be forwarded to a downstream system capable of performing a locate check. Locates can be loaded at the start day or during the trading day. In some circumstances, a client can submit a request for a locate to SpiderRock Connect and SpiderRock Connect will forward that request to the client's prime broker on its behalf.
Properly managing the compliance issues involved in selling stock can be involved and we work with clients and sponsors to find solutions. Please contact us at our Client Support Desk for additional assistance.
Market Data Considerations
The SpiderRock Connect execution engines directly process low-level market data multicast feeds where possible. In general, market data handling latencies within our execution engines are very low and we can process market data at very high rates.
Please see our Market Data guide for additional information. The Market Data guide is coming soon.
Embedded Exchange Simulators
Our execution engines feature exchange simulators that attempt to accurately replicate expected market behavior. Any order sent to one of our exchange engines that is for a T.XXXX trading account will route child orders to one of our simulated exchanges. We generally allow clients to do a (limited) amount of testing or practice trading in this fashion to better understand the behavior of our algorithms in an environment that is as close to real market behavior as possible. This is designed to increase knowledge of SpiderRock Connect's trading workflows and behaviors.