Solutions to Broker Dependency: Would Trading Only One Feed Work ?

Yesterday I wrote a post about the use of fuzzy logic to help us alleviate the issue of broker dependency which was met with enthusiasm by several members of the Asirikuy community. This method coupled with dithering and other similar procedures could help us eliminate dependency although at the expense of a great increase in complexity within the code of our systems. As Gabor clearly pointed out in a comment yesterday this makes managing of code harder and the location and elimination of bugs a potential nightmare. Within this post I intend to talk about another possible way in which broker dependency could be solved, which is the use of a single broker’s feed. Through the following few paragraphs you will learn what this solution is about and several of the problems we would face in this regard.

The problem in Forex trading – as I highlighted in yesterday’s post – is our lack of a central exchange and the difference between the feeds of different brokers. A seemingly easy solution to this problem is then to make all brokers take signals from the same broker’s feed, effectively eliminating the problem of having different signals but generating a set of new problems that arise because we are “simulating” a central exchange.

The first problem that arises with the above idea is the fact that we need to have a certain type of trade copier which enables us to copy decision made on one broker on others. This generates the problem of lag since you will need to generate some sort of signal between brokers and you are most likely going to get very different types of entries since brokers will have different spreads and price levels at the moment when the signal is received. Of course this lag problem would be minimal compared to commercial trade copiers since there is no “web communication” but merely communication between two programs on the same computer.

The second problem we need to address is the inherent difference between the exit targets of the systems, certainly since the feeds are different the brokers may not reach the same TP or SL levels or may have different profit levels when exit signals are received. We could certainly listen “only” to the exit signals from the reference broker but in any case we will still have some inherent differences with other brokers because of the lag problem added to the inherent feed differences between them. This would cause another difference on exits which will make overall per-trade results different on each broker even if the time at which the signals are executed are almost exactly the same.

It is also very important to note that the ONLY broker which is useful for this purpose is Alpari UK since other brokers which would seem like better models (because they have 120 hours a week all year round) cannot be used because our backtesting data is ALPARI UK data and NOT data from other brokers. In order to ensure that our profit and loss expected targets are as close as possible to our simulations we need to use Alpari UK as a signal broker since this is the broker which has data that matches our backtests and which we can obtain going forward.

I believe that this method of reducing broker dependency has the advantage of making signals completely uniform between different brokers but trading results between brokers will vary to a certain extent due to the execution of trade entries and exits which will not match the exact same price level across different brokers. In the end this will ensure almost complete signal parity at the cost of exact entry/exit level precision. Of course this means that there will still be some differences amongst different broker accounts but such differences are bound to be minimal compared to the current scenario.

The idea of course is NOT for Asirikuy members to take signals from some central source (like a webserver) but for each Asirikuy member to setup their own Alpari instance trading the systems they want to signal on their other broker accounts. Since demo account feeds are different from live Alpari UK feeds the best solution might be for Asirikuy members to access a live Alpari UK account through investor access from which they can deliver signal information without concerns of getting disconnected due to a demo expiration or something of this sort.

Whether or not the above can be done successfully is a matter of testing it out reason why I will start to work on this implementation so that we can eliminate the broker dependency problem as much as possible without introducing a lot of added complexity into our systems (as they would get through the implementation of fuzzy logic and dithering). Certainly we need to try this before actually fully implementing it within Asirikuy but it seems like a very worthy idea to evaluate in-depth within Asirikuy due to its full potential to eliminate signal dependency.

If you would like to learn more about automated trading and how you too can learn to create your own systems based on sound trading tactics please consider joining Asirikuy.com, a website filled with educational videos, trading systems, development and a sound, honest and transparent approach towards automated trading in general . I hope you enjoyed this article ! :o)

Print Friendly, PDF & Email
You can leave a response, or trackback from your own site.

3 Responses to “Solutions to Broker Dependency: Would Trading Only One Feed Work ?”

  1. Fd says:

    Hi Daniel,

    as historical Alpari data contains Sunday-wraped Monday candles, I don’t believe that you can get real backtest consistency using Alpari historical data even with an Alpari live account. I can’t say how much the impact will be but there will be one.

    However the measures we should take are dependend from our definition of goals. Do we want all member instances trade at the same times in the same direction? Or do we want to develop robust EAs that are able to survive even under sub optimal feed conditions? Would you say that the anomalies we are exploiting are so weak that they are likely to be distorted by broker dependency? Can you please clarify?

    Best regards,
    Fd

    • admin says:

      Hi Fd,

      Thank you for your comment :o) Don’t the Sunday-wrapped Monday candles on the history match the way in which daily candles are plotted on a regular Alpari account? If this is the case then we should expect better consistency. About our objectives, I believe that our inefficiencies are quite robust and this has been shown by the way in which different brokers have shown profitable outcomes for several different systems, we can therefore assure that broker dependency does not cause a “losing of the edge” of the systems but makes system evaluation harder as we have many different results which are often difficult to compare. I believe that eliminating dependency is about getting clearer expected targets and a clearer interpretation of results. Although a different feed doesn’t eliminate our inefficiency it does distort the long term expected targets as we did not test for that particular feed. The idea of equalizing performance to one broker would be to get a clearer evaluation and a better match to our long term expected statistical targets but certainly the question of whether or not different feeds act as a means of additional diversification is valid.

      Long story short, our systems are made to be robust and survive even on feeds that do not match their optimization set but having coherence of all signals to one broker would enable us to have more certainty about our long term statistical targets. In essence what I am saying is that the idea of having one feed to trade the systems makes the interpretation of results and their evaluation more straightforward but it is in no way necessary for the systems to actually be profitable. I hope this clears it up :o)

      Best Regards,

      Daniel

      • Fd says:

        Hi Daniel,

        thanks for your clarification! Most likely we will come up with an arsenal of measures which we can apply to change odds a little bit in our way.

        > Don’t the Sunday-wrapped Monday candles on the history match the way in which daily candles are plotted on a regular Alpari account?
        No. The live feed form Alpari starts on Monday 0:00 GMT+1 (with European DST settings). Having a wrap during live feed would imply that to the Monday 0:00 hourly candle the Sunday values are added at open. In most cases the Sunday open 23:00 will be different than the Monday open 0:00. It would thus imply adding Sunday 23:00 data to at once to the Monday 0:00 candle. Otherwise, what could be done – but is not in Alpari practice – would be to start feed on Sunday 23:00 GMT+1 with a timestamp of GMT+2 and doing a switch back of 1 hour to be 0:00 GMT+1 again. This does not happen.

        Regards,
        Fd

Leave a Reply

Subscribe to RSS Feed Follow me on Twitter!
Show Buttons
Hide Buttons