Hello Rudiger,

It's simple, but one approach would be to run a backtest without holding back any capital as cash. Then one could estimate the effective tax burden (over the entire backtest period), and re-run the backtest with the cash needed for taxes held back. This would provide an estimate of the impact of taxes on performance, since the backtester uses the initial amount of cash to compute the overall return. If less than 100% of the initial cash is allocated for trading, then the performance takes a hit (since the return on the cash is zilch).

For example, if I run a backtest with $50K capital, ~100% in the market, and the estimated taxes are $2.5K, then the backtest would be run again with $50K, but $2.5K would be held back as cash to pay Uncle Sam.

Generally, it would be nice to have a function to extract cash as taxes or a fee (e.g. pay_fee(dollar_amount)). Presently, I don't think there is any way to do this.

Grant

Thanks Grant. That's a really good idea.

But, I wonder if it would accurately model the real world situation. For instance, you can use some of that withheld tax capital to get some gains before April, when you have to pay the taxes for the last year. So, withholding that capital from the algorithm for the whole backtesting period might underestimate your potential returns.

But, that's just my gut reaction. I'd have to think about it a bit more to see if I fully agree with whether your approach could work.

Well, in the end, there is some amount of initial working capital that can be withheld as cash (i.e. kept out of the market) that will reduce the overall return so that it represents the effect of taxes over the period of the backtest. Perhaps others can provide a more sophisticated approach, but it seems this 'back-of-the-envelope' calculation will provide a lower bound on the return after taxes are estimated. My sense is that from backtesting, one wants a worst-case scenario anyway, so that in real-money trading, things can only improve.

Another, less convenient, option is to keep track of your tax burden in the algorithm with the context object and then on April 1 (or a similar date) you can automatically sell and withhold the cash amount permanently (keeping in mind that this sale will affect your next years tax burden). Then at the end of the backtesting period you can subtract the total tax burden you had.

I think Rudinger's answer is the only way to get things to work out close to correct. In addition, there needs to be a way to observe dividends, so that you can track the tax that would have to be paid on them as well. And, as a result of doing things this way, you can no longer use the convenience of order_target_percent, since it doesn't know about the cash you're trying to hold back. Instead, you have to make all trades for explicit amounts.

Alternatively, I think that if you continue to work with percents, you could write a post-processor on your transactions that recalculates what you would have earned if your capital was decreased by the amount of tax at each step. (That still requires knowledge of dividends somewhere, but maybe it could be in the post-processor, and your algo could still be "dumb" with respect to percentages - no need to track forbidden cash.)

I'd love to hear an easier way.