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

Upcoming Webinar: Addressing conduct risk: approaches to surveillance

Date: 3 December 2024 Time: 10:00am ET / 3:00pm London / 4:00pm CET Duration: 50 minutes Conduct risk in financial services is a critical area that requires vigilant monitoring and robust surveillance mechanisms. Regulatory bodies, (FCA, FINRA and others) have tightened their scrutiny and financial institutions must adopt advanced approaches to effectively manage and mitigate...

BLOG

Ascent Technologies Adds Horizon Scanning with Acquisition of Waymark

Ascent Technologies, a Chicago-based vendor of AI-enabled compliance automation solutions, has acquired Waymark, a UK-based provider of horizon scanning and compliance management workflow solutions. The move follows Ascent’s recent acquisition by Edgewater Equity Partners. Waymark’s horizon scanning tools augment Ascent’s obligations management technology, with the combined company now able to offer regulatory coverage of the...

EVENT

RegTech Summit New York

Now in its 8th year, the RegTech Summit in New York will bring together the regtech ecosystem to explore how the North American capital markets financial industry can leverage technology to drive innovation, cut costs and support regulatory change.

GUIDE

Pricing and Valuations

This special report accompanies a webinar we held a webinar on the popular topic of Pricing and Valuations, discussing issues such as transparency of pricing and how to ensure data quality. You can register here to get immediate access to the Special Report.