If you have no other option and no brokerage account, you could use this for small projects:
Update: Nice review of Genesis by Dan Horowitz in the comments:
I primarily work with the Genesis API (www.gndt.com) to do equity pairs trading. They only support US and Canadian markets (TSX) The API is fairly robust in that its the same API that their GUI uses and therefore has the capability to perform any operation a human trader might need to execute. That is also its downfall in that the API was designed to sit behind a GUI and expects and windows environment in which to operate. The API is written in C so you can easily write bindings to any application environment. I wrote my system in Java so I wrote a JNI bridge.
The biggest gripe I have with Genesis is that they dont really have a test platform so the only real way to test your system is with real money. Their idea of a test platform is some fake illiquid symbols that you cant really trade back and fourth because theres no one on the other end to take your orders.
Anyways, I would love to switch to lime but being a one man show means I cant afford their platform. Genesis is much more accommodating to start ups.
Here are my opinions on the API's I've worked with. I recently sent them to someone and thought they'd be worth sharing with anyone who wants the opinion of a programmer and trader who's used them for long enough to have a legitimate opinion.
IB has the worst customer support of the three. It's hard to get in touch with someone who knows what they're talking about since they have a call center. One problem with IB is that their Java/ActiveX API is only active when their high-overhead GUI is running in the background. But IB is nice because they have access to many markets, their commissions are good, and they provide up to a year of historical 1min bars. It's hard to extract historical data though because of barriers, like not being allowed to request data except every 10 seconds. These are extra hurdles to jump through, but I've written tools to make it usable for myself. Another annoyance are their internal symbols, which are inconsistent and poorly documented. For example a futures contract's symbol might be "MAR 09" while another is "JUN 09", where only the number of spaces is different. It's extremely frustrating to debug but eventually you get used to it and learn all the quirks. There are complaints about the documentation, but I haven't felt it's that bad.
WEX has the most features, including a chat client which I wasn't very interested in and news data feeds. They're very professional and have the best documentation of the three. Their API is .NET so it's flexible. I was going to translate WEX's .NET API into Matlab for a hedge fund but the project fell through so I haven't spent as much time trying to smooth out bugs introduced by it as with the other two.
Lime's Java API is the most barebones. They only have access to US markets and very few extra functions beyond order submission, portfolio details, and data subscription. However they do offer co-location. Their niche is that they're built for speed and they do a good job. Also their customer support is the best. Whenever I emailed them very technical questions they'd reply in detail typically within an hour. I liked working with their API the best because I never ran into any problems caused by them being careless with their implementation. The only problem with Lime is that the data feeds they have available are for book data rather than trades so it's nontrivial to construct an accurate midpoint price, which I find most practical.
I haven't used each of the three's FIX APIs.
If you have opinions/experiences, share them in the comments or via email and we can come up with a more comprehensive review of all brokers with APIs.
I translated Lime Brokerage's Java API to Matlab working for a startup hedge fund recently and I was allowed to keep the rights to the translation. If anyone else would like to program strategies directly in Matlab which execute via Lime, let me know - maxdama "@" berkeley.edu. Lime is known for their low commissions and extremely low latency. They are one of Interactive Brokers main competitors, targeting similar customers, but focusing on US markets. They have much better customer service too.
I've also checked out and demo'd Wolverine Execution Services' API so I can translate that one too if it's needed.
Of course I'm very familiar with Interactive Brokers' API.
If you want to design strategies around the strategy rather than being constrained by the broker and API language then translation should be valuable. If there's another broker's API you'd like translated to a more efficient language, let me know. I'm sure it will be similar to what I've seen before.
In general the languages I can translate to or from include:
Matlab, Python, Java, C++, and .NET (C#, Excel VBA, etc). FIX is fine too.
And again, generally speaking, coding takes around 3-4 weeks once discussion of specifications, terms, etc is resolved.
If you email me we can talk about what you need- maxdama "@" berkeley.edu
I wrote a note on how to combine multiple predictors with only marginally higher than baseline accuracy to construct an ensemble predictor that is much more accurate, via unanimous voting. It has a few simple formulas which don't work in html so here it is in pdf format.
I'm a bit worried because it looks much more mathematically complicated than it is (it's only simple fraction arithmetic and the most basic probability) and because it has no pictures. There is a table at least. It's written to be as intuitive as possible though, like everything else.
I'd like to hear if anyone's using techniques like this.
Everyone has to model slippage on their own based on historical execution data since it depends on account size, instruments traded, what time of each day you trade, etc so there's no good general model. Slippage is important because it can make alpha-generating strategies lose money. Modelling slippage is important because then you can optimize trade size and frequency to minimize transaction costs. We want everything to be measured as accurately as possible so optimization can be automated.
This note is naturally organized under the development of a few definitions.
Participation Rate: Percent of ADV.
If you transact 100,000 shares of GOOG in one day which trades an average of 3.3M shares per day, then your participation rate is 100,000/3,300,000 ~ 3.0\%.
Actually we can generalize percent of ADV to be over a time range other than a day. Participation rate is actually the percentage of volume your trading accounts for out of the average total volume that transacts in the stock over a given range of time. So if 500,000 shares of GOOG are traded every hour, and you buy in to a 100,000 position over the course of an hour, then your participation rate is 20\%. Higher participation rates increase slippage and vice-versa. 1\% could be considered a high participation rate (for GOOG this would be 3M*500*0.01=\$15M) although I'm just trying to give you a rough feel for how low a high participation can be.
Liquidity Impact: The money you lose when you're trying to buy and there aren't enough sellers so you have to bid more to access more supply of shares. The two key determinants here are SPREAD and DEPTH. Here's what they look like in terms of an order book.
Spread hits you with costs every time you trade, low depth eats into big orders. Higher participation rates generally cause higher liquidity. There are some simple but widely used strategies to decrease participation rate and reduce liquidity impact. Basically you spread your order out over time, and there are two simple patterns of spreading:
VWAP is better than TWAP. There are other execution strategies with creative names, like guerilla, sonar, etc which actually interact with the market during the day. Instead of trying to target liquidity based on historical average volumes, they ping the market to look for "icebergs" - large hidden orders, which the algo can extract liquidity from without any impact, until the iceberg is exhausted. These more sophisticated execution algorithms are generally classified as liquidity seeking, rather than passive.
In the news you'd hear that spreads are widening because of high volatility. We've covered how participation rate causes liquidity impact when the market depth is too shallow; now I'll explain briefly here how the market making business works to show why spreads widen and complete this part of the cost picture. A market maker is like a warehouse. That's their business model, warehousing inventory (sounds kind of boring huh?). Instead of selling to other traders, you sell to the market maker and then he sits around and waits for a buyer so you don't have to. He's worried that the price will go down before he finds another buyer so he charges you a spread. Now of course there are a bunch of market makers so just one can't set the spread, but competition drives them to more or less agree.
When volatility is high, the price has a tendency to move faster so the market makers charge higher spreads to hold the inventory until someone else comes. They are taking more of a risk. Market making is one of the most profitable trading strategies since some exchanges will actually give rebates (the opposite of commissions) for "liquidity providers", i.e. traders who use limit orders, like market makers do.
Now let's look at the other component of slippage,
Short Term Alpha Loss: You only attempt to trade into a position that is going to make money, so the longer you take to get in, the more of that profit has already been absorbed and you missed. Whereas we wanted to slow down execution to decrease liquidity impact, here we want to execute as fast as possible. This suggests an optimization problem. We'll return to that in a second.
Estimate short term alpha by asking the portfolio manager or trader where he expects the market to go over the next few hours after a buy/sell order is issued on average, or by statistically analysing a large sample of past executions and the path of prices before and after on average. Anytime we say statistical analysis we generally mean dealing with averages or frequencies instead of looking for trends or meaning in individual points.
Here we assume alpha is generated linearly from the time of the strategy issues a signal to the time when the alpha signal is totally exhausted. Like if you have a momentum strategy, it might signal at time T that supply and demand dynamics are indicating the market will rise over the next hour. After that hour the signal is exhausted. If it takes you 20 minutes to scale into the position while minimizing liquidity impact, then you only get to ride the momentum (alpha) from time T+20 to T+60, i.e. 40 minutes instead of 60 minutes. We assume that the alpha is generated linearly so the difference from T+20 to T+30 is the same as T+40 to T+50 etc. Finding alpha is hard enough, so in modelling the exact shape keep it simple.
Let's look at a diagram of how liquidity impact and alpha loss combine. Notice that going up in this chart means losing more money, and going right means looking at how the price impact evolves over time. Assume you start executing at the left side and as you execute more shares the liquidity impact increases until you're done and the price corrects itself. The longer you take, the more alpha loss you will suffer.
This is a very important diagram. It displays how you can estimate the liquidity impact even though it's confounded by the alpha loss. (We'll need estimates of these two components later) Basically we need to estimate alpha loss first and then liquidity impact second, after subtracting out the effect of alpha loss. For alpha loss, draw the line of best fit on the average of all the stocks that you got signals on but then didn't trade. This is like the dashed line in the picture. Then once you have this baseline, draw the line of best fit on all the stocks you did trade and subtract out the baseline. (similarly you could execute a lot of share with no signal to estimate the liquidity first, but it's cheaper the other way) Now you have each component.
This motivates another definition,
Execution Shortfall: liquidity impact + alpha loss.
Shortfall is the number we'll be trying to minimize by choosing a certain time to spread execution over.
Here's a diagram of where the minimizing point lies:
Notice that here the x-axis gives different choices of the time you might take to execute, whereas in the previous chart it showed what happened after you chose a certain time and then started to execute. These two curves were estimated in the previous step (but now we say alpha loss is kind of curved because we're looking over a longer time range). To find the minimum in Excel or Matlab, add up the two curves and choose the minimum of this sum-curve. For example with numbers along two curves x=(10,9,8,6,5,4,2,1,1) y=(1,2,3,4,5,6,7,8,9) to minimize x+y=(10+1,9+2,8+3,6+4,5+5,4+6,2+7,1+8,1+9) =(11,11,11,10,10,10,9,9,10) we could pick either the 3rd or 2nd to last, which correspond to, say, execution times of T=8 or T=9.
This is what you need to optimize duration of execution. It should be clear that these issues are more important for a large investor than a small one. Also this is a framework that can help to analyse your strategies execution, but of course it's not 1-size fits all. For example if you trade around very sudden events then the alpha profile might not be linear. And if you trade in micro caps then liquidity impact could be extremely hard (useless) to model.
One final thing to mention, this model is also useful to get a grasp on the capacity of a strategy. Capacity is the amount of money you can manage following a certain strategy before the transaction costs wipe out the alpha. Transaction costs rise when you're managing and moving more money. Look at how much transaction costs would have to rise to make there be no optimal execution time. In other words it's best never to trade. Based on your transaction cost model, see what this rise corresponds to in terms of number of shares traded and back out the portfolio value that would produce that many orders. There's your capacity. Here's that in a simple diagram:
Please leave comments or suggestions.
Subscribe to:
Posts (Atom)
