The Accidental HFT Firm

To many, high-frequency trading remains a mystery. According to Matt Hurd, it is simply the law of big numbers that lets an HFT make money every day. That same law dictates that if an HFT loses enough edge, it either ends up unable to trade, or it loses money every day. It’s a tough industry, plumbing the depths of market infrastructure and microstructure to improve its efficiency. In this article from the early days of HFT, Hurd offers a bit of his trading story, revealing some of the inner workings of the industry, and provides some advice for asset managers.

A bit of my trading story, with the names largely changed.

I started my HFT career at one of the larger American trading firms as a C++ jockey. On my first day, I was greeted by full panes of glass boasting glorious Sydney Harbour views which were modestly obscured by a hand-scrawled “< 2ms” on that glass. This was the main goal for the dozen of us in IT. That wasn’t my remit at the start, though. First things first …

Early daze

One of the desk guys had an idea for trading tailor-made combinations on the Australian Stock Exchange (ASX). That is, equity option spreads and combinations, along with their associated hedges. He needed something that could handle a bunch of intricate auto-trading rules that could be integrated with the Orc front end being used for ASX trading. It was the early 2000s, so I developed a quick resizing UI with VB6 for the Windows 2000 desktops. This involved C++, Boost, and multi-threading with a Spirit parser for the Orc integration at the back end. Orc calculated the binomial or trinomial trees for the ASX-listed American options on demand. For my binomial pricing code, I used simple Haug VBA code that I had transliterated to C++.

However, Orc didn’t calculate solely on demand; rather, it used simple memorization for pricing. If the parameters were the same, Orc remembered, rather than recalculated the price. Our Orc Trader had been too slow to beat Timber Hill’s custom platform or IMC’s exclusively licensed Orc Liquidator, the fastest vendor system at the time. The stack seemed too lame to be latency competitive, no matter what tricks I could come up with. However, with a large price cache from the busy C++ threads diligently filling out a multi-dimensional cache of option prices by parameter proximity for easy interpolation, suddenly we could hit trades that were previously unhittable.

By changing an interest rate, or selecting another volatility curve adjustment in Orc Trader, my pricing cache got busy replenishing itself. This wasn’t an entirely original solution. I first heard about the idea of pre-caching option prices in an old article about either Hull or CRT some years prior. Just as a modern out-of-order microprocessor can speculate on the next thing that’s going to be required, so can you. Market prices are discrete after all. Remember, the fastest calculation is always the one you don’t have to do. A later lesson was that it was hard, but not impossible, to beat zero latency. This strange corollary to this speculative lesson exists because the fastest message is the one you don’t have to send. This is perhaps even more significant.

In my view, the best architecture is no architecture. That is a little facetious, but an important system truth. Reification just becomes legacy without a sufficient lack of architecture. As premature optimization is the root of all good, it is best to not talk too loudly about computing myths, as it is best for your competitors to stumble.

The Orc Trader hackery I concocted wasn’t a great solution, but it made a few people happy getting some trades that were previously out of reach. Indeed, there was a bit of fist pumping and mirth when they first got some types of trades they’d never seen before. Overall, it was only mildly successful. It grew to hundreds of manual rules monitoring trading potentials and seemed to pay for itself when someone bothered to turn it on. It was a fun build for me at least.

Focus on ‘< 2 ms’

Let’s revisit that “< 2ms” challenge on the window. I wrote a paper espousing a faster, but more complicated way of getting much lower latency. A three-person team, myself included, was born to go and try. Korea was the first choice. No need for option pricing caches in this project, even at a secondary level, as the European index option calculations, especially the incremental or finite differenced ones, are not that much more expensive than a cache interpolation, even on limited dimensions.

This was a time in which 2-3 GHz processors were new. Our performance measurement approach was a bit lame. We measured performance internally within the application rather than properly from the external network. This was fine when talking about 2 millisecond timeframes, as the network stack was in the 50 to 100 microsecond zone in those days of yore. The key point to remember here is that when you can do more than a billion instructions a second, that translates to more than 2 million instructions for 2 milliseconds. Frankly, it was just criminally wrong that even a millisecond, over a million instructions, was burnt on simple trading tasks. If it takes you a million sequential steps to decide on a trade, retire now! A modern processor can do thousands of instructions in a microsecond. Every nanosecond is sacred.

As a relative newbie to a firm, you have to tread carefully when you get assigned to a non-functioning team. In the development phase, there were only three of us, including me. One team member, who was normally excellent, unfortunately rebelled by spending time focused on inter-webs, games, and forum posts about GPU cards. Mr. GPU had previously written the firm’s core libraries for multi-threading, which were quite good, but strewn with nomenclature errors. Mutexes were locks and locks were mutexes. I ended up choosing to use Boost’s C++ libraries just to stay sane. Mr. GPU didn’t seem to enjoy the project and kind of went on strike, it seemed. Part of it was no doubt being annoyed at having to work on my newbie idea. The other guy was less capable, but not incompetent. He would usually eat a lot of food and zone out to watch DVDs.

