Continuous Evolution and Development of Clock Sync for Regulatory Compliance Beyond MiFID II RTS 25

Continuous Evolution and Development of Clock Sync...


Continuous Evolution and Development of Clock Sync for Regulatory Compliance Beyond MiFID II RTS 25

by Ben Newton
about the authors
Continuous Evolution and Development of Clock Sync for Regulatory Compliance Beyond MiFID II RTS 25

Share this Blog with a friend.

About the Author

dark mode

In 2018, regulators in Europe and the US introduced clock synchronisation regulations for financial services firms. In Europe, ESMA’s MiFID II requires investment firms and venues to timestamp trading events accurately to Coordinated Universal Time (UTC) and to an appropriate level of granularity such as microseconds for High Frequency Trading (HFT). Since February 2018, US firms have been timestamping to the National Institute of Standards and Technology (NIST) atomic clock in order to meet SEC 613 requirements. Accurate timestamping is a high priority for the regulators in all jurisdictions and we expect to see requirements become more onerous over time. To optimise clock sync investments and service performance, Citihub Digital has been working with a number of clients to build best in class operating models.

Clock Sync Themes

Citihub has observed five common clock sync themes:

Clock Sync TailCompleting the full roll-out of clock sync infrastructure post MiFID II
Continuous ImprovementEstablishing a process of continuous improvement as part of the BAU operate model
UTC Application CoverageImproving application level UTC coverage when applying timestamps
Annual ReportingImproving the efficiency of annual reporting
Cost reductionLowering the cost of the clock sync compliance


Clock Sync Tail

When MiFID II went live on 3rd January 2018, many firms had not fully completed clock sync infrastructure implementations. For many, the aim was to have as much coverage as possible at go-live and a roadmap for remaining implementation actions. Approaches for delayed implementations include:

  • 80/20 coverage by tackling easy implementation actions and delaying difficult to solve edge cases. Good examples of these edge cases include cross-regional and multi-entity flows;
  • Regional and/or line of business prioritisation.

In addition to planned delays, some firms have been subjected to unplanned delays caused by vendor difficulties, integration problems, and changes in technology direction. Incomplete clock sync coverage can impact a firm’s ability to meet its order record keeping obligations and transaction reports to national competent authorities as well as impacting the effectiveness of market surveillance.

The key client challenge is how to address coverage gaps and the compounding processes of continued new regulation and changing business requirements. To overcome this, Citihub recommends that the clock synchronisation service should be established as a long-term (multi-year) programme or be embedded as a BAU function.

Continuous Clock Sync Improvement Programs

Clock sync solutions are not always perfect. This can manifest itself in failure to timestamp transaction reports in UTC or electronic trading businesses not having the required accuracy or granularity.

Co-located HFT environments typically achieve high levels of accuracy. This is because these implementations tend to be comparatively small and are managed by a single team with direct control. Citihub has observed issues in enterprise data centres and networks because scale results in network jitter and end of life systems can result in signal drift outside of reporting boundaries.

In the case of MiFID II, RTS 25 Article 4 requires an annual clock sync traceability review that highlights variances or performance issues. Citihub recommends generating a metric to describe the time systems spend within compliance of clock sync requirements. Thus, instead of saying a system falls outside of compliance because of a single or nominal variance, it can be reflected as the percentage of time the system was available and compliant 99.99999% of the year. Clearly, variations need to be logged, analysed and remediated but this approach balances compliance with the reality of complex and large estates.

UTC Timestamp Application Coverage

The applications in scope of MiFID II timestamp requirements are, typically, complex and have many interdependencies. For top tier firms, this is compounded by sheer scale.  Examples of compliance impacting events include:

  • Exception code that is rarely executed (e.g. on a leap day/second) that has not been tested for UTC usage;
  • UTC timestamping within an application ceases operation when failing over to a DR server is in another region;
  • An in-scope application that has each of the required remediations but makes the wrong system call to take the time signal from the server clock rather than the NIC, or through poor SDLC controls, reverts to the wrong system call.

Citihub adopts a forensic approach to ensure regulatory submissions are correct. This starts by ensuring there is an inventory of all businesses and applications, each mapped by requirements for UTC timestamps (e.g. level of accuracy and drift). Firms should be extending existing CMDBs to capture this information. Full implementation of this inventory is a foundational requirement and should be completed before regulators tighten requirements.

Annual Reporting and Testing

A statement of clock sync compliance is not a statutory regulatory submission, but firms must ensure one is produced annually (RTS 25 Article 4 and within recital 5). Most firms have produced early reports in a bespoke and sometimes ad hoc way. Automation of the reporting process reduces long term costs and ensures that the relevant level of quality is achieved and appropriate for different regulators.

Typically, Citihub uses a template-driven approach to capture the appropriate information for each regulator. Because there is no template, or specification within the text of MiFID II, we recommend an approach of minimum viable disclosure.

Annual clock sync testing should not be left to the last month of the year. Data should be collected and collated each month using a plan that clearly defines owners and testing responsibilities. Waiting to complete all testing (and potentially implement remediations) during month 12 is a high-risk strategy.

Cost Reduction

Achieving clock sync compliance for MiFID II was a considerable expense for many firms. Firms faced a range of strategic, governance, technical and obsolescence hurdles. To avoid erosion of this investment, Citihub recommends an effective operating model and BAU investment plan to ensure that the estate is well managed and maintained. This reduces compliance risk and will also reduce the cost of embedding new regulatory requirements as they emerge.

In the rush to achieve MiFID II compliance, some firms made sub-optimal investments in technology that now look expensive by comparison to Open Source competition. Technologies such as Chrony and low-cost hardware by players like u-blox and Jackson labs, with GPS and PNT cards, have been getting orders of magnitude cheaper.

Each firm should execute an annualised clock sync health check that examines:

  • The effectiveness of governance, operating processes and controls;
  • Clock sync performance and stability;
  • Standardisation and re-architecting opportunities to improve service, flexibility and to reduce costs.

Conclusion: Towards a Clock Sync Target Operating Model

Regulatory focus on clock sync will increase in the coming years and requirements will become more onerous. An effective operating model that reflects each firm’s RTB and CTB objectives can reduce compliance risk, improve flexibility and manage down costs.

Related Insights

See technical discoveries and coding insights from our developers.

Find out more about life at Citihub

about us