An Interview with Sergei Poliakoff

By Mike O’Hara, 13th August 2013

With no threats of things like financial transaction taxes, maximum order/trade ratios, minimum resting times or any of the other artificially introduced initiatives to slow the markets down that are being increasingly discussed in Europe and US; Russia is looking more and more attractive to Western HFT firms.

And within Russia, Moscow Exchange is taking a number of steps to attract Western firms that are looking for new trading opportunities.

In this interview, Sergei Poliakoff, Chief Information Officer and Member of the Executive Board at Moscow Exchange, discusses some of the initiatives that he is spearheading, as well as some of the challenges he faces.

HFT Review: Sergei, welcome to HFT Review. Can you start by telling me a little about your own background?

Sergei Poliakoff: Thank you. I’m an engineer in maths and computer science by training and started my career at Bell Labs, working on operating systems before progressing to banking and finance systems, with all sorts of roles at Instinet, Citibank, Morgan Stanley, NatWest Securities and Deutsche Bank as well as a start up called QuadraServe, which was specifically an exchange business. My roles have ranged from running UNIX infrastructure to building equity derivative systems, analytics and then global execution, algos, trading systems, all that sort of stuff.  So on the broking side I have run large departments globally, but I also built a shop in Moscow where we put together a lot of interesting technology. When I switched to more market structure-type roles, dealing with securities lending, executions and so on, I ended up on the path to Moscow Exchange. 

From a personal perspective, I was born in Russia and so coming back here has been fun and interesting. The technical challenges and the scale of the tasks involved in changing the financial infrastructure in the country feed my psyche, I like that.

HFTR: And now you’re overall responsible for the whole technical strategy at Moscow Exchange, correct?

SP: That’s right.  So in the Western world I would be called the CIO or CTO of the Exchange, the titles are interchangeable. But yes, I’m the Chief Officer responsible for all aspects of the technology, from development to dealing operations, to the infrastructure and so on.

 It’s a fairly wide remit, but my own personal focus is the architecture around the transformation, that’s probably my greatest contribution to how we’re going to develop further from here.

HFTR: On the theme of transformation, the Exchange was merged at the end of 2011, it went public this year, and now you’ve got the two completely separate exchanges, each with their own technology architectures. You’ve got the task of bringing those together. How challenging a task is it to create a single cross-asset matching engine for the two exchanges, for example?  And what are some of the other key challenges you’re facing?

SP: There is a bit of a misconception where exchanges – or electronic marketplaces – are viewed as something that’s identical to a matching engine.  An exchange is far more than a matching engine; in fact the matching engine is the simplest component in all this.  Graduate students create matching engines as part of their diploma projects; there is even code for matching engines posted on the Internet.  So to me, the matching engine itself is not the interesting thing; having multiples of them is actually normal, there’s nothing special about that.  Even if they are the same kind, running multiple clones of the same matching engine and partitioning the order stream amongst several is a fairly common way to scale a trading operation. 

Right now, we do have two different matching engines, one of which services the equities & FX markets and the other, the derivatives market.  But merging them into one is not a goal that we’re actively pursuing.  The real challenge is the merging of the risk and clearing infrastructure. That’s actually where we produce most of our latencies and that’s where we get most of the work done because Moscow Exchange does full pre-trade risk checking. And whereas other exchanges might do their normal pre-trade, pre-validation checks, they generally limit themselves to market stability or client buying power or something like that.  We do a lot more than that, because we essentially perform a full clearing certainty check.

HFTR: So you’re pulling in a lot more data?

SP: It’s more data but it’s also the computational complexity of, when an incoming order hits the book, looking at the entire portfolio position that that particular client is holding and verifying whether, if the order executes and forms a position, it is going to breach the margin collateral held at the clearing house.  The majority of exchanges are not capable of running this check pre-trade because they’re not linked to their clearing houses the way we’re linked to ours.  For example in the US market structure, clearing houses are updated completely independently from the exchanges, so there is no way that the DTCC can tell the New York Stock Exchange for example, whether they’re going to accept an incoming order for clearing. Fortunately we do have this ability because the clearing infrastructure, the clearing house, is essentially the same company as the Exchange, we exist under the same corporate umbrella and we are connected technologically too, so we can create this clearing certainty. In addition to this, we can implement some very interesting and very wide schemas for portfolio cross-margining. And that reduces the cost of trading at the Exchange by reducing the cost of funding the trade.

HFTR: Are you able to do that for all asset classes or just for equities?

 SP: We can do it for all asset classes.

HFTR: And what kind of latency does that introduce?

SP: Under 50 microseconds. And you’re getting a lot of certainty, a lot of safety and a lot of stability – especially for what are essentially emerging markets – for this kind of latency hit. 

