TRUP? You can't handle the TRUP!

A guide to transaction reporting under MiFID II

Of course, there will be no UK TRUP once MiFID II comes into effect. Instead, there will be an EU-wide version and whether ESMA will call this EU TRUP is an open question. However, with its eye firmly on an EU harmonised reporting regime ESMA, on 23 December 2015, released its consultation paper titled "Guidelines on transaction reporting, reference data, order record keeping and clock synchronisation" (the Guidelines). The principle behind the Guidelines should be welcomed by industry, i.e. to provide clarification on what is a complicated area of MiFID II. It is safe to note that without such guidelines all hopes of a harmonised regime would be lost. However, there are oddities, gaps and further clarifications needed; of course, this is all part of the consultation process and several hundreds of collective City of London hours will be spent pouring over this document.

Broadly, the Guidelines in terms of transaction reporting are broken down into four primary parts:

• General principles (Part I) which sets out some of the underlying principles that apply to transaction reporting;
• Blocks (Part II) where ESMA provides detailed step-by-step analysis of the transaction reporting blocks;
• Trading Scenarios (Part III), here, ESMA valiantly turns its attention to the multiplicity of trading scenarios possible under the enormously expanded MiFID II transaction reporting requirement; and
• Financial Instruments (Part IV), the final part of the Guidelines that focuses on the various reporting permutations for specific financial instruments.

There are then walk-through guides on "order keeping" that relate primarily to RTS 23 and 24, and that just go to show the bewildering array of operational requirements that will need to be put in place, particularly by trading venues and SI firms. The final piece of the Guidelines is a relatively short section on clock synchronisation that will do little to relieve the concerns of market participants about the pragmatics of the regime ESMA has proposed under RTS 25.

We note below some of the most useful elements provided by ESMA and suggest certain areas of continual uncertainty.

Part I: general principles

ESMA starts the Guidelines with a ringing reminder of the rationale for transaction reporting: the identification of market abuse and the monitoring of fair and orderly market functioning. This is true enough, but whether the collective burden imposed on industry by Article 26 MiFIR and RTS 22 is really necessary in the pursuit of this goal is a separate matter.

A few of the main points in this section are:

