Hi @t7support, as discussed over the call, thank you for clarifying this in detail. We are reviewing this with our team and will update you on priority via DM.
Again, this happened today.
As I mentioned earlier, this issue was fixed previously, but it has started recurring. When a basket is executed via ATO, one of the order legs fails due to an alleged margin shortage. However, I can execute the exact same order manually immediately afterward, which clearly indicates there is no actual margin issue.
Please investigate and fix this permanently. I have been reporting this issue for days, then months, and now years, yet it still remains unresolved.
@Mohseen_Usmani @Naman When the market is moving and I have set a basket to trigger at a specific price, all the basket legs should execute correctly once the trigger condition is met.
This error has happened again where the existing/open leg was closed, but the new leg was not placed. There was no margin issue, as I was able to place the new leg manually immediately afterward.
Please investigate and fix this on a priority basis. This kind of partial basket execution is particularly risky in a fast-moving market.
I can write code and handle these situations through Algo/API mode, but I cannot offer that as a solution to my clients due to SEBI-related restrictions. This is why the Dhan basket and margin execution system needs to be robust enough to handle such scenarios reliably.
Hey @t7support ,
We are checking this.
@Mrunmayi_Vaity It appears that the failed leg may have been sent before the margin was released from closing the open position. We have discussed (Dhan, me and other users) this issue several times over the past year or so. As per @PravinJ , this was supposed to have been fixed, but it seems to be recurring.
Could you please look into this and check whether the order sequence or margin release timing could be causing the issue?
Hi @t7support ,
As discussed over call, we are reviewing this scenario.
Just for the record of the Dhan Dev Team and Customer Support Team:
- The orders in the basket were market orders on highly liquid, near-ATM NIFTY option strikes. So please be assured that they should have reached the market and executed within milliseconds through Dhan’s super-fast DEXT infrastructure.
- I was closing an existing open 23,500 PUT. Therefore, I had a SELL 23,500 PUT as the first leg in the basket. The second leg was to BUY the 23,400 PUT. At the time, the 23,500 PUT had a much higher premium than the 23,400 PUT. Once I exited the 23,500 PUT, I had sufficient funds to buy the 23,400 PUT. This was also proved by the fact that I was able to manually fire the same 23,400 PUT BUY order for 1,300 quantity when I noticed the basket order failure. So there was no actual margin issue preventing the second order from being placed.
- I don’t need to arrange the BUY leg as the first leg. I was closing an existing option position first and then placing a new position. I was not placing an entry order for a hedged option-selling strategy. The correct sequence in this case is therefore SELL 23,500 PUT first, followed by BUY 23,400 PUT.
- Just like Zerodha, simply add a micro-delay between the basket order legs so that the first leg goes first, gets executed, the margin is released, and then that available margin is used to place the next leg when it reaches the market. Problem solved. Dhan already releases the margin almost instantly after the position is closed.
- If someone thinks adding micro-delays between basket order legs will cause noticeable lag for the user, let me assure you that the UI lag in the basket order interface itself is already in seconds. So even a few milliseconds of delay between the legs will never be noticed by the user.
There is no point in sending an order super-fast if the result is an execution failure.
2 Likes
Hey @t7support,
Following our discussion over the call, as explained, your square-off order was partially executed, and the margin was released accordingly. As a result, your buy order was rejected.
@Vaibhav_Lad As discussed, similar to Zerodha, Dhan should consider introducing a small, controlled delay between the execution of basket order legs to ensure that one leg is executed before the next leg reaches the exchange.
DEXT is already extremely fast, and in this case I am placing market orders on highly liquid, near-ATM Nifty options. So even with a small delay between the legs, the basket can still execute very quickly while ensuring the intended execution sequence and avoiding unnecessary margin-related failures.
Once again, I can easily work around this for my own strategies using the API route. However, my clients cannot do that. They have already moved back to Zerodha because of recurring issues like this with Dhan basket orders. Unless Dhan addresses this at the platform level, it becomes very difficult for me to recommend Dhan to them or convince them to move back.
I would really appreciate it if the team could look into this on priority.
Hi @t7support
This has been optimised for basket orders. Let us know if you face such scenario again.
1 Like
Thanks @Naman. Will check and revert.
@Naman, thankfully the market moved, allowing for a quick test. Once again, the order execution failed. I had to manually place the order again, which further confirms that the margin at my end is not the issue.
1 Like
@banerjee Yeh bandhan to pyaar ka bandhan hey, Is Janam ka yeh sangam hey 
He is mostly an aggressive buyer, who frequently rolls strikes on his profitable Long PE/CE positions.
1 Like
Mostly just aggressive buyer like @VijayNair said. For intraday option selling yes credit spreads are deployed and that is where another issue at Dhan hurts - https://madefortrade.in/t/kindly-consider-sell-legs-first-when-exit-all-positions/16076/61?u=t7support
Does Sahi provide Exit selected positions like Dhan ? Does Sahi provide auto trigger execution in Basket Orders like Dhan ?
@Naman further optimization done or pending ?
Hi @t7support
Yes, you can go for it.
I have explained this bit earlier as well. We execute the orders in Basket in the sequence it is placed by the user, whether you are using manual execution or conditional triggers, it will execute in the sequence you have placed. Yes, there is sufficient gap between the two orders sent to exchange.
Still, there maybe the case when the first order sent to the exchange does not execute and second order is sent to the exchange. This may happen for any reason, like delay from exchange in response, pending order at exchange, order rejection, quote que etc.
Alternatively, we have added a new feature for manual basket execution - 1-by-1 Order Execution. When you press this button, your next order will be sent to exchange when the previous order is reached a terminal state. Terminal state includes success or failed.
Here is the link to read more about 1-by-1
I place market orders in highly liquid, near-ATM NIFTY options, so there is virtually no chance of this happening unless there is a genuine issue at the exchange. However, that has not been the case when I have experienced these order failures at Dhan’s end.
As I mentioned earlier, I have not faced this problem with Zerodha, where both I and most of my clients came from before moving to Dhan. This strongly suggests that the issue lies in how Dhan executes the individual legs of a basket order, particularly in conjunction with its margin check and margin release mechanism.
That would not be useful in my case, as I either execute baskets through algo mode using TradingView webhooks or via ATO. In my opinion, simply introducing sufficient micro-delays between the execution of the individual basket legs should resolve the issue.
Even with a 10x improvement in web rendering speed, there is still more than enough latency on the frontend to naturally mask these micro-delays between the execution of different basket legs. So no case of someone complaining about slow basket order execution because of the micro delays either.
@Naman Yet another failure. Again, there was no issue with liquidity, margin, or anything else on my side, as I was able to quickly execute the failed order leg manually through ATO.
If algo traders have to constantly babysit and monitor how Dhan is executing each order, what is the real benefit of using Algo Mode ? This issue is exclusive to Dhan and has forced active traders I know to move out of Dhan back to where they came from.