Release Notes

REMINDER: Cboe Europe Equities: MiFID II Order Record Keeping requirement, effective Fri 1st Dec, 2017

October 31, 2017 15:55:48

Dear Cboe Europe Participants
In preparation for the RTS 24 Order Record Keeping (ORK) MiFID II requirement, Participants submitting orders onto the Cboe Europe BXE and CXE platforms will be required to populate the relevant ORK fields per order, as well as register their short code/long code mappings in Production by Friday, 1st December, 2017.

Summary

* RTS 24: Record Keeping - Trading venues are required to maintain records of all orders submitted into their systems. Cboe Europe's approach involves requiring 'short code IDs' on orders and then Participants supplying the mapping from those short codes to their longer form National IDs or Algorithm IDs through a mapping file out of band. This mapping is stored securely until such time as a regulator requests the relevant order records. In order to meet this requirement, all Participants submitting orders onto the Cboe Europe BXE and CXE platforms are required to populate the relevant ORK fields per order, as well as register their short code/long code mappings. Whilst Cboe Europe will verify whether identifiers are supplied on orders, Cboe Europe will not reject orders in real-time in the event of missing short code or the use of unregistered short codes.
Details

* Required ORK fields are ClientID, Investment Decision Maker, Executing Decision Maker, Direct Electronic Access (DEA), Liquidity Provision Activity order, and Algorithmic order. FIX/BOE field details summarised below:

Record Keeping Information

Content of the order details to be maintained by Cboe Europe at the disposal of the competent authority

FIX tags to supply

BOE fields to supply

Client identification code

Code used to identify the client of the member or participant of the trading venue. In case of DEA, the code of the DEA user should be provided.

Where the client is a legal entity, the LEI code of the client shall be used.

Where the client is not a legal entity, the {NATIONAL_ID} shall be used. In the case of aggregated orders, the flag AGGR shall be used.

In case of pending allocations, the flag PNAL shall be used.
This field shall be left blank only if the member or participant of the trading venue has no client.

Where the order is for a single client who is a legal entity:
PartyID (448) = Short Code ID / 0 (NONE) / 1 (AGGR) / 2 (PNAL)
PartyRole(452) = 3 (Client ID)
PartyIDSource(447) = P (Short code identifier)
PartyRoleQualifier(2376) = 0 (where PartyID is 0, 1 or 2) or 23 (Firm or Legal Entity)

Where the order is for a single client who is not a legal entity:
PartyID (448) = Short Code ID / 0 (NONE) / 1 (AGGR) / 2 (PNAL)
PartyRole(452) = 3 (Client ID)
PartyIDSource(447) = P (Short code identifier)
PartyRoleQualifier(2376) = 0 (where PartyID is 0, 1 or 2) or 24 (Natural Person)

Where the order is for a single client who is a legal entity:
ClientID = Short Code ID / 0 (NONE) / 1 (AGGR) / 2 (PNAL)
ClientQualifiedRole = 0 (where ClientID is 0, 1 or 2) or 23 (Firm or LEI)
Where the order is for a single client who is not a legal entity:
ClientID = Short Code ID / 0 (NONE) / 1 (AGGR) / 2 (PNAL)
ClientQualifiedRole = 0 (where ClientID is 0, 1 or 2) or 24 (Natural Person)

Investment decision within firm

Code used to identify the person or the algorithm within the member or participant of the trading venue who is responsible for the investment decision.

Where a natural person(s) within the member or participant of the trading venue is responsible for the investment decision the person who is responsible or has primary responsibility for the investment decision shall be identified with the {NATIONAL_ID}

Where an algorithm is responsible for the investment decision the field shall be populated in accordance with Article 8 of Commission Delegated Regulation (EU) 2017/590 on transaction reporting (RTS 22).

This field shall be left blank when the investment decision was not made by a person or algorithm within the member or participant of the trading venue.

Where decision maker is a trader:
PartyID (448) = Short Code ID
PartyRole(452) = 122 (Investment decision maker)
PartyIDSource(447) = P (Short code identifier)
PartyRoleQualifier(2376) = 24 (Natural Person)

Where decision maker is an algorithm:
PartyID (448) = Short Code ID
PartyRole(452) = 122 (Investment decision maker)
PartyIDSource(447) = P (Short code identifier)
PartyRoleQualifier(2376) = 22 (Algorithm)

Where decision maker is a trader:
InvestorID = Short Code ID
InvestorQualifiedRole = 24 (Natural Person)

Where decision maker is an algorithm:
InvestorID = Short Code ID
InvestorQualifiedRole = 22 (Algorithm)

Execution decision within firm

