FIX Certification MiFID II
It's getting to the end of the year and everything is getting a little stressed. I'm not talking Christmas gifts - I'm talking MiFID 2.
There's no question that MiFID 2 introduces a massive amount of work for investment firms from exchanges to brokers and software vendors. Armies of developers and consultants have been deployed to answer the question of what needs to change and to make it happen.
Sensing a sales opportunity, many vendors have been quick to slap "MiFID 2 compliant" stickers on their products in an attempt to access short-term budgets. While this isn't FixSpec's style, we understand why others have tried it. To quote one US president - who can blame them?
So if you are a bank, exchange or vendor offering a FIX interface to customers, what exactly changes under MiFID 2 in terms of FIX conformance?
Well, let's start with what you DON'T need to do.
One common rumour is that MiFID 2 mandates annual re-conformance cycles, which isn't actually true. The confusion appears to stem from the re-use of the word "conformance" in two different RTS sections - one relating to bank internal systems, and one relating to receiving FIX messages.
The annual timeframe comes from Article 9 of RTS 6 which obliges banks or vendors to perform an annual self-assessment of their algorithms and produce a report for internal review - a process that doesn't involve any third party.
Article 6 of the same RTS also requires banks to perform conformance testing prior to deploying a new software release. This second obligation is not tied to an annual cycle, and it stops short of requiring trading venues (who may receive messages as a result of testing) to participate or verify behaviour. Trading venues may decide to formally re-certify of course, but most European exchanges have adopted a more pragmatic self-declaration approach given rapid software cycles for algorithms.
Obligations for firms to validate that incoming messages comply with their interface - what we traditionally think of as FIX conformance - is covered by RTS 7. Here there is no specific annual requirement, merely that re-conformance should happen whenever there is a "substantial update" to systems... without actually defining what that means. Our common-sense interpretation, however, is that if you make an API change that is not backward-compatible, then you should probably re-certify impacted customers.
While it's tempting to conclude from this that MiFID 2 doesn't really change FIX conformance, it's important to note that by merely describing conformance in vastly more detail than MiFID 1, the regulators are clearly highlighting this as an area of increasing focus and we therefore recommend firms plan accordingly. In particular, we would recommend more regular re-conformance as a general risk-reduction measure, along with reviews of documentation, conformance coverage and the mechanisms by which interface change is managed and tested; topics we will talk more about shortly.
So what DO you need to do?
MiFID 2 introduces a range of new obligations around reporting, which in turn creates a need to extend or adjust many of the FIX messages that you may support in your interface. For example audit requirements require timestamps to be captured to millisecond granularity, and orders may need to identify the person who originated the order. For FIX interfaces, we would recommend taking a look at the work coming out of the FIX Trading Community to learn more. Don't forget that these requirements are protocol-agnostic, so things like timestamps need to change in non-FIX interfaces too.
Since these are likely to be mandatory, non backwards-compatible API changes you WILL need to document, communicate and re-conform customers to the updated API in time for the 3rd January 2018 deadline. But then, if you work in FIX certification in Europe right now you will know this first-hand!
Good luck with your MiFID 2 implementation, and - when the dust settles - let us know how we can help.