Hello,

Is there a way to perform a backtest taking end of year tax into account?

I am looking for a possibility to set a x% tax value which needs to be paid to the tax man by the end of a financial year.

Many thanks,
Konstantin

Some ideas:

1. Perhaps you could include an artificial losing trade on some symbol in your backtests, once a year.
2. Maybe this setting can help: Preferences > Backtest and Settings > Apply interest rates... > After enabling, type in a negative % for Return rate on "uninvested cash"
3. Withdrawal (monthly) PosSizer

Hi Eugene,

good ideas, but not exactly what I am looking for.

Tax must be paid on profit an not on the whole capital. Therefore idea 2 and 3 will not work correctly.

QUOTE:
1. Perhaps you could include an artificial losing trade on some symbol in your backtests, once a year.

As far as I know the strategy only generates alarms. After this step the PositionSizer/Performance Visualizer takes the alarms and calculates the performance of a backtest. How can I access the yearly profit from a strategy if it is calculated after the strategy has finished its job?

PS:
How do you include the fancy links? I can only paste a URL.

Wealth-Lab never considered to effect for withdrawals, deposits, and taxes in backtests. Maybe somebody else can suggest a more appropriate solution.

QUOTE:
Therefore idea 2 and 3 will not work correctly.

That's right, I completely missed it.

QUOTE:
How can I access the yearly profit from a strategy if it is calculated after the strategy has finished its job?

Short answer: you can't.

However, this unofficial solution might make it possible, without guarantees: WealthScript Techniques | Interacting Dynamically with Portfolio Level Equity. But before you ask any questions w.r.t. this workaround, please make sure to read all forum topics on this matter. Everything required to make it work has already been said there.

QUOTE:
How do you include the fancy links? I can only paste a URL.

Instead of pasting a URL inside a pair of LINK tags, modify the opening LINK tag like this: [link=, then goes your URL, and then close it as usual: [/link].

Hi Eugene,

many thanks.

Would a special designed PositionSizer, somithing like the Withdrawal PosSizer, which withdraws a % of the profit work? Would it be a clean solution?

QUOTE:
Would a special designed PositionSizer,

No, as this will still be a rough simulation because it's not possible to affect the portfolio equity directly this way.

Hmmm. That ir really not satisfying...

Is there any way to implement any sort of clean solution for a customer like me without creating an official feature request? I relly would like to avoid some dirty implementations.

If a "clean solution" existed, wouldn't I suggest it from the start?

You can file an "official" feature request which will most likely will end up being deferred. Firstly, there are numerous much more important requests pending (like WFO) or delayed (like multi-core CPU support for optimizations). Second, I doubt that "the bang for the buck" is there, and various scripted workarounds may be sufficient for this kind of ideas.

Although a PosSizer couldn't possibly work, I think you may have been thinking of a new Commission Structure - and I think this would work quite well. In basic form, when exiting a position it could extract a percentage of trading proceeds for taxes, however, there are many complicating tax consequences:

1. Washsale rules
2. Assuming trades are not wash sales, you can deduct losses from trading gains.
3. Short term / long term trades have different percentages (this could be fairly easily programmed, however)
4. If you're not subject to 1, 2, or 3 (i.e., Trader in Securities), you can deduct all of your losses and expenses of your trading business from proceeds. How could you model that?

And, depending on your tax home, all of this changes again.

I think if we assumed "Trader in Securities" rules (i.e., no wash sales and no long/short term tax difference) and ignored other trading business deductions (office, computers, etc.), there could be a way to model and execute a one-time (or quarterly) tax deduction on the first trade of the year/quarter.

edit... himm, this assumes that Position data are available in WealthLab.Commission and I don't think that they are. :(

QUOTE:
If a "clean solution" existed, wouldn't I suggest it from the start?

You replied so quick that I thought if you would think about it a little bit longer, you could have a new idea. ;)

@Cone:
Many thanks for your input!

QUOTE:
I think if we assumed "Trader in Securities" rules (i.e., no wash sales and no long/short term tax difference) and ignored other trading business deductions (office, computers, etc.), there could be a way to model and execute a one-time (or quarterly) tax deduction on the first trade of the year/quarter.

That sounds good, lets assume that! How would I do that?

Many thanks,
Konstantin

QUOTE:
That sounds good, lets assume that! How would I do that?

You probably have overlooked Cone's edit below:

QUOTE:
edit... himm, this assumes that Position data are available in WealthLab.Commission and I don't think that they are. :(

The Commission API is pretty rudimentary, limiting implemenation of many ideas. If you consider this route, see if these threads can offer some creative workarounds:

Commission: Day by day money cost in intraday strategy - read data from file
Commissions based on trade outcome - leverage the .Bars.Tag property

Thanks Eugene,

I will give it a try.

The problem with Bars.Tag is that it's symbol-dependent. I can think of a way to put a List<Position> for all symbols into a single Bars.Tag, but accessing it would still depend on entering or exiting a particular symbol. The advantage of storing references to actual Positions is that you should be able to access NetProfit of closed Positions directly from the Position object (after sizing in Port Sim mode).

That said, the only way I can think to make it work is:
1. Add a symbol called ZZZZ to your DataSet (needs to be the last one). Use a DataSeries with a constant price = 0.01. It should cost as little as possible to purchase a ZZZZ position so that it is never rejected - this probably requires using a PosSizer; probably the "Position Options" sizer would work by passing a % of Equity through the Position.Tag.

2. Use this sort of framework in your trading script. Rotation scripts need a different framework -

CODE:
Please log in to see this code.

3. When the Positions are sized and the Commission.Calculate() is later called, some 'normal' commission schedule is applied to all symbols except ZZZZ. For ZZZZ's Commission.Calculate() call, you cycle through all Positions closed in the previous quarter, deducting losses from gains (summing NetProfit) and return a commission charge for some percentage of profits.

I could take a shot at adding that part too to one of the existing Commission schedules. Actually, I'd like to create a new schedule that more accurately reflects commissions charged over time. It cost far more to trade 10 (or 20) years ago than it does now!

QUOTE:
Is there a way to perform a backtest taking end of year tax into account?

There's a new solution. With the advent of the new "Transfer fundamental provider" to MS123 Extra Fundamental providers, it becomes pretty easy to backtest the effect of deposits and/or withdrawals on the account. The Withdrawal PosSizer becomes legacy solution. A detailed walkthrough is available in the Wiki:

Backtesting deposits and withdrawals