Latency not top priority: HKEx

Latency might be important for traders, but reducing it should be not the exchange’s overriding aim, according to the co-head of the IT division at Hong Kong Exchanges and Clearing.

Latency might be important for traders, but reducing it should be not the exchange’s overriding aim, according to the co-head of the IT division at Hong Kong Exchanges and Clearing (HKEx).

For an exchange, how important is latency and its deployment?

“Latency is not important, in the sense of bringing down latency from 150 micro-seconds to 100 micro-seconds. What is more important is reliability and monitoring the consistent level of our system’s latency,” says HKEx’s Richard Leung.

Leung joined HKEx in 2011. Before then he was the chief technology officer for Chi-X Global.  

He was speaking at Trading Architecture Asia in Hong Kong this week in a panel discussing the evolution of a high-performance trading fabric.

“It is hard for an exchange to justify the costs of reducing end-to-end latency,” says Leung. “We seldom get latency complaints, because our throttles are structured in a way that you can’t bust the platform I.” In HKEx, throttles are  control mechanisms that govern trading capacity

By way of comparison, he says that Canada is currently launching a trading platform which features a mere 30 micro-seconds of latency. According to Leung, rather than aiming for speed, more focus at HKEx is spent on backing up without pain and without the market being adversely affected if something goes wrong.

HKEx has been investing heavily in new technology at its new Tseung Kwan O datacentre, including the HK$3 billion spent in the last couple of years on IT in its so-called ‘Project Orion’.

In terms of current speed capabilities, HKEx now has 40 Gigabit capacity at its disposal. It isn’t a resource? the exchange needs right now, but Leung says it is something HKEx can grow into.

He was also mindful that if HKEx’s systems are tweaked to provide slight enhancements, an unintended by-product could be a more complicated framework that risked going haywire.  “To keep our reliability we need to keep systems simple. I don’t want to trouble my developer when performance is at a certain level, as it would just make systems more complex.”

«