We had to get on with it. Two milliseconds to beat. As it turned out, I had more code than expected to write – hence a few late nights and stumbling over bumps in the night. Mr. GPU did end up doing some integration work on the edges, while Zoned-Out Guy did no work at all. The result was a system a bit faster than 5 microseconds. I thought that was a success. The speed did not take into account the network stack. Clearly, the network stack latency now mattered a lot more than it did a month earlier.

One of the other IT guys congratulated me and from him I learned that the majority of the IT team, including him, thought it had been an impossible task. Apparently, most were also hoping I’d fail. It appears change coming from the new guy was not widely appreciated and I only received a small bonus and no significant pay rise.

I had hoped to stay in this job for 20 years, especially after that dot-com bubble thing. Plainly it was time to move on for me.

Finding a new job

I chatted to a few firms and shared some new thoughts on how to do things. One private trading firm, one of the good Dutch firms, listened intently but nothing happened. Years later, I learned that a team started implementing some of what we had talked about in those interviews the very next week. I heard the approach was successful. They called it the “implied base method,” where everything is expressed in terms of a base future or instrument. I liked their name for my technique, although it all sounded a bit cargo-cultish to me. This is pretty much how a modern delta one desk thinks about life. I was flattered to be deceived.

I then spoke to a significant Australian institution that had a team of around a dozen developers focusing their holy dollar on the ASX market. Their technology was even slower than Orc Trader, most of the time, with significant milliseconds in their stack. I arranged a meeting with the business head, who was a lot more successful and much younger than me. He was one of their high-income earners whose income has to be declared under Australian listing rules. The politics of the business looked untidy and he warned me that earning money overseas wasn’t easily attributable back to your profit center. The discussions with this firm were a waste of everyone’s time – I don’t do black hat. Grey is fine. Finding gaps between the rules is a fun game as long as the ethics are acceptable. However, those black lines should not be crossed. There is no fun in winning by cheating but, more important, reputation matters. People always underestimate the NPV of a scandal, and I did not want to risk that.

One investment bank that I spoke to, I liked. It was a big Wall Street firm’s outpost. I had spent years in that kind of environment previously. The pass bar seemed pretty low. They didn’t want to make money. They just wanted to generate no-cost turnover so their corporate finance department could serenade firms. That was looking like the best option, and I was sure they wouldn’t mind getting their turnover and also making a profit. Profits rarely cause complaints.

A good thing about my prior firm is they did fire people for making money. Someone broke the rules by doing some pair trades they were unauthorized to do. They made money. I was impressed they were fired for breaking the rules. Such a correct stance is shamefully all too rare in financial services.

Then another opportunity popped up quite unexpectedly.

I had lunch with a guy I knew from my computer science course at the University of Tasmania, who now worked for ITG. He suggested I speak to ITG, as they did proprietary trading. That was news to me; I had thought they were just a broker. I met their Asia-Pacific CEO and he filled me in a little more on their dual-listed arb machine that was running on USD and CAD stocks. Then I met the US CEO, Ray Killian, when he was on a trip to Australia. The meeting went alright and there seemed to be a lack of resistance for doing more HFT-style trading at ITG. The Asia-Pacific CEO, plus their chairman, who was also a board member of the NYSE-listed ITG Inc., eventually took a makeshift business and risk plan to the US for a board meeting.

Then I don’t really know what happened next. I was told three quite different versions over the next few years. According to one version, the board approved it, but Killian knocked it back. According to another version, some board members did not approve the plan. Another version had it not going to the board at all. I’m later not sure which versions were false, perhaps all of them. It didn’t matter. The ITG guys decided they would bypass their employer and invest personally. It was not quite the new job I had planned, but if the business went well, I could earn about a quarter of the new company’s shares via options vesting over a few years. It felt like a win.

A new HFT firm is accidentally born

So, with a 1.5 million AUD investment, it was time to start working again, all by myself with a laptop in a serviced office. I built some servers, desktops, installed Suse 64-bit Linux, hired three programmers – and the funding runway clock started ticking. It turned out I’m not a very good Linux system administrator. Not many months later I tired of doing system-administration badly and got some part-time help. Our head-count was now four and a half. But 64-bit Linux, especially with AMD & Hypertransport, was not ready for prime time, so we dialed back to 32-bit and RedHat/CentOS. It was a wise call from Mr. Sysadmin and progress improved.

Four months in, things were looking prospective. We had tossed and turned on starting locally on the ASX or going to Korea. The Korean exchanges – KSE, KOSDAQ, and KOFFEX – were merging into the Korea Exchange (KRX). We decided on Korea even though the business and tech environment was more complex and riskier. At the time, the opportunity was larger, plus the math and the limited number of products promised a simpler code base.

