MIFID II DATA DELUGE: WHY WE NEED TO COLLABORATE.

Tim Healy, FIX Trading Community

It is now over 2½ years since the first meetings were held by a number of different FIX working groups to review MiFID II topics with the aim of providing guidelines and best practices for market participants. What has become clear since those first calls, was that many participants on the calls were also participating in other working groups with various other trade associations. The risk was that there would a be a duplication of effort and that firms would have different individuals working at cross purposes.

To try and help this issue, FIX Trading Community and Association for Financial Markets in Europe (AFME) partnered to form a joint industry working group looking at Order Data and Record Keeping (ORK). Not an easy task considering the sheer depth and volume of data that is required by the regulators, so joining forces only made sense.

Initially, the focus for the working group was to scope out what exactly the working group needed to focus on. Those items were decided as:

• What events trigger Record Keeping?
• A list of fields required by trading venues;
• Specifics on these fields;
• High Frequency Trading (HFT) superset fields;
• FIX mapping with the required fields.

There was quickly a realisation from members of the working group that whilst the detail of the regulation had good intent, the magnitude and scope would mean extensive effort in detailing requirements. Additionally, the regulation does not necessarily have the robustness of a tried and tested trading protocol. Being able to map record keeping requirements to the FIX Protocol has allowed for a common interpretation that is practical to implement. This was done with very little need to add to the protocol, and the creation of a set of guidelines on how to use existing features has allowed for a flexible approach that caters for differing use-cases but driving a consistency between them.

One of the key areas that the working group focused on initially was to come up with a standardised format that would allow the venues to receive the newly required regulatory information from their members in short code. This could include:

• Execution algo;
• Execution individual;
• Investment decision algo;
• Investment decision individual;
• Client legal entity;
• Client individual.

As a guiding principle, it has been accepted that it would create unnecessary cost and complexity for members if venues were to diverge in their approach with respect to short codes, particularly when venues trade the same instruments. If individual venues require different values on orders, a translation would have to occur at the router level, after the venue had been selected, potentially introducing additional latency. If different values were required, separate and different end of day mapping files would have to be produced for all venues. As with all the MiFID working groups, achieving consensus and providing clear standards was the main objective and, after polling the venues, a short code standard with FIX mappings was produced.

The main body of work for the broader ORK working group was to produce a definitive document that would provide guidance on various use cases and the reporting requirements that are needed for each counterparty involved, whether they be a buyside, sellside or venue/exchange. Of course, with any electronic order routing, there is a two-way flow of information between submitting firm and receiving firm, and firm to venue. ESMA has clearly stipulated that all parties bear the responsibility to ensure that the required data and information is recorded and that such information should be made available to the competent authorities using uniform standards and formats.

The document covers FIX order and execution events as well as quote events that happen via a trading venue. For each of these event types, it looks at the types of entities that will be receiving and sending these events. It considers the specific record keeping requirements of each of these entities and whether the information can be generated internally or whether it is required from another entity. If this information is required from another entity, the document provides the FIX tags that map to ESMA’s requirements. Again, this highlights that FIX is much more than just an electronic trading language. As one participant at a recent FIX event noted, “What we’re working with in FIX is a regulator’s dream.”

By being able to map ESMA’s requirements to the FIX Protocol and putting these guidelines in place, the members of the FIX Trading Community and AFME have shown that there is a strength in working closely together to address regulation. There has been much talk over the years about the unintended consequences of MiFID II. From here, it would appear that one of those consequences, would be greater collaboration to ensure all market participants meet their respective requirements. This is the way that FIX Trading Community has worked over a number of years and will continue to work to promote the use of cost-effective standards that are available for all.

©BestExecution 2018[divider_to_top]