Privacy Model
TraderTape is a SaaS product that handles real money. Privacy is not optional. This document explains exactly what the cloud sees, what stays on your device, and the design choices that produce that split.
The high-order question
"Why would I trust a cloud service with my trading data?"
You shouldn't, if the answer requires unconditional trust. The TraderTape design makes trust selective: you decide which data goes where, and the architecture enforces those choices.
There are two user classes:
| Class | Broker secret | Session token | Trade data | Execution | Who it's for |
|---|---|---|---|---|---|
| Default | Never on cloud | Cloud stores ~14h token | Cleartext | GTT only (cloud) | Most users |
| Admin/Family | Cloud (encrypted) | Cloud stores | Cleartext | GTT + market orders | Admin + family |
The Default class is what new users get. Your broker API secret never touches our servers.
How Browser Login works (Default class)
When you log in to your broker via Browser Login:
- You paste your
api_secretinto the login form on our site - Your browser computes
SHA256(api_key + request_token + api_secret)locally using the Web Crypto API - Only the resulting one-way checksum is sent to our server
- Our server forwards the checksum to your broker's token endpoint
- The broker validates the checksum and returns an
access_token - We store the
access_token(~14 hours, revocable) so the scanner and dashboard can read your account
Your API secret never crosses the network. The SHA-256 checksum is useless without the single-use request_token (which expires in ~60 seconds). Even if our server were compromised, an attacker could not derive your secret from the checksum.
This works for Zerodha Kite and Groww (both use checksum-based auth). For Upstox, the API secret passes through our server once during the code exchange (Upstox's API requires it as a POST field), but is never stored.
Your password manager can save the API secret field so you don't have to paste it daily.
What's in the cloud database, always
These things are in the cloud no matter which class you pick:
- Email address (required for magic link login)
- Strategies (the DSL definitions you create or fork)
- Backtest results (computed from public market data)
- Signals (generated by the cloud scanner running your strategies)
- Audit log (every action you take in the system)
- Public market data (candles, instruments, NAVs -- shared across all users)
None of these reveal your identity beyond your email. None of them contain account-specific financial data unless you upload tradebook data.
What's in the cloud with your consent
-
Broker
api_key-- saved when you configure a broker in Settings. Theapi_keyis not a secret -- it identifies your broker app but can't authenticate without the secret. -
Active broker session token -- present after a successful login. Lasts ~14 hours then expires. This lets the scanner, dashboard, and Telegram bot access your broker account without you having a browser tab open.
-
Tradebook data -- uploaded via Settings. Stored as-is unless you use the local agent with obfuscation enabled.
-
Broker snapshots -- holdings, positions, and margins fetched periodically (every 15 minutes during market hours) and stored for use when your session expires.
What never goes to the cloud (Default class)
- Your broker
api_secret-- stays in your browser and password manager - Your broker login password and OTP -- entered on the broker's own login page, never on ours
Multi-broker support
TraderTape supports three Indian brokers:
| Broker | Auth method | Secret in transit? | GTT support |
|---|---|---|---|
| Zerodha Kite | SHA-256 checksum | Never | Native GTT |
| Groww | SHA-256 checksum (stateless, no redirect) | Never | SL-LIMIT only |
| Upstox | OAuth2 code flow | Once during exchange (not stored) | Native GTT |
All three work via Browser Login. Your dashboard shows per-broker tabs so you can view holdings, positions, and orders from each broker separately.
Execution and SEBI compliance
All cloud-driven execution uses GTT (Good-Till-Triggered) orders only. GTT placement is exempt from SEBI's static-IP check because the actual order execution happens from the broker's infrastructure, not from the user's or our IP.
This means:
- You don't need a static IP to trade via TraderTape
- You can place GTTs from any device, any network
- Immediate market orders (
/orders/regular) are not supported through the cloud -- they require a static IP per SEBI rules
Admin/Family accounts (Class 0) can place immediate market orders because SEBI permits IP sharing within family units and the admin's static IP is registered with the broker.
Admin/Family class (Class 0)
Admin users and family members explicitly approved by the admin can store their api_secret on the cloud (encrypted at rest with Fernet). This enables:
- Cloud-driven OAuth login (no need to paste the secret each time)
- Immediate market order placement from the cloud's IP
- Full automation without a browser tab open
This mode requires the admin to grant allow_cloud_credentials to the user.
The local agent (optional, advanced)
The local agent is a Python daemon that runs on your machine. It's not required for most users -- Browser Login handles everything. The agent is useful for:
- Trade data obfuscation -- the agent multiplies all numeric values by a secret factor before uploading tradebooks, so the cloud only sees scaled-down patterns
- Headless/24-7 operation -- runs without a browser tab open
- SEBI-compliant immediate orders -- orders leave from your machine's IP
If you don't need any of these, you don't need the agent.
What the admin can see
The cloud admin has direct database access. From the admin's perspective:
- Always visible: all users' emails, strategies, backtest results, signals, audit logs
- Visible only with consent: uploaded tradebook data, broker snapshots
- Never visible for Default users: the broker API secret (it never reaches the cloud)
- Visible for Admin/Family users: encrypted
api_secretblobs (decryptable with the cloud's encryption key)
Authentication tokens
Your TraderTape session cookie:
- Name:
kite_session - Value: UUID, generated server-side
- TTL: 7 days (configurable)
- Flags:
HttpOnly,Secure,SameSite=Lax
HttpOnly means JavaScript can't read the cookie (prevents XSS exfiltration). Secure means HTTPS-only. SameSite=Lax blocks most CSRF attacks.
Next
- Brokers -- connecting and managing broker accounts
- Local Agent -- the optional privacy/automation upgrade
- Architecture -- system components and data flow