The good, the bad and the new: Final MiFID II transaction reporting guidelines

It was a big day in the world of regulatory reporting on Monday (10 October) with the publication of what is expected to be the final version of ESMA Guidelines for MiFID II transaction reporting.

These guidelines are very important because they establish an obligation on financial market participants who “shall make every effort to comply with those guidelines and recommendations.”[ref]Article 16(3)of Regulation (EU) no 1095/2010 of the European Parliament and of the Council[/ref] Failure to comply with the guidelines will be considered a breach of the transaction reporting requirements.

The guidelines are extensive so we’ve carried out an initial review of the 280-odd pages and a quick comparison to the previous version focusing on the transaction reporting requirements.

Our take? Well, the good news is that ESMA has answered a lot of questions. The not-so-good news is that many questions still remain unanswered.  The bad news is that the guidelines have thrown up some new questions.

Here are our immediate observations (there will be more to come once we’ve had more time to plough through and analyse all the changes).

Identifying natural persons

There have been some changes to identifiers for individuals which we think will be welcomed by the industry:

1. Person identifiers: no longer requires firms to monitor for the expiry of identification documents such as passports.
2. Clarification of how to determine nationality of individuals with multiple non EEA nationalities is by the first country code when sorted alphabetically.
3. Introduction of an exhaustive list of name prefixes where these are to be removed when constructing the CONCAT identifier.
4. Name and surname fields are now to allow the original country spelling so transliteration is not required for these fields.

Who is the decision maker?

This is the key question that competent authorities need to answer when undertaking surveillance for market abuse. As such, this is key information in the transaction report and ESMA has provided further clarifications and examples in the scenarios for the various decision maker fields including reporting chains which will prove very useful when mapping out the reporting logic.

Reporting trades against fund managers has been clarified

ESMA clarifies that they are looking for the decision maker. Therefore, where there is a transaction on the instruction of the fund manager, the fund manager will be the buyer and the decision maker field is left blank as it is one and the same party.

Where execution is determined outside of the reporting firm then the “execution within firm” field should be populated with “CLIENT”. Similarly, where executions are filled by an order management system then this should be identified with an Algo identifier.

Venue identifier

The original guidance and RTS 22 indicated that all trading that was not directly on venue activity would be reported as XOFF. Unfortunately, the latest guidance suggests a move back to the MiFID I approach where the venue MIC code must be used when a trade is executed under the rules of a venue.

“The buying and selling interest of two parties is not brought together by the Trading Venue either on a discretionary or non-discretionary basis, but the transaction is nonetheless subject to the rules of that Trading Venue and is executed in compliance with those rules.”

ESMA confusingly goes on to say,

“Where an Investment Firm is not the direct market facing entity the Investment Firm is not regarded as executing on the Trading Venue for the purposes of transaction reporting.”

This seems to contradict the prior statement. The examples provided, however, do make clear that where the parties to a transaction agree that it is executed under the rules of an exchange or trading venue then the venue field should be populated with the MIC code of that exchange or trading venue.

Short-selling flag

Only real change here is that aggregated client orders do not require a short-selling flag to be populated as it relates to multiple clients. Transaction reports that show individual client-side activity will need to be populated based on the each client’s overall position in the traded security.

ESMA has also clarified in the examples that the short-selling flag is only required for uncovered short sales of shares and sovereign debt instruments per articles 12, 13 and 17 of the short selling regulations.

Cancellation of transaction reports

ESMA has clarified that only the “key” fields 1, 2, 4 and 6 are to be submitted in the cancellation report. Inclusion of additional field information will result in a rejection of the cancellation report.

Identification of the underlying instrument

Surprisingly, ESMA has asked that where there is a derivative on a derivative (an option on a future on an equity, for example) the direct underlying should be identified i.e. the future rather than the equity.

This raises the question of reportability. Are they suggesting that underlying refers to only one level down and when assessing reportability, there is no longer a look through to the ultimate underlying? For example, an option on an ADR on BT shares would not be reportable because the look through only goes down one level to the ADR? While when assessing the ADR you would look through one level to find BT shares and conclude the ADR itself is reportable? In the case where the immediate underlying is a future on a third country exchange that doesn’t use ISIN to identify its products means that the underlier field cannot be populated again – does this suggest that ESMA now considers such instruments as not reportable?

Equity swaps and instruments reported with two separate transactions reports

There has been an amendment to the approach ESMA wants to see for instruments which have multiple legs such as equity swaps. ESMA has compressed the two legs of an equity swap into a single transaction report using + and – to flag the buyer and seller of the legs. Previously in the consultation paper ESMA expected two transaction reports which were to be linked using the complex trade ID field.

Similarly, for equity swaps the ISIN code for each equity leg is included in underlying instrument field with a + for the buyer (receives the performance) and – for the seller (on the equity leg that where they pay the performance).

Similarly, where a benchmark is exchanged for equity performance the benchmark is identified in the “Underlying index name” field with a + or -.

Other things of note:

• Transfers are further defined in the text.
• Changes in ownership structure are reportable.
• Units of funds are not financial instruments and therefore not reportable.
• Transactions for the creation and redemption of funds are only excluded where they are directly with the fund administrator. This was in the prior version of the guidance but it is now much clearer.
• Identifying buyer or seller for trusts has been amended to be consistent with the approach taken for firms.

What’s not addressed
Outsourcing – do you need to be an ARM?

There is an open question being debated by lots of different interested parties. The suggestion by ESMA had been that where a firm uses a central reporting hub to generate the transaction reports for all the reporting entities in its group that firm would have to register as an Approved Reporting Mechanism or ARM. Similarly, parties that stood between the reporting firm and the ARM providing reporting services would also be required to become an ARM.

The guidelines clarify that

“No requirement for a receiving firm to become an ARM. There was request for confirmation that a receiving firm reporting details transmitted by a transmitting firm did not need to become an ARM. ESMA confirms that that is not an outsourcing arrangement as the receiving firm is making its own report and it is not required to become an ARM. A statement on this has been included in the relevant section of the Guidelines.”

From this it does imply that any form of outsourcing type arrangement involving your transaction reporting activity may require the supplier of the service seeks ARM status. This is not black and white and my suspicion is that this issue is still under discussion behind the closed doors at ESMA. What they have been able to do is rule out a scenario for receiving firms in the reporting chain to be ARMs.

My view is that extension of the ARM regime beyond entities seeking to submit transaction reports directly to a competent authority on behalf of third parties will be unworkable.

To conclude

The above is by no means an exhaustive list – as always, the devil will be in the detail. Firms should be looking to see if their request for additional scenarios (as requested in the consultation paper) has been appropriately addressed.

Do share with us here at Kaizen your initial reaction to the guidelines and anything further you’ve discovered so far. As mentioned, we will post a more thorough analysis once we’ve had more time to digest.

Happy reading!