Hi @hachiko Margins will be upfront required for all trades, at all times - so on both the cases. Reverse feature that Dhan provides exits the first order, and then executes the next one. It is designed to work in that sequence. No breaking of any margin rule here.
The post title is now misleading… and it seems we drifted a bit from the context. There is no margin delay on Dhan + DEXT works seamlessly & much faster + the other platform in discussion seems to add / induces a delay in between trades., something we are not comfortable with.
This will often fail too for Fut, unless user has 2x margin (accounting for both positions). ‘Reverse Tap’ will be fool-proof only if the opposite order is placed after completing first order.
I trade very less in Dhan nowadays, and do it with effectively 2x normally required margins, so I dont face the issue. I use it for low freq OB and Fut based strategies where I use less margin (smaller leverage), so I can afford to do that.
90+% of my brokerage goes to other brokers (for OS strategies) that meet my needs.
Dhan is sub-optimal (or just the way it is designed) for a section of people (imo a section with potential for large # of orders), and if you ask @PravinJ he will probably say Dhan is too fast for that group of people
Nope. Out of context. That is not what it really means.
I suppose you do not take leverage, but that is not how many employ derivatives. Infact for Fut, I only employ 1:2 or 1:3 leverage, and even at that size ‘reverse tap’ will not fail. But for OS(which often are at high size in terms of contract value) and higher lev Fut (which I do not recommend), there can be executional roadblocks using Dhan.
Again completely utterly out of context. We are talking about leverage employed and ‘relative margin’ usage in terms of muliples - thats it.
Margin usage is relative to size and can be big or small.
Section of people I was referring to are those who use high frequency OS, that’s it. 1 lot or 100 lots.
Thank you. I hope I do not have to clarify this any more.
Dhan executes ~40% orders in < 10ms, ~90% in under 20 ms. Margin update delay is 55 ms. So a reverse tap order or basket order even if it is sent in sequence will fail.
Assume that we start at t =0. Then the first order gets executed at t = 20 ms. The next order is now sent for execution, but the margin released is not yet available. It will be available only at t = 75 ms. So the order fails if there is not enough margin to hold both positions.
@thisisbanerjee this being the case, if you can share specifics or even a video where these are clear it would be helpful.
Margin available before taking the trade
Margin blocked by an open position that you are going to close
Margin requirement for the new position
Platform from which orders were fired (we tested using Dhan main mob app, Web App, Api and TV webhooks)
It is simple… Normally brokers are expected to understand the importance of margin updation keeping pace with orders; for Dhan only speed of order matters.
Dhan should try to be like Dale Steyn, synergy of important qualities, instead of being like Shaun Tait (wonder if youngsters heard of him ), fast and furious… just throwing them in fast fast fast…
@VijayNair Margins we understand, and we have received severe criticism from our users in our journey as we optimised for all cases that are genuine and in-line with the user’s interest as well as being compliant. We have made all those scenarios as we built our own trading engine and even today we keep optimising this as and when we do come across genuine feedback and suggestions.
Our view on this is as a broking platform, we do not want to read / interpret trades of users and based on their strategy induce delays in them. It is plain and simple, and with that we adhere to all regulations and guidelines for an execution only platform. It is matter of principle.
Additionally, we mentioned that this is probably less than 0.001% of all errors we encounter - as this is just taking a chance with execution. We spent months on this thinking it was an problem on our end and when we check in the mentioned platform - it problem existed on them as well, for 100% of time.
Interestingly, when we said and proposed the solution to make the trade work was to add a delay between transactions to make the trades happen - it was not acceptable. Now the same solution is being proposed to us, is to add delay in our trading system.
This is being misunderstood @t7support, let me clarify. Next order is sent to exchange immediately. There is no margin delay of 55 ms, the margin release is instant when the trade is completed.
The same we mentioned when we debug the trade logs for your orders. The margin was not available because your earlier trade was in-execution, and the second leg was sent for execution. Hope this clarifies.
In case of reverse order, first order is executed and instantly next goes for the user-case of @hachiko. There is no delay of 55ms for margin update.
We are releasing Iceberg Plus soon to all users. DEXT has executed 100 orders end-to-end under 600ms to 750ms., average time taken to execute per order is 6 to 7.5 ms. No margin update delays. We will share details on Iceberg Plus soon.
If margin release and reflection on client account is instant then it is great.
I trade with highly liquid Nifty ITM options close to the spot via market orders. When it hits the market it will instantly get executed. But the problem we noted almost always happens because margin is not available.
like in this case where it took about 55ms for the whole process to complete and as the sequence of order legs is not respected in a basket the other order failed.
Is this the way reverse order was always set ? Because we tested reverse tap orders also and it was failing due to insufficient margin. After order failure, we do a repeat order, it goes through then.
The error % may be 0.001% 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.
There is no need to read client trades for adding a delay. Agree, staying compliant is important. Also, like I said earlier the problem we noted can be handled in client-side code for TV webhook and APIs. However, basket order is a different case, as it fires from the Dhan platform.
What other brokers do is that they respect basket order sequence set. If there is a use case for parallel execution of basket order that was noted from Dhan client base please give a preference option for the client to select parallel or serial execution of the basket. In the basket order settings a user definable delay option can also be added. It doesn’t affect other users or order flow from other channels.
A retry flag can also work like @Tushar11 suggested. However am not sure how much this falls into the algo space.
Any other solution to the problem is welcome. A solution to the problem is what is needed.
Thanks. Not sure whether this will sort out the problem here. But as a feature am looking out for this.
