The UK Financial Services Authority has calmed market practitioners’ fears about the new Alternative Instrument Identifier (AII) for use in identifying some derivative instruments in MiFID transaction reports (Reference Data Review, September 2007) by clarifying that individual firms will not have to use the code for the time being.
Rather, reporting entities will just have to provide the exchange product code (usually up to five characters), and the rest of the information making up the AII – exchange code, derivative type, put/call identifier, prompt date and strike price – will be concatenated between the Approved Reporting Mechanisms (ARMs) and the regulator for exchange over the relevant systems.
When news of the AII broke, it caused considerable confusion in the market, with firms fearing they would have to populate the instrument identifier field in transaction reports with a new – very long (up to 47 characters) – code. This would have required a massive reference data project, they reckoned, and the length of the code would have challenged many existing systems and formats. Swift’s new ISO 20022 transaction reporting messages, for example, allow for just 35 characters in the “OtherIdentification” field for financial instruments.
The confusion was compounded by the fact that the AII proposal was unleashed on the market so late in the day, with the MiFID implementation date of November fast approaching. The FSA has allayed concerns on this front also, by confirming that because it and the ARMs for MiFID need to modify their systems to handle the concatenation, reporting impacted by the AII will not be required until some time in 2008, to be defined.
Currently the list of exchanges planning to use the AII – rather than the ISIN – for their derivatives includes the Euronext exchanges, ICE Futures, Eurex and the Athens Derivatives Exchange, according to the FSA, though this list may change. Exchanges with derivatives activity must choose whether they will use the ISIN or the AII for their derivatives; they cannot offer both.
Those market practitioners who were concerned about AII sought clarity on the issue and are certainly pleased to have received it. However, the industry is not out of the woods yet when it comes to instrument identification in MiFID transaction reports, they suggest. Crucially, the FSA’s ability to do its due diligence on market activity could be negatively impacted if the data from which it is creating AIIs is inaccurate: sources say the regulator will have to work to ensure market participants are consistent in their provision of data such as the strike price, paying attention to details such as the number of decimal places and ensuring data isn’t out of date because of corporate actions, for example. Otherwise, the FSA could end up creating numerous different representations of the same instrument.
There are also concerns about inconsistencies in the way exchanges issue ISINs – the identifier mandated for use for other instruments under MiFID. Essentially, exchanges issue ISINs at different levels – some at the contract level, some at the option level, for example – which again could negatively impact on the regulators’ ability to be sure of exactly which instruments are being reported on.
Similarly, there are ongoing worries about the use of BICs to identify entities in MiFID transaction reports, since some entities have multiple BICs and theoretically one reporting firm could choose one BIC and another a different one, both referring to the same entity. The industry is calling on the FSA – which has said firms must use either an FSA Reference Number or a BIC (if available, and failing that a consistent internal identifier) – to offer some clarification on this issue.
These reference data-related challenges do not constitute immediate major problems, market participants say, but solutions to them will need to evolve if the FSA is to be able to carry out its due diligence function based on the transaction reports it receives under MiFID.
Subscribe to our newsletter
