Margin Update Delay at Zerodha & Dhan - Ongoing conversation

Product Feedback 🗣️ Margin Feedback ⚖️📊
1

As an AP of Dhan I have clients coming from zerodha who were flagging order failures at Dhan due to margin availability issues (me included). The specific scenario is this

If we close a position that blocked margin and try to open a new position that blocks margin, the new order fails if there is not enough margin to hold both the first and second positions together.

Today I did an experiment to check margin update delay at zerodha - Open a position with funds just enough to hold a margin blocked position. Then set a basket order to close that position and open a new position (margin requirement same as orginal position). Execute it and then we can see if an order leg fails due to margin update delay.

Zerodha order also failed. This means if we don’t have sufficient funds to hold both open and closed position then it will fail in both Zerodha and Dhan. This happens if orders are sent fast in sequence without respecting the margin update delay between orders.

In short the inference is that Dhan is not having any excessive margin update delay issue (atleast now with all the recent upgrades to infra and bug fixes). Margin update delay is under 55ms at Dhan.

@PravinJ @Alok_Pandey @Naman apologise for not testing with Zerodha earlier. Appreciate your patient support on this issue thus far.

@VijayNair @Castelinojason guess we can now rest this case.

3 Likes
3

Oops accidently put limit order in zerodha basket. It’s been couple years since I used zerodha. Didn’t hit me till you pointed that out @BNF_japan. Nice catch !!!

I stand corrected. Zerodha orders went fine with market order set for both legs in basket. @PravinJ @Alok_Pandey @Naman pls look into how Dhan can execute the orders without failures in the scenario mentioned.

3 Likes
4

Dear @t7support,

Thank you for sharing your detailed insights on margin update behavior in the thread. We appreciate your efforts to dive deep into this topic, and we conducted a similar exercise with the other broking platform’s front-end (web) and also via their APIs to better understand the scenario you described and our own attempt to understand the behaviour.

Here are our observations:

When replicating the scenario using other broking platform’s web frontend with basket orders, we noticed the orders were successfully executed, but there was a slight delay between the placement of the two orders. By examining the order numbers, which follow a running sequence, we observed a difference of 7 orders between them, suggesting that the platform processes orders sequentially, ie wait for one order to execute and then sends another one, or adds a delay in between the orders to ensure the scenario does not happen - it could be either of that, we cannot comment on same. Post that, tested the same scenario via that platform’s APIs, the orders were rejected once again due to margin validation, likely because we sent both orders simultaneously, resulting in rejection of order.

While we cannot comment on other platforms; at Dhan - we are committed to empowering traders with a seamless and efficient trading experience. Our platform, DEXT by Dhan, is designed to be fast, reliable, transparent, and truly made for trade. We understand that our role is to take the order from our users and send it to the exchange as fast as possible for execution, without any delays being added / or any additional processing. We ensure that our frontend platforms leverage the same APIs and technology infrastructure published at dhanhq.co, maintaining consistency and trust.

Our core belief is that when a customer places an order, it should be sent to the exchange immediately for execution without any platform-induced delays. This approach allows DEXT to deliver rapid order placement, ensuring traders can capitalise on market opportunities in real time.

We also have detailed videos about this behaviour, we would be happy to take you through them over a video call and assure you that our platforms, APIs and DEXT works seamlessly as they are supposed to be.

Thank you.

5

Thanks @hardik for the time spent again on investigating the issue I noted.

DEXT is fast The execution speed achieved via parallel order flow is quite good. But users tend to frown upon order failures rather than on few extra tens of ms delay which may not even get reflected on the user order timestamp (min interval = 1 Sec). Also many active traders I know load positions ultilising close to the available margin and so they have to unload an existing position to open a new position. But when they do so in Dhan via basket orders, reverse tap orders, TV webhook orders, API orders etc they fail.

My suggestion to overcome this issue without affecting the overall parallel order flow in Dhan is this.

For TV Webhook / API orders user can control the order firing delay in script. Dhan doesn’t need to do anything here.

But for Basket Orders and Reverse tap orders please respect the order sequence and add 55ms delay between orders if that is the delay for margin updation after first order execution. Dhan can even consider giving user the control to select between the parallel or sequential flow for these order types.

Please consider this.

1 Like
6

Hi @t7support Request you to view it from our side.