As we progress to further architectures, we’ll be introducing our two-tier risk verification structure. With that, we can reduce the latency of the pre-trade risk check even further. And again I’m not just talking about a “fat finger” or “crazy robot” check.  Everybody does that, but we do much more than that because we’re checking against the client’s actual portfolio and against the margin collateral, so it really is a clearing certainty check. I believe we can reduce the time for that check to under one microsecond while still providing a level of risk management and risk protection that’s probably unrivalled by anyone in the world.  So that’s really the philosophy, that’s where we’re going forward. 

Within that infrastructure of risk management and collateral management margining, we can have – and we will have – multiple trading cores.  Initially we’re going to use the ones that we have today, they’re quite adequate in terms of latency.  We’ll continue working on them to reduce the latency, and more importantly to stabilise it because it’s the dispersion of the latency, the jitter, that is more critical that the actual absolute number.

HFTR: Are you using FPGAs in your infrastructure for pre-trade risk checks?

SP: No, we don’t need FPGAs for that; we can get to one microsecond without using FPGAs.  I’m scared to think what we can achieve with FPGAs in this context, but the fact is we can achieve these numbers through a good architectural design and pretty much commodity hardware. We don’t need to go to FPGAs, GPUs or anything esoteric.  In a dynamic market – dynamic in the sense of emerging market regulation, emerging participant preferences and so on – FPGAs might be a bit of a limiting factor to us because we’re more dynamic with our release cycle than most other exchanges.  In certain markets we have up to four releases a year and in this respect, an FPGA-based solution or any hardware-type solution will begin to limit our ability to introduce change. 

We may go in that direction a couple of years from now when the general market landscape stabilises, but at this point we have no particular plans. We’re certainly aware of all possible available FPGA solutions and in fact I am speaking to vendors of those.  Are we ready to have a specific plan to go to FPGA?  No.  Can we achieve the numbers that we’re targeting without FPGA?  Yes, we can.

HFTR: Can you tell us a little about your future strategy around market data and order interfaces and protocols?  Will you continue to offer your own binary protocols as well as FIX and FAST alternatives, for example?

SP: For the indefinite future we’re going to continue offering FIX and FAST as the boilerplate solutions because they are the most recognised standards and probably the easiest to attach to. But we’re also going to offer the alternatives, just as we do today.  We currently have two binary APIs, one is faster than FIX and the other is actually slower, so we’re going to take the faster one and expand it to cover all the markets. Right now it’s only operating in the derivatives market, so we’re going to extend it.  As for the work on this, I am in very active discussions with vendors regarding what I would call the new generation of binary access path, because we want to transition to a faster binary access to our system, probably bypassing the API libraries and allowing the developers at client firms direct access to the wire and to the message structure itself as it goes on the wire. Unfortunately, I can’t go into any specifics on that right now.

HFTR: That’s a shame, it sounds very interesting!

 Presumably you are seeing more and more demand for co-location amongst your members and clients? How are you satisfying that demand?

SP: Co-location is just a function of the available space of the data centre.  Within our existing data centre structure we have plenty of room for co-locators, so if somebody comes tomorrow and says, “I’d like to place my computer next to yours”, we have no problems satisfying this demand.  One problem that has been an issue for co-locators – up until now – was the fact that the major systems servicing the different markets were housed in different data centres.  So the derivatives market was living in one place and the equities and FX in another.  But in August we’re moving the derivatives market to the same location where the other systems are.  This means that co-locators will not have to split their systems between two places; they can move everything into one place and have access to all of our markets as instantaneous as it gets.

HFTR: Your co-location centre is currently the Stack M1 facility in Moscow. What are your plans for future growth?

SP: Looking ahead, we have an ongoing project to provision a new data centre, but we haven’t decided yet whether we’re going to rent, buy or build. My guess would be that within a two year timeframe, we’ll have a new tier three data centre where we’re going to position all of the systems with co-locating equipment. And that data centre is going to be a world-class, state of art facility on the same level as you would get in, say, Aurora.

HFTR: In conclusion, are there any words of advice that you would give Western firms when coming to trade on Moscow Exchange, from a technology perspective?

SP: Not really advice, more a statement of our intent and direction.  There’s going to be plenty of innovation internally.  We’re building world-class systems, but outside it’s going to look like any other place. I don’t want any user to come to us and say, “Oh gosh, what a mess, I can’t even read this documentation”.  We’d like to be standard, we’d like to be normal, we don’t want to introduce any additional trouble or logistical obstacles to those who want to connect to us.

Russian markets need more HFT.  If you look at the percentages and the fraction of the market that’s really algorithmic HFT trading, we’re lagging behind the US and UK markets.  So there’s plenty of room for participation, we welcome it, we understand the special needs of the HFTs, not just from a trading systems perspective but from a risk systems and market data systems perspective too. Just improving the transaction time is not enough, you’ve got to see the market data fast enough, otherwise you’re trading blind.  We understand the need for balanced improvement of systems and means of communications across all types of systems and all functions, not just matching for example.  So there’s room for growth and we welcome HFTs.

HFTR: Thank you Sergei.

Download as PDF