RTS 24: Data Required for Record Keeping
MiFID II introduces a requirement for trading venues to record considerable amounts of data throughout the trading day. Some of this information is only available from our Participants. We require:
- Submitting Member/Participant
- Client identification code
- Trader/Algo identification code (investment decision)
- Trader/Algo identification code (execution)
- Whether Direct Electronic Access ("DEA") or not
- Whether conducting liquidity provision
Venues are also required to be able to block specific DEA clients as well as specific trader and algo IDs.
These requirements suggest that venues will require each identification code to be present on every order so that checks can be made and, where necessary, orders blocked on submission.
Cboe' overall approach to collecting the data required for record keeping is summarised in Figure 1 below.
Figure 1. Cboe Overall Approach to Record Keeping
In order to reduce the amount of sensitive data flowing through the trading system, as well as to minimise any latency impact due to large message sizes, Cboe will operate an approach that requires Participants to supply "short codes" on each order and supply a mapping file out of band on a pre- or post-trade basis.
Fields are being added to the order entry protocol (both FIX and BOE) that allow specification of the client identifier, the decision maker for the investment decision and the responsible entity for the execution.
However, these fields will not support specification of the raw identifier. Participants must supply an integer, known as the short code, for the identifiers that are relevant to their order flow. This code must accurately depict the entity involved in this activity and be consistent throughout the course of the trading day. The short code associated with the order cannot be changed.
Separately, participants must supply a mapping from the short code used on the order to the long code that Cboe will be required to supply to the FCA, on their request. Participants may choose to either pre- or post-register their mapping files, but at the end of the day, Cboe must have a long code for every short code used that day. The value supplied may be changed, but cannot be removed if used.
The registration process is available to permissioned users who can use a secure web application to manage the registration of long codes to short codes as outlined in the Cboe MiFID II Identifier Management Application. Sensitive data is encrypted between the server and the data store and cannot be decrypted by the server, although a masked version is available to help in any reconciliation Participants may wish to perform.
At FCA's request, Cboe will combine order records with the provided mappings to produce the prescribed output and transfer the data to them in the mechanism they require.