Hanno Klein is Senior Vice President at Deutsche Börse Group which also provides the technology for Eurex, its main derivatives exchange. He joined the company in 1997 and worked in various positions and projects of strategic and operational nature in Germany and the USA. From 2001 to 2005, he served as Vice President of Deutsche Borse Systems Inc. in Chicago.
bobsguide sat down with Hanno Klein at the FIX Trading conference to discuss the implications around MIFID II, the technical challenges and how the industry can work together to combat regulatory issues.
What are your thoughts and highlights from today?
I’m here with a clear focus on the technical side of FIX. My focus is on providing the basis for the FIX Family of Standards comprising a number of technical standards, as well as discussing the FIX language which describes the standardised terms for messages, fields and valid values as well as for the workflows. These include how to exchange information for trading, clearing and market data, and of course the main focus of today’s event which is MIFID II. There’s a large set of MiFID II requirements coming to the community so it’s important to understand the FIX standards to use and to enhance the relevant messages accordingly.
We have now established a translation of the terminology used by the European Securities and Markets Authority (ESMA) to FIX. The role of the Global Technical Committee within the FIX community is to primarily extend the existing standards and cover new business and regulatory requirements. We’ve seen that FIX as a standard has very good coverage of what ESMA requires. The terminology may be different, but we are putting the guidelines in place for the community on what to use and how to use it. We’ve focused on getting a harmonised usage of FIX within the FIX community, although there are still a few areas where the regulation is unclear.
There shouldn’t be any ambiguity when approaching a regulation as large as MIFID II. I think this is the topic of many of the visitors here today, to get a better understanding and to look for a common approach to regulation under MIFID II. The FIX members themselves participate in the committees and working groups of FIX, but we all have day jobs, and we have to put time aside to spend on FIX .
You spoke about the FIX Family of Standards in your presentation. Could you tell us more?
The FIX application layer is the key value proposition, describes the semantics, represents a single standard and consists of several aspects: these are the concepts, guidelines and workflows for business functionality of the financial industry. Then comes the FIX presentation layer with a number of technical standards for ASCII and binary encodings of messages on the wire (e.g. FIXTV, FIXML, FAST, SBE,…). Finally we have the FIX session layer which also consists of a number of technical standards for the transport and recovery of messages between counterparties (FIX4, FIXT, FIXP). FIX also supports non-FIX transports such as AMQP and MQ Series. Any given FIX implementation uses the application layer and supports one or more technical standards from the presentation and session layer respectively. For example, legacy FIX 4.x engines will only support FIXTV (tag=value) and FIX4 (embedded session layer).
What do you see are the challenges facing MIFID II?
The challenges really are on a semantic level; people read a term and immediately have their own view on what it means. FIX tries to establish the meaning and develop a common language, the FIX language, and then the main challenge is to translate the single semantic into other terminologies such as the one used by ESMA. The sheer size of these regulations are important to note to understand part of the complexity of the task.
How is FIX supporting MIFID II?
Our approach is that we aim to provide a standard interpretation of the ESMA requirements and a mapping between terminologies. But FIX has to go beyond requirements for reporting towards ESMA and identify information needing to be exchanged between members of the financial community to allow them to accurately report to ESMA. It’s easy to understand at a very high level what the objectives are, but it is much more difficult to break that down into FIX fields, messages and valid values.
People want to know: what do I exactly have to do? They are looking at specific use cases. It’s difficult to find the right balance between writing the obvious into a FIX guideline and giving a detailed breakdown. I think that should be left to the industry experts inside the FIX working groups to provide the documents supporting the different areas of MiFID II. The FIX Global Technical Committee merely extends the available business functionality by approving and implementing so-called Extension Packs to the FIX Protocol.
And finally, what are the responses or feedback you’ve had from your presentation about the work of the FIX Global Technical Committee? What’s everyone talking about?
Some people are still struggling with the FIX version concept which is more relevant for the FIX legacy versions 4.x than for FIX 5 and above. After FIX 5.0, we stopped packaging extensions into versions and published smaller Service Packs instead. After FIX 5.0 Service Pack 2, we went to even smaller units called Extension Packs to allow immediate and official publication of specific extensions. FIX can be seen as a huge “toolbox”, and we always add to it by means of Extension Packs mentioned before. Any communication between two counterparties will always only need a small subset of this “toolbox”.
FIX 5.0 was introduced back in 2006 but there are still many users out there with FIX 4.x that are reluctant to migrate to a higher version. However, they need the latest extensions to FIX to comply with regulatory requirements. FIX has a policy for this group of users as we cannot simply extend prior versions. It would be like an extension of Microsoft Word 95 with features made available with Office 2016 for the first time. Nobody expects that from a software vendor. Hence there is a technical challenge to establish interoperability between FIX versions. This is the main objective for what we call “next generation FIX” and which is a vision for the future of FIX. The version should not play any role in this concept. It is simply about the subset of FIX messages, fields and valid values supported between two counterparties. As part of this vision, FIX is working on a new technical standard for the community called FIX Orchestra which supports machine-readable Rules of Engagement. These rules represent the exact scope of services and are much more specific than a FIX version. This represents a huge step forward for FIX users by supporting automated testing and reducing the time needed to on-board a new counterparty.