Key Points

• Timestamp log verification of traceability to Coordinated Universal Time (UTC) and tracking of any variance – This is the hidden key to compliance
• Time granularity without synchronized accuracy is useless
• Define a Best Execution Process through an order execution policy
• Demonstrate that the execution processes are consistent with the order execution policy
• Define all workflow processes and implement governance
• Record all affected transactions for examination, risk mitigation and regulatory reporting

The Trouble with Time

New regulations from MiFID II in Europe to the Consolidated Audit Trail in the US mandate that reportable events must be timestamped to much more accurate levels than ever before and that regulated organizations must have a clear understanding of time for all information they are required to report. Europe’s MiFID II, in particular – which comes into force on January 3 2018 – is far more prescriptive with regards to timestamping, as defined by the European Securities and Markets Authority (ESMA) within RTS 25.

Regulators want a better ability to reconstruct trades for the purposes of market surveillance, through the provision of accurate time sequencing for events immediately before and after a transaction. MiFID II requires the accuracy of such reports to be as low as the 100-microsecond level for high-frequency trading firms, and for voice trades it will be one second. Firms must fully review how they manage time to ensure that events happen and are recorded in the proper time sequence. If this does not happen correctly, there will be situations where transactions may appear to travel forward or backward in time. Moreover, maintenance of time accuracy and clear links back to the time synchronization standard will be important to the effectiveness of analytics.

The technical requirements of RTS 25 must be met by both business clocks and by the actual computing and data systems involved in trading, including matching engines, order management systems, application servers and database servers. In other words, all compute, network and data systems, but not all events, involved within the pre-trade, trade and post-trade workflow. Although the requirement does not cover all systems within an enterprise, there will be many systems governed by this rule.

Clock synchronization and the associated time stamps are closely tied to the rules of best execution. This applies to both the sell side and the buy side. MiFID II ups the ante on best execution practices requiring buy side and sellside to define a best execution and an order execution policy. The firm must demonstrate the execution workflow and processes are consistent with the order execution policy. And all must prove quantitatively that the firm has taken sufficient steps to provide their customers with best execution against their policies and that they have taken steps to ensure that their processes are doing so. Thus, the need to ensure that there is a clearly defined best execution and order execution policy requires accurate timestamping of many events within the execution workflow, and these time stamps must be, in some cases, at the microsecond level.

Regulatory Technical Standard 25 (RTS 25)

The European Securities and Markets Authority (ESMA) developed the technical time standard for MiFID II and defined this within RTS 25. RTS 25 establishes all standard for clock synchronization which affects much of the functioning of business processes within the financial services industry. The goal is to acquire accurate and standardized, time across all domains within the transactions workflow.

RTS 25 governs the time reference that is to be used and the level of accuracy required for time stamps used in reporting records.

Article 1 of RTS 25 defines that the time reference used for synchronizing the business
clocks used by operators of trading venues will be Coordinated Universal Time (UTC).

“As per Article 1 of RTS 25, systems that provide direct traceability to the UTC time issued and maintained by a timing centre listed in the BIPM Annual Report on Time Activities are considered as acceptable to record reportable events. The use of the time source of the U.S. Global Positioning System (GPS) or any other global navigation satellite system such as the Russian GLONASS or European 285 Galileo satellite system when it becomes operational is also acceptable to record reportable events provided that any offset from UTC is accounted for and removed from the timestamp. GPS time is different to UTC. However, the GPS time message also includes an offset from UTC (the leap seconds) and this offset should be combined with the GPS timestamp to provide a timestamp compliant with the maximum divergence requirements in RTS 25.”

UTC is a time scale maintained by the Bureau International des Poids et Mesures (BIPM),
headquartered in Paris. The time scale is derived from comparing atomic clocks of over 70 recognized atomic clocks maintainers. These organizations include and/or are like national metrology firms such as the National Physical Laboratory located in the UK, the National Institute of Standards and Technology in the USA, or Physikalisch-TechnischeBundesanstalt in Germany.

