400 karma · joined April 11, 2009
The "average investor" doesn't need L2, and doesn't care what it says, including flashing "fake" orders.
Yes, "flash crashes" exist, and normally because of liquidity disappearing. Yes, algos are basically sheep that all bail at the same time. But overall, the net effect is massively beneficial to everyone except lazy traders (which include fund managers who miss the days of getting lots of steak dinners from their favorite brokers).
The reason this gets prosecuted is that it's an easy target for the exchanges to make it look like they care. They are now publicly-traded companies interested in profits first and foremost--not market integrity (which maybe used to be the case--different discussion).
source: 25-year vet of futures markets, the last 10 in HFT; many many millions of orders and executions
The point is that when the difference is opinion (or close to), such as matters of color, font, position, etc., there is no reason to tweak things. If you're not going to make a big difference, don't make one at all.
But basically the hypergrowth of the '90s was borrowed from the future. All policy was good if GDP grew. Greenspan noodled on the problem--"irrational exuberance"--but unfortunately became convinced the existing pyramid scheme was working. He's since publicly expressed regret over a ton of those decisions.
+1.
The "making hundreds of millions" part made me laugh too. Bet that's news to the index desks.
I'm straight (and divorced), and we got married for many of the same reasons that LGBT folks want to--it makes sense. Visitation rights, inheritance, tax treatment, etc.
It's unlikely that marriage would be removed as something of concern to lawmakers--has that kind of thing ever happened anywhere, any time, any way?
I respect OP's opinion, but it's ivory tower and we're talking about real people right now.
possibly unnecessary edit: just want to reiterate that I think OP is _right_, it's just not practical, and I'll sacrifice rightness for a rather-large "quick and dirty win".
> 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 < ~ 50us) is there are so many sources of jitter the data is basically "mean of x, st dev of 6x^3". Too much noise to signal to make it worth it.
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.
edit: s/dude/guy-who-made-this
With respect to the idea that this guy is the culprit, that's literally laugh-out-loud funny. It's possible he was spoofing, etc., even with decent size. But the clearing firm (Hi, MF!) controls the throttles on those pipes. But there is what is called "sponsored direct access" in these markets, and that basically means the clearer wants your business enough you can just hook up directly so you can go really fast, and they (the clearer) will just pretend that they're looking at your stuff.
"We make tax law simple!"
"We make heart surgery simple!"
^^ similar silly things, only you don't ever see them
The thing is, no one actually DOES make anything simpler. They just restrict the toolset with which you can solve problems to things that work for the 80% cases.
1. You have a working product--do not do a full rewrite. Rewriting has so many pitfalls in the best of cases, and if it's just you, the context switches between the "old" (which you will still be spending most of your time maintaining) and the "new" systems will be brutal.
2. This is the prototypical "real world" case. You're basically asking how you can prioritize immediate enhancements vs. long-term flexibility and maintainability. But maintainability is a feature. Any (good) book on agile development methodologies will tell you that consistent refactoring and cleaning of the code has direct user benefit, in that future velocity (user enhancements) will be better.
3. The prudent way forward is to chip away at the problems. As you "touch" various parts of the system, start doing small refactoring work, adding comments, tests, etc. Remember, you're starting from nothing--anything you do in this regard is improving your situation.
4. If you're not doing some sort of iterative development methodology, start. Personally, I have a preference for Scrum, because of its time-boxed nature. It lends itself well to devoting a section of each dev cycle (sprint) to the kind of cleanup work you need to do.
Good luck!
What's inherently wrong with "brand tribalism" or "proof of discerning taste"?
I read this is a tribute to Apple, nothing more.
Engineering? Implementation of PM strategy.
Marketing? Communicating the PM message.
Sales? Delivering the product spec'd and built by PM.
Etc....
first track: http://www.youtube.com/watch?v=4kHEu50uq3w
(Although it's possible some delayed feeds may be available, etc.)
My reaction tends to be opposite yours: when someone gives me the "top 5", I consider it only a trailhead; it's unlikely my top 5 would be the same.
FPGAs canonical use case is still as very fast codecs. There are exceptions, but they're really only the very simplest of arbitrage strategies. And in order to make those work you need top-of-the-line network gear and engineers as well.