SL didn't execute - account now underwater
SL didn't execute - account now underwater
16 Jul 2013, 12:16
Spotware - I have completely lost faith in your platform after this recent trade. As the log shows the SL did not execute due to a "technical error".
I have contacted my broker IC Markets who are looking into it, but I would also like a response from you.
As a result my account balance is now in the negative. Obviously I am seeking the position be closed at the SL level and my account refunded.
Replies
cAlgo_Fanatic
18 Jul 2013, 16:39
We've investigated your issue. Here is an explanation of what really happened:
16.07.2013 08:29:59.190-345
Two stop orders (buy and sell) were created, both with SL=2pips.
The Buy order's target price was 1.51142, SL price 1.51122
16.07.2013 08:30:00.205
The buy order was triggered with the price 1.51182 and then the price had gone down
16.07.2013 08:30:00.622
The buy order was filled at the price 1.51182
16.07.2013 08:30:00.628
Server applied SL and TP to the created position, but SL was rejected due to SL validation rule: SL price for buy order must be always less than the current price.
Current Bid was 1.50976, but requested SL was 1.51122.
Prices:
Bid 1.51126 11:29:59.071
Ask 1.51136 11:29:59.071
Bid 1.50947 11:29:59.122
Bid 1.50944 11:29:59.229
Bid 1.50939 11:29:59.281
Ask 1.51127 11:29:59.281
Bid 1.50934 11:29:59.492
Bid 1.50954 11:29:59.744
Ask 1.51148 11:29:59.744
Bid 1.51114 11:30:00.000
Ask 1.51137 11:30:00.000
Bid 1.50995 11:30:00.205
Ask 1.51182 11:30:00.205 // Buy stop order was filled at this price
Bid 1.50983 11:30:00.463
Ask 1.51062 11:30:00.463
Bid 1.50976 11:30:00.630 // This bid was used to validate SL price
@cAlgo_Fanatic
kricka
18 Jul 2013, 22:42
Hi,
If I understand it right 2 pips stop loss in a news enviroment is a risky trade. The chance of not being filled is very big because of the fast moving market. My question is, was the technical error at the precise time the market tried to fill your stop loss, the reason it was out of range, or did the technical error delayed you stop loss being filled until it was out of range.
@kricka
kricka
18 Jul 2013, 23:09
Mocean, your experience with the stop loss not being filled is nothing new, this can happen and the soloution is to have protection beyond the initial trade. A position without stop loss can even blow up an account if the trade goes against you as it did in your case. Hopefully you got out of it not losing too much. My suggestion is to have an account equity protection in your robot in case the stop loss don't get filled. This will protect you even in a bad case scenario like the one you experienced.
@kricka
cAlgo_Fanatic
19 Jul 2013, 11:01
The "Technical error" in the log is not related to SL. The Robot tried to cancel the second (sell) stop order in 1 second, but it was already triggered. So there was an error.
We will be replacing the generic "Technical Error" term that is rather confusing with more detailed messages in the next two-three releases.
@cAlgo_Fanatic
Mocean
19 Jul 2013, 14:13
Thank you all for your comments.
Yes, I fully understand the risks of trading the news - false spikes that trigger your positions and SL before the news is even released, and slippage in a fast moving market or lack of liquidity. It's these risks that actually led me to cTrader / cAlgo, where a STP / ECN platform would reduce, if not eliminate, false spikes; and fast execution to direct market prices should reduce slippage. What I was not expecting was what happened with this trade.
First of all I stand corrected, the "technical error" noted in the cAlgo log was in fact referring to the second pending order. More detail of trade logs should be an absolute priority. If cTrader / cAlgo is going to replace MT4 then you need to at least match their functionality and trade journal.
I also want to note that as I have associated IC Markets in this post I can confirm they have, and continue to, assist investigating this trade. I have found them to be the most legitimate broker I have used and have full confidence they do not trade against me and make their money via commission only.
It took two attempts to request the detailed server log from Spotware. I am surprised the broker does not have direct access to this? The server log was finally supplied, and saying it is complex and difficult to understand is an understatement.
The server log was about 7 pages of information like this, but I believe this to be the execution event.
2013-07-16 08:30:00.597 +0000 DEBUG Order filled event FilledOrderEvent[orderSnapshot=[ orderId=528151 positionId=430594 type=STOP traderId=68017 bookType=BOOK_A symbol=GBPUSD tradeSide=BUY volume=30000000 closingOrder=false limitPrice=<null> stopPrice=151142 baseSlippagePrice=<null> slippageInPips=<null> createTimestamp=1373974199302 utcLastUpdateTimestamp=1373974200595 expirationTimestamp=1373974210000 partialFillAllowed=true stopLoss=151122 takeProfit=151442 stopLossInPips=<null> takeProfitInPips=<null> deals=[[ positionId=430594 key=0,528151,1373974199745,1 symbol=GBPUSD volume=30000000 type=MARKET tradeSide=BUY limitPrice=<null> retryCount=1 bookType=BOOK_A traderId=68017 marginRate=164299 commission=1478 execution=Execution[feedKey=FeedKey[bookType=BOOK_A,feedId=1],orderId=528151,status=EXECUTED,price=151182,volume=30000000,lpPrice=151182,createTimestamp=2013-07-16 11:30:00.595] marketDataEntryKey=MarketDataEntryKey[entryId=04011151148,feedId=1,type=ASK] priceSnapshotId=8466 partialFillAllowed=true baseToUsdConversionRate=150954]] status=FILLED clientRequestId=2e055995-513b-405e-9148-c7762cc87bdf label=<null> comment=<null> channel=cAlgo commission=1478 executionPrice=151182 filledVolume=30000000 marginRate=164299],sessionId=<null>,clientRequestId=<null>,source=LP]
It states:
stopPrice=151142
stopLoss=151122
EXECUTED,price=151182
As indicated by Spotware's tick data, the spread at time of execution was 18.7pips - I understand it was a news event but this is a pretty big spread for supposedly direct market prices and deep liquidity.
Bid 1.50995 11:30:00.205
Ask 1.51182 11:30:00.205 // Buy stop order was filled at this price
Spotware has indicated that their platform functions like this - even if a pending order has a SL attached, once the pending order is executed the SL is "verified", meaning the SL is only attached to the position once it's executed. Basically double handing the SL. If the SL is inside the spread it won't trigger and is rejected. Why reject a SL? If the price has moved beyond the SL then it should be triggered immediately - this is called SLIPPAGE. The whole point of a SL is to STOP LOSS - not consider it, then reject it. I see this as a major flaw in Spotware's programming logic and business rules.
How does this = TRADERS FIRST™
Not obligating a SL = Greater Risk = Greater Losses = PRIME BROKERS FIRST
Spotware – a question I'd be interested to know the answer to, is – do any Prime Brokers or Liquidity Providers have a vested interest or investment in Spotware?
Back to the trade - as mentioned the spread was indicated as 18.7pips, so even if I had a SL of 15pips this SL would still have been rejected and the position would have continued into loss. So what SL is sufficient?
This flaw of SL being rejected if it's inside the spread applies to all orders - whether you use a Robot for high volume trading or scalping with a tight SL, you run the risk of the SL being inside the spread and not firing.
I have traded the news with straddle pending orders on Trading Station and MT4 and never had a SL not fire. Sure I've had slippage but that's trading.
OK, so now to the big kicker. After the SL failed, the trade continued into loss and kept going. The platform failed to initiate a Margin Call and close the trade and it continued into unlimited loss. Luckily I was watching it, as I run cAlgo on a VPS it could have very well been a trade I was not watching. Imagine your surprise to find not only your account is blown but now you're underwater and in debt. My broker is also extremely concerned by this as they would be the one most at risk. Like I'm going to be paying back a negative account that failed to close a trade.
Spotware, in theory your platform has great potential, but in reality you are still in development and Beta testing with people's real money. You've been around for a year now and while you're platform is pretty, it fails to address traders real needs:
- Trade Protection / Trade Management
I have requested via my broker to have my account refunded, I understand they are still investigating it with Spotware – I await a response and will post it here.
@Mocean
cAlgo_Fanatic
19 Jul 2013, 17:59
As indicated by Spotware's tick data, the spread at time of execution was 18.7pips - I understand it was a news event but this is a pretty big spread for supposedly direct market prices and deep liquidity.
Bid 1.50995 11:30:00.205
Ask 1.51182 11:30:00.205 // Buy stop order was filled at this price
The amount of spread depends on various factors but does not have anything to do with the platform. Prices come directly from the Liquidity Provider and are not modified.
Spotware has indicated that their platform functions like this - even if a pending order has a SL attached, once the pending order is executed the SL is "verified", meaning the SL is only attached to the position once it's executed. Basically double handing the SL. If the SL is inside the spread it won't trigger and is rejected. Why reject a SL? If the price has moved beyond the SL then it should be triggered immediately - this is called SLIPPAGE. The whole point of a SL is to STOP LOSS - not consider it, then reject it. I see this as a major flaw in Spotware's programming logic and business rules.
Due to multiple broker/trader requests the functionality became as follows:
I have traded the news with straddle pending orders on Trading Station and MT4 and never had a SL not fire. Sure I've had slippage but that's trading.
Most other platform setups are on Instant, meaning this scenario is just not applicable. Also, there's a required gap between entry price and the protection level. Spotware is different.
- introduce what we call Relative Protection for Limit and Stop orders - the same way as we have it done for Market Orders - desired protection levels are defined by users in pips from the executed price which would give us the logical space not to validate
OK, so now to the big kicker. After the SL failed, the trade continued into loss and kept going. The platform failed to initiate a Margin Call and close the trade and it continued into unlimited loss. Luckily I was watching it, as I run cAlgo on a VPS it could have very well been a trade I was not watching. Imagine your surprise to find not only your account is blown but now you're underwater and in debt. My broker is also extremely concerned by this as they would be the one most at risk. Like I'm going to be paying back a negative account that failed to close a trade.
@cAlgo_Fanatic
Mocean
20 Jul 2013, 02:34
Thanks for the response.
Thinking about this further something painfully obvious occurred to me, and confirmed by your comment.
First of all, I'd rather be "surprised" to take an instant small loss over a rejected SL and unlimited loss any day.
Due to multiple broker/trader requests the functionality became as follows:
SL/TP absolute values are validated before being applied (resulting in cancelled SL/TPs in such scenarios). It did make some sense to us - traders were often surprised by a position being live for a fraction of a second, generating an immediate loss, with no option to recover.
Then the logical thing to do to protect TRADERS - is to treat the SL as a primary execution criteria. Meaning, if the SL is within the spread then don't execute the trade at all, rather than executing followed by an instant SL close at a loss.
When I place a SL I am instructing the platform to stop my loss at, or as close to, that level as possible. Having the platform cancel a SL in any scenario is nonsensical.
Our plan is to:
- introduce what we call Relative Protection for Limit and Stop orders - the same way as we have it done for Market Orders - desired protection levels are defined by users in pips from the executed price which would give us the logical space not to validate
When I set a SL on a Pending Order this is what I believed I was already doing.
Just seems like this whole validating SL is absurd, and a waste of programming speed.
I can't find your explanation of this SL functionality explained anywhere on your site, and could not even locate your Product Disclosure Statement. If you can show me where this is outlined to advise traders, then I will concede. if you cannot then it is fair to assume that your platform functions like others and SL would have been instant in this scenario. And on that basis my request for my account to be refunded stands.
@Mocean
kricka
20 Jul 2013, 06:21
Hi,
a stop loss is a stop loss and a position should be stopped out regardless if the position is out of range or within the range. Slippage we can take as long we know that we are protected on the downside. This is very important for the developer team of Spotware to pay attention to, so the traders are assured that the protection is valid. Tecnical errors in a worst case scenario should not have any bearing as long tho stop loss order is in place. After all, the stop loss was placed to protect the trade, even if it was triggered out f range the platform have to aknowledge that the position needs to be closed. On the other hand tecnical errors can happen and to be assured that our positions is protected whatever happens, other security messurment needs to be firmly in place. I'm refering to having protection outside the robot placing the orders, an external robot dedicated to guard the trading account and keep an eye on all opened poitions made by manual trading or made by other robots.
@kricka
Mocean
20 Jul 2013, 06:59
Thanks for your comments Krica.
Just to confirm, the error with this SL not firing had absolutley nothing to do with the Robot. The Robot performed perfectly. I did not create the Robot, I downloaded it from CTDN, and I am not a programmer.
The SL did not fire because of Spotware's core platform logic on exection of Pending Orders.
This is what happened:
- Robot placed Pending Order with SL + TP - this is the end of the Robot's involvement in this trade.
- Ask price moved and triggered Buy pending order @ 1.51182 / with SL @ 1.51122
- The platform then "verifies" the SL level after the Buy order is executed - as indicated by Spotware 425ms later
- SL was inside the spread, therefore higher than the Bid price @ 1.50976. Spotware's platform logic therefore rejects (ignores) the SL altogether and lets the trade run into unlimited loss.
Ask 1.51182 11:30:00.205 // Buy stop order was filled at this price
Bid 1.50983 11:30:00.463
Ask 1.51062 11:30:00.463
Bid 1.50976 11:30:00.630 // This bid was used to validate SL price
I don't want a platform to consider if my SL is within a range to verify it, I want the SL to execute if the level I specificed is reached, or exceeded, as quickly as possible. Not think about it for 425ms.
Due to multiple broker/trader requests the functionality became as follows:
SL/TP absolute values are validated before being applied (resulting in cancelled SL/TPs in such scenarios). It did make some sense to us - traders were often surprised by a position being live for a fraction of a second, generating an immediate loss, with no option to recover.
I would not be "surprised" at all if I set a tight SL, as I did (2pips) and it triggered immediately. That is precisely what I instructed the platform to do. If "traders" are "surprised" then they should be setting a bigger SL level.
@Mocean
Sunbrick
22 Jul 2013, 11:37
Whereas I'm not a particularly big fan of this trading strategy, and I think a lot of brokers will do what they can to try and prevent it from being possible, I do agree completely with Mocean, that if the logic is as described, where an order with an SL attached first gets entered without the SL, then the SL is verified, and if rejected the order still stands, then that is completely unacceptable.
The entire thing should get rejected in the first place.
@Sunbrick
cAlgo_Fanatic
22 Jul 2013, 16:15
RE:
Whereas I'm not a particularly big fan of this trading strategy, and I think a lot of brokers will do what they can to try and prevent it from being possible, I do agree completely with Mocean, that if the logic is as described, where an order with an SL attached first gets entered without the SL, then the SL is verified, and if rejected the order still stands, then that is completely unacceptable.
The entire thing should get rejected in the first place.
First, the order goes to the market, where it gets executed. Then a position is created/affected. Only then is protection applied to the position. Therefore, there is no way to "reject the entire thing in the first place".
We believe that introducing "relative protection" for pending orders plus killing the above validation, will be sufficient to achieve what you have described.
@cAlgo_Fanatic
cAlgo_Fanatic
01 Aug 2013, 11:38
The current validation of protection levels is not an error. It is intended to protect from scenarios where a position is live for a fraction of a second, generating an immediate loss. It is currently the standard way as well as it being the most logical implementation for protection defined in absolute values.
@cAlgo_Fanatic
kricka
06 Aug 2013, 03:41
Hi Spotware,
will you clearify it a lttle more, please.
My opinion is if you place a stop loss and the market is when the stop loss is triggered, out of range.The platform should still take the stop loss as a fact and close the position immideately. This is bound to happened now and then in a fast moving market. A position without a stop loss can be devistated for the trading account. The purpose of placing it, is to protect the position and should do so under any circumstances. "Changing protection to relative values will allow us to remove such validation".
If that means that a change is coming to prevent a position with a stop loss, "not to be out of range", we are welcoming it.
Thanks..
@kricka
cAlgo_Fanatic
06 Aug 2013, 11:03
RE:
Hi Spotware,
will you clearify it a lttle more, please.
My opinion is if you place a stop loss and the market is when the stop loss is triggered, out of range.The platform should still take the stop loss as a fact and close the position immideately. This is bound to happened now and then in a fast moving market. A position without a stop loss can be devistated for the trading account. The purpose of placing it, is to protect the position and should do so under any circumstances. "Changing protection to relative values will allow us to remove such validation".
If that means that a change is coming to prevent a position with a stop loss, "not to be out of range", we are welcoming it.
Thanks..
That is correct, by setting your stop loss in relative value (pips away), you avoid the risk of the stop loss being invalid because it will be calculated as pips away from the entry price.
@cAlgo_Fanatic
Mocean
07 Aug 2013, 13:51
Spotware - please elaborate?
That is correct, by setting your stop loss in relative value (pips away), you avoid the risk of the stop loss being invalid because it will be calculated as pips away from the entry price.
What you're saying here is that "relative value" SL will set the SL from the Entry Price, as opposed to a static SL value in the pending order. So a "relative vlue" SL will account for any Slippage on the Entry Price. How does this eliminate the SL from being inside the spread and rejected by your flawed programming?
Our plan is to:
- introduce what we call Relative Protection for Limit and Stop orders - the same way as we have it done for Market Orders - desired protection levels are defined by users in pips from the executed price which would give us the logical space not to validate
So why is it you can't use the "logical space not to validate" from the SL I set in the Pending Order?
I have exhausted this whole trade and errors with my Broker, here is a summary of the outcome:
- SL was rejected because it was inside the Spread, instead of closing the position immediately, this let the position run into UNLIMITED loss.
Server applied SL and TP to the created position, but SL was rejected due to SL validation rule: SL price for buy order must be always less than the current price.
- Spotware's initial claim was to blame the Algo, which had absolutely no bearing on the SL failure - as explained the SL was rejected because it was inside the spread and they have deliberately programmed it this way because -
Due to multiple broker/trader requests the functionality became as follows:
SL/TP absolute values are validated before being applied (resulting in cancelled SL/TPs in such scenarios). It did make some sense to us - traders were often surprised by a position being live for a fraction of a second, generating an immediate loss, with no option to recover.
- Margin Call set at 80% of Margin Level failed - for which Spotware offered to reimburse just enough to cover my Broker's loss on my negative balance.
- Spotware derived the calculation of the amount to reimburse on their supplied tick data - which amazingly calculated my balance to be -$1.65.
OK, so the tick data could be legit and coincidentally zeroing my account, but after the string of "errors" that Spotware claim are not errors, I am of the conclusion that nothing is coincidental in FX trading - and errors don't happen, they are intentional.
cTrader offers little, if no transparency in the way of trade logs and tick data - so at the end of the day you are at the mercy of Spotware's honesty. Yes they constantly claim it's in development like everything else to protect traders interests.
I would even go further to reiterate a question I posed to Spotware earlier in this thread -
Spotware – a question I'd be interested to know the answer to, is – do any Prime Brokers or Liquidity Providers have a vested interest or investment in Spotware?
So is cTrader a ECN / STP - or is it another Market Maker platform for Prime Brokers instead of Retail Brokers?
With all the shortcomings of MT4 - at least it works as I instructed it to!
@Mocean
cAlgo_Fanatic
09 Aug 2013, 16:55
RE:
Mocean said:
Spotware - please elaborate?
That is correct, by setting your stop loss in relative value (pips away), you avoid the risk of the stop loss being invalid because it will be calculated as pips away from the entry price.
What you're saying here is that "relative value" SL will set the SL from the Entry Price, as opposed to a static SL value in the pending order. So a "relative vlue" SL will account for any Slippage on the Entry Price. How does this eliminate the SL from being inside the spread and rejected by your flawed programming?
Our plan is to:
- introduce what we call Relative Protection for Limit and Stop orders - the same way as we have it done for Market Orders - desired protection levels are defined by users in pips from the executed price which would give us the logical space not to validate
So why is it you can't use the "logical space not to validate" from the SL I set in the Pending Order?
The relative protection implementation will function as follows: In the event that the protection is within the spread the position will close.
So is cTrader a ECN / STP - or is it another Market Maker platform for Prime Brokers instead of Retail Brokers?
http://www.youtube.com/watch?v=9-_HweZUGS4
@cAlgo_Fanatic
kricka
10 Aug 2013, 00:31
Oh, forgot to mention the cTrader youtube video http://www.youtube.com/watch?v=9-_HweZUGS4
Very good video explaining the difference between cTrader and the rest of the pack. Have not seen it before, so I enjoyed watching it very much. One killer video it would have been, if it would have zoomed in and out on the different aspect on cTrader platform between the 29 points listed and compared in the video.
@kricka
kricka
04 Nov 2016, 19:36
Protect the trading account
A "technical error" revival on this thread maybe. Errors do happen and for different reasons. For any trader with real money placed in positions, there has to be an external protection if something goes wrong with the basic position stop loss at the brokerage server. A VPS server is an excellent overall protection that can be used if the stop loss for some reason is not executed from the broker side. Read more here: VPS Server
An account protection is vital regardless of how many positions are in place. Visit the RMMRobot.com site for more information on this so important subject, how to protect the trading account.
@kricka
kricka
04 Nov 2016, 19:36
Protect the trading account
A "technical error" revival on this thread maybe. Errors do happen and for different reasons. For any trader with real money placed in positions, there has to be an external protection if something goes wrong with the basic position stop loss at the brokerage server. A VPS server is an excellent overall protection that can be used if the stop loss for some reason is not executed from the broker side. Read more here: VPS Server
An account protection is vital regardless of how many positions are in place. Visit the RMMRobot.com site for more information on this so important subject, how to protect the trading account.
@kricka
susantasaren
16 Jul 2013, 16:39
Its look like you are trying to straddle during news event. I have experienced "Technical Error" during News event with many brokers.
@susantasaren