As a result, the spread between bids and asks, and credit spreads is wider. That gives traders more margin, and Goldman, which put more value at risk during the quarter than at any time in its history, was uniquely poised to capture trading gains. [2]

The above letters-of-fire was from an MW story posted just yesterday.  Now everyone take a deep breath, because we’re diving deep into the mysterious places where those trading gains get made.  These are the venues where a war for information supremacy is currently being fought, with big bucks the prize, so a breakthrough sensor design could make a critical difference.  Who knows, could Serge’s code tarball have contained today’s equivalent of the plans for a Randall & Boot cavity magnetron?

Doom was shocked by some of the information that started coming out after the Aleynikov affair broke open. Was Goldman Sachs really making countless billions of dollars in profit out of what sounded for all the world like playing tens of thousands of rounds per second of Paper / Scissors / Rock against the punters in the world’s captial markets? Now coming from an era when placing a bug in somebody’s phone was a big deal, I was gobsmacked at the idea that major financial institutions were being allowed to colocate racks of networked supercomputers right in the Holy of Holies of the core infrastructure of exchanges like the NYSE. However, it would seem … C’est normal!

Even if this is all above-board, seems that the opportunities for market dominance and possibly manipulation (to the benefit of the Plunge Prevention Team, if we’re in a Men in Black sort of mood) is extreme. Public participation in examining this situation [3] would therefore be indicated.

Fortunately, there are various web resources to start studying the issue. I recently came across this fascinating podcast about low latency and algorithmic trading.[1] I’m going to hope that creating a new Doom transcript of the interview and adding a few obvious annotations to the text doesn’t stretch the point of their Creative Commons Licensing too far. I expect that there may be a few people looking for information like this, and if this transcript directs a few new listeners to the May 2008 discussion, it will be well worth the trouble on this end.

Interestingly, there are PDF transcripts on the site for all 6 earlier ‘casts in the series.  The present special ‘cast seems to be the most relevant one to our purpose, though.  I hope these guys take up the microphone again soon, now that there is intense new interest in the topic.

UPDATE (7/23): Mike sends … :)

From: Mike O’Hara (ViB)
Date: Thu, Jul 23, 2009 at 2:29 AM
Subject: Re: new online transcript of your May 16, 2008 podcast
To: John M

Hi John

Thanks for your e-mail, and thank you for producing the transcript and bringing attention to the podcast series.

We agree that now would indeed be a good time to try to resurrect the series. We are approaching sponsors to see if we can get some funding to produce more interviews.

Watch this space!

Best regards
Mike O’Hara

The podcast homepage provides this handy guide to the parts of the ‘cast (which I’ve taken the further liberty of using as section headings in the transcript):

Notes for the May 16, 2008 episode:

00:08 – Introduction
01:24 – Some background and history
02:18 – At what point did latency become an issue?
04:01 – The diverse business drivers for reducing latency
07:36 – Orders versus market data
08:40 – The exponential growth of option data
09:26 – Managing real-time position risk
10:38 – Dangers of quote mitigation
11:32 – Causes and types of latency, & where it is introduced
15:32 – Piecemeal versus big-bang approach to reducing latency
18:22 – Measuring and monitoring latency
21:44 – Visualisation tools & heat maps
22:14 – Consistency & reliability versus outright speed
23:29 – FIX, FAST & other industry standards
25:55 – Proximity hosting and co-location [this bit the most relevant to understanding the Aleynikov Affair]
29:25 – What Telco & network providers are doing
30:57 – Do latency reduction initiatives justify the cost?
31:45 – Potential operational risks inherent in low-latency strategies
34:48 – End of interview and wrap-up

Introduction

Mike O’Hara: [00:00] Hi this is Mike O’Hara of Voices in Business, welcoming you to a special edition [May 16, 2008] of the Algorithmic Trading Podcast, focusing on low latency. Now earlier on in this series we featured an interview with Thomas Chippas, head of Autobahn Equity in North America for Deutsch Bank.

And one of the topics that’s been a recurring theme, not just in our interview with Thomas, but pretty much every episode of the Algo Trading Podcast, has been low latency. So we decided to ask Thomas back to talk to us about the subject in more depth.

Joining me on the interview is the host and moderator of the Algo Trading Podcasts series, Greg Grimer of Voices in Business. And if you want to hear the original interview with Thomas [March 13, 2008 -- that one has a transcript onsite], just go along to www.AlgoTradingPodcast.com . Here’s the interview.

