With the new year just around the corner, so is MiFID II enforcement. Although MiFID is a widely encompassing set of regulations aimed at thwarting market abuse, one of the key areas is around timing, as defined in Regulatory Technical Standards 25 (RTS25). Because trades today are executed faster than a human can blink and the volume is overwhelming, monitoring everything in real time is virtually impossible.

The next best thing is to require firms to accurately timestamp all the relevant events so that regulators can piece together a chain of events to know what happened. This is precisely what RTS25 is meant to address.

RTS25 is pretty clear on the level of accuracies to UTC (Coordinated Universal Time) that your timestamps need to meet. For anyone implementing timing to meet these accuracies, the process and hardware needed is relatively straightforward (although not always simple to implement). However, as many finalize implementing their solutions for RTS25, there is one part of it that is often overlooked — the reporting side of RTS25.

Maintaining the accuracies defined in RTS25 is only half of the challenge. You must also be able to prove to regulators that the timestamps you provide on your reportable events are accurate. This is where things get a bit more challenging.

To begin with, the exact data and format of the data that regulators expect has not been clearly defined. Nor has the frequency at which data needs to be recorded.

On top of that, timing networks can be very complex – redundant timeservers, boundary clocks, multi-tiered architectures, etc. Not to mention that, in large networks with hundreds or thousands of clients, the sheer volume of logs generated creates a big data issue — how do you collect, sort, and analyze those logs for meaningful data?

To address this challenge, Spectracom has taken a database-centric approach. We’re working on offering a solution with regulations in mind, built upon a low latency, time series database by QuasarDB that allows us to easily manage all that data. We’ve also taken great care to ensure this solution will provide full UTC traceability — from your client to your time source.

We’ve also built all the complexity into the database itself and kept the front end simple, so that as requirements change or become more well defined, adapting to those changes is simple.

Stay tuned…more information to come as we get closer to releasing the solution!

Related Resources Related Resources

Safran acquires Orolia and plans to become the world leader in resilient PNT

News

Learn More

Safran acquiert Orolia pour devenir le leader mondial des solutions PNT résilientes

News

Learn More

Measure Measure

Take our free 5-minute assessment of your PNT needs.

Get Your R.E.S.I Report

Adapt Adapt

Reach out today to assess your options.

Contact Us

Jeremy Onyan
ABOUT THE AUTHOR
Jeremy Onyan

Jeremy Onyan, Director of Time Sensitive Networks, holds a Bachelor of Science in Economics from the University at Buffalo. He has over 20 years of Global Sales and Management experience. Onyan is recognized as an industry thought leader in timing for commercial applications, especially in Finance and Big Data.