Considerations Around MiFID II Transaction Reporting
Blog: Software AG Blog - Reality Check
Within the last year or so, there has been a marked increase in the amount of fines levied on financial institutions by the FCA for transaction reporting breaches. Last year for example, Deutsche Bank was fined £4.7m for incorrectly reporting over 29 million swaps transactions, where the buy & sell indicators were the wrong way around[1]. Then in May of this year, the FCA levied its largest fine yet for transaction reporting failures – £13.3 million – to Merrill Lynch for a range of transgressions, including incorrectly reporting more than 35 million transactions and failing completely to report another 121,387[2]. Some of the failures included incorrect client and counterparty identifiers; wrong trade dates and times, missing maturity dates and buy/sell indicators reversed (again!).
Complexity
Whilst reporting whether a trade is a buy or a sell might seem pretty simple and fundamental, the details in these and other similar cases serve to highlight the increasingly complex nature of transaction reporting today. Firms might be trading on behalf of all sorts of clients and counterparties, across asset classes covering various instruments types, on a wide range of different markets falling under multiple jurisdictions. And they might be managing a range of trading desks across multiple geographic locations, each with their own trading systems, trade/data formats and local reporting requirements. So it’s not surprising that figuring out what needs to be reported to whom, by when and in what format, can become something of a system integration nightmare where things can go badly wrong.
MiFID II will only compound this situation. From January 2017, transactions will need to be reported across many more instruments and asset classes, on a much wider range of trading venues. And the details of what must be reported will grow substantially too, as firms will have far stricter obligations regarding the identification of transaction counterparties, individual traders and even computer algorithms. The number of firms impacted by these new regulations will grow too with the removal of buy-side exemptions and the requirement for any firm that is party to a trade in Europe – regardless of their geographic location – to report transactions.
Best practices
Unfortunately there is no “silver bullet” when it comes to addressing challenges around transaction reporting under MiFID II. But there are some best practices that firms can adopt. And by following these principles, firms will not only minimise the risk of being fined by competent authorities for reporting breaches, they will also have the necessary business intelligence to pro-actively manage their reporting requirements in the future.
Much of this revolves around how a firm captures and stores data and applies business logic to it. It is important that firms not only capture all of the relevant transaction data in the first place, but also that they have the necessary tools and infrastructure in place to be able to make sense of that data in order to translate it into meaningful transaction reporting.
Top-down Approach
Given the growing complexity in terms of what needs to be reported, one of the key elements here is to ensure that any reporting solution implemented for MiFID II can be modified to factor in specific local regulatory or asset/instrument-based requirements. For example, although there is no excuse for getting things like buy and sell indicators the wrong way around, it is an easy mistake to make when trying to fit the square peg of a payment/receipt-based equities swap transaction (for example) into the round hole of an exchange-traded derivative.
Firms need to take a top-down approach when it comes to transaction reporting, starting with the Chief Data Officer (or equivalent) driving the emphasis on the firm’s transaction reporting strategy. And with the fast pace of change around regulatory reporting in the financial sector – MiFID II and MiFIR transaction reporting is one example but there are others such as BCBS239 – it is important that any systems initiatives they undertake in this regard follow more of an integration-type approach where data can be transformed, rather than a complete re-building of their enterprise data infrastructure to cater for each new regulatory requirement.
Technology as Enabler
As is often the case when addressing complex business issues, technology can act as an enabler, as long as the right tools are used in the right way. Complex transaction reporting requirements can often result in spaghetti code that is hard to maintain and correct, but this challenge can be addressed by using Business Process & Analysis (BPA) tools – such as Software AG’s Aris – which are able to model transformation logic in a way that can be easily understood, verified and even modified by business analysts.
From a reporting and workflow perspective, Integration and Business Process Modelling (BPM) tools such as WebMethods can help firms not only monitor the end-to-end processes from their multiple systems to the approved reporting mechanism (ARM), but also define actionable workflows if (for example) a specific system extract doesn’t get produced, or the ARM reports errors.
In conclusion, the transaction reporting obligations under MiFID II, EMIR, Dodd-Frank, Basel III and so on are only going to grow over time. But if firms are able to use technology wisely to simplify what is becoming an increasingly complex area, they will not only save themselves a great deal of time and, they will also reduce the risk of non-compliance along with the associated fines and bad press.
[1] https://www.fca.org.uk/news/deutsche-bank-fined-transaction-reporting-failures
[2] https://www.fca.org.uk/news/fca-fines-merrill-lynch-international-for-transaction-reporting-failures
The post Considerations Around MiFID II Transaction Reporting appeared first on Reality Check.
Leave a Comment
You must be logged in to post a comment.
