Fully Automated Stocks Trading

I have a question about the first chart in your today's post: there is a red line with label "Slippage included". What does this line indicate? I think that you don't mention this in your post.

 

Same strategy but with slippage. Last screen has a formula for it commented. Small traders have advantage of getting almost no slippage for this strategy.

 

@ValeryN I've read the Bensdorp book (thanks for the recommendation!) and have one thing I didn't really understand, so wanted to see how you interpreted that.
He mentions 6 systems in there, that all share capital and are backtested together, so I assume they are traded on the same account. What do you do when one system says one thing and another says the other, eg. long trend following is long a stock, but then the short RSI thrust says to short it?
Do you do any separation of positions between subsystems?

Thanks!

 

Short answer - those are all valid situations and your backtesting tool should resolve it.

I don't think there is any "wrong" way to do it, you just need to define yourself exactly what you want to happen in those cases.

Couple of tips -

1. When trading multiple systems you certainly want to pick ones that don't trade same symbols at the same time or minimize that. Normally it's done by design. Let's say if you do MR long and MR short - they can't be extremely extended in both directions on the same timeframe on the same bar. Or low volatility / high volatility stocks etc.
2. Assuming you are using automatic your execution - if you're already in a stock - just keep it simple, skip a new signal if another or same system gives you new one. Otherwise you will ned to get into virtual position management and it will really increase chance of you introducing bugs.
3. If testing on EOD data and have two entries from different systems on same bar - you will not know for sure which one would enter first. Ones that trigger at the open are the only easy ones. If it's high / low - you can assume something like the side that passed your trigger by biggest distance is more likely to execute first. But by design (ref to #1) your goal to minimize those situations
4. For retail account - I'd say go with a single account for all systems. Just model it in your backtest the way you gonna trade it. Let's say if you size your positions on a previous day's account size - take into account that multiple systems traded it.

You can allocate a portion of your account to each system. I personally go aggressively and set it to 100% for each. But when I design a system I know how much average and max account use I want it to have. In this case your systems themselves better have 10-15% max DD in backtest.

Talking about tools my personal opinion is that AmiBroker is a way to go for most retail traders for advanced backtesting. There is not much you can't model there. I've been using it for years. But for last year I switched 100% to proprietary systems portfolio testing tool my friend developed, which is designed exactly for simulating multiple systems.

One more thing - if it start sounding very complex, focus on picking systems that don't have trades in the same symbol at the same time too often and study their overlayed drawdowns. Good modeling of all nuances does take some time to figure out but those two things are by far most important at the end of the day than a bit more accurate equity curve in your backtest. I started trading multiple systems before I was able to model combined performance accurately.

Val

 

Backtesting: use to be my own and AmiBroker, but since about a year ago it is RealTest (working name), which my trader friend has developed.

what kind of tests are you using? Just Backtesting? WalkForward?

 

There are two rather distinct approaches to this problem (speaking from institutional perspective).

One is to think in terms of alpha factors instead of strategies/systems - that means identifying whatever features/patterns give positive expectation to a particular stock and using them to formulate a portfolio. E.g. imagine that you have expectation of some form of seasonality and some expected mean reversion for a particular stock - if have expected signal strengths for both, you combine the two to get a target position.

Second approach is to net targets at the execution level and keep track of strategy positions separately. You can improve it by making each strategy produce "trade" and "cross" targets, i.e. weaker signal will only cross with other strategies instead of going to the exchange (thus minimizing transaction costs).

The former makes it easy to add new (even weak) sources of alphas and optimize execution at the portfolio level. The latter makes it easier to track performance of each source of alpha (as each alpha is treated a separate strategy).

PS. My personal preference is the latter, since it allows easier cross-product approaches and combining systematic and discretionary approaches.

 

I'd argue that WalkForward is a backtesting. And pretty much any quantitative testing is some sort of backtesting.
I think classification of ways of testing is not unified enough just to give you a list so it will make the same to you as for me. So I'll just give a few examples

