Steve, how did it all start?

Radez: After leaving college I worked for IBM for two years before moving on to Merrill Lynch as a retail account executive in 1970. I was not a good one - good AEs find out what the customer needs and sells it to them. I on the other hand wanted to deploy certain trading strategies I had developed. I left in 1977 when one of my largest customers agreed to capitalise me for a seat on the CBOE (Chicago Board Options Exchange) and Essex Radez was formed. Waiting for flow to arrive in the pit was pretty tedious, so I would fulfil my volume requirements there in the morning before trading - more profitably - from upstairs, for the rest of the day. I finally left the pit in 1979 to trade upstairs permanently.

So when did you start automating your trading?

Radez: 1984. I started using a service bureau - National Computer Network - to scan for trades that met my criteria. At the time, this was a hugely compute-intensive task and it made me one of their largest customers.

My strategy was programmed and all qualified trades were converted into key strokes that were transmitted to the First Options Server for automated order entry. With a computer-driven and managed strategy we could do, literally, thousands of trades in 500 stocks. However, executions were still not electronic, so while we were automated up to the point of order submission, once the order hit the floor, it was executed manually and the fills telephoned back.

What implications did that style of trading have?

Radez: We were doing thousands of orders per session, so there was no way we could have loads of limit orders floating around because real-time portfolio management would have been a total nightmare. As a result, all of our orders were for immediate execution, which earned me the nickname of 'Mr Immediate'.

What sort of option trades were you doing?

Radez: I got tagged pretty badly in 1978 when I was trading net short options (vertical spreads), so after that I always traded net long option spreads (back spreads). That meant that time decay was now a huge enemy. We were very diversified in terms of the number of names we traded and we were doing a lot of trades in this array of names, but average position size was small. For example, with at the money options we might only be trading 25 to 50 lots per name.

John Muelhausen (left) and Steve Radez

How long did that trading style last?

Radez: Until about 1992. You might have thought that things would have become easier as time progressed but, ironically, it actually became harder, since our automated trading volumes increased faster than the market's ability to handle them. Floor traders eventually could 'see' us coming and knew who we were. Initially, they filled most orders, but in time (since their markets were not automated in those days) they merely backed away from order flow that was to them obviously automated. Today, you merely need to be faster than the other guy, since all orders, whether providing or taking liquidity, are computer generated. As a result, with all the volume plus rule changes creating very small bid-ask spreads, profits per option are far smaller - so you merely make it up in volume.

So what happened after you moved out of automated options trading?

Radez: Next stop was automated equities trading. We were able to reuse the automation technology we used for options across about 500 stocks to trade on average between 1m and 1.5m shares per day. We were using a very simple trading model based upon imbalances between the bid/offer on the NBBO (National Best Bid and Offer). All trades were long trades (shorts were too difficult to get off 'immediate' because of the uptick rule) and fortunately we were in a bull market, so it was easy to make money.

Risk management was tight, typically using something like a two cent stop loss. Profit-taking was based on formula where if a stock fell back by more than a given percentage from its high since we opened the position then we would automatically take profits and exit. These retracement ratios would tighten as the trading session progressed and any open positions at the end of the day were automatically terminated with a market on close order. We finally quit the equity trading business just before the market turned down in 2000. We were still trading profitably, but it made sense to focus our resources on another business we had developed that showed superior returns.

Which was?

Radez: Married puts. As I mentioned, one of the problems we had with equity trading was being unable to short efficiently because of the uptick rule. One way around this was to buy a married put - buying the stock plus a put option simultaneously. With this position, a trader could trade from the short side all day without an uptick.

I wanted to take short positions in my own trading, but when we found a married put dealer, the cost in my opinion was way too high for a trader with my style to be profitable. That set us thinking that there must be plenty of other traders in the same position, so we decided to deal in married puts in 1997.

The CBOE floor

So how did John become involved in the business?

Radez: Initially he came on board to automate the option arbitrage side of the business. John was introduced to me by a partner in a large clearing firm as the absolute best programmer and developer his firm had ever worked with. He was right.

Muehlhausen: Well I started off with option arb business before Steve realised that it might be better to have me focus on automating the married puts. There were perhaps a dozen customers (mostly day trading firms) sending us orders for married puts on behalf of their clients and our pricing to them was far more aggressive than they could get elsewhere. A key part of this was using technology to cut the costs of processing the order flow and making it easier for customers to send orders. Making ourselves a FIX destination certainly made a difference in terms of easing client connectivity and achieving tighter integration with clients' bookkeeping and accounting functions.

We also did a lot of work in getting ourselves more tightly integrated with popular front-end systems. For example, if an executing broker's clients were using REDIPlus as an execution managment system, the broker would have a clean consolidated view of where they stood with us. The net result was that the technology we deployed allowed our clients to make married puts a profit centre. Where everybody else was charging them three cents per share, we were charging one, so they could charge their clients two and everybody was happy.

So the element of automation was an integral part of the businesses?

Muehlhausen: Absolutely; it also tied in well with another change that we made while in the married put business - self-clearing. The firm that cleared us was also clearing for a lot of our customers and since married puts were controversial at the time, they didn't want to clear both sides of the trade. They suggested we go to self-clearing and with the benefit of hindsight (we weren't that keen on the idea originally) it was a hugely valuable change. Though it took about two years to accomplish, it probably saved us around USD 1 m per year.

