OneChronos

amendment_reason

This is a Material Amendment that: - Introduces Conditional Orders to the ATS (Part III Items 7, 9, 11, 14, 15). - Adds an additional introductory fee discount (Part III Item 19). - Amends the tie-breaker logic in Part III Item 11 to add an additional tie-breaking metric. This Amendment applies to the Subscribers of the ATS. It does not apply to the Operator, as the Operator does not trade on the ATS.

amendment_reason

This is an updating amendment reflecting changes to the operation of the ATS to: 1. Remove reference to restrictions on orders priced under $1 to conform with previous amendment in Part III Item 8; 2. Remove introductory launch schedule details in Part III Item 10; 3. Clarify limit price wording for peg orders and include handling of permissible and impermissible price increments in Part III Item 7; 4. Update minimum quantity restriction to "at least 100 shares" from "more than 100 shares" in Part III Item 7; 5. Define eligibility exception for NMS stocks that cannot be processed by the ATS's clearing or reporting partners in Part III Item 11; 6. Add detail on error handling scenarios in Part III Item 20; 7. Revise description of round-robin allocation procedure in Part III Item 11; 8. Include detail on the ATS's clearing and settlement process, and related requirements for subscribers in Part III Item 22; 9. Update Part III Item 14 to reflect the self-trade prevention mechanism previously disclosed in Part III Item 11; 10. Define default port settings for trading during locked markets in Part III Item 11; The changes apply to all subscribers of the ATS, but do not apply to the Operator as the Operator does not trade on the ATS.

amendment_reason

This is an updating amendment to: 1) Reflect changes to the operation of the ATS to remove support for 1G LR SMF cross-connects in Part 3 Item 6. 2) Update the disclosures to reflect that minimum quantity is supported on all orders, including odd lot orders (Part 3 Item 7). 3) Update the disclosures around the number of messages our clearing provider submits to NSCC, per transaction on the OneChronos ATS (Part 3 Item 22). These changes affect the Subscribers of the ATS, but does not affect the Operator, as the Operator does not trade on the ATS.

amendment_reason

This is a Correcting Amendment that restores language in Part II Item 7 regarding the access that Operations and Engineering staff have to Confidential Trading Information. This language was originally disclosed in a Material Amendment filed on 2023-05-26, but the amended language was inadvertently reverted in subsequent amendments to the language as of the Updating Amendment on 2023-05-18. This Amendment also includes a revised Schedule A of the OneChronos Form BD. This Amendment applies to the Operator, and does not apply to Subscribers to the ATS.

amendment_reason

This is an Updating Amendment that includes a revised Schedule A and Schedule B of the OneChronos Markets LLC Form BD. These changes do not affect any functionality or access for the Subscribers or Broker-Dealer Operator.

amendment_reason

This is a Material Amendment that adds a new type of Introductory Discount in Part III Item 19. This Amendment applies to the Subscribers of the ATS. It does not apply to the Operator, as the Operator does not trade on the ATS.

amendment_reason

This is an Updating Amendment to the Material Amendiment filed on November 22nd, 2024 that updates the disclosures in Part III Item 19 to disclose that the Broker-Dealer Operator passes through CAT fees. The Material Amendment updated Part III Item 19 to reflect changes to the ATS' pricing structure for executions in Custom Groups and for executions originating from Subscriber-attested retail flow. This Amendment applies to the Subscribers of the ATS. It does not apply to the Operator, as the Operator does not trade on the ATS.

amendment_reason

This is an updating amendment to: 1) clarify the definitions of External Users and Subscribers in Part II Item 5(a) and Part III Items 1, 2, and 5 to include External Users as "subscribers" for the purpose of Regulation ATS. External Users are users who can submit orders to the ATS indirectly through Subscribers, such as hedge funds, principal trading firms, etc.; 2) update descriptions Subscriber vs. External User eligibility, and list of materials required from prospective Subscribers in Part III Item 2; 3) clarify the functionality provided by the Portal described in Part II Item 5(a), and Bidder Logic submission process for Subscribers and External Users in Part III Items 2 and 7; 4) describe process and timelines for exclusion from the ATS in Part III Item 3; 5) include cancel-replace message type in Part III Item 7 under the heading "ORDER CANCELLATION, MODIFICATION, AND REPLACEMENT"; 6) rename "Computational Orders" to "Expressive Orders" in Part III Items 5, 7, 11, 20, and 23; 7) update Subscribers' ability to configure order pricing risk controls in Part III Item 11; 8) clarify auction timing, NBBO handling, and the meaning of "midpoint" with respect to clearing price formation in Part III Item 11(c); 9) update fee schedule in Part III Item 19; 10) include drop-copy reports and replace the OATS reporting destination with FINRA CAT in trade reports described in Part III Item 21; 11) updates to Exhibit 1 - Form BD Schedule A (this change only applies to the Operator); Except where otherwise noted, these changes apply to all Subscribers of the ATS.

amendment_reason

This is an updating amendment reflecting changes to the operation of the ATS: 1) Inclusion of Juneteenth National Independence Day as a market holiday in Part III Item 4; 2) Clarification of minimum prices on orders in Part III Item 8; 3) Description of the planned schedule for introduction of symbols following launch of the ATS in Part III Item 10; These changes apply to all subscribers of the ATS, but do not apply to the Operator as the Operator does not trade on the ATS.

amendment_reason

This is a Material Amendment that updates Part III Item 19a to reflect changes to the ATS' pricing structure for executions in Custom Groups and for executions originating from Subscriber-attested retail flow. This Amendment applies to the Subscribers of the ATS. It does not apply to the Operator, as the Operator does not trade on the ATS.

amendment_reason

This is an updating amendment reflecting changes to the operation of the ATS to: 1) Include market data service provider, Exegy, in Part II Item 6 2) Re-organize description of historical vs. intraday Confidential Trading Information and corresponding description of internal roles (Operations and Engineering), defined in Part II Item 7. Item 1 affects all Subscribers to the ATS equally, but does not affect the operator as the operator does not trade on the ATS. Item 2 affects the Operator but does not affect Subscribers to the ATS.

amendment_reason

This is an updating amendment reflecting changes to the operation of the ATS to: 1) Include market data service provider, Exegy, and remove reference to market data in description of service provider Pico in Part II Item 6. This change affects all Subscribers to the ATS equally, but does not affect the operator as the operator does not trade on the ATS. 2) Re-organize description of historical vs. intraday Confidential Trading Information in Part II Item 7. This change affects the Operator but does not affect Subscribers to the ATS.

amendment_reason

This filing updates the Operator's Form BD Schedule A, to the latest version, filed on January 13th, 2025, to reflect a change in the Operator's FINOP. This Amendment applies to the Operator of the ATS, but not the Subscribers, as no functionality of the ATS is changing.

amendment_reason

This Material Amendment: 1. amends the disclosures concerning the availability of the Expressive Bidding Service to allow up to two Target Orders in an Expressive Order and to permit Subscribers to include certain market data supplied by Operator in their Bidder Logic. Specifically, Part III Items 7 and 23 have been amended; 2. amends Part III Item 7 to give Subscribers the ability to opt in at the session level to have an Immediate or Cancel Order submitted during the applicable session handled as if it was submitted with a time-in-force of Good \'Til Date with an expiration time specified as an offset from the order\'s PoP arrival timestamp; 3. amends Part III Item 9 to amend the ability of firm orders to opt-in to generate Conditional Invitations; 4. amends Part III Item 11 and Part III Item 14 to give Subscribers the ability to specify Custom Groups of counterparties against which to execute for both orders and Conditional Indications on an order-by-order basis or at the session level rather an order-by-order basis or at the session level; and 5. amends Part III Item 20 to amend the ATS' short sale restrictions to provide that in the event that a circuit-breaker has been triggered for a given security, rather than not accepting "short" orders in that security unless they are marked "short exempt", the ATS does not execute "short" orders in that security at the NBB unless they are marked "short exempt". These changes apply to all Subscribers, but not the Operator of the ATS, as the Operator does not trade on the ATS.

amendment_reason

This Material Amendment: 1) changes Part III Item 7 to provide that where a Peg Order (including offset amount) results in an effective price at a sub-penny increment for a given auction, instead of that order being ineligible to participate in that auction, the effective price of the Peg Order will be rounded conservatively to the nearest permissible increment (i.e. the effective price will be rounded down for a buy order, and the effective price will be rounded up for a sell order) so that the order may participate in that auction. 2) changes Part III Item 19(a) and (c) to provide that that commission fees for execution of orders in Custom Groups will range from $0 per share to $0.0030 per share. 3) changes Part III Item 19(a) and (c) to provide that the Operator may charge a higher commission to certain Subscribers in Custom Groups and then rebate part of that higher rate to the other Subscriber or Subscribers in the Custom Group. These changes apply to all Subscribers, but not the Operator of the ATS, as the Operator does not trade on the ATS.

amendment_reason

This is an Updating Amendment which amends the Material Amendment filed on 2024-09-18, which: - Introduces Conditional Indications to the ATS (Part II Item 7, and Part III Items 7, 9, 11, 14, 15). - Adds an additional introductory fee discount (Part III Item 19). - Amends the tie-breaker logic in Part III Item 11 to add an additional tie-breaking metric. This Amendment applies to the Subscribers of the ATS. It does not apply to the Operator, as the Operator does not trade on the ATS.

amendment_reason

This is an Updating Amendment to the Material Amendment filed on 2023-10-30 that: - Introduces new Custom Group functionality to the ATS that allows Subscribers to specify custom groups of counterparties against which to execute on an order-by-order basis (Part III Item 7, 11, and 14). - Introduces a change to the ATS' optimization process, including the tie-breaking procedure and allocation logic (Part III Item 11). - Amends the disclosure to reflect that the lower-bounding procedure considers Limit Orders, all Pegged Orders, and not Expressive Orders (Part III Item 11). - Amends the disclosure around when a solution found by the lower-bounding procedure is selected by the optimization process (Part III Item 11). - Introduces new types of fee discounts (Part III Item 19). - Introduces a change to how the ATS trade reports (Part III Item 21). These changes affect both the Broker-Dealer Operator and Subscribers of the ATS.

amendment_reason

This Updating Amendment updates Part III Item 11(c) to reflect that the ATS uses a single objective function to implement the match priority outlined in that section rather than evaluating the two objectives in succession. There is no change to the match priority. This update applies to all Subscribers, but not the Operator of the ATS, as the Operator does not trade on the ATS. The Amendment also updates Part I Item 9 Exhibit 2, the Operator's Form BD Schedule B, to the latest version.

amendment_reason

7(g) language - This Updating Amendment updates: Part III Item 11(c) to update the formula and result of the calculation of aggregate price improvement provided in "Example 4: Multilateral Limit Order Fill". Part III Item 19(a) to specify that commission fees for execution of Expressive Orders will be determined in the same way as for Custom Groups and Firm Up Orders, where commission fees are at a negotiated rate in a range from $0 per share to $0.0015 per share. Part III Item 19(c) to specify that discounted commissions will generally be in a range from $0 per share to $0.0015 per share; and until October 31, 2025, any discounts will continue to be calculated retroactively, and after November 1, 2025, discounts will be established and disclosed to the Subscriber at the beginning of the month and apply only prospectively (and not retroactively). These updates apply to the Subscribers, but not the Operator of the ATS, as the Operator does not trade on the ATS. The Amendment also updates Exhibit 1, the Operator's Form BD Schedule A, to the latest version.

amendment_reason

This is a Material Amendment that: - Introduces new Custom Group functionality to the ATS that allows Subscribers to specify custom groups of counterparties against which to execute on an order-by-order basis (Part III Item 7, 11, and 14). - Introduces a change to the ATS' optimization process, including the tie-breaking procedure and allocation logic (Part III Item 11). - Amends the disclosure to reflect that the lower-bounding procedure considers Limit Orders, all Pegged Orders, and not Expressive Orders (Part III Item 11). - Amends the disclosure around when a solution found by the lower-bounding procedure is selected by the optimization process (Part III Item 11). - Introduces new types of fee discounts (Part III Item 19). - Introduces a change to how the ATS trade reports (Part III Item 21). These changes affect both the Broker-Dealer Operator and Subscribers of the ATS.

amendment_reason

This Updating Amendment updates Part III Item 19(a) to specify: 1. that commission fees for execution of Firm Up Orders will be determined in the same way as for Custom Groups, where commission fees are at a negotiated rate in a range from $0 per share to $0.0015 per share. 2. that Operator does pass through certain regulatory fees it is assessed and does not currently pass through clearing fees. These updates apply to the Subscribers, but not the Operator of the ATS, as the Operator does not trade on the ATS.

amendment_reason

This filing amends the disclosures concerning the availability of the Expressive Bidding Service. Specifically, Part II Items 5 and 7, and Part III Items 2, 3, 4, 5, 7, 11, and 23 have been amended. This Amendment applies to the Subscribers, but not the Operator of the ATS, as the Operator does not trade on the ATS.

amendment_reason

This Updating Amendment revises: 1. example 4 under the "PRIORITY AND PRICE FORMATION EXAMPLE" heading in Part III Item 11, correcting the NBBO range such that the execution price is permissible, and adding a description of the buy orders' effective prices. This change applies to the Subscribers, but not the Operator of the ATS, as the Operator does not trade on the ATS. 2. the Operator's Form BD Schedule A, to the latest version filed on April 21, 2025. This applies to the Operator of the ATS, but not the Subscribers, as it does not change functionality of the ATS.

amendment_reason

This is a material amendment reflecting changes to the operation of the ATS: 1) addition of a datacenter and network connectivity service provider, Pico Quantitative Trading, in Part II Item 6; 2) handling of Confidential Trading Information as defined in Part II Items 6 and 7, and the ability for Subscribers and External Users to consent to the disclosure of their Confidential Trading Information; 3) the introduction of additional peg instructions for Standard Orders described in Part III Item 7, and corresponding updates in Part III Items 11 and 23. Peg instructions may now indicate passive, midpoint, or market and may include optional price offsets; 4) the inclusion of odd-lot and mixed-lot orders in Part III Item 8; 5) the capacity in which the Operator acts for the purpose of clearing and settlement (as dual-agent) in Part III Item 22. These changes apply to all subscribers of the ATS, but do not apply to the Operator as the Operator does not trade on the ATS.

