QUANTITATIVE DEVELOPER · MUMBAI, INDIA
Quant developer — market-data infrastructure, research and backtesting, and live multi-broker execution.
Tick to fill on an Indian derivatives desk: the feed, the warehouse, the research clock, the risk gate, and the door five brokers share.
I build and run what a trading desk is made of: market data coming in, research in the middle, orders going out. On the data side that is the exchange feed, tick distribution across equities, derivatives and commodities, a serving API, and a platform whose pipelines and quality gates research replays. In the middle it is the simulation engine an idea has to clear — next-bar fills, real Indian costs, walk-forward — and the paper stage that uses the live order path. On the execution side it is a control layer turning one master trade into orders for twenty to thirty client accounts, and an OMS layer where each instance holds every client on its broker. Python across the desk, C++ where the packet path is hot, two-plus years of it in production in Mumbai.
Everything below is drawn, because the useful question about a trading system is never the feature list — it is what the shape is, what is allowed to block an order, and what happens at 09:16 when a broker stops answering. Every stage on the drawing opens into what I actually built there.
Four stages carry market data in — feed, distribution, serving, warehouse. Four carry orders out — research, risk, control, OMS. The figures hang off the drawing as dimensions, the way a measurement belongs on a plate.
OPEN ANY STAGE
This is the shape these roles are hiring for. A strategy publishes a single master trade at unit size and never names a broker. The control layer sizes it against each client’s own capital and resolves which order-management system it has to leave through. Each OMS instance owns one broker’s API and holds every client account that trades on it, each in its own lane.
← DRAG TO READ THE FULL DRAWING
MASTER
The strategy writes one tradesheet at unit size. It knows nothing about clients, capital or brokers, which is why adding either is not a strategy change.
CONTROL
Per client: how large, which broker, which OMS. Routing keeps working from same-day cached state when the client directory is unreachable, and marks the orders that did.
OMS
One instance per broker, every account on that broker inside it — own connection, own cache, own rate limit, own lane. Dealer and retail accounts route differently.
A tick becomes a feature, a feature becomes a signal, a signal meets the risk gate, and only then is there an order. Pre-trade risk blocks: no answer, no order. Post-trade risk observes: position, charges and P&L are allowed to be a moment behind, and never hold a trade. Keeping those two apart is most of what makes a desk fast and safe at once.
← DRAG TO READ THE FULL SECTION
I have taken strategies the whole way — from an observation about how a market behaves, through specification and backtesting, around the iteration loop more times than anyone enjoys, out to paper on the live order path, and into client capital. The gates are the product. An engine that never kills an idea is not measuring anything.
← DRAG TO READ THE FULL LOOP
THE ENGINE
Instruments, entries, legs, exits and lifecycle rules are declared rather than coded, so iterating on an idea does not mean maintaining another fork. Multi-leg structures, Greeks and strike selection come with it.
THE GATES
Fills land on the next bar after the broker clock. Indian charges are applied by product class. Walk-forward freezes the training window before out-of-sample is scored. Most ideas end here, and that is the point.
THE HANDOFF
Paper trading leaves through the same OMS door as live, with the same timeouts and the same fan-out. What clears it is the same program that runs on capital, not a lookalike.
I have built across all four of these, so I am not scoping myself to one of them. Grouped the way these briefs are usually written, so nobody has to translate.
Grouped by the job each tool does rather than listed as a cloud, because the useful question is never how many I can name — it is which one I reach for and why.
Python across the desk and the services. C++ on the exchange feed path, where the packet loop is hot.
Column store for ticks and bars, cache for what has to be instant, streams for fan-out, document store for order and desk state.
Asynchronous services with REST and socket surfaces, plus the binary and broker interfaces underneath them.
Containerised services on Linux hosts, orchestrated pipelines, and systems that report their own problems.
Vectorised computation over market data, derivatives pricing, and evaluation that holds up out of sample.
Five broker APIs behind one interface, across cash, index and stock derivatives, and commodities.
Building it is half the role. The other half is being on the end of it at 09:16 when something breaks in front of live client capital.
I am the person the desk calls when something is wrong while the market is open — abnormal prints, a margin call, a position breach, a broker-side failure. The goal is not heroics, it is no disruption to live trading across every client account.
Structured logs, health endpoints and alerts on stuck state mean the system reports its own problems. Most incidents are identified from the service before a trader notices, which is the only version of this that scales.
Failover, circuit reset, reconciliation against the broker book, then a written account of what happened. Order-book replay makes the post-mortem an examination of the actual session rather than a reconstruction from memory.
What the desk moves in a session, and what the order path costs in time. Each one is measured where the drawing says it is measured.
| REF | QUANTITY | WHERE IT IS MEASURED |
|---|---|---|
| A1 | 15–20Kticks / sec | feed → sequenced book |
| A2 | ~40Kinstruments | subscribed universe |
| A3 | 300–600Mticks / day | stored in the warehouse |
| B1 | 5broker APIs | behind one OMS interface |
| B2 | 20–30client accounts | one signal, fanned out |
| B3 | 10–20ms | order path, colocated |
| B4 | 80–500ms | order path, over internet |
| C1 | 8strategies | cleared paper → live |
| C2 | 2+years | on a production desk |
| C3 | 9.58CGPA | B.Tech CE, DJSCE |
Live and replay share assembler → dedup → gap → features. Failover when the primary is silent. The UI does not stream every tick.
github.com/Parth4786/market-observatory ↗What-if before size: basket margin plus prop vs retail costs on the same proposed book. FastAPI + UI. Hygiene is real; the product is the what-if.
github.com/Parth4786/DeskMetrics ↗Event-driven research. Regimes from basis and vol z-scores, then risk limits in the same loop. Repeatable from the CLI. Not a live OMS.
github.com/Parth4786/deepitm-regime-hedge ↗LONG READ · 9 MIN
The cheapest-looking line in a broker integration, and the most expensive one to get wrong.
NOTE · 3 MIN
If the backtest can see the bar it traded, the Sharpe is fiction.
NOTE · 3 MIN
Paper uses the live order path. Eight strategies cleared every gate.
Quantitative Developer — Endovia Wealth, Mumbai · Jul 2024 – present
Quant Developer Intern — Anived Portfolio Managers · Jun 2023 – Aug 2023. IBKR path before this desk.
B.Tech Computer Engineering — Dwarkadas Jivanlal Sanghvi College of Engineering · 2021–2024 · CGPA 9.58