Professional Investor

Downloads

Document Library

Search Site

Retail Investor

Market News

News Events Press Releases

Downloads

Document Library

Search Site

RTS 24 - Record Keeping

RTS 24 - Record Keeping

Overview

MiFID II defines and specifies information relating to orders that trading venues are required to collect and store. The stored data will need to be made available to National Competent Authorities (NCAs) upon request in a pre-defined standardised format.

 

The additional information which Equiduct will need to receive and store includes:

 

Equiduct Approach

In line with other major European trading venues Equiduct will use short codes to represent the following data items:

‘Short codes’ will be received in the FIX messages for the identifiers which are marked accordingly in the table in ANNEX 1.

Equiduct will only accept the short codes in FIX messages; the corresponding “long code” cannot be used in the FIX message.

 

Uploading mapping files to Equiduct

Equiduct have decided to use existing SFTP infrastructure for the collection of the long to short code mapping files.

Equiduct will set up new SFTP accounts for members that do not current have one. Mapping files will then be uploaded to the SFTP site in CSV format on a daily basis.

The mapping file for short codes used in a trading session must be supplied to Equiduct before the next trading session. Mapping files will need to be supplied no later than 4am CET. This means that pre-registration of short codes before a trading session will not be necessary. However, failure to provide mappings for short codes before the next trading session (specifically the 4am CET cut-off before the next trading session) would result in those codes being blocked for the duration of the trading session and any orders entered using these unmapped codes will be rejected.

If a mapping file fails to be delivered, we will use the last mapping file received.

 

Mapping file delivery timeline

On any given trading day T+0 any new short codes will be accepted as valid, as will any short codes for which a mapping was provided prior to 04:00CET on the same day. Codes which were used on the previous trading day T-1 and for which no mapping has been provided as of 04:00CET on T+0 will not be valid for use – orders will be rejected.


 

File format



Column name

Description

Example

ShortCode

32bit unsigned integer, valid values between 4 and 4,294,967,295 inclusive

15485863

LongCode

LEI, National ID or Algo ID

391200I7OS301UELZA68 (LEI)

FR19620604JEAN#COCTE (National ID)

DataType

Whether the corresponding long code identifies a person (National ID), entity (LEI) or algo.

“Person”

“Entity”

“Algo”

EffectiveDate

Date (ISO 8601 format) from which the short code mapping is effective. If blank, mapping is currently valid.

2018-01-22

EndDate

Date from which the short code will be unregistered. If blank, mapping is currently valid.

2018-03-07




When the file is processed, Equiduct will generate an acknowledgement file containing the same columns but adding a “Status” column which will contain “OK” if the mapping row was processed successfully and otherwise will contain error text describing the mapping error. Examples of mapping errors include but are not limited to:

“Duplicate short code provided”

“Invalid LEI”

“Invalid National ID”

“Invalid date(s)”

Note that the LongCode column in the acknowledgement file will be blank for security reasons.

The acknowledgement file will be provided using the secure FTP site.

 

File Naming Convention

Mapping files should use the convention of: SHORTCODE_PARTID_YYYYMMDD.csv, where PARTID is the Equiduct-assigned mnemonic for the trading member submitting the file and YYYYMMDD is the trading day to which the file corresponds.

The acknowledgement file generated by Equiduct will be named SHORTCODE_RESPONSE_PARTID_YYYYMMDD.csv.

 

MiFID II FIX Interface Guidance

The technical changes to the Equiduct FIX interface are documented in the Equiduct FIX Specification version 2.17. This guide aims to provide business-level and non-technical guidance to inform members about the changes required and to be read in conjunction with the more detailed specification document. It must be remembered that compliance with MiFID II – and any other national or European legislation – is always the responsibility of each investment firm and Equiduct cannot guarantee compliance on behalf of member firms.

 

Key Changes

 

The most extensive changes to the Equiduct FIX interface result from the record-keeping requirements of RTS 24. Orders (and to a lesser extent, market-maker quotes) submitted to Equiduct will need to contain additional fields to cover these MiFID II requirements:

 

  1. Where members provide DEA services, orders resulting from DEA must be flagged accordingly by setting OrderOrigination=5. Moreover, the DEA client firm must be identified as part of the submission of the order. For existing members offering DEA (DMA) services, this is, and can continue to be, supported by setting the SenderSubID tag on the inbound order to the appropriate client mnemonic as allocated by Equiduct Market Control. The same effect can be achieved in a more standard fashion by adding a PartyID entry containing the client mnemonic and setting PartyIDSource=C and PartyRole=3.
  2. Algorithmic trading. Where members use algorithms, orders which result from algorithmic trading must be flagged as such by setting OrderAttributeTypes=4.
  3. Liquidity provision activity. Where members submit orders as part of a Liquidity Provision scheme these orders should be flagged using OrderAttributeTypes=2. In cases where algorithms are used for liquidity provision, use OrderAttributeTypes=2 4 (“two-space-four”).
  4. Riskless principal. Where members submit orders using riskless (a.k.a. “matched”) principal capacity, these should be flagged using OrderCapacity=R.
  5. Client identification. Members who are brokers with clients submitting orders in agency capacity must provide an identifier for their client. Either a National ID or LEI should be provided in the long code mapping file and the relevant short code should be filled in a PartyID entry with PartyRole=3 and PartyIDSource=P.
  6. Investment decision within firm. Members who submit orders in principal (or riskless principal) capacity must provide an identifier for the investment decision maker responsible for the generation of the order. Either a National ID or Algo ID should be provided in the long code mapping file and the relevant short code should be filled in a PartyID entry with PartyRole=122 and PartyIDSource=P.
  7. Execution within firm. Members must provide an identifier for the person or algorithm responsible for the execution of the transaction resulting from the order. This identifier, either a National ID or an Algo ID, should be provided in the long code mapping file and the relevant short code should be filled in a PartyID entry with PartyRole=12 and PartyIDSource=P.

 

 

