The leading knowledge platform for the financial technology industry
The leading 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

Share article
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…

Related content

WEBINAR

Recorded Webinar: Embedding AI & Machine Learning into your trading operations

It’s no secret that AI and Machine Learning are changing the landscape of the trading industry. As these tools and techniques become more mainstream, their availability to even the smallest of financial firms is becoming a more viable proposition.  From speech recognition and natural language processing (NLP) to deep learning algorithms and predictive analytics, these...

BLOG

Mphasis Partners with iMeta on AI-Driven KYC Model

Cloud and cognitive specialist Mphasis has launched a brand new strategic partnership with the UK’s iMeta Technologies, a provider of onboarding, client lifecycle and master data management software and services, to deliver a next generation onboarding model for the UK and Europe that aims to disrupt the traditional KYC market through the use of AI....

EVENT

Data Management Summit London

Now in its 10th year, the Data Management Summit (DMS) in London explores how financial institutions are shifting from defensive to offensive data management strategies, to improve operational efficiency and revenue enhancing opportunities. We’ll be putting the business lens on data and deep diving into the data management capabilities needed to deliver on business outcomes.

GUIDE

Entity Data Management Handbook – Sixth Edition

High-profile and punitive penalties handed out to large financial institutions for non-compliance with Anti-Money Laundering (AML) and Know Your Customer (KYC) regulations have catapulted entity data management up the business agenda. So, too, have industry and government reports on the staggering sums of money laundered on a global basis. Less apparent, but equally important, are...