Part of the saving was due to the fact that we were using a third-party facilities management firm for our clearing and they still had a lot of manual processes. That increased costs for us both directly and indirectly. The manual processes increased the error count and we were wasting a lot of time sorting out these errors, when we could have been doing something more productive.

Was that the only factor in the clearing cost saving?

Muehlhausen: No. Another major contributor, which I don't think is widely appreciated, is that when you self-clear you only need to think about infrastructure specific to the way your own business runs. If you are clearing for others, you have to put technology in place that can cope with all the different requirements of your various customers. That makes a huge difference to your overall clearing costs.

Have you been able to re-use those cost savings as the trading side of the business has changed?

Muehlhausen: Very much so. The SEC ruled against married puts in 2003, but we were able to leverage the technology and self-clearing savings we were making as we moved into providing liquidity in the equity markets, which still represents some 70 per cent of our revenues. In addition, because the client base was very similar, we had many of the client connections we needed already in place. That saved us both setup costs and delay.

Radez: I think our attitude to technology has made a major difference to our success as a business. Throughout the whole evolution of Essex Radez we have been in trading businesses where margins per trade were small, so it was critical that costs per trade were equally small. Technology and trade automation have helped us to keep these to the minimum and continue to help us as our trading volumes grow.

You also have a data business - how did that come about?

Radez: In the same way as the married puts business - as a trader I kept hitting my head against something that bugged me. In the case of data it was both cost and latency - so yet again the thought occurred to us: 'Hey, if we're having this problem, perhaps a lot of other people are too.'

Muehlhausen: It looked to me that if we accessed our data direct from SIAC (Securities Industry Automation Corporation), we would save money and improve performance. The original idea was to lower our costs and increase our own efficiency. It then evolved from there into a full-blown commercial business. There is a corollary with self-clearing here in that we only had to implement the data and functionality that we actually needed for our own business. That has meant that we haven't had to make all the investments in ticker plants and so on that a conventional data vendor makes. And because our client base has very similar needs to ourselves, this situation hasn't changed.

So do you see direct access feeds as the only way to go?

Muehlhausen: I think that the colossal growth in data volumes we've seen in the past few years is putting severe strain on the conventional ticker plant model, just in terms of sheer processing. In addition, the way we're seeing automated and algorithmic trading becoming more the rule than the exception makes direct access to reduce latency the logical choice.

In general terms, our typical customer has fairly straightforward needs, in that they are looking for the least expensive and fastest direct feed from exchanges (without having to pull their own lines). They want to be able to combine that with tools that will allow them to access the data as simply as possible without requiring specialist expertise in house. They don't want to have the hassle of coming up with their own data parsers, so we provide them with all the necessary code libraries (our KMD Market Data API) so they don't have to.

Are your clients on the data side, mostly prop trading firms?

Radez: The data business has been going for a couple of years and I would say that until about a year ago that was the case, but since then we've seen a steady increase in the number who are hedge funds. Both groups have pretty broad requirements, so we provide all North American exchange feeds across stocks, options and futures.

What's your general technology philosophy - buy or build?

Muehlhausen: Build; we don't want the cost overhead and limitations of using software or middleware from third-party vendors, so for both the trading and data businesses we build everything ourselves and/or use open source.

What do you use as an operating system for your mission-critical servers?

Muehlhausen: Mostly Solaris at present (running on both Sun and Intel architectures), though we do use some other UNIX operating systems as well, such as Linux and FreeBSD. The key for us, particularly on the data side, is multicast performance and at present we think Solaris has the edge there. All our core machines in Equinix Chicago (our main data/collocation centre) and our new facility in New York run Solaris.

The majority of exchanges have moved to multicast (or are in the process of doing so), because it is a great way to disseminate data from one to many. For both our trading and data businesses we have to be able to take multicast packets and deliver them with complete reliability to the business logic in the trading application. Therefore our end processing nodes must be able to receive all the packets (otherwise you end up with gaps in your data), even if they subsequently discard most of them because they aren't needed for a particular trading application. We did a lot of testing of multicast performance by putting Solaris and Linux on similarly configured boxes and then checking packet loss rates. Solaris definitely had the edge, but as the Linux kernel is always being revised, that may change in the future. (We do of course support Solaris, Linux and Windows for client implementations.)

"Over time, profitable inefficiencies will disappear and you will have to move on to something else. You can't stand still and assume that tomorrow will be like today."

Apart from cost saving, how has technology changed the trading side of the business?

Radez: When we were using a bureau for the option arbitrage business, it took us 20 minutes to scan every option, so there were a lot of things that happened in the interim that we missed. You certainly couldn't call that event-driven trading! Now, it's completely the opposite, we make trading decisions between individual quotes coming in.

Finally, Steve do you have a general philosophy about trading?

Radez: Over time, profitable inefficiencies will disappear and you will have to move on to something else. You can't stand still and assume that tomorrow will be like today. For example, I just don't believe that it is possible any more to make money as we used to in conventional day trading - that's why we now prefer to be paid for providing liquidity in stocks rather than trying to call their direction. (The 'directional' element in our market-making models is only there to help with risk control.)

Over time, competition from other technology-efficient traders will doubtless erode the opportunities available in our current business space. But that is what this business (and all other businesses) are all about - responding to constant change. That is why we must continually spin our research models to find other unknown or little-known inefficiencies.