Security
How your credentials, your traffic and your record are handled
QuantGrid places orders inside your broker accounts, so you are entitled to know exactly what it holds, where it connects from and what it writes down. This page states the mechanism rather than the reassurance.
- Access
- Broker OAuth token
- Never requested
- Password or trading PIN
- Source address
- Dedicated, never shared
Practices
Six things we do, and how each one actually works
Every item below is something you can ask us to demonstrate, or verify from your own broker console and your own trade log.
Your broker credentials stay yours
QuantGrid connects through your broker's official API using tokens you authorise. You can revoke access from your broker's console at any time, and the connection stops immediately.
You authorise QuantGrid on the broker's own screen: the Kite Connect redirect for Zerodha, SmartAPI authorisation with your own TOTP for Angel One, and the auth-code exchange for FYERS API v3. What comes back is an API session token scoped to that broker's API, and that token is the only thing QuantGrid holds.
Zerodha and FYERS sessions expire at the end of every trading day and cannot be refreshed, so the credential QuantGrid stores has a life measured in hours rather than months. When it lapses you re-authorise through the broker again.
A static IP reserved to you alone
Every broker account you connect gets a dedicated static IP address that is never shared with another customer. Brokers that require API access from a whitelisted IP will see one stable address, and your API activity is never mixed with anyone else's.
The address is allocated to your account and stays the same across restarts, redeploys and reconnects. Everything QuantGrid does on your behalf leaves from it: the authorisation call, the order WebSocket subscription, the REST order-book polls and every child order placement.
If your broker asks you to declare or whitelist the address your API calls come from, you enter one value, once. No other customer's traffic ever originates from it.
Encryption in transit and at rest
All traffic runs over TLS. Broker tokens and account secrets are encrypted at rest and are never written to application logs.
Broker traffic is HTTPS and WSS only, with no plaintext fallback path. Tokens and account secrets are encrypted before they reach the database, and the fields holding them are excluded from application log output.
Some broker socket handshakes carry the access token inside the connection URL. Rather than record that request and redact it afterwards, the telemetry pipeline drops WebSocket handshake events entirely, so the token never lands in a monitoring system in the first place.
Tenant isolation
Each account's data is bound to its own tenant at the point where a broker stream is opened, so one customer's order events can never reach another customer's replication engine.
The owning account is attached at the moment a broker stream is opened, not looked up later. That identity travels with the event through normalisation, the in-process event bus and job creation, so there is no stage where an event exists without knowing whose it is.
Broker accounts carry an owner as a database foreign key, and a copy relationship can only be created between accounts under the same login. It is a constraint in the schema, not a check in the interface.
Duplicate-order protection
Every replicated order passes three independent duplicate checks before it reaches a broker. A network retry, a reconnect or a repeated event cannot place the same child order twice.
The three layers are independent by design. A marker key in Redis short-circuits an event that has already been handled. A distributed lock, held per child account and instrument, stops two workers racing on the same fill. A unique database index on the idempotency key is the final backstop.
The first two exist for speed. The third exists for correctness: if the database refuses the insert, no order is sent to the broker.
Complete audit trail
Every event received, every decision taken and every broker response is written to an append-only log you can inspect and export. If you need to reconstruct exactly what happened at 09:15:04, the record is there.
Order events are written before replication is attempted, each stamped with the path that delivered it (websocket or rest_poll), so you can tell a live socket update apart from one recovered by order-book polling.
Every replication job records the quantity it calculated, the multiplier and lot size it used, the broker's response, and the reason when nothing was sent, including the case where a multiplier floors below one full lot. Records are appended, never edited after the fact.
Dedicated IP
One address, allocated to you, that nobody else connects from
This is the infrastructure feature we lead with, so it is worth more than a bullet point. Here is what it is, why your broker cares, and what specifically breaks without it.
What a static IP is
Every request QuantGrid makes to a broker arrives there from an IP address, and that address is part of what the broker records about the connection. On ordinary cloud hosting the address is drawn from a shared pool: it can differ between two servers, and it can change when a process restarts or moves. A static IP is a single address allocated to you and held there, so the broker sees the same origin every time.
Why brokers care where you connect from
Broker API programmes treat the source address as part of an integration’s identity. Some ask you to declare or whitelist the address your API calls originate from. All of them use it in some form for abuse detection, throttling and forensics. An address that moves means re-declaring it, or being treated as an unfamiliar source at exactly the moment you need the connection to work.
On a shared address
- Throttles you did not spend. Broker rate limits are counted per user, but network-level throttles, WAF rules and abuse heuristics are commonly applied per source address. A neighbour's polling loop can eat headroom you were relying on at 09:15.
- Reputation that is not yours. If a block or a flag lands on a shared address because of somebody else's behaviour, your orders are travelling through that same address.
- A whitelist that no longer means anything. Whitelisting an address that other people also use narrows nothing. The control your broker offered you has quietly stopped being a control.
- Attribution you cannot get back. When you ask your broker to check their side, a shared address makes your API calls indistinguishable from everyone else's on the same host.
On your own address
- One value to declare. The address you give your broker is the address every call arrives from, this session and the next.
- Your activity only. Nothing else routes through it, so anything your broker sees from that address was caused by your account.
- Stable across reconnects. Socket drops, restarts and failovers do not move you onto a different address.
- Yours while it is paid for. The allocation is held for your account, not drawn from a pool at connection time.
IPv4 or IPv6: two prices, one question
Each broker account you connect gets its own dedicated address, and QuantGrid prices the two families separately, with IPv6 the lower price. Beyond the price, the choice rides on what your broker’s API accepts: IPv4 is still the common case, and IPv6 works only where the broker’s endpoints and whitelisting forms accept it.
Not every broker API accepts IPv6 connections today, and which ones do can change without notice. We deliberately do not print a per-broker IPv6 claim here, because a stale claim on a page is worse than no claim at all. Ask us on the contact form and we will tell you what we currently observe for your broker.
| Component | Charged | Price |
|---|---|---|
| Dedicated static IPv6 | per broker account | ₹499 per 30 days, + 18% GST |
| Dedicated static IPv4 | per broker account | ₹799 per 30 days, + 18% GST |
Credentials
What QuantGrid asks for, and what it will never ask for
Copy trading tools are a natural target for phishing, because the payoff is direct access to a funded account. So the boundary is worth stating in one unambiguous line.
QuantGrid will never ask you for your broker password or your trading PIN.
Not on sign-up, not during setup, not while troubleshooting a failed order, and not over email, phone, WhatsApp or Telegram. Nobody who works here has any reason to know them. If a message claiming to be from QuantGrid asks for either one, it is not from us: do not reply, and forward it to support@quantgrid.in.
Authorisation happens on the broker
You are sent to your broker’s own authorisation screen and you approve API access there. QuantGrid receives a session token back. It is the broker, not QuantGrid, that authenticates you, which is the whole point of the flow.
Tokens are encrypted and unlogged
The token is encrypted at rest and excluded from application logs, error reports and telemetry. Support staff diagnosing a failed order work from order events and broker responses, not from your credentials.
You can revoke it, from their side
Access can be withdrawn from your broker’s own console at any time, without asking us and without waiting for us. The connection stops. On Zerodha and FYERS it also lapses on its own at the end of every trading day.
The scope of that token is the broker’s to define, not ours. What it permits, and what it does not, is described in each broker’s API documentation, which we link from the supported brokers pages.
Isolation
Your events reach your engine, and only your engine
Multi-tenancy is where a replication platform fails quietly and expensively. Two structural decisions keep the boundary from depending on anyone remembering to check it.
Ownership is attached at the socket
The tenant is bound when the broker stream is opened, so an order event is never in flight without carrying the account it belongs to. That identity is present through normalisation, through the in-process event bus and into every replication job. Copy relationships are constrained to accounts under a single login by a foreign key in the schema, so the isolation does not rest on an interface check that a future screen could forget to make.
Only a master can cause an order
QuantGrid streams your child accounts too, but purely to record what happened in them. A fill in a child account is written to the event log and stops there. It cannot start a replication, so a child account can never become an accidental source that fans orders back out across your other accounts. If you want to see how the fan-out is wired, the how it works page walks the full path.
What the record looks like
Shape of the log, not a real accountOne master order, one child account, four rows. The quantity line shows the arithmetic that produced the child order, so a number you did not expect can be traced to the multiplier, the lot size or the cap that produced it rather than argued about.
| Time IST | Event | Account | Broker order id | Detail |
|---|---|---|---|---|
| 09:15:04.118 | order.received | master · Zerodha | 250804000112233 | BUY NSE:RELIANCE 100 MKT · source websocket |
| 09:15:04.126 | qty.calculated | child · FYERS | n/a | 100 × 0.50 = 50 · lot 1 · cap 500 |
| 09:15:04.141 | order.placed | child · FYERS | 25080400987654 | BUY NSE:RELIANCE-EQ 50 INTRADAY |
| 09:15:04.147 | order.accepted | child · FYERS | 25080400987654 | broker acknowledged · 29ms end to end |
Reliability
What the 99.9% uptime SLA covers, and what it honestly cannot
An availability number is only useful if the boundary around it is drawn in public. Ours is drawn here, starting with the hours the platform is switched on at all: the commitment is 99.9% uptime during NSE and BSE market hours, measured over those hours rather than over the calendar month.
QuantGrid is not a 24-hour service, and one consequence follows from that
QuantGrid runs from 8:00 AM to 5:00 PM IST on NSE and BSE trading days. Outside those hours, and at weekends and exchange holidays, the platform is taken offline for maintenance and to keep running costs down.
Place your orders while the platform is up. An order placed on the master account outside the hours above, including an after-market (AMO) order, is not replicated at all: it is already on the order book by the time the engine starts, so it is treated as history rather than as a new order, and a later fill on it does not replicate either.
The reason is the way the engine starts. It reads the master’s order book and records everything already sitting on it as seen, so that starting up mid-session does not mirror a whole trading day into your child accounts. An order placed while the platform was down is on that book by then, so it is filed as history rather than replicated. The how it works page sets out that startup behaviour in full. The uptime commitment is scoped to the same hours on purpose: promising 99.9% of a calendar month would be promising uptime through hours the service is deliberately switched off.
Inside the SLA
- The QuantGrid replication service during the hours it runs: 8:00 AM to 5:00 PM IST on NSE and BSE trading days.
- Event intake from the broker order WebSocket, with REST order-book polling taking over automatically when a socket drops.
- Order placement into linked child accounts, plus the square-off and cancel controls.
- The trade log and the audit trail behind it.
Outside the SLA
- The hours outside that window. The platform is deliberately offline outside 8:00 AM to 5:00 PM IST, and at weekends and exchange holidays, so those hours are scheduled downtime rather than availability we are measuring or owe you.
- Anything outside the replicated scope. QuantGrid replicates equity and F&O orders on NSE, BSE, NFO and BFO. Commodities (MCX) and currency (CDS and BCD) are outside that scope and are never replicated.
- Broker API outages, broker-side maintenance windows and broker rate limiting.
- Exchange halts, circuit breakers, and any order the exchange or your broker rejects, including margin shortfall, freeze quantity and blocked scrips.
- Daily token expiry. Zerodha and FYERS sessions end each trading day, and until you re-authorise there is no stream to read.
- Your own network, device or broker terminal when you are placing the master order by hand.
How the number is defended
Order updates come off the broker WebSocket first because it is the fastest path. When a socket drops, order-book polling takes over on its own and keeps replicating while the connection is re-established. Both paths run through the same duplicate checks, so the handover cannot double an order. Reconnection is automatic, with a manual reconnect control if you want to force one, and a Telegram alert fires on connection loss so you find out from us rather than from a missing order.
When something is wrong
Scheduled maintenance and any live incident are published on the status page, which is the place to check first when replication is not behaving and the one we update while we are working on it. Support is available Monday to Friday, 8:00 AM to 5:00 PM IST. If an incident affected your account, the audit trail is the record we work from, and you can export the same rows we look at.
Disclosure
Found something? Tell us before you tell anyone else
We would much rather hear about a weakness from a researcher than from a customer. Reports are read by an engineer, not by a ticket queue.
Where to send it
Email support@quantgrid.in with “Security report” in the subject line. If you have had no reply within five working days, escalate to grievance@quantgrid.in and it will be picked up.
What to include
- The endpoint, page or behaviour affected.
- What you did, what you expected and what actually happened.
- Timestamps in IST, and the source address you tested from.
- Any proof-of-concept steps, kept to the minimum needed to show the issue.
What we ask of you
- Test only against an account you own. Never touch another customer's data.
- No automated scanning during market hours, and nothing that degrades the service for people with live positions.
- Give us a chance to respond before publishing.
In return: we acknowledge within two working days, we tell you what we found and whether we are fixing it, and we credit you publicly if you want that. There is no paid bounty programme today, and we will not pretend otherwise.
What we do not claim
QuantGrid holds no security certification. We are not ISO 27001 certified, we have no SOC 2 report, and we have not been audited by a third party. When that changes we will publish the certificate and its scope here. Until then, everything on this page is a practice we operate rather than a badge somebody issued us, and you should read it that way.
QuantGrid is a technology platform for order replication. It is not registered with SEBI, does not provide investment advice, and does not guarantee any return. Trading in securities carries substantial risk of loss. You are solely responsible for your trades. Read the full compliance position, or check the FAQ for the questions people ask before signing up.
Get started
Start with one child account and a small multiplier
Link a single child account and check every replicated order against your broker's order book before you scale it up. The audit trail described on this page is the same record you can export, from the first order onwards.
Prepaid wallet · No lock-in, stop any time