We need few words from @nithin
1 Like
In this circular they mentioned there will be no Open API allowed, APIs will be client specific what does it mean?
What I understood is there will be no open API from brokers side what we use now for our execution. @nithin please post your thoughts
So i was talking with a friend and he made a valid point.
Blackbox/whitebox is only wrt user vs algo provider. There is no mention of what is the process to get algo registered with the exchange. It is possible that SEBI expects algo to be fully disclosed to exchange and that will suck big time and make this impractical.
I have also heard from multiple places that in the existing algo registration process, people do not disclose what they actually do, atleast not with details. They may or may not be following process but if broker expects 100% disclosure then independent retail will get discriminated against.
I hope that âEmpanelmentâ wont be required for us and so the requirements will water down. At best i can disclose where i execute with what kind of orders in general terms.
It would be crazy for regulator to call blackbox algo proprietary and then expect disclosure. Once disclosed there is no way to know with certainty that it leaked other than seeing algo work worse or have competition for entry in same area and in my case target markets arenât that liquid (and so slippages spike up).
So, as per my understanding.
- Open APIs for savvy traders should be possible. But yeah, through static IPs to validate. I think we should be able to continue offering Kite connect APIs.
- So people who rely on others for Algos, that is a little grey. They expect the brokers to validate a strategy through which an order is placed, and that strategy has to be registered at the brokerâs end. So essentially, the Algo has to be run on the brokerâs system; I donât know if this is possible.
3 Likes
Algo will need to be registered against exchange as per draft. I hope Zerodha is quick to implement this.
What kind of info is expected ( from independent traders) ? Does SEBI expect complete details of the algo ?
I get the feeling that it wont be necessary from your answer but its not explicitly mentioned in the draft. Nothing is mentioned beyond one para so its not clear which requirements overlap for us.
I guess static ip requirement is here to stay. Never had one, now i will need to see how to do this for both primary and backup network connection. All providers give dynamic y default. Ideally want to be able to move about too.
1 Like
We will seek clarity from SEBI on this.
1 Like
But IPs are usually dynamic through most Internet providers
1 Like
Hope they donât expect full algo details, else it will become impractical, esp for someone like me who trades in stocks intraday and liquidity in some stocks can be a bit tight.
No way i can disclose algo completely beyond say generic overview and hint of execution areas.
1 Like
yeah, i am no expert at this. One way seems to be via VPN. But this will add an external dependency and probably will also lead to delay. If VPN goes down, then we get in trouble.
Dunno, will need to check best way.
Still since they will give us algoID and that algoID will only work in my account why would this be needed ?
If its really needed, a better option perhaps would be to allow dynamic ips and say max 5 ips per day against each algo id. This would allow us to use backup internet and restart internet with some room to spare.
or run it in a VPS with static IP (which I dont want to do). That way one can access anywhereâŚ
One thing that this circular does is distinguish between algo orders and API orders. If the order rates are within a prescribed order-per-unit-time threshold, they wonât get tagged as algo even if they come from APIs. And algos need to be registered, not API orders. For most retail APIs, broker risk management rules already have these limits in place, so this shouldnât be a problem.
Why? This is so only algos that are bypassing some RMS parameters need exchange registration while others (most retail ones) remain exempt, making it feasible for people to use APIs.
But ISPs also provide static IPs. Users may have to purchase one. This is a compromise to allow APIs while ensuring origin of orders is always known. Better than not allowing APIs. 
3 Likes
They wonât. Thatâs the point. If youâre using regular retail APIs, you wonât need to register algo at the exchange, but youâll need a static IP instead.
2 Likes
Any idea on what this is, some kind of range ? I send orders in bursts, so in one second i have set a limit of 20. 2-3 times a day, on a very volatile day, i may get close to that today.
ok, i did not get this impression from the circular, but this is great if true. I thought it was an additional rule.
ok, will need to figure out best most stable way to get static ips, esp because we need redundancy too and no delay and ideally we should be able to move about.
I donât think mobile internet gives out static ips. Lets see, maybe someone who has experience about this can post something.
Maybe shifting to aws type servers will work for this ? Dunno
- Ideally, they should allow multiple ips as we will need backup internet
- There should be easy way to change ip if something changes ( obv not everyday).
Yet to be determined.
Will depend on implementation, but backup is always the trading terminal broker offers.
Again, will depend on brokersâ implementation, but isnât disallowed by the circular.
2 Likes
ok i see this now. This is great if they allow some reasonable max limits for order aps, say even 10 should be fine.
All orders, above the specified order per second threshold2,
originating/flowing through Application Programming Interface (API) extended by brokers to their clients/service providers, shall be treated as
algo orders and shall be tagged with a unique identifier provided by Stock
Exchange. This is in addition to orders already tagged as Algo orders.
Brokers shall:
ďˇ ensure that they have systems and procedures in place to
detect/identify and categorize all orders above the specified
threshold as algo orders;
ďˇ not permit open APIs and allow access only through unique vendor
client specific API key and static IP whitelisted by broker to ensure
identification and traceability of the vendor and end user
Check aws ec2 t3a instances that would be good with elastic ip
2 Likes
Why is sebi concerned about overall order per second limit? If they are really looking to prevent things like flash crashes, they should be restricting it on a per symbol basis.
Algo providers will have high requirements here.
So they will either need to comply to get higher per second limits, or they will need to have a distinct static ip for each customer and call apis through these. Dunno how feasible that is.
Perhaps this will also allow them some sort of audit trail ?
I still donât understand why they donât go after tradetron if tradetron broke rules.
Most of your existing ISPâs will give you a static IP, for an extra payment. You can even convert your residential plan to an office or business plan that comes bundled with static IP. Just checked Airtel and Jio.
If your phone is on the same WiFi, then it will have the same external IP, as will all the devices in your house that are connected to the same router. So you should be free to move around.
Right now, if your internet goes down, you can connect via your phone thru mobile internet. However, this will give you a different IP. So, in this proposal by SEBI, your internet backup plan fails. I donât know if a trade which was initiated by an algo can be closed by calling Zerodha in this case.
IDK WTF SEBI is thinking about, wanting static IPâs. Next they will want a live video feed to run via facial recognition to ensure itâs really, really you⌠Isnât 2FA enough to establish the owner of the account?
1 Like