After a series of delays over the last three years, the UK Financial Services Authority (FSA) has finally launched its new enhanced transaction reporting and market surveillance system for the collection of Alternative Instrument Identifier (AII) codes, as required under the upcoming 13 November deadline for the reporting of these new codes. This new identification scheme and the launch of the Zen system is all part of the European regulatory community’s plans to harmonise transaction reporting for equity, debt and derivatives and bring market abuse surveillance systems into line across the region, as required under the Market in Financial Instruments Directive (MiFID).
The regulator had planned to launch the enhanced system at the end of February last year, however, at the time, it noted that further work was required to ensure the system was able to deliver the surveillance tool it needed. The FSA seemingly struggled to get its current surveillance system up to scratch in order to be able to process transaction reports for AII transactions. It first indicated in October 2009 that it had experienced a “number of difficulties” in rolling out its system for processing these reports and was therefore forced to engage in a “re-planning exercise”.
The Committee of European Securities Regulators (CESR – now the European Securities and Markets Authority, ESMA) had originally wanted each competent authority (CA) to collect this information and share relevant reports with other CAs by November 2008, one year after MiFID went live. However, the FSA and approved reporting mechanisms (ARMs) found the practical reality of implementation was much harder than first thought.
The key objectives of the FSA’s AII project are to meet MiFID obligations for reporting all AII derivatives transactions in an efficient and secure manner. Additionally, all reference data must be obtained in order to understand, validate and route transaction reports to the relevant CA according to MiFID’s criteria.
The Zen system replaces the existing FSA SabreII system and, according to the regulator, it provides enhanced regulatory capabilities including a market abuse monitoring, alerting and reporting function. It also provides support for increased transaction volumes from the industry and to/from the ESMA central Transaction Reporting Exchange Mechanism (Trem).
To ensure the industry has sufficient notice to implement the reporting of AII transactions, the FSA has said that it will require firms to be compliant no later than 13 November this year, the “hard go-live” date. However, subject to the respective firms’ ARM authorisation status (see the FSA website for more information on this here) and their state of readiness, firms may begin the reporting of AII transactions now. The FSA has also made available a test environment to enable firms to undertake end to end testing for both ISIN/OTC and AII transactions, which will be available until the November deadline.
The AII is composed of six elements: the ISO 10383 market identifier code (MIC) of the regulated market where the derivative is traded; the exchange product code (the code assigned to the derivative by the regulated market where it is traded); derivative type (identifying whether the derivative is an option or a future; put/call identifier (mandatory where the derivative is an option); expiry/delivery/prompt date (exercise date/maturity date of a derivative); and strike price (mandatory where the derivative is an option). The only new element is the exchange product code, as many of the other elements are already used by firms reporting transactions in OTC derivatives.
However, with the implementation of Zen, the regulator has introduced additional business validation rules, aimed at tightening up validation to ensure the FSA does not receive erroneous transaction data from the industry and propagate that data, via the Trem, to other relevant competent authorities. This will result in some transaction reports being rejected that were previously accepted by the FSA SabreII system. For example, now, the system will reject transaction reports containing Bank Identifier Codes (BICs) in the reporting firm field, or in the counterparty fields, that were not active at the trading date.
On the subject of BICs, the FSA says: “Firms must therefore ensure they keep the list of BICs for their counterparties up to date to avoid rejections. In addition, where a firm is undertaking any back reporting it should ensure the BIC to be reported is the BIC that was active at the date and time the trade took place.”
Moreover, the Zen system will also now reject transaction reports for derivative types ‘F’ (future), ‘S’ (other swap), ‘X’ (spread bet), ‘D’ (contracts for difference) or ‘Z’ (credit default swaps) where the put/call field has been populated and ISIN transaction reports where the trading venue is populated with an AII MIC (for example, XLIF, XEUR). Similarly, the regulator’s new system will reject AII transactions where the trading venue is not populated with a valid AII MIC. The FSA states: “Firms must ensure the trading venue is consistent with the instrument reported and is valid for the trade date.”
The FSA has also recently sold its Transaction Reporting System (TRS) to the London Stock Exchange (LSE) for the sum of £15 million. The TRS is an ARM established in the UK market for the reporting of transactions in regulated instruments by firms to the FSA in accordance with SUP 17 of the FSA Handbook and MiFID. Up until now, clients using the TRS service have been using it solely for transaction reporting purposes, however, the LSE’s UnaVista platform, onto which its transaction reporting solution was moved in May last year, aims to offer much more than these reporting functions. On this note, it aims to provide a solution for all asset types, including a reference data feed to help customers prepare for the AII code.
Subscribe to our newsletter
