4 Tips for achieving transaction reporting “completeness”
As part of our blog trilogy on CAT (Complete, Accurate and Timely) reporting, today we will address the topic of how to achieve regulatory reporting completeness for EMIR, MiFID II, SFTR as well as other regulatory reporting regimes.
To start with, reporting completeness can be defined as not “over or under” reporting and has been addressed on several occasions, including:
- ESMA’s requirement in Article 26(1) of MiFIR which states that investment firms which execute transactions shall report “complete and accurate details” of such transactions.
- ESMA’s final report on EMIR data quality peer review where several times they refer to the quality of data being complete and accurate.
Let’s take a look at what “complete” transaction reporting involves and how you can achieve it.
- Eligibility
Part of completeness of reporting covers the requirement to capture all trade data and analyze whether it falls under scope for reporting or not. The rules associated for completeness often come down to the type of investment firm. Some items to consider.
Asset Managers
For EMIR/SFTR, the counterparty to a report is the underlying fund. Therefore, when reporting, it is important to identify on the allocation level the underlying funds and sub-funds that are the ultimate counterparties that need to be identifies. This means that using order data may not provide complete details for EMIR reporting as it often is one the trade level before applying allocations.
On the other hand, for MIFID II, the challenge is identifying fills vs aggregated order details. MIFID II requires reporting of individual fills of a transaction when available
CFD Brokers with Match Principal
Under EMIR, brokers with a matched principal (STP) structure will encounter multiple legs for their report. Therefore, a separate Leg and UTI is needed for the Client-to-Broker leg and Broker-to-Liquidity-Provider. The result is that each trade requires two separate reports.
Under MIFID II, if trade details such as time and price match between the two legs, one report line is submitted. The report indicates the client and LP in the buyer/seller fields while the broker is the executing entity.
When determining if your trades fall under scope or are eligible to be reported under MiFID II/EMIR/SFTR or others, you will want to determine the following:
- Is the specific instrument and trade type reportable under a certain regulation? Make sure you do not have any reporting gaps by reviewing products and ISIN trades to ensure everything under scope is being reported as it should be
- Is the counterparty reportable? Make sure for instance you are excluding test trades or that the LEI of the counterparty is valid
- Is the trading venue reportable?
- Does the reporting entity have an obligation to report?
- If a reporting entity has multiple branches, which of its branches have an obligation to report? It is worth noting that the type of the reporting party changes the specifics of the obligation.
- Validation
Data validation is the process by which data is populated into the relevant reporting fields according the technical standards as outlined under the reporting regime. ESMA’s Data Validation Rules span many of the regulations including EMIR, SFTR and include guidance on data needed in certain reporting fields such as natural persons identifiers, legal entity identifiers (LEI), reporting timestamp, etc. When possible it is best to set up an internal validation process to reduce rejections caught by the TR or NCA.
- Trade Rejections
Trades can be rejected for any number of reasons by the regulator and can make your reporting incomplete and inaccurate. In my previous blog on reporting accuracy, we discussed the that trades are rejected. However even if you apply best practices when reporting trades, it is still important to put in place a rejection identification and handling process. Using our platform, we have seen our customers internally identify over x% of trades and resolve problems before their reports are even submitted to the regulator. Thus, overtime their rejection rates have improved and they have achieved complete reporting as per the regulators intentions.
- Reconciliation
Under MiFID II, the regulator requires investment firms to conduct systematic reviews of their regulatory report submission. The process requires periodically ensuring that the trades reported to regulator are reconciled with the trades as the regulator sees them.
- Why is this reconciliation important? When comparing the number of transactions sent to the regulator versus the number of transactions accepted by the regulator, you can identify numerous reporting issues such as rejections or records missed. Obviously, any omissions or errors will deem your reporting incomplete. You can read more about reconciliation here
- How does MiFID reconciliation work? A 3-way reconciliation is needed from the EMS/OMS data to the regulator and back. To do this, you need to reconcile the trades you send to your ARM with the results from the NCA. To perform NCA reconciliation, you must download data from NCA. In the UK, firms register for access to the Market Data Portal (MDP) to download XML files of ARM submissions and then the data needs to be compared to what is submitted. Additionally, you also need to reconcile front-office trades with what is being report
Do you want to ensure your transaction reporting is complete? Talk to us about our solution for Reconciliation, Eligibility for MiFIR, EMIR and SFTR as well as our validation engine and trade rejection tool.
