Do the MiFID Transparency Rules Lack Transparency?
The European Commission’s Markets in Financial Instruments Directive (MiFID) Level 2 guidance, issued in February 2006, listed 23 data fields to be included in any MiFID transaction report to a competent authority. It also listed 12 further fields to be included in other reports, including post-trade transparency reports and reports to clients. Conspicuously however, it omitted to define the actual content of each field for example, “Instrument Identification”.
Furthermore, the MiFID Level 2 Guidance indicated that this was the minimum set of fields, and that optionally more could be added. There has been some industry discussion about this kind of “gold plating”, and it’s been rumoured that both the Financial Services Authority (FSA) in the UK and the German financial regulator (Bundesanstalt für Finanzdienstleistungsaufsicht or BaFin) have intentions to ask for substantially more information than the basic 23 fields. It’s possible that BaFin may want to continue their current reporting requirement which uses 48 fields. The FSA on the other hand, seems to be taking account of industry pressure and backing off any attempt to “gold-plate” MiFID by extending it in this, or any other area.
Most of our contacts in the industry were waiting for the Committee of European Securities Regulators (CESR) Level 3 guidance for clarification. We all expected this would specify the content of each of the fields, and identify exactly which fields would be common to all regulators.
In May 2007, CESR issued what they said would be their “last set of guidance” on MiFID Level 3 regulation.
In the event, this guidance failed to fully define either of these issues. The implication of these omissions is that both the data fields (beyond the basic 23 specified in the Level 2 Guidance), and the actual content of each field will be specified by each country regulator. This raises the possibility that there could be 30 different sets of requirements – one for each jurisdiction.
It also increases the likelihood that one of the major objectives of MiFID could be compromised: that of market transparency. If each one of the 30 countries requires a different set of information, and some of that information is not directly comparable, then surely this fails to meet MiFID transparency requirements. Fundamentally MiFID required that the published data is in a form which is easily consolidated to give an overall view of the market. If we can’t even rely on using the same set of instrument codes across the 30 MiFID countries, how can this information be consolidated? And if it can’t, then surely the whole concept of market transparency is fatally compromised.
To make the situation worse, let’s consider the impact of passporting and home/host regulation. It’s up to each individual regulator to decide if they want a firm that’s registered in their jurisdiction, but which executes a trade in another MiFID country to report that trade in their home area. It has been widely suggested that post-trade and transaction reporting will be required only to the “home” regulator; and if the “host” regulator wants to see details of the transaction then it will be able to obtain it via the CESR transaction exchange system. However if your “home” regulator is in a jurisdiction which implements MiFID without any gold-plating, (i.e., you have to only report the basic 23 fields), but you conducted the transaction in Germany (which may require you to report 48 data fields), you can’t rely on CESR’s system to enable you to comply with the local regulations in Germany. You may well need to send a separate report to the “host” regulator (in this case, BaFin) to ensure you comply with their requirements. Imagine the confusion that would follow if each of the 30 regulators required a slightly different set of data to be reported!
“So what?” I hear you ask, “We can implement technology to do this, can’t we?” Well in theory we can, and certainly Gissing Software’s MiFID Post-trade output handler can handle business rules based on instrument codes, execution venues and other parameters. For instance, it can handle look-ups of instrument codes against tables of other codes, converting International Standard Instrument Names (ISINs) to Reuters Extended Instrument Codes (RIC-Xs). It can also handle output in multiple protocols - even those reporting venues that have adopted FIX as a protocol are using slightly different flavours of it. And others may adopt FAST (FIX Adapted for STreaming) or something else entirely.
But given the uncertainty over precisely how MiFID is to be implemented and the lack of clarity regarding exactly this set of parameters, we understand that many of the big investment banks are doing as little as they can. One bank described it as, “papering over the cracks on existing systems”.
Perhaps this is unwise? Very possibly, papering over the cracks in an existing system is not going to meet even the initial requirements, let alone deal with subsequent modifications required by regulators. As these requirements shake down and as other instrument classes (such as Bonds and Derivatives) are added to the MiFID transparency checklist, better home improvement now, may mean you don’t have to re-plaster the whole wall tomorrow..
References
|
