Under the current framework, API access to an Indian broker’s trading system comes from an IP address you have registered with the broker. Requests from anywhere else are rejected. It is a sensible control — a leaked API key is far less useful without the matching address — and it has one practical consequence: your strategy needs somewhere permanent to run.
Why the requirement exists
Process flow
Two conditions must match before an API order is accepted
A valid credential proves account authority; a whitelisted egress address proves the request came from registered infrastructure.
The strategy signs a request with an API credential and sends it from its public egress IP. The broker first validates the credential, then compares the observed source IP with the registered static address. Only when both checks pass does the broker apply risk controls and forward the tagged order to the exchange. Any mismatch is rejected before exchange submission.
The broker sees the public egress address, which may be a NAT gateway rather than the address shown on the virtual machine.
API credentials are bearer tokens: whoever holds them can place orders on your account. IP whitelisting adds a second factor that an attacker cannot obtain by reading a leaked config file or a screenshot in a support ticket. It also gives the broker an audit trail tying order flow to a known origin, which is what the SEBI framework is ultimately after.
The three options
System architecture
Hosting choices share one independent emergency path
Home, cloud and managed VPS differ in ownership and uptime, but none should host its own only kill switch.
An ISP static IP keeps the strategy on local hardware and depends on home power and network. A cloud instance uses a pinned public or NAT egress address and requires operating-system and security administration. A managed trading VPS bundles infrastructure but adds vendor dependence. Each connects to the broker whitelist. A separate monitor and kill host uses independent infrastructure and credentials to cancel and flatten if the primary path fails.
Choose the primary host for reliability and operational fit. Choose the emergency host specifically so the same outage cannot disable both.
ISP static IP
Cloud instance
Managed trading VPS
Typical cost
Modest monthly add-on
Low for a small instance
Higher, bundled
Latency to exchange
Depends on your city and ISP
Low from a Mumbai region
Usually the lowest
Uptime
Your power and your ISP
Provider SLA
Provider SLA
Setup effort
Low — one ISP request
Moderate — you administer it
Low — provisioned for you
You must maintain
Local machine, power, network
OS, security, deployment
Little
Main risk
Home outage takes the book with it
Misconfigured security group
Vendor dependency
Trade-offs between the practical hosting options
On latency
Latency is the most over-weighted factor in retail hosting decisions. If your strategy makes a decision every minute and holds for twenty, the difference between 5 ms and 40 ms of round-trip time is not what determines your P&L. Slippage from crossing the spread will dominate it by orders of magnitude.
Latency starts mattering when the strategy competes on price for a resting order, or when it reacts to a specific event faster than others. If that describes your strategy, hosting is the least of the changes you need to make. If it does not, pick for reliability.
Reliability
Optimise for this
For any strategy holding longer than seconds
Mumbai
Region to prefer
Shortest path to the exchanges
Elsewhere
Where the kill switch runs
Not on the same host as the strategy
Setting it up without locking yourself out
Timeline
A migration sequence with a safe rollback
Provision and observe the actual egress address before changing the broker whitelist, then test read-only access before any live order depends on it.
Provision and harden the new host. From that host verify the public egress IP. Register that IP with the broker on a non-trading day and wait for confirmation. Test an authenticated read-only request, then an order in a safe environment or minimum size. Observe through a full session while the old path remains available for rollback. Retire the old address only after documentation and emergency access are updated.
Do not combine infrastructure migration, broker re-registration and strategy changes in one release. Isolate what can fail.
Provision the host and note its public IP before touching broker settings
Verify from the host itself rather than trusting the console — NAT and egress gateways mean the outbound address is not always the one shown.
Register the IP with the broker and wait for confirmation
Propagation is not always immediate. Do this on a non-trading day.
Test an authenticated read-only API call first
Fetch your positions or profile. Confirm the whitelist works before an order depends on it.
Restrict inbound access to the host to your own address
A trading host with SSH open to the internet is a much larger problem than a dynamic IP ever was.
Store API secrets outside the repository
Environment variables or a secret manager. Never committed, never in a container image layer.
Document the IP and the re-registration procedure
Including how long it took. You will need this when you migrate, under time pressure.
A reasonable default
System architecture
A small but failure-aware default topology
The trading path is simple; the supervision path is deliberately separate.
A pinned-address cloud host in a Mumbai region runs the feed handler, strategy, risk gate and order manager. It connects to the broker API through the registered primary static IP and persists logs and position state. A second small host in another failure domain runs monitoring and the kill switch with separate credentials and a separately registered address. The operator can also reach the broker web terminal independently.
This topology optimises for recoverability, not microsecond latency. Keep broker-terminal access and the manual flatten runbook usable when both automation hosts are unavailable.
For someone running their own strategy on their own account: a small cloud instance in a Mumbai region with a pinned static address, the strategy and order manager on it, and the kill switch plus monitoring hosted separately. It is inexpensive, it survives your home losing power, and it separates the component that must work under failure from the component that is failing.
An ISP static IP is a reasonable choice if you already have reliable power and connectivity and prefer to keep everything local. A managed trading VPS is worth the premium when you would rather not administer a server at all — just verify that you retain the ability to reach the broker independently if the vendor has an outage.
Frequently asked questions
Why do broker APIs in India require a static IP?
API credentials are bearer tokens, so whoever holds them can place orders. Whitelisting a registered IP address adds a factor an attacker cannot obtain from a leaked config file, and it gives the broker an audit trail tying order flow to a known origin. Requests from unregistered addresses are rejected.
Can I run an algo strategy from my home internet connection?
Only with a static IP, which most home broadband plans do not provide by default — a dynamic address changes on reconnect and silently breaks API access. Many ISPs offer a static IP as a paid add-on. Separately, a laptop is a poor host regardless of the IP question, because sleeping or rebooting leaves open positions unsupervised.
How much does latency matter for retail algo trading?
Much less than usually assumed. If a strategy decides once a minute and holds for twenty, the difference between 5 ms and 40 ms of round-trip time is dominated by slippage from crossing the spread. Latency starts to matter when competing on price for resting orders or racing to react to an event, in which case hosting is the smallest of the required changes.
What is the risk with cloud NAT gateways and IP whitelisting?
On cloud platforms, outbound traffic can leave through a NAT gateway with a different address from the instance itself, so the address you see in the console may not be the one the broker sees. Verify the outbound address from the host with an IP-echo request and whitelist that. Also pin the address explicitly, since a replaced instance may otherwise get a new one and lose API access mid-session.
Where should the kill switch run?
On different infrastructure from the strategy. If a power cut, ISP outage or host failure takes down the strategy, the same event should not remove your ability to cancel orders and flatten positions. That means the kill switch needs its own host, its own credentials and its own registered IP.
The engineering team builds QuaTick’s order routing, market-data pipeline and broker integrations. These pieces cover the parts of automation that only show up in production.