1. Simple test over 5 years period, normally the ones before the recent ones
2. Then if equity/DD promising and number of trades is high - run same over a different market period
3. I have my own list what I believe represent different markets and I'll eventually go over all of them
4. Run some "simplified" versions, run some slightly different versions. I wanna see that "universe" of those alike strategies performs, not only the version initially seemed to be working
5. Removing most rules and looking at worst/best stocks picked up
6. Will try some sort of symmetrical opposite direction system. Doesn't have to work but if it does - it is a very good sign
7. Then I'll look at every single year manually to look at speed of max DD/recovery, correlation with general market
8. Lots of extra tests to see outcomes distributions under unusual circumstances like randomized entries, unable to take some trades, took more than expected etc.
9. Combined with my other strategies. Ideally I want have add new strategy that reduces cumulative DD, increases return = smoothens the curve and doesn't use too much extra capital
10. Run live and see if assumptions are holding and my live execution is trailing backtest

This is just a few high level things. I'd probably need to run at least few hundred different little tests to check all the things I'm looking for before trading live.

Execution automation component testing is very complex. In general, I try to simplify design so much that there is very little chance for a bug. There are auto-tests in place for most frequent end to end scenarios. I also assume that anything can fail at any time. And then troubleshoot in my sleep (I actually do). It is a never-ending cycle of improvement that involves lots of effort vs value kinda thinking.

Val

 

Bensdorp uses Trading Blox (or, at least, the reports he's showing on his books are equal to those produced by TB ).

if i remember well, in TB you have the option to consider 6 separate accounts and then sum up the equity line, or to use one single account for all systems. So - as far as Bendorp results are concerned - it really depends how he coded the whole thing.

With the filters he uses, I guess it's rare occurrence to be long system A and short system B, but in backtesting and for accounting purposes it's correct to treat these as 2 separate trades. Othewise you are not able to compute the real performance of each system.

In real time, of course, you are long 10 shares with system A and get a short signal for 10 shares by System B, you simply go flat at a portfolio level.

Amibroker is a very good piece of software, but IMHO its main limit is inability pro "easily" process multisystem multiportfolio systems.

In the member zone there's a suggestion for this purpose, made by me an awful time ago (more than 10 years ago) but TJ, a genius at programming but a bit stubborn, doesn't consider this a priority... (it can be coded ... god luck is a typical response in his forum.. in which the attitude with newcomers is a bit bully)

 

Right. I still have a license but try not to code systems in AB for this reason and not really looking for a day when I'd need to again... But it's really good in terms of - anything can be done there.

Maybe I'm a sloppy programmer but it also felt like it is very easy to make a mistake coding a strategy with AB. For that and multi-system portfolio modeling reasons I'm now using a software with a working name "RealTest" developed by my friend over last 20 years. Few screenshots with a strategy code I posted here were actual scripts from RealTest. Seeing my backtesting code shrink by a few pages after migrating there was a very joyful time.

Val

 

Thought I'll mention this as didn't see anyone using "Slack" for controlling their automation. Though, it is extremely powerful and efficient in terms of dev cost/value.

When I started working on my first execution software I had the following key requirements in mind:

1. Have something that runs as 24x7 as possible and is resilient to typical failures
2. Have good transparency on what's going / available literally on the go
3. Have ability to control it / fix it on the go

It took a while to find a right balance considering cost and development time.

Ended up implementing my own Slack bot which is very easy.
Biggest advantage was leveraging their mobile/desktop apps. Can send a message to my own channel in one line of code, another line to handle Slack initiated command.

I try not to look at it during a day but it has everything normally needed to get the full picture of what's going on / was happening historically.

1. Once every 30 mins it posts quick status report with all systems status, positions, orders, closest triggers, proximity to exit points, exact plan for scheduled actions etc.
2. It notifies about key actions like executions
3. Alerts on unusual stuff like very high margins or borrow rates for my some items on my watchlist
4. Once a day, after EOD data is available it runs backtesting software to generates model vs backtest comparison report and calculates any discrepancies
5. There are secondary notifications for critical stuff like broker or data feed is down / generated by separately hosted service. SMS + email. So I don't need to open Slack unless I really want to.

Overtime I came up with little tricks like completely removing indication of P&L in intraday reports. So if I do look at them there is less chance of emotional reaction.



In general I don't think that software component is very important in trading. So I didn't start this journal with this.

It also tends to be a rabbit hole. Whenever I think I need to work on software more I ask myself a question - how much money it's gonna potentially make or save. That really helps to stay focused.

Biggest return on time invested normally will be on strategy development or looking for ways to improve executions.

Val