—————————–

Greg Grimer: So the purpose of today’s interview, Tom, is really to dive down a bit more deeply into low latency, because in the 6 episodes we’ll done to date, low latency is obviously an issue that’s come up in every interview with every bank that we’ve interviewed. But we haven’t really done a deep dive, so the idea of today really was to get more into the nitty gritty of the low latency aspect of algorithmic trading, and why it’s important to reduce latency and what the … some of the knock-on effects are in terms of cost and risk and other things.

Some background and history

Thomas Chippas: Certainly low latency has been a popular topic, and if you dig into it and its history, it really started off here initially in the US as something for folks that were trying to take advantage of various rebate schemes at the different market centers, and really folks that were focused on black-box trading, getting closer to the actual trade and beating everybody else to the trade.

But with all things that start off being bespoke or boutique and applicable to a niche, they tend to mushroom and grow and become standard, and something that everyone needs to address, and I think we’ve reached that tipping point here. As regardless of the type of electronic trading you’re engaged in today, you can’t ignore the tidal wave of market data and message traffic that’s taking place every day, and they have to address it in a way that lets you process nonlinear volume, but do it actually in an acceptable period of time.

At what point did latency become an issue?

Greg Grimer: So thinking back in your career, then, at what point did low latency become an important issue. In other words, when this … when program trading started off (it wasn’t called algorithmic trading then, it was called program trading) presumably there were other issues to get it done anyway, that were not so fast as the speed of the computer.

Thomas Chippas: Yeah, that’s a good question. I would say that there are different aspects of this; there’s the latency of receiving and disseminating and processing market data, there’s latency in transmitting your order to the market centers and receiving it back, but looking at it from the perspective of your question, I would say if you went back to 2002 / 2003, people started to notice an uptick in the number of fill[ph] messages coming back to those program orders at the time. And then into 2004 /2005 we start to think about decimalization’s impact here in the US. And the number of fill messages on an order that came back from the buy side desk became overwhelming.

And many of the popular trader management systems that are still around today, obviously newer versions and iterations, at the time weren’t able to cope with that.

So when stock was traded in pieces-of-8 here, and you had people trading things in 1/8ths and 1/4s and 1/16ths, the number of fills that you came bacl was statistically lower than what you received for fill messages in the new world of decimals.

And I think that was probably the canary in the coal mine. Certainly now what most people would think of when they hear of latency or you’re thinking about measurements of speed between two different points, but if I had go back to the point where using the benefit of hindsight 20/20, I can see that that would be the first point that latency started to crop up.

The diverse business drivers for reducing latency

Greg Grimer: OK, the whole issue of latency, I guess, is of import to different types of trader and different types of organization, and different people within the organization. Can you maybe talk us through some of the business drivers for the those different types of trader, on the sell side, on the buy side, whether institutional or proprietary trading. Because some traders obviously are looking at the long term, and others are in and out of the market doing kind of statistical arbatrage, and that kind of thing.

So where is this important, and why?

Thomas Chippas: Yeah you’ve hit the nail on the head, there. Most people may have an investment horizon, or a view towards the outperformance of their trade versus just market return that could be quite long. But the fact of the matter is, if the majority of the flow that is executing today, regardless of geography, wherever it may be, is taking advantage of lower latency technologies, it will have an impact. Your orders will, by definition, be victims [05:00] of adverse selection if you aren’t too taking advantage of the low latency technologies that are there.

So even if you are a long term investor, and you go to liquidate that large position and take a gain, you could lose several bps [basis point == 1/100 percent] on a trade if you’re not using technology and execution tools that take advantage of low latency.

So I think initially it definitely was the black box high frequency trading community, not even folks that were running statistical or index arbitrage models. These well people that, as I indicated originally, were taking advantage of price disparity across different venues, and differences in the rebates schemes to try and earn the rebates, and get the rebate cheque from, in the case of the US, from NASDAQ or Arca or, you know, going further back, BRUT, etc., these sorts of folks.

And then obviously, for statistical and index arbitrage traders, it also became necessary to take advantage, and they were also looking at these arbitrage opportunities.

And slowly but surely from there, it eked out, much to Greg’s point earlier that this all started off in the program trading desk. Well, if I’m using this technology for my electronic execution, my algorithms, why wouldn’t I want to take advantage of this across all of my execution technology?