Code used to identify the person or algorithm within the member or participant of the trading venue who is responsible for the execution of the transaction resulting from the order.

Where a natural person is responsible for the execution of the transaction, the person shall be identified by {NATIONAL_ID}

Where an algorithm is responsible for the execution of the transaction, this field shall be populated in accordance with Article 9 of Commission Delegated Regulation (EU) 2017/590 on transaction reporting (RTS 22).

Where more than one person or a combination of persons and algorithms are involved in the execution of the transaction, the member or participant or client of the trading venue shall determine the trader or algorithm primarily responsible as specified in Article 9(4) of Commission Delegated Regulation (EU) 2017/590 on transaction reporting (RTS 22)
and populate this field with the identity of that trader or algorithm.

Where decision maker is a trader:
PartyID (448) = Short Code ID / 3 (CLIENT)
PartyRole(452) = 12 (Executing trader)
PartyIDSource(447) = P (Short code identifier)
PartyRoleQualifier(2376) = 0 (where PartyID is 3) or 24 (Natural Person)

Where decision maker is an algorithm:
PartyID (448) = Short Code ID/ 3 (CLIENT)
PartyRole(452) = 12 (Executing trader)
PartyIDSource(447) = P (Short code identifier)
PartyRoleQualifier(2376) = 0 (where PartyID is 3) or 22 (Algorithm)

Where decision maker is a trader:
ExecutorID = Short Code ID/ 3 (CLIENT)
ExecutorQualifiedRole = 0 (where ExecutorID is 3) or 24 (Natural Person)

Where decision maker is an algorithm:
ExecutorID = Short Code ID/ 3 (CLIENT)
ExecutorQualifiedRole = 0 (where ExecutorID is 3) or Algorithm (22)

Direct Electronic Access (DEA)

'true' where the order was submitted to the trading venue using DEA as defined in Article 4(1) (41) of Directive (EU) 2014/65.

'false' where the order was not submitted to the trading venue using DEA as defined in Article 4(1) (41) of Directive (EU) 2014/65.

OrderOrigination (1724) = 0 (Default). Indicates DEA activity (as deemed by MiFID II) is not involved in the order.
OrderOrigination (1724) = 5 (DEA). Indicates DEA activity (as deemed by MiFID II) is involved in the order.

OrderOrigination = 0 (Default). Indicates DEA activity (as deemed by MiFID II) is not involved in the order.
OrderOrigination = 5 (DEA). Indicates DEA activity (as deemed by MiFID II) is involved in the order.

Liquidity provision activity

Indication as to whether an order is submitted to a trading venue as part of a market making strategy pursuant to Articles 17 and 48 of Directive 2014/65/EU or other activity in accordance with Article 3 of this Regulation.

OrderAttributeTypes (8015) =
2 = Liquidity Provision activity order. This indicates the order is related to any sort of liquidity provision activity, as deemed by MiFID II. This flag is mandatory for orders which are part of a liquidity provision activity. Absence of this value indicates otherwise.

LiquidityProvision =
N = Not Liquidity Provision (default)
Y = Liquidity Provision

Algorithmic order

Indication the order submitted from the dealer/investment firm resulted from an algorithm.

OrderAttributeTypes (8015) =
4 = Algorithmic order. This indicates that the order was placed as a result of an investment firm engaging in algorithmic trading. Absence of this value indicates otherwise.

AlgorithmicIndicator =
N = No algorithm was involved (default)
Y = Algorithm was involved

Documentation

* RTS 24: Record Keeping Guidance

* MiFID II Identifier Management Application

* BXE/CXE FIX specification

* BXE/CXE BOE specification
Testing

* All of the above functionality is already available for Participant testing in the BXE and CXE Certification (UAT) environments.
Production

* This functionality is currently available for use in in the BXE and CXE Production environments, and Participants are urged to begin supplying their RTS 24 relevant identifiers in advance of Friday, 1st December, 2017. Whilst Cboe Europe will verify whether identifiers are supplied on orders, Cboe Europe will not reject orders in real-time in the event of missing short code or the use of unregistered short codes. The validation will be conducted out of band and Participants will have until End of Day of the current trading session to register any missing short codes. Cboe Europe is urging participants to rollout their RTS 24 identifier functionality in advance, in order to ensure compliance once MiFID II comes into force.
All current and historical Cboe Europe notices, including symbol universe updates, are available online at http://markets.cboe.com/europe/equities/notices/schedule_update/.
Please contact the Trade Desk or your Account Manager if you have any questions.

Trade Desk
Cboe Europe Equities
11 Monument Street | London, EC3R 8AF
T. +44 207 012 8901
E: [email protected] | cboe.com >