Fully automated futures trading

[globalarbtrader]

how about thresholding, is that still a viable concept ?

I'm still trying to experiment with my backtests, basically the improved PnL I see in the larger system where current risk is choked by the risk-overlay is most likely explained by the higher risk the system is taking. So it's not a real improvement, it's just extra profit from running the system hotter..

I guess the main appeal here was using margin capital more efficiently during "downtimes", i.e. during periods of weak across-the-board forecast lots of cash in the system is sitting around doing nothing, and if it was possible to "temporary" apply that capital to other instruments which are currently trending, i.e. simply try to make margin usage less variable without really improving the "true performance" of the system.. But looks like any such attempts result in cost increase which just makes things worse overall..

Thresholding, I've come to the conclusion it's quite a palaver for a very marginal gain and I'm going to be deleting in my 'version 2' system.

You're sort of right, except I'd say 'spare risk capital' rather than 'spare margin cash'. With the sort of vol target I run, you're unlikely to use all your margin up.

GAT

 

[globalarbtrader]

Great blog post. I could clearly follow the line of thought. Does this make me an incarnation of Auntie Barbara? (LOL)

In your blog post you use the criteria "strong forecast" as the selection criteria to select your "best friends". Have you tried to use the criteria "lowest value volatility per contract" as the selection criteria instead? And then in such a way that you scale the size of the party such that the "least best friend" can have an open position of at least 3 contracts (thus 2.5 unrounded)? I use the value 3 here as that provides sufficient granularity for an instrument to follow the changes in forecast value.

Yeah that sounds like a no-stupid thing to do, but frankly I'm just tired of the whole exercise and I'm really happy sticking with static selection, albeit in a more systematic way...

GAT

 

[d08]

.... and I get daily emails telling me what the system is doing (which I check every few days). So far the worst that has happened is a power cut or something going wrong, and the machine can't trade for a couple of weeks. I've backtested this, and the expected average performance penalty is small enough (a few bp of SR annually) that I'm relaxed about it. The machine could go haywire and trade millions of times, but I'm confident I have enough failsafes in for that not to happen.

Extreme case is I have to remotely log in to IB in webtrader which will automatically disconnect my home trading machine.

GAT

You've obviously considered this already and it's been talked about but alas, again, why not use a VPS?
I tried the solution you're using (although with an unstable connection) and it was a nightmare, although it worked most of the time. VPS has been a breeze though, I haven't had a single problem for over a year, although I'm sure it'll happen eventually.

My setup is: I have two accounts, one with a 2FA optout for trading (IbcAlpha to deal with drops) and a "full" account with banking that is used for discretionary trades when things go wrong and to monitor everything on top of the logs that the trading account already creates. The only downside is that both accounts require separate data subscriptions. Less my often terrible coding practices, it has worked exactly as expected.

 

[HobbyTrading]

Yeah that sounds like a no-stupid thing to do, but frankly I'm just tired of the whole exercise and I'm really happy sticking with static selection, albeit in a more systematic way...

In its essence that is what I do with my system: create a ranking based on the number of contracts an instrument can hold if the forecast were at its maximum value. And "adjust the size of the party" such that the instruments which can have a position size of 3 contracts or more "get invited". This "party size" is set manually. Every now and then I review this and adjust the party size, depending on the volatility of the instruments, and the available risk capital.

 

[Kernfusion]