amendment_reason

This is a Correcting Amendment which amends Part III Item 9 to state that firm orders are only eligible as conditional contras when part of a Custom Group, and to include a constraint that if a Conditional Indication allows for interaction outside of a Custom Group, then the associated Firm Up Order must also allow for interaction outside of a Custom Group. This Amendment applies to the Subscribers of the ATS. It does not apply to the Operator, as the Operator does not trade on the ATS.

amendment_reason

This is a material amendment which adds Instinet, LLC as a clearing firm and removes Wedbush Securities as a clearing firm. The amendment makes changes to Part II Item 6 and Part III Item 22. The amendment applies to both the Operator and Subscribers of the ATS.

amendment_reason

This is a material amendment reflecting changes to internal Operations and Engineering roles' access to Confidential Trading Information in Part II Item 7. This amendment applies to the Operator, and does not apply to Subscribers to the ATS.

amendment_reason

This is a material amendment reflecting changes to the fees charged by the ATS described in Part III Item 19. This change introduces volume-based pricing tiers wherein Subscribers are eligible for discounted fees, based on their total traded volume on OneChronos as a percentage of OneChronos' total matched volume. Discount eligibility is determined on a monthly basis at the end of each calendar month. This change applies to all subscribers of the ATS, but does not apply to the Operator as the Operator does not trade on the ATS.

ats_name

OneChronos

operator_crd

000286322

operator_name

OneChronos Markets LLC

order_types

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 price limit and/or an offset amount. Price limits and 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. 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. +, *, 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 (available on orders for more than 100 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.

order_types

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 that is a sub-penny increment for a given auction, then the effective price for that order will be automatically rounded conservatively to the nearest permissible increment (i.e. the effective price will be rounded down for a buy order, and the effective price will be rounded up for a sell order) so that the order may participate in that auction. EXPRESSIVE ORDERS: The ATS also supports Expressive Orders, an order type 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 three 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) Target Orders: Limit or Pegged Orders submitted by Subscribers via FIX that reference Submitted Bidder Logic upon which such Bidder Logic acts. BIDDER LOGIC SUBMISSION: Bidder Logic can be expressed using a programming language supported by the Operator, or via a domain-specific language developed by the Operator. A person using the Expressive Bidding Service must submit its Bidder Logic in advance of its use in any Expressive Order. The Operator may require External Users to certify their Bidder Logic in the OneChronos UAT environment before the Bidder Logic is available in production, particularly when the Logic is first submitted, or if the logic is altered in a material way (minor updates to Bidder Inputs such as the tolerance of a fill ratio on a pairs order may not require certification). When UAT certification is not required, updates to existing Bidder Logic will be available on the next calendar day after receipt by the ATS. Supported languages for expressing Bidder Logic use common mathematical and Boolean constraints. Examples are provided below. Users of the service, as authors of any Bidder Logic, can submit such code via specific ATS personnel, who will deploy it into the ATS. 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. Upon acceptance, each Bidder Logic submission is 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. Target Orders are always sent via FIX and must be received by the ATS from Subscribers. The ATS supports Bidder Logic that enables the External User to submit a pairs order type on the ATS (see example below), where the External User may submit two target orders, and join them together as a pair order. The two target orders joined in the pair order will only execute if both can be filled (i.e., one target order will not execute if the other cannot). The ATS also supports specifying optional, customizable parameters that impose additional constraints, which, when not satisfied, suppress fills in either target order. One set of parameters constrains the ratio of fill quantities to a numeric range (i.e., the orders in the pair may not fill except in a specific ratio; the User may optionally specify a tolerance, so that the ratio need not be exact, but within the tolerance specified). Another set of parameters mandates that the execution prices of those fills satisfy a linear relationship (i.e., the User may specify three numbers, g1, g2, and L, such that the two orders in the pair may not fill unless g1 * p1 + g2 * p2 >= L, where p1 and p2 are the execution prices of the two orders in the Pair, respectively). The following Example illustrates this functionality: EXAMPLE: 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 is 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. 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. For Expressive Bidding, the parameters of all constituent Target Orders (e.g. limit price) and the constraints provided in Bidder Logic must all 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. 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, and Conditional Indications (as described in Part III Item 9). 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). As discussed in Part III Item 9, Firm Up Orders sent in response to a Conditional Invitation may not be cancelled and replaced. 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. CUSTOM COUNTERPARTY GROUPS: As described in Part III Item 14, the ATS offers functionality for Subscribers to specify custom groups of counterparties against which to execute on an order-by-order basis, for both orders and Conditional Indications.

order_types

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 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 three 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) Target Orders: Limit or Pegged Orders submitted by Subscribers via FIX that reference Submitted Bidder Logic upon which such Bidder Logic acts. BIDDER LOGIC SUBMISSION: Bidder Logic can be expressed using a programming language supported by the Operator, or via a domain-specific language developed by the Operator. A person using the Expressive Bidding Service must submit its Bidder Logic in advance of its use in any Expressive Order. The Operator may require External Users to certify their Bidder Logic in the OneChronos UAT environment before the Bidder Logic is available in production, particularly when the Logic is first submitted, or if the logic is altered in a material way (minor updates to Bidder Inputs such as the tolerance of a fill ratio on a pairs order may not require certification). When UAT certification is not required, updates to existing Bidder Logic will be available on the next calendar day after receipt by the ATS. Supported languages for expressing Bidder Logic use common mathematical and Boolean constraints. Examples are provided below. Users of the service, as authors of any Bidder Logic, can submit such code via specific ATS personnel, who will deploy it into the ATS. 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. Upon acceptance, each Bidder Logic submission is 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. Target Orders are always sent via FIX and must be received by the ATS from Subscribers. The ATS supports Bidder Logic that enables the External User to submit a pairs order type on the ATS (see example below), where the External User may submit two target orders, and join them together as a pair order. The two target orders joined in the pair order will only execute if both can be filled (i.e., one target order will not execute if the other cannot). The ATS also supports specifying optional, customizable parameters that impose additional constraints, which, when not satisfied, suppress fills in either target order. One set of parameters constrains the ratio of fill quantities to a numeric range (i.e., the orders in the pair may not fill except in a specific ratio; the User may optionally specify a tolerance, so that the ratio need not be exact, but within the tolerance specified). Another set of parameters mandates that the execution prices of those fills satisfy a linear relationship (i.e., the User may specify three numbers, g1, g2, and L, such that the two orders in the pair may not fill unless g1 * p1 + g2 * p2 >= L, where p1 and p2 are the execution prices of the two orders in the Pair, respectively). The following Example illustrates this functionality: EXAMPLE: 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 is 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. 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. For Expressive Bidding, the parameters of all constituent Target Orders (e.g. limit price) and the constraints provided in Bidder Logic must all 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. 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, and Conditional Indications (as described in Part III Item 9). 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). As discussed in Part III Item 9, Firm Up Orders sent in response to a Conditional Invitation may not be cancelled and replaced. 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. CUSTOM COUNTERPARTY GROUPS: As described in Part III Item 14, the ATS offers functionality for Subscribers to specify custom groups of counterparties against which to execute on an order-by-order basis, for both orders and Conditional Indications.

order_types

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 price limit and/or an offset amount. Price limits and 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. 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 (available on orders for more than 100 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.

order_types

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. CUSTOM COUNTERPARTY GROUPS: As described in Part III Item 14, the ATS offers functionality for Subscribers to specify custom groups of counterparties against which to execute on an order-by-order basis.

order_types

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) "Midpoint Peg Order": a type of Limit Order which (if filled) executes at the midpoint of the NBBO (or better). Determination of the NBBO and midpoint price follows in Part III Items 11 and 23. Midpoint Peg Orders must include a security (symbol), a side (buy or sell), and a maximum quantity (shares). Midpoint Peg Orders can also include a price limit such that the order will not execute if the computed midpoint price is higher (buy) or lower (sell) than the specified limit. 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, including Midpoint Peg 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 (including Midpoint Peg 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. +, *, 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 Midpoint 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 (available on orders for more than 100 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.

order_types

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.

order_types

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 (available on orders for at least 100 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.

order_types

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) "Midpoint Peg Order": a type of Limit Order which (if filled) executes at the midpoint of the NBBO (or better). Determination of the NBBO and midpoint price follows in Part III Items 11 and 23. Midpoint Peg Orders must include a security (symbol), a side (buy or sell), and a maximum quantity (shares). Midpoint Peg Orders can also include a price limit such that the order will not execute if the computed midpoint price is higher (buy) or lower (sell) than the specified limit. COMPUTATIONAL ORDERS: The ATS also supports Computational Orders, an order type that allows Subscribers or other External Users entering Bidder Logic to specify execution instructions spanning one or more individual Limit Orders, including Midpoint Peg Orders. Any Limit Order or collection of Limit Orders referencing Bidder Logic receives treatment as a Computational Order. Computational Orders have four components: 1) Bidder Logic: static functions that take data and return execution instructions. All External Users may provide 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 Computational Orders. Bidder Inputs are provided as a FIX tag and may be specified on any Target Order entered in connection with a Computational 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 (including Midpoint Peg Orders) submitted by Subscribers via FIX upon which Bidder Logic acts. BIDDER LOGIC SUBMISSION: Bidder Logic is expressed via computer code in a general-purpose programming language. External Users must submit Bidder Logic in advance of its use in any Computational 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. External Users, as authors of any Bidder Logic, can submit such code to the ATS through the Portal or, in the case of Subscribers specifically, through FIX messages as an alternative. 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: - 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; - Selection between 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. +, *, 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 Computational Order will not be filled in either A or B. Upon acceptance, each Bidder Logic submission is assigned a unique reference ID 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 Computational Orders, 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 Computational Orders 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 Computational Orders 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 Bidding Logic, or the Bidding 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 Computational 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 Computational Orders, 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: a Computational 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 Computational 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. Computational 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 Computational Orders could allow for varying degrees of complexity, their evaluation is resource constrained. That is, each Computational 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 Computational Orders equally (i.e. regardless of order complexity or from whom the ATS received the order). A Computational Order and its associated Target Orders will not be eligible for the auction if the Computational 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 as for analyzing complexity and resource utilization of Computational Orders. 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 Midpoint Peg Orders) at the FIX layer. These execution instructions also apply to the Target Orders that are used in connection with Computational Orders. 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 (available on orders for more than 100 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 Computational Order Bidder Logic. ORDER CANCELLATION, MODIFICATION, AND REPLACEMENT: the ATS does not support modification of resting orders, but Subscribers can cancel and replace orders with 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.

order_types

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, and Conditional Indications (as described in Part III Item 9). 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). As discussed in Part III Item 9, Firm Up Orders sent in response to a Conditional Invitation may not be cancelled and replaced. 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. CUSTOM COUNTERPARTY GROUPS: As described in Part III Item 14, the ATS offers functionality for Subscribers to specify custom groups of counterparties against which to execute on an order-by-order basis, for both orders and Conditional Indications.

means_of_entry

The ATS is designed to accommodate multiple points of presence ("Points of Presence", "PoP", "PoPs") for order entry. Only Subscribers may directly submit orders to the ATS, and may only do so by establishing a connection via FIX (4.2) protocol at a PoP maintained by the Operator. Currently, the Operator maintains a single PoP at Equinix NY5. Such orders are time-stamped then transmitted to the (centralized) matching engine location at Equinix NY5. Further information on the PoP model follows in Part III Items 5, 6 and 11. No other order entry protocols are available. ORDER AND BIDDER LOGIC SUBMISSION: External Users cannot submit orders directly to the ATS through the Portal. In addition, only a Subscriber may submit orders to the ATS. External Users may submit their Submitted Bidder Logic to the ATS through the Portal, but such Submitted Bidder Logic submissions are NOT orders themselves. An External User's Submitted Bidder Logic represents conditionality that may be attached to an order submitted to the ATS (termed a "Target Order") for execution. Subscribers may submit Target Orders that reference Submitted Bidder Logic (the combination of which is the "Expressive Order") to the ATS via FIX protocol. An External User that is not a Subscriber may direct a Subscriber with which it has established a customer relationship to submit an Expressive Order on its behalf that references the External User's Submitted Bidder Logic.

means_of_entry

The ATS is designed to accommodate multiple points of presence ("Points of Presence", "PoP", "PoPs") for order entry. Only Subscribers can directly submit orders to the ATS, and may only do so by establishing a connection via FIX (4.2) protocol at a PoP maintained by the Operator. Currently, the Operator maintains a single PoP at Equinix NY5. Such orders are time-stamped then transmitted to the (centralized) matching engine location at Equinix NY5. Further information on the PoP model follows in Part III Items 5, 6 and 11. No other order entry protocols are available. ORDER AND BIDDER LOGIC SUBMISSION: External Users other than Subscribers (e.g. institutional investors seeking to direct orders to the ATS using the services of a Subscriber) cannot submit orders directly to the ATS; they must direct orders through a Subscriber. Such External Users, however, can directly submit Bidder Logic to the ATS through the Portal. Subscribers may enter Bidder Logic either through FIX messages or through the Portal. Bidder Logic submissions are NOT orders themselves. Rather, they are reliant on subsequent orders (which are termed "Target Orders") to effect transactions in the ATS. Orders are always received by the ATS from Subscribers, and are always received via FIX protocol. External Users that are not themselves Subscribers (e.g. institutional investors) cannot establish FIX connections to the ATS and cannot directly enter orders into the ATS. To enter orders into the ATS, including Target Orders that are to be used as part of a Computational Order, non-Subscriber External Users must send orders destined for the ATS to a Subscriber with which they have established a customer account. Non-Subscriber External Users may have customer accounts with more than one Subscriber.

means_of_entry