So it sort of mushroomed. And then as we reached the tipping point in the early 2000s, where this algorithmic trading, sell side technology started to be pushed out to the buy side, people started to take notice.

I would argue that today, the majority of the traders at long-only type shops, with that longer term horizon, they’re aware of latency, but they’re not really concerned about it.

Hedge funds tend to be, because they have a lot of traders that are former sell side traders and are aware of these issues, but, you know, if I’m a traditional long / shot global macro type fund, I’m aware of it, and I know bad latency when I see it, but I’m probably not overly concerned with measuring it.

And then you have the high frequency statistical and index arbitrage shops, where you can ring them up and say, "how’s latency today?" and they’ll say, "Well hold on, let me give you your ranking, I’ll give it to you right now in real time."

So it’s a real diverse spectrum of people, though I’ll come back to … If more and more flow is taking into account latency, and is using low latency solutions, it’s hard to say, "I’m a long term guy," and just ignore this at this point, because you can’t. They’ll have an adverse impact on your execution.

Greg Grimer: So essentially it’s becoming sort of a fundamental feature of a trade?

Orders versus market data

Thomas Chippas: Yeah, it is, from 2 perspectives.

  1. If I’m consistently the last guy in line, I’m going to
    1. miss the quote; or,
    2. be picked off.
  2. Of course the other aspect of this, and I’ll bundle it under the umbrella of low latency, is on the market data side.

So we’ve been kind of focused on the "getting my trade to market" side.

If you look at the market data side of things, look at the statistics in the US. And I use the US only because we have such a diversity of markets centers here. You have 7 options of execution venues. There’s 13 protected quotes and you’ve 40-plus total markets, if you add up all the ATSs.

There’s a lot of quote traffic, and I point out options simply because, you know, it’s an exponent of the equity quotations. It’s staggering. 700,000, 900,000 messages per second. These sorts of numbers, to just process that, sift through it, and take out what you need to go execute your order, is a gargantuan task, and I think many sell side firms and buy side firms that do consume that level of data, although there’s very few that take in that level on the buy side, are really confronting that right now. And I think that qualifies under the umbrella of the low latency problem.

Greg Grimer: And I guess those numbers are only going up as well, aren’t they?

Thomas Chippas: They’re not abating …

Greg Grimer: … no …

The exponential growth of option data

Thomas Chippas: They’re not abating by any stretch. I think in the US, it was the fear, as we transitioned Reg NMS [my uncorrected transcription: "OREG[ph] in a mess"], and it started to materialize, just the number of quotes that you get, and then if you look on the options side of things, because of the nature of options, right? For one, equity underlying, I could have tens of strikes on the put and call side. There’s a significant amount of data there, and people are struggling, and there’s new entrants into this market on the market data side, whether it’s people focusing on the transmission of that information, you know, sort of the messaging side of things, or folks working through a normalizing of that data, and giving you a subscription of just what you need.

And I think right now, the majority of people are filtering out what they don’t need, simply because their pipes couldn’t handle the entire fire hose from point A to point Z.

Managing real-time position risk

Greg Grimer: I mean traditionally, when the fall[ph] people were doing program trading, and they were just manually entering, say, derivatives trades into a trading system, one of the issues they had, when the portfolio got large, was just managing the risk on it in real time, or anything like near-real time.

Is the position keeping on this an issue of latency, too, given the amount of data points that [one] has to consider?

Thomas Chippas: I think that, going back to my earlier point about what was sort of the canary in the coal mine, the fill traffic, most sell side firms, [10:00] and any sort of high frequency trading shop, or anyone that’s heavy into programs, has implemented an execution management platform that’s built to deal with the high rates of fill traffic.

If I were to compare fill messages to market data and quote messages, it would be statistically insignificant. So I think that anyone who is engaged in an active program trading and active algorithmic and direct market access trading, you know, as the underlying technologies for execution, they’re in good shape on the sell side, and on the high frequency trading side with respect to the fill traffic.

Dangers of quote mitigation

But you do raise a point about, if I’m using a model that’s trying to operate in real time, and I’m just suffering from this deluge of quotes, how do I manage that? And there are different approaches people are taking, either quote mitigation, which I’m not a big fan of, because you could miss pertinent information, quote mitigation being defined as: if I’m receiving 10 ticks, and I can only process 6, then drop, you know, 4 ticks out of 10, so that my machine doesn’t crash. Some people do that. It’s just, to me, not an acceptable solution.

