Yes , we are asking exchanges to push the deadline.
2 Likes
Also need a way to test that all is working, before deadline.
Don’t want issue on day 1.
This is a request for sandbox or dry-run api mode.
It was requested earlier but it didn’t get a positive response.
1 Like
No i only meant for static ip, to get some idea that once registered, api calls are working in a compliant way instead of finding there is an issue on Day 1.
@siva please also describe all the client-side limits that a retailer needs to adhere to as per page 13-14 of the attached pdf, so that the constraints can be baked into our systems and we don’t pointlessly shoot orders which violate some limit and will be cancelled by your RMS.
I understand you can’t disclose your entire RMS but if you disclose the client-side limits, we can incorporate into our rate limiting and will both free up resources on your end and lead to better order placement success on our end.
If they are dynamic limits, please consider making those client-level risk limits available through the API instead of buried in some forum post.
Detailed Operational Modalities_Retail Algo.pdf (308.9 KB)
1 Like
@siva Are you going to tell us today? Or you guys need more time?
I really need a way to register my algo to bypass the 10 OPS limit! I have very valid reasons for it.
We need more time.
This definitely can’t happen before 1st, as registration itself will take time, but lets see what reply we get, accordingly we will update.
1 Like
Will you be able to handle the static ip registration process before deadline ?
NSE was really really late here, hopefully SEBI will give more time to everyone.
Don’t think so, waiting for reply.
That’s concerning. Could you please clarify the following questions?
-
If the deadline isn’t extended, will you completely stop accepting orders via the API because of the inability to handle static IP registration for sometime?
-
In the future, do you plan to increase the current limit of 10 orders per second (OPS) for a single API upon registration? Currently, the limit is 10 OPS per API, but it’s possible to bypass this restriction by using multiple APIs. Are you planning to maintain the 10 OPS limit indefinitely, or will there be an increase for registered API and upto what limit?
Please answer these questions to the best of your current understanding, so that I can adjust my code accordingly as soon as possible. I understand plans might change, but I’m looking for your current position at Zerodha.
Thank you, @siva
1 Like
- In the future, do you plan to increase the current limit of 10 orders per second (OPS) for a single API upon registration?
Zerodha does not set that limit. It’s up to whatever SEBI feels like doing in the future.
Currently, the limit is 10 OPS per API, but it’s possible to bypass this restriction by using multiple APIs. Are you planning to maintain the 10 OPS limit indefinitely, or will there be an increase for registered API and upto what limit?
I asked that already, apparently the 10 OPS is at client level, not api_key level. So can’t just buy a new API for higher OPS.
If you want me to be frank we have not yet thought of that, waiting for response.
To begin with we will stick with under 10 ops per sec, in coming days we may relax that and go for registration for above 10 ops, but not sure on this.
For that you need to open another account , maybe from your close family and use another API, this 10 ops is at account level, above that one need registration of algo which we are not taking up initially.
@siva
How will the 10 OPS limit be implemented? Will it be the same as Zerodha’s current 10 OPS restriction? NSE mentioned “10 orders per calendar second”—could you clarify exactly what this means?
I see two possible interpretations:
Method 1:
Allow up to 10 orders within any rolling 1000 milliseconds.
Method 2:
Allow up to 10 orders in each separate calendar second, regardless of milliseconds.
For example, 10 orders at exactly 09:15:01.99 and another 10 orders immediately afterward at 09:15:02.00. In this case, a user could effectively place 20 orders within just 0.01 milliseconds because the two sets fall within different calendar seconds.
Could you clarify which of these interpretations is correct?
2 Likes
If a static IP is registered for an algo…
Will I be able to operate the algo from public IP or any other company network if I am out of home?? Algo is on AWS @siva if not what to do in that case ?? @siva
This is correct. But this also means that you’ll have to wait for 9:15:03 to place the next order.
Yes.
As long as the order comes to us from the registered static IP, how you interact with the algo won’t matter.
1 Like
Which calendar second is used? Is it exchange calendar second? Is it zerodha’s second?
I am asking because I may send an order to Zerodha at 09:15:01.98 and Zerodha may send the order to exchange at 09:15:02.01 ??
So will the order be counted for which second? 09:15:01 or 09:15:02?
2 Likes
How will I get my register static id of algo? I have an algo which third party coded for me in form of software …it runs on aws platform instance @Matti @siva siva ?
[quote=“KD61, post:34, topic:181989”]
Allow up to 10 orders in each separate calendar second, regardless of milliseconds.
For example, 10 orders at exactly 09:15:01.99 and another 10 orders immediately afterward at 09:15:02.00. In this case, a user could effectively place 20 orders within just 0.01 milliseconds because the two sets fall within different calendar seconds
[/quote]
This is correct. But this also means that you’ll have to wait for 9:15:03 to place the next order.
@Matti That’s surprising. As @KamalChhirang pointed out, the clock at client-end and at the broker and exchange can have slightly different calendar seconds, which makes accurate rate limiting while shooting orders unnecessarily difficult if not impossible.
@KD61 's Method 1 (Allow up to 10 orders within any rolling 1000 milliseconds.) - makes much more sense. For rate limiting we can simply assume that there is a relatively consistent transmission time between client - broker - exchange and shoot orders accordingly instead of having to guess the broker’s and exchange’s calendar second.
Personally, I prefer the calendar-second clock. With the rolling 1000ms approach, we need to track the last 10 orders placed. Even then, we’re never completely certain whether our order will be executed after the 1000ms mark,
For example after 1000ms from first order, our 11th order can get rejected because it’s possible that the first order took longer to reach the broker or exchange than the 11th order.