a. Identify and explain each order type offered by the NMS Stock ATS. In your explanation, include the following:
i. priority, including the order type's priority upon order entry and any subsequent change to priority (if applicable); whether and when the order type can receive a new time stamp; the order type's priority vis-à-vis other orders on the book due to changes in the NBBO or other reference price; and any instance in which the order type could lose execution priority to a later arriving order at the same price;
ii. conditions, including any price conditions (e.g., how price conditions affect the rank and price at which it can be executed; conditions on the display or non-display of an order; or conditions on executability and routability);
iii. order types designed not to remove liquidity (e.g., post-only orders), including what occurs when such order is marketable against trading interest on the NMS Stock ATS when received;
iv. order types that adjust their price as changes to the order book occur (e.g., price sliding orders or pegged orders) or have a discretionary range, including an order's rank and price upon order entry and whether such prices or rank may change based on the NBBO or other market conditions when using such order type; when the order type is executable and at what price the execution would occur; whether the price at which the order type can be executed ever changes; and if the order type can operate in different ways, the default operation of the order type;
v. whether an order type is eligible for routing to other Trading Centers;
vi. the time-in-force instructions that can be used or not used with each order type;
vii. the circumstances under which order types may be combined with another order type, modified, replaced, canceled, rejected, or removed from the NMS Stock ATS; and
viii. the availability of order types across all forms of connectivity to the NMS Stock ATS and differences, if any, in the availability of an order type across those forms of connectivity.
| STANDARD ORDER TYPES: The ATS supports the following "Standard Order" types:
1) "Limit Order": an order which (if filled) executes at or above (for an order to sell) or at or below (for an order to buy) the User specified price. Limit Orders must include a security (symbol), a side (buy or sell), a limit price, and a maximum quantity (shares);
2) "Peg Order": a type of Limit Order which (if filled) executes at the NBB, NBO, or midpoint of the NBBO (or better) as indicated by execution instructions. Determination of the NBBO and midpoint price follows in Part III Items 11 and 23. Peg Orders must include a security (symbol), a side (buy or sell), and a maximum quantity (shares). Peg orders can also optionally include a limit price and/or an offset amount. Offset amounts must be expressed in increments greater than or equal to one penny ($.01). Buy orders will not execute at a price greater than the lowest of: the limit price, the NBO, or the peg price plus or minus the offset amount. Sell orders will not execute at a price lower than the greatest of: the limit price, the NBB, or the peg price plus or minus offset amount.
Limit prices greater than or equal to $1.00 must be expressed in increments of at least $.01 (i.e. sub-penny prices are not permitted). Limit prices less than $1.00 must be expressed in increments of at least $.0001. This applies to limit prices on all order types. If a peg order (including offset amount) would result in an effective price at an impermissible increment for a given auction, then the order will not be eligible to participate in that auction.
EXPRESSIVE ORDERS: The ATS also supports Expressive Orders, an order type unique to OneChronos that allows Subscribers or other External Users entering Bidder Logic to specify execution instructions spanning one or more individual Limit Orders. Any Limit Order or collection of Limit Orders referencing Bidder Logic receives treatment as an Expressive Order.
Expressive Orders have four components: 1) Bidder Logic: static functions that take data and return execution instructions. External Users approved to use the Expressive Bidding Service may provide their Bidder Logic via the mechanism described in Part III Item 5 under "ORDER AND BIDDER LOGIC SUBMISSION"; 2) Bidder Inputs: data provided by Subscribers (for example, notional maximum values or symbol ratios/weightings) for use in Expressive Orders. Bidder Inputs are provided as a FIX tag and may be specified on any Target Order entered in connection with a Expressive Order; 3) Market Inputs: market data (e.g. the NBBO) supplied by the Operator as an input to Bidder Logic (see Part III Item 23); 4) Target Orders: Limit Orders submitted by Subscribers via FIX that reference Submitted Bidder Logic upon which such Bidder Logic acts.
BIDDER LOGIC SUBMISSION: Bidder Logic is expressed via computer code in a general-purpose programming language (e.g. ReasonML). A person using the Expressive Bidding Service must submit its Submitted Bidder Logic in advance of its use in any Expressive Order. Bidder Logic is available for use on the first trading day after the calendar day of its receipt by the ATS. The ATS and the programming language itself are sufficiently flexible to allow External Users to create their own constraints that suit their execution objectives, using common mathematical and Boolean constraints. Examples are provided below. Users of the service, as authors of any Bidder Logic, can submit such code to the ATS through the Portal. As detailed in Part III Item 5, Bidder Logic is not itself an order, and orders themselves can only be submitted directly to the ATS by Subscribers. Examples of computations that may be performed using Bidder Logic (and full examples illustrated below in this section):
- Measurement of bid/ask spread and volume imbalance; - Computation of midpoint prices with custom volume / venue weightings; - Selection of a subset of stocks (i.e. underlying Target Orders) for participation or elimination; - Further constraining of prices / quantities expressed in Target Orders to less aggressive levels; - Expressing indifference across different quantity levels at different price points; - Requiring execution in multiple stocks simultaneously, or else none at all;
The output of any Bidder Logic is similar to a collection of Boolean constraints (e.g. "AND," "OR") and algebraic constraints (e.g. +, *, < , =), acting on prices and/or quantities for different symbols. For example, a constraint Quantity(A) > 0 AND Quantity(B) > 0 would require that the quantity filled in symbol "A" must be greater than 0 and the quantity filled in symbol "B" must also be greater than 0. A similar, more restrictive constraint would be Quantity(A) = Quantity(B) meaning the share quantity in both symbols must be equal. Either case would represent an intent to "only execute a trade in A if also executing a trade in B." If the constraint cannot be met in the auction, the Expressive Order will not be filled in either A or B.
Upon acceptance, each Bidder Logic submission is systematically evaluated to confirm its properties (e.g. that it can successfully terminate), then assigned a unique reference ID, which is provided back to the user, for inclusion in Target Orders. The Portal provides tools for analyzing and testing properties of Bidder Logic such as the execution instructions that result from the application of specific simulated Bidder Inputs and Market Inputs to the Bidder Logic. Bidder Inputs and Market Inputs are specific to order entry and matching, and are not managed through the Portal. Target Orders are always sent via FIX and must be received by the ATS from Subscribers.
As an illustrative example of execution instructions that are possible with Expressive Bidding, an order seeking to buy three securities in any ratio, up to a total notional amount, would consist of: 1) Bidder Logic (External User controlled): instructions in the form of a computer program to buy any combination of symbols provided as an input to the program (the Bidder Inputs), each at prices less than or equal to their NBBO midpoints (the Market Inputs) up to a fixed notional cap (also specified as a Bidder Input); 2) Bidder Inputs (External User controlled): a list of symbols e.g. ("A", "B", "C") and a notional cap e.g. $500,000.00 included as a FIX tag on one of the Target Orders; 3) Market Inputs (Operator controlled): The NBBO of "A", "B", and "C" as determined by the procedure described in Part III Item 23; 4) Target Orders (External User controlled): three underlying Limit Orders to buy "A", "B", and "C" respectively with corresponding limit prices and maximum volumes;
The FIX message for entering this order would contain an identifier referencing the pre-submitted Bidder Logic, as well as Bidder Inputs. The Bidder Logic would provide for the computation of midpoint prices for each symbol using the Market Inputs provided by the Operator at the time of auction (as described in Part III Item 23).
Additional examples of trading objectives that may be expressed using Expressive Bidding are given below. These examples include constraints and computations which would, in practice, be constructed and submitted as Bidder Logic. These constraints and computations are shown in a reduced form analogous to Bidder Logic (i.e. a more easily readable format than the programming language used in actual Bidder Logic) to illustrate how Expressive Bidding may be used. In practice, additional constraints for each example may be included to manage combinations of, for example, price, quantity, and or notional limits.
EXAMPLE A: Basket of Substitutes: A trader may have equal preference for one or more stocks in a Bidder supplied list that similarly satisfy some investment objective, e.g.: buy any combination of A, B, and/or C up to a total notional maximum of $1,000,000.
Constraint 1 (notional maximum):
Quantity(A) * Price(A) + Quantity(B) * Price(B) + Quantity(C) * Price(C) <= $1,000,000
EXAMPLE B: "One out of Many" Basket: A trader may wish to transact in only one out of a list of stocks: buy only stock A or stock B, up to the price and quantity limits specified on the underlying Target Orders. The quantities in Constraint 1 are set at > 0 without an upper limit because the trader is relying on the quantity specified in the Target Orders to establish the maximum size of the order.
Constraint 1 (one out of many):
Quantity(A) > 0 XOR Quantity(B) > 0
Note: "XOR" refers to exclusive-or, a logical operation that can be interpreted as "one or the other, but not both". Sequences of multiple other constraints can be used to create similar behavior for 3 or more stocks.
EXAMPLE C: Basket of Complements: A trader may wish to transact if and only if they can do so in multiple stocks simultaneously, e.g.: sell (A and B and C) in equal quantities as a single basket. In this example, each unit of the basket (i.e. 1 share of A, 1 share of B, and 1 share of C) must be sold for a sum of at least $100, or N units for N * $100 (all units of a given basket will have the same price, as auctions clear each symbol at a single price). Alternatively, the quantities for A, B, and C may be expressed as a desired ratio, e.g. reflecting the market capitalization or price per share of the stocks.
Constraint 1A (equal quantities):
Quantity(A) = Quantity(B) = Quantity(C)
Constraint 1B (quantity ratio):
2 * Quantity(A) = 10 * Quantity(B) = 15 * Quantity(C)
Constraint 2 (minimum price per unit):
Price(A) + Price(B) + Price(C) >= $100
EXAMPLE D: Pairs / Hedge Trade: A trader may wish to transact in two different symbols in similar amounts: buy A if and only if selling an approximately equal (within $1,000) notional amount of B.
Constraint 1 (both A and B simultaneously):
Quantity(A) > 0 AND Quantity(B) > 0
Constraint 2 (maximum net notional of +/- $1,000):
-$1,000 < (Price(A) * Quantity(A) - Price(B) * Quantity(B)) < $1,000
Note: side (buy/sell) for A and B would be expressed in the underlying Target Orders. Additional logic could be constructed to identify and select buy vs. sell side Target Orders for participation if Target Orders were provided for both sides.
EXAMPLE E: Dollar Neutral Basket: A trader may wish to purchase and sell a mix of stocks such that the notional amount sold is equal or approximately equal to the notional amount purchased.
Constraint 1 (maximum net notional of +/- $100)
-$100 <= (Notional(A) + Notional(B) + Notional(C)) - (Notional(D) + Notional(E) + Notional(F)) <= $100
It is assumed for simplicity that A, B, and C have corresponding Target Orders to BUY and D, E, and F have corresponding Target Orders to SELL (or vice versa). This can be validated and asserted by the Bidder Logic, or the Bidder Logic can analyze the input Target Orders and arrange the terms of the constraint according to each Target Order's side.
EXAMPLE F: Price Improvement Size-Up: A trader may wish to transact different volumes at different prices: sell up to 500 shares at $20, or sell up to 1,000 shares if the price is more favorable at $21, but not both (i.e. not 1,500 total). This is an example of a Expressive Order that is employed for a single stock.
Constraint 1:
(0 <= Quantity(A) <= 500 AND Price(A) > $20) XOR (500 < Quantity(A) <= 1,000 AND Price(A) > $21)
EXAMPLE G: Imbalance Discretion: A trader may wish to defer the single stock execution decision between bidding at the midpoint price or at a more aggressive price until the time of auction, based on external market conditions measured by the ATS via the SIP and made available as Market Inputs. For example, a trader might wish to enter an order on the following basis: if there is at least twice as much exogenous volume available at the national best offer (NBO) than is available at the national best bid (NBB), then buy 100 shares up to the NBO. Otherwise, buy 100 only up to the midpoint.
Computation on Market Inputs: IF NBO_Volume(A) / NBB_Volume(A) > 2.0 THEN dynamic_price = NBO(A) OTHERWISE dynamic_price = Midpoint(A)
Constraint 1 (set dynamic limit price):
Price(A) <= dynamic_price
For Expressive Bidding, both the parameters of all constituent Target Orders (e.g. limit price) and the constraints provided in Bidder Logic must be satisfied for an execution to occur. Bidder Logic cannot permit an execution that would violate the parameters of the Target Order(s); likewise, Target Order parameters cannot permit an execution that would violate constraints provided in Bidder Logic. For example: an Expressive Order with Bidder Logic specifying willingness to execute multiple orders at the calculated midpoint or better, will not execute if dependent on inclusion of a Target Order whose limit price is less aggressive than the calculated midpoint and the clearing price of the auction.
ORDER AVAILABILITY: The ATS uses periodic call auctions that make use of mathematical optimization techniques to match buyers and sellers. These auctions take place multiple times per second throughout the trading day. Each auction considers all eligible orders across all symbols simultaneously and seeks an "optimal" matching between buyers and sellers as described in Part III Item 11. All order types, including Expressive Orders, are available to all Subscribers of the ATS, and have the same eligibility criteria and time cut-offs for participation in a given auction. Expressive Orders are evaluated (i.e. Bidder Logic code is processed) in each auction prior to the start of the auction's optimization process. Given that Expressive Orders could allow for varying degrees of complexity, their evaluation is resource constrained. That is, each Expressive Order is allocated a finite amount of computation resources and is evaluated prior to the commencement of the Match Optimization process described in Part III Item 11 under the Auction Procedure heading. These computational constraints apply to all Expressive Orders equally (i.e. regardless of order complexity or from whom the ATS received the order). An Expressive Order and its associated Target Orders will not be eligible for the auction if the Expressive Order exceeds its evaluation constraints. Subscribers can opt-in to receive message alerts via FIX that their orders did not participate in a given auction. The ATS provides tools for analyzing the complexity and resource utilization of Expressive Bidding.
ORDER PRIORITY: The ATS periodically holds auctions (multiple times per second) designed to seek an optimal matching between buyers and sellers across all eligible orders. Each order's eligibility for participation is determined by its time-stamped receipt at one of the Operator's distributed PoPs (the Operator is commencing operation with a single PoP, in Equinix NY5). Executions, allocations, and per symbol clearing prices are determined using mathematical optimization techniques, maximizing Aggregate Price Improvement dollars across eligible orders in a given auction. See Part III Item 11 under the Distributed Point of Presence System and Auction Procedure headings for specific details.
EXECUTION INSTRUCTIONS: The ATS supports a set of execution instructions applicable to both of its Standard Order types (Limit Orders and Peg Orders) at the FIX layer. These execution instructions also apply to the Target Orders that are used in connection with Expressive Bidding. Subscribers may use these execution instructions on a per order basis, subject to system bounds established and imposed by the ATS itself as described in Part III Item 8. The following execution instructions are available: 1) Price Limit (minimum price verification on a per-share basis); 2) Maximum number of shares; 3) Minimum number of shares; 4) Time-in-force: Day, Immediate or Cancel, Fill or Kill, Good 'Til Date (with an expire time not to exceed the end of the current trading session);
These message-layer constraints cannot be overridden by Expressive Bidding and Bidder Logic.
ORDER CANCELLATION, MODIFICATION, AND REPLACEMENT: the ATS does not support modification of resting orders, but Subscribers can cancel and replace orders with either a single cancel-replace request or two separate cancellation and new order entry requests. Order entry and cancellation requests are processed as described in Part III Item 11(c).
ROUTING: The ATS does not route orders to other trading centers.
The ATS does not support any order types designed not to remove liquidity, as the ATS does not distinguish between providing and removing liquidity. |