On the other part, it really comes down to being intelligent about the data you need, so that your risk management utility is only receiving the data it ultimately needs. So there needs to be intelligence in that publication and subscription mechanism, so that it can just calculate what it needs. If I’m working on an S&P 500 basket, I don’t need the Russell 3000 coming into my machine to do my risk analytics.

Causes and types of latency, & where it is introduced

Greg Grimer: OK, so if we can maybe look at the different causes and different types of latency, where are some of the biggest culprits for introducing latency, do you think? Is it mostly on the application side, or is it the operating environment, or the network? I mean, what are some of the things that we’re looking at?

Thomas Chippas: Yeah, I think we’ve touched on some of them, but to kind of aggregate it under the causes and types, obviously the cause in it’s most summarized form is: there’s too much data from a quote perspective and execution message perspective, filling pipes that are too small.

If your pipe has only a capacity of 1, and you’re trying to put through 2 times through that pipe, it’s not going to work. So we can say the cause is too many quotes, too much traffic being generated, but that sort of assumes that you can reduce that, and we can’t. It is what it is, that’s what … that’s a fundamental output of the markets we exist in today.

So knowing that we have to process all that information, where does the latency typically occur? And I think it breaks down across a variety of segments, some of which are the trading applications, some of which are the feed handling and message handling components, and then also, there’s also a bit of contribution in there from the actual market centers themselves.

So yes the market centers are producing this data. Some are more efficient than others in how they publish it, but not everyone subscribes to every market center in the same way. So by way of example, if I’m taking a feed of market data from, let’s say, NASDAQ and Arca and BATS here in the US, directly, because they’re, you know, 3 of the top 4 execution venues in the US by volume, you know perhaps I’m taking the other venues off a consolidated feed.

Well now I have a difference. I’m taking raw direct data from some markets centers, but then somebody else is taking that raw data and consolidating it for me from the others. And now I have a disparity in the timing of those quotes, so when something comes down the consolidated pipe, it might not be arriving as quickly as something coming down the direct pipe, even though the point in time the quotes were generated at both sources are the same.

So I can have some disparity there, and you have to account for that, and manage and mitigate for that. So that requires some intelligence in your publication and subscription from the market centers themselves.

Within the 4 walls that you can control, whether at a buy side or a sell side firm, you obviously … the technology used to move those quotes between the various points is very important, and there are a number of vendors in the space now that are pushing out, you know, the next wave of middleware, I think, if I wind back the clock to 5 / 6 / 7 / 8 years ago when people started really hearing the name "TIBCO," or I should say when business guys such as myself knew what TIBCO was, as opposed to the technology guys, your TIBCO has run its course, and it still is an active vendor in the space, but there are technologies that have leapfrogged it now, that are focused on this low latency communication environment, and there are a number of vendors out there that are sort of promoting themselves as the next replacement for TIBCO, that works well with them, but also has a whole new solution.

And then on the software application side, there’s an entire cottage industry of conferences and consultancies around bespoke hardware as well as taking commodity hardware and applying it to these problems.

So on the market data side, you see people with something called FPGA hardware based acceleration for processing market data, and then you have people using the multi-core chips, [15:00] the same ones you buy in your laptop today, to take advantage of systems processing simultaneously, rather than synchronously.

So I think there’s a lot of places people address it. It’s brute forcing through hardware, it’s intelligence in subscriptions to the market data, and then it’s making the hardware you have do more and rewriting your applications to take advantage of the processing capabilities.

There is no one answer, and it’s all about fitness for purpose. What am I trying to achieve? Which latency is most important to me? Because you could focus on speed for speed’s sake, but if that doesn’t contribute and address your trading needs, you’re just wasting your time.

Piecemeal versus big-bang approach to reducing latency

Greg Grimer: It must make the architecting of the way you’re going with this very complicated, and to some degree more of an art than a science. I mean, how do you sit down and decide when we are going to change our middleware, what we’re changing it for? And do you ever get the chance to do more of a, not even a Big Bang, but change several elements at once, where you think that the combination of those elements is going to let you make a big jump? Or is it always going to be piecemeal changes and tweeks?

Thomas Chippas: I think that it’s — for established providers such as my firm and my peer firms — you’re always very focused on, obviously, providing a top quality execution service. But there’s one thing that’s, you know, typically doesn’t come out in a discussion on latency, that clients won’t suffer. And that’s bad operations.