PartnerEx Usage and DEA

Equiduct’s PartnerEx service is a guaranteed Best Execution service for retail order flow. As such it has specific requirements around client identification: for members with direct end-clients this is accommodated by standard MiFID II identifiers – see (5) above; however in the case where members provide DEA services for retail order flow targeting the PartnerEx service an additional field is required to identify the original end client (“order owner”). This additional information should be provided as a National ID in the long code mapping file with the relevant short code filled in a PartyID entry with PartyRole=11 and PartyIDSource=P.

 

Summary of FIX Changes related to RTS 24 – Order Record Keeping

The following summary of FIX changes should be read in conjunction with the full Equiduct FIX Specification document.

 

Quote

FIX tags which are added or changed for RTS 24 requirements are listed in the table below.

Tag

Field Name

Req'd

Comments

453

NoPartyIDs

Y

 

 

448

PartyID

Y

Used to identify source of quote and other information (MiFID II Order Record Keeping).

 

447

PartyIDSource

Y

Valid value:

C = Generally accepted market participant identifier (i.e. Equiduct mnemonic)

P = Proprietary / Custom Code (Short code)

 

452

PartyRole

Y

Valid value:

1 = Executing Firm

3 = Client ID (Client of Executing Firm)

5 = Investor ID (Person or algorithm responsible for investment decision)

12 = Executing Trader (Person or algorithm responsible for execution of order)

8015

OrderAttributeTypes

N

Space delimited list of attributes. Note that quotes are, by definition, classified as Liquidity Provision activity.

Valid values:

4 = Algorithmic Order

1724

OrderOrigination

N

Set to indicate that the quote was placed as a result of activity defined as DEA under MiFID II (aka DMA). If not set, the quote does not result from DEA.

Valid value:

5 = Order received from a direct access customer (DEA)



 

New Order Single

FIX tags which are added or changes for RTS 24 requirements are listed below.

Tag

Field Name

Req'd

Comments

453

NoPartyIDs

Y

 

 

448

PartyID

Y

Used to identify source of order and provide other information about the order (MiFID II Order Record Keeping).

Reserved values (applicable when PartyRole=3 with PartyIDSource=P):

0 = NONE (No client for this order)

1 = AGGR (An aggregation of multiple client orders)

2 = PNAL (Clients are pending allocation)

 

447

PartyIDSource

Y

Valid values:

C = Generally accepted market participant identifier (i.e. Equiduct mnemonic)

P = Short code identifier

 

452

PartyRole

Y

Identifies the type of PartyID.

Valid values:

1 = Executing Firm (Order owner) – Required

3 = Client ID (Client of Executing Firm)

122 = Investment Decision Maker

11 = Order Origination Trader (End client)

12 = Executing Trader (Person or algorithm responsible for execution of order)

17 = Contra Firm (Liquidity Provider) – VBBO orders only

8015

OrderAttributeTypes

N

Space delimited list of order attributes. Multiple values can be set. Valid values:

4 = Algorithmic order

2 = Liquidity Provision activity order

1724

OrderOrigination

N

Set to indicate that the order was placed as a result of activity defined as DEA under MiFID II (aka DMA). If not set, the order does not result from DEA.

Valid value:

5 = Order received from a direct access customer (DEA)

 

 

Frequently asked questions

 

When will long code mapping files need to be made available to Equiduct?

Files must be received before 4am CET covering the previous day’s trading activity. Any short codes used in the previous session without a mapping provided will not be usable in the subsequent trading session. Any orders entered using these unmapped codes will be rejected.

 

When will we be able to begin testing?

Equiduct are currently aiming for the solution to be available for testing at the beginning of August 2017.

 

Can long codes be sent directly in the FIX message?

We can only accept short codes in the FIX message in conjunction with a long code mapping file.

 

How will Equiduct be accepting the mapping files?

All mapping files will need to be delivered via Secure FTP to Equiduct. All mappings for the previous day trading must be submitted before 4am CET the next trading day. Failure to provide a valid mapping by the cut-off would result in that mapping being blocked the next trading day. If a mapping file fails to be delivered we use the last mapping file received.

 

Would the short codes for trader id, algo id and client id have a dedicated range?

Equiduct’s approach is to offer a single range of short code identifiers (starting from 4 and running up to 4,294,967,295). Members can allocate short codes as they see fit, however it is not possible to use the same short code with a different “meaning” (ie mapped to a different long code).

 

Can you confirm the format, datatype and size for short codes?

Short codes must be numbers which can be represented as a 32bit unsigned integer in C. Values 0, 1, 2 and 3 are reserved. Maximum usable value is 4,294,967,295.


Data from Market by Limit feed, delayed at least 15 minutes. View our methodology.