Towards Eliminating Broker Dependency: Fuzzy Logic, Another Technique to Help

Broker dependency has been becoming – little by little – one of the largest problems we face as Forex traders. The fact that our strategies lack the ability to perform equally across different brokers opens up a realm of uncertainty which is not only difficult to evaluate but whose consequences are hard to predict and determine across the large array of brokers currently available. One of the most powerful tools we have to counter this problem is potentially the introduction of some concepts derived from “fuzzy logic” which allow us to make our strategies entries and exits less strict and therefore much less prone to variations across brokers that may cause sharp changes in outcomes. On today’s post I will talk about some of these ideas and how they could be implemented within our trading strategies.

Broker dependency arises from the fact that Forex brokers have different feeds as there is no central exchange. Feeds can be different for many reasons, some of them are determinant (for example the broker’s opening hour and liquidity providers) while others are random (the broker’s latency to liquidity providers, to you, balancing between customer orders, etc). It therefore becomes very hard to determine whether one broker is better than another or to somehow test systems against broker dependency as this phenomena comes in almost random variations which change without any notice through time.

Many people believe that only systems which trade on the lower time frames or using tight SL/TP values are prone to broker dependency but the truth is that – although these systems are much more affected – systems traded on larger time frames, with very large SL and TP targets can also be significantly affected. We have witnessed this countless times in Asirikuy as different brokers yield different results due to  variations in their feeds that often cause significant variations across indicators in the medium/long term. These variations tend to cause differences in the time and existence of entries and exits which cause trade outcomes to be from slightly to completely different. However not only indicator based tactics are affected as price action strategies are also affected by this type of behavior.

In the end the main conclusion seems to be that there is no way to fully eliminate broker dependency through simple design considerations and therefore it becomes vital to make logic changes that can reduce the incidence of this problem to its minimum expression. In order to do this we need to consider that the main cause of the problem lies in the use of “strict” logic. If we enter a trade when a given indicator reaches above a value of  – for example – “31” then a trade might be triggered on a broker at 31.1 while another at 30.9 might fail to trigger the trade. In the end what we have is a large difference caused by what was probably a very small difference in feeds. This type of difference is what gives broker dependency its “power” in the first place.

How can we eliminate the problem? This is where fuzzy logic has its place. This technique tells us that we shouldn’t think in terms of “black and white” but that we should think about strict entry criteria as “fuzzy regions” around which entries should happen. In trading the easiest way to implement this is as a half-bell-shaped curve around the entry criteria which causes entries to be triggered “all around” the center. This means that if in the above example a trade achieved a value higher than 31 and entered a trade with 1 lot, the other broker which reached 30.9 shouldn’t stay out but enter at a lower lot size (0.9 for example). The idea is that an “almost entry” should still be a valid entry but yet “less valid” than a fully realized criteria.

In the “fuzzy logic” scheme of things the strength of the entry is reduced as we move away from the entry threshold and we end up with a decaying curve that makes broker dependency a very small factor in the end. In the above example we would enter a trade even at a cross above 30 with 0.1 lots while subsequent moves up would trigger the opening of additional positions until we accumulate the full 1 lot above the 31 threshold. What we get is a “cascading entry” when there is dependency in which most brokers will match at least to some percentage , even if there is very high variation. For example a broker may enter directly into 1 lot while another may enter at 0.1 and then 0.9 on the next bar and another may enter 0.5 and then 0.5 on the next bar. In the end this breeds less broker dependency than the approach without fuzzy logic because in this case brokers share at least a percentage of the original entry at the original location, something which doesn’t happen without this implementation.

The true power of this type of mechanism is really attained when you couple it with something I discussed before – trade dithering – where you enter several trades targeting different exit levels in order to eliminate dependency on exits attained by trades. This further diminishes the dependency of the strategies on brokers and makes the cascading effect equally important on trade exits. Certainly “fuzzy logic” is not very easy to implement and requires more advanced order management and entry/exit interpretation but its addition, coupled with trade dithering, may offer some key improvements that may help make broker dependency a total non-issue in the future.

If you would like to learn more about my work in automated trading and how you too can learn and get a true education around this field please consider joining, 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.