So you are always focused on, no matter what I’m making, whether it’s a tweak or a Big Bang leapfrog, those trades need to print and settle. And that’s something you’re always focused on. So I think it depends where you’re trying to actually effect change. I know for us we always have sort of a sandbox environment in which we can attempt new things, and we try and quickly roll those thing out.

So I don’t know of anyone doing a Big Bang, simply because I don’t know that a Big Bang is necessary today. For example, there is always the age old brute force approach of simply buying faster hardware, right? The Sun or Dell sales guy will always be happy to come and tell you to buy a bigger, faster box. That being said, you might not get maximum efficiency from that, so maybe you do it in 2 phases.

Let me take my existing application and put it on a bigger, faster box. It will by definition go faster, right? If I swap off the 4-cylinder engine for the turbocharged 8-cylinder, and put it in the same car, the car will go faster. It might not get good miles-per-gallon, but it will go faster.

So I think you can do things like that in 2 phases. Just put it in and make your existing infrastructure faster, and then you go through and you evolve your application to be more efficient, and you get greater throughput in 2 stages that way.

I think with respect to other types of technologies, it just depends what they are. Something like changing your market data subscription technology, look, I’m doing it today, I’m getting good information, I can continue to use that and try out new technologies there, and if they’re superior, go to them very quickly, because it’s really … market data is one of those things that’s binary: it either works or it doesn’t. So if you architected something new, and you burn it in in the testing phase, if it’s working, you can turn it on and go full bore with those sorts of things.

So I think it varies, and there’s different opportunities to bring to bear these technologies, but it can be staggering. What I focus on is defining the business requirement, because, again, this is the sort of thing where you can focus on speed for speed’s sake, but if you haven’t defined what’s fast enough and what’s the most critical, your technology people will go away and come back with a solution that doesn’t fit your purpose.

Measuring and monitoring latency

Greg Grimer: On the topic of measuring latency and, you know, monitoring how fast things are running and where the bottlenecks and so on are, there must be some real problems with that, because when you dance at milliseconds and microseconds, how do you actually go about measuring this stuff, and how do you know that the results that you’re getting are consistent and accurate. I mean that must be a pretty difficult thing to do.

Thomas Chippas: Yeah, it is. And there’s a whole industry cropping up around that, too. So I think if you look at it from a technology point of view, the maturity of measuring latency across a pipe is there. There are plenty of tools to do that.

But we’re not just talking about transit time across a pipe, there are applications processing this data, handing this data off. There are gateways to market centers. There are all sorts of touch points, some of which are raw network, some of which are application and line handlers, some of which are database.

So what you really need, and the way I look at it is, it’s a big algrebra problem. So the way I’ve defined it is: Point A is when the order leaves the client. So literally when their FIX engine generates that order. And point Z is when they get that order back. And then what I aim to do is slice up, in as finite as possible a way, every step along the path, whether it’s network, another FIX engine, a line handler, an application, what have you. You create that algebraic equation, and then we can just fall back on simple mathematical properties, right?

If the client doesn’t care about a measurement from BCD … to E, well let’s just sum those, and we’ll call it all "B."

So if you slice it up in a granular enough way, you can reconstitute [20:00] the pieces in a way that’s representative, not only to me, but to my client, who ultimately is who I’m concerned about satisfying.

Greg Grimer: But can you measure each of those segments using the same tools?

Thomas Chippas: … That’s where the difficulty comes …

Greg Grimer: … Yeah, …

Thomas Chippas: … I would say that there are two, … so there are two general approaches that are being taken. And there is a whole array of vendors in this space that have just cropped out of nowhere.

One is the bespoke measurement community, where they have a framework, and they will come in and they will listen to your network traffic, and then they will work with you to find the nuances of your application in line handling and feed handling stack, and they will write the bespoke listeners that will take all this information together, put it into a database and let you extract it out.

So it’s: "Heh, we have a framework, we know no two firms are the same, we are going to come in and work with you to plug into all the right places, and tie it all back together for you." That’s one approach, so that’s all called sort of the "ground up" approach.

The alternative approach is sort of the "top down," which says, "Look, everyone’s different, so rather than having to manually crank it out every time for everybody, what we’re going to do is capture as many data points as we can across that A to Z transit, and then we’re going to use a big inference engine that looks at all these data captures we’ve done, and try to come back to what we think the measurement pathways are, and these points are, and then we just tweak it around the ends."