A funny thing happened about then. When building a new system, you try to set some naming conventions to future proof yourself a little. I decided to use ISO codes, or part thereof, for the exchange names. However, due to the merger of the Korean exchanges, there was no ISO code for the Korea Exchange. I contacted the ISO group responsible, which turned out to be one guy with a spreadsheet somewhere in Europe. He decided XKOX would be the new code for the combined exchange. I gasped and wrote back suggesting this would have an unfortunate English phonetic symbolism. Perhaps the obvious KRX, or XKRX in their nomenclature, may be a better idea? There was a joint laugh over email and XKRX became the ISO code. I think I can claim I originated the ISO code for the KRX.

In those old times in Korea, traders, even HFT ones, didn’t get access to the exchange directly. You had to go through a broker gateway and use their broker-specific API to connect. There was no co-location. A great deal of the variation in performance, beyond a broker’s control, was simply due to the location and exchange-provided technology. Now, the KOFFEX was the futures and option trading bit. KOFFEX was based in Busan, a seaport town a little over 300km away from Seoul. The KOSPI 200 products were small in ticks but large in volume. They were the most popular derivative contracts in the world by around a factor of nearly 10 back then. Eurodollars at CME were number two and K200 options were number one in volume. This had proved a bit too much to handle for KOFFEX. They had the K200 market run, on their behalf, by KSE in Seoul. So everything we needed was in one location in Seoul, although the primary derivative platform was based in Busan.

Now, I was aware that the network stack was perhaps the most important latency aspect I could control in this implementation. I found a hardware device that could do a 3-microsecond translation from InfiniBand to Ethernet IP. It was a module that would plug into a TopSpin InfiniBand switch. Hypertransport (HTX), an alternative to PCI Express (PCIe), was a new thing in AMD land and it provided a lower latency way of doing InfiniBand comms. I bought some Pathscale HTX Infinipath cards, HTX mainboards in alpha (e.g., serial number 0x0000045!), boxes, plus assorted bits. I assembled up a motley crew of parts to be a gee-whiz, not dirt cheap, but extremely frugal, network stack. It felt good. I had my somewhat clumsy but world-competitive network stack. It would not be for some years that regular network cards could spank that set-up.

Choosing a broker

We were off to Seoul to find a broker and data center location. I went with one of the investors, Bubble, who would come on as a staff member later. At first, he would split his time between ITG and the HFT. He could get away with this abuse as both the CEO and Chairman for Asia-Pac, plus other ITG staff, were investors. Unfortunately, Bubble booked the hotel in Seoul. It turned out to be a “love motel” booked from a very picturesque artistic impression rather than a true picture. Seedy, unclean rooms with flaky air-conditioning unsuited to the humidity. A virus-infested Internet PC. Not a great start. A couple of brokers picked us up and expressed a bit of astonishment at the locale. Embarrassing but funny. It turned out to be a quite productive trip. We got a ground shaking, unbelievable deal.

A good deal

Muppetz Securities offered direct exchange access. The big firm I had left didn’t have direct access. In fact, I had priced getting an HP/Compaq/Tandem non-stop system in the old job, as it was one way of getting into a particular broker’s production network to be closer to the exchange. It was about 500,000 USD for a small dev box on a special HP application development program. Tempting, but not taken by the business at the end of the day. So, this offer of direct access, which was X.25 serial access, was groundbreaking to me. The broker’s deal was kind of expensive, but, as direct access was unheard of back then, I signed the contract after a few days.

At the time, I ran into Mr. Ree from RTS, who was in Seoul sorting out some business. We were helping each other in approaching brokers. We used RTS as a backup repository for our trades, so the shareholders would have some comfort that a third-party vendor system could price things independently. You may think the logical choice was Orc. I was familiar with Orc and it had kind of won the trader user interface game at that stage. However, RTS had a much nicer API and was around 10% of the monthly cost for what I needed.

Back in Sydney, I looked at all that expensive TopSpin InfiniBand gear. It was now useless to me. We were going X.25. An unexpected but pleasant turn of events. Then I received the message from Muppetz. The deal was off. The signed contract was worthless.

Quite sometime later I learned that Muppetz had gone to the big firm I’d left. X.25 was a limited and rare resource. Why give it up to some little wannabe HFT firm that had never traded, when you could go to their past employer and get a real trader to bite the hook? It was a smart move by Muppetz, albeit unethical.

This content is for TabbForum Membership members only.
Log In Register
TabbFORUM is an open community that provides a platform for capital markets professionals to share their ideas and thought leadership with their peers. The views and opinions expressed are solely those of the author(s). They do not necessarily reflect the opinions of TABB Group, its analysts, TabbFORUM and its editors, or their employees, affiliates and partners.


  • profile image

Add a Comment