The ATS is designed to accommodate multiple points of presence ("Points of Presence", "PoP", "PoPs") for order entry. Only Subscribers may directly submit orders to the ATS, and may only do so by establishing a connection via FIX (4.2) protocol at a PoP maintained by the Operator. Currently, the Operator maintains a single PoP at Equinix NY5. Such orders are time-stamped then transmitted to the (centralized) matching engine location at Equinix NY5. Further information on the PoP model follows in Part III Items 5, 6 and 11. No other order entry protocols are available. ORDER AND BIDDER LOGIC SUBMISSION: Only a Subscriber may submit orders to the ATS. External Users may submit their Bidder Logic to the ATS (as described in Part II Item 5), but such Submitted Bidder Logic submissions are NOT orders themselves. An External User's Submitted Bidder Logic represents conditionality that may be attached to an order submitted to the ATS (termed a "Target Order") for execution. Subscribers may submit Target Orders that reference Submitted Bidder Logic (the combination of which is the "Expressive Order") to the ATS via FIX protocol. An External User that is not a Subscriber may direct a Subscriber with which it has established a customer relationship to submit an Expressive Order on its behalf that references the External User's Submitted Bidder Logic.

pricing_methodology

The ATS makes use of external market data (including NBBO) from the Securities Information Processor ("SIP") to: 1) Determine the prices at which pegged orders are eligible for participation; 2) Evaluate Expressive Orders that rely on external market data received by the ATS; 3) Determine the prices at which each security in the auction clear; 4) Maintain compliance with the Regulation NMS Order Protection Rule. NBBO FOR PRICE CONSTRAINTS: The ATS treats Midpoint Peg Orders as Limit Orders with dynamically computed limit prices. Thus, unless specified otherwise as an Expressive Bidding constraint, Midpoint Peg Orders are eligible for price improvement when the computed clearing price for the security is more aggressive than the midpoint. Expressive Bids can also specify computations based on Market Inputs, which consist of the measured NBBO and other market data. This functionality endeavors to provide all Subscribers' orders with a single, consistent view of market conditions. The following are examples of how Bidder Logic can use Market Inputs: 1) Specify limit prices based on NBBO (e.g. set a price limit to a specified amount higher or lower than NBBO); 2) Compute a momentary volume-weighted average price for a security, based on data from away venues; 3) Specify a bid price for a security as a function of the price of one or more other securities; NBBO FOR ORDER PROTECTION RULE COMPLIANCE: The ATS match procedure takes the national best bid and national best offer for a given security as lower and upper bounds (constraints) on the allowable clearing price for that security. If no clearing price within the measured NBBO results in a match for a security, the auction will not execute a trade in that security. The ATS runs multiple auctions per second, and as such the ATS reports all transactions within less than one second of measuring NBBO. MEASUREMENT OF MARKET DATA AND NBBO: The ATS constructs a view of NBBO from data provided by the SIP. Each SIP message contains a timestamp provided by the reporting exchange representing when that exchange processed the given message (the "Exchange Timestamp"). The ATS market data and matching systems use these Exchange Timestamps in an effort to construct a consistent time-aligned view of the market. The NBBO prices used in the auction are the ones most recent to but not after the Initialization Time. Below is an illustrative example of this procedure: 1) Auction Initialization results in a Cutoff Time; 2) Auction Network Buffering allows data to propagate from exchanges, to the SIP, and ultimately to the ATS; 3) After buffering the ATS computes NBBO for each tradable symbol by processing all messages from the SIP with Exchange Timestamps less than or equal to the Cutoff Time for the auction. The Exchange Timestamp for a given record is the same on the record for an event received through the SIP and the record for the same event received through lower latency proprietary direct feeds. The ATS does not subscribe to direct feeds from the national exchanges. However, the Auction Network Buffering Period is typically substantially more than the difference in latency between the SIP data feeds and the exchange direct feeds. The Operator uses a combination of time reference sources and statistical processing techniques to survey and correct inter-exchange clock synchronization issues and delays or cancels auctions during periods when the ATS market data systems flag national exchange timestamps as potentially anomalous (See ERROR CONDITIONS in Part III Item 20).

pricing_methodology

The ATS makes use of external market data (including NBBO) from the Securities Information Processor ("SIP") to: 1) Determine the prices at which pegged orders are eligible for participation; 2) Evaluate Expressive Orders that rely on external market data received by the ATS; 3) Determine the prices at which each security in the auction clear; 4) Maintain compliance with the Regulation NMS Order Protection Rule. NBBO FOR PRICE CONSTRAINTS: The ATS treats Peg Orders as Limit Orders with dynamically computed limit prices. Thus, unless specified otherwise as an Expressive Bidding constraint, Peg Orders are eligible for price improvement when the computed clearing price for the security is more aggressive than the order's computed peg price (including offset, if present). Expressive Bids can also specify computations based on Market Inputs, which consist of the measured NBBO and other market data. This functionality endeavors to provide all Subscribers' orders with a single, consistent view of market conditions. The following are examples of how Bidder Logic can use Market Inputs: 1) Specify limit prices based on NBBO (e.g. set a price limit to a specified amount higher or lower than NBBO); 2) Compute a momentary volume-weighted average price for a security, based on data from away venues; 3) Specify a bid price for a security as a function of the price of one or more other securities; NBBO FOR ORDER PROTECTION RULE COMPLIANCE: The ATS match procedure takes the national best bid and national best offer for a given security as lower and upper bounds (constraints) on the allowable clearing price for that security. If no clearing price within the measured NBBO results in a match for a security, the auction will not execute a trade in that security. The ATS runs multiple auctions per second, and as such the ATS reports all transactions within less than one second of measuring NBBO. MEASUREMENT OF MARKET DATA AND NBBO: The ATS constructs a view of NBBO from data provided by the SIP. Each SIP message contains a timestamp provided by the reporting exchange representing when that exchange processed the given message (the "Exchange Timestamp"). The ATS market data and matching systems use these Exchange Timestamps in an effort to construct a consistent time-aligned view of the market. The NBBO prices used in the auction are the ones most recent to but not after the Initialization Time. Below is an illustrative example of this procedure: 1) Auction Initialization results in a Cutoff Time; 2) Auction Network Buffering allows data to propagate from exchanges, to the SIP, and ultimately to the ATS; 3) After buffering the ATS computes NBBO for each tradable symbol by processing all messages from the SIP with Exchange Timestamps less than or equal to the Cutoff Time for the auction. The Exchange Timestamp for a given record is the same on the record for an event received through the SIP and the record for the same event received through lower latency proprietary direct feeds. The ATS does not subscribe to direct feeds from the national exchanges. However, the Auction Network Buffering Period is typically substantially more than the difference in latency between the SIP data feeds and the exchange direct feeds. The Operator uses a combination of time reference sources and statistical processing techniques to survey and correct inter-exchange clock synchronization issues and delays or cancels auctions during periods when the ATS market data systems flag national exchange timestamps as potentially anomalous (See ERROR CONDITIONS in Part III Item 20).

pricing_methodology

The ATS makes use of external market data (including NBBO) from the Securities Information Processor ("SIP") to: 1) Determine the prices at which pegged orders are eligible for participation; 2) Evaluate Computational Orders that rely on external market data received by the ATS; 3) Determine the prices at which each security in the auction clear; 4) Maintain compliance with the Regulation NMS Order Protection Rule. NBBO FOR PRICE CONSTRAINTS: The ATS treats Midpoint Peg Orders as Limit Orders with dynamically computed limit prices. Thus, unless specified otherwise as a Computational Order constraint, Midpoint Peg Orders are eligible for price improvement when the computed clearing price for the security is more aggressive than the midpoint. Computational Orders can also specify computations based on Market Inputs, which consist of the measured NBBO and other market data. This functionality endeavors to provide all Subscribers' orders with a single, consistent view of market conditions. The following are examples of how Bidder Logic can use Market Inputs: 1) Specify limit prices based on NBBO (e.g. set a price limit to a specified amount higher or lower than NBBO); 2) Compute a momentary volume-weighted average price for a security, based on data from away venues; 3) Specify a bid price for a security as a function of the price of one or more other securities; NBBO FOR ORDER PROTECTION RULE COMPLIANCE: The ATS match procedure takes the national best bid and national best offer for a given security as lower and upper bounds (constraints) on the allowable clearing price for that security. If no clearing price within the measured NBBO results in a match for a security, the auction will not execute a trade in that security. The ATS runs multiple auctions per second, and as such the ATS reports all transactions within less than one second of measuring NBBO. MEASUREMENT OF MARKET DATA AND NBBO: The ATS constructs a view of NBBO from data provided by the SIP. Each SIP message contains a timestamp provided by the reporting exchange representing when that exchange processed the given message (the "Exchange Timestamp"). The ATS market data and matching systems use these Exchange Timestamps in an effort to construct a consistent time-aligned view of the market. The NBBO prices used in the auction are the ones most recent to but not after the Initialization Time. Below is an illustrative example of this procedure: 1) Auction Initialization results in a Cutoff Time; 2) Auction Network Buffering allows data to propagate from exchanges, to the SIP, and ultimately to the ATS; 3) After buffering the ATS computes NBBO for each tradable symbol by processing all messages from the SIP with Exchange Timestamps less than or equal to the Cutoff Time for the auction. The Exchange Timestamp for a given record is the same on the record for an event received through the SIP and the record for the same event received through lower latency proprietary direct feeds. The ATS does not subscribe to direct feeds from the national exchanges. However, the Auction Network Buffering Period is typically substantially more than the difference in latency between the SIP data feeds and the exchange direct feeds. The Operator uses a combination of time reference sources and statistical processing techniques to survey and correct inter-exchange clock synchronization issues and delays or cancels auctions during periods when the ATS market data systems flag national exchange timestamps as potentially anomalous (See ERROR CONDITIONS in Part III Item 20).

pricing_methodology

The ATS makes use of external market data (including NBBO) from the Securities Information Processor ("SIP") to: 1) Determine the prices at which pegged orders are eligible for participation; 2) Determine the prices at which each security in the auction clear; 3) Maintain compliance with the Regulation NMS Order Protection Rule. NBBO FOR PRICE CONSTRAINTS: The ATS treats Peg Orders as Limit Orders with dynamically computed limit prices. Thus, unless specified otherwise by an Expressive Bidding constraint, Peg Orders are eligible for price improvement when the computed clearing price for the security is more aggressive than the order's computed peg price (including offset, if present). NBBO FOR ORDER PROTECTION RULE COMPLIANCE: The ATS match procedure takes the national best bid and national best offer for a given security as lower and upper bounds (constraints) on the allowable clearing price for that security. If no clearing price within the measured NBBO results in a match for a security, the auction will not execute a trade in that security. The ATS runs multiple auctions per second, and as such the ATS reports all transactions within less than one second of measuring NBBO. MEASUREMENT OF MARKET DATA AND NBBO: The ATS constructs a view of NBBO from data provided by the SIP. Each SIP message contains a timestamp provided by the reporting exchange representing when that exchange processed the given message (the "Exchange Timestamp"). The ATS market data and matching systems use these Exchange Timestamps in an effort to construct a consistent time-aligned view of the market. The NBBO prices used in the auction are the ones most recent to but not after the Initialization Time. Below is an illustrative example of this procedure: 1) Auction Initialization results in a Cutoff Time; 2) Auction Network Buffering allows data to propagate from exchanges, to the SIP, and ultimately to the ATS; 3) After buffering the ATS computes NBBO for each tradable symbol by processing all messages from the SIP with Exchange Timestamps less than or equal to the Cutoff Time for the auction. The Exchange Timestamp for a given record is the same on the record for an event received through the SIP and the record for the same event received through lower latency proprietary direct feeds. The ATS does not subscribe to direct feeds from the national exchanges. However, the Auction Network Buffering Period is typically substantially more than the difference in latency between the SIP data feeds and the exchange direct feeds. The Operator uses a combination of time reference sources and statistical processing techniques to survey and correct inter-exchange clock synchronization issues and delays or cancels auctions during periods when the ATS market data systems flag national exchange timestamps as potentially anomalous (See ERROR CONDITIONS in Part III Item 20).

counterparty_selection

SELF-TRADE PREVENTION: The ATS provides a "self-trade prevention" mechanism which allows Subscribers to prevent their own orders from matching with one another (i.e. to prevent an order entered by the Subscriber from matching with another order entered by the same Subscriber), as described in Part III Item 11. CUSTOM COUNTERPARTY GROUPS: The ATS offers functionality for Subscribers to specify Custom Groups of counterparties against which to execute on an order-by-order basis for both orders and Conditional Indications. OneChronos will set up a specific Custom Group at the request of one or more Subscribers that wish to form a particular grouping, and assign them a particular Group Id. A Subscriber must provide their consent for their orders and Conditional Indications to participate in a Custom Group. Clients of Subscribers can request that OneChronos set up a Custom Group, in which case the Subscriber routing their client's orders to OneChronos must be willing to pass through the Group Id pertaining to their client's Custom Group, on the orders that should participate in the Custom Group. As noted in Part III Item 11, Subscribers may provide an execution instruction to allow execution of some or all of the order's quantity outside of the Custom Group as described in Part III Item 11. This instruction is available on both orders and Conditional Indications, with the exceptions noted in Part III Item 9 regarding matching instructions on Conditional Invites and associated Firm Up Orders. OneChronos also supports combining Custom Groups into a composite group, with its own composite Group Id, and the specification of the composite group on an order via a composite Group Id. When this feature is utilized, the order will be eligible to execute against all Custom Groups in the composite group, where the user is an existing member of those Custom Groups. Which Custom Group or Custom Groups the order executes against will be determined by which set of executions best satisfies the objective function as specified in Part III Item 11. As also discussed in Part III Item 11, orders that participate in multiple Custom Groups may receive fills at distinct prices per Custom Group. References to Custom Groups in this document also apply to composite groups. The Custom Group functionality is generally available to any Subscriber or client of a Subscriber that wishes to use it, however, OneChronos in its sole discretion may deny usage of Custom Group functionality (in whole or in part) to a Subscriber or their client in a manner consistent with the conditions discussed in Part III Item 3. As detailed in Part III Item 11, executions that occur within a Custom Group may execute at a different price from orders in the same auction that execute outside of the Group. The number of shares executed within Custom Groups is used as a tie-breaker in the optimization process described in Part 3 Item 11 under the MATCH OPTIMIZATION heading.

counterparty_selection