So it’s kind of intriguing, actually.  There’s two different approaches. one of which is "let’s detail it out, and do what we need to do to solve it exactly." The other is "let’s just look at everything we can, and tweak it around the edges."

So it’s kind of interesting, there’s two different approaches. I wouldn’t say that one is superior to the other … yet. But definitely there are two different schools of thought there.

Visualisation tools & heat maps

Greg Grimer: Are there any visualisation tools you use to give the look of the A to Z thing in some sort of heat map, or something like that?

Thomas Chippas: Definitely, so you have all sorts of things. We have heat maps, obviously, to show you perhaps what’s slow and what’s fast. For someone like me, I’m interested in which exchanges are slow or fast. And you have to sort of have to get a baseline set of data, and then from that baseline set of data you’re really interested in how far … what’s the standard deviation, right?

Consistency & reliability versus outright speed

Because, I think there are always going to be some clients that want you to be outright "the fastest," but, you know, I’d rather be the guy that is 2nd place, 99.999 percent of the time, every day, to every market center, rather that a rotating number 1, that’s only there maybe 1 day a week.

And I think if you talked to people who are extremely latency sensitive, once you get down into that relevant range, and you’re fast enough, they start to care about standard deviation more than they care about outright speed at very tight range, because, again, we’re talking about, if the accessible number, just for the sake of discussion, is 10 milliseconds, if you’re consistently 11, and the guy who’s 10 is only 10 one day a week, they’d rather come to the guy who’s 11 all the time.

So these tools really put all their data into a data structure, whether it’s a traditional relational data base, or memory, or what have you, and then there are a lot of visualization tools that let you look at histograms that slice it up into different buckets, heat maps that show you where things are peaking.  And then there’s just, you know, good old line charts and pie charts that kind of show you contributions.

So we look at all those things, and try and use that as our guideposts, not only for all our internal development, but for using and having a metric based conversation with the market centers and other vendors we deal with.

FIX, FAST & other industry standards

Greg Grimer: Earlier you mentioned FIX, and how you measure the order coming out of the clients as a FIX message getting filled, and going back to the client. I’m interested in how industry standards such as FIX and FAST, and so on, can help with latency, if they can. And any kind of initiatives that are being done in that area.

Thomas Chippas: Sure. So you … FIX has been great in terms of providing a common language for us to use, although I always joke, it’s English, right? But we all speak English but you say, "lorry," I say "truck."

So it’s a common framework, and we could figure what we’re all saying, but it isn’t … it’s an interpretive standard.

So because it’s an interpretive standard, there has to be a lot of an information within the message to tell me what it is I’m looking at. And I kind of have to know what to expect, and what to look for.

So it’s been good in normalizing the playing field, leveling the playing field, so that we can all speak to each other, but I don’t think anyone would stand up and say that FIX is the most efficient way to communicate an order. FIX is an efficient way to communicate market data.

So with the advent of the FIX Adapted for STreaming [== FAST] protocol, to address market data, I think the folks that wrote that standard recognized that, and took that into account and tried to create a message standard that takes into account speed.

If you look at the market centers, I’ll use NASDAQ as an example, you know, it’s safe to say that if you send them an order via FIX and then you send them that same order using their native protocol, [25:00] you’re probably going to see a, you know, a 4 to 6 millisecond difference in processing time in favor of the native protocol over FIX.

So what that tells you is that, in the case of NASDAQ their matching engine doesn’t natively speak FIX. And maybe that’s because of legacy investment and the various matching technologies they have acquired over the years, or maybe it’s because they feel they’ve found a better way to do it, and changing over would lead to your performance degradation.

Either way, there’s not a lot of market centers that still natively process FIX inside their matching engine. They may say they do, or appear to, but when you dig into it and you measure the differences, you do find an underlying difference.

So I think FIX has been good to get us all delivering information in the same way, but if you really keep peeling it back, there are still some places where speaking the native protocol of your target execution venue is advantageous.

Proximity hosting and co-location

