Fully automated futures trading

The government only insures cash, up to 85K.

So let's suppose I have 385K in cash, of which 200K is needed for margin. So I have 300K of cash which is unisured. I need to keep 115K of that for margin, but the other 185K I could use to buy say ETFs. This would mean that my counterparty risk is now with the ETF provider, rather than against IB. In the simplest possible example if I could buy a 0% return money market ETF that cost me 10bp a year in fees, then 10bp is the cost I'm paying to transfer my credit risk away from IB against the ETF provider. If the provider is Vanguard or Blackrock; well that's probably about as safe as I could get.

(I may also benefit from being able to claim another 85K in insurance against the ETF provider, but it's not clear if I could do that in practice)

GAT
Ahh, I see. My understanding is slightly different. I have been under the impression to use your example, that although your ETF will be segregated from IB's own assets it will nevertheless be pooled with other clients' assets. In the event of default, you would only receive a prorata share of these pooled assets. So if there wasn't enough money to pay everyone back, you would receive a haircut. In that sense, I had thought your counterparty would still be IB and not the ETF provider.

Now its entirely possible that setting up a separate non-margin account doesn't mitigate against the above risk, but my understanding from the answers from IB was that any securities bought would a) not be lent and therefore b) have higher level of segregation, but I wonder if b) is in fact also incorrect.
 
This is exactly what I am planning to do. Using account values as given by @globalarbtrader my current system would use a volatility target of 385k*25%. In order to move cash away to another account where I hold ETFs I would need to modify the risk percentage (25%) such that the cash volatility target remains the same. For example: if I change the percentage from 25% to 40% I would need to change the account value from 385k to (25/40)*385k = 240k. 385k*25% = 240k*40% = 96k. Thus move 145k to another account. The remaining 240k would still be sufficient for the margin requirements. I can use the 145k to invest in ETFs, and, if these ETFs have low volatility, the combined volatility would be similar to the current situation.

FWIW, if the accounts are linked you can use the NAVs from both accounts to determine the available capital without having to touch the vol target.
 
Ahh, I see. My understanding is slightly different. I have been under the impression to use your example, that although your ETF will be segregated from IB's own assets it will nevertheless be pooled with other clients' assets. In the event of default, you would only receive a prorata share of these pooled assets. So if there wasn't enough money to pay everyone back, you would receive a haircut. In that sense, I had thought your counterparty would still be IB and not the ETF provider.

Now its entirely possible that setting up a separate non-margin account doesn't mitigate against the above risk, but my understanding from the answers from IB was that any securities bought would a) not be lent and therefore b) have higher level of segregation, but I wonder if b) is in fact also incorrect.
Don't know if this website sheds any further light. On the one hand it talks about pooling of ETFs through nominee accounts but also about segregation of client assets. I guess I will have to start another Q&A thread with IB and plan to report back once I have further answers (hopefully this shouldn't take more than a month...)
 
FWIW, if the accounts are linked you can use the NAVs from both accounts to determine the available capital without having to touch the vol target.
You are correct. That would indeed be possible, but for reasons specific to my account setup cause a complication. Which is why I don't do it like you suggest.
 
Hi @globalarbtrader and everyone else,

Could I check if you have tested real effective exchange rate (REER) as a signal for forex instruments before? I'm intending to test the factor and wanted to understand your experience using it as a signal.

Thanks!
 
Hi @globalarbtrader and everyone else,

Could I check if you have tested real effective exchange rate (REER) as a signal for forex instruments before? I'm intending to test the factor and wanted to understand your experience using it as a signal.

Thanks!

Yes I tested it, albeit about 10 years ago

It pretty much collapses to a mean reversion towards a cointegrated equilibrium level of exchange rates; as the trade weightings change so slowly.

GAT
 
Just finished adding NIKKEI 225 mini futures from Osaka exchange (to the paper system for now). It's also available on the Singapore exchange but the volume is very small. It seems like a great contract for a small capital system: margin is only 2.6k, very liquid, IB data subscription is only ~2$\month, and also Quandl has a lot of historical data for it for free (https://www.quandl.com/data/OSE-Osaka-Securities-Exchange?keyword=NIKKEI 225 mini futures).
Next will probably try to add NIFTY and XINA50 from SGX..
 
Hi all, couple of posts back. I noticed that some of you are using MongoDB (via Arctic) to store your time series data. What's the disadvantage/ advantage over say Kdb+ (Q) which seems like a commonly used DB in the quant space? At the moment, I'm not well verse Kdb+ but plan to look into it.
 
Hi all, couple of posts back. I noticed that some of you are using MongoDB (via Arctic) to store your time series data. What's the disadvantage/ advantage over say Kdb+ (Q) which seems like a commonly used DB in the quant space? At the moment, I'm not well verse Kdb+ but plan to look into it.

Kdb+ is a more industrial strength solution which is used by a lot of HFT type people. It's licensing is complicated and it's generally more palaver to run than a simple mongoDB instance (which you can run with fancy distributed sharding and what not, but out of the box for simple instances). Kdb is also columnar not no-sql. I find mongoDB without the Arctic layer very handy for storing non time series information; basically I just store everything as a dict and write .as_dict() and .from_dict() methods for all my objects.

Basically for low frequency traders Kdb is overkill; in fact even Mongo is unneccessary given I ran the first iteration of my trading system for over five years on SQLite.

GAT
 
Back
Top