Mechanism
From a first email to your own code placing its own orders
This is managed self-hosting, so the sequence has two halves. We provision and operate an instance that belongs to one customer. You bring the broker account, the key, the whitelisted address and the algorithms. Neither half works without the other, and neither half quietly becomes the other.
Setup
Six steps to a running instance
Each step depends on the one before it. Four of the six are yours, and that is the shape of the product rather than an oversight: what you are buying is somewhere for your own trading system to live, not somebody else operating it.
Sign up
Done by You and us
There is no self-serve checkout, and that is deliberate: an instance is real infrastructure with a real address attached to it, so it starts as a conversation. Tell us what you intend to run, which broker you are with, and roughly what load to expect, through the contact form.
We come back with what the instance will look like and what it will cost. Nothing is provisioned and nothing is charged until you have that in writing and say yes to it.
Verify your email
Done by You
Your account is created against a verified email address, and that address becomes the one thing we trust for the life of the relationship: it is where the instance details go, where incident notices go, and the only address we act on a written instruction from.
Keep it an address you control personally. A shared inbox on a domain somebody else administers is a poor place to receive the keys to a trading system.
Link your broker with your own API key
Done by You
You register a developer application in your own broker’s console, under your own account, and enter that key into your own instance. It is your app, your key, your entitlements. We never create a broker app on your behalf and never hold a credential you did not issue.
That is what keeps the broker relationship between you and your broker. Revoke the key in their console at any moment and your instance stops trading immediately, without asking us, and we cannot restore access without you doing it again.
Indian broker sessions expire daily, at a time the broker sets rather than one we choose. Your instance handles that daily lifecycle; what it cannot do is invent a credential you have withdrawn.
Take your dedicated egress address
Done by Us
We allocate a static IP address reserved to your instance and to nothing else, and every outbound call your instance makes to your broker leaves from it: the authorisation, the market-data subscription and every order.
It does not rotate, it is not drawn from a pool at connection time, and it is not recycled to another customer while it is yours. One address per broker account you connect, because that is the unit your broker registers.
Whitelist that address at your broker
Done by You
You enter the address into your own broker’s developer console against your own app. This is the step we cannot do for you and would not want the ability to: it is a control your broker gave you over your own account.
Until it is done, your broker will refuse the orders your instance sends, and the refusal happens at their end rather than ours. It is by a distance the most common reason a brand-new instance places nothing.
If your broker needs something different, a second address, a different address family, or an address in a particular region, tell us. Reallocating is routine and there is no drama in it.
Deploy your strategy
Done by You
Paste Python into the in-browser editor, or build the logic as a node graph in the no-code builder, or leave the engine as an execution endpoint and drive it over its HTTP API from wherever your signal already lives.
Exercise it against the paper-trading sandbox first, which has its own database and its own capital and cannot reach your broker. Then schedule it on IST times, and consider leaving order approval switched on until you trust it. The feature list covers each of those surfaces properly.
Starting it, stopping it and squaring it off remain yours to do. There is no discretionary switch on our side and we are not going to add one.
Static IP
Your broker will only accept API orders from an address you have registered with them.
Indian brokers require API order traffic to arrive from a static IP address registered on your own developer app, following SEBI's framework for retail algorithmic trading. That is why every instance gets a dedicated egress address rather than sharing one: a shared address would mean whitelisting infrastructure other customers also trade from, and it would break the moment it changed. You register the address we allocate you in your own broker's console, and the registration is yours.
Why it exists at all
Indian brokers have required API order traffic to arrive from a registered address since 1 April 2026, under their own implementation of the framework for retail algorithmic trading. The practical effect is worth having: a stolen API key is much less useful to somebody who is not also on the whitelisted address.
Confirm it with your own broker
Which operations a broker checks the address on, and from when, is the broker's own rule and can change without notice. Confirm the current position with your broker before you rely on it, and tell us if they need something different: reallocating an address is routine.
This paragraph was last checked against broker documentation on 23 August 2026. It describes what brokers require, and it is not legal advice.
Order path
What happens when your strategy decides to trade
Five things happen, in this order, every time. The first one is yours and the last one is yours, and the three in the middle are the part we operate.
Your code
Your strategy makes the decision
A scheduled Python process, a node graph, or an HTTP call from outside. Whichever it is, the intent originates in something you wrote and can read. Nothing in the engine forms a view on a security or decides that now is the moment.
Your engine
The engine turns it into a broker order
The instruction is validated, mapped from the platform's own symbol format into your broker's vocabulary, and checked against whatever limits and approval mode you configured. If approval mode is on, it stops here and waits for you.
Your address
It leaves from your dedicated egress IP
The call is made over TLS from the static address reserved to your instance. This is the address your broker has on file for your app, which is why the request is accepted at all.
Your broker
Your broker accepts or rejects it
The order reaches the exchange through your own broker, against your own margin, in your own account. Their rejection reasons are theirs: margin shortfall, a frozen scrip, a limit at their end. The engine records the response verbatim rather than interpreting it.
Your log
Every step is written down on your instance
The request, the response, the timestamps and the decision in between, in a log that lives on your instance and that you can read and export. Reconstructing what happened at 09:15:04 is a matter of reading the record, not of asking us to look.
No latency claim
We do not publish a millisecond figure, because on this product it would be a number about your code rather than about our infrastructure. How long a strategy takes to decide is set by what the strategy does, and what happens after the order leaves your address is your broker’s API, the exchange and the market at that instant. None of those are ours to put a number on, so we do not.
What we will tell you is what your instance is sized for, in writing, before you take it.
Responsibility
Who does what, in one table
Worth reading closely, because it is the whole commercial relationship. We operate infrastructure. You operate your trading.
| What | Whose job |
|---|---|
| The host, the operating system and the runtime | Us |
| The isolated database, its volume and its backups | Us |
| The dedicated egress IP address and its allocation | Us |
| Platform upgrades, patching and monitoring | Us |
| Registering that address in your broker console | You |
| Your broker account, its funding and its margin | You |
| Your broker API key and its renewal | You |
| The strategies: writing, testing, scheduling, stopping | You |
| Every order placed in your account, and its consequences | You |
The engine addresses NSE, BSE, NFO, BFO, CDS, BCD, MCX and NCDEX, covering equity, futures and options, currency and commodities. What you can actually trade is set by your own broker's API and your own entitlements with them, not by us.
Once it is running
What we do while your instance is live, and what we do not
We run the infrastructure your instance sits on: the host, the isolated database, the dedicated egress IP and the engine process. Your strategies run on the schedule you configure, and starting, stopping and squaring them off remains yours to do. Planned maintenance is scheduled outside NSE and BSE market hours wherever it can be, and you are told before it happens.
Maintenance is scheduled around the market
Planned work happens outside NSE and BSE market hours wherever it can, and you are told before it happens. Support is staffed Monday to Friday, 8:00 AM to 5:00 PM IST, which is a different thing from your instance being up and is never written here as if it were the same. The status page sets out both.
Nothing is replayed after an outage
If your instance is unreachable, orders it would have placed are not placed, and nothing is replayed when it comes back: a strategy that missed an entry has missed it. Trading through a broker terminal is always available to you as a fallback, because the broker account is yours and we never stand between you and it.
Leaving
You leave with your data, and the address is decommissioned
Order records, logs and strategy files are yours and are exportable at any time, including on the way out. When an instance is decommissioned its dedicated address is released, so remove it from your broker’s whitelist as part of the same exercise. The broker account, the money and the code were never ours to keep hold of, and nothing about the arrangement is designed to make going hard.
Boundaries
What we do not do
Blunt, because it is the part that decides whether this product is right for you. If you were hoping to be given something to trade, this is the wrong page and it is better to know now.
We do not choose what you trade
The platform holds no view on any security and never originates an order. Every order it sends is one your own code or your own configuration produced.
We do not decide when
Timing comes entirely from your strategy and the schedule you set. If your code does nothing all day, your instance does nothing all day.
We do not read your strategies to trade alongside you
Your code sits on your instance. It is not aggregated, not mined for signals, and not run on anyone else's account.
We never hold your money
Funds and securities stay with your own SEBI-registered broker throughout. The instance holds an API session, not an account, and cannot withdraw or transfer anything.
Regulatory position
triStack AlgoTrader is hosting infrastructure, not an investment adviser and not a signal provider.
triStack AlgoTrader is managed hosting for trading software you operate yourself. Tristack Technologies LLP is not registered with SEBI in any capacity, publishes no signals or recommendations, never handles your funds, and guarantees no return. Trading in securities carries a substantial risk of loss, and you are solely responsible for your trades.
Get started
Tell us what you want to run
Bring the broker you are with, the strategies you already have or the ones you are about to write, and how much of the day they need to be awake. We will come back with what the instance looks like, what it costs and what you have to do at your broker before it can place its first order.
Your infrastructure, your code, your broker account. · [email protected]