FWIW here's the results of my experiments, take it with a HUGE grain of salt, because there could be bugs, missing\wrong data, anything.. Also, I'm running the whole backtest with the latest parameters that I'm using in real trading right now, as opposed to recalculating instrument and forecast weights as I go, optimizing them on the available data at the time(more correct). Also, as my weights are constant and many instruments only have recent data, a lot of risk-capital isn't allocated in the beginning..
Again, the general methodology here is to take the normal system with smaller number of instruments and a larger system with higher capital and larger number of instruments but apply the normal Markowitz-style risk overlay to the larger system such that it's realized risk (and therefore capital requirements) become the same as of the smaller system. This results in path-dependence, as when-ever the risk-capital is exhausted the new high-forecast instruments will be denied positions until some existing positions are exited.
I had to play with the "normal" risk overlay parameter quite a bit to make realized risk of the larger system to be as close as possible to the realized risk of the small\normal system to be able to compare apples to apples. The system's PnL takes trading costs into account, but I wouldn't vouch for it's accuracy : the backtests assumes fills on the worst side of the spread (the bid-ask spread for each instrument is loosely calculated as the average daily spread for this contract, might be incorrect in many places in my DB ) + 5$ commission per trade.

So what I can see apart from the 1.2 increase in P&L is that the realized risk of the larger system is more even, less jumpy, that makes sense(more instruments, better diversification), also there are fewer extremes.
The number of trades increased mildly, only by 1.14, so that doesn't look too bad.
Margin usage improved, i.e. it's slightly higher on average and also seems less jumpy on the larger system and less often goes to almost zero.

What is tempting from these results, but is most-likely wrong, is to assume that I can slightly increase the target risk of the larger system simply because I'm adding more instruments. I.e. I can almost trade a little more instruments for free because the greater diversification reduces my risk and makes it more nicely-behaved. But of course this measure of risk is not perfect, and increasing system risk simply because I trade more instruments is probably dangerous because of idiosyncratic and unseen risk (that's essentially we're capping IDM to 2.5 as I understand, because we don't want to believe in the better diversification completely)..

So I dunno, as I mentioned, don't consider these results very accurate, as maybe I'm just seeing what I want to see and my system and data, especially far back might not be accurate..

 

[Kernfusion]

FWIW here's the results of my experiments, take it with a HUGE grain of salt, because there could be bugs, missing\wrong data, anything.. Also, I'm running the whole backtest with the latest parameters that I'm using in real trading right now, as opposed to recalculating instrument and forecast weights as I go, optimizing them on the available data at the time(more correct). Also, as my weights are constant and many instruments only have recent data, a lot of risk-capital isn't allocated in the beginning..
Again, the general methodology here is to take the normal system with smaller number of instruments and a larger system with higher capital and larger number of instruments but apply the normal Markowitz-style risk overlay to the larger system such that it's realized risk (and therefore capital requirements) become the same as of the smaller system. This results in path-dependence, as when-ever the risk-capital is exhausted the new high-forecast instruments will be denied positions until some existing positions are exited.
I had to play with the "normal" risk overlay parameter quite a bit to make realized risk of the larger system to be as close as possible to the realized risk of the small\normal system to be able to compare apples to apples. The system's PnL takes trading costs into account, but I wouldn't vouch for it's accuracy : the backtests assumes fills on the worst side of the spread (the bid-ask spread for each instrument is loosely calculated as the average daily spread for this contract, might be incorrect in many places in my DB ) + 5$ commission per trade.

View attachment 262393

View attachment 262394

So what I can see apart from the 1.2 increase in P&L is that the realized risk of the larger system is more even, less jumpy, that makes sense(more instruments, better diversification), also there are fewer extremes.
The number of trades increased mildly, only by 1.14, so that doesn't look too bad.
Margin usage improved, i.e. it's slightly higher on average and also seems less jumpy on the larger system and less often goes to almost zero.

What is tempting from these results, but is most-likely wrong, is to assume that I can slightly increase the target risk of the larger system simply because I'm adding more instruments. I.e. I can almost trade a little more instruments for free because the greater diversification reduces my risk and makes it more nicely-behaved. But of course this measure of risk is not perfect, and increasing system risk simply because I trade more instruments is probably dangerous because of idiosyncratic and unseen risk (that's essentially we're capping IDM to 2.5 as I understand, because we don't want to believe in the better diversification completely)..

So I dunno, as I mentioned, don't consider these results very accurate, as maybe I'm just seeing what I want to see and my system and data, especially far back might not be accurate..