Please note that this is an exception behaviour, as I mentioned earlier - taking a chance. For such exceptions, which usually are <1% of all rejections we cannot add a delay between orders. We nearly do anywhere from few lac orders everyday via group scenarios - to manually add an delay to all such orders, wouldn’t make sense at all.

All this while we continue to review the situation from a view that - DEXT is not working or has bugs that causes orders to fail - which is not at all a case. Now to solve a non-existing problem we cannot add delay to orders. We process ~40% orders now in <10 ms, and ~90% in under 20 ms. Adding a delay - just isn’t the solution that we will ever consider.

Morever, i feel it is very odd for any broking platform - not just Dhan, but anyone to induce delays in orders as @Hardik mentioned above. This may lead to slippages which may negatively affect trader’s profits or losses - even if the trader may or may not notice the same.

Hope you understand our view. Dhan, its platform, and our transaction engine DEXT works and has continued to work seamlessly at all times.

7

@PravinJ Please view it from our side. When we line up orders in basket, and even with Reverse tap orders, it is with specific purpose (often) - which is to execute them in that (expected) order, and honestly with all due respect, this is common sense and intuitive behavior many would expect.

Seriously, margin is a precious commodity for OS, especially now when margin requirements have gone up.

Also, its been a while since I have sold options on Dhan (due to obvious reasons), and I hope now the margin issues dont happen when a delay of 1 sec is given via the API.

8

While I understand that margins is important, for an exception case we can’t fundamentally agree to add a delay in orders.

Honestly this is a broker induced delay - so may be wrong even from a regulatory perspective. It simply means that some system is reading trades and then adding delay., its something we will never be aligned towards even if other large broking platforms may be doing it.

Margin issue, as we have mentioned here are non-existing. It was a perception, and DEXT worked seamlessly even before and even now. Infact much much faster than the other platforms that we benchmarked against when we did this exercise.

9

I dont think other brokers are adding delay. They may be executing orders one after the other when the user places them in a basket. That is how baskets work on most platforms.

I dont think people want all orders in a basket to be thrown in all at once, definitely not sellers with complex positions.

10

First of all delay was just a possible solution that I suggested. If it cannot be done so be it. But does Dhan have another solution for this problem ?

Its not just the clients I brought to Dhan from Zerodha complaining. I have seen order failure posts in this community too from other unrelated users due to the same issue.

As things stand now Dhan is saying either

  • don’t use basket order / reverse tap order or
  • if your capital is X then don’t block a margin more than X/2 if you have to close the X/2 pos and then open another X/2 pos or
  • if your capital is X then bring 2X if you want to close and open a position worth X or
  • be willing to monitor the basket order / reverse tap order failure and then place a repeat order.

As margin requirements have now gone up there is extra strain on available margins. Orders may fail and traders may not notice. It has happened to me also multiple times. While I have spent the time to report, document and follow up this issue, I have seen other users migrating their orders away from Dhan…:grimacing:

1 Like
11

@PravinJ ,

So, how much would be the impact on the performance if we try to measure it after doing chages to accomodate these requirements?

Let’s say it’s been asked by SEBI to all brokers to implement a solution to reduce the margin burden on the traders, will you still say NO to SEBI?

Is it worth giving a try and see?

13

None, if Dhan allows basket orders to be executed like they are elsewhere in the broking industry, or allows an option(choice) to execute one after the other (apart from all at once default behavior).

Can you explain what you tried?
@t7support has also verified that basket orders often fail at Dhan whilst being accepted by ‘another’ brokerage, because Dhan doesnt respect the order sequence in the basket.

Here are the steps:

  1. Have an existing Short Option position (Sell CE or PE)
  2. Now in the basket, put in an order to sq off the existing Short CE/PE and then another order to set up new Short CE/PE.
    Above basket will often fail if you dont have enough margin to hold 2 short options positions.
14

All this is genuine feedback and not blind criticism.

I and @Castelinojason are in @t7support’s very small Discord group and together I and Jason execute 6000+ orders a month across brokerages. We both have largely stayed away from Dhan (still use for low frequency strategies) because of the platform’s pecularity.

My main issue with Dhan was the margin updation delay (not always) even after giving a delay of a sec between successive API orders, and @t7support has assured me that this problem has been solved, though I am still wary (seeing the way Dhan handles baskets)

2 Likes
15

Should it be called a consistent feature if it works for one user and not for others?

We’re discussing about consistency across users, whether they place orders manually or through automation.

16

This is a well documented and tested problem. It is also replicable with near 100% chance of order failure.

