About a-team Marketing Services
The knowledge platform for the financial technology industry
The knowledge platform for the financial technology industry

A-Team Insight Blogs

UK FSA Indicates BIC Codes are Needed for all Transaction Reporting Firms, Defers AII System Launch Indefinitely

Subscribe to our newsletter
This month, the UK Financial Services Authority (FSA) has indicated that transaction reporting firms under MiFID will need to obtain a bank identifier code (BIC) in order to be in compliance with wider European level regulations. Firms will have to apply to Swift for a BIC before they email the transactions monitoring unit (TMU) with the relevant BIC and their firm’s reference number (FRN). The regulator has also stated that the launch of the enhanced transaction reporting and market surveillance system incorporating the Alternative Instrument Identifier (AII) has been delayed indefinitely.
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…

Subscribe to our newsletter

Related content

WEBINAR

Recorded Webinar: Adding cloud to your high performance trading infrastructure

Adding cloud to high performance trading infrastructure offers the benefits of scalability, faster development, and lower capex costs – but can it meet required speeds of data delivery, does it limit the extent of available data, and how can low-latency data be sourced in the cloud? Still more, is it feasible to run a complete...

BLOG

A-Team Webinar to Discuss Adding Cloud to High Performance Trading Infrastructure

The cloud is playing an ever greater role in financial markets, and firms across the sector – buy side, sell side and trading venues – are increasingly looking at how to make best use of it within their trading infrastructure, given the benefits that cloud offers in terms of its elasticity & scalability, the rapid...

EVENT

Data Management Summit London

Now in its 13th year, the Data Management Summit (DMS) in London brings together the European capital markets enterprise data management community, to explore how data strategy is evolving to drive business outcomes and speed to market in changing times.

GUIDE

Regulatory Data Handbook 2022/2023 – Tenth Edition

Welcome to the tenth edition of A-Team Group’s Regulatory Data Handbook, a publication that has tracked new regulations, amendments, implementation and data management requirements as regulatory change has impacted global capital markets participants over the past 10 years. This edition of the handbook includes new regulations and highlights some of the major regulatory interventions challenging...