The ATS provides a "self-trade prevention" mechanism which allows Subscribers to prevent their own orders from matching with one another (i.e. to prevent an order entered by the Subscriber from matching with another order entered by the same Subscriber), as described in Part III Item 11.

counterparty_selection

SELF-TRADE PREVENTION: The ATS provides a "self-trade prevention" mechanism which allows Subscribers to prevent their own orders from matching with one another (i.e. to prevent an order entered by the Subscriber from matching with another order entered by the same Subscriber), as described in Part III Item 11. CUSTOM COUNTERPARTY GROUPS: The ATS offers functionality for Subscribers to specify Custom Groups of counterparties against which to execute on an order-by-order basis. OneChronos will set up a specific Custom Group at the request of one or more Subscribers that wish to form a particular grouping, and assign them a particular Group Id. A Subscriber must provide their consent for their orders to participate in a Custom Group. Clients of Subscribers can request that OneChronos set up a Custom Group, in which case the Subscriber routing their orders to OneChronos must be willing to pass through the Group Id pertaining to their client's Custom Group, on the orders that should participate in the Custom Group. OneChronos also supports combining Custom Groups into a composite group, with its own composite Group Id, and the specification of the composite group on an order via a composite Group Id. When this feature is utilized, the order will be eligible to execute against all Custom Groups in the composite group, where the user is an existing member of those Custom Groups. Which Custom Group or Custom Groups the order executes against will be determined by which set of executions best satisfies the objective function as specified in Part III Item 11. As also discussed in Part III Item 11, orders that participate in multiple Custom Groups may receive fills at distinct prices per Custom Group. The Custom Group functionality is generally available to any Subscriber or client of a Subscriber that wishes to use it, however, OneChronos in its sole discretion may deny usage of Custom Group functionality to a Subscriber or their client in a manner consistent with the conditions discussed in Part III Item 3. As detailed in Part III Item 11, executions that occur within a Custom Group may execute at a different price from orders in the same auction that execute outside of the Group.

financial_condition_summary

The commissions charged for using the ATS are calculated on a per-share basis. As discussed in this section, the commission rate is dependent on the type of transaction, as well as the origin of the order, as discussed below, with discounts available based on a Subscriber's total traded quantity over the course of a calendar month. In the event that none of the pricing described in this section applies to an execution, the execution will be charged a commission of $0.0010 per executed share. The commission structure is the same for all Subscribers, outside of Custom Groups, Expressive Orders and Firm Up Orders. CUSTOM GROUPS, EXPRESSIVE ORDERS AND FIRM UP ORDERS: The ATS does not have a standard commission schedule associated with Custom Groups, Expressive Orders or Firm Up Orders. Execution of Firm Up Orders, Expressive Orders or orders executed in a Custom Group are charged commissions in a range from $0 per share to $0.0015 per share. The commissions associated with Custom Group, Expressive Orders and Firm Up Order executions are at a negotiated rate, and the negotiated rate for a Custom Group execution, Expressive Order execution and Firm Up Order execution may be subject to different negotiated commission rates with a single Subscriber. Factors considered when negotiating commissions change from time to time and may include but are not limited to historical trading volumes and patterns, anticipated trading volumes and patterns, and the characteristics of the orders (for example, how frequently marketable the orders are, size of orders, breadth of symbols, resting times, origin of the order flow (retail or institutional), etc). The commissions charged for Custom Group, Expressive Order or Firm Up Order executions may be re-evaluated from time to time. RETAIL: Additionally, there is no commission charged for executions on orders that the Subscriber has attested, on an order-by-order basis, as originating from retail flow. This is irrespective of whether or not the executions occur inside of a Custom Group. INTRODUCTORY DISCOUNTS: As discussed in Item 19c, the Operator may offer an introductory discount period, pertaining to new Subscribers, new functionality, existing Subscribers' initial use of existing functionality, or material changes in existing Subscribers' use of existing functionality (see Item 19c) for which the Operator determines the discount amount and length of the discount period. The discounted commissions will generally be between $0.0000 and $0.0015 per share. The length of the discount period will generally be 3 to 6 months, subject to revision at the Operator's discretion (e.g. based upon onboarding progress). FEE PASSTHROUGH: In addition to the commissions described above, the Operator passes through certain regulatory fees it is assessed (e.g. Section 31 fees, and Trading Activity Fees) to Subscribers. The OneChronos ATS is the CAT Executing Broker for both the buyer and the seller on all trades it executes and the Operator is charged CAT fees accordingly, which it then passes through to Subscribers. OTHER: The ATS does not charge Subscribers for network connectivity, access, or execution data.

financial_condition_summary

The fees charged for using the ATS are calculated on a per-share basis. The fee is the same for all types of transactions, with discounts available based on a Subscriber's total traded quantity over the course of a calendar month. The base rate fee is $0.0010 per share. The commission structure is the same for all Subscribers. The Operator may offer an introductory discount period, pertaining to new Subscribers, new functionality, existing Subscribers' initial use of existing functionality, or material changes in existing Subscribers' use of existing functionality (see Item 19c) for which the Operator determines the discount amount and length of the discount period. The discounted fees will generally be between $0.0000 and $0.0005 per share. The length of the discount period will generally be 3 to 6 months, subject to revision at the Operator's discretion (e.g. based upon onboarding progress). In addition to the ATS's fees, the ATS may pass through clearing and regulatory fees it is assessed (e.g., NSCC, FINRA Section 3 fees, and Trading Activity Fees) to Subscribers. The ATS does not charge Subscribers for network connectivity, access, or execution data. Nor does the ATS compute different fees based on the type or content of orders executed.

financial_condition_summary

The commissions charged for using the ATS are calculated on a per-share basis. As discussed in this section, the commission rate is dependent on the type of transaction, as well as the origin of the order, as discussed below, with discounts available based on a Subscriber's total traded quantity over the course of a calendar month. In the event that none of the pricing described in this section applies to an execution, the execution will be charged a commission of $0.0010 per executed share. The commission structure is the same for all Subscribers, outside of Custom Groups. CUSTOM GROUPS: The ATS does not have a standard commission schedule associated with Custom Groups. Orders executed in a Custom Group are charged commissions in a range from $0 per share to $0.0015 per share. The commissions associated with Custom Group executions are at a negotiated rate. Factors considered when negotiating commissions may include but are not limited to historical trading volumes and patterns, anticipated trading volumes and patterns, and the characteristics of the orders (for example, how frequently marketable the orders are, size of orders, breadth of symbols, resting times, origin of the order flow (retail or institutional), etc). The commissions charged for Custom Group executions may be re-evaluated from time to time, as the factors previously listed change. RETAIL: Additionally, there is no commission charged for executions on orders that the Subscriber has attested, on an order-by-order basis, as originating from retail flow. This is irrespective of whether or not the executions occur inside of a Custom Group. INTRODUCTORY DISCOUNTS: As discussed in Item 19c, the Operator may offer an introductory discount period, pertaining to new Subscribers, new functionality, existing Subscribers' initial use of existing functionality, or material changes in existing Subscribers' use of existing functionality (see Item 19c) for which the Operator determines the discount amount and length of the discount period. The discounted commissions will generally be between $0.0000 and $0.0005 per share. The length of the discount period will generally be 3 to 6 months, subject to revision at the Operator's discretion (e.g. based upon onboarding progress). FEE PASSTHROUGH: In addition to the commissions described above, the Operator may pass through clearing and regulatory fees it is assessed (e.g., NSCC, Section 31 fees, and Trading Activity Fees) to Subscribers. The OneChronos ATS is the CAT Executing Broker for both the buyer and the seller on all trades it executes and the Operator is charged CAT fees accordingly, which it then passes through to Subscribers. OTHER: The ATS does not charge Subscribers for network connectivity, access, or execution data.

financial_condition_summary

The commissions charged for using the ATS are calculated on a per-share basis. As discussed in this section, the commission rate is dependent on the type of transaction, as well as the origin of the order, as discussed below, with discounts available based on a Subscriber's total traded quantity over the course of a calendar month. In the event that none of the pricing described in this section applies to an execution, the execution will be charged a commission of $0.0010 per executed share. The commission structure is the same for all Subscribers, outside of Custom Groups and Firm Up Orders. CUSTOM GROUPS AND FIRM UP ORDERS: The ATS does not have a standard commission schedule associated with Custom Groups or Firm Up Orders. Execution of Firm Up Orders or orders executed in a Custom Group are charged commissions in a range from $0 per share to $0.0015 per share. The commissions associated with Custom Group and Firm Up Order executions are at a negotiated rate, and the negotiated rate for a Custom Group execution and Firm Up Order execution may be subject to different negotiated commission rates with a single Subscriber. Factors considered when negotiating commissions change from time to time and may include but are not limited to historical trading volumes and patterns, anticipated trading volumes and patterns, and the characteristics of the orders (for example, how frequently marketable the orders are, size of orders, breadth of symbols, resting times, origin of the order flow (retail or institutional), etc). The commissions charged for Custom Group or Firm Up Order executions may be re-evaluated from time to time. RETAIL: Additionally, there is no commission charged for executions on orders that the Subscriber has attested, on an order-by-order basis, as originating from retail flow. This is irrespective of whether or not the executions occur inside of a Custom Group. INTRODUCTORY DISCOUNTS: As discussed in Item 19c, the Operator may offer an introductory discount period, pertaining to new Subscribers, new functionality, existing Subscribers' initial use of existing functionality, or material changes in existing Subscribers' use of existing functionality (see Item 19c) for which the Operator determines the discount amount and length of the discount period. The discounted commissions will generally be between $0.0000 and $0.0005 per share. The length of the discount period will generally be 3 to 6 months, subject to revision at the Operator's discretion (e.g. based upon onboarding progress). FEE PASSTHROUGH: In addition to the commissions described above, the Operator passes through certain regulatory fees it is assessed (e.g. Section 31 fees, and Trading Activity Fees) to Subscribers. The OneChronos ATS is the CAT Executing Broker for both the buyer and the seller on all trades it executes and the Operator is charged CAT fees accordingly, which it then passes through to Subscribers. OTHER: The ATS does not charge Subscribers for network connectivity, access, or execution data.

financial_condition_summary

The fees charged for using the ATS are calculated on a per-share basis. The fee is the same for all types of transactions, with discounts available based on a Subscriber's total traded quantity over the course of a calendar month. The base rate fee is $0.0010 per share. The commission structure is the same for all Subscribers. For a new Subscriber, the Operator may offer an introductory discount period, for which the Operator determines the discount amount and length of the discount period. The discounted fees will generally be between $0.0000 and $0.0005 per share. The length of the discount period will generally be 3 to 6 months, subject to revision at the Operator's discretion (e.g. based upon onboarding progress). In addition to the ATS's fees, the ATS may pass through clearing and regulatory fees it is assessed (e.g., NSCC, FINRA Section 3 fees, and Trading Activity Fees) to Subscribers. The ATS does not charge Subscribers for network connectivity, access, or execution data. Nor does the ATS compute different fees based on the type or content of orders executed.

financial_condition_summary

The commissions charged for using the ATS are calculated on a per-share basis. As discussed in this section, the commission rate is dependent on the type of transaction, as well as the origin of the order, as discussed below, with discounts available based on a Subscriber's total traded quantity over the course of a calendar month. In the event that none of the pricing described in this section applies to an execution, the execution will be charged a commission of $0.0010 per executed share. The commission structure is the same for all Subscribers, outside of Custom Groups, Expressive Orders and Firm Up Orders. CUSTOM GROUPS, EXPRESSIVE ORDERS AND FIRM UP ORDERS: The ATS does not have a standard commission schedule associated with Custom Groups, Expressive Orders or Firm Up Orders. Execution of Firm Up Orders, Expressive Orders or orders executed in a Custom Group are charged commissions in a range from $0 per share to $0.0015 per share. Orders executed in a Custom Group are charged commissions in a range from $0 per share to $0.0030 per share. The commissions associated with Custom Group, Expressive Orders and Firm Up Order executions are at a negotiated rate, and the negotiated rate for a Custom Group execution, Expressive Order execution and Firm Up Order execution may be subject to different negotiated commission rates with a single Subscriber. Factors considered when negotiating commissions change from time to time and may include but are not limited to historical trading volumes and patterns, anticipated trading volumes and patterns, and the characteristics of the orders (for example, how frequently marketable the orders are, size of orders, breadth of symbols, resting times, origin of the order flow (retail or institutional), etc). The commissions charged for Custom Group, Expressive Order or Firm Up Order executions may be re-evaluated from time to time. RETAIL: Additionally, there is no commission charged for executions on orders that the Subscriber has attested, on an order-by-order basis, as originating from retail flow. This is irrespective of whether or not the executions occur inside of a Custom Group. INTRODUCTORY DISCOUNTS: As discussed in Item 19c, the Operator may offer an introductory discount period, pertaining to new Subscribers, new functionality, existing Subscribers' initial use of existing functionality, or material changes in existing Subscribers' use of existing functionality (see Item 19c) for which the Operator determines the discount amount and length of the discount period. The discounted commissions will generally be between $0.0000 and $0.0015 per share. The length of the discount period will generally be 3 to 6 months, subject to revision at the Operator's discretion (e.g. based upon onboarding progress). FEE PASSTHROUGH: In addition to the commissions described above, the Operator passes through certain regulatory fees it is assessed (e.g. Section 31 fees, and Trading Activity Fees) to Subscribers. The OneChronos ATS is the CAT Executing Broker for both the buyer and the seller on all trades it executes and the Operator is charged CAT fees accordingly, which it then passes through to Subscribers. REBATES: As discussed in Part III Item 19(c) below, certain Subscribers in Custom Groups may pay a higher negotiated commission rate to the Operator, who will rebate part of that higher rate to the other Subscriber or Subscribers in that Custom Group. As noted above, the Operator charges a commission of $0 per share to $.0030 for executions in Custom Groups. OTHER: The ATS does not charge Subscribers for network connectivity, access, or execution data.

financial_condition_summary