Greg Grimer: I’d like to maybe move onto the issue of proximity hosting and colocation. We’ve seen a big movement over the past couple of years, I guess, a lot of firms have put their kind of black boxes and applications and so on actually colocated at the exchange sites, but with the fact that there are in more and more trading venues coming into play now, the growth in these Dark Pools and so on, is colocation still relevant, or is the … now that you got these proximity hosting venues, where you can do the same thing, but it can give you access to a wide range of venues. What are your thoughts on that?

Thomas Chippas: So certainly I’ve yet to see an issue that’s come up so fast in this industry, and come full circle so quickly. If you look back about 18 months ago, the concept of proximity hosting was making a common sense to people that were confronting REG MNS in the US, where you have 13 protected quote markets centers, and you have upwards of 40-plus places you can execute a trade. That’s a lot of places to get to. And historically, before REG NMS, you had a lot of folks who were focused on speed putting their equipment in the data center of NASDAQ, of Arca, what have you, and for them, they were either trading independent strategies at those market centers, or the fact they could pull a line in to get to Arca from NASDAQ and vis versa sufficed for them.

But with the advent of REG NMS, folks were concerned that the actual liquidity would move so quickly between markets centers, that if I were colocated at NASDAQ and had to suddenly get to the NSX, if I didn’t have a quality connection there I might be slow.

So I think it’s come full circle because people have realized that 80-some-odd percent of the flow flows through the top 4 market centers here, and it’s relatively static. There might be differences between them intra-day and inter-week, but in general that’s where you find it, so the concept of leaving my equipment at NASDAQ or Arca, as long as I’m good to these top 4 venues, makes sense, and is achievable and is feasible for some folks.

That being said, now the question’s changed a little bit. I want more than just a market data feed of equity. I need options information. I need CME data, etc. I’m may be running a global strategy and need data from other market centers oversees.

So now the concept of proximity hosting makes sense to someone that wants to have a proper data center support and market data support coming in from a diversified set of venues over a low-latency fiberoptic connection. And then if I’m sitting here on the East Coast of the US and I have fiber optics going out to all these market centers, I’m now measuring in microseconds the transit time, and if I’m 50 micros, or 110 micros to get from my box in NASDAQ to the NASDAQ naxing[ph] engine, well if I’m only adding 50 / 60 / 80 / 90 micros to get from the proximity hosting center on top of that, on a percentage basis it’s quite high, but it’s pretty, pretty thinly sliced at that point, and I think that it’s all about fitness for purpose.

So for folks that aren’t set up in a colocated environment already, proximity hosting may make a lot of sense, because I can get to many, many more places, get data across many different asset classes, all from one location, with someone who’s focused on data center services.

It’s not to say that NASDAQ, Arca, others don’t do a good job there, but certainly I don’t think they would say they’re in the data center business on a customer-facing side of things.

So the issue’s gone full circle and now has gone back to fitness for purpose and what makes sense for me and my business.

What Telco & network providers are doing

Greg Grimer: Have any telco or network providers really stepped up to the plate on that and said, "We’ll make a big committment to the financial services market globally, so that you can be on … you can have one network carrier." Because obviously that would make a difference, wouldn’t it?

Thomas Chippas: Yeah, it would. I think everyone always wants diversity, and certainly a recognition from your provider that you’re going to need to deal with a competitor, for that diversity is necessary, and most of them have been very good about it.

BT Radianz has probably been the most vocal and made the biggest investment. Certainly they’ve opened up a large proximity hosting here in the US, with fiberoptic infrastructure, and not only bring in the raw data and having the raw outbound connections, [30:00] but housing vendors that support trading applications. So whether it’s Reuters, or other folks in the market data space, or trade processing space, they brought them all together in one location, and they continued to build it out.

Fixnetix in London has obviously done quite a bit, Deutsche Börse is obviously doing some of their own in Frankfurt. I think you see in Asia a variety of transactions taking place with different folks to provide this thing, and I think Asia … the need in Asia is lower on the equity side, but people are looking for uniformity, and they look down the road and recognize that the same sorts of issues we’re encountering here will end up there.

So I’ve named a few vendors. I’d say, yes, there are some that have stepped up, and others who are just trying to be good citizens and are saying, "Look I’m going to work with whoever you’d like me to work with."

And so I think that there’s still room for people, but it’s a big investment, it’s a lot of infrastructure to get behind and amortize over a lot of customers over a long period of time.

Do latency reduction initiatives justify the cost?

Greg Grimer: Do you think most firms in the algo trading space have passed the point where the cost that they spend have been justified by profits going forward? Or do you think that that point is still to be covered by most firms?

