For 2 days in a row i am facing issues from Zerodha unfortunately.
Yesterday there was NSE issue. This we know and it was fixed. This post is not about that.
yesterday my future orders with trigger/limit were rejected. Zerodha has this extra check where they reject orders if they think price has already triggered. Yesterday, all of my future orders were rejected and Z server used PDC as reference price. So ltp was stale in Zerodha server and so they rejected all orders.
Today same thing happened in cash market. All of my cash trigger orders were rejected with PDC used as ltp by Zerodha server. This is within opening couple of minutes.
Now, other than the error itself i really think this is faulty design. I can see the motivation might be to prevent mistakes from newbies in GUI. But why is this also done in api ? And also should you not have an option to override this in both GUI and api ? Problem is that in order to do this, Z ltp basically has to be always in sync with exchange. This obviously wont happen and you will always have some lag. And in something like stock futures this problem is even more apparent because ltp is not correct reference point. It can be stale in exchange too with transaction a minute ago and bid ask may have already moved in response to movement in cash. And ofc, anytime Z server has trouble catching up with price you will have needless rejections.
My code right now assumed that Z ltp is correct and because of this my reponse to this error was also faulty today and i sent orders with pdc as reference. I had to cancel all of them. I will have some workarounds for that which basically will ignore ltp sent by Z server - but you can see this is really a bad fix and if i want to use a trigger order only, then Z server will keep rejecting my orders until they catch up with actual ltp.
Please rethink why Zerodha should act as a secondary exchange of sort and reject orders that have already triggered. Atleast in api there must be a way to override it. This is certainly wrong in stock futures as ltp itself is not reliable.
Also please look at whats happening in last 2 days and get it fixed.
I have a post in Z api forum too for this. I am posting here as well in order to escalate it a bit and also so that you can perhaps rethink on this error design itself. Not sure who to tag, so tagging nithin. @nithin
In one of our silos, there was some issue with feeds the first few minutes yesterday and today. We are working on having this fixed and not repeated.
Bad orders come through both GUI and API. Exchanges hold us responsible for this and hence some sanity checks are in place. Unfortunately can’t do away with this.
Understood and i will try to adapt. But could you give an example on what kind of order with bad trigger price would cause exchange to have an issue ?
From what i can see, worst case of bad trigger price is that the order gets filled immediately. You then learn and correct your mistake but this does not seem to be a risk to me. It can be a feature for newbies, but then we should have option. if multiple triggers causing market impact is the issue, wouldnt we have same with limit/market orders ?
Nest used to pass through such orders and Nest ran for a long time with multiple brokers. From what i know, perhaps mistaken, most other brokers pass through such orders and orders get triggered immediately if ltp is past trigger price. Fyers certainly used to do that, as i had to add logic for this only after moving to Z.
And you can see how this is wrong for stock futures, as ltp can be stale while bid ask has moved on.
Thanks for your time.
Edit - After thinking more on this, if SEBI/exchange has issue with such trigger orders then ideally, exchange itself should reject trigger orders if they have already triggered and exchange can probably look at current state of bid/ask for this. This would be much better vs forcing largest broker to do something which others dont do, that is a bit discriminatory and fix itself is not perfect …
Being the largest broker just adds a lot more responsibility to us. We do go an extra step in terms of risk and compliance. But I understood your problem statement and talking to our team. @MohammedFaisal will follow up on this.