hft_throwaway

That assumes there is no bias to their signal returns over time, which is extremely unlikely. 90% of the moves that go their way could happen in the first second, for example.

Many HFTs hold positions for seconds or minutes, and predict prices out over similar time horizons, but they'll lose their best winners to competitors if they aren't fast and adept at executing.

I see no mention of the spread, costs or even ability to put on a short position, exchange lag variability (huge issue when simulating even on modern exchanges, let alone fly-by-night bitcoin markets). Additionally, it is very easy to find trend-following signals that "work" but break down when conditions change very quickly. That seems to make up most of the prediction, along with an order book imbalance signal that might be more stable.

I think a better approach would be looking at order book features and lags vs. other markets. The costs are high on BTC markets so it would be pretty tough to overcome those though. Anyone with experience to do this is probably doing it somewhere more lucrative. I think BTC markets only trade a few million USD a day.

I don't believe they were trading with themselves. They were accumulating stock in the opposite direction to hedge their imbalance-only order. However, the way they accumulated that stock was done in a way that would impact the price received on the closing order.

So imagine they sold 10000 shares imbalance-only in the auction at 3:50. They would then buy 2500 immediately, slowly pick up another 2500 in the next 9 minutes, then do the last 2500 in the last second. The initial trades would get them into their hedge at a low average price, and the last-second ones would push the price of the closing auction up, maximizing their return on their imbalance-only order.

If you read the case, it seems like this didn't always work if they had slippage on the close or they got so aggressive that they would "flip" the imbalance and not get filled on their closing order at all, instead being stuck with a bunch of shares from crappy prices. The people trading with them in the last two seconds could also keep replenishing their orders and prevent them from spiking the price. Sounds like a dangerous game of high-stakes chicken.

It is stuffy, but I wouldn't call it backward-thinking, unless mindless hedonism is what passes for forward-thinking these days. Raising children without marriage would be akin to starting a business without incorporation or contracts. Strong bonds, group loyalty, and long-term planning/character are what let man build something larger than himself.

The claim that market makers pass costs on to end users is only true if they have pricing power. In reality, on-exchange liquidity provision is basically the kind of perfect competition that only exists in economics textbooks. Market makers are selling a commodity product (you don't care or control who you trade stocks with) in a market where buyers are purely sensitive to price (tightest market always wins and is enforced by exchange matching rules).

So what actually ends up happening in a market with multiple competitive market makers? To make money, a market maker needs to trade a lot of volume. The only way to trade a lot of volume is to put up the most aggressive (worse for the market maker, better for end users) prices at any time. Market makers can only do this by charging a smaller spread than their competitors. They can only charge a smaller spread by either reducing their margins or getting smarter at deciding when to be in or out of the market, usually a combination of both. The end result is extremely tight markets that react to information very quickly (i.e. cheap to trade and very efficient).

Competition keeps markets honest. If you had one very fast guy, he would clean up, but when you have a dozen guys who are roughly equally fast, they all compete one another down to barely making profit above their cost of doing business. Only the most efficient can survive. If anything, we want more HFT by removing barriers to entry rather than creating a lot of regulations that would ironically help incumbents by killing off weaker competitors.

Cool idea!

Some questions/thoughts:

Do you provide any access to raw tick-by-tick event data or just bars?

How do you secure your users' scripts so they don't worry about you stealing their ideas or front-running them?

It might be useful to provide FX rates as a feed so users could come up with a synthetic price for non-USD pairs.

For guys who want to work passive orders, an API where they can pass a dictionary of prices/sizes they're willing to buy/sell at into a goal seeking algorithm that handles canceling/placing individual orders might be a better match and more convenient.

It likely was happening.

If I'm a market-maker, I want to trade with retail orders or slowly sliced institutional orders that are trying to rebalance a portfolio throughout the day. When I sell stock to them, the price doesn't move very much in the short-term and I have a chance to buy back on the bid to make a spread. I don't want to trade with aggressive arbitrage or stat-arb traders capturing short-term price inefficiencies, hedge funds that want to buy huge blocks of stock all at once, etc. If I sell stock to them, the price ends up moving up more than the spread very rapidly and I lose money.

When trading on a public market, I have no way to control which of these groups I trade with. I have to employ countermeasures to predict whether it's likely that I'll trade with an informed or uninformed trader and adjust my market accordingly. This is why you see market-makers rapidly flash their quotes for seemingly pointless reasons (e.g. I may adjust my prices in an airline when oil futures move) or flip out of positions aggressively when their model believes they were hit by an informed trader.

Now if I'm able to trade on a market where I know I'll only trade with long-term fundamental traders, I can quote much larger, tighter, and more stable markets. This is good for the institutions since their execution costs are lower than going to the exchanges. It's bad for arbitrage traders and hedge funds with short-term information since they effectively pay higher execution costs in a tiered market (if more "good" order flow goes to dark pools, less reaches displayed markets, and spreads on displayed markets will increase to compensate). When people want to end dark trading or internalization, they really want to have retail and institutional flow cross-subsidize fast speculators.

Ironically, it's probably HFT market-making firms who were the most impacted by Barclays giving other high-alpha HFT firms manual overrides to put them in a lower tier. If anyone would be excited at the promise of removing high-alpha traders from the pool, it would be market-makers who want to avoid being "picked off", not institutions who have a much longer time horizon.

But isn't that because C++ itself evolved from C? The original "C With Classes" wasn't much more than a convenient syntactic sugar for using structs and function pointers as a poor man's object system, something that was and is common in large, abstract C programs (e.g. Linux's VFS layer, Gtk+).

I think you may be confusing is with ought here. Everybody sane knows C++ has flaws; I think Meyers even feels this way in his presentation. C++ is popular because it evolved and thus contains a lot of compromises. To draw an analogy, the Mormon Church is immensely popular in the US for similar reason--they basically said, "Hey the New and Old Testaments you spent your formative years learning are all good, but we've got some swell new stuff here too!" I'm sure Zen Buddhism is more theologically pure, but people like what's familiar to them.

Programming languages are a network effect problem first and foremost. Just like it's hard to unseat Craigslist despite its crappy UI, it's difficult to get users for a new language that may be only marginally better in terms of features, productivity, safety or convenience. Even if it's a significant improvement existing code bases, library availability, programmer availability with domain knowledge and so on matter much more for serious projects. There's a reason why Facebook took the time to write a PHP VM instead of rewriting their code.

Guys who write HFT systems in Java are basically programming them like one would in C or C++. They pre-allocate byte buffers for everything and never run the GC. If you write C-style code in Java, it's going to run pretty quickly. They aren't doing architecture astronaut AbstractMetaClassFactory stuff or using much of the provided libraries for latency-sensitive code.

FWIW, I don't think Jane Street is a competitor in the "ultra HFT" space where every nanosecond counts. AFAIK they are more of a statistical and quantitative trading group, so they may have less need for things like talking directly to hardware, keeping tight control over memory layout, deterministic latency w/o GC pauses, etc.

Almost everything that is popular has evolved over time, and making these changes once you have established users results in compromises that can be sort of ugly. C++ has patina.