The Q2 2016 Release

20th January 2016

Cboe announced the Q2 2016 Exchange Release in January 2016. Alongside the decommissioning of unrelated order types and services, this release represents the first major functionality change related to MiFID II compliance. In addition to the key changes listed below, a Guidance Note contains fuller details to help guide participants with the transition.

Cboe Auction Feed

  • MiFID II requires disaggregation of scheduled daily auctions. The Cboe Auction Feed captures all relevant auction activity in an environment, so for those users only interested in consuming scheduled daily auctions, this provides a low bandwidth alternative to consuming PITCH feeds. The Cboe Auction Feed in BXE provides Periodic Auction data and in CXE provides Opening and Closing Auction data.
  • Refer to the Specification.

Last Sale Feed

  • MiFID II requires post-trade data to be disaggregated from pre-trade data. The Last Sale Feed excludes pre-trade data. Post-trade data users can use this feed for a low bandwidth alternative to consuming full depth PITCH feeds.
  • MiFID II requires post-trade transparent data to be published in a specific format, with the goal of reducing frictional costs of consuming feeds from multiple trading venues. The Last Sale Feed message structure follows the prescribed format mandated by RTS 1: Equity Transparency
  • Refer to the Specification.

Market Data

  • MiFID II requires trade cancellations to be published with a message that contains the details of the original trade, as well as a specific cancellation flag. Currently, order book trade cancellations are published using a Trade Break message, which does not contain sufficient information. These cancellations will transition to use of the Trade - Extended message, which provides the appropriate granularity to meet this requirement.
  • MiFID II requires any trade amendments to be published as two messages. The first should represent a cancellation of the original trade, while the second should represent the new details of the trade. Currently, trade report amendments are only published with the new details of the trade, but these will transition to the prescribed sequence.
  • MiFID II requires trades to be published with the Market Identification Code (MIC) of the trading venue, or with SINT for trades from Systematic Internalisers and XOFF for trades not conducted on a trading venue or a Systematic Internaliser. Within the BXTR Trade Reporting environment, Over the Counter (OTC) and Systematic Internaliser trades are currently published with the Trade - Extended message, with the Execution Venue field left blank. This release will transition to the prescribed values of XOFF and SINT.
  • More information on Market Data and MiFID II.

Symbol File

  • MiFID II requires trading venues to have an unexecuted order to transaction ratio (OTR), calculated on the number-of-orders basis and a volume-of-shares basis, as part of their system of controls to prevent disorderly trading conditions. Though Cboe is not seeking to introduce an OTR at this time, when it does, Cboe will set the maximum acceptable OTR at the symbol level. New columns added to the file allow Participants to be aware of the relevant thresholds when they're introduced.
  • MiFID II imposes a limit on the volume of transactions that can be conducted using certain pre-trade transparency waivers. Should those thresholds be breached, various symbols will not be available to trade under these waivers. MiFID II also requires trading venues to make efforts to ensure that they do not permit activity to occur that would breach the thresholds. Accordingly, Cboe may also choose to limit trading in affected symbols ahead of any such breach. New columns added to the file will ensure Participants will be aware of any such limitations.


  • As mentioned above, MiFID II imposes a limit on the volume of transactions that can be conducted using certain pre-trade transparency waivers. Should a symbol not be available to trade due to this requirement, any orders or trade reports entered that might use such waivers will be rejected. The reject message will include a reason code to indicate that the rejection was related to the Double Volume Caps.
  • With Exchange Trade Reports (ETRs) entered into BXE or CXE, customers currently set the OrderCategory input field to indicate the trade is being conducted as a Negotiated Transaction under Cboe rules. Within FIX, any trade acknowledgements and confirmations include the field confirming first that Cboe acknowledges that the Participant believes it to be a trade conducted as a Negotiated Transaction under Cboe rules. The trade is then regarded as a Negotiated Transaction (and accordingly, uses the Negotiated Transaction waiver). This field is being added to BOEv2 to allow similar information to be communicated within this protocol.