Taxes

Questions and discussion of Trading Blox and other platforms for non Trading Blox customers. Trading Blox customers should use the Trading Blox Support forum.
Post Reply
TK
Roundtable Knight
Roundtable Knight
Posts: 167
Joined: Tue Apr 15, 2003 5:45 pm

Taxes

Post by TK » Wed Mar 31, 2004 9:10 am

I wonder why no trading system backtesting platform that I know of accounts for taxes. Compounded annual growth rates are calculated as if taxes did not exist. I think taxes are a very important factor to consider. Why do platform designers think otherwise?

drm7
Roundtable Fellow
Roundtable Fellow
Posts: 96
Joined: Sun Apr 20, 2003 9:02 pm
Location: Richmond, VA

Taxes

Post by drm7 » Wed Mar 31, 2004 10:13 am

I agree that tax considerations are often overlooked, and need to be strongly considered in any strategy.

The problem is that taxes are so different around the world. Even in one country such as the U.S., people have different tax rates depending on their income. Other people have their trading accounts in IRAs, which defers taxes until withdrawal. Some people, such as full-time traders, need to file quarterly, while other traders only need to file annually.

So many moving parts...

One kludgy solution would be to run your system in chunks, equal to your tax reporting period. After every period, deduct the amount of tax equal to your tax rate, then run the system for the next chunk.

Thanks for bringing this up!


-Doug

ksberg
Roundtable Knight
Roundtable Knight
Posts: 208
Joined: Fri Jan 23, 2004 1:39 am
Location: San Diego

Taxes

Post by ksberg » Wed Mar 31, 2004 10:20 am

I, for one, do include taxes in system calculation as an option.

I think some reasons developers do not include taxes is that they are complex, depend on the individual return, and are always changing. Some of the things a developer must consider are the type of transaction, the length of transaction, the type of tax and it's allocation (e.g. long term vs. short term capital gain), maximum loss deductions, carry forward period, minumum payments, and payment frequency. The developer must also account for known and/or planned changes in tax ruls (and they do change frequently!).

Even so, it's nice to have something to correct and project returns with some level of tax included.

Cheers,

Kevin

jankiraly
Roundtable Fellow
Roundtable Fellow
Posts: 52
Joined: Tue Feb 03, 2004 7:23 pm
Location: San Diego

Post by jankiraly » Wed Mar 31, 2004 11:24 am

There are some traders for whom the current set of software tools compute precisely the correct answer. Among them are US citizens who trade in an IRA account and who plan to quit trading before age 59.5.

Since trading software developers can't possibly solve all problems experienced by all people, they might as well optimize the software for one particular target group. IRA traders in the US are as good a choice as any.

TK
Roundtable Knight
Roundtable Knight
Posts: 167
Joined: Tue Apr 15, 2003 5:45 pm

Post by TK » Fri Apr 02, 2004 1:45 am

While accounting for all possible tax rates and schemes may be difficult, if not impossible, I think it would be very easy to implement a feature that would allow you to reduce your equity at the end of each year by a user-defined tax rate, be it 10%, 20%, 40% or whatever. So if you paid a 20% capital gains tax and made a 100% profit in the first year, your CAGR would show not 100% but 80%. Another useful feature that is missing from backtesting platforms is the ability to manually add to or withdraw part of your equity. This would bring trading simulations much closer to reality as there are few traders that during their trading life neither add additonal funds to their starting capital nor withdraw any funds (e.g. to pay taxes). Being able to code additions to or withdrawals from your equity would probably also make it possible to code your own tax paying scheme.

cyphrograph
Senior Member
Senior Member
Posts: 39
Joined: Thu Oct 16, 2003 11:38 am

Post by cyphrograph » Fri Apr 02, 2004 8:34 am

Good points, TK.
I'd also like to have a feature which calculates slippage based on
-position size
-position size in relation to volume
Constant slippage is not realistic.

ksberg
Roundtable Knight
Roundtable Knight
Posts: 208
Joined: Fri Jan 23, 2004 1:39 am
Location: San Diego

Post by ksberg » Fri Apr 02, 2004 1:16 pm

TK
While accounting for all possible tax rates and schemes may be difficult, if not impossible, I think it would be very easy to implement a feature that would allow you to reduce your equity at the end of each year by a user-defined tax rate, be it 10%, 20%, 40% or whatever. So if you paid a 20% capital gains tax and made a 100% profit in the first year, your CAGR would show not 100% but 80%.
That would be a good start. If you're trading futures, you need to consider year-end mark-to-market, carry-forward and carry-back. On a longer-term system you'll end up paying taxes on ghost profits (based on open trade equity), and may need to adjust this in the next year. It happens all the time.
Another useful feature that is missing from backtesting platforms is the ability to manually add to or withdraw part of your equity. This would bring trading simulations much closer to reality as there are few traders that during their trading life neither add additonal funds to their starting capital nor withdraw any funds (e.g. to pay taxes). Being able to code additions to or withdrawals from your equity would probably also make it possible to code your own tax paying scheme.
Yes, I find this extremely useful. I implement a "Funds Management" policy which addresses re-investments, additional capital contribution, and withdrawal logic. Then I can plug in an arbitrary funds mgmt policy and see its effects on a trading portfolio. Since this is just another trading system component, it can also be part of Monte Carlo simulations. I believe it is definitely worth modeling simulations as close to actual practice as possible.

cyphrograph
I'd also like to have a feature which calculates slippage based on
-position size
-position size in relation to volume
Constant slippage is not realistic.
For those who are rolling their own, why not implement a "Fill Function" that can account for size in relation to volume and volatility. Then plug and play to your particular liking. Works great. BTW: from what I read, VeriTrader does allow for volatility in slippage calculations.

Cheers,

Kevin

Post Reply