Once a firm has submitted this data, the regulator will map the FRN to the BIC and the firm must ensure that the TMU is aware of the BIC on an ongoing basis. This is with a view to ensuring entity data is consistent across the MiFID compliant landscape and the regulator is able to identify each firm correctly.
With regards to the AII system launch, the FSA says: “We had planned to launch the enhanced system at the end of February, however further work is required to ensure the system will deliver the surveillance tool we need. We understand this may cause issues for firms who need to implement the new code and we are working very hard to get the system ready. Although we can not publish a revised timeline at the moment, we will issue one at a later date.”
This delay is not the first that the FSA has been forced to announce: the launch has been delayed for nearly two years, as the regulator has struggled to get its current surveillance system up to scratch in order to be able to process transaction reports for AII transactions. The regulator indicate in October last year 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) 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) have found the practical reality of implementation is much harder than first thought.
Despite the delays, the FSA says that firms that wish to continue with their AII implementation projects may submit their AII transaction reporting flow to their ARMs in the interim. In order to facilitate this, the regulator will continue to provide testing facilities for firms to test the records submission process with their ARM. “We intend to provide a data extract service only for the test data. This enables firms to reconcile accepted records against their original submissions,” says the FSA.
There are currently two such ARMs that are able to provide these AII testing services: Xtrakter and the FSA’s Transaction Reporting System (TRS). Both of these will accept and validate AII records in their live production environments but these transaction reports will not be sent to the FSA but will instead be deleted by the ARM.
AII transactions are related to derivatives admitted to trading on regulated markets where the ISO 6166 ISIN is not the industry method of identification. 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 regulator has also recently noted that some firms are incorrectly populating their counterparty and customer or client identification fields when reporting principal trades. The FSA has therefore issued a reminder of the guidelines for this data I its recent newsletter. The counterparty field must contain: a BIC, FRNor internal code (where a BIC/FRN has not been assigned to that entity) of the market counterparty/executing or clearing broker/client or; the BIC of the central counterparty. The customer or client identification field, on the other hand, must be left blank.
In line with its crackdown on the data details, the FSA has also issued a general warning to firms to pay more attention to transaction reporting data. “We encourage firms to regularly review the integrity of their transaction reports to ensure they have been successfully submitted to the FSA,” it says. “Firms should note that when relying on a third party to submit transaction reports on their behalf, the reporting firm remains responsible for the completeness and accuracy of the information submitted to the FSA.”
The FSA is not afraid of “enforcement” when it deems a breach to be “particularly serious”, it notes in the newsletter. Those not convinced by this argument might want to be reminded of the fine slapped on Barclays Capital last year…