The Technology Impacts of Mifid II (Part 3)

Much of the impact of Mifid II on post-trade workflows concerns data: the need to collect, normalize, transform and enrich an extended dataset for analysis, reporting and archiving purposes. We look first at the general need for unification of order data across systems for record keeping, before considering other post-trade workflows.

Order Data and Record Keeping

While new regulations for order record keeping (ORK) have at heart the need to generate a permanent audit trail, they imply a strong requirement to capture and correlate everything that happens to a client order as part of the historical record. This holistic view forms a key element of other post-trade activities including trade and transaction reporting, best execution and market-abuse monitoring. As well as extended information regarding each client order, the details to be captured include all associated child (and grandchild) orders, all house and market fills, any operations such as cancellations or amendments, as well as details of more complex activities such as management of composite orders.

A chronological biography must be captured, enriched and normalized across all firms’ trading systems that touch a client order, even though many of these systems may have no link to the client order itself. Firms commonly deploy a heterogeneous mix of systems for high- and low-touch flows with specialized algo boxes, smart order routers or pre-trade risk gateways, all of which have their own means of order identification and data logging. Linking child or grandchild orders generated by a home-grown algo box with client orders staged in a vendor OMS, or moved between different vendor high-touch and low-touch platforms, is not trivial; multiple layers of mapping between data export and logging mechanisms and order identifier schemes may be required to reconstruct a complete, normalized sequence of events.

Firms will be rewarded for investment in centralized solutions for collecting and normalizing data from other systems to provide the required data structures for downstream processes, including archival storage for record-keeping purposes. The alternative is a series of complex modifications of existing systems to generate multiple views of the data they hold to meet the needs of different post-trade processes.

Trade Reporting

Trade and transaction reporting are different processes with different goals; the purpose of the former is to publish trades to other market participants in the interests of transparency, while the latter is aimed at regulatory scrutiny of trading activity for compliance with market abuse regulations. Despite the differences, Mifid II presents similar challenges for both: new reporting logic to determine what to report and by whom, and a greatly expanded set of data—for a larger range of eligible instruments—that needs to be reported.

For trade reporting, Mifid II brings a new set of rules with the intent to significantly broaden visibility into trading activity in listed and over-the-counter (OTC) instruments. Accuracy is key; over-reporting is not permitted, so the “if in doubt, report” approach that has been the norm is acceptable no longer. The shrinking time window for reporting (reduced to a maximum of one minute from execution in many cases) implies an automated process with close affinity to the OMS that is tracking executions. But firms that deploy multiple order management system (OMS) solutions for different asset classes, regions or trading desks will want to centralize reporting due to the complex rules, data enrichment and connectivity to reporting venues. This introduces the idea of a real-time trade reporting service, connected to, but independent from, specific front-office solutions.

The logic to determine who is responsible for reporting in different scenarios is more complex under Mifid II—technologies like business rules engines (BREs) may be needed to automate this logic. In some circumstances, buy-side firms can delegate authority for trade reporting to their brokers, but they are still accountable for ensuring reporting is done correctly. Consequently, more buy-side firms will handle their own trade reporting, or, where an “assisted report agreement” is in place, will need real-time drop copies from their brokers of all reports done in their name, in order to match against their trades to validate correctness.

Mifid II allows intermediaries to set up as reporting venues, handling pre-trade and post-trade publication of quote and trade information. Such third parties will be approved by the regulator and will operate under an Approved Publication Arrangement (APA). A number of firms have announced that they will operate APAs, but with different levels of coverage of Mifid instruments and different workflows, data formats and APIs. Besides the obvious need to build and certify new connectivity, automated business rules will be required to select the most appropriate APA depending on instrument and other characteristics of the trade. At the user level, a unified interface will be needed that shows the status of all reporting—and allows interaction to cancel/modify reports and handle APA rejections—regardless of which venue the report has been sent to.

Transaction Reporting

Mifid II transaction reporting rules also introduce new connectivity requirements—to so-called Approved Reporting Mechanisms (ARMs). While firms will likely work with multiple APAs for trade reporting, it is expected that a single ARM will suffice in most cases. The integration requirements are also likely to be less challenging, both in terms of workflows and technical integration; most communication with ARMs will be through file upload.

A vital role of an ARM is to enrich transaction reports with data before sending them to the regulator on behalf of market participants. Mifid II introduces more than 25 new reference data fields to be included in transaction reports, including identifiers for venue, entity, instrument, currency and more. This reference data is fragmented across different authorities, updated on different frequencies and accessed via different mechanisms, which the ARM will handle. The ARM will also hold some of the more sensitive data on the individuals involved in the decision-making process leading to order generation and routing. The exact mechanisms to handle this sensitive data are still being discussed, and data security requirements will be paramount in any solution.

Despite the longer time windows—transaction reports must be sent to the regulator on a T+1 basis—firms may wish to report to their ARM much quicker, to detect and resolve problems well in advance of regulatory deadlines. This, coupled with the complexity of rules and amount of data to be included, means the entire transaction reporting process will also have to be heavily automated.

Because of the new trade and transaction reporting regime, and the impact on a broader set of market participants, a number of “reporting hub” services are being launched to act as intermediaries. Such services will alleviate much of the technical burden on participants, but not the overall accountability for ensuring reporting is performed correctly.

Best Execution

Best execution rules are extended under Mifid II. Fundamentally, the rules apply to all “Mifid instruments,” introducing requirements for accurate benchmark pricing for many non-equity products to calculate performance metrics. For trade information, venues are required to provide much more detail on trade capture reports, such as whether a trade was passive or aggressive from the point of view of each counterparty. These requirements will necessitate further technical work to integrate new sources of pricing data and extended trade capture feeds from trading venues.

More formal reporting on quality of execution is also required including annual reports relating to top execution venues, percentage of client orders executed on each venue, how much of this was passive versus aggressive, and more. This emphasizes the need for capture of detailed order and execution information in a normalized form as the basis for later analytics processing and report generation. 

The overall impact of the above changes to post-trade workflows is to drive a higher degree of centralization and automation. Compression in reporting windows and the need for consistent management of order and reference data further blurs the line between front-, middle-, and back-office functions. A consequence for technology will be a greater focus on open architecture and standardization of APIs to allow specialized systems like order/execution management systems to inter-operate in real time with middle- and back-office systems to enable bidirectional transfer of data and control.

In this series of articles we have examined some of the impacts of Mifid II on current trading technology. The impacts are broad, touching connectivity and trading systems in the front, middle and back offices. Assessing the full extent of the impact, however, will only be possible once Mifid II has become “business as usual”; this will be many months—if not years—from now.

Richard Bentley is chief product officer at Ullink, a Paris-based provider of multi-asset trading technology and infrastructure to the buy side and sell side. 

Sponsored content