Basically, this circular distinguishes 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. Only thing that changes is API users will have to acquire a static IP if they don't already have one and get it whitelisted with broker. We'll make changes to the Developer Console to accommodate this.
Only thing that changes is API users will have to acquire a static IP if they don't already have one and get it whitelisted with broker.
@Matti I don't get the logic. Why does the regulator need the user's IP address if he doesn't want to place an order? Data analysis and order placement are totally different. Data analysing, we do the computation with our PC, which is very private and doesn't require any regulation, but placing an order is under regulation. Though there is already a strict order limit with all brokers' APIs.
The truth is that the broker already knows who made the order. However, while we place the order, the broker receives all user information, why they also require IP. The logic behind the IP is to know who is placing the order, right? So the broker has all information of the user.
Anyhow, I don't think this logic is very smart. Whatever we do, the computation is totally under our privacy; nobody can regulate that process. So the broker has to specify in the console whether the user needs tick data or tick data with order placement; if the user wants both, then he has to mention his static IP. The new static IP is an extra burden for the poor retailers. Now, regulation is like a double-edged sword! After all, "regulations" mean that only the regulator remains in the market.
I don't get the logic. Why does the regulator need the user's IP address if he doesn't want to place an order? Data analysis and order placement are totally different. Data analysing, we do the computation with our PC, which is very private and doesn't require any regulation, but placing an order is under regulation. Though there is already a strict order limit with all brokers' APIs.
The regulations are for order placement. However, analysis and order placement aren't divorced from each other here because the APIs are to the trading platform. For pure analysis and data consumption, you'd need to purchase data from an authorised data vendor. Brokers are only allowed to give APIs to the trading platform, and data just happens to be a key part of it.
why they also require IP. The logic behind the IP is to know who is placing the order, right? So the broker has all information of the user.
Brokers already collect IPs for orders as part of reporting requirements. However, there (are) were people out there who end up sharing their login and API credentials with others who then trade on their behalf. This was basically like a pseudo-PMS service. The static IP requirement is to crack down on such things. Whitelisting IP will also come with brokers requiring to ensure that the same IP doesn't have dozens (maybe more) accounts placing similar orders.
Anyhow, I don't think this logic is very smart. Whatever we do, the computation is totally under our privacy; nobody can regulate that process. So the broker has to specify in the console whether the user needs tick data or tick data with order placement; if the user wants both, then he has to mention his static IP.
As I said above, if the user needs only data, then they are required to purchase it from an authorised vendor.
Brokers already collect IPs for orders as part of reporting requirements. However, there (are) were people out there who end up sharing their login and API credentials with others who then trade on their behalf. This was basically like a pseudo-PMS service. The static IP requirement is to crack down on such things.
I don't think this static IP logic will work efficiently for this specific case. As you mentioned, people who are doing this also know better alternatives. There are a lot of other alternatives, such as building HTTPS or cloud or private APIs. The customer still can access the signal from anywhere; the order only goes from the customer account, so they can do their activity smoother as earlier. Anyway, the people doing this are not technically illiterate.
Implementing this also hurts the convenience of using the API from anywhere in the world. Suppose I use the API in both AWS and PC; should I configure the same static IP in both systems? This is overhead.
Basically, this circular distinguishes 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. Only thing that changes is API users will have to acquire a static IP if they don't already have one and get it whitelisted with broker. We'll make changes to the Developer Console to accommodate this.
The truth is that the broker already knows who made the order. However, while we place the order, the broker receives all user information, why they also require IP. The logic behind the IP is to know who is placing the order, right? So the broker has all information of the user.
Anyhow, I don't think this logic is very smart. Whatever we do, the computation is totally under our privacy; nobody can regulate that process. So the broker has to specify in the console whether the user needs tick data or tick data with order placement; if the user wants both, then he has to mention his static IP. The new static IP is an extra burden for the poor retailers. Now, regulation is like a double-edged sword! After all, "regulations" mean that only the regulator remains in the market.
Implementing this also hurts the convenience of using the API from anywhere in the world. Suppose I use the API in both AWS and PC; should I configure the same static IP in both systems? This is overhead.
What would happen if a single API user has multiple static IPs for redundancy. Would that case be handled as well?