Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
I believe I know the author of that article as he's in Cambridge now.
To be honest - I don't have an exact number, although I can give you an educated response. Before this, I have to explain that this is a definition of scope problem: there's no universal definition for "HFT" and their paper makes this clear. Moreover, their definition of "liquidity taker/maker" (posting standing limit orders) is conventional but backdated. I also want to clarify this for the other readers that this means "57% of the executed trades" (because the number of added orders will always dwarf the number of executions - currently by about 30x in equities).
The percentage will always be about even as any systematic advantage between the two types of orders will be arbitraged away.
First, the effects:
1. The most probable effect I can see is that this takes away time precedence, which would deter liquidity providers, and lead to several adverse effects - more alternative venues that would bypass the rule, which would mean even more redundant HFT (cross-venue trading between EBS and these alternative venues) and greater fragmentation of the markets. This has always been the case even before electronic trading: one of the advantages of being a NYSE specialist was the speed of access. If you imposed the same restrictions on NYSE specialists while taking away this advantage (made them work from home with telegraphs), I doubt anybody would sign up.
2. Another highly probable consequence: Not to mention EBS already has a restriction on the lifetime of your standing orders and aggregated data slices, both of which deter high-frequency activity. You can see this as simply introducing a modified form of pro-rata matching. In this case, it wouldn't really matter, as there are pro-rata markets that are dominated by HFT and it's easy to model the "randomness" in the matching within the batch. It could introduce an algorithmic complexity, but the same technology will still be in place.
3. All speed-limit introductions miss the point: The majority of our competitive advantage does not come from the time it takes to interact with a particular direct feed.
It seems that nothing good can come out of this. Is it something that will become more commonplace? I'll address the arguments:
1. Typically, software vendors or data providers make the argument that low latency is a negative externality because it encourages a high scratch rate, which results in many redundant messages which ends up being a public tax. That's silly: Bandwidth has always increased quadratically with respect to speed.
2. A mix of people argue that speed poses a systemic risk that makes it difficult for people to step in. No, we saw CME's volatility interruption fix the problem very well. And definitely, we've seen a crash of much lesser magnitude in 1987 yet several markets took years to recover from that. The systemic risk argument is ironic because we can view systemic risks as the few initial conditions whose deterministic and dynamical effects the markets are particularly sensitive to. Then regulators and exchanges have to be the biggest systemic risk (Reg NMS - terrible consequences. Sub-penny decimalization - blew up KCG and resulted in the merger between two of the largest competitors in HFT space... very nice).
3. "It will make the world a fairer place." Let's take the example of the EBS again. It already charges $60,000 per month to increase your feed granularity by 150 ms - right, like introducing a delay will help retail or long-term investors. I'm not sure how it will make things any fairer for any party besides ICAP...
4. "It's only 1/13th of human reaction time..." This sounds like a superfluous argument to me. We could impose a regulated delay on internet search engine results to 1/13th of a human reaction time so Bing can keep up, or processor threads to 1/13th of a human reaction time so Intel and AMD are on equal footing. I believe Japanese automakers had a gentlemen's agreement not to develop engines that produced any more than a particular HP limit...
Actually, at one of the firms I worked at, we mostly developed strategies which only worked once, though these had longer execution horizons. I won't be able to discuss strategy implementation - I apologize about that.
Yes. But not on a macro level; it is difficult to reverse-engineer their strategies although it hasn't stopped people from trying.
That's market and strategy-dependent. Restrictions are usually about 1:25 on a product-by-product basis. On the Eurex, we will see significant changes in late 2013 because of new German legislation against high-frequency trading.
There's not enough information on that chart for me to make a judgment, and I wouldn't want to make premature statements that might spur you in the wrong direction.
How do institutions decide how they will be entering and exiting the market? Are market orders really considered "aggressive"? How is the decision made on entry and exit order type?
Aggression:
Yes, execution algos usually give you a few parameters to tune, and aggressiveness (sometimes called "immediacy" or "urgency") really just steps up on the market orders in one way or another. If you're doing long-duration trades or enough size to require slicing, it's usually better to leave it to the off-the-shelf algos*, so the decision is already made for you.
*Note: There are factors to take into account even if you are carrying out large trades, such as the transparency of the algo vs the kind of backward/forward analysis you wish to carry out, what kind of interfacing you'll like to do with third party components and how dependent you wish to be on a particular platform or provider. If your edge is a fraction of transaction cost, then obviously you have no choice but to build your own tools.
Entry vs exit:
The execution algos that I know of are all blind to entry or exit - it's symmetric. Of course, this just means entry/exit behavior is implicit in the other parameters** that the algo takes into account, which will be strategy-dependent.
**Besides the obvious ones, the parameters that the algos are not blind to are such as whether to search for resting liquidity in the internal crossing network, desired display size, offset to a particular reference price etc.
How is the decision made on entry and exit order type:
In other words, the strategy developer has to ask himself if each leg of his strategy demands immediacy or not and run tests to verify the cost-benefit. Broadly speaking, most retail strategies demand immediacy - they are therefore more destabilizing to the markets than high-frequency trading, actually.
Of course, this has been an unsatisfactory answer because I'm just telling you "they leave it to the computer" or "you need to backtest". As for how execution algos decide under the hood between market and limit orders once you've specified all the parameters, I'll try to simplify things.
I have to start by saying that I've seen Nanex flame a self-proclaimed Barclays algo developer on Zerohedge, saying that the algos are too simple to require a whole development team.
Nanex is incorrect here.
Because even at the most basic level, assuming the market is in a steady-state, there are 4 things that the algo needs to do - and you can classify each of these as either "cost" or "benefit" (which are really dual, since the objective function is eventually in price units so you can just flip the sign and just treat it as cost - easy to understand - we can say we're minimizing transaction cost). I mentioned in a previous post by saying that we assume no opportunity cost from information, so that removes 1 of them. More elaborately, the other 3 are easy if you assume that the constraints define a convex set. Then it becomes easy and you're guaranteed a closed-form solution with a global minimum. One person can do this.
The problem is when you have nonlinearity in any of your constraints, you're not guaranteed a closed-form solution, and then you'll need someone who did his PhD in operations or applied math to communicate with someone who did his degree in computer science. These algos usually have 10 constraints on top of these 3-4 that I mentioned, and of course, the market is not in a steady-state. You also don't expect just these two guys to be responsible for rolling the feature into production. You need to push this into a test and staging server, you need market data, you need sales to understand what's going on in even more straightforward language than my grossly-simplified version above.
As for how execution algos decide under the hood between market and limit orders once you've specified all the parameters, I'll try to simplify things.