We cannot open a margin blocked product position after closing an open position unless the margin available is sufficient to hold both the open position and new position if both orders are sent fast one after the other (like it happens in a basket order or reverse tap order).

The problem is also unique to Dhan. Ironically parallel processing done for speed advantage is causing this. Instead of ms we are forced to spend seconds in noting the error and taking corrective action. Sometimes we fail to notice and take a hit on our account too.

2 Likes
18

View point 1:
This captures the risk we mention in the best way, to induce - means tracking trades and adding a decision factor if we should add a delay or not. It results in losing precious time, however little this means.

Fundamentally, we are blind to your trades. As long as customers are meeting all exchange parameters for trade, our job as an platform is to execute your trades as fast as we can; and not to see what you are trading in or what your strategy is.

View point 2:

We process ~40% orders in < 10ms, ~90% in under 20 ms. Adding a delay of 50ms to space this trades will mean that our average speeds will be 60ms to 80ms. Still 2-3X faster, but this is done to manage possibly less than <0.1 % of all our rejections.

View point 3:

Yes, may be right or may not be. We just noticed the running sequence of orders and they were not in a sequence. Same via an APIs, were rejected. Just stating what we noticed.

View Point 4:

SEBI / Exchanges has guidelines for this already @hachiko. We adhere to that - Margins should be upfront for the trade. Brokers should not interfere with order flow.

View Point 5

Yes @t7support @VijayNair It is a valid feedback and that is what got us digging as it bothered us a lot. We are just mentioning that there is nothing wrong with order / margin processing at Dhan with DEXT. Our systems work perfectly and seamlessly.

The conversation on this started with @t7support sharing feedback that he was disappointed when our team suggested adding a delay in processing the orders, to now when @t7support suggesting we add a delay. We came a full circle :slight_smile:

1 Like
19

From the customer side it is not working relative to other brokers we have traded in the specific scenario noted. Like I mentioned the order failure in the scenario mentioned is causing us to spend extra seconds to execute failed order again. Sometime we miss and lose money as well.

The order rejections may be <0.1% because traders migrated orders back to other brokers after facing issues with Dhan. Obviously they are not going to keep punching in orders to see failures. Almost all active traders will note this problem now or later and I don’t think they are going to like it.

Just need a solution to the problem - with delay, without delay, serial mode or parallel mode is ok as long as it is working for us.

2 Likes
20

So true.

Common knowledge, but a good time to post this :wink:
Survivorship bias is a type of sample selection bias that occurs when an individual mistakes a visible successful subgroup as the entire group . In other words, survivorship bias occurs when an individual only considers the surviving observation without considering those data points that didn’t “survive” in the event.

image
image1200×894 93.9 KB

One of the most famous illustrations of survivorship bias comes to us from Abraham Wald, a famous statistician known for studying World War II aircraft as part of his work at Columbia University. When Wald’s research group attempted to determine how war bomber planes could be better protected, the group’s initial approach was to assess which aircraft parts had incurred the most damage. After identifying areas that were in the worst condition, they would then reinforce the aircraft with more protection in those locations. However, Abraham Wald noted that the aircraft that were most heavily damaged were the ones that had not returned to American bases—in other words, the ones that did not survive.

1 Like
21

Introducing a delay in order execution is neither an acceptable nor an advisable solution—I am absolutely certain of that. Speed is paramount, as it minimises impact costs.

In my view, this issue can be effectively resolved through the implementation of a retry flag.

If Dhan provides a flag for API and webhook orders, then setting the retry option to True would enable the system to automatically attempt to place the order again if the initial attempt fails.

22

Mine is around 3500. Remaining is yours. :sweat_smile: when I started moving funds to Dhan I kept around 20 percent funds with Dhan and balance with Zerodha. Now it’s less than 10 percent.

Two reasons.

  1. Basket order failure
  2. No mutual funds pledging for corporate accounts.
1 Like
23

Hey @PravinJ ,

Let’s see following two scenarios where two Dhan users want to reverse their positions:

  1. One user uses “Reverse Position” feature available through TV interface and it works perfectly fine.
  2. Another user does similar thing but he doubles the quantity manually (or through API or Webhook) to reverse the position, and he gets required funds insufficient error.

So, did Dhan break the upfront margin rule while serving the user one?

Can Dhan think some kind of solution to serve both of its users?

@t7support ,

Please feel free to share your comments from this viewpoint.

1 Like