MiFIR Implementation: Practical Challenges & Solution Options
With less than six months to go before the MiFIR implementation deadline, one question we're hearing more and more from our clients is "Will everything go smoothly from Day 1?” I think it’s safe to assume that it won’t, given the scale of the challenge still remaining, the time to implementation and the sheer complexity of transaction reporting.
The good news is, now that the industry is knee-deep in preparations, some of the possible challenges you might encounter during MiFIR implementation are becoming clearer. I recently discussed these on a webinar with our partners at London Stock Exchange’s Approved Reporting Mechanism (ARM) UnaVista; here’s a recap of what you’re most likely to face.
A brief survey conducted by UnaVista during our webinar showed that nearly 40% of respondents are concerned about sourcing data from multiple sources, followed by concerns around sourcing reliable reporting eligibility data, acquiring LEIs, personal data protection and exception handling. This is where an OMS can be particularly helpful, pulling together and storing security reference data, entity data and LEIs, collating decision makers’ information and order and allocation data.
The FIX Trading Community has been working hard to produce implementation guidelines specifying how to communicate the required information for transaction reporting, and we’re now starting to see updated MiFID II FIX specifications come through from brokers. Of course, if you think about the magnitude of the industry being able to implement these FIX updates between every broker and every system vendor in the time remaining, it’s reasonable to expect at least some manual effort required come Jan. 3rd 2018 to close some of these gaps. Again, more good news here for the buy-side, in the form of the extensive exception handling features as part of UnaVista’s ARM portal, helping you catch and correct any transactions that fail validation.
There’s been much buzz surrounding the issue of report construction for MiFIR, much of it surrounding how the report is put together, and the infamous 65 fields that are now required. There are two major misconceptions surrounding report construction under MiFIR:
Myth: Every report must have 65 fields
Reality: Many of the fields will never be required for buy-side reports. For example, the buyer and seller sections have three fields each for the first name, last name and date of birth of those parties, but for most investment managers their buyers and sellers are funds and brokers, which are corporate or legal entities, not individuals. That means those six fields will never apply – corporations don’t have first names or last names. Depending on the scenario, you can cut down multiple fields out of the report. The key is to focus on the fields that match your scenario.
Myth: Reports are just an export of all my trades with some new fields.
Reality: Reports aren’t just a straightforward export; they require stitching together of data from the market side with the client side, so you need to include both who you are trading with and who you are trading for. Another such scenario is where the asset manager has multiple entities in U.S. and U.K. jurisdictions, for instance, with portfolio managers and the trading desk acting as a global team. The challenge here will be deciding for each scenario which of the entities represent the investment decision maker, the executing decision maker, and the executing entity. Ultimately, you will have to make the decision about what matches your situation.
The OMS is a tool that can help you construct transaction reports according to a scenario – the practice we call stitching. The OMS will send those reports every night to the Approved Reporting Mechanism (ARM), where they will be enriched with personal data and run through the aforementioned validations. This isn’t your only option though, there are a number of different scenarios of how this can work, and who’s doing the stitching and the enriching:
No matter what scenario you pick, it’s critical that you understand the scenarios, how they should be reported and agree with the relevant parties on the fields they’re using. At the end of the day, the responsibility for the reports lies with you.
So, should you expect to have to upgrade your OMS? That depends on what version you’re on, the complexity of your business and the solution you’re choosing. Whether you can make do with existing functionality or not, clearly the latest version will be the one most likely to accommodate all of your MIFID needs and then some others, so an upgrade might be the most cost-effective option in the long term.
What you should expect is that not everything will go smoothly on day 1, and you will need to prepare for any anomalies. This means budgeting for exception scenarios, either to be handled within the OMS or through an ARM functionality such as the UnaVista ARM portal validation and exception management functionality. The good news is, those exceptions should fall over time as FIX enhancements roll out, reference data improves and together with our clients we systematically address the exception categories picked up by the ARM portal.
Adam De Rose
Adam De Rose, Associate Director, Product Management, joined Eze Software Group in January 2014 and is now a Product Manager focusing on MiFID II and Best Execution. Previously, he was responsible for selling Eze EMS to hedge funds and asset managers in Europe, and prior to that was a Sales Engineer across the wider Eze Software Investment Suite. Prior to Eze Software, Adam worked at TradingScreen on U.K. Hedge Fund EMS sales from 2012 to 2014.