Differences with prior versions of BOE

Notable differences between BOEv3 and the prior major version of BOE (BOEv2) include:

1. BOEv3 has statically sized messages except when sizing variability is required due to (statically sized) repeating groups of fields. Consequently, BOEv3 does not support optional fields on input nor bitfield-specified optional return fields. This provides a more consistent and predictable experience for all users.
2. Connectivity is now managed as a port specific to a matching unit. Consequently, separate ports will be required for access to each matching unit.
   1. A "convenience" BOEv3 port will be made available which will allow for a single connection to interact with all matching units. Note that using a convenience port will incur an incremental latency cost due to the additional communication layer.
3. The Logout Response message no longer returns the LastReceivedSequenceNumber, nor the highest available sequence numbers of the matching unit(s).
4. There is no longer a systematically enforced limit on the number of open orders or quotes a firm may have entered on the exchange from a unitized port.
5. BOEv3 requires the EFID (ClearingFirm) be specified on all Cancel Order and Modify Order messages (either via Port default or by specifying in the message). This differs from prior versions of BOE where this was only required of service bureau members.
6. When logging in, members may specify a behavior of "Fail" for unspecified matching units (fail the login if a matching unit was not specified). This in addition to the "Skip" and "Replay" behaviors, as detailed in Login, Replay, and Sequencing.
7. Logging in may specify a "deep replay" mode, available on the inactive session. See Failover and Disaster Recovery (DR).
8. The Cancel Order message type now cancels a single order. A new message type Mass Cancel Order provides all multi-order cancellation requests.
9. There no longer exists a condition where a member would send a Modify Order followed immediately by a Cancel Order message and it was not deterministic as to which OrigClOrdId value was correct on the Cancel Order message. In BOEv3, the OrigClOrdId on a cancel should be the ClOrdId sent on the most recent Modify Order (or New Order if no modifies have been sent), even if the corresponding response has not yet been seen. CancelOrigOnReject should be set to Y to ensure that a rejected Modify Order does not leave behind a live order.
10. Member risk trips and self-imposed lockouts are now required to be reset using the Reset Risk message. They can no longer be reset via the New Order message.
11. An in flight field has been added to most return messages, informing the member of the total number of messages received by the BOE3 order handler which have not yet been acknowledged by the matching engine(s).
12. A ScratchPad field has been added to messages sent from the Member to Cboe. This two byte field is located at or near the end of the message structure and can be used for a Member’s own internal purposes.
13. BOEv3 Trade Cancel or Correct messages are not suppressible by port parameter.
14. Added requirement for members to record and connect to secondary IP in event of failover to secondary port in the primary, Secaucus Datacenter as detailed in Failover and Disaster Recovery (DR)
15. Risk resets on a BOEv3 unitized port only apply for the unit associated with that port. BOEv2, BOEv3 convenience, and FIX ports risk resets may optionally apply to all units.
16. In many of the messages from Cboe to Member, the fixed set of fields in the response will be fewer than the total number of fixed and optional fields available over BOEv2.
17. For sequenced messages from Member to Cboe, a sequence number of 0 will always be accepted and is treated as if it were the next expected sequence number.
18. Symbol Order Rate threshold is no longer an available risk port attribute for BOEv3.

19. The Complex Instrument Accepted message does not provide an indication as to whether or not legs have been reordered relative to the original request. Members should always assume reordering has occurred (or compare against a cached copy of their request).