7 Responses to “Towards Eliminating Broker Dependency: Fuzzy Logic, Another Technique to Help”

  1. McDuck says:

    This development is very exciting, cause broker dependency is really the biggest problem. Do you have plans to adapt asyrikuy systems any time soon?. Thx.

    • admin says:

      Hi McDuck,

      Thank you for your post :o) I certainly will start testing the idea in Asirikuy systems but it will probably be sometime before it can be implemented on all of them since the implementation is not very straightforward for some systems. For example Teyacanani takes into accounts about 4 different criteria which need to be translated to fuzzy logic, to what extent and how much this would increase capital requirements is something that needs to be assessed clearly before wide implementation. However expect some videos about this and trade dithering soon :o) Thanks again for your comment,

      Best Regards,


  2. Maxim says:


    I liked the article vey much!
    Well, it depends upon a definition:
    If we define broker independency (invariance) as “All the instances should have the same equity after any period of time”,-an ideal, then any approach will hardly allow us to get there.
    On the other hand, softening the definition and making it more pragmatic-“All the instances should have the same amount of trades at any time” looks to be good enough.
    Your article will possibly allow us to implement the second definition.


  3. Gabor says:

    Hi Daniel,

    On the one hand I like you ideas about fuzzy logic and dithering and the combination of the two techniques, on the other hand I’m a bit worried about that the complexity of the EA code will increase to a great extent, which will make it difficult to read/understand/maintain and also it will be more complex just to run the strategies and understand what is going on at a given moment.

    An alternative to that problem could be that we take Alpari UK as “central exchange” – as we have simulation data from them – and we would use Alpari’s feed for generating enter/exit signals. If you want to trade at another broker you would run only a “thin client” EA, that would only copy the Alpari signals (you could copy your own Alpari account or a central Asirikuy service). As we develop new strategies and re-optimize old ones on Alpari feed, I think this could be a viable alternative. This solution has its drawbacks of course: introduces some more net failure possibility and Alpari UK dependence (e.g what happens if Alpari goes bankrupt or just won’t give us price history any more), and also latency/spread difference/slippage issues should be tested.

    • Fd says:

      I agree with Gabor, complexity will be increased and I’m not sure we are getting better results in the sense that different accounts will have a more synchronized behaviour. For sure the number of trades will be increased and that will lead to a smother return curve – lower peaks and drawdowns.

      I would suggest to systematically study the impact of broker dependency. There are several areas from which it arises and the impact of each has to be evaluated regarding it’s severity.

      – different time zones
      => possible measure: adjust to GMT+2

      – inaccurate broker time stamps
      => possible measure: adjust to NTP using offline charts

      – not enough hourly candles per week
      => possible measure: only use brokers with 120 hourly candles a week (Alpari does not outside DST!)

      – difference in broker digits
      => possible measure: only use brokers with 5 digits (except Yen, ofcourse)

      – heterogenous sources of broker feeds
      => possible measure: lowering granularity for indicator calculations

      – spread differences
      => possible measure: only use brokers with typical spread ranges equal to your backtests

      – swap differences
      => possible measure: unknown (I have not evaluated this)

      – dealing desk execution
      => possible meausre: only use STP or ECN accounts

      Ofcourse we could also think about building a central unified feed, distributing it amongst our clients, but having indicator values calculated on the client side. However that would be somewhat contrary to Asirikuy goals: enabling members to run their own systems without having to rely on some central knowledge.


      • admin says:

        Hi Fd,

        Thank you for your post :o) The idea would NOT be to have a centralized server which sent signals to members – which would defeat the site’s purpose – but, as Gabor mentioned for each member to have a single Alpari platform from which they derive their signals on their OWN VPS. Bear in mind that we should NOT use other brokers besides Alpari UK for this purpose because our backtesting data is from Alpari and therefore using a broker with 120 hours on each week will inevitably cause problems dealing with our profit and draw down targets derived from backtesting. We need to have a broker which matches our backtesting data, so Alpari UK is the only broker which should be used as reference (since there would only be one broker feed generating signals there is not need for any offline chart correction as this feed matches our backtesting feed which is what we care about). I believe that using Alpari UK as a single feed for the systems would eliminate the largest components of our current dependency problem. I have written today’s post about this issue :o) Thanks again for your comment,

        Best Regards,


    • admin says:

      Hi Gabor,

      Thank you for your comment :o) The idea of having Alpari UK as a central feed to use the systems is a good one that could breed a very reduced level of broker dependency. I have given a more extensive opinion on today’s post but I will certainly give this implementation a shot. Thanks again for posting!

      Best Regards,


Leave a Reply

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