MiFID II and beyond. In depth session on a slightly different approach to compliance validation. George Nowicki, TP ICAP ITSF 2017

Transcription

1 MiFID II and beyond. In depth session on a slightly different approach to compliance validation. George Nowicki, TP ICAP ITSF 2017

2 MiFID II clock sync Global traceability of financial events 100 [us] macro scale meets micro scale Precise timestamp of a specific offset within IP packet.

3 Compare and contrast Telecommunications Industry Financial Industry physical reality Entirely acceptable, part of the package e.g. connection dropped no big deal business failure 100 [us] abstracted reality NOT acceptable huge reputation risk what is a microsecond?

4 A short introduction to market abuse

5 Loose coupling good or bad? Queue Processing Generally good, it can even help you to print money (but don t try this at home)

6 How? Market Participants Financial Exchange Queue Order Book SELL BUY

7 Just add another queue Market Participants Financial Exchange Queue Order Book SELL BUY

8 Knowing the future will make you rich Market Participants Financial Exchange Queue Order Book SELL BUY If you can see the queue and have the ability to place orders then you have both the ability to time travel (Back to the Future) and print money (riskless profit)

9 Market Surveillance and MiFID II

10 Timestamp to recreate the sequence of events Market Participants timestamp Financial Exchange Queue timestamp Order Book SELL BUY timestamp

11 Traceable event example (big picture) Matching Engine Application External clock reference Libraries Kernel Devices if the response time Is below 1 [ms] then the application is considered HFT and requires 100 [us] timestamp precision clock PTP clock New Order FIX Network FIX Order Confirmed e.g. 500 [us]

12 MiFID II compliance no clear guidance from the regulators as to how to achieve the compliance hence a lot of focus on the deployment of the clock sync infrastructure current status however this is the necessary but NOT sufficient condition for compliance

13 Burden of proof The directive states RTS 25, Article 4: operators of trading venues [ ] shall evidence that the crucial systems components used meet the accuracy standard levels so in order to mitigate the risk of non-compliance the focus for the rest of this presentation the obvious the not so obvious clock sync infrastructure understand the dynamics of the entire system, and identify factors that really matter

14 Clock sync in practice

15 Clock sync infrastructure GPS GPS A NTP GPS NTP NPL PTP PTP PTP B GPS PPS

16 A lot of decisions to make e3 NIST GPS ee NTP NTP NTP client NTP GPS NTP PTP client with hardware support NPL PTP PTP PTP PTP Precision e3 1.9 [ns] ee 3.8 [us] Time distribution mechanism: NTP Simple but dated and regarded as inferior to PTP (a view not always justified). Straightforward to implement without capital expenditure. PTP sophisticated, but needs hardware and infrastructure support to fully deliver on it s promise.

17 Compare and contrast Telecommunications Industry Financial Industry G G G G.8275 MTIE TDEV PPS over UDP PTP NTP

18 Why is PPS so useful (in absence of a proper lab)? NTP Req Rep clock sync server timeline clock sync client timeline offset and clock rolled into one PTP Sync FollowUp DelayReq DelayRep offset and clock separated PPS over UDP When sending PPS over UDP there is no need to send the transmit timestamp as this is happening on the PPS grid. This is significant simplification. If offset was also required, the DelayReq/DelayRep mechanism can be used as in PTP, but we are not duplicating PTP functionality. We just want to get some insight with simplicity.

19 Calibrating test fixture PPS FPGA NIC The distribution shown is a very good result and reference for further measurements. NTP Req Rep PPS jitter at the receiving hardware NIC on the 7.5 [ns] grid (just 3 significant buckets) reflecting 125MHz network clock PTP Sync FollowUp DelayReq DelayRep GPS FPGA Distribution PPS over UDP NIC 10 [ns] Intel I210 (1G) CentOS 7.3 POSIX

20 PPS over UDP NOT an alternative to NTP or PTP! BUT very useful in gaining the insight GPS Visualising network jitter PPS FPGA PPS over UDP one of multiple agents

21 PPS max. 1000ppm jitter, no drift network + software stack error Filter 1 Filter RT clock max. 50ppm drift, no jitter (1[ps] rms phase jitter)

22 PPS 6 1 RT clock

23 PPS 60 1 RT clock

24 PPS 60 1 RT clock

25 PPS 60 1 RT clock

26 PPS RT clock

27 PPS RT clock

28 PPS RT clock

29 Effectiveness of smoothing PPS error detection which is the primary source of error?? RT clock

30 Same parameters, multiple clients PPS which is the primary source of error? In a typical scenario it is this one RT clock

31 Time transfer model reference clock local clock error detection PPS over UDP error processing PPS e.g. 260 sec averaging window 118 sec median window

32 Clock sync in a nutshell. error detection PLL/FLL algorithm PTP or NTP error correction traceability

33 Clock sync in a nutshell. error detection PLL/FLL algorithm UDP packet error correction (software NOT hardware) traceability

34 Clock sync in a nutshell. error detection PLL/FLL algorithm UDP packet error correction ETA traceability

35 Anything wrong? YES

36 Large jitter and stable drift jitter (NO drift) PLL/FLL algorithm drift (NO jitter) traceability

37 Any evidence? disciplined clock undisciplined clock YES

38 Frequency counter reference clock local clock counter PPS over UDP PPS

39 Summary poor quality the primary source of error good quality RT clock Pause for thought The local clock is a quartz oscillator. It has a very low jitter and a significant but stable drift Historically the objective of NTP and PTP was generally just to eliminate the local clock drift. MiFID II is about something different. It is about making sure that at no point in time we are more than 100 [us] off from true UTC (punishable with a heavy fine). And we are trying to achieve this by adjusting a good quality local time (RT clock) with the reference time of much poorer quality (at the point of delivery). The PPS based approach allows to measure the quality of the time distribution channel and drift of the local clock independently of the clock sync software and in the open loop fashion.

40 The network is the computer. Is it really?

41 Architectural choices and trends FPGA FPGA FPGA + ARM (SOC) ARM FPGA ARM low latency and determinism FPGA + PHY FPGA PHY ARM + MAC + PHY ARM MAC PHY CPU + NIC Intel + FPGA PHY FPGA throughput and offload PCIe QPI NOT REALLY...

42 The network is the computer PHY FPGA PHY PHY fast interconnect what ever else

43 The network is the computer (and a lab) PHY FPGA PHY PPS fast interconnect GPIO CLK CLK

44 Thank you!