The fees charged for use of the ATS are calculated on a per-share basis. For every share matched, the ATS charges a fixed fee to each counterparty. The fee is the same for all types of transactions, except where the same Subscriber provides both the buy and sell side of a trade (for example, when the Subscriber is matching two customer orders against each other). Exact fees are maintained on the ATS website and are $0.0008 per share, and $0.0003 per share for Subscribers providing both the buy and sell side of a trade (i.e. $0.0006 in total per share). However, for an introductory period, the length of which is determined by the Operator, fees for all Subscribers, for all activity, are $0.0002 per share, per side. The commission structure is the same for all Subscribers. The ATS does not currently offer volume-based or tiered pricing. In addition to the ATS's fees, the ATS passes through to Subscribers certain regulatory fees (e.g. FINRA Section 3 fees and Trading Activity Fees) it is assessed. The ATS does not charge Subscribers for network connectivity, access, or execution data. Nor does the ATS compute different fees based on the type or content of orders executed.

financial_condition_summary

The fees charged for use of the ATS are calculated on a per-share basis. For every share matched, the ATS charges a fixed fee to each counterparty. The fee is the same for all types of transactions, except where the same Subscriber provides both the buy and sell side of a trade (for example, when the Subscriber is matching two customer orders against each other). Exact fees are $0.0009 per share, and $0.0004 per share for Subscribers providing both the buy and sell side of a trade (i.e. $0.0008 in total per share). However, for an introductory period, the length of which is determined by the Operator, fees for all Subscribers, for all activity, are $0.0000 per share, per side. The commission structure is the same for all Subscribers. The ATS does not offer volume-based or tiered pricing. In addition to the ATS's fees, the ATS passes through to Subscribers certain clearing and regulatory fees (e.g. NSCC, FINRA Section 3 fees and Trading Activity Fees) it is assessed. The ATS does not charge Subscribers for network connectivity, access, or execution data. Nor does the ATS compute different fees based on the type or content of orders executed.

financial_condition_summary

The fees charged for using the ATS are calculated on a per-share basis. The fee is the same for all types of transactions, with discounts available based on a Subscriber's total traded quantity over the course of a calendar month. The base rate fee is $0.0010 per share. The commission structure is the same for all Subscribers. The Operator may offer an introductory discount period, pertaining to new Subscribers, new functionality, or existing Subscribers' initial use of existing functionality (see Item 19c) for which the Operator determines the discount amount and length of the discount period. The discounted fees will generally be between $0.0000 and $0.0005 per share. The length of the discount period will generally be 3 to 6 months, subject to revision at the Operator's discretion (e.g. based upon onboarding progress). In addition to the ATS's fees, the ATS may pass through clearing and regulatory fees it is assessed (e.g., NSCC, FINRA Section 3 fees, and Trading Activity Fees) to Subscribers. The ATS does not charge Subscribers for network connectivity, access, or execution data. Nor does the ATS compute different fees based on the type or content of orders executed.

compliance_officer

The Operator maintains Written Supervisory Procedures ("WSPs") that govern the use of Confidential Trading Information. The Operator classifies as Confidential Trading Information: orders and order handling instructions, Conditional Indications (as described in Part III Item 9), executions, clearing reports, non-tape TRF reports, risk configurations, and Bidder Logic (as described in Part II Item 5). Intraday and historical data are both considered Confidential Trading Information. The commingling of data that would otherwise not be considered confidential with Confidential Trading Information (for example, application performance logs containing raw FIX message data) is also treated as Confidential Trading Information. Individuals with access to a system that stores or processes Confidential Trading Information are considered to have access to that information. ACCESS TO AND USE OF CONFIDENTIAL TRADING INFORMATION: The Operator's activities as a broker-dealer are limited to operation of its alternative trading system. Operator employees operating the ATS may have access to Confidential Trading Information. A Series 24 registered supervisor ("ATS Supervisor") ensures the Operator restricts access to Confidential Trading Information to employees (and temporarily hired contractors, together with employees, "personnel") who are operating the ATS, those whose roles require access to such information for performing their duties, or those responsible for the Operator's compliance with Reg ATS and other applicable rules, as further described in Part II Item 7(c) below. Operator personnel with access to Confidential Trading Information are only authorized to use such information as required by their job functions, and are prohibited from using such information for trading for their own accounts. They cannot disseminate such information to anyone not authorized to receive that information. The Operator requires all employees, including those with authorized access to Confidential Trading Information, to undergo annual compliance training that includes instruction and attestation relating to the protection of Confidential Trading Information. The Operator performs at least quarterly reviews to confirm that those personnel with access to Confidential Trading Information continue to have a valid need to access such information, as described under KEY SECURITY CONTROLS below. As covered more fully in the ATS's Subscriber Agreement, the Operator's personnel and certain third parties (such as accountants and lawyers) may receive a subscriber's confidential information, which may include Confidential Trading Information, in connection with performing services for the Operator or its subsidiaries or affiliates (e.g., auditing, development or surveillance). To the extent they may receive Confidential Trading Information, such persons will be legally bound by confidentiality obligations substantially similar to those that apply to the Operator under the Subscriber Agreement. Any such Information will not be shared until a third party has satisfactorily undergone a Third Party Risk Assessment (as described below under KEY SECURITY CONTROLS). KEY SECURITY CONTROLS: The Operator employs a broad range of security controls to protect its trading systems and Confidential Trading Information. The principal controls are as follows: 1) Centralized identity management: The Operator maintains a central repository of user accounts for Operator personnel ("Internal Users"), which may include temporary contractors hired by the Operator as well as employees of the Operator. The Operator also maintains a central repository for all Subscribers and other External Users accessing the Portal described in Part II Item 5. Only an ATS Supervisor or a designee can establish new accounts for Internal Users or External Users. Internal Users may only access Confidential Trading Information if their accounts have been authorized, as discussed in the "Authorization" section in paragraph (3) below; 2) Authentication: The Operator requires the use of strong passwords meeting specified length and complexity requirements for all authenticated internal and external systems and services. Systems require multi-factor authentication whenever possible. Anti-brute-force mechanisms such as request throttling, IP whitelisting and blacklisting, account lockouts, and the use of cryptographic hashing help protect user credentials against both online and offline attacks; 3) Authorization: The Operator uses Role-based access control ("RBAC") to manage access to resources and systems for both Internal and External Users. In an RBAC process, categories of Roles are identified. Persons in particular Roles are given defined access to specific systems and resources, and thereby to specific categories of Confidential Trading Information. Accounts of specific Internal Users and External Users are granted Roles. Those Accounts can then only access a system or resource to the extent that their configured Roles allow the access. For example, an Internal User in the Operations area who requires routine access to cleared transaction information, but not to "live" orders, would be assigned an Account for which the Role was configured to deny access to live order information. A Subscriber External User would only have access to information related to its orders and transactions, and not to that of other Subscribers. The "principle of least privilege" dictates what Roles are appropriate for a given Account. The Operator's CCO or a designee of the CCO conducts periodic (at least quarterly) audits of Roles and their assignments to Accounts. These audits analyze the current and expected job functions of Operator personnel, the Roles configured for their Accounts, and whether the systems, data, and other resources accessible through those Roles are necessary for those personnel to perform their job functions. As personnel responsibilities change, e.g. through assignments to new positions or due to systems or processes re-design, the CCO or designee would assess the (continued) need for those personnel to access specific kinds of Confidential Trading Information, and, as a result, the CCO or designee may require a change in Accounts or re-configuration of Roles; 4) Encryption: the Operator requires the use of strong encryption for data in transit over any untrusted network. Transmission of unencrypted data is not permissible unless a physical security model, e.g. a private cross connect between a Subscriber and an Operator trading system, provides comparable security guarantees. Media encryption protects Confidential Trading Information (as defined in Part II Item 7(d)) as part of the nightly archival process; 5) Physical Security: all production ATS trading systems are hosted in a SOC (System and Organization Controls) certified facility (described in Part II Item 6) which employs strong security controls, such as: surveillance, physical barriers, armed security, and multi-factor access controls. This facility maintains fully redundant HVAC and power systems to reduce the risk of outages and business interruptions. Control of production trading systems happens over a physically secured private network; 6) Change Management: The Operator employs a rigorous change management process for changes to all of its production systems, including the trading systems described in Part III and the Portal described in Part II Item 5 ("Production Systems"). Any proposed changes to Production Systems are analyzed by a designated "Change Team" for: software and/or configuration integrity; adherence to regulatory requirements and disclosures; impact on systems, operations, and practices; changes to External User-facing elements; and adherence to policies and procedures. These reviews include an assessment of the impact of the change on Confidential Trading Information, including how it is processed and stored, access to the information by Internal Users and External Users, and possible vulnerability to unauthorized access or misuse. The Change Team includes senior management of the Operator and ATS System, Business Development and Compliance managers; 7) Monitoring: the ATS uses a combination of proprietary and commercial software that monitors: a) trading system status, utilization, connectivity, and message rates; b) anomalies in trading data (orders, executions, reports, market data); and c) centrally aggregated system and application log data for anomalous events and unauthorized access to critical systems and systems containing Confidential Trading Information; 8) Incident Management: The Operator maintains a documented incident response process identifying steps to investigate and remediate security incidents, and a list of designated emergency contacts to alert upon detection of a security incident; 9) Third Party Risk Assessment: The Operator maintains a list of third-party suppliers with whom it conducts business. Before integrating any new third-party supplier, the Operator conducts a risk assessment that analyzes a) the type and classification of data that third party may access, and b) the potential threats to that data. For any third parties that have access to or may reasonably receive access to Confidential Trading Information, the risk assessment includes a thorough review of the third-party's security controls, business continuity controls, data protection and privacy practices, policies and procedures. These reviews focus on the ability of the third party to protect the confidentiality, availability, and integrity of Confidential Trading Information at each point where such information is stored or processed; ATS EMPLOYEES' TRADING ACTIVITY: In accordance with FINRA Rule 3210 employees of the Operator must report to the CCO all personal investment accounts, as well as related accounts (those of immediate family members residing with the employee or to whom the employee provides material financial support, or other accounts the employee controls). These reports must be made to the CCO within 30 days of commencing employment or promptly upon opening a new account. Employees are strictly prohibited from trading on firm proprietary information, Confidential Trading Information, other confidential ATS External User information, and material non-public information ("MNPI"). The CCO surveils employee personal and related accounts for activity that may be indicative of possible abuses or violations of federal securities law, including those proscribing insider trading, which may include, as examples, excessive trading activity, activity that departs materially from typical activity in the account under review, or unusual trading activity in securities of a company with breaking news in the press. Operator employees operating the ATS may have access to External User orders and trading information; those and other employees described in Part II Item 7(d) may have access to information about Subscriber trading strategies and objectives. All Operator personnel are strictly prohibited from using any such information to their personal advantage. Annual compliance training includes materials and an attestation relating to employee trading activity, trading activity with regards to Confidential Trading Information, and identification, escalation and misuse of MNPI. The CCO reviews account statements received from broker-dealers where employees hold accounts on a monthly basis. Patterns of activity, as exemplified above, that may be indicative of insider trading or misuse of confidential data, including External User Confidential Trading Information, are subject to further scrutiny and escalation.

compliance_officer

