Execution Algorithms
SpiderRock Connect execution algorithms are the collection of behaviors that are possible with SpiderRock Connect SpdrParentOrder messages and their associated execution engine ParentBrokers. These ParentBrokers, in turn, can generate child orders that take liquidity, rest in exchange order books, initiate and respond to ATS auctions, respond to exchange auctions, and interact with other execution venues and systems in a variety of ways.
These execution algorithms are integrated into our OMS/EMS trading tools and can also be accessed programmatically via FIX, MLink or SRSE for clients who wish to build higher level systematic execution and trading strategies using the SpiderRock Connect platform.
Primary and Secondary Order Limits
All of our algo order handling frameworks feature split (primary and secondary) client limit price handling. Clients directly supply the primary limit, either as a static limit or a simple formula based limit (volatility, delta/gamma adjusted, etc). The secondary limit is computed from a combination of an offset the client has supplied and a live fair market value that SpiderRock Connect supplies. The effective limit when creating or canceling child orders is then the combination of the primary and secondary limit.
For example, a BUY order with a primary limit of $1.00 and a secondary offset of +$0.01 with the SpiderRock fair market value at $0.95 would have an effective limit of $0.96 (minimum of the primary and instantaneous secondary limit).
Primary Order Limit
All parent order are required to have a primary client limit. This limit can be expressed in a number of ways, including:
| Name | SecType | Details |
|---|---|---|
| Market | any | Client limit will be set to several increment through the prevailing BBO market. Not available if there is no BBO market or the market is halted. |
| MarketArrival | any | Client limit is set to touch the opposite side of the BBO market on arrival and is not adjusted further. |
| Prc | any | Client limit is the orderPrcLimit value. |
| PrcDe | option, spread | Client limit is initially the orderPrcLimit but then delta/gamma adjusted based on underlier BBO mid-market, orderRefUPrc, orderRefDelta, and orderRefGamma. xRef values will default to SpiderRock values on arrival if not supplied. |
| PrcDeX | option, spread | Similar to PrcDe except the live market reference underlier BBO bid or ask that is most aggressive when hedging. |
| PrcDeT | option, spread | Similar to PrcDe but include a theta (time-decay) component as well. |
| PrcDeP | option, spread | Similar to PrcDe except that the effective limit price cannot become more aggressive than the original orderPrcLimit. |
| PrcDeXT | option, spread | Similar to PrcDeX but includes a theta (time-decay) component as well. |
| PrcDeXP | option, spread | Similar to PrcDeX and PrcDeP. Order is protected by the original orderPrcLimit and is adjusted based on BBO bid or ask instead of mid. |
| Vol | option | Client limit is the price calculated from orderVolLimit using underlier BBO mid-market and SpiderRock default pricing values including years, rate, sdiv, and discrete dividends. Pricing displayed on SR tools will generally match pricing in our execution engines, including if pricing overrides have been applied at the point where the order was created. |
| VolX | option | Similar to Vol except instead of mid-market the live underlier BBO reference value will be the least aggressive of the bid or ask. |
| PrcV | option | Client supplied both orderLimitPrc. Spider computes an implied volatility on arrival from the client orderPrcLimit and treats the order as a Vol type order at the arrival implied vol level. |
| PrcVX | option | Similar to PrcV except the underlier reference is BBO bid or ask instead of mid. |
| RelMid | stock | This limit works in conjunction with the size release Immediate: Limit will be put at mid-market and won't change Fast reset: Limit will be put at mid-market and reset on and off every 15 seconds Slow reset: Limit will be put at mid-market and reset on and off every minute |
| RelJoin | stock | Same as above, but the limit will be on the bid if buying and on the offer if selling |
| RelCross | stock | Same as above, but limit will cross the market |
| RelTurn | stock | Same as above, but limit will turn the market by one price increment |
| UPrcPct | option, spread | effective limit price = uPrcPct * underlier BBO mid-market. |
| PkgNeutral | spread w/stock | effective limit price = orderPrcLimit + 0.01 * stockDir * stockShares * orderRefUPrc |
| RcPrem | rev/con | effective limit price = orderPrcLimit + strikeDir * Strike |
| SynthLimitMM | synthetic | effective limit price = underlier BBO (mid) + orderPrcLimit. |
| SynthLimitBW | synthetic | effective limit price = underlier BBO (best way) + orderPrcLimit |
| SynthLimitWW | synthetic | effective limit price = underlier BBO (worst way) + orderPrcLimit |
| Aux | any | A corresponding ParentLimit is required. Limit details are supplied in that record. |
| NoLimit | any | Client actively declines to supply a limit. This option is generally only valid in special situations. |
If the primary client limit is dynamic (tied to the underlier or other markets) it will be continually recomputed and applied both when creating new child orders and also as a cancel condition for working child orders.
Secondary Order Limit(s)
Parent orders can also have secondary order limits that work along side (in addition to) the client supplied primary order limit. These secondary limits are based on offsets to a SpiderRock supplied fair mid-market value and often used as the more tactile limit control for working child orders in a market.
Secondary limits can be set relative to a SpiderRock surface dynamic volatility model (options only) or relative to a ML based fair market value, or both. Independent secondary limits can be set for ActiveMaker and ActiveTaker algo.
Using a SpiderRock surface volatility model client can express an offset in either premium, volatility, or market width terms (or a combination) for any options market with a valid SpiderRock surface.
Using a SpiderRock ML/probability model clients can specify a secondary limit as a probability [0-1] value where 0.50 = fair mid-market and values greater than 0.50 are more passive (better probability of a positive PnL). The fair market price (0.50) points are computed from ML models designed for each asset class which include information from the market in question as well as related markets and are frequently recomputed. The associated ML probability distribution widths reflect expected market print scatter as well as market drift over relatively short time horizons. As a result, a probability specification of 0.60 would result in an effective limit price that, if executed, would have a 60% chance of being better than the average expected print in the subject market.
All SpiderRock fair market models are statistical in nature and it is not possible to guarantee the performance of any particular order or effective limit. For clients who wish to experiment with these types of orders in a simulated trading context we offer special trading accounts (T.XXX) that allow fake trading with live market data and high quality exchange simulators.
Interlude - Active vs. Passive Making and Taking
Passive limits tend to drift across the natural market and trade at less favorable prices. Active making attempts to move child orders in concert with the natural market and result in more favorable price outcomes. Performance differences between active and passive making is best captured by measuring PnL a short time after each trade.
Passive taking simply crosses the existing market at the time of order arrival and usually pays about half the market spread. Active taking attempts to detect aggressive orders in the marketplace and trade with them as much as possible. Performance differences between active and passive taking are best captured by benchmarking against comparable prints in the market at large.
ActiveTaker Algo Family
(parentOrderHandling = ActiveTaker)
The ActiveTaker algo family instructs a ParentBroker to send child orders that will actively take liquidity only if/when all order conditions are met. If an order is marketable these algo handlers optimize liquidity taking across all available exchanges, including with respect to fees and available liquidity. Active taker orders range from aggressive (take all available liquidity letting as little as possible escape) to passive (wait patiently for a high probability opportunity to take).
ActiveTaker option orders can also, in some circumstances, start flash auctions in the SpiderRock ATS. This is typically to either seek liquidity in wider markets ahead of fully crossing, to seek more liquidity that is available at NBBO, or to attempt to trade at a lower fee that would be required to take liquidity on a public exchange.
ActiveTaker order handling is also a component of our most complex progression algos that break orders up and work them over time.
The following parameters control active taking behavior:
| ReachRule | Description |
|---|---|
| Delayed | The algo waits a few seconds before taking thus giving the posting side an opportunity to generate fills |
| Passive | The algo does not take until the market turns one price increment in the client's favor |
| WeakOnly | The algo only takes liquidity when the opposite side size is less than the average market size. |
| FullSize | This will send the full order size on the taking side of the algo. |
| ISOSweep | Utilizes ISO market code to sweep the market. This can only be used if setup to use ISO. |
| RespondOnly | Orders will only respond to auctions. |
ActiveMaker Algo Family
(parentBalanceHandling = MakerAlgo)
The ActiveMaker algo family instructs a ParentBroker to send resting child orders or quotes into exchange order books. The child orders are never immediately marketable when created within our execution engines and are subject to both primary and secondary limit constraints as well as other ActiveMaker balance handling behaviors. They often include maker size controls that limit their size profile in exchange order books.
ActiveMaker orders range from passive (post orders in an exchange order book behind a fair mid-market value) to aggressive (post orders through a fair mid-market level but behind the opposite touch market price).
ActiveMaker orders can be used in combination with ActiveTaker orders to create hybrid order handling, including at split limit levels. ActiveMaker orders are also a core component of our longer running progression algo.
The following parent order parameters control active making behavior:
| MakerAlgo | Description |
|---|---|
| PostWith | Posts child orders with BBO |
| PostTurn | Join or improve existing markets if there is sufficient limit room to do so. |
| PostImprove | Join or improve existing markets if there is sufficient limit room to do so. In the event of another party turning the market, the order will improve again. Will continue to improve until either a limit is hit or other parties cease improving the market. |
| PostLimit | Post to limit price (primary + secondary/offset) |
| PostWthF | Join existing markets if the size on the join side is at least 25% of the opposite side. Will fade if the ratio between the sides drops below 20%. Designed to prevent your order from being the last at a price. Will use dynamic market sizing to prevent out sizing the prevailing market size. |
| PostImprv | Join or improve an existing market if there is sufficient limit room to do so. Will improve own market periodically (~30 – 60 seconds) if there is sufficient limit room. Will be dynamically sized if the child order would outsize the prevailing market size. |
| PostFlash | Same as post limit, but flashes the order in the market for a 1 second and then is removed from the market. It will only flash if the child order is improving the market. It will flash again at a random time between 45 seconds. |
| PostFlashW | This is as PostFlash, where the order will flash in the market for 1 second, but will post on the bid for the remaining time. |
| PostFlashI | Similar to PostFlash. However instead of posting immediately at on the limit price, the order will first flash one price increment better than the NBBO. With each subsequent flash the algo will further improve. This will continue until the algo has reach the user limit. Like PostFlash, the order will post for 1 second and then go dark (no child orders) for a random time of 45 seconds. At the end of the timer the order will flash the market again. |
| PublicSize | Description |
|---|---|
| Randomize | Will randomize the last 10% of the average market size. |
| MktSize | Uses dynamic sizing, which is the average of the public size on the NBBO and the second best price. |
| FullSize | References the user's full order size. |
| MktSizeA | A will join your order with 25% of the visible market size on the bid/offer. |
| MktSizeB | B will join your order with 50% of the visible market size on the bid/offer. |
| MktSizeC | C will join your order with 75% of the visible market size on the bid/offer. |
| FullSizeR | Will randomize the last 10% of the user's full order size. |
| ExchRule | Description |
|---|---|
| MaxPart | Will pick exchanges to maximize participation. |
| FeeOptimal | Balances receiving rebates with cost of the other side to take liquidity. May not post at the highest rebate exchange in order to get flow. Default for account setting. |
| ImprvOnly | Will only make when improving the NBBO. |
| FeeStrict | Only takes maximum rebate potential into routing logic. |
| RoundRobin | Will work through full exchange list one exchange at a time. |
| ProRataOptim | Will send orders to pro-rata exchanges first. |
Progression Algos
(progressRule = ProgressionAlgo)
Progression algos are available for stock, futures, and options. They typically work by breaking an order in several slices (up to 20 depending on order size and duration and client request) and work an order one slice at a time. Individual slices can step from more passive to more aggressive while the slice is working. They can trigger flash auctions prior to crossing markets and put an order balance in the exchange closing auctions (if one exists). They can actively take (including leg) public markets at the end of slices. And they always honor a clients primary limit, even at the cost of not completing a progression sequence.
Progression algos can be configured to work in simple time/slice steps (TWAP handling) or more dynamic print volume/slice steps (VWAP handling) that directly match the velocity of child order release with the public trading volume.
The following parameters control progression algo behaviors:
| ProgressionAlgo | Description |
|---|---|
| Twap | The order's working size is divided into slices of both size and time. |
| Vwap | The size is released based on volume traded. |
| FastReset | Limit will be reset on and off every 15 seconds. |
| SlowReset | Limit will be reset on and off every minute. |
| TwapAlpha | This progression algo is intended to work for the full duration of the parent order. This algo takes the slice size, count, and target duration. It then works the next slice through the different modes (passive, moderate, and aggressive). If a slice fills before its target time has elapsed, the algo waits until the fully allotted time has passed, before switching to the next slice. TwapAlpha is available for equities, options, futures, and MLEG orders. |
| VwapAlpha | This progression algo is intended to work for the full duration of the parent order. This algo takes the volume and target duration. It then works the next slice through the different modes (passive, moderate, and aggressive). If a slice fills before its target time has elapsed, the algo waits until the fully allotted time has passed, before switching to the next slice. VwapAlpha is available for equities, options, futures, and MLEG orders. |
| TwapAlphaC | This progression algo that is intended to work for the full duration of the parent order. This algo determines a slice size, count, and target duration. It then works the next slice through the different modes (passive, moderate, and aggressive). If a slice fills before its target time has elapsed, the algo waits until the fully allotted time has passed, before switching to the next slice. There is also a variation for equities called TwapAlphaC that will promote any parent order balance into the primary equity closing auction just before auction cutoff time. |
| VwapAlphaC | This progression algo that is intended to work for the full duration of the parent order. This algo determines a volume and target duration. It then works the next slice through the different modes (passive, moderate, and aggressive). If a slice fills before its target time has elapsed, the algo waits until the fully allotted time has passed, before switching to the next slice. There is also a variation for equities called VwapAlphaC that will promote any parent order balance into the primary equity closing auction just before auction cutoff time. |
| SpdrPulse | SpdrPulse is designed to work each parent order in distinct slices. Each slice will work through passive, moderate, and aggressive modes. If any slice fills, the order will immediately revert to passive mode and start working the next slice. The SpdrPulse is designed to work each parent order in distinct slices duration for each SpdrPulse slice is 30 seconds but can be set on each individual parent order. SpdrPulse is available for equities, futures, options, and MLEG orders. |
Market/Limit On Open/Close Child Orders
Parent order algo handlers can place child orders in exchange opening or closing auctions and have integrated these child orders into some of our progression algos as well.
DMA Child Orders
Simple algo handlers that generate zero or one child order with a static limit price are called DMA algo handlers within our execution engines. If the resulting child order terminates the ParentBroker that generated it, the DMA algo handler will either auto-close (direct orders) or go into an active hold state (staged orders) pending further instructions.
DMA orders can be sent to exchanges (sometimes useful as they have no requirement that the target or underlier market is open and are somewhat less restricted that our normal algo child orders). They can also be sent to other brokers and venues (we sometimes call these away orders) if appropriate routes have been established.
Auction Response Orders
Parent orders responding to either exchange auction notices or our ATS notices must include a SpiderRock auction notice ID. We then immediately generate a responsive child order for the notice.
These orders are subject to all normal parent order handling rules and risk checks and can go through a StageReview sequence (if client systems are fast enough).