A high-frequency trading model using Interactive Brokers API in Python

The one key part this seems to be missing is a backtesting framework. Did you look at https://www.quantopian.com/?

Great stuff.

I think the author would have been better suited without mentioning HFT, maybe algo trading model?, as its a lighting rod for controversy.

If anything I thin this is useful to illustrate just how hard it is to write a full blown trading system.

So maybe we could look at what you could add to this to make it something you could use in production(Note, please don't use this in production).

1) Risk system, before you write any algos, before you learn how to ingest market data, before you write anything else, you write the risk system.

in a true trading system because you always have orders flying between you and the exchange you never really know what your positions is. The Risk system allows you to deal with this uncertainty by giving each algo rules as to how many shares its allowed to be offside.

If you only ever take away one thing let it be this:

Trading Rule #1 Sooner or later your algo/code will make a mistake, it's your risk system that determines if you have a job tomorrow or not.

2) The system has no rate limiter, what do you do when the quotes come in too fast for you to deal with?

3) Locking the world, the system retrieves a quote and locks up the entire system while the quote is acted on. Essentially the very design of the system means you can only ever run one strategy for one set of tickers at a time.

If you wanted to tackle this start by looking at this data structure/library:

https://lmax-exchange.github.io/disruptor/

4) Back testing, no HFT trade idea's go into production without backtracking, Every HFT firm is different but I think they'd all adhere to this rule.

5) Closing positions, every algo gets offside at some point. How do you notify a trader to close out a position? How does the trader close the position and notify the algo?

6) Multiple algos over multiple symbols.

7) Real time PnL. Your PnL is everything, it means you get paid, it means you can do this again tomorrow. it is the single most important piece of information(Risk metrics are a close second) that you can track. This is probably my only quibble with the demo.

As the great Jules Winnfield (http://en.wikipedia.org/wiki/Pulp_Fiction) once said, "Well, allow me to retort."

> I think the author would have been better suited without mentioning HFT, maybe algo trading model?, as its a lighting rod for controversy.

Don't be so quick... in a world where keeping score is simple and the odds are tilted for many, any publicity is good publicity.

> 4) Back testing, no HFT trade idea's go into production without backtesting, Every HFT firm is different but I think they'd all adhere to this rule.

I'm sure the majority do. But I really didn't. The problem with backtesting low latency (by which I mean switch-to-switch roundtrips of So I would run something "in sim" for a while on live market data but simulated execution. I never looked for profitability--I looked for predictability. If you know the knobs on your system, you can make it work in any market. If you don't know the knobs, you have no business trading it. After a run of a week or so with no major problems I'd go into production. BUT:

> before you write anything else, you write hte risk system.

Oh Dear Lord yes. Not counting life-supporting, military, etc. tech, these are some of the sharpest tools you can imagine. Knight lost $440mm in less than an hour. And they were decidedly not of average expertise. That failure was a much bigger deal than most realize. Luckily smart people noticed and a lot of risk stuff changed after that (imo that was when people finally started to say "fast enough, I need to generate smarter orders").

> 2) The system has no rate limiter, what do you do when the quotes come in too fast for you to deal with?

I've been out of the guts for ~2 years, but by universal unforgiving law, the volume of quotes has got to be ridiculous now. People talk about "low latency" when they're talking about serving static HTML at 1000/s. So few people have actually seen the nuts and bolts of feed handlers--it's not their fault, this isn't widely available stuff--but the traffic spikes are mind-boggling. Good adapters combined with a tuned network stack will translate signal into "book" data, meaning usable basically, in ~ 5us. Meaning they do that 200 times per MILLIsecond. And it's not enough sometimes. And you and your rival firms are spending a lot trying to make that number 4us. Blah blah blah, I kinda miss it.

Also, I recommend checking out the QuantStart project started by Michael Halls-moore. Really handy if you are using the Oanda Api. Plus, there exists some great articles on the quantstart site about the creation of the code. https://github.com/mhallsmoore/qsforex

Python can be a good tool to prototype hft algos but not for trading (probably you want to trade under < 1ms).