My use case is simple i use api to copy my orders in my parents and wife account to manage tax better will i be able to do this after these changes ?
1 Like
We don’t know yet how this will work.
1 Like
Thanks for confirming.
To be clear, (i also updated my previous post above just now)
one other aspect would be to NOT mandate unique IP addresses across all API users.
Basically, this step must NOT require that
the user specify an IP-address that is already not in use by any other API user.
IMHO, applying such a restriction would be be a step too far,
adding costs and increasing risks for the individual retailer.
(instead of reducing risks, the intent behind the regulation).
Encouraging risk-ier behavior like
- running API clients from a 3rd-party VPS with a static-ip
- running only one session (single point of failure due to any network/power issues)
- running API clients through 3rd-party proxies
Hopefully, the regulators and brokers
don’t want to be remembered as the ones to introduce
the digital equivalent of the Cobra Effect during the British Raj. 
[ Source ]
1 Like
yes, there should be a provision to allow family members ( with proof i guess) to share same static ip with a common order/sec restriction for all of them.
1 Like
I run my trading program for myself and fam from a single DigitalOcean VPS with free uptime monitoring from HetrixTools, I have a script on my local PC to exit all positions if the VPS goes down along with a catastrophic SL order at exchange in case the broker API goes down.
I’m a sysadmin but not really a networking guy, so having to configure a separate interface for each user would be would be a pain and needless cost increase. More complications arise when the VPS goes down and the IP has to be configured in floating mode, assigned to another VPS just to exit all my positions. Whaa… 
But this whole static IP requirement would see peeps sign up with managed hosting providers who has access to all data or setup a server themselves which exposes them to security risks if they’re not familiar with locking it down properly. Not good for anyone IMHO. 
The API token itself should be tied to a single account/user, so there’s really no need to have any other checks like static IP, etc. 
1 Like
When a user consuming the broker’s APIs places an order via the APIs today, it is impossible to determine if the user is using their own discretion to set up a trading strategy or if the user is engaging the services of a third-party service provider to create/deploy trading strategies with a high degree of confidence.
This is the problem statement that led to the static IP restriction. The idea is that it isn’t feasible for someone to set up a single cloud machine running different strategies for users with the user having shared their user ID, password, 2FA, as well as API key and secret. This was actually a rather prevalent practice that is being shut down.
Hi @Matti . what will stop the users to share their credentials post these changes as third party algo sellers will also get dedicated static ip for each user ,which according to siva will cost around 2-3k per year and maybe cheaper for bulk corporate plans. wouldn’t it make all these regulations redundant and just add cost and security risk for the community as a whole as they have to rely on proxy servers if hosting scripts on the cloud.
Also what will happen for people who have hosted scripts on aws . some of them might have have same ip address. How will that be dealt then?
1 Like
The bet is that this is enough of a deterrent for such practices at this point.
Also what will happen for people who have hosted scripts on aws . some of them might have have same ip address. How will that be dealt then?
Hosted apps like this should also be able to get a static IP.
I don’t understand this line of thinking. 
Setting up a static IP for individuals is 10x harder and cost prohibitive than for someone providing algo services, after all the algo provider is getting paid to set this up. IPv6 addresses are cheap and abundant. There is no cost deterrence unless limiting to IPv4. 
Retail traders thrown under the bus again for our own protection 
I understand. But not much else the regulator can do when users end up sharing login credentials. It was either do something where you make it difficult for people to scam and allow APIs with a higher barrier for entry or ban APIs altogether. Banning APIs won’t be well received either. 
1 Like
You guys have a seat at the table, why not tell them (politely of course) that there are times when regulation does not solve a problem 
. When all they have is a hammer (regulation) then that’s what they would use whether the situation warrants it or not. 
This is a losing battle, scammers are just going to scam without using API. Unofficial APIs from reverse engineered front-end requests and just plain old web scraping will be their tools going forward. I doubt the regulator has inconvenienced even a single scammer with this, they probably were doing this all along 
2 Likes
We have already relayed all this.
3 Likes
Interesting stuff!
@Matti @siva Reading through the SEBI circular it doesn’t mention restricting static IP to only one client, only that the IP must be static and registered with the broker.
Relevant part (the only part with any mention of IPs from the document):
not permit open APIs and allow access only through a unique vendor client specific API key and static IP whitelisted by the broker to ensure identification and traceability of the algo provider and the end user (i.e. investor).
Can you clarify if a static IP registered to one client can also be used by another client, especially for individual traders with order rates below the registration limit? 
These details are yet to be prescribed by the exchanges.
1 Like