Article 2 defines the required accuracy for clocks of trading venues. Requirements are detailed for the gateway-to-gateway latency time of a trading system, allowing the maximum divergence from UTC to be either 1 millisecond or 100 microseconds. The granularity of the time stamps can be either 1 millisecond or 1 microsecond, also depending on the gateway-to-gateway latency time. The 1-microsecond requirement is for high frequency or algorithmic trading operations, so most reporting will in the 100-microsecond range.

Article 3 covers the needed level of accuracy for members or participants of a trading venue. Five different types of trading activity are defined and like article 2 defines a maximum offset to UTC and a minimum time stamp granularity.

ESMA in Article 4 states that the operators of trading venues must establish a system of
traceability to UTC and define a sufficient level of auditability to deliver proof by documenting the system design and specifications. One must also identify the exact point at which a timestamp is applied. Compliance reviews of the UTC traceability system must be conducted annually.

So, we see an exacting standard applied toward the maintenance of time synchronization that is required. Without an exacting and clear synchronization of time is would be impossible to analyze and understand the functioning of the markets.

Online monitoring of the time synchronization is not indicated by this Article because it only requires annual review. However, there are a few valid reasons to establish a real-time time monitoring solution.

First, you should be prepared in the case of regulatory action or a lawsuit. The outcome of such an event may well depend on whether you can prove that the business clocks within your transactions workflow have been within the defined requirements of RTS 25. Another reason is operational hygiene. Your trading systems must be synchronized, especially if you are involved with high frequency or algorithmic trading where you must integration and correlate information from many sources to manage buy or sell decisions. It is also interesting to think of how time affects higher level applications such as Transaction Cost Analysis (TCA). If you come to realize that you have a clock out of sync, do you immediately resynch and thus cause a time delta, or do you continue to drift over time so there is a consistency of time for your analysis? In both cases how should this be shown in TCA? An order may have been placed at time t and fills arrive at t1 but what should the calculation be of t1-t yield? The best answer to this question is to ensure that you keep time synchronized always. One should also keep in mind that MiFID I guidance from the FCA for best execution rules apply to order routing and it is a “good practice” to use TCA as a tool to demonstrate how the execution venue selection occurred.

Increased granularity of time is pointless, however, if you do not have the time accuracy to match. Clocks need to be both accurate; i.e., with the correct time to a certain degree, and granular with respect to accuracy. There is no point using a granularity of microseconds if you are timestamping to a clock that is only accurate to the nearest second. Granularity and accuracy must go hand in hand to be valid. A systems clock cannot be more accurate that its synchronization sources.

Start with Process

The first step is to start with a detailed understanding of process. A firm must correctly
identify all the machines where reportable events will happen, ensure the solution can meet the precision/accuracy required and then ensure that effective and auditable monitoring is in place.

Machines may technically lose a central time service, but there must be a plan in place for alerts to the network staff and logging of events to make sure that any loss of time is audited — and moreover, to ensure that time synchronization is quickly reestablished. In most cases, these issues are resolved without time drift exceeding guidelines.

It is possible for machines to lose synchronization with a central time service, but there must be a plan in place to alert operations teams to address the issue immediately. If such an event occurs, it is imperative that an audit trail exists that is part of the reported records. In most cases, resolution is achieved prior to a firm drifting out of acceptable guidelines.

An operations director at a tier one London based bank believes that the issue is one that is manageable. He goes on to state that the reason to exceed the regulatory requirements is mostly due to the business believing that they need more accurate or precise time information to reduce slippage (for their analysis) and to future proof, because the market is getting faster in all areas of trading — not just high frequency trading.

Reporting Obligations:

Transparency

MiFID II’s new transparency requirements enforce the reporting of both pre-trade and posttrade information for potential and actual transactions.

Of course, MiFID II builds on MiFID I by defining a much wider set of instruments that
must be reported, going beyond equities to include “non-equity” instruments such as bonds, securitized derivatives, structured finance, and emission allowances.

Some of these instruments will need to be traded on venues such as organized trading facilities or multilateral trading facilities.

Pre-Trade Reporting

