$prem arb strategy
I received this email which I thought would be of interest to others:
This is a great concept and strategy and I have posted this email here because I have some research in this area and tried to create a profitable strategy out of it.
First off, I used the $EPREM symbol and not the $PREM symbol because it is more relevant. $EPREM shows the ES versus cash premium while $PREM shows the SP versus cash premium - I believe. If you're trading the ES then you need to look at the $EPREM.
The next thing that you have to consider is how often the cash index AND the $EPREM value, that you are receiving, are recalculated. Remember that the $EPREM value is CASH - FUTURE (or FUTURE - CASH, I can't remember which). So it is possible to have 2 delays: One for the re-calculation of the cash and one for the subsequent re-calculation of the $EPREM.
Does your data vendor route the values for the cash index and $EPREM to you from the exchange or does your data vendor add value and calculate these values at a higher frequency than the exchange does? When I was studying this I found that eSignal provided extra value by calculating certain values at a higher frequency than the exchange which meant that eSignal subscribers were receiving this type of data faster than subscribers to services that just routed the information from the exchange. I can't remember if they were doing this for cash and $EPREM though.
From the tests (some of them were live with real money) that I did I determined that it was very difficult (but not impossible) to trade this strategy profitably. The problems were:
1. Delays in the calculation of $EPREM. (By the time that I got the info the move was half over.)
2. Delay in my reaction to hit the buy/sell at market.
3. Delay in my trading platform to route the order to my broker and hence exchange. (I'm trading from South Africa with appallingly bad connectivity to the exchange.)
These problems can be resolved and I believe turn this type of strategy into a profitable one. This is how I would go about doing it.
1. Build a system that calculates the cash value of the S&P500 on my local machine. This would require having all 500 prices updating live on one of my computers and from that it would calculate the cash value and the $EPREM value in real time and there would be zero delay.
2. Automate the trading so that when the threshold value of $EPREM is hit the order is automatically and immediately sent to the broker/exchange without my intervention.
3. Have the system running with a super-fast and reliable DSL connection.
Questions, suggestions and corrections welcome...
quote:
you may have already come across this site, but if not:
http://www.indexarb.com/index.html
pretty interesting correlation between $PREM levels and ES activity.
there is data on $COMPQ premiums too, but so far can't find an esignal
symbol for it. if you haven't looked at $PREM or the site before, you
might want to put up a 1min chart of $PREM and ES. the lines for $PREM
for today were:
BA: 2.22
BT: 1.47
ST: -0.88
SA: -1.85
put up the charts side by side (or stacked or whatever) and scope the
activity on the ES on or around the $PREM levels.
This is a great concept and strategy and I have posted this email here because I have some research in this area and tried to create a profitable strategy out of it.
First off, I used the $EPREM symbol and not the $PREM symbol because it is more relevant. $EPREM shows the ES versus cash premium while $PREM shows the SP versus cash premium - I believe. If you're trading the ES then you need to look at the $EPREM.
The next thing that you have to consider is how often the cash index AND the $EPREM value, that you are receiving, are recalculated. Remember that the $EPREM value is CASH - FUTURE (or FUTURE - CASH, I can't remember which). So it is possible to have 2 delays: One for the re-calculation of the cash and one for the subsequent re-calculation of the $EPREM.
Does your data vendor route the values for the cash index and $EPREM to you from the exchange or does your data vendor add value and calculate these values at a higher frequency than the exchange does? When I was studying this I found that eSignal provided extra value by calculating certain values at a higher frequency than the exchange which meant that eSignal subscribers were receiving this type of data faster than subscribers to services that just routed the information from the exchange. I can't remember if they were doing this for cash and $EPREM though.
From the tests (some of them were live with real money) that I did I determined that it was very difficult (but not impossible) to trade this strategy profitably. The problems were:
1. Delays in the calculation of $EPREM. (By the time that I got the info the move was half over.)
2. Delay in my reaction to hit the buy/sell at market.
3. Delay in my trading platform to route the order to my broker and hence exchange. (I'm trading from South Africa with appallingly bad connectivity to the exchange.)
These problems can be resolved and I believe turn this type of strategy into a profitable one. This is how I would go about doing it.
1. Build a system that calculates the cash value of the S&P500 on my local machine. This would require having all 500 prices updating live on one of my computers and from that it would calculate the cash value and the $EPREM value in real time and there would be zero delay.
2. Automate the trading so that when the threshold value of $EPREM is hit the order is automatically and immediately sent to the broker/exchange without my intervention.
3. Have the system running with a super-fast and reliable DSL connection.
Questions, suggestions and corrections welcome...
quote:
Originally posted by guy
This is how I would go about doing it.
1. Build a system that calculates the cash value of the S&P500 on my local machine. This would require having all 500 prices updating live on one of my computers and from that it would calculate the cash value and the $EPREM value in real time and there would be zero delay.
2. Automate the trading so that when the threshold value of $EPREM is hit the order is automatically and immediately sent to the broker/exchange without my intervention.
3. Have the system running with a super-fast and reliable DSL connection.
Questions, suggestions and corrections welcome...
guy -
it sounds like you have a plan, so what's the hold up?
but seriously, other than dedicating the time to setup/configure the systems, what gives you pause? is your connection the main hinderance? i'd really like to pursue this further and would greatly appreciate your input/assistance.
personally, and this is based on only very recent comparisons, it looks to me like this strategy might be best suited for a scalping or pseudo-scalping strategy (maybe 1-3pts profit target). stop methodology might also be interesting - the spread can shift relatively swiftly, like it did on the 31st. it went something like this (using $PREM):
10:01 -240
10:06 220
10:08 -180
10:16 280
i agree that an automated entry/exit system would be best. i'm sure it's do-able as a discretionary method, but OOF! i think that would be a rough ride. especially if you were aiming for 100% execution. i don't think this approach leaves much room for flinching (or blinking or breathing or ... ).
i'd also like to see this for the NQ. would you dedicate a second machine for tracking the NAS100?
as for the $EPREM vs $PREM, i think you made a great point. in fact, in comparing the two, on a 1min chart you can see the lag. when the $eprem is breaking through a BT or BA line what you typically see is a big up bar followed by a big, lower down bar, while on the $prem you see a big up bar followed by a big, higher low bar.
interesting stuff. i'd love to see any additional info you might have on the idea ...
take care -
omni
Well the reasons that I haven't attempted to implement this are twofold:
1. From where I live I can't get a reliable connection to execute the strategy.
But the main reason:
2. It will take a many weeks (if not months) to write the code to implement all the parts to the system and some expensive and dedicated hardware to run it.
There are a lot of unkown variables when entering a project like this:
Can you get the components of the S&P500 from a feed vendor faster than the feed vendor can calculate and redistribute the index or eprem values?
Are the API's to the different components stable and bug free? For example you need to either write or use an API to a trading platform or directly to a broker to implement the execution of the strategy. And remember that this is not just fire and forget. You have to have it automated to the level that the machine will adjust the orders as the position matures and you need to enter and manage stops and targets. Do you hand the trading of the strategy over to a manual system after the initial entry? You also need to have an override facility.
There are a million things to consider when building an automated trading system. It's far from trivial. Unfortunately you find that 1% of your time goes into the development of your strategy and trading idea and the other 99% of your time goes into building the infrastructure around which to generate, execute and manage alerts.
My apologies for being negative on this post but the magnitude of doing something like this is huge.
This is also a very difficult strategy to back test as you need tick data to test this strategy and you can't use 1 minute bars. More so you need tick data for the 500 component stocks of the S&P 500 and the ES and you need to stream them into your back testing engine in the same order that they were generated in real time in the market. There are very few back testing systems that can do this. In fact I've never heard of one that can do this except the one that I wrote. Although this system allows streaming tick data for testing it hasn't be designed to handle a stream as large as 500 stocks and would have to be modified to do this.
Another thing about back testing this sort of strategy (if you want to make the back test realistic) is that you need to look at the size on the bid and ask at the time you would have fired the order to execute, then calculate a time latency for the order to reach the exchange and enter the order execution queue, and then look back at the bid/ask size and see where you would have been filled. For example, if you fire a sell order while there are 500 contracts bid, and one second later the ticker reads that the inside bid is 2 ticks lower at say 25 contracts then it is highly likely that you would have probably been filled at 3 ticks below your execution price.
Just a few of the things that you need to think about...
1. From where I live I can't get a reliable connection to execute the strategy.
But the main reason:
2. It will take a many weeks (if not months) to write the code to implement all the parts to the system and some expensive and dedicated hardware to run it.
There are a lot of unkown variables when entering a project like this:
Can you get the components of the S&P500 from a feed vendor faster than the feed vendor can calculate and redistribute the index or eprem values?
Are the API's to the different components stable and bug free? For example you need to either write or use an API to a trading platform or directly to a broker to implement the execution of the strategy. And remember that this is not just fire and forget. You have to have it automated to the level that the machine will adjust the orders as the position matures and you need to enter and manage stops and targets. Do you hand the trading of the strategy over to a manual system after the initial entry? You also need to have an override facility.
There are a million things to consider when building an automated trading system. It's far from trivial. Unfortunately you find that 1% of your time goes into the development of your strategy and trading idea and the other 99% of your time goes into building the infrastructure around which to generate, execute and manage alerts.
My apologies for being negative on this post but the magnitude of doing something like this is huge.
This is also a very difficult strategy to back test as you need tick data to test this strategy and you can't use 1 minute bars. More so you need tick data for the 500 component stocks of the S&P 500 and the ES and you need to stream them into your back testing engine in the same order that they were generated in real time in the market. There are very few back testing systems that can do this. In fact I've never heard of one that can do this except the one that I wrote. Although this system allows streaming tick data for testing it hasn't be designed to handle a stream as large as 500 stocks and would have to be modified to do this.
Another thing about back testing this sort of strategy (if you want to make the back test realistic) is that you need to look at the size on the bid and ask at the time you would have fired the order to execute, then calculate a time latency for the order to reach the exchange and enter the order execution queue, and then look back at the bid/ask size and see where you would have been filled. For example, if you fire a sell order while there are 500 contracts bid, and one second later the ticker reads that the inside bid is 2 ticks lower at say 25 contracts then it is highly likely that you would have probably been filled at 3 ticks below your execution price.
Just a few of the things that you need to think about...
quote:
Well the reasons that I haven't attempted to implement this are twofold:
1. From where I live I can't get a reliable connection to execute the strategy.
But the main reason:
2. It will take a many weeks (if not months) to write the code to implement all the parts to the system and some expensive and dedicated hardware to run it.
fair enough.
quote:
There are a lot of unkown variables when entering a project like this:
Can you get the components of the S&P500 from a feed vendor faster than the feed vendor can calculate and redistribute the index or eprem values?
Are the API's to the different components stable and bug free? For example you need to either write or use an API to a trading platform or directly to a broker to implement the execution of the strategy. And remember that this is not just fire and forget. You have to have it automated to the level that the machine will adjust the orders as the position matures and you need to enter and manage stops and targets. Do you hand the trading of the strategy over to a manual system after the initial entry? You also need to have an override facility.
uh, I’m guessing you are asking the hypothetical ‘you’, not the actual me . here’s my current relationship with trading sys dev:
|--- sys dev ---|<---------------<too many light years to type>--------->|--- me ---|
quote:
There are a million things to consider when building an automated trading system. It's far from trivial. Unfortunately you find that 1% of your time goes into the development of your strategy and trading idea and the other 99% of your time goes into building the infrastructure around which to generate, execute and manage alerts.
I, literally, can only imagine what goes into such an endeavor. Quite honestly, I do prefer manually trading. Don’t get me wrong, I think it would be great if I already had programming background/experience that I could apply to trading and thoroughly enjoyed creating the infrastructure necessary for the operation, but such is not the case i guess that means i hope that you develop a system for this strategy and at least send me a postcard from the island you buy with your profits
quote:
My apologies for being negative on this post but the magnitude of doing something like this is huge.
No, not at all … I appreciate your insight and realism. I have no desire to be (remain???) part of the 95% who chase the pipe dream of trading. I’m in this to win this, which means realistically evaluating ideas. You have helped me this time and many other times. That’s a good thing … Thx
quote:
This is also a very difficult strategy to back test as you need tick data to test this strategy and you can't use 1 minute bars. More so you need tick data for the 500 component stocks of the S&P 500 and the ES and you need to stream them into your back testing engine in the same order that they were generated in real time in the market. There are very few back testing systems that can do this. In fact I've never heard of one that can do this except the one that I wrote. Although this system allows streaming tick data for testing it hasn't be designed to handle a stream as large as 500 stocks and would have to be modified to do this.
I agree and began comparing tick charts after your initial reply. When you looked into this idea before did you conclude that the lag in signals was due to using $EPREM instead of actually computing the true, real-time value or was connectivity/reliability a possible influence? Just from eyeballing (please be kind to the non-coding neophyte ) the tick charts over the last few sessions, it looks like as soon as a given threshold was pierced, a market order would have got you into the trade. However, as I wrote before, I would want to trade this strategy with tight stops and tight, time-stops. If it doesn’t work within a couple minutes, get out. You might lose a tick on entry with the market order, but that wouldn’t be too terrible. As you pointed out, delay or hesitation can easily negate these moves (some producing a quick 1.5pts or more in less than 2min, followed by a 1.75pt reversal), so at least the market order would put you in it. Since you are much more experienced with backtesting, I’d appreciate any insight you’d be willing to share regarding the entry/stop/exit strategies you investigated for this type of approach.
quote:
Another thing about back testing this sort of strategy (if you want to make the back test realistic) is that you need to look at the size on the bid and ask at the time you would have fired the order to execute, then calculate a time latency for the order to reach the exchange and enter the order execution queue, and then look back at the bid/ask size and see where you would have been filled. For example, if you fire a sell order while there are 500 contracts bid, and one second later the ticker reads that the inside bid is 2 ticks lower at say 25 contracts then it is highly likely that you would have probably been filled at 3 ticks below your execution price.
I completely agree. Again just from eyeballing, it looks like price typically hovers for a few seconds (gulp! Did he just say ‘seconds’? [:O]) before making any type of directional response.
quote:
Just a few of the things that you need to think about...
Definitely. I sincerely appreciate your time and suggestions. I hope we can continue to discuss this idea, but completely understand if you feel it is a wheel-spinning, rainbow-chasing endeavor. If so, just tell me:
quote:
So go to Yahoo and get it and stop bothering me.
quote:
Originally posted by omni72
I agree and began comparing tick charts after your initial reply. When you looked into this idea before did you conclude that the lag in signals was due to using $EPREM instead of actually computing the true, real-time value or was connectivity/reliability a possible influence? Just from eyeballing (please be kind to the non-coding neophyte ) the tick charts over the last few sessions, it looks like as soon as a given threshold was pierced, a market order would have got you into the trade.
To tell the truth I can't remember exactly but if I were to guess it was the slowness of the trading platform (read DSL connection) that prevented me from getting into the position.
I remember using an alarm on eSignal to alert me when the $eprem crossed the signal threshold and then I would try and execute the appropriate trade. I found that the time between the alarm sounding and my order hitting the market lost me those few vital ticks.
I suggest that we both try and paper trade this strategy on one or more of the days going forward from today. One of the important concepts to note is that in the 3 months that the contract trades the threshold cutoff for long/short trades will change each day as the price of the future and cash come together - which happens as the future reaches expiration. So each day (in reality each week) you need to make a slight adjustment to the signal levels.
quote:
However, as I wrote before, I would want to trade this strategy with tight stops and tight, time-stops. If it doesn’t work within a couple minutes, get out. You might lose a tick on entry with the market order, but that wouldn’t be too terrible.
That's very sensible.
quote:
As you pointed out, delay or hesitation can easily negate these moves (some producing a quick 1.5pts or more in less than 2min, followed by a 1.75pt reversal), so at least the market order would put you in it. Since you are much more experienced with backtesting, I’d appreciate any insight you’d be willing to share regarding the entry/stop/exit strategies you investigated for this type of approach.
Well the seed of any strategy that you want to back test comes from observing market behavior and playing with the charts and trying out some simulated trades. This helps develop ideas for filters and allows the strategy to mature in your mind and for you to jot down ideas about it. Some strategies are impossible to back test and so the only way to get an idea about them is observation and your own sim trades.
quote:
I completely agree. Again just from eyeballing, it looks like price typically hovers for a few seconds (gulp! Did he just say ‘seconds’? [:O]) before making any type of directional response.
Yes, I remember that being the case.
You're very welcome. The questions are always helpful in trying to pick up ideas for filters or ways to enhance a strategy.
Guy
Quick Update: I've just been watching $EPREM on eSignal and I had an idea. If your charting platform allows this you can calculate $EPREM yourself without taking it from the exchange or feed vendor. On eSignal you enter ES #F - $SPX and this will give you a faster updated version of $EPREM. (You can also use ES Z5 etc. instead of ES #F.) This is still subject to the speed at which $SPX is updated. Can't remember if eSignal calculate this themselves or route it from an exchange.
guy -
very interesting. i did not know that was an option. it follows then that NQ #F - $NDX will calculate the NQ premium and YM #F - $INDU for the Dow premium.
couple of quick questions ...
1. should ES #F - $SPX match up with $EPREM? it looks like the values don't always coordinate with each other (i.e. the 13:53 EST 1min bar on the 6th was a BA signal on the $EPREM but barely a BT signal on the ES #F - $SPX chart; similar thing happened on the 13:00 1min bar on the 6th).
2. i wasn't able to generate tick charts for the ES #F - $SPX; should i be able to?
3. looking at esignal's symbol guide, the refer to cash symbols (i.e. IN X0 for SP, etc.) but couldn't get them to work on my charts. are these different than the main index symbols?
i'll continue to check it out ...
thx so much for the heads up :)
take care -
omni
very interesting. i did not know that was an option. it follows then that NQ #F - $NDX will calculate the NQ premium and YM #F - $INDU for the Dow premium.
couple of quick questions ...
1. should ES #F - $SPX match up with $EPREM? it looks like the values don't always coordinate with each other (i.e. the 13:53 EST 1min bar on the 6th was a BA signal on the $EPREM but barely a BT signal on the ES #F - $SPX chart; similar thing happened on the 13:00 1min bar on the 6th).
2. i wasn't able to generate tick charts for the ES #F - $SPX; should i be able to?
3. looking at esignal's symbol guide, the refer to cash symbols (i.e. IN X0 for SP, etc.) but couldn't get them to work on my charts. are these different than the main index symbols?
i'll continue to check it out ...
thx so much for the heads up :)
take care -
omni
quote:
Originally posted by omni72
1. should ES #F - $SPX match up with $EPREM? it looks like the values don't always coordinate with each other (i.e. the 13:53 EST 1min bar on the 6th was a BA signal on the $EPREM but barely a BT signal on the ES #F - $SPX chart; similar thing happened on the 13:00 1min bar on the 6th).
What I noticed was that as the $eprem value changed they lined up (which makes sense) but in the following 6 seconds until you get a new $eprem value the ES #F - $SPX changes quickly and is pressumably more accurate. If the $SPX updated more frequently then it would be even more accurate.
w.r.t. the 13:53 and 13:00 bar - I don't know how it looks at the historical values of the difference between 2 symbols. I find that some values can only be observed in real time on eSignal and that you can't reproduce them with historical data.
quote:
2. i wasn't able to generate tick charts for the ES #F - $SPX; should i be able to?
I know that there are some things that you can only do with time based charts - this may be one of them. Also, think about what makes up a tick chart: It moves onto a new bar every X ticks. So for 233 ticks in the ES how do you extract the same values in the $SPX for comparison? There are ways of doing it but probably not available in eSignal yet. Remember that what you are creating is a synthetic symbol.
quote:
3. looking at esignal's symbol guide, the refer to cash symbols (i.e. IN X0 for SP, etc.) but couldn't get them to work on my charts. are these different than the main index symbols?
I've never heard of IN X0... What is it?
quote:
What I noticed was that as the $eprem value changed they lined up (which makes sense) but in the following 6 seconds until you get a new $eprem value the ES #F - $SPX changes quickly and is pressumably more accurate. If the $SPX updated more frequently then it would be even more accurate.
yeah, I think we are noticing the same behaviors.
quote:
w.r.t. the 13:53 and 13:00 bar - I don't know how it looks at the historical values of the difference between 2 symbols. I find that some values can only be observed in real time on eSignal and that you can't reproduce them with historical data.
oof! That’s not cool doesn’t that kind of impair the automation potential? For example, on that 13:53 bar there was almost an entire point that didn’t print on the user defined chart that did show up on the $EPREM chart. Even if it was being manually monitored, would the missing point of activity actually be seen? Do you think it would be of any use to use $EPREM as a secondary/fallback signal?
quote:
I know that there are some things that you can only do with time based charts - this may be one of them. Also, think about what makes up a tick chart: It moves onto a new bar every X ticks. So for 233 ticks in the ES how do you extract the same values in the $SPX for comparison? There are ways of doing it but probably not available in eSignal yet. Remember that what you are creating is a synthetic symbol.
good point. Well, I guess esignal better hop on it so that we can keep looking into this, huh?
quote:
I've never heard of IN X0... What is it?
from http://www.esignalcentral.com/support/symbol/cmes.asp
Nasdaq 100
ND
H,M,U,Z
(Cash=IQ X0)
Russell 2000*
RL
H,M,U,Z
(Cash=IU X0)
S&P 500
SP
H,M,U,Z
(Cash=IN X0)
Feeds for these symbols may come in a different data package because when I try to use them I get ‘No Ent’ for status on the floating cursor window. You may have it already available for yours though.
thx again for all of your input and your time.
Take care –
omni
I also get not entitled for most of the cash symbols. Strange that the S&P500 cash symbol isn't $SPX though...?
Here is something that I didn't know before that somebody has just emailed me:
quote:
eSignal does a good job too, especially with the
E-mini PREM. Their ticker symbol for PREM is PREM A0
(zero not O) and the E-mini PREM is EPREM A0. Most
traders that have eSignal do not know that. If they
look at the PREM at all, they look at $PREM. That
symbol is not correct. It is a snapshot every 6
seconds and therefore is usually wrong. The same is
true for $EPREM. It is almost never correct, since the
ES contract is so active. eSignal does not have the
Nasdaq or Russell PREM.
Emini Day Trading /
Daily Notes /
Forecast /
Economic Events /
Search /
Terms and Conditions /
Disclaimer /
Books /
Online Books /
Site Map /
Contact /
Privacy Policy /
Links /
About /
Day Trading Forum /
Investment Calculators /
Pivot Point Calculator /
Market Profile Generator /
Fibonacci Calculator /
Mailing List /
Advertise Here /
Articles /
Financial Terms /
Brokers /
Software /
Holidays /
Stock Split Calendar /
Mortgage Calculator /
Donate
Copyright © 2004-2023, MyPivots. All rights reserved.
Copyright © 2004-2023, MyPivots. All rights reserved.