4 ms·

One of the prevailing theories from http://www.nanex.net/ http://www.nanex.net/ is that when Knight went live they also put their order simulator live as well.

One of the prevailing theories from http://www.nanex.net/ http://www.nanex.net/ is that when Knight went live they also put their order simulator live as well. The thinking behind this theory was that a simulator would keep adding liquidity to a fake market for testing a market making algo. During the day that Knight lost their pants nanex saw that while their algo was taking liquidity someone else was constantly providing it, ie the bid ask spread didn't really open up that much and the price held relatively flat. This meant that someone else was constantly adding liquidity that Knight was taking away. The thinking was that Knights market simulator was the one sending out the live orders to add liquidity. TL/DR Knight crossed themselves many many times in a few minutes. See http://www.nanex.net/aqck2/3525.html http://www.nanex.net/aqck2/3525.html for the acutal details

mcphilip 13y ago
As an example of why Nanex is worth listening to, here is an article [1] describing how Nanex claimed Monday's ISM manufacturing data was leaked 15 milliseconds early, leading ultimately to an admission by Reuters that it caused the leak. Eric Hunsander, a software developer at Nanex, went so far as to hint to Reuters that they should check their NTP settings since a drift of 15 milliseconds is allowed by default [2]. Eric is very interesting to follow on Twitter [3]. He highlights mysterious HFT related events on a daily basis. My only complaint is that his articles and charts, in particular, are very difficult to interpret. As an outsider to the HFT industry, I don't know where to find the resources to learn enough to interpret most of Eric's insights. [1] http://www.cnbc.com/id/100792260 http://www.cnbc.com/id/100792260 [2] http://www.nanex.net/aqck2/4306.html http://www.nanex.net/aqck2/4306.html [3] https://twitter.com/nanexllc https://twitter.com/nanexllc
- ansible 13y ago
  ... claimed Monday's ISM manufacturing data was leaked 15 milliseconds early ... While I'm peeved that as an adult I'm still not able to purchase an affordable flying car (though I was able to afford a tiny flying robot recently), there are days where I do think I am living in the science fictional future anticipated in my youth. Reading that CNBC article... this is one of those days.
- arielweisberg 13y ago
  What NTP configuration option is being referred to?
minimax 13y ago
Some tweaks to your explanation: The thinking behind this theory was that a simulator would keep adding liquidity to a fake market for testing a market making algo. If you're testing a market making algo (i.e. to participate in NYSE's RLP program), you're simulator needs to remove liquidity, not add it. The idea is that the simulator (the tester) accidentally got deployed, and then went around crossing the spread (removing liquidity) and building up large positions in various instruments. TL/DR Knight crossed themselves many many times in a few minutes. A self trade doesn't affect your profit. Any self-trades would have been problematic because it's illegal to paint the tape, but that's not what caused the losses.
- cma 13y ago
  NYSE's RLP program is for consumers; market makers my be providing liquidity for it, but certainly aren't taking (except if they handle customer orders as well). Market Makers by definition tend to provide liquidity; most are obligated to keep a bid and offer on each stock they make a market in available at all times, and they get a few benefits like not having to locate shorts.
  - minimax 13y ago
    My point was that if you are developing a program to do electronic market making (adding liquidity), then the program you write to test that program must by definition be taking liquidity (it shoots test orders at the quotes provided by your market making algo).
beachstartup 13y ago
applying occam's razor, i'm not sure which would be the simpler explanation: 1. a test suite got deployed accidentally, that happened to exactly match the buying predisposition of the production algorithms and fronted a bunch of their own trades @ a loss, or 2. someone got greedy and spilled the beans, and a competitor knew which algorithm would be unleashed on day X and buried it with their own

mcphilip 13y ago

As an example of why Nanex is worth listening to, here is an article [1] describing how Nanex claimed Monday's ISM manufacturing data was leaked 15 milliseconds early, leading ultimately to an admission by Reuters that it caused the leak. Eric Hunsander, a software developer at Nanex, went so far as to hint to Reuters that they should check their NTP settings since a drift of 15 milliseconds is allowed by default [2]. Eric is very interesting to follow on Twitter [3]. He highlights mysterious HFT related events on a daily basis. My only complaint is that his articles and charts, in particular, are very difficult to interpret. As an outsider to the HFT industry, I don't know where to find the resources to learn enough to interpret most of Eric's insights. [1] http://www.cnbc.com/id/100792260 http://www.cnbc.com/id/100792260 [2] http://www.nanex.net/aqck2/4306.html http://www.nanex.net/aqck2/4306.html [3] https://twitter.com/nanexllc https://twitter.com/nanexllc

ansible 13y ago
... claimed Monday's ISM manufacturing data was leaked 15 milliseconds early ... While I'm peeved that as an adult I'm still not able to purchase an affordable flying car (though I was able to afford a tiny flying robot recently), there are days where I do think I am living in the science fictional future anticipated in my youth. Reading that CNBC article... this is one of those days.
arielweisberg 13y ago
What NTP configuration option is being referred to?

minimax 13y ago

Some tweaks to your explanation: The thinking behind this theory was that a simulator would keep adding liquidity to a fake market for testing a market making algo. If you're testing a market making algo (i.e. to participate in NYSE's RLP program), you're simulator needs to remove liquidity, not add it. The idea is that the simulator (the tester) accidentally got deployed, and then went around crossing the spread (removing liquidity) and building up large positions in various instruments. TL/DR Knight crossed themselves many many times in a few minutes. A self trade doesn't affect your profit. Any self-trades would have been problematic because it's illegal to paint the tape, but that's not what caused the losses.

cma 13y ago
NYSE's RLP program is for consumers; market makers my be providing liquidity for it, but certainly aren't taking (except if they handle customer orders as well). Market Makers by definition tend to provide liquidity; most are obligated to keep a bid and offer on each stock they make a market in available at all times, and they get a few benefits like not having to locate shorts.
- minimax 13y ago
  My point was that if you are developing a program to do electronic market making (adding liquidity), then the program you write to test that program must by definition be taking liquidity (it shoots test orders at the quotes provided by your market making algo).

beachstartup 13y ago

applying occam's razor, i'm not sure which would be the simpler explanation: 1. a test suite got deployed accidentally, that happened to exactly match the buying predisposition of the production algorithms and fronted a bunch of their own trades @ a loss, or 2. someone got greedy and spilled the beans, and a competitor knew which algorithm would be unleashed on day X and buried it with their own