Portfolio Risk Consistency The basic risk measure, R, should be consistent across system strategies. While certain conditions may justify the increase or decrease of risk of a given position, the basic amount (1R) should be consistent. _______________________ The standard risk unit. The idea here is that I can update the Risk unit from a single function, and all my strategies will re-calibrate and adjust their positions sizes as necessary. Adjust the entire portfolio to be more conservative or aggressive on the fly - handy, that.
Empirical Optimization Optimization should be used only to answer well-formed empirical questions. In the absence of a specific question to answer, variables should not be optimized. In particular, strategies should not rely on fitting variable inputs in order to be viable. __________ This is the last tenet, for now at least. Here we're saying that systems aren't made by optimization - there should be logic behind each system. Variables can be optimized, but only in response to a logical question. For example, one might optimize to determine which type of moving average best suits a certain stock. Any thoughts? Next we'll delve into User Stories.
OK, well it doesn't appear anyone wants to discuss the tenets, so I'll assume their perfect in every day. Next phase is to decide what we want, based on different roles. There are several roles involved with designing, running, and investing in an automated trading system. While as a practical matter I am fill multiple roles, there is the potential that I won't fill all of them. In particular I probably will not be the operator. Roles include: * Strategy designer/programmer * Researcher/Tester * Operator * Investor Each of these roles will approach the system differently, and have their own priorities and requirements, which are collectively called User Stories. Can you think of any roles I may have neglected? Any questions about how I imagine these virtual stakeholders, or why they are of value?
Following up on the focus on stakeholders (real or virtual), the point here is to use logic and interests as the main drivers for the system - not a single trading idea. We're constructing the playing field and creating the ground rules. This is all a form of discipline, of due diligence. A benefit of all this governance is that when the trading starts, these items will be safely out of mind, allowing greater focus on the actual market and performance. Creating this framework is more work than most individuals could perform, in terms of programming. The tenets are probably more than a group could agree upon. The intention is to realize an advantage by applying my programming expertise to trading, where I have experience but not expertise. I was recently reading Outliers, and the 10,000 hour rule is applicable here. As a programmer I have expertise (easily more than 10,000 hours experience). As a trader I may have a thousand hours. It only makes sense to focus as much as possible on my expertise, and to marginalize my areas of inexperience, one area being trading psychology. Automation is one way to minimize the impact of trading psychology. A tangible advantage is that programming your own strategies allows for a much faster development cycle - what would take a month of emails and updates with a contract programmer, I can accomplish in an hour or two. If I have bad trading strategies, there is no way to make money aside from pure luck. But even good strategies, implemented poorly, can be unprofitable (if not ruinous). So my goal is to build a framework that provides good strategies a high probability of success. Once the framework is operational I can spend months and years developing trading (strategy) expertise, and hopefully in 8-12 years I'll be an expert (and financially independent). Next we'll dig into actual user stories. Implementing those stories is when we share code. Damien
User Stories for the Researcher/Tester: As a researcher/tester I can: * Test a strategy over any past period using system functions (Start and End dates). * Test using a non-production version of code (built-in development/test environment support). * Perform Monte Carlo analysis on any strategy/security combination. ________________ The first point deals with easily being able to test over any period without doing all the annoying TradeStation date math. I'll have some system functions that take a normal date format and limit the trading period as defined. This allows for fast backtest results and general research convenience. The second point is a directive to build in environmental support. This is actually not too tough if you think about it. Basically, if you have a function A, you make the first parameter the environment (D=Dev, P=Prod). Function A checks the environment and calls A_d (development) or A_p (production). When testing, you set your environment to D, and you can update the A_d function all you want without affecting your live positions or worrying about version control. Once the code is tested, you copy A_d to A_p and recompile. Handy. The third point may be hard to implement, but it won't be a Release 1 deliverable so it won't hold us back. The idea here is to somewhat automate Monte Carlo testing. Those of you familiar with TradeStation probably know that you can compute your maximum loss and gain over a backtest period. However, that is based on real results. If you have 100 trades, what you would like to do is take those 100 and re-order them a couple hundred times and see what the max loss and gains are over that data set. This will give a much better idea of the limits you can expect. Also, say your period has 80 trades of less than 1% variation, 18 trades of 2% variation, and 2 of 5% variation. When testing, not every run will have this exact distribution. Rather, each individual trade has a 80%/18%/2% probability. Some runs will have 0 trades of 5%, some will have 5 or more. Based on the characteristics of the system being tested this could have a big impact on the expected variance and performance of a system. So these three stories look pretty simple, but they imply a lot of capability, all of which has absolutely nothing to do with a particular trading strategy. Anything I missed?
User Stories for the role of Investor: As an Investor I can: 1. View my portfolio balance and uninvested cash at any time. 2. View my performance by: * Time period * Strategy * Security 3. View my total market exposure. ___________________________ I think it's important to take a step back and try to view my system as would an objective investor, or as I would if I were investing my money with someone else. The balance and percent invested are pretty straightforward. This is something one might track on a daily basis. Performance by criteria, including Time Period, Strategy, and Security (and any combination) will allow reporting that might tease out some findings. In particular, narrowing which strategies have performed the best with certain securities, or if certain strategies fared especially well during a type of market. For example, my "Dying Company" strategy did real well during the swoon last year - of course it did, as it likes to go short and the market was down big time. Once might use their overall market outlook to choose which strategies to emphasize during a certain time period. By the way, I am all for using discretionary (non-automated) criteria as part of the automated system. Choices such as which strategy to use on which security are very important to system success, and can't very well be automated. This is why I don't mind opening up this project to the public - you could have every line of code and that wouldn't provide you with my own discretionary criteria. No two people will have even nearly the same results (except by luck) even if they run this identical system. Back to the user stories: total market exposure. This gets back to maximum risk. As an investor, if I say listen, I don't want any condition to lose more than 10% over market close (any overnight or weekend), then the system should be able to reflect that (note that excessive protection may also reduce potential gains). Going the other direction, we should be able to view (and track) market exposure. Again, this is a number one might track on a daily basis, as it may correlate with results and provide insight into the system performance. Some of these reporting aspects may be a bit tricky to implement, and I plan to automate tracking of data as best I am able. As User Stories they won't necessarily be part of the first release, but will be implemented as I'm able, based on priorities. We'll do some prioritization after we list all the stories. Two more roles to go. Damien
Love this thread, you're doing a lot of my thinking/planning for me You are long on documentation far in advance, which I tend not to be. I am probably 6 months behind you on the dev curve and you're giving me good things to think about that I wouldn't discover until I was already coding.
Some very good material here but.. I have found that usually the more variables I put into my systems, the worse they perform. KISS principle anyone? Maybe I'm wrong who knows.
Good to know guys. As far as KISS, yes, that is the idea actually. When you are designing strategies or actually trading, it will be very simple because so much is handled by the system governance functions. For example, you never have to compute the number of shares or create buy/sell orders in your strategies. I am a big proponent of simplicity, but I am willing to put in the work now to build the pieces that will make it simple later. The documentation is long, and we will trim parts off later. For example I am already backtracking on my tenet of defined targets - I realize that when I trade manually I don't identify profit targets, so it isn't really a valid tenet for me. The code will be a model of simplicity and efficiency, though. I've coded a lot of EasyLanguage so no worries. Back to the user stories (next post).
As a Strategy designer/programmer I can: 1. Set Stop Loss exit criteria to be managed by the system. 2. Set Profit Target(s) to be managed by the system. 3. Send notifications via the system. 4. Open a position via the system. 5. Close a position via the system. 6. Expect the system to manage position sizing. 7. Expect the system to correct mis-alignment of strategy and actual positions. 8. Expect the system to manage end-of-day activities (notifications, profit taking, risk mitigation, etc). 9. Expect the system to manage overall position risk (against major market moves). __________________ Back to KISS (Keep It Simple, Stupid), I am a big fan of simple trading ideas. But those simple trading ideas can get complicated when you realize all that can happen. From position sizing to coding buy/sell orders to fixing misalignments between actual and strategy positions, it can be a real pain. Clean ideas get messy when you pull up your system and see that you're short when your strategy says you should be long (trust me it happens). I've had positions that were supposed to close double in size and other strange behavior. While prevention is nice, cures are sometimes necessary. So look at those 9 functions, and realize that as a strategy designer, all of those factors are out of mind. You basically say "Open 1R @ $210, Stop Loss $202.90" and the system will ensure you hit your risk target (1R), purchase the right number of shares, guard your stop loss, ensure the total position size isn't too large, etc. When your strategy says to get out, you just "Close" and don't worry about the details (whether you were long or short, number of shares, etc). I'd like to hear from the experienced coders out there - do you think it's worthwhile to abstract these functions out of the actual strategies? Enjoy, Damien