Thomas Chippas: I think it varies. There are a lot of firms that perhaps were top tier years back, that have been surpassed. But the difference between No. 1 and No. 10 is shrunken considerably because of the commoditization of some of this technology.

So I would say that it used to be just the cost of a ticket to get in the theater was very high, but now the theater owners have recognized that they can sell balcony seats, and they can sell opera seats. And we’re all getting into the theater now, just some of us in the balcony, and some of us are in the opera box.

Potential operational risks inherent in low-latency strategies

Greg Grimer: And do you think, finally, to top this off, Do you think there are any potential operational risks that are inherent in these low latency strategies, where … I mean is there any sort of acknowledged potential risk for all players in the space having all their eggs in one basket, as it were?

Thomas Chippas: Well I think that there are … you always have to be aware of the operational risks. And it comes back to, I think, the theme we’ve talked about throughout this whole podcast, which is: speed in and of itself isn’t going to be the answer for everyone. If you look at, operationally, what occurs in environments and geographies where you have multiple market centers amongst which you trade, I’ve yet to see a consistent graceful way of a market center telling you there’s a problem.

You really have to react to various conditions, and depending upon those conditions, you may or may not want to convey all that back instantaneously to your client. You may want to redirect order flow, hold it up momentarily until you get clarification on what’s occurring, or perhaps give clients outs, and give them opportunity to trade somewhere else.

But I think there’s no one answer. I think folks aimed purely on speed could lead you to make investments that yield no profit and additional costs. So it all comes back to that definition of what you’re trying to achieve, putting in place some of the metrics we’ve talked about, and then making a fitness for purpose selection.

I mean, if it were all marketing, why wouldn’t I want to be the fastest? Why wouldn’t I make that investment? The fact of the matter is, the majority of people that are trading algorithmically today on the buy side, they don’t ask you about latency, they ask you about performance, flexibility, access to liquidity. It’s my job to know that latency is a component of that, and service that.

For the Black Box community, the statistical index arbitrage or any of the high frequency trading strategy, latency is part-and-parcel with your product. They care about it. So you need to meet their requirements.

So it depends who your client is, and you certainly don’t need two infrastructures, but you need to be able to tune and measure and monitor your infrastructure for those components that are most of interest to your client.

Greg Grimer: Um hm?

Thomas Chippas: This is good business practice. And you have to define what you need to service your clients and stay ahead of the rest of the market and then pick amongst the various solutions that could be presented to you.

I would say that this would be a topic that will be very interesting to revisit in a year’s time with respect to the impact of growing options market data, and equity data here in the US. And more importantly in the markets in Europe, where diversified trading venues are opening up, and under multilateral trading facilities you’re able to execute for the same share of stock in different places. It will be very interesting to see how they’ve been impacted by these issues, and whether or not the solutions are portable between the different geographies.

So I think there’s probably something to revisit here down the road.

End of interview and wrap-up

Greg Grimer: Thank-you very much for your time today, Tom. It was very interesting.

Mike O’Hara: That was an interview with Thomas Chippas, head of Autobahn Equity in North America for Deutsch Bank. If you’d like to hear more interviews along similar lines to this, then visit www.AlgoTradingPodcast.com . And for interviews with thought-leaders [35:00] on a wide range of business topics, visit www.VoicesInBusiness.com .

Thanks for listening. Good bye.

Notes and References

[1]: "ATP Special Edition – Low Latency (featuring Thomas Chippas, Deutsche Bank)", The Algo Trading Podcast, May 16, 2008.

[2]: "Profits on Wall Street turn out to be evasive", by David Weidner, MarketWatch, July 21, 2009.

[3]: "What’s the frequency, SEC?", by Matthew Goldstein, Reuters, July 21, 2009.

Still, there’s little doubt there’s a lot of money to be made from automated trading that relies on complex mathematical formulas to predict momentary price moves in stocks and commodities. The name of the game in high frequency trading is literally trying to stay one millisecond ahead of the competition thousands of times a day. High frequency traders also earn lucrative “rebates” from stock exchanges by serving as de facto market makers for fast-moving stocks
…

Some say there’s already evidence high frequency trading may be playing havoc with the markets. James Angel, a professor at Georgetown University’s McDonough School of Business, says the big end-of-the-day price swings in the major stock indexes that were quite common last fall were probably exacerbated by high frequency trading.