Market operators and investment firms operating a trading venue will be required to make public their range of bid and offer prices in each instrument, and the depth of trading interest at those prices.

Post-Trade Reporting

All transactions in equity-like instruments must have published price, volume and time of
execution to a time granularity to be as close to “real-time” as possible, or within one minute. Details of non-equity transactions will need to be reported within 15 minutes (this falls to 5 minutes in 2021).

This data must be published via Approved Publication Arrangements (APAs). Only largescale orders or financial instruments that are not liquid may be allowed deferred publishing.

Transaction Reporting

MiFID II also extends the scope of the more detailed transaction reports, which must be provided to regulators on a T+1 basis via an Approved Reporting Mechanism (ARM) and which will be used to identify any forms of market abuse.

The number of reportable fields in transaction reports will increase from 26 to 65, including information identifying the person responsible for the trade.

All counterparties to a trade will have to make a transaction report, including buy-side firms. Such firms may do this via a broker, but many are likely to report to ARMs themselves to avoid having to send highly-sensitive personal data to multiple brokers.

“So, it all boils down to putting lots of process and management in place to first correctly identify all the machines where
reportable events will happen, ensure the solution can meet the precision/accuracy required and then ensure that effective and auditable monitoring is in place.”

Head of Infrastructure – Tier 1 London based bank

The time requirements enable regulators to trace the complete path that a transaction takes so they may investigate market manipulation and attribute that manipulation to firms and individuals.

Key Hidden Challenge

You have been diligent. You have identified all the systems involved within the workflow that one needs to report. You have time synchronized and you are generating massive data logs to ensure you can prove compliance.

Now you must find the timing logs for the specific machine or trade within this massive database of logs and tie those logs back to UTC.

They key part of your solution is collecting, maintaining and of course reporting on the timing offsets to comply with the regulations. But, if you do not have a system to make the appropriate correlations for the timing offsets all the work done will be in vain. You must be able to make these correlations to prove that the timestamps that you applied to events that happened years ago were correct, auditable and specific to the area(s) the regulator is exploring.

“…if our network ever melted to the point they drifted out too far (of RTS 25 specifications) they would likely pull out of
the markets as they would have bigger problems than time stamping.”

Head of Operations – Tier 1 London based bank

Therefore, data management of your logs must be a key consideration for you to protect your organization and hard work and comply with the regulations.

Conclusion

Time is at the heart of all market activity. You must apply time against clearly understood and documented pre, trade and post trade, systems and transaction workflows.

In certain cases, you must acquire microsecond granularity of time but perhaps more important, that time must be synchronized to Coordinated Universal Time (UTC), so it may align with all other market activity. This is especially important for high frequency and algorithmic trading.

Effective governance is critical because regulated organizations must prove their effective time synchronization. A real-time monitoring regime should be put into place to help to ensure synchronization but to also maintain a full audit trail of any time drift that may occur.

Data log maintenance and the ability to manage those logs to accurately to prove that the timestamps you provide are correct is key to these efforts.

Regulatory compliance is almost always a burden in terms of cost, time and potential missed market opportunities. Effective synchronization to UTC will enable firms of all types to obtain a better understanding of their trading environments, not only for regulatory reporting but for their own need to model the market with reliable precision.

“Within the FIX working group, we are continuing to refine the guidance through peer review as we go through implementations. The two points that most people waver over are what to do about non-compliance (especially the typical short periods when a device fails over) and then what data to keep and for how long.”

Neil Horlock, Credit Suisse, Chair of FIX Clock Sync WG

About Tabb Group

TABB Group is a financial markets research and strategic advisory firm focused exclusively on capital markets. Founded in 2003 and based on the methodology of first-person knowledge, TABB Group analyzes and quantifies the investing value chain, from the fiduciary, investment manager and broker, to the exchange and custodian. Our goal is to help senior business leaders gain a truer understanding of financial market issues and trends, so they can grow their businesses. The press regularly cites TABB Group members, and analysts routinely speak at industry conferences and gatherings. For more information about TABB Group, visit www.tabbgroup.com