a serious bug in trade
a serious bug in trade
12 Jun 2017, 07:52
I have looked at the FIX API for quotes and trading and it works quite well.
However I noticed a serious bug in trading.
When a position with PosID closes completely (by any independent way possible, or manually from cTrader platform), a stop order that had been attached to that PosID (and was not triggered during the lifetime of the PosID) still remains active after the complete closing of that PosID.
If that active stop order gets triggered afterwards (after the complete closing of the PosID), a new position is re-opened under the same PosID of the position that had been closed.
I think this is inconceivable; it is a quite serious error.
Because of that error, it becomes possible a position that was opened at a later time from a previous position, to have a position-id which is smaller than the position-id of a previous position.
Also the trades history gets erroneous and invalid under these circumstances.
I think the correct functionality is that as soon as a position (PosID) closes completely, then any attached stop orders attached to that PosID (attached by the use of 721=PosID) must automatically be canceled. I believe this is the correct functionality.
I would appreciate your feedback.
Otherwise I have found that the FIX API works quite well, but because of this bug I would have to change platform, until it gets solved.
Replies
sand
12 Jun 2017, 21:41
I cannot agree with that reply, or it needs clarification.
When I was in corporate software development and investment banking, some people used to call the bugs, features.
In that sense this issue maybe called a feature, but I kindly prefer to call it bug.
There are 2 types of stop orders.
1st a standalone or independent stop-order (not attached to any existing position), and 2nd a stop order attached to an existing PosID.
The 2nd type of stop order, is like a stop-loss order and cannot stay active after the main position (PosID) closes, but has to be closed automatically by the broker.
As long as a stop-order attached to a PosID is like a stop-loss, then it must close automatically upon closing of the main PosID.
As far as I know this is the only way to add stop-loss in your platform.
You also advised:
"If you wish your stop order to be canceled when a related position is closed, then this is a functionality that you need to develop on your side. You will need to keep track of your positions and the related orders and cancel those orders when positions are closed."
As far as I know what you advise is not possible in your platform. Your platform can close only a PosID but cannot close an OID (order id). Your platform can close only positions but it cannot close orders. Please correct me if I am mistaken.
I hope you can forward please this issue to a manager.
It is like seen a person walking in the streets holding an umbrella high above his head, and when the person goes inside his house, the umbrella still remains outside high in the air by itself.
The 2nd type of a stop order (or stop-loss) is like an umbrella to the main position (PoSID); when the PosId closes by any other action, the attached stop order (or stop-loss) must not remain in the air by itself; it must be closed automatically by the broker.
Otherwise without any provision for stop-loss, your FIX API is obsolete for trading. It works for quotes but for trades it is absolutely no use. And what a pity, it is a nice FIX API !
I think I sense that there is some reservation holds from your side, to have the FIX API running as it is supposed to be, as a high performance tool and the standard in financial transactions.
It is like buying a brand new multi-tonne lorry and keep moving around with it only with 3 kilograms of load, for not spoiling it.
Or buying a Ferrari and going in the main streets with 10 Mph blocking the traffic avoiding to stretch it.
FIX API is the standard of financial transactions and cannot be such much shy and blocking from opening and operating proper stop-loss (never mind the trailing stops), to save internet traffic and CPU utilization from/to the brokers.
Your trading friends,
Kind regards
@sand
Spotware
13 Jun 2017, 15:02
Hi sand,
Thanks for sharing your opinion and for the constructive discussion. Please find below some comments on some of the points mentioned in your post
"The 2nd type of stop order, is like a stop-loss order"
This is not true. Stop Orders assosiated to positions can be used for much more cases, like to increase volume (opening), to decrease it (fully or partially closing the position) or even reverse the position. So, a Stop Order assosiated to a position can't be interpret as solely as a stop loss.
"As far as I know what you advise is not possible in your platform. Your platform can close only a PosID but cannot close an OID (order id). Your platform can close only positions but it cannot close orders. Please correct me if I am mistaken."
Just for clarity and use of the correct terminology, orders cannot be closed but only cancelled. Order cancellation has been added to our FIX API. Please check the latest rules of engagement here. Therefore it is possible to handle this on the client side.
"The attached stop order (or stop-loss) must not remain in the air by itself; it must be closed automatically by the broker."
This cannot be done currently on our side. The reason is because we have both netting and hedging accounts. If we cancel pending orders, then it will be impossible to put pendings into netting accounts.
"It works for quotes but for trades it is absolutely no use."
Please accept our disagreement with this statement. If FIX API is used properly, it can be useful for both cases.
Implementing a stop loss on our side is not theoretically impossible but raises many other technical implications e.g handling position increase/decrease, that it is architecturally more corrert that the entire logic is implemented on the client side.
In any case, please rest assured that all your feedback has been sent to the product team for consideration.
@Spotware
#EOL
14 Jun 2017, 11:20
Hi sand,
You should interpret positions like a way to aggregate orders volume. Every order has a position, there are no standalone orders, they are just assigned to another position you can find in PosID in {OrdStatus=NEW, ExecType=NEW} execution report.
I think theoretically your problem could be solved on your side but it needs some development from Spotware. Spotware should add somehow open position volume in {OrdStatus=FILLED, ExecType=TRADE} execution report and extend Order Mass Status Request (MsgType(35)=AF) to have a possibility to filter by PosID.
So, in case you received some filled execution report with zero open position volume, you request all the pending orders left assigned to this position and cancel them one by one.
Similar flow to amend volume of artificial stoploss and take profit: receive filled execution report with non-zero open position volume, request pending orders for the position, cancel and put new ones if the volume is different
@#EOL
sand
14 Jun 2017, 19:06
Replying to Spotware,
Thank you for your replies and advise which I studied carefully.
I tested also the order cancellation that has been added and found it useful.
I do agree with your statement that if FIX API is used properly, it can be useful for both cases.
I would like to mark this question as solved.
Thank you.
@sand
Spotware
12 Jun 2017, 11:28
Hi sand,
Thanks for reporting the issue you face. However this is not a bug of FIX API but rather an expected behavior. A stop order will be executed unless it is explicitely canceled. If you wish your stop order to be canceled when a related position is closed, then this is a functionality that you need to develop on your side. You will need to keep track of your positions and the related orders and cancel those orders when positions are closed.
@Spotware