As you know, traders need to control their positions risk.

One of the basic way to do so is not to spend all the equity that remains in our account in case of the losses our positions could face after opening them. Of course that implies to check the equity before opening any new position.

JForex is a real time trading environment, then our strategies which, in real time too, analyse the market and then take or not the decision to create a new position need to know the value of Equity in real time.

It is said in the documentation that :



That's totally in contradiction with the basic need of a trader to control his positions risk.

If I insist on that, that's because I faced the same problem while testing my strategies with the previous API (which also didn't provide a real time updated Equity). Even if one of my conditions for launching a new trade was my positions not to overtake 40 % of the remaining equity, my positions were often using 100 % (and more if some losses occured...) of my equity. And that ,even if I invested only 5 % of my initial equity on each trade.

Of course, getEquity() should also take into account the commissions paid during our investments. (As it was not doing that in the previous API), because, as you know, the amount of the commssions could represent a big ratio of profits and losses.

I noticed that I could never overtake 100 % of my equity just after opening a new position.
That means that you have the real-time-updated variable to prevent any trader to overtake this 100 % level.
What we need from you is only to provide us this real time variable.

That's a crucial problem.

Thank you

The reason why variables you can call through the interface IAccount are not updated real-time is that it would cause an overflow of
messaging, that could eventually be the cause for slowing down the whole process.
In addition, the frequency of ticks can be much more higher than the time necessary for an order to be sent, acknowledged, processed,
and confirmed back to the strategy, even if this order processing sequence is usually quite fast in such an environment.

In the case you are submitting orders onTick, and checking the use of leverage in the same interface, you must ask for the state of orders, which is
real-time, in order to get the true use of leverage, then checking your criteria for authorizing the strategy before sending an additional order.
In addition, in such a short time span, the equity shall not have changed significantly enough from its last updated value, to make the calculus of the use
of leverage useless.

The non-inclusion of transaction costs in the equity variable is primarily due to the reason described above. However, we understand the concern, and
are working to either provide directly the equity net of transaction costs (available now through the reports), or provide JForex users with a code sample to
compute these transaction costs within the strategy.

Please feel free to comment on the above.

I already told you about the crucial need of having the variables UseOfLeverage and/or Equity real time updated particularly for an automated program. Then I won't say it again.

You tell me about "messaging overflow" that would "cause an overflow of messaging"...

Well excuse me but the platform is already receiving in real time all instruments bid and ask at any tick, the platform already displays in real time profits and losses (taking account all the positions on all the instruments in real time).

If adding the real time display of only one more variable (UseOfLeverage) would cause such problems, that means that there's a problem on your server hardware capacity ?...

Moreover (and you did'nt refer to it) I said that this UseOfLeverage variable we need so much is already computed in real time in your server.

What we need is a function getEquity() that already exists but which gives us, when needed, the value of your UseOfLeverage rt updated variable. (The getEquity() that exists now is updated about every 5 seconds)

Thank you

You can use IHistory.getEquity() now, it calculates equity on the client side on every tick