I decided to recheck my risk overlay code, and it looks like it's doing something "not exactly correct" i.e. it does reduce positions when the current expected risk goes above configured values, but not in the way I intended (not sure if it matters because one way or another the realized risk of the larger system was reduced).. But probably it's better to ignore these results..

 

[globalarbtrader]

You've obviously considered this already and it's been talked about but alas, again, why not use a VPS?
I tried the solution you're using (although with an unstable connection) and it was a nightmare, although it worked most of the time. VPS has been a breeze though, I haven't had a single problem for over a year, although I'm sure it'll happen eventually.

My setup is: I have two accounts, one with a 2FA optout for trading (IbcAlpha to deal with drops) and a "full" account with banking that is used for discretionary trades when things go wrong and to monitor everything on top of the logs that the trading account already creates. The only downside is that both accounts require separate data subscriptions. Less my often terrible coding practices, it has worked exactly as expected.

You'll take my physical servers out of my cold dead hands....

Seriously, I've considered this many times and ultimately with the speed and style of trading I have the likely losses from losing connections are minimal, even with a three week holiday. So ultimately it comes down to the fixed 'admin / time / hassle' costs of setting up some kind of cloud solution (the variable costs, I'm sure, are probably quite evenly matched now).

I probably will look at this again in ~3 years time, but as I've just bought new trading hardware earlier this year it makes sense to let them depreciate before considering switching over again.

GAT

 

[wopr]

Quick update for the mid year (data as of Friday). Time-weighted return for the year so far is 14.79%, currently in a ~11% drawdown. Overall, pretty happy, despite the recent drawdown. Early May things were looking pretty good

Positions:
ZS 202111: 1
GBM 202109: -3
N225M 202109: 1
GE 202409: 2
HO 202206: 1
MXP 202109: 5
SCI 202108: 3
SB 202203: 3
V2TX 202109: -10
ESTX50 202109: 2
CT 202203: 1
ZC 202112: 1
EUR 202109: -1
MES 202109: 10
ZF 202109: 3
OAT 202109: -2

Absolute MVP so far this year has been SCI (Iron on SGX exchange). OAT (French bonds) and NG (Gas) have been quite bad, mostly because of carry. My carry for NG has been max negative since early April until a few weeks ago, and NG has seen a big rally in that time. I have been working on seasonality rule and have it almost done, that could help with some of those moves going forward.

 

[Kernfusion]

Quick update for the mid year (data as of Friday). Time-weighted return for the year so far is 14.79%, currently in a ~11% drawdown. Overall, pretty happy, despite the recent drawdown. Early May things were looking pretty good

View attachment 262523

Positions:
ZS 202111: 1
GBM 202109: -3
N225M 202109: 1
GE 202409: 2
HO 202206: 1
MXP 202109: 5
SCI 202108: 3
SB 202203: 3
V2TX 202109: -10
ESTX50 202109: 2
CT 202203: 1
ZC 202112: 1
EUR 202109: -1
MES 202109: 10
ZF 202109: 3
OAT 202109: -2

Absolute MVP so far this year has been SCI (Iron on SGX exchange). OAT (French bonds) and NG (Gas) have been quite bad, mostly because of carry. My carry for NG has been max negative since early April until a few weeks ago, and NG has seen a big rally in that time. I have been working on seasonality rule and have it almost done, that could help with some of those moves going forward.

Somewhat the same here, I think I'm about 10% up from start, was ~+20% at some point.
here's my current positions, somewhat similar I guess:. Need to add that iron contract too..

 

[HobbyTrading]

Similar results here: everything was hunky-dory until a drop occurred in June. Nevertheless still up for the year.
I am currently adding multiple smaller-sized instruments to the portfolio and my system is in the process of replacing larger instruments with smaller instruments. This will take some time because I don't force larger contracts to be closed.
@wopr what are SB and CT?