The Operator maintains Written Supervisory Procedures ("WSPs") that govern the use of Confidential Trading Information. The Operator classifies as Confidential Trading Information: orders and order handling instructions, Conditional Indications (as described in Part III Item 9), executions, clearing reports, non-tape TRF reports, risk configurations, and Bidder Logic (as described in Part II Item 5). Intraday and historical data are both considered Confidential Trading Information. The commingling of data that would otherwise not be considered confidential with Confidential Trading Information (for example, application performance logs containing raw FIX message data) is also treated as Confidential Trading Information. Individuals with access to a system that stores or processes Confidential Trading Information are considered to have access to that information. ACCESS TO AND USE OF CONFIDENTIAL TRADING INFORMATION: The Operator's activities as a broker-dealer are limited to operation of its alternative trading system. Operator employees operating the ATS may have access to Confidential Trading Information. A Series 24 registered supervisor ("ATS Supervisor") ensures the Operator restricts access to Confidential Trading Information to employees (and temporarily hired contractors, together with employees, "personnel") who are operating the ATS, those whose roles require access to such information for performing their duties, or those responsible for the Operator's compliance with Reg ATS and other applicable rules, as further described in Part II Item 7(c) below. Operator personnel with access to Confidential Trading Information are only authorized to use such information as required by their job functions, and are prohibited from using such information for trading for their own accounts. They cannot disseminate such information to anyone not authorized to receive that information. The Operator requires all employees, including those with authorized access to Confidential Trading Information, to undergo annual compliance training that includes instruction and attestation relating to the protection of Confidential Trading Information. The Operator performs at least quarterly reviews to confirm that those personnel with access to Confidential Trading Information continue to have a valid need to access such information, as described under KEY SECURITY CONTROLS below. As covered more fully in the ATS's Subscriber Agreement, the Operator's personnel and certain third parties (such as accountants and lawyers) may receive a subscriber's confidential information, which may include Confidential Trading Information, in connection with performing services for the Operator or its subsidiaries or affiliates (e.g., auditing, development or surveillance). To the extent they may receive Confidential Trading Information, such persons will be legally bound by confidentiality obligations substantially similar to those that apply to the Operator under the Subscriber Agreement. Any such Information will not be shared until a third party has satisfactorily undergone a Third Party Risk Assessment (as described below under KEY SECURITY CONTROLS). KEY SECURITY CONTROLS: The Operator employs a broad range of security controls to protect its trading systems and Confidential Trading Information. The principal controls are as follows: 1) Centralized identity management: The Operator maintains a central repository of user accounts for Operator personnel ("Internal Users"), which may include temporary contractors hired by the Operator as well as employees of the Operator. Only an ATS Supervisor or a designee can establish new accounts for Internal Users or External Users. Internal Users may only access Confidential Trading Information if their accounts have been authorized, as discussed in the "Authorization" section in paragraph (3) below; 2) Authentication: The Operator requires the use of strong passwords meeting specified length and complexity requirements for all authenticated internal and external systems and services. Systems require multi-factor authentication whenever possible. Anti-brute-force mechanisms such as request throttling, IP whitelisting and blacklisting, account lockouts, and the use of cryptographic hashing help protect user credentials against both online and offline attacks; 3) Authorization: The Operator uses Role-based access control ("RBAC") to manage access to resources and systems for both Internal and External Users. In an RBAC process, categories of Roles are identified. Persons in particular Roles are given defined access to specific systems and resources, and thereby to specific categories of Confidential Trading Information. Accounts of specific Internal Users and External Users are granted Roles. Those Accounts can then only access a system or resource to the extent that their configured Roles allow the access. For example, an Internal User in the Operations area who requires routine access to cleared transaction information, but not to "live" orders, would be assigned an Account for which the Role was configured to deny access to live order information. A Subscriber External User would only have access to information related to its orders and transactions, and not to that of other Subscribers. The "principle of least privilege" dictates what Roles are appropriate for a given Account. The Operator's CCO or a designee of the CCO conducts periodic (at least quarterly) audits of Roles and their assignments to Accounts. These audits analyze the current and expected job functions of Operator personnel, the Roles configured for their Accounts, and whether the systems, data, and other resources accessible through those Roles are necessary for those personnel to perform their job functions. As personnel responsibilities change, e.g. through assignments to new positions or due to systems or processes re-design, the CCO or designee would assess the (continued) need for those personnel to access specific kinds of Confidential Trading Information, and, as a result, the CCO or designee may require a change in Accounts or re-configuration of Roles; 4) Encryption: the Operator requires the use of strong encryption for data in transit over any untrusted network. Transmission of unencrypted data is not permissible unless a physical security model, e.g. a private cross connect between a Subscriber and an Operator trading system, provides comparable security guarantees. Media encryption protects Confidential Trading Information (as defined in Part II Item 7(d)) as part of the nightly archival process; 5) Physical Security: all production ATS trading systems are hosted in a SOC (System and Organization Controls) certified facility (described in Part II Item 6) which employs strong security controls, such as: surveillance, physical barriers, armed security, and multi-factor access controls. This facility maintains fully redundant HVAC and power systems to reduce the risk of outages and business interruptions. Control of production trading systems happens over a physically secured private network; 6) Change Management: The Operator employs a rigorous change management process for changes to all of its production systems, including the trading systems described in Part III ("Production Systems"). Any proposed changes to Production Systems are analyzed by a designated "Change Team" for: software and/or configuration integrity; adherence to regulatory requirements and disclosures; impact on systems, operations, and practices; changes to External User-facing elements; and adherence to policies and procedures. These reviews include an assessment of the impact of the change on Confidential Trading Information, including how it is processed and stored, access to the information by Internal Users and External Users, and possible vulnerability to unauthorized access or misuse. The Change Team includes senior management of the Operator and ATS System, Business Development and Compliance managers; 7) Monitoring: the ATS uses a combination of proprietary and commercial software that monitors: a) trading system status, utilization, connectivity, and message rates; b) anomalies in trading data (orders, executions, reports, market data); and c) centrally aggregated system and application log data for anomalous events and unauthorized access to critical systems and systems containing Confidential Trading Information; 8) Incident Management: The Operator maintains a documented incident response process identifying steps to investigate and remediate security incidents, and a list of designated emergency contacts to alert upon detection of a security incident; 9) Third Party Risk Assessment: The Operator maintains a list of third-party suppliers with whom it conducts business. Before integrating any new third-party supplier, the Operator conducts a risk assessment that analyzes a) the type and classification of data that third party may access, and b) the potential threats to that data. For any third parties that have access to or may reasonably receive access to Confidential Trading Information, the risk assessment includes a thorough review of the third-party's security controls, business continuity controls, data protection and privacy practices, policies and procedures. These reviews focus on the ability of the third party to protect the confidentiality, availability, and integrity of Confidential Trading Information at each point where such information is stored or processed; ATS EMPLOYEES' TRADING ACTIVITY: In accordance with FINRA Rule 3210 employees of the Operator must report to the CCO all personal investment accounts, as well as related accounts (those of immediate family members residing with the employee or to whom the employee provides material financial support, or other accounts the employee controls). These reports must be made to the CCO within 30 days of commencing employment or promptly upon opening a new account. Employees are strictly prohibited from trading on firm proprietary information, Confidential Trading Information, other confidential ATS External User information, and material non-public information ("MNPI"). The CCO surveils employee personal and related accounts for activity that may be indicative of possible abuses or violations of federal securities law, including those proscribing insider trading, which may include, as examples, excessive trading activity, activity that departs materially from typical activity in the account under review, or unusual trading activity in securities of a company with breaking news in the press. Operator employees operating the ATS may have access to External User orders and trading information; those and other employees described in Part II Item 7(d) may have access to information about Subscriber trading strategies and objectives. All Operator personnel are strictly prohibited from using any such information to their personal advantage. Annual compliance training includes materials and an attestation relating to employee trading activity, trading activity with regards to Confidential Trading Information, and identification, escalation and misuse of MNPI. The CCO reviews account statements received from broker-dealers where employees hold accounts on a monthly basis. Patterns of activity, as exemplified above, that may be indicative of insider trading or misuse of confidential data, including External User Confidential Trading Information, are subject to further scrutiny and escalation.

compliance_officer

The Operator maintains Written Supervisory Procedures ("WSPs") that govern the use of Confidential Trading Information. The Operator classifies as Confidential Trading Information: orders and order handling instructions, executions, clearing reports, non-tape TRF reports, risk configurations, and Bidder Logic (as described in Part II Item 5). Intraday and historical data are both considered Confidential Trading Information. The commingling of data that would otherwise not be considered confidential with Confidential Trading Information (for example, application performance logs containing raw FIX message data) is also treated as Confidential Trading Information. Individuals with access to a system that stores or processes Confidential Trading Information are considered to have access to that information. ACCESS TO AND USE OF CONFIDENTIAL TRADING INFORMATION: The Operator's activities as a broker-dealer are limited to operation of its alternative trading system. Operator employees operating the ATS may have access to Confidential Trading Information. A Series 24 registered supervisor ("ATS Supervisor") ensures the Operator restricts access to Confidential Trading Information to employees (and temporarily hired contractors, together with employees, "personnel") who are operating the ATS, those whose roles require access to such information for performing their duties, or those responsible for the Operator's compliance with Reg ATS and other applicable rules, as further described in Part II Item 7(c) below. Operator personnel with access to Confidential Trading Information are only authorized to use such information as required by their job functions, and are prohibited from using such information for trading for their own accounts. They cannot disseminate such information to anyone not authorized to receive that information. The Operator requires all employees, including those with authorized access to Confidential Trading Information, to undergo annual compliance training that includes instruction and attestation relating to the protection of Confidential Trading Information. The Operator performs at least quarterly reviews to confirm that those personnel with access to Confidential Trading Information continue to have a valid need to access such information, as described under KEY SECURITY CONTROLS below. As covered more fully in the ATS's Subscriber Agreement, the Operator's personnel and certain third parties (such as accountants and lawyers) may receive a subscriber's confidential information, which may include Confidential Trading Information, in connection with performing services for the Operator or its subsidiaries or affiliates (e.g., auditing, development or surveillance). To the extent they may receive Confidential Trading Information, such persons will be legally bound by confidentiality obligations substantially similar to those that apply to the Operator under the Subscriber Agreement. Any such Information will not be shared until a third party has satisfactorily undergone a Third Party Risk Assessment (as described below under KEY SECURITY CONTROLS). KEY SECURITY CONTROLS: The Operator employs a broad range of security controls to protect its trading systems and Confidential Trading Information. The principal controls are as follows: 1) Centralized identity management: The Operator maintains a central repository of user accounts for Operator personnel ("Internal Users"), which may include temporary contractors hired by the Operator as well as employees of the Operator. The Operator also maintains a central repository for all Subscribers and other External Users accessing the Portal described in Part II Item 5. Only an ATS Supervisor or a designee can establish new accounts for Internal Users or External Users. Internal Users may only access Confidential Trading Information if their accounts have been authorized, as discussed in the "Authorization" section in paragraph (3) below; 2) Authentication: The Operator requires the use of strong passwords meeting specified length and complexity requirements for all authenticated internal and external systems and services. Systems require multi-factor authentication whenever possible. Anti-brute-force mechanisms such as request throttling, IP whitelisting and blacklisting, account lockouts, and the use of cryptographic hashing help protect user credentials against both online and offline attacks; 3) Authorization: The Operator uses Role-based access control ("RBAC") to manage access to resources and systems for both Internal and External Users. In an RBAC process, categories of Roles are identified. Persons in particular Roles are given defined access to specific systems and resources, and thereby to specific categories of Confidential Trading Information. Accounts of specific Internal Users and External Users are granted Roles. Those Accounts can then only access a system or resource to the extent that their configured Roles allow the access. For example, an Internal User in the Operations area who requires routine access to cleared transaction information, but not to "live" orders, would be assigned an Account for which the Role was configured to deny access to live order information. A Subscriber External User would only have access to information related to its orders and transactions, and not to that of other Subscribers. The "principle of least privilege" dictates what Roles are appropriate for a given Account. The Operator's CCO or a designee of the CCO conducts periodic (at least quarterly) audits of Roles and their assignments to Accounts. These audits analyze the current and expected job functions of Operator personnel, the Roles configured for their Accounts, and whether the systems, data, and other resources accessible through those Roles are necessary for those personnel to perform their job functions. As personnel responsibilities change, e.g. through assignments to new positions or due to systems or processes re-design, the CCO or designee would assess the (continued) need for those personnel to access specific kinds of Confidential Trading Information, and, as a result, the CCO or designee may require a change in Accounts or re-configuration of Roles; 4) Encryption: the Operator requires the use of strong encryption for data in transit over any untrusted network. Transmission of unencrypted data is not permissible unless a physical security model, e.g. a private cross connect between a Subscriber and an Operator trading system, provides comparable security guarantees. Media encryption protects Confidential Trading Information (as defined in Part II Item 7(d)) as part of the nightly archival process; 5) Physical Security: all production ATS trading systems are hosted in a SOC (System and Organization Controls) certified facility (described in Part II Item 6) which employs strong security controls, such as: surveillance, physical barriers, armed security, and multi-factor access controls. This facility maintains fully redundant HVAC and power systems to reduce the risk of outages and business interruptions. Control of production trading systems happens over a physically secured private network; 6) Change Management: The Operator employs a rigorous change management process for changes to all of its production systems, including the trading systems described in Part III and the Portal described in Part II Item 5 ("Production Systems"). Any proposed changes to Production Systems are analyzed by a designated "Change Team" for: software and/or configuration integrity; adherence to regulatory requirements and disclosures; impact on systems, operations, and practices; changes to External User-facing elements; and adherence to policies and procedures. These reviews include an assessment of the impact of the change on Confidential Trading Information, including how it is processed and stored, access to the information by Internal Users and External Users, and possible vulnerability to unauthorized access or misuse. The Change Team includes senior management of the Operator and ATS System, Business Development and Compliance managers; 7) Monitoring: the ATS uses a combination of proprietary and commercial software that monitors: a) trading system status, utilization, connectivity, and message rates; b) anomalies in trading data (orders, executions, reports, market data); and c) centrally aggregated system and application log data for anomalous events and unauthorized access to critical systems and systems containing Confidential Trading Information; 8) Incident Management: The Operator maintains a documented incident response process identifying steps to investigate and remediate security incidents, and a list of designated emergency contacts to alert upon detection of a security incident; 9) Third Party Risk Assessment: The Operator maintains a list of third-party suppliers with whom it conducts business. Before integrating any new third-party supplier, the Operator conducts a risk assessment that analyzes a) the type and classification of data that third party may access, and b) the potential threats to that data. For any third parties that have access to or may reasonably receive access to Confidential Trading Information, the risk assessment includes a thorough review of the third-party's security controls, business continuity controls, data protection and privacy practices, policies and procedures. These reviews focus on the ability of the third party to protect the confidentiality, availability, and integrity of Confidential Trading Information at each point where such information is stored or processed; ATS EMPLOYEES' TRADING ACTIVITY: In accordance with FINRA Rule 3210 employees of the Operator must report to the CCO all personal investment accounts, as well as related accounts (those of immediate family members residing with the employee or to whom the employee provides material financial support, or other accounts the employee controls). These reports must be made to the CCO within 30 days of commencing employment or promptly upon opening a new account. Employees are strictly prohibited from trading on firm proprietary information, Confidential Trading Information, other confidential ATS External User information, and material non-public information ("MNPI"). The CCO surveils employee personal and related accounts for activity that may be indicative of possible abuses or violations of federal securities law, including those proscribing insider trading, which may include, as examples, excessive trading activity, activity that departs materially from typical activity in the account under review, or unusual trading activity in securities of a company with breaking news in the press. Operator employees operating the ATS may have access to External User orders and trading information; those and other employees described in Part II Item 7(d) may have access to information about Subscriber trading strategies and objectives. All Operator personnel are strictly prohibited from using any such information to their personal advantage. Annual compliance training includes materials and an attestation relating to employee trading activity, trading activity with regards to Confidential Trading Information, and identification, escalation and misuse of MNPI. The CCO reviews account statements received from broker-dealers where employees hold accounts on a monthly basis. Patterns of activity, as exemplified above, that may be indicative of insider trading or misuse of confidential data, including External User Confidential Trading Information, are subject to further scrutiny and escalation.

compliance_officer

