OmniVest User Forums
Risk Control Requests (& other Account Settings)
Minimum Trade Size Settings
11 replies, 1155 viewings
|
OmniVest User Forums
Risk Control Requests (& other Account Settings)
Minimum Trade Size Settings
|
Last Activity 5/17/2016 11:06 AM 11 replies, 1155 viewings |
|
|
|
| Printer friendly version |
Jim Dean Elite   Posts: 1059 Joined: 10/11/2012 Location: L'ville, GA  User Profile |
I think there are good arguments for minimum size based on 1. $ amount 2. # shares 3. % equity 4. ATR mult vs commission costs Alow the user to specify any combo of those. Then, calc the "min share Limit" from whatever rules are specified, and allow the user one more input that specifies whether to use the min of those sizes, the max of those sizes, or the average of those sizes as the minimum limit? The code for doing this is just a handful of lines. Not complicated It covers a lot of different perspectives. Not limited It is easy to understand. Not confusing No need to debate and just choose one, or have just one "dictated" to us. Let the user manage their money and trading as THEY want to. | ||
| Calvin Hunziker Veteran  Posts: 101 Joined: 10/11/2012 Location: Lake Tapps, WA User Profile |
I couldn't agree more to your request. I've had a number of <10 share trades that although they showed a "profit" of $0.06 - $0.10 per share ended up being a negative when you factor in the $1.00 in and $1.00 out per trade commission. Sure, this might limit the number of trades, and therefore the number of potential profitable trades, but at least I wouldn't be upside down on the commission factor. Cal Hunziker [Edited by Calvin Hunziker on 8/15/2013 10:47 AM] | ||
| Wes Smith Veteran Posts: 199 Joined: 10/11/2012 Location: Ontario,Canada User Profile |
That way we could eliminate flappy strats that churn thru lots of low value trades. | ||
| kmcintyre Elite  Posts: 890 Joined: 10/11/2012 Location: Portland, OR User Profile |
It doesn't address the basic problem - TP lacks intelligence. At the least, trade size restrictions need to be Strategy level settings. Why go farther down the rat hole of countless account settings when they are a step in the wrong direction? Features added (just like laws) are rarely appealed. The result of adding tons of user settings is an application that is confusing and hard to use. Sorry, Jim. I think you have it wrong. Keith | ||
| Jim Dean Elite Posts: 1059 Joined: 10/11/2012 Location: L'ville, GA User Profile |
If they want to rewrite everything (unlikely at this point I think) then maybe there are better ways. But since this is a FEATURE REQUEST thread - please put discussion type postings and postings that request different features in a different thread. Thanks. [Edited by Jim Dean on 8/17/2013 4:43 AM] | ||
| kmcintyre Elite Posts: 890 Joined: 10/11/2012 Location: Portland, OR User Profile |
1) Fix the existing "Max exposure % per symbol" logic. I believe the root of the problem is that logic in OV reduces the size of trades to meet this setting. The last trade to the bar gets whacked down to the remaining percentage for that symbol. Why is that bad? When Nirvana creates strategies it does extensive testing. Part of that testing appears to be what SIZE trades should be taken. Hence the "Average Alloc per Trade" and "Trade %" stats on the Strategy and Strategies pages, respectively. When an OV user creates portfolios and accounts, she sets an "Alloc %" for each strategy. (Perhaps through inheritance, but ultimately each strategy is assigned an allocation strength.) All the research the OV user performs to select the components of said account is predicated upon both the Strategy "Average Allocation Per Trade" (aka "Trade%" in concert with the weightings placed at the strategy and portfolio level. For a bit of "quick and easy" logic (Max Exposure % Per Symbol) to disregard trade size information and (arbitrarily) whack trades down to silly allocation levels is wrong. IMO "Maximum Exposure % Per Symbol" should only allow trades to pass if the ENTIRE trade can be purchased. Fixing this should eliminate silly sized trades. (And hence obviate the need for even more "quick and easy" logic to mask the effects of the existing "quick and easy" logic.) 2) Make sure the trade size calculator is working properly. If you will recall, the beta group (me) had numerous discussions about the way the trade size calculator (inherited from OT) needed to work. The legacy code calculated trade sizes based on remaining buying power, versus the actual account equity. Basing trade sizes on buying power caused trades to become smaller and smaller as the account became more and more invested. This allowed silly small trades to be taken when the account was near fully invested. (This is a particularly bad thing to do if trading RTM strategies which expect tiny % returns per trade, and hence can't cover the commission costs.) I believe (after much discussion, coding and testing) Nirvana fixed this issue by using account equity x (Account Settings | Buying Power %) to determine trade sizes. (I still contend trade sizes should only be calculated on account equity, without regard to margin...) If this logic is broken (again), fit it. And to reiterate, Maximum Exposure % Per Symbol logic should honor the trade size calculator, and not arbitrarily whack the size of the last trade to the bar for said symbol. And it is wrong (INHO) to and another layer of "quick and easy" code to mask logic errors that exist elsewhere in OV/TP. 3) If anything, add trade size limits at the Strategy level. Minimum trade sizes are required because the profit potential of the trade must exceed the cost of placing the trade in order for a trade to make money. Hence minimum trade size needs to be a function of profit expectancy of the trade, expressed in $s. Different strategies will have different % profit per trade expectations. Hence the size of trade required to achieve a specific minimum $ profit target will vary between strategies. Hence the place to enforce minimum trade sizes is at the Strategy level, and should be specified as a minimum $ trade size (predicated upon the commission costs). (I'd be fine with "Minimum trade size | Expected Profit = X x Commission" too...) Again, for an Account level "Maximum Exposure % Per Symbol" to ignore such trade instructions (if and when implemented) and arbitrarily whack the size of a trade is wrong. Adding logic to mask the effects of said whacking is not the solution. (I contend it would be a bad thing in the long run...) In summary, the issue of silly small trades is a symptom of anomalies in the existing code base. If those anomalies are not fixed they will fester and ultimately harm attempts to add good and significant logic to OV/TP. Cluttering the UI with every possible setting imaginable and throwing "quick and easy" logic at the wall to see what sticks is seldom the solution to elegant software. Fixing the problem right the first time leads to a solid foundation upon which enhancements can be built. Patches and bandaids lead to an unstable product that breaks in mysterious ways every time the code is touched. End of rant. Peace Keith [Edited by kmcintyre on 8/17/2013 9:13 AM] | ||
| Jim Dean Elite Posts: 1059 Joined: 10/11/2012 Location: L'ville, GA User Profile |
I think there are good arguments for minimum size based on 1. $ amount 2. # shares 3. % equity 4. ATR mult vs commission costs Alow the user to specify any combo of those. Then, calc the "min share Limit" from whatever rules are specified, and allow the user one more input that specifies whether to use the min of those sizes, the max of those sizes, or the average of those sizes as the minimum limit? The code for doing this is just a handful of lines. Not complicated It covers a lot of different perspectives. Not limited It is easy to understand. Not confusing No need to debate and just choose one, or have just one "dictated" to us. Let the user manage their money and trading as THEY want to. | ||
| kmcintyre Elite Posts: 890 Joined: 10/11/2012 Location: Portland, OR User Profile |
Please note my objections and add my requests to the "features" and "bug fix" lists. Keith | ||
| SteveL Veteran Posts: 189 Joined: 10/11/2012 Location: Boulder, CO User Profile |
I agree with your philosophy. Putting a quick veneer on an unstable foundation is not a good solution. On the other hand, once the foundation is good, properly architected bells and whistles added to the UI are useful to meet the needs of different subsets of users. | ||
| Jim Dean Elite Posts: 1059 Joined: 10/11/2012 Location: L'ville, GA User Profile |
However, over the years I've learned that Nirvana rarely makes a wholesale change to their architecture for anything, once it's been released. So although I agree that an alternative IOP type mode would be better ... my pragmatic assumption is that, at least on the OVest side of things, radical revamping is not likely at this point. That is, the "better architecture" horse may be "alive", but there ain't no barn for it to live in. SO ... based on that assumption, I renew my request, with the "caveat" that if an architectural revamp is already planned or in the works, please integrate these controls on a lower level. [Edited by Jim Dean on 8/17/2013 12:41 PM] | ||
| Jim Dean Elite Posts: 1059 Joined: 10/11/2012 Location: L'ville, GA User Profile |
The request was NOT intended to "lock in" to the current architecture "versus" other proposed architectures ... it was intended to be GENERIC. So, if anyone OBJECTS to having some flexible form of minimum-size user-input controls, VERSUS HAVING NONE AT ALL, then your comments might be helpful here. Comments regarding architecture in general are likely to "cloud" the initial reason for posting this request. I suggest that those architectural comments be put in a different thread, since this suggestion is not contingent on what direction those other things might lead. That, at least, was my INTENT. | ||
| Jim Dean Elite Posts: 1059 Joined: 10/11/2012 Location: L'ville, GA User Profile |
However, even if other potentially-goofy calculations are fixed, I would contend that there is STILL A NEED for the optional minimum settings that I've outlined. They won't hurt anyone, or hide anything, if they are turned off ... but they presently are not available at all and that is what I'm requesting. This is not a boxing match between two alternative solutions ... it's simply a request for options that do not exist at all right now. Selah. |
|
|
|
|
Administrator
Forum Moderator |
Registered User
Unregistered User |
 E-Mail this thread to a friend |
Toggle e-mail notification |
