Why an HFT bot loses performance under peak load
An HFT bot doesn't "break" entirely — it loses performance gradually as load increases. While the quote flow is moderate, the bot's response latency stays within familiar bounds, and the order execution model matches the calculated one.
Under peak load on the exchange — a statistics release, opening auction, cascade of stop triggers — the time between signal and order placement increases severalfold, and the strategy starts operating on an outdated market picture.
The second failure point is order slippage. During a sharp move, liquidity in the order book drops: the price passes through several levels while the order reaches the exchange, and execution comes worse than calculated.
The higher the decision frequency, the greater the discrepancy between the modeled and actual entry price — the position is already open, and the expected advantage is eaten by the move.
The third failure is a connection drop at the worst possible moment.
During peak volatility, the exchange's message rate limits are exhausted faster than in calm mode: the bot loses the data stream, the local copy of the order book diverges from the exchange's, and after reconnection, some orders remain out of control.
Every such minute means open positions without management and strategy drawdown that later has to be recovered manually.
We analyze how this is closed: where to measure latency by stages — from quote receipt to execution confirmation, how to reconnect without losing the order book state, and which risk limits stop the bot before the discrepancy turns into a loss.
What implementation gives: response speed, failures, risk control
A trading module is evaluated not by the speed of sending an order, but by how many orders reach the trade.
The share of executed orders depends on the freshness of the local copy of the order book and on the handling of partial executions: if the state diverges from the exchange's, some orders are rejected already on the exchange.
After reworking the queue and reconciling the state, the share of executed orders grew from 78% to 94% on the same signal flow.
The reduction in drawdown comes not from speed itself, but from order in risk limits.
When limits on position, loss per trade, and loss per interval are checked before sending an order, rather than after the exchange's response, the module stops chasing the market with a series of delayed triggers. Predictable limit behavior removed the spikes that caused interval drawdown to reach 9%.
A separate class of failures is channel disconnection. The HFT bot exchanges service packets with the exchange, automatically reconnects on a drop, cancels stale orders, and reconciles the position via the FIX protocol.
Previously, after a drop, the module could open a second position on the same signal — now this class of failures is closed.
Monitoring of the trading module is built on four metrics: response time, order queue depth, divergence between local and exchange position, and number of rejected orders.
The alert arrives before the divergence turns into an unplanned position — risk control stops being reactive.
Operating modes: autonomous, semi-autonomous, arbitrage
The mode is determined not so much by the strategy as by the point at which the decision is made: who places the order at the moment the signal triggers and how many steps remain until the trade.
The same calculation module in autonomous and semi-autonomous loops gives a different risk profile, so we fix the mode before development — otherwise changes have to be made to already working logic.
| Option | When it fits | Limitations |
|---|---|---|
| Autonomous trading mode | The strategy is formalized into rules: entry, position size, stop are calculated from quotes without human involvement | An error in logic is replicated at the same speed as the result; an external control loop, hard limits, and emergency stop are needed |
| Semi-autonomous mode | Signals are calculated by the system, the decision is confirmed by a human — or the bot hedges a manual position | Reaction is limited by the operator's speed: some signals are missed, statistics shift toward calmer scenarios |
| Cross-exchange arbitrage | The same pair is traded on multiple exchanges, and the price discrepancy covers entry and exit costs | Requires synchronous access to multiple quote sources and reserves on each exchange; the discrepancy window does not last long |
What we check before choosing a mode
The common denominator for all three loops is liquidity constraints. An order that was executed instantly in history moves the price on a live market, and slippage eats part of the profit.
Therefore, we run the calculation module on a quote recording with realistic depth, and limit position size by a share of the exchange's turnover, not just by the mathematical optimum of the strategy.
The mode is not necessarily permanent: a typical route is starting in a semi-autonomous loop, confirming statistics on a limited volume, then transferring to autonomous while retaining manual stop.
Describe your strategy — we will return with an assessment of which loop suits it and what limits to set.
Development stages: from strategy analysis to launch
Development of a trading bot begins not with code, but with formalizing the strategy: while the entry and exit rule exists only in someone's head, it can neither be checked nor limited by risk.
Below is the order of work, where each subsequent stage relies on the artifacts of the previous one, so an error in signal calculation is discovered at early steps, not on a live account.
- Strategy analysis. We fix entry and exit conditions, handling of partial execution, and behavior at moments when the order flow breaks.
- Data flow diagram. We determine where quotes come from, how trade history accumulates, and where the boundary between the calculation module and execution lies.
- Module assembly. We implement signal calculation, order management, and logging — so that every decision leaves a trace for analysis.
- Historical data testing. We run the strategy on the accumulated flow, accounting for commissions and slippage; we look not only at the result but also at drawdown.
- Risk limit setup. We set maximum position, daily stop, order count limit, and auto-stop on deviation from calculated behavior.
- Test run on live flow. We work in observation mode without real execution, comparing calculated signals with the actual market.
- Handover and support. We hand over configurations, logs, data flow diagram, and emergency stop procedure; then — a strategy update regulation.
What we hand over at the end: configurations, risk logic, regulations
The project is closed not by demonstrating a working HFT bot, but by handing over a kit that your engineers can use to support it and analyze incidents without us.
The artifacts lie next to the code in the version control system and are updated along with it — otherwise documentation quickly diverges from the actual system behavior.
- Configurations of all modules — strategy parameters, limits, thresholds, timeouts — in versioned files, with an explanation of what each setting changes and where its working range is.
- Data flow diagram from the market data source to order placement: points where a message can be lost or arrive late, and how the system detects this.
- Risk control logic layer by layer: position and instrument limit, daily result stop, automatic order cancellation, and full trading halt under specified conditions.
- Documentation for each module: purpose, inputs and outputs, dependencies, behavior when a neighboring node fails.
- Event log: record composition, detail level, retention period, procedure for restoring the incident timeline from the log.
- Failure procedure: sequence of actions for the on-duty operator, switch to backup loop, rollback to previous configuration.
- Acceptance test bench on historical data: a set of scenarios that must pass before each strategy update.
The kit is designed for independent support: without access to our infrastructure, without verbal agreements, and with a unified procedure for analyzing any failure. Further development of the bot is done by your team — or by us, if you decide to keep support with us.
Case: HFT bot for market making — metrics before and after
What was before
The team maintained quotes on several instruments across three exchanges at once. The trading core ran on a timer: price recalculation and order placement went in a single cycle, without separation into calculation and execution.
On a calm market this did not interfere, but on sharp moves, slippage reached 18–25 basis points, and the number of erroneous triggers — up to 40–60 per day. After a connection drop, the bot was raised manually, and recovery took from 20 to 40 minutes.
Bottleneck
Quote calculation and order sending lived in the same thread. If the exchange responded slower than the recalculation proceeded, the order queue accumulated, and the bot sent them at an already outdated price — hence slippage and extra trades.
There was no automatic protection against a drop: only external monitoring that reported the failure after the fact. The core was assembled on the basis of Hummingbot, but the execution loop was rewritten for its own risk rules.
What was changed and what metrics were obtained
We separated the calculation loop and the execution loop, added a local order book with timestamps and rules for canceling an order by age and deviation from the target price.
The backup communication channel switches automatically, positions are transferred without manual intervention.
- slippage: 18–25 → 3–6 basis points per trade;
- erroneous triggers: 40–60 → 2–4 per day;
- recovery time after a drop: 20–40 minutes → 40–90 seconds;
- share of cancellations that made it before execution: 88% → 97%.
After a month of production operation, the team switched to on-call by deviations: not a single manual restart was required.
What to do if the trading module is already running on the exchange?
A high-frequency trading (HFT) module running on an exchange is not a reason to rewrite everything from scratch.
First, an analysis of the current logic is needed: how signals are formed, where risk safeguards are placed, what happens when the connection to the exchange drops, and how the module behaves on partial order execution.
The audit of trading logic proceeds by actual behavior, not by someone else's documentation.
We take order and trade logs for a representative period, compare them with the declared strategy, and find places where the decision deviates from it: outdated entry conditions, bypassing risk limits, handling of rarely recurring situations after which the position remains open longer than intended.
Modification of an existing module is built so as not to stop trading. Changes are moved to separate layers — signal calculation, execution, position control — and enabled by a mode switch.
New logic first runs in parallel on a shadow data stream and on historical runs; until the results match the expected ones, the previous branch goes to market.
Handover to support is a separate step, and it is not just handing over source code.
A working system is needed: a description of the actual configuration, a data flow diagram, a list of emergency scenarios with a procedure, an update regulation, and a clear rollback point to the previous build.
At the end, the client receives a module that can be changed in parts, not entirely, and a team that understands why a particular decision was made in it. Describe what is already running on the exchange — we will return with an assessment and plan.
Technical doubts before start: delays, limits, reliability
Before start, four things are usually checked: how the exchange limits request frequency, what the bot does on a channel drop, who is responsible for the system after release, and how non-standard the trading interface looks.
Below are short answers; for each exchange they are clarified at the stage of access to the test loop.
How does the bot live within exchange limits?
The exchange limit is not only the number of messages per second, but also daily quotas for cancellations, a limit on the number of active orders, and penalty pauses for exceeding them.
We build our own scheduler with request weights into the core: as the threshold approaches, some orders go in batches, and excess cancellations are rescheduled. The limit stops being a source of random account blocks.
What happens on a connection drop?
The bot keeps a local state log and marks each order with an identifier so that resending does not create a duplicate. After the channel is restored, it reconciles its picture with the exchange's, cancels orphaned orders, and only then returns to trading.
A separate scenario is an emergency "flat mode": closing positions and stopping the strategy without manual intervention.
What is included in support after launch?
We hand over configurations, a deployment diagram, and an on-call regulation; then we run the system according to an agreed response window: we monitor execution delays, the share of rejected orders, and divergence from the exchange state. Alerts arrive before the deviation becomes a loss, and strategy changes go through the test loop.
What if the exchange has a non-standard interface?
Some exchanges provide their own binary format or a limited set of calls instead of FIX. For such cases, we write a separate adapter and run it on recordings of real traffic, including errors and partial responses. A change in the exchange interface is then closed by fixing one module, not by rewriting the logic.
Let's discuss the task: we will send an assessment, plan, and scope of work
We assemble the assessment and work plan from your trading logic, not from a general description of "we need an HFT bot". The first analysis is a short call with your trader or quant: instruments, position holding horizon, entry and exit rules, acceptable drawdown.
Then we proceed step by step, and at each step it is clear what is required from you and what you get at the end.
- Statement of work, 1–2 days. We fix entry, exit rules, and risk limits; the output is a specification that you confirm in writing.
- Data, 2–3 days. Trade and quote history, logs of previous versions, instrument descriptions. Whatever is missing — we calculate from what is available and mark assumptions directly in the assessment.
- Access, in parallel. Broker's test loop, read-only keys and sandbox trading keys, a separate account for checks. We do not request production keys until acceptance.
- Assessment and plan, 3–5 days. Document: stages, result of each stage, team composition, external dependencies and risks with workaround options.
- Historical testing, 2–4 weeks. We run the logic on your data and show where the discrepancy is — in the rules, in the data, or in execution.
The assessment comes as a work plan with team composition and each person's area of responsibility. The handover format is a repository, configuration documentation, launch and rollback regulations; data and access remain with you. Describe the task — we will return with an assessment and plan.