The Operator maintains Written Supervisory Procedures ("WSPs") that govern the use of Confidential Trading Information. The Operator classifies as Confidential Trading Information: orders and order handling instructions, executions, clearing reports, non-tape TRF reports, risk configurations, and Bidder Logic (as described in Part II Item 5). The commingling of data that would otherwise not be considered confidential, for example, raw FIX messages appearing in application performance logs, with Confidential Trading Information is also treated as Confidential Trading Information. Individuals with access to a system that stores or processes Confidential Trading Information are considered to have access to that information. ACCESS TO AND USE OF CONFIDENTIAL TRADING INFORMATION: The Operator's activities as a broker-dealer are limited to operation of its alternative trading system. Operator employees operating the ATS may have access to Confidential Trading Information. A Series 24 registered supervisor ("ATS Supervisor") ensures the ATS restricts access to Confidential Trading Information to employees who are operating the ATS, those whose roles require access to such information for performing their duties, or those responsible for the Operator's compliance with Reg ATS and other applicable rules, as further described in Part II Item 7(c) below. Operator personnel with access to Confidential Trading Information are only authorized to use such information as required by their job functions. They cannot disseminate such information to anyone not authorized to receive that information. The Operator requires all employees, including those with authorized access to Confidential Trading Information, to undergo annual compliance training that includes instruction and attestation relating to the protection of Confidential Trading Information. The Operator performs at least quarterly reviews to confirm that those employees with access to Confidential Trading Information continue to have a valid need to access such information, as described under KEY SECURITY CONTROLS below. KEY SECURITY CONTROLS: The Operator employs a broad range of security controls to protect trading systems and Confidential Trading Information. The principal controls are as follows: 1) Centralized identity management: The Operator maintains a central repository of user accounts for Operator personnel ("Internal Users"), which may include temporary contractors hired by the Operator as well as employees of the Operator. The Operator also maintains a central repository for all Subscribers and other External Users accessing the Portal described in Part II Item 5. Only an ATS Supervisor or a designee can establish new accounts for Internal Users or External Users. Internal Users may only access Confidential Trading Information if their accounts have been authorized, as discussed in the "Authorization" section in paragraph (3) below; 2) Authentication: The Operator requires the use of strong passwords meeting specified length and complexity requirements for all authenticated internal and external systems and services. Systems require multi-factor authentication whenever possible. Anti-brute-force mechanisms such as request throttling, IP whitelisting and blacklisting, account lockouts, and the use of cryptographic hashing help protect user credentials against both online and offline attacks; 3) Authorization: The Operator uses Role-based access control ("RBAC") to manage access to resources and systems for both Internal and External Users. In an RBAC process, categories of Roles are identified. Persons in particular Roles are given defined access to specific systems and resources, and thereby to specific categories of Confidential Trading Information. Accounts of specific Internal Users and External Users are granted Roles. Those Accounts can then only access a system or resource to the extent that their configured Roles allow the access. For example, an Internal User in the Operations area who requires routine access to cleared transaction information, but not to "live" orders, would be assigned an Account for which the Role was configured to deny access to live order information. A Subscriber External User would only have access to information related to its orders and transactions, and not to that of other Subscribers. The "principle of least privilege" dictates what Roles are appropriate for a given Account. The Operator's CCO or a designee of the CCO conducts periodic (at least quarterly) audits of Roles and their assignments to Accounts. These audits analyze the current and expected job functions of Operator personnel, the Roles configured for their Accounts, and whether the systems, data, and other resources accessible through those Roles are necessary for those personnel to perform their job functions. As personnel responsibilities change, e.g. through assignments to new positions or due to systems or processes re-design, the CCO or designee would assess the (continued) need for those personnel to access specific kinds of Confidential Trading Information, and, as a result, the CCO or designee may require a change in Accounts or re-configuration of Roles; 4) Encryption: the Operator requires the use of strong encryption for data in transit over any untrusted network. Transmission of unencrypted data is not permissible unless a physical security model, e.g. a private cross connect between a Subscriber and an Operator trading system, provides comparable security guarantees. Media encryption protects Confidential Trading Information (as defined in Part II Item 7(d)) as part of the nightly archival process; 5) Physical Security: all production ATS trading systems are hosted in a SOC (System and Organization Controls) certified facility (described in Part II Item 6) which employs strong security controls, such as: surveillance, physical barriers, armed security, and multi-factor access controls. This facility maintains fully redundant HVAC and power systems to reduce the risk of outages and business interruptions. Control of production trading systems happens over a physically secured private network; 6) Change Management: The Operator employs a rigorous change management process for changes to all of its production systems, including the trading systems described in Part III and the Portal described in Part II Item 5 ("Production Systems"). Any proposed changes to Production Systems are analyzed by a designated "Change Team" for: software and/or configuration integrity; adherence to regulatory requirements and disclosures; impact on systems, operations, and practices; changes to External User-facing elements; and adherence to policies and procedures. These reviews include an assessment of the impact of the change on Confidential Trading Information, including how it is processed and stored, access to the information by Internal Users and External Users, and possible vulnerability to unauthorized access or misuse. The Change Team includes senior management of the Operator and ATS System, Business Development and Compliance managers; 7) Monitoring: the ATS uses a combination of proprietary and commercial software that monitors: a) trading system status, utilization, connectivity, and message rates; b) anomalies in trading data (orders, executions, reports, market data); and c) centrally aggregated system and application log data for anomalous events and unauthorized access to critical systems and systems containing Confidential Trading Information; 8) Incident Management: The Operator maintains a documented incident response process identifying steps to investigate and remediate security incidents, and a list of designated emergency contacts to alert upon detection of a security incident; 9) Third Party Risk Assessment: The Operator maintains a list of third-party suppliers with whom it conducts business. Before integrating any new third-party supplier, the Operator conducts a risk assessment that analyzes a) the type and classification of data that third party may access, and b) the potential threats to that data. For any third parties that have access to or may reasonably receive access to Confidential Trading Information, the risk assessment includes a thorough review of the third-party's security controls, business continuity controls, data protection and privacy practices, policies and procedures. These reviews focus on the ability of the third party to protect the confidentiality, availability, and integrity of Confidential Trading Information at each point where such information is stored or processed; ATS EMPLOYEES' TRADING ACTIVITY: In accordance with FINRA Rule 3210 employees of the Operator must report to the CCO all personal investment accounts, as well as related accounts (those of immediate family members residing with the employee or to whom the employee provides material financial support, or other accounts the employee controls). These reports must be made to the CCO within 30 days of commencing employment or promptly upon opening a new account. Employees are strictly prohibited from trading on firm proprietary information, Confidential Trading Information, other confidential ATS External User information, and material non-public information ("MNPI"). The CCO surveils employee personal and related accounts for activity that may be indicative of possible abuses or violations of federal securities law, including those proscribing insider trading, which may include, as examples, excessive trading activity, activity that departs materially from typical activity in the account under review, or unusual trading activity in securities of a company with breaking news in the press. Operator employees operating the ATS may have access to External User orders and trading information; those and other employees described in Part II Item 7(d) may have access to information about Subscriber trading strategies and objectives. All Operator personnel are strictly prohibited from using any such information to their personal advantage. Annual compliance training includes materials and an attestation relating to employee trading activity, trading activity with regards to Confidential Trading Information, and identification, escalation and misuse of MNPI. The CCO reviews trade confirmations, ex-post, and account statements received from broker-dealers where employees hold accounts on a monthly basis. Patterns of activity, as exemplified above, that may be indicative of insider trading or misuse of confidential data, including External User Confidential Trading Information, are subject to further scrutiny and escalation.

compliance_officer

The Operator maintains Written Supervisory Procedures ("WSPs") that govern the use of Confidential Trading Information. The Operator classifies as Confidential Trading Information: orders and order handling instructions, executions, clearing reports, non-tape TRF reports, risk configurations, and Bidder Logic (as described in Part II Item 5). The commingling of data that would otherwise not be considered confidential with Confidential Trading Information (for example, application performance logs containing raw FIX message data) is also treated as Confidential Trading Information. Individuals with access to a system that stores or processes Confidential Trading Information are considered to have access to that information. ACCESS TO AND USE OF CONFIDENTIAL TRADING INFORMATION: The Operator's activities as a broker-dealer are limited to operation of its alternative trading system. Operator employees operating the ATS may have access to Confidential Trading Information. A Series 24 registered supervisor ("ATS Supervisor") ensures the Operator restricts access to Confidential Trading Information to employees (and temporarily hired contractors, together with employees, "personnel") who are operating the ATS, those whose roles require access to such information for performing their duties, or those responsible for the Operator's compliance with Reg ATS and other applicable rules, as further described in Part II Item 7(c) below. Operator personnel with access to Confidential Trading Information are only authorized to use such information as required by their job functions, and are prohibited from using such information for trading for their own accounts. They cannot disseminate such information to anyone not authorized to receive that information. The Operator requires all employees, including those with authorized access to Confidential Trading Information, to undergo annual compliance training that includes instruction and attestation relating to the protection of Confidential Trading Information. The Operator performs at least quarterly reviews to confirm that those personnel with access to Confidential Trading Information continue to have a valid need to access such information, as described under KEY SECURITY CONTROLS below. As covered more fully in the ATS's Subscriber Agreement, the Operator's personnel and certain third parties (such as accountants and lawyers) may receive a subscriber's confidential information, which may include Confidential Trading Information, in connection with performing services for the Operator or its subsidiaries or affiliates (e.g., auditing, development or surveillance). To the extent they may receive Confidential Trading Information, such persons will be legally bound by confidentiality obligations substantially similar to those that apply to the Operator under the Subscriber Agreement. Any such Information will not be shared until a third party has satisfactorily undergone a Third Party Risk Assessment (as described below under KEY SECURITY CONTROLS). KEY SECURITY CONTROLS: The Operator employs a broad range of security controls to protect its trading systems and Confidential Trading Information. The principal controls are as follows: 1) Centralized identity management: The Operator maintains a central repository of user accounts for Operator personnel ("Internal Users"), which may include temporary contractors hired by the Operator as well as employees of the Operator. The Operator also maintains a central repository for all Subscribers and other External Users accessing the Portal described in Part II Item 5. Only an ATS Supervisor or a designee can establish new accounts for Internal Users or External Users. Internal Users may only access Confidential Trading Information if their accounts have been authorized, as discussed in the "Authorization" section in paragraph (3) below; 2) Authentication: The Operator requires the use of strong passwords meeting specified length and complexity requirements for all authenticated internal and external systems and services. Systems require multi-factor authentication whenever possible. Anti-brute-force mechanisms such as request throttling, IP whitelisting and blacklisting, account lockouts, and the use of cryptographic hashing help protect user credentials against both online and offline attacks; 3) Authorization: The Operator uses Role-based access control ("RBAC") to manage access to resources and systems for both Internal and External Users. In an RBAC process, categories of Roles are identified. Persons in particular Roles are given defined access to specific systems and resources, and thereby to specific categories of Confidential Trading Information. Accounts of specific Internal Users and External Users are granted Roles. Those Accounts can then only access a system or resource to the extent that their configured Roles allow the access. For example, an Internal User in the Operations area who requires routine access to cleared transaction information, but not to "live" orders, would be assigned an Account for which the Role was configured to deny access to live order information. A Subscriber External User would only have access to information related to its orders and transactions, and not to that of other Subscribers. The "principle of least privilege" dictates what Roles are appropriate for a given Account. The Operator's CCO or a designee of the CCO conducts periodic (at least quarterly) audits of Roles and their assignments to Accounts. These audits analyze the current and expected job functions of Operator personnel, the Roles configured for their Accounts, and whether the systems, data, and other resources accessible through those Roles are necessary for those personnel to perform their job functions. As personnel responsibilities change, e.g. through assignments to new positions or due to systems or processes re-design, the CCO or designee would assess the (continued) need for those personnel to access specific kinds of Confidential Trading Information, and, as a result, the CCO or designee may require a change in Accounts or re-configuration of Roles; 4) Encryption: the Operator requires the use of strong encryption for data in transit over any untrusted network. Transmission of unencrypted data is not permissible unless a physical security model, e.g. a private cross connect between a Subscriber and an Operator trading system, provides comparable security guarantees. Media encryption protects Confidential Trading Information (as defined in Part II Item 7(d)) as part of the nightly archival process; 5) Physical Security: all production ATS trading systems are hosted in a SOC (System and Organization Controls) certified facility (described in Part II Item 6) which employs strong security controls, such as: surveillance, physical barriers, armed security, and multi-factor access controls. This facility maintains fully redundant HVAC and power systems to reduce the risk of outages and business interruptions. Control of production trading systems happens over a physically secured private network; 6) Change Management: The Operator employs a rigorous change management process for changes to all of its production systems, including the trading systems described in Part III and the Portal described in Part II Item 5 ("Production Systems"). Any proposed changes to Production Systems are analyzed by a designated "Change Team" for: software and/or configuration integrity; adherence to regulatory requirements and disclosures; impact on systems, operations, and practices; changes to External User-facing elements; and adherence to policies and procedures. These reviews include an assessment of the impact of the change on Confidential Trading Information, including how it is processed and stored, access to the information by Internal Users and External Users, and possible vulnerability to unauthorized access or misuse. The Change Team includes senior management of the Operator and ATS System, Business Development and Compliance managers; 7) Monitoring: the ATS uses a combination of proprietary and commercial software that monitors: a) trading system status, utilization, connectivity, and message rates; b) anomalies in trading data (orders, executions, reports, market data); and c) centrally aggregated system and application log data for anomalous events and unauthorized access to critical systems and systems containing Confidential Trading Information; 8) Incident Management: The Operator maintains a documented incident response process identifying steps to investigate and remediate security incidents, and a list of designated emergency contacts to alert upon detection of a security incident; 9) Third Party Risk Assessment: The Operator maintains a list of third-party suppliers with whom it conducts business. Before integrating any new third-party supplier, the Operator conducts a risk assessment that analyzes a) the type and classification of data that third party may access, and b) the potential threats to that data. For any third parties that have access to or may reasonably receive access to Confidential Trading Information, the risk assessment includes a thorough review of the third-party's security controls, business continuity controls, data protection and privacy practices, policies and procedures. These reviews focus on the ability of the third party to protect the confidentiality, availability, and integrity of Confidential Trading Information at each point where such information is stored or processed; ATS EMPLOYEES' TRADING ACTIVITY: In accordance with FINRA Rule 3210 employees of the Operator must report to the CCO all personal investment accounts, as well as related accounts (those of immediate family members residing with the employee or to whom the employee provides material financial support, or other accounts the employee controls). These reports must be made to the CCO within 30 days of commencing employment or promptly upon opening a new account. Employees are strictly prohibited from trading on firm proprietary information, Confidential Trading Information, other confidential ATS External User information, and material non-public information ("MNPI"). The CCO surveils employee personal and related accounts for activity that may be indicative of possible abuses or violations of federal securities law, including those proscribing insider trading, which may include, as examples, excessive trading activity, activity that departs materially from typical activity in the account under review, or unusual trading activity in securities of a company with breaking news in the press. Operator employees operating the ATS may have access to External User orders and trading information; those and other employees described in Part II Item 7(d) may have access to information about Subscriber trading strategies and objectives. All Operator personnel are strictly prohibited from using any such information to their personal advantage. Annual compliance training includes materials and an attestation relating to employee trading activity, trading activity with regards to Confidential Trading Information, and identification, escalation and misuse of MNPI. The CCO reviews account statements received from broker-dealers where employees hold accounts on a monthly basis. Patterns of activity, as exemplified above, that may be indicative of insider trading or misuse of confidential data, including External User Confidential Trading Information, are subject to further scrutiny and escalation.

