Case study · Featured · Product engineering
Inside AlphaSync
How we engineered an algorithmic trading platform around market data, a central risk engine and five broker integrations.
From an idea for a strategy to an order at the exchange, without gaps.
Systematic traders and desks in India often assemble their tooling from separate parts: a charting tool, spreadsheets or scripts for backtests, a broker terminal for orders, and manual discipline for risk.
Each handover is a place where a rule can be skipped, a position missed, or a strategy can behave differently live than in testing. The problem to solve was continuity: a single system in which the strategy that is designed, tested and traded is the same, with limits the platform enforces.
Five stages, one pipeline.
AlphaSync is organised as a pipeline. Market data enters, strategies evaluate it, the risk engine checks every intended order, execution routes it to the broker, and analytics records what happened. Select a stage to explore it.
Market Data
Live NSE and BSE prices arrive through broker market-data interfaces and are normalised into one internal format, so every downstream component sees the same instrument, the same timestamp and the same price.
- Equity and F&O instruments
- Streaming feeds, with polling where a broker offers only request-based access
- Historical data for backtesting
- One normalised format across brokers
Strategy Engine
Strategies are defined once, either in a visual rule builder or in Python, and the same definition runs in backtesting, in paper trading and live. That continuity is the core design decision.
- Indicator, price, time and volume conditions
- Backtest reports: CAGR, Sharpe ratio, maximum drawdown, trade-by-trade P&L
- Paper trading on live prices, with no orders placed
- Variants compared side by side
Risk Engine
No strategy talks to a broker directly. Every intended order passes through the risk engine first, which applies the limits the user has set and can stop trading altogether.
- Per-trade stop-loss and position sizing
- Daily maximum-loss limits
- Margin utilisation caps
- Kill switch that halts all live orders
Execution
Approved orders are routed to the user's own broker account through that broker's official API. A separate adapter per broker absorbs the differences in order types, sessions and responses.
- Zerodha, Alice Blue, IIFL, Zebu and BNR
- Order routing and position tracking
- Multiple accounts from one interface
- Broker connections authorised by the account holder
Analytics
Every signal, order and fill is recorded, so a user can see not just their P&L but why each trade happened. The same record forms the audit trail.
- Daily, weekly and monthly P&L
- Strategy-level performance comparison
- Export for record-keeping
- Alerts by email and Telegram
Why it is built this way.
- One strategy definition everywhereThe same definition runs in backtest, paper and live modes, so validation actually applies to what trades.
- Risk engine in the path, not beside itNo component can place an order without passing the risk engine, which makes limits enforceable rather than advisory.
- An adapter per brokerDifferences in order types, sessions, responses and market-data delivery are contained in one place per broker.
- Stop and report on failureWhen data or a connection is lost, the platform stops acting and tells the user rather than guessing.
- Everything recordedSignals, orders and fills are logged, which gives both analytics and an audit trail.
What the architecture has to hold up against.
Real-time data
Brokers deliver data differently. Normalising it early means strategies never depend on a single broker's format.
Reliability
When a connection drops, the right behaviour is to stop and report, not to guess. Failure modes are designed to be safe.
Risk
Limits are enforced in one place, between strategy and execution, so no path to a broker bypasses them.
Integrations
One adapter per broker keeps each API's behaviour contained and lets new brokers be added without touching strategies.
Scalability
Strategies, users and accounts are separated, so more of each can run without one affecting another.
Security & regulation
Designed with applicable SEBI and broker requirements in mind, including audit trails, order-rate limits and user-level permissions.
A platform in production, and a foundation for the next two.
AlphaSync is in production use, connected to Zerodha, Alice Blue, IIFL, Zebu and BNR through their official APIs. It is also the simulation environment for our College Workshop Programme.
Its market-data, strategy and risk layers are the foundation that AlphaSync Campus and HedgePro are being built on.
Technology stack.
Frontend
- React
- TypeScript
- WebSockets
Backend
- Python
- FastAPI
Data
- MySQL
Integration
- Zerodha
- Alice Blue
- IIFL
- Zebu
- BNR
Important. AlphaSync is trading technology, not investment advice. Backtested or simulated results do not indicate future returns.
More work