• MiFID managers: the Guidelines states that "where two investment firms trade with each other, each will make its own transaction report that reflects the transaction from its own perspective". Where the two firms are brokers, this is nothing new but signals greater change for MiFID managers (the FCA has noted UCITS and AIFMD managers are out of scope for transaction reporting) who will have to report (as transmitter to a broker, usually). It is likely that MiFID managers going forward are going to get less help from their brokers than previously and many are building their own systems rather than relying on transmission under Article 4, RTS 22.
• Matched principal capacity: an important point to make about the matched principal capacity is that this is different from how back-to-back transactions have looked like under MiFID I. In particular under MiFID II, the matched principal field is defined as "a transaction where the facilitator imposes itself between the buyer and the seller to the transaction in such a way that the buyer is never exposed to market risk throughout the execution of the transaction where both sides executed simultaneously". The requirement that both sides are executed simultaneously is a new development under MiFID II and gives rise to a number of knock-on questions in relation to systematic internalisation. Putting these aside for the moment, for transaction-reporting purposes back-to-back trades that do not occur simultaneously will have to be reported as DEAL or ATOC.
• Personal identifiers: a particularly difficult area in transaction reporting is the identification of individuals and ESMA's requirement for ongoing monitoring in this space. Where a counterparty/client is a natural person, the LEI is replaced with a natural identifier. Typically, this will be a passport. The Guidelines state that firms must "monitor the expiry date of a non-persistent identifier" – such as a passport. So when firms take on clients, they will need to know when the passport is due to expire and build a system in order to remind the client to give them the new passport number. This ignores the fact that passports might be changed for a variety of reasons (change of name through marriage or divorce, for example), or be renewed at a different time to the expiry date (for example, through loss or damage). This will be an administrative headache for all firms and it is not clear that the Level 1 text required this level of detail.
• What's in a name?: another administrative and unexpected quirk relates to naming conventions. When a natural person is named in a transaction report, the Guidelines require the removal of prefixes from surnames; 33 different examples (such as Von and de) are given. But not all are as straightforward as they seem, and some may be downright difficult to spot. For instance, if the surname is "Van der Rohe", only the word "Rohe" is to be used, but if the surname is "Vandenberg" then the whole surname is to be used.
• Exclusions to reporting – the problem of SFTR: ESMA includes a useful section at 6.1.6 of the Guidelines which walks through the meaning of reportable transactions and the exclusions to it. A number of these exclusions are straightforward but others are far from it. For example, if a transaction is reportable under SFTR, there is no need for a transaction report to be submitted. On many occasions, this will be unproblematic to identify – two investment firms entering into a repo, for instance. But there is a more difficult scenario. If the counterparty is a central bank, it is exempt from reporting under SFTR, and the transaction must therefore be reported under MiFID II by the investment firm instead. In other words, investment firms cannot assume that transactions falling under SFTR do not need to be transaction reported. They need to know the status of their counterparty under SFTR as well, i.e. yet more counterparty-by-counterparty monitoring!
• Exclusions to reporting – the problem of Mandatory Events: ESMA makes a number of useful points in relation the exclusion from transaction reporting for transactions that relate to "pre-determined contractual terms" or "mandatory events". This exclusion has been subject to some debate. In particular, there has been some wishful thinking that this exclusion can be extended to cover initial public offerings, secondary public offerings, placing or debt issuance. ESMA has said previously that all these elements are within the transaction reporting regime and it further clarifies that here. An interesting point to note, however, is that where a reporting firm receives allotment rights from a company, there is no transaction reporting obligation in relation to these allotment rights. This is because the creation of the financial instrument is a result of pre-determined contractual terms where no investment decision takes place at the point in time of the creation of the allotment rights. A similar point is made in relation to redeemable bonds. These clarifications will be welcomed by many.
• EEA branches: the issue of branches and transaction reporting perhaps deserves a chapter in itself. The basic starting position is that investment firms will have to send all their transaction reports to their home competent authority, regardless of where the transaction was executed. This means that where an investment firm's EEA branch reports part of the transactions, it will do so to the home competent authority and not the host competent authority of the branch. ESMA has noted that there are three exceptions to this general principle.
• The first is where the firm is a non-EEA firm but has the obligation to report its transactions. In this case, the home competent authority is an authority located outside the EEA and thus outside the scope of MiFID II. However, the branch which executed the transaction has a reporting obligation, and in this situation the following applies:
  • in the case that the non-EEA investment firm has one branch within the EEA, it will report to the host competent authority of that branch; or
  • in the case that the non-EEA firm has branches in multiple jurisdictions, it will choose one of the host competent authorities of its branches and report all the transactions to the competent authority.
• The second major exception is trading venues reporting transactions executed on their platform by members that are not investment firms. In this case, the trading venue is still required to report the transaction to its home competent authority.
• The third and final exception to the general rule is where the competent authority from the home member state and the competent authority from the host member state have agreed to deviate from the general rule. Investment firms are advised to contact their home competent authority to ask if such a deviation exists … such deviations could be seen as unhelpful complications to an already complicated system.

Part II: blocks

Although there are some further clarifications needed in relation to Part II, one of its principle merits is clarification around buyer and seller identifications. There are a number of examples where firms are uncertain as to whom to record as the buyer/seller depending on the particular arrangement. ESMA has gone some way to clarify this. For example, in the case of trusts, the investment firm is not required to look through the trust or the beneficiaries of the trust but just to report the trust which should be identified by its LEI where it has one. The general principle here is that firms shall report their direct client rather than trying to determine the ultimate client. This is a helpful principle to keep in mind when analysing the various arrangements which are relevant to transaction reporting.

A number of other points from this section are also worth highlighting:

• Short selling and other forms of torture: transaction reports have to identify whether or not the seller is, or is not, short. Where the firm making a report does not know from its records whether the client is short or not, it "shall request the client to disclose whether it is selling short". This must be done on a transaction-by-transaction basis. This seems to run contrary to high frequency trading models, unless a compulsory flag (short/not short) is included on every high frequency trade. There is a fall-back – where the short selling information is not made available to the investment firm, the field can be populated "UNDI". The guidance does state that the investment firm must request this information from the client first.
  Worryingly, ESMA notes that where a firm receives an order from a client and sells instruments in the market in relation to this order, if its market side transaction is earlier than its client allocation it will in effect be short and will have to report this, regardless of the fact that the firm would be flat after the purchase from the clients. This is not a particularly pragmatic approach.
• More on branches: unsurprisingly, ESMA spends much time setting out how to populate the fields in relation to branches. A complex example is provided whereby a Dutch investment firm (Firm D) receives an order from a Spanish client (Client D) in its Paris branch, where the Paris branch forwards the order to a fellow branch in London, which decides to execute the order on a trading venue (M), the membership of which is held by a further branch based in Frankfurt.
  The question is posed "how shall Firm D and the client report the branch fields?" The answer is, from the point of view of the investment Firm D, the country of the branch for the Buyer is "FR", the country of the branch membership is "DE", and the country of the branch supervising the person responsible for the execution is "GB".
  From the point of view of Client D, they do not need to include the country of the branch for the Buyer (although they would presumably know it is "FR"), nor do they need to include the country of the branch membership or the branch supervising the person responsible for execution. But they do need to include the country of the branch responsible for the person making the investment decision at the client (ES). This is how the above looks:

Thinking all of these examples through, they do make sense, but they do also show the tremendous complexity of the regime – a single trade would generate two different transaction reports which would identify the location of four different jurisdictions to cover the location of the client, the branch receiving the order, the branch deciding to execute the order, and the branch with the exchange membership. Phew!

Part III: trading scenarios

The third section of the ESMA Guidelines in relation to trading scenarios is perhaps the most useful.

• Gifts and other non-priced instruments: ESMA has confirmed that where client A who wants to transfer without price/charge instruments to Client B, the price field should be marked NOAP. The date and time of the report of transfer shall be that when the firm effected the transfer. This will be of interest to firms in relation to, for example, gifts or transfers between funds and/or portfolios.
• Child orders: the Guidelines make clear that when a firm breaks down a parent order into child orders, a separate report is required for each child order, even if the trade is eventually booked to the client at an aggregated or volume weighted average price. In a high-frequency trading environment, this might mean a very large number of transaction reports for what might traditionally have been seen as a single order.
• Client accounts: ESMA makes the point that the aggregate client account signified by INTC (client account) shall only be used in the circumstances set out in 1.3.5.2 of the Guidelines. Of particular note is the point that where there is a transfer into the aggregate client account, there shall be a corresponding transfer out of this client account within the same business day. Where there are transactions for multiple clients involving INTC, ESMA has noted that the trading price, date and time shall be identical in all three transaction reports, i.e. the trading price, date and time shall be the market price, date and time of the market execution. It is not entirely clear why this necessary.
  The consequence of the above INTC point becomes significant when a firm receives multiple orders and these are transacted over the course of a couple of days; here the firm will have to report the position at the end of each day since the INTC account cannot display changes in position for more than one day. How these allocations are recorded is in part down to the firm's internal procedures. For example, if a firm has purchased 500 out of a 1,000 instrument order and has client A and B, it will have to allocate this 500 between the two clients from the INTC account at the end of the day. It could do this by equally splitting the securities or on a time-priority basis, for example.
• Chains: ESMA spends much time setting out how chains and submission work. To recap, MiFID II requires that an entity which transmits an order has a transactional reporting obligation. The firm does not have to report the transaction if it satisfies the conditions for transmission set out at Article 4 of RTS22. It is worth reviewing the ESMA examples on this from page 109 onwards, which appear to make sense but demonstrate the potential for an enormous amount of reports. Specifically, it should be noted that where a transmitting firm does not meet the conditions for transmission, the receiving firm shall report the transmitting firm as buyer or seller. This is regardless of whether the transmitting firm has transaction-reporting obligations.
• Direct Electronic Access: ESMA has only touched on the issue of DEA and transaction reporting. The principle provided by ESMA here is that firms should report from their own "perspective"; this is slightly unclear and an example may help. What it appears to be aiming at is the fact that no investment decision has been taken by the DEA provider and therefore this firm does not have to consider the fields relevant to this. Further, transaction reports by non-EEA users might benefit from further consideration. Although it seems sensible that no report should be provided in this context (other than the DEA providers), confirmation would be useful.
• Give ups: ESMA has noted that there are a number of difficulties in defining give up agreements and sets out a number of definitions within the consultation. In particular, ESMA considers give ups for execution, give ups for clearing and give up relationships with clients. In relation to gives ups for clearing, there is an exemption for transaction reporting, and where a firm gives up a trade to another broker for clearing this is not a reportable transaction. However, this should be distinguished from where a firm gives up an order to another firm for execution where there is potentially a number of transactional reports required (in relation to the transmission and separately the execution).

Part IV: financial instruments

Part IV is concerned with the specifics of financial instruments. ESMA has set up a number of examples in relation to particular instruments, such as OTC derivatives, fixed income and spread bets. An example of how potentially complicated things can get can be seen from the calculation firms are asked to undertake in relation to net amount of debt (field 35). Further, although "debt" is not defined in RTS 22, ESMA in the Guidelines point to bonds and securitised debt as being examples (whether these are exhaustive is left unconfirmed). Firms are also left guessing as to whether ESMA has changed its mind on the requirement for all derivatives to have an ISIN. For example, the equity option example (at page 159) has no ISIN populated (field 41), similarly the equity swap illustrated at page 169. Is this just a slip or can reports be sent without an ISIN?

A further point to note is ESMA's view on the infamously intractable "strategy" field. ESMA provide the following: an investment firm X sells ten bund futures on Eurex Bonds and simultaneously buys a corresponding number of underlying German Government bonds. These transaction legs are part of this strategy transaction (basis trade) and traders will pay one single price of €20. According to the Guidelines, the transaction shall be reported in two separate transaction reports, each reflecting the transaction for one of the financial instruments that composed the strategy. Both transaction reports have to be linked by an internal code to be populated in field 40 that is unique for the transaction reports relating to the same strategy. This is useful guidance as far as it goes, the problem is that it does not provide principles for firms to decide whether their trades really are strategy trades; there are, it goes without saying, far less straightforwardly linked trades. What firms need here are principles as well as examples.

Order record keeping

ESMA has also set out as part of the consultation some guidance on order record keeping which relates to RTS 23 and RTS 24. The section on order record keeping is roughly about a quarter of the size of the transactionreporting guidelines. Nevertheless, this element of the Guidelines illustrates the enormity of the reporting obligations which will be placed on trading venues and SIs in particular. It is likely that this section will raise less concerns and calls for clarification than the transaction reporting section. However, firms will have to go through these fields very carefully to ensure that their operation systems where relevant are appropriately established.

Clock synchronisation

Finally, ESMA's Guidelines provide some illustrations on clock synchronisation, which has been the subject of much industry debate, given the impossibility of meeting certain time requirements. In this respect, ESMA sets out what it considers a reportable event for Article 50 of MiFID II at page 259 and goes into some specifics on time stamping as well as audit data record keeping examples. In reading this section, it is difficult not to look at the elephant in the room on it all, i.e. the difficulty in complying with the clock synchronisation and time requirements which are part of the level 1 and being debated as part of the level 2. The current guidelines in relation to clock synchronisation are not intended to and will not help firms in this respect.