compliance_officer

The Operator maintains Written Supervisory Procedures ("WSPs") that govern the use of Confidential Trading Information. The Operator classifies as Confidential Trading Information: orders and order handling instructions, executions, clearing reports, non-tape TRF reports, risk configurations, and Bidder Logic (as described in Part II Item 5). Confidential Trading Information may consist of historical data, intraday data, or both. The commingling of data that would otherwise not be considered confidential with Confidential Trading Information (for example, application performance logs containing raw FIX message data) is also treated as Confidential Trading Information. Individuals with access to a system that stores or processes Confidential Trading Information are considered to have access to that information. ACCESS TO AND USE OF CONFIDENTIAL TRADING INFORMATION: The Operator's activities as a broker-dealer are limited to operation of its alternative trading system. Operator employees operating the ATS may have access to Confidential Trading Information. A Series 24 registered supervisor ("ATS Supervisor") ensures the Operator restricts access to Confidential Trading Information to employees (and temporarily hired contractors, together with employees, "personnel") who are operating the ATS, those whose roles require access to such information for performing their duties, or those responsible for the Operator's compliance with Reg ATS and other applicable rules, as further described in Part II Item 7(c) below. Operator personnel with access to Confidential Trading Information are only authorized to use such information as required by their job functions, and are prohibited from using such information for trading for their own accounts. They cannot disseminate such information to anyone not authorized to receive that information. The Operator requires all employees, including those with authorized access to Confidential Trading Information, to undergo annual compliance training that includes instruction and attestation relating to the protection of Confidential Trading Information. The Operator performs at least quarterly reviews to confirm that those personnel with access to Confidential Trading Information continue to have a valid need to access such information, as described under KEY SECURITY CONTROLS below. As covered more fully in the ATS's Subscriber Agreement, the Operator's personnel and certain third parties (such as accountants and lawyers) may receive a subscriber's confidential information, which may include Confidential Trading Information, in connection with performing services for the Operator or its subsidiaries or affiliates (e.g., auditing, development or surveillance). To the extent they may receive Confidential Trading Information, such persons will be legally bound by confidentiality obligations substantially similar to those that apply to the Operator under the Subscriber Agreement. Any such Information will not be shared until a third party has satisfactorily undergone a Third Party Risk Assessment (as described below under KEY SECURITY CONTROLS). KEY SECURITY CONTROLS: The Operator employs a broad range of security controls to protect its trading systems and Confidential Trading Information. The principal controls are as follows: 1) Centralized identity management: The Operator maintains a central repository of user accounts for Operator personnel ("Internal Users"), which may include temporary contractors hired by the Operator as well as employees of the Operator. The Operator also maintains a central repository for all Subscribers and other External Users accessing the Portal described in Part II Item 5. Only an ATS Supervisor or a designee can establish new accounts for Internal Users or External Users. Internal Users may only access Confidential Trading Information if their accounts have been authorized, as discussed in the "Authorization" section in paragraph (3) below; 2) Authentication: The Operator requires the use of strong passwords meeting specified length and complexity requirements for all authenticated internal and external systems and services. Systems require multi-factor authentication whenever possible. Anti-brute-force mechanisms such as request throttling, IP whitelisting and blacklisting, account lockouts, and the use of cryptographic hashing help protect user credentials against both online and offline attacks; 3) Authorization: The Operator uses Role-based access control ("RBAC") to manage access to resources and systems for both Internal and External Users. In an RBAC process, categories of Roles are identified. Persons in particular Roles are given defined access to specific systems and resources, and thereby to specific categories of Confidential Trading Information. Accounts of specific Internal Users and External Users are granted Roles. Those Accounts can then only access a system or resource to the extent that their configured Roles allow the access. For example, an Internal User in the Operations area who requires routine access to cleared transaction information, but not to "live" orders, would be assigned an Account for which the Role was configured to deny access to live order information. A Subscriber External User would only have access to information related to its orders and transactions, and not to that of other Subscribers. The "principle of least privilege" dictates what Roles are appropriate for a given Account. The Operator's CCO or a designee of the CCO conducts periodic (at least quarterly) audits of Roles and their assignments to Accounts. These audits analyze the current and expected job functions of Operator personnel, the Roles configured for their Accounts, and whether the systems, data, and other resources accessible through those Roles are necessary for those personnel to perform their job functions. As personnel responsibilities change, e.g. through assignments to new positions or due to systems or processes re-design, the CCO or designee would assess the (continued) need for those personnel to access specific kinds of Confidential Trading Information, and, as a result, the CCO or designee may require a change in Accounts or re-configuration of Roles; 4) Encryption: the Operator requires the use of strong encryption for data in transit over any untrusted network. Transmission of unencrypted data is not permissible unless a physical security model, e.g. a private cross connect between a Subscriber and an Operator trading system, provides comparable security guarantees. Media encryption protects Confidential Trading Information (as defined in Part II Item 7(d)) as part of the nightly archival process; 5) Physical Security: all production ATS trading systems are hosted in a SOC (System and Organization Controls) certified facility (described in Part II Item 6) which employs strong security controls, such as: surveillance, physical barriers, armed security, and multi-factor access controls. This facility maintains fully redundant HVAC and power systems to reduce the risk of outages and business interruptions. Control of production trading systems happens over a physically secured private network; 6) Change Management: The Operator employs a rigorous change management process for changes to all of its production systems, including the trading systems described in Part III and the Portal described in Part II Item 5 ("Production Systems"). Any proposed changes to Production Systems are analyzed by a designated "Change Team" for: software and/or configuration integrity; adherence to regulatory requirements and disclosures; impact on systems, operations, and practices; changes to External User-facing elements; and adherence to policies and procedures. These reviews include an assessment of the impact of the change on Confidential Trading Information, including how it is processed and stored, access to the information by Internal Users and External Users, and possible vulnerability to unauthorized access or misuse. The Change Team includes senior management of the Operator and ATS System, Business Development and Compliance managers; 7) Monitoring: the ATS uses a combination of proprietary and commercial software that monitors: a) trading system status, utilization, connectivity, and message rates; b) anomalies in trading data (orders, executions, reports, market data); and c) centrally aggregated system and application log data for anomalous events and unauthorized access to critical systems and systems containing Confidential Trading Information; 8) Incident Management: The Operator maintains a documented incident response process identifying steps to investigate and remediate security incidents, and a list of designated emergency contacts to alert upon detection of a security incident; 9) Third Party Risk Assessment: The Operator maintains a list of third-party suppliers with whom it conducts business. Before integrating any new third-party supplier, the Operator conducts a risk assessment that analyzes a) the type and classification of data that third party may access, and b) the potential threats to that data. For any third parties that have access to or may reasonably receive access to Confidential Trading Information, the risk assessment includes a thorough review of the third-party's security controls, business continuity controls, data protection and privacy practices, policies and procedures. These reviews focus on the ability of the third party to protect the confidentiality, availability, and integrity of Confidential Trading Information at each point where such information is stored or processed; ATS EMPLOYEES' TRADING ACTIVITY: In accordance with FINRA Rule 3210 employees of the Operator must report to the CCO all personal investment accounts, as well as related accounts (those of immediate family members residing with the employee or to whom the employee provides material financial support, or other accounts the employee controls). These reports must be made to the CCO within 30 days of commencing employment or promptly upon opening a new account. Employees are strictly prohibited from trading on firm proprietary information, Confidential Trading Information, other confidential ATS External User information, and material non-public information ("MNPI"). The CCO surveils employee personal and related accounts for activity that may be indicative of possible abuses or violations of federal securities law, including those proscribing insider trading, which may include, as examples, excessive trading activity, activity that departs materially from typical activity in the account under review, or unusual trading activity in securities of a company with breaking news in the press. Operator employees operating the ATS may have access to External User orders and trading information; those and other employees described in Part II Item 7(d) may have access to information about Subscriber trading strategies and objectives. All Operator personnel are strictly prohibited from using any such information to their personal advantage. Annual compliance training includes materials and an attestation relating to employee trading activity, trading activity with regards to Confidential Trading Information, and identification, escalation and misuse of MNPI. The CCO reviews account statements received from broker-dealers where employees hold accounts on a monthly basis. Patterns of activity, as exemplified above, that may be indicative of insider trading or misuse of confidential data, including External User Confidential Trading Information, are subject to further scrutiny and escalation.

hours_of_operation

The ATS operates Monday through Friday according to the standard market hours schedule below, with the exception of the following holidays: New Years Day, Martin Luther King Jr. Day, Presidents' Day, Good Friday, Memorial Day, Independence Day, Labor Day, Thanksgiving Day, and Christmas Day. Standard Market Hours (US Eastern time): 1) 8:00am: begin accepting FIX connections / sessions; 2) 9:15am: begin accepting orders; 3) 9:30am: begin executing orders (i.e. first call auction will take place at or after 9:30am); 4) 4:00pm: stop executing orders (i.e. final call auction will take place at or before 4:00pm)*; 5) 5:00pm: all FIX sessions disconnected. * The ATS stops executing orders at 1:00pm instead of 4:00pm on: the day prior to observed Christmas Day, the day prior to observed Independence Day, and the day after Thanksgiving Day. FIX sessions are disconnected at 2:00pm instead of 5:00pm on these days. While the ATS only accepts orders as described above, the Portal defined in Part II Item 5 is available on any calendar day.

hours_of_operation

The ATS operates Monday through Friday according to the standard market hours schedule below, with the exception of the following holidays: New Years Day, Martin Luther King Jr. Day, Presidents' Day, Good Friday, Memorial Day, Independence Day, Labor Day, Thanksgiving Day, and Christmas Day. Standard Market Hours (US Eastern time): 1) 8:00am: begin accepting FIX connections / sessions; 2) 9:15am: begin accepting orders; 3) 9:30am: begin executing orders (i.e. first call auction will take place at or after 9:30am); 4) 4:00pm: stop executing orders (i.e. final call auction will take place at or before 4:00pm)*; 5) 5:00pm: all FIX sessions disconnected. * The ATS stops executing orders at 1:00pm instead of 4:00pm on: the day prior to observed Christmas Day, the day prior to observed Independence Day, and the day after Thanksgiving Day. FIX sessions are disconnected at 2:00pm instead of 5:00pm on these days. While the ATS only accepts orders as described above, the Portal defined in Part II Item 5 is available on any calendar day.

hours_of_operation

The ATS operates Monday through Friday according to the standard market hours schedule below, with the exception of the following NYSE market holidays: New Years Day, Martin Luther King Jr. Day, Presidents' Day, Good Friday, Memorial Day, Juneteenth National Independence Day, Independence Day, Labor Day, Thanksgiving Day, and Christmas Day. Standard Market Hours (US Eastern time): 1) 8:00am: begin accepting FIX connections / sessions; 2) 9:15am: begin accepting orders; 3) 9:30am: begin executing orders (i.e. first call auction will take place at or after 9:30am); 4) 4:00pm: stop executing orders (i.e. final call auction will take place at or before 4:00pm)*; 5) 5:00pm: all FIX sessions disconnected. * The ATS stops executing orders at 1:00pm instead of 4:00pm on: the day prior to observed Christmas Day, the day prior to observed Independence Day, and the day after Thanksgiving Day. FIX sessions are disconnected at 2:00pm instead of 5:00pm on these days. While the ATS only accepts orders as described above, the Portal defined in Part II Item 5 is available on any calendar day.

hours_of_operation

The ATS operates Monday through Friday according to the standard market hours schedule below, with the exception of the following NYSE market holidays: New Years Day, Martin Luther King Jr. Day, Presidents' Day, Good Friday, Memorial Day, Juneteenth National Independence Day, Independence Day, Labor Day, Thanksgiving Day, and Christmas Day. Standard Market Hours (US Eastern time): 1) 8:00am: begin accepting FIX connections / sessions; 2) 9:15am: begin accepting orders; 3) 9:30am: begin executing orders (i.e. first call auction will take place at or after 9:30am); 4) 4:00pm: stop executing orders (i.e. final call auction will take place at or before 4:00pm)*; 5) 5:00pm: all FIX sessions disconnected. * The ATS stops executing orders at 1:00pm instead of 4:00pm on: the day prior to observed Christmas Day, the day prior to observed Independence Day, and the day after Thanksgiving Day. FIX sessions are disconnected at 2:00pm instead of 5:00pm on these days.

display_best_quotes

The OneChronos ATS does not display firm orders. When handling Conditional Indications, the OneChronos ATS will communicate a Conditional Invitation to the Subscriber that sent the Conditional Indication, making them aware that eligible counterparty liquidity exists, as described in Part III Item 9. The information contained within the Conditional Invitation is the same as the information within the associated Conditional Indication, with the addition of an Invitation ID as described in Part III Item 9. As the Broker-Dealer Operator does not route orders to its ATS, it does not send Conditional Indications or receive Conditional Invitations.

execution_services

OPENING PROCEDURE: The ATS begins accepting orders before trading commences (before the "opening auction"), at the dates and times specified in Part III Item 4. The opening auction will take place after the opening time specified in Part III Item 4. As a general matter, this and all other auctions will include any NMS securities for which there has been an opening or a re-opening print from the primary listing exchange for that security.; PRIORITY, MATCHING, EXECUTION: orders are prioritized, matched, and executed in an opening or re-opening auction in the same manner as subsequent auctions, as described in Part III Items 11(a) and 11(c); ORDER TYPES: all order types specified in Part III Item 8 are accepted for opening and re-opening auctions.