Trading systems for prop desks
Prop desks, arbitrage traders and scalpers ask for one thing above all: a system that does exactly what the strategy says, as fast as the strategy needs, and stops cleanly when something goes wrong. We have built arbitrage and scalping systems for prop desks in the US and India, and deployed at NSE’s co-location facility in Mumbai. The strategy is yours; we build the engine, the data handling and the risk controls around it.
The strategy, the capital and every trading decision are yours. We do not trade, we do not supply strategies, and we quote no speed figure until we have measured it in your setup.
What we have built for prop desks
- Arbitrage and scalping systems for prop desks in the US and India, each built to the desk’s own rules.
- HFT-style backtesting on NSE tick-by-tick data: the exchange’s full record of orders and trades, replayed in sequence, so a test sees the market the way the live system will.
- A deployment at NSE’s co-location facility in BKC, Mumbai, for a prop desk and for a broker.
Arbitrage: two legs, one decision
Arbitrage systems live or die on the legs. Both orders have to go out together, at prices that still hold when they arrive, and the system has to know at every moment what to do if only one fills: hedge it, chase it or close it, by your rules. We build leg handling as its own tested component, with price checks before sending, a time limit on an unfilled leg, and a record of every attempt, so you can see how often the second leg slipped and by how much. The same applies whether the legs sit on two exchanges, in cash and futures, or in two expiries of one contract. Options arbitrage such as conversions and reversals adds a third leg; we have coded those for an Indian broker, as our page for brokers describes.
Scalping: the order path is the product
For a scalper, most of the work sits between the signal and the exchange: how fast an order goes out, how quickly a cancel follows, and what the system does when the broker or the exchange rejects or throttles. We keep the order path short, with no database writes, no blocking log calls and no network calls the order does not need, and move everything else to the side. Then we test the cases a fast system meets many times a day: a cancel that arrives after the fill, a change to an order that is already gone, a partial fill at a price that has moved. Order rate limits are built in, so the system stays inside the broker’s and the exchange’s rules.
Tick data, recorded and replayed
Fast strategies need more than bars. We build feed handlers that decode the exchange or vendor feed, rebuild the order book and timestamp every message on arrival, and we record all of it, so research, backtests and incident reviews replay exactly what the live system saw. A backtest at this level also has to model what bars hide: where your order would have sat in the queue, how long it takes to reach the exchange, and fills that depend on who was ahead of you. More on feeds in market data engineering, and on testing in backtesting software.
Risk controls per strategy, trader and account
A desk runs many strategies at once, so the controls sit in the order path, not in a report afterwards: maximum order size and position, price bands, loss limits per strategy and per day, and a kill switch that stops one strategy, one trader or the whole desk. Positions are reconciled against the broker or the exchange’s own records, and every order, change and cancel goes to an audit log. Our reference architecture for a small prop desk shows where the risk gate and the order manager sit.
Co-location, and when it is worth it
Co-location pays only where microseconds change the result: scalping, market making and some arbitrage. For most other strategies a well-placed server near the broker is cheaper and easier to run, and our guide on when you actually need co-location sets out the trade. When it is worth it, what changes is discipline: dedicated hardware, a tuned operating system and network, C++ on the order path, and timestamps at every hop (market data in, decision, order out, exchange acknowledgement), so you measure tick to trade in your own environment instead of taking anyone’s word for it.
US and Indian markets
In the US, prop desks usually trade through direct-access platforms such as Takion and Lightspeed, or a broker’s FIX API, and futures through Rithmic; we connect to all of them, as our page on direct-access platforms explains. In India, every order reaches NSE or BSE through a trading member, and the exchange’s rules on algos and order rates apply. The member’s compliance team handles the exchange approvals; we build to the rules and document the system for them. A desk trading through a broker’s API also falls under SEBI’s retail algo framework, which our guide to the rules explains.
Common questions
- What latency can you get us?
- We will tell you after we measure it, not before. Latency depends on your venue, broker, hardware, network and the work your strategy does on each tick, so a figure quoted without your setup would be a guess. We build timestamps into every hop and report what we measure, in your environment.
- Do you build in C++?
- Yes, for the parts where speed decides: feed handling, the order path and the risk checks inside it. Research, tooling and dashboards usually stay in Python or C#, where they are quicker to change. Our guide to choosing a language explains the split.
- Will our strategy stay confidential?
- Yes. We sign an NDA before you share your rules, your code or anything about the desk. Owning the source code outright is also an option, and our FAQ explains how it works.
- I trade a funded account with a prop firm. Can you automate it?
- Often, yes, on the platform the firm gives you, such as NinjaTrader or a Rithmic connection. Rules on automated trading differ from firm to firm, so check yours first; we build within them.