The need for a CFI code may not be needed for every reported line in trade files, but at some point it is likely to be required. The problem a lot of firms will have is ensuring the correct code is used and there may be a reliance on a data provider for that information.
If you are a user of more than one system then you’ll probably be very familiar with the challenge of mapping one taxonomy of instruments to another between systems, or even from your system to a third party. Once the mapping has to exist there will always be an issue with adding a new class due to downstream mappings.
Sometimes it is not solely the mapping of the classifications that is the issue; it can extend to how the instruments and subsequent trades are modelled. For example, a repurchase agreement in one system is a contract with events and in another it could be an instrument that may have multiple trades. All of these translations come at a cost to the firm performing the translation.
The granularity of instrument classes is something that can provide powerful reporting and is often essential for calculating commissions correctly, though there is a trade off with the maintenance of all the classifications for each individual instrument.
MiFID II lists instrument classes in the RTS 28 for the best execution reporting and elsewhere within RTS 22 there is provision for the use of a CFI code. While not worlds apart, there is a level of interpretation that may be applied here. Some firms consider convertible bonds to be bonds and some firms consider them to be equity. Not insurmountable, but it highlights that the industry has had this problem for ages. As mentioned earlier, this often manifests itself when integrating systems internally or externally and a mapping frequently needs to be maintained.
The use of an International Securities Identification Number (ISIN) for all instruments within the European Securities and Markets Authority (ESMA) regulation would remove ambiguity for the regulator, but that doesn’t mean there will be a consistency in reporting.
This challenge is not new, but it is global. The risk remains of having to use CFI codes, ISIN, FIGI, Unique Product Identifier (UPI) and who knows what else in the future.
Hedgd takes a view on CFI that since it is within MiFID II and EMIR, it is therefore likely to be required in some form or another for the foreseeable future. The problem a lot of firms will have is ensuring the correct code is used and there may be a reliance on a data provider for that information.
This is why we developed Hedgd Core and Hedgd OMS (Order Management System) to contain an instrument taxonomy that is built to the CFI code model. I believe it’s a logical starting point for constructing instrument classifications and with the allowance of custom classifications for different purposes it goes some way to solving the issue.
However, without a full industry consensus from industry bodies, software vendors, buy-side, service providers and regulators, this is likely to be an on-going challenge for all market participants.
MiFID II offers chance to reboot
MiFID II actually offers the perfect opportunity for organisations to clean up all that static data in their systems and rethink the way they manage trades and reporting. Organisations can find out with whom they are truly executing, and could be a timely and necessary conduit to refocus on systems and processes. This could lead to impressive productivity and efficiency gains.
LEI codes for brokers, custodians and indeed any market participant will also become mandatory when dealing with MIFID firms, which will be something that even entities not directly covered by the regulation will need to contend with. LEI use demands that everyone knows exactly who they are dealing with and when.
Again, this poses challenges to the market participants because often the organisation static is set up by other rules, perhaps down to commission schedules, or connectivity mapping codes. Many technology solutions will involve bolting LEI as an add on attribute for organisations, at Hedgd we have made this a primary identifier for any entity that exists within the system. LEI removes all ambiguity about where counterparty risk lies. While it is accepted that the risk will always roll up to a parent entity, these relationships are rarely mapped and if they are the data quality may be questionable. GLEIF are introducing relationships which should mean that if the LEI is known then the ultimate relationship to other entities will also be derivable.
The static data challenge has always been present for financial services firms, but regulation by regulation the need to get this in better shape increases. It is never going to be a glamorous subject, but if this data can be captured and maintained in a painless way then there are efficiencies to be gained as well as the ability to accurately report with confidence.
The events of 2008 brought into focus the need for better data and the Chief Data Officer role came more into prominence and is continuing to do so. The fact that data is now getting more and more C-level support just goes to highlight the importance with which it is now viewed.
MiFID II demands better data and firms are demanding better data and this is all wanted with a low cost of ownership. ESMA and institutions like GLEIF are making a lot of the data available free of charge and financial firms should be using the application programmer interfaces (APIs) to bring that data and the delta in-house to ensure that their enterprise data is as rich as possible. Technology allows for this data to be brought in house for a fraction of the cost when it can be automated through APIs.
Oliver South, CEO and Co-Founder, Hedgd
Image Credit: Alexskopje / Shutterstock