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.
@Matti@nithin Yeah, I understand SEBI wants to make this segment organized and protect from frauds. But they also have to look at the unnecessary complications they are adding to the system.
Think of a scenario like this. There are 4-5 friends who understand a strategy completely and run it in their accounts through shared aws lambdas and cron triggers . As of now they don't incur any costs or manage complex network related things which makes it easier for them to trade and focus on strategy rather then tech side of stuff. Once these regulations come in there will be tech overhead and significant changes too right.
Also if the purpose of static IPs is to track orders, there can be better ways like combination of API_KEY, client_id, timestamp, PAN of account holder etc etc. As @ANL suggested, brokers should listen to suggestions from their users, before agreeing to bigger policy changes for the markets
It's a huge step forward when prices were reduced from 2000/- to 500/-. Might I suggest to reconsider our earlier discussion https://kite.trade/forum/discussion/comment/47284. If all API endpoints could support this then maybe it allows for a long term solution?
Cloud providers currently have to continue to keep the current prices or even potentially increase them
A general example showing an elastic IP being used/idle throughout for 24 hours and 30 days (0.005 * 24 * 30) * 85 * 2 = 611.9999999999999, having a redundancy of 2 IPs, already goes up beyond a month's worth of API charges, whereas with IPv6 the charges from clouds do not apply
Side Note: The pricing above does not apply to me(With or without IPv6, I welcome the pricing change), since I intend to use Kite only for streaming purposes for now. ((0.005USD/hour * ~6-12 hours * 30 days) * 85INR/USD) = 76/152 INR monthly on IPv4 usage
@ANL@sahilMn I agree with you on the need for having everyone heard, but there are limits to what we can get done. There was an extensive consultation process before these norms were published, and these concerns were indeed aired at the time. However, the regulator felt the additional cost was an acceptable trade-off to allow retail APIs. Without this, retail APIs weren't even on the table.
brokers should listen to suggestions from their users, before agreeing to bigger policy changes for the markets
We did. There was extensive consultation and this is the result of that.
"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.
Think of a scenario like this. There are 4-5 friends who understand a strategy completely and run it in their accounts through shared aws lambdas and cron triggers . As of now they don't incur any costs or manage complex network related things which makes it easier for them to trade and focus on strategy rather then tech side of stuff. Once these regulations come in there will be tech overhead and significant changes too right.
Also if the purpose of static IPs is to track orders, there can be better ways like combination of API_KEY, client_id, timestamp, PAN of account holder etc etc. As @ANL suggested, brokers should listen to suggestions from their users, before agreeing to bigger policy changes for the markets
Side Note: The pricing above does not apply to me(With or without IPv6, I welcome the pricing change), since I intend to use Kite only for streaming purposes for now. ((0.005USD/hour * ~6-12 hours * 30 days) * 85INR/USD) = 76/152 INR monthly on IPv4 usage