What information does a forex trading system need to communicate to the user?

User Rating: / 4
PoorBest 
Written by Forex Automaton   
Monday, 02 March 2009 12:46

As any computer program, a forex trading system has input and output. This post is about the output -- what should be in it? What are the guiding principles of this communication? Here are the basic principles as we see them now:

  • Regularity.
  • Communicate actions, not prophecies.
  • Communicate actions as they happen.
  • Program the computer, not the user.
  • Be accountable for the past performance.
  • No misrepresentation.
  • Access control.

Regularity

Trading decisions are made and executed at regular, discrete time intervals. The time intervals may be an hour, a few hours, or a day. A decision can be a buy or sell order, a decision to stay in the trade, to reduce or increase position, or to move a stop-loss. The trading decisions make impact on a simulated portfolio (in dollars, not pips). Money management is an integral part of the problem.

Communicate actions, not prophecies

There is a difference between the statements "I went long EUR/USD at 9:01 am at 1.249 with 1% of my account" and "EUR/USD is going to break the resistance level at 1.25 and keep moving up". Even though the latter statement may correctly communicate the reasoning behind the action summarized by the former, the former statement implies higher standards of accountability. For the same reason, we are not going to "just give you the direction" -- a "direction" without accountable commitment measured in dollars is almost useless.

Communicate actions as they happen

Sometimes it happens with investment newsletters: a certain trade is placed, then exited in between the newsletter publication dates. When the reader finds out about it (on the next publication date), it's already too late. And the newsletter's portfolio looks much better than the client's one. To prevent this from happening, we are going to follow the rule: trade frequency is the communication frequency; the only exception to this rule is a stop-loss order which is communicated together with the trade decision it applies to. A stop-loss order can be executed (but not moved) in between the regular communications, at the level known to the user from previous communications.

Program the computer, not the user

This means you won't find statements like "if {A happens} then {do B}" in the trading system output. Since actions of the system are communicated regularly and with minimum delay after they happen -- which means that the trades themselves happen regularly, except for stop loss execution -- there is no need to program the user. Again, the only exception to this rule is a stop-loss order which is communicated together with the trade decision it applies to.

Be accountable for the past performance

Web access to the past performance archive will be kept open. Not only performance statistics, but the actions of the system themselves must become "declassified" after a certain, not too long, time interval. This must be done to differentiate the service from scam "business models" based on providing different (opposite) "signals" to different people, so there is always a happy constituency within the user community, even if of limited half-life. So let's make sure the user community can see that here is actually a single track record, visible even to prospective clients some time after the trades are entered. The length of the time interval in question will depend on the time scale of trading; for definiteness' sake let's make it long enough so that statistically, 99% of positions opened following a signal are closed by the time the signal is "declassified". Declassified history must be visible to all, not just the subscribers of the service, and publishing it after the fact can't hurt those who trade the signal.

No misrepresentation

A service like this is not an investment advice. Even though the trading algorithms can be tuned to maintain a certain level of risk, and the level of risk can be calibrated and announced to the user in advance, matching the level of risk with individual circumstances is the job of a financial advisor -- the job we are not qualified to do. Needless to say, no promises can be made as to the potential profits or losses.  Past performance is no guarantee of future returns and the user must at all times stay aware of the risky nature of trading and the personal degree of risk she can accept.

Access control

Money moves the prices, and so does information. Granted, the intellectual side of "how Forex Automaton™ works" will never be revealed. (Poking fun at the efficient market hypothesis does not count!) But there are second-order problems. A retail investor has her scale of money under control, and a big institution -- a completely different scale. The difference is many orders of magnitude. This service is designed for retail clients, not for big institutions. With the business model in mind (subscription service), the amount of money that follows our algorithms may be merely weakly correlated with the number of subscribers, and the latter is a poor measure of the former.

To what extent is the problem of hypothetical institutional money liquidating the real-time inefficiencies we will be communicating -- with our almost thankless help, and at a detriment to other users -- is really a problem? What is the magnitude of the price effect they can cause? What measures (technological, legal and so on) can be taken to prevent such a scenario from happening, or reduce its likelihood? The easiest for us would be to dismiss this concern as premature, but please share your thoughts on the subject.

Bookmark with:

Deli.cio.us    Digg    reddit    Facebook    StumbleUpon    Newsvine
Last Updated ( Tuesday, 22 December 2009 13:44 )