For all of the improvements made in MetaTrader 5 and introduced by proprietary trading platforms, MT4 stubbornly refuses to lie down and die. In part this is because of the huge amount of time, which traders globally have invested in getting familiar with its operation (and the substantial sums invested in third-party Expert Advisors to automate their MT4 trading). It must also be partly attributed to MT4 being the most common component in the “Forex -in-a-box” offerings taken up by would-be forex brokers. Whatever the underlying reason, those tasked with preparing retail forex trade reports for EMIR purposes are highly likely to have to negotiate the quirks of MT4 as it relates to extracting and mapping the data to the EMIR report specifications. This article aims to give some hints as to what should be borne in mind during this mapping and extraction process.
First though it should be said that rolling spot forex trades, outside of the MT4 complications, are not particularly difficult to report. As they aren’t exchange-traded products, they will always be reported with a venue id of XXXX (indicating OTC derivatives) and will use the interim taxonomy (Taxonomy E), whereby you describe the product, rather than uniquely identifying it. And how you will describe this particular product is with CU (for Currency) in the product id 1 slot, which describes asset class, and with CD (for CFD) in product id 2 field, which states derivative type. For the regulatory basis of describing rolling spot forex as a CFD see my previous article.
Thanks to clarifications in the latest ESMA Q&A (March 20th) we now know that forex trades must have both Notional Currency 1 and Notional Currency 2 fields populated and that the Underlying field should contain the value “NA” and emphatically not the relevant currency pair.
There are, to be sure, some additional points to ponder on the population of Quantity and Notional Amount for forex trades. For the moment we don’t want to be too definitive about these, but have sought clarification from the regulator and plan to host a workshop for those affected at the Cyprus FX Conference in May. Watch out for the Abide Financial breakout sessions.
The main problem with turning MT4 trade records into compliant EMIR reports stems from the structure of the standard reports, and the fact that many brokers are not sufficiently familiar with the internals of MT4 to obtain anything more than the standard closed trades and open orders reports. These reports have the following peculiarities:
• Each extracted record in the Closed Trades Report implies two reportable transactions, the Opening Trade (which can be a Buy or a Sell) and the Closing Trade (an implicit Sell or Buy reversing the Opening Trade). Both of these trades share a single ticket number, so you will need to differentiate the two legs when populating the transaction reference numbers (for instance by prefixing the ticket number with O or C)
• The Open Orders report contains details of unfilled orders (which are not reportable) and executed orders (which are). Each Execution record contains a single Opening buy or Sell and basic trade details which can serve towards populating your EMIR report. The complicating factor is that today’s opening trade may reappear as the first half of a closed trades report tomorrow or on any subsequent day, so you need a mechanism to avoid reporting the same trade twice.
The first shock to confront the developer when starting to map these reports is the extreme sparseness of the data. From one client we receive a closed trades report containing 18 fields, only 9 of which are relevant for EMIR reporting, from which we have to populate two transaction records, each containing over 100 fields. Fortunately, there are some simplifying factors:
• A majority of fields can be left blank, or take the value NA, because of the very narrow product range typically traded on the MT4 platform and the fact that clearing and exposure values do not yet need to be populated
• Another great swathe of fields will have the same value over and over again because static data such as the reporting firm’s Legal Entity Identifier does not change from one trade to the next.
Retail forex brokers have the undoubted advantage that the majority of their trades are undertaken with individuals or non-EEA entities that have no reporting obligation. They can therefore submit one-sided trade reports without the worry of matching Unique Trade Identifiers or Trade Data with their counterparties before submission. On the other hand the European regulator, ESMA, having focussed initially on the large inter-bank swap market, has now started to address the guidance requirements of the Exchange-Traded Derivative community, but has yet to turn its attention to the retail derivatives sector. Forex brokers will therefore look in vain in official publications for tailored guidance as to what is expected of them. The same holds true for Binary Options Brokers and CFD and Spread Bet providers. The aim of these articles is to attempt to plug that gap, at least on an interim basis, until more authoritative guidance is provided. Whenever further information does surface, whether from the ESMA Q&As or individual communications, we will confirm our suggested approach wherever possible and revise it wherever necessary.
