1. How a trader can deploy his algo on AWS or any cloud service without getting IP overhead.
2. How does a trader overcome issues when he is travelling and runs his algo in different places?
3. Multiple static IPs are required to solve the above issue? Alternatively, can the user change his static IP address before the access token is generated?
4. IP is required only for order placement/modification, so if a user only uses tick data instead of placing an order, will they have an exception for static IP?
Better to address all these issues before implementing.
1. How a trader can deploy his algo on AWS or any cloud service without getting IP overhead.
There will be some overhead. Unavoidable.
2. How does a trader overcome issues when he is travelling and runs his algo in different places?
This is up to the user. However, you're allowed to change the attached static IP at will once a week so such instances are not too big of a hurdle.
3. Multiple static IPs are required to solve the above issue? Alternatively, can the user change his static IP address before the access token is generated?
We'll allow a primary and secondary static IP per app, as provisioned in the circular. Frequent changing of the registered IP will defeat the purpose of prescribing static IPs so won't be allowed.
4. IP is required only for order placement/modification, so if a user only uses tick data instead of placing an order, will they have an exception for static IP?
For AWS user has to again subscribe for ECS static IP to deploy his algo on cloud. Traders will have to spend more money and face an extra hurdle. "Indian users are like a drum; the person who beats the drum gets all of the money, but all beats go to the poor drum. "
@Matti This is a cumbersome process for developers/traders who are using AWS lambda functions or other serverless infrastructure.
Someone needs to raise concerns with SEBI to highlight wider usecases and get rid of such measures, as this will increase management overhead as well as costs for retail algo traders/developers. This is a discouraging move.
Is there a way to get this opinion in front of SEBI?
@Matti Thanks for the quick reply.. do you have any ideas/thoughts on how service providers who send trades on behalf of customers will work with this? will they spin up new servers/containers for each customer they send order for or how will this be managed? What do you think?
Service providers who send trades on behalf of customers are the targets of this regulation. The idea is to not allow for such actors. If you want to send trades on behalf of others, you'll need to get yourself and your strategies approved as vendors and research analysts.
@Matti@nithin Brokers need to listen trader's side and propose the suggestion to the regulator rather than just implement one-sided logic that will definitely harm the trader. There are lots of other approaches to do this without a static IP.
The broker and trader must be aware of an unwritten rule that the regulator should listen to them before going to implement a rule like this. The sledgehammer rule is not a decoration for anyone.
We are living in a democratic country, and opinion is highly valuable here.
"Indian users are like a drum; the person who beats the drum gets all of the money, but all beats go to the poor drum. "
Someone needs to raise concerns with SEBI to highlight wider usecases and get rid of such measures, as this will increase management overhead as well as costs for retail algo traders/developers. This is a discouraging move.
Is there a way to get this opinion in front of SEBI?
@sahilMn There was an extensive consultative process. This is the best possible outcome. The alternative was no APIs.
The broker and trader must be aware of an unwritten rule that the regulator should listen to them before going to implement a rule like this. The sledgehammer rule is not a decoration for anyone.
We are living in a democratic country, and opinion is highly valuable here.