Why an arbitrage bot loses profit on sharp market moves
A sharp market move is not a "bad day" but a test of architecture for resilience.
While the arbitrage bot calculates a signal, the price between venues manages to diverge: the spread that existed at the moment the opportunity was detected is already closed by the time orders are placed.
A decision delay of fractions of a second turns into price slippage — the trade executes 0.3–0.8% worse than calculated, and that is enough to wipe out the strategy's profit.
This is especially noticeable on liquid venues such as Binance, where momentum is processed in one or two seconds.
The second point of losses is order execution failure. During momentum, liquidity on one side of the book evaporates, the venue limits request frequency, partial fills occur — and the leg of the pair remains unclosed.
Instead of a neutral position, the strategy owner gets a directional one, and the calculated spread turns into unplanned risk that has to be closed at market.
A separate layer is the model. Trained on calm data, during a volatility spike it sees inputs outside the training sample: confidence drops, the signal arrives late or does not arrive at all.
Then the strategy simply stalls: the bot spends the hours when the market offers the best ratio of movement to costs out of the market — and the losses from such downtime are comparable to a series of losing trades.
We break down how each area is closed: latency budget along the entire path from data ingestion to order submission, execution policy with slippage control, handling of rejects and partial fills, as well as model control loops that take it out of trading when it goes beyond the training distribution.
What changes after implementation: decision speed and risk control
The first thing visible after launch in production mode is signal accuracy.
The model evaluates not only the price divergence between venues, but also the instrument's liquidity, spread width, and execution history of similar trades, so the share of signals brought to an actual trade grows, and false triggers on news spikes are filtered out before order placement.
The second measurable indicator is the share of executed orders. The system calculates available volume in advance, splits a large entry into parts, and recalculates the remainder on partial execution, instead of leaving a hanging order and an incorrect position. The journal shows how many orders are fully closed, how many partially, and for what reason.
Risk control stops relying on operator attention: position limits are set per instrument, per direction, and for total exposure, and near the boundary the volume of the next order is reduced automatically. This caps maximum drawdown from above — it no longer depends on whether a human managed to react.
Strategy resilience is tested across changing market regimes: rising volatility, falling liquidity, diverging quotes. For such periods a protocol is defined — narrowing limits or pausing — so the result does not fall apart on the first non-standard session.
Manual operator interventions are reduced to isolated cases: confirming parameter changes, reviewing disputed trades, reconciling reporting. The system closes the rest itself and records it in the journal.
Exchange connection schemes and trade execution modes
The connection scheme determines where capital is held, who places the legs of the trade, and how much time passes between the quote and actual execution.
An error at this level cannot be compensated by the bot's logic: no matter how accurate the signature the model calculates, the divergence arises at the junction of "saw the price — entered the position." Therefore, the connection option is fixed before choosing the model and trading mode.
| Option | When it fits | Limitations |
|---|---|---|
| Direct connection to two venues: quote stream plus private order channel | full control over entry timing and own risk management is needed | keys and request limits on each side, balance must be maintained on both, latency between venues eats part of the divergence |
| Triangular arbitrage within one venue | capital is concentrated in one place, no transfers between exchanges | narrow set of pairs, high competition, the spread closes faster than the model can act |
| Spot versus futures (basis scheme) | need neutrality to market direction and holding the position longer than a minute | the funding rate periodically changes sign, the margin leg has forced liquidation risk, a collateral buffer is required |
| Execution through an external order aggregator | no own infrastructure and keys, fast launch is important | order queue priority is not visible, third-party rate limits, response latency is entirely outside your control |
The trading mode is selected for the same scheme. Market execution guarantees that the leg closes, but pays a higher commission and sweeps the order book on large volume.
Limit orders are cheaper, but the leg may not fill, and then one side remains open — a classic source of loss in arbitrage. A workable compromise is a limit entry with a timeout and market top-up: the bot waits, then closes the divergence forcibly.
A mandatory element of any scheme is control of partial execution and automatic rollback of the unclosed leg.
Implementation stages: from data audit to handover to operation
The order of work is structured so that logic errors are found before connecting a real account. Each stage is closed with a verifiable artifact — a report, diagram, or fixed limits — and only after that does the next one begin.
- Data audit. We check the history of trades and quotes: completeness, gaps, timestamps, correct accounting of commissions. The output is a report on sample suitability and a list of areas where data is insufficient.
- System design. We fix quote sources, signal calculation, order formation, state and log storage. The design is agreed before the first line of code.
- Risk setup. Limits per position, daily drawdown, number of simultaneous trades, and behavior when connection to the exchange is lost — all in configuration, not in code.
- Historical testing. Run on historical data taking into account commissions and execution latency: we review drawdown, share of unexecuted orders, resilience to market regime changes.
- Shadow mode. The bot calculates signals on live data but does not send orders. The divergence between the calculated price and the actual order book shows where the model overestimates liquidity.
- Handover to operation. Deployment on the target environment, account connection, monitoring and alerts, shutdown protocol. We provide documentation and configurations.
Next comes support: model review when the market regime changes and monitoring of deviations from expected behavior.
What we hand over: configurations, diagrams, protocols, and reports
We hand over the system so that it can be operated, retrained, and stopped by your team — without the engineer who built it. The package includes not only working code but everything needed for predictable operation of the arbitrage bot in production mode.
- Strategy configurations: profiles, entry thresholds, position and daily risk limits, feature set — with notes on what can be changed on the fly and what requires revalidation on history.
- System diagrams: the data path from quote source to trade execution, failure points in each area, connections between models and queues.
- Response protocol: drawdown thresholds, data desynchronization and model quality degradation thresholds, procedure for switching to manual mode and stopping trading.
- Accesses and roles: permission matrix for changing parameters, launching retraining, and viewing reports, key rotation procedure, action log.
- Documentation: description of features and signal logic, quality assessment methodology, retraining and model validation procedure before deployment.
- Reports: summaries on profitability, drawdown, number of trades, and reject rate — daily and weekly, with configuration history.
Each artifact is accepted together with you on a live system: we show how changing a parameter changes the bot's behavior and fix the boundaries of responsibility between your team and ours.
Case study: how we reduced drawdown and eliminated manual interventions
Before implementation, arbitrage between two trading venues relied on manual confirmation: the operator saw a price divergence, checked limits, and placed orders himself.
Reaction took 6-8 seconds — during that time, the divergence was either closed by other orders or went negative. Per shift, 40-60 manual operations accumulated, and drawdown over a long period reached 18%.
What we changed
The cycle was moved to the model: it estimates the expected return of a pair taking into account commissions and order book depth, filters out signals below the threshold, and sends the order for execution itself.
Risk limits — by instrument, venue, and daily drawdown — are checked before sending, so a new position is not opened until the previous one is closed.
- Reaction time: from 6-8 seconds for an operator decision to tenths of a second.
- Share of executed orders: 71% → 96%, the rest are filtered out by order book depth filters.
- Manual interventions: 40-60 per shift → 1-2, only handling of non-standard situations.
- Incident frequency: several incidents per week → one per month, and that one on the venue side.
- Drawdown: from 18% to 6-7% over a comparable period.
Metrics are pulled from the Grafana monitoring dashboard — reaction time, execution share, venue rejects, and current drawdown for each strategy separately. The client sees the same data stream we rely on, so discrepancies in numbers are resolved by facts, not by feelings.
How a machine model differs from hard rules in an arbitrage bot
Hard rules are manually specified thresholds: spread above a given level, sufficient order book depth, accounted commissions, and time to settlement. The logic is transparent: a trade is explained by one condition line, and behavior is reproduced with the same input.
But the market changes regime — liquidity leaves, spreads widen — and thresholds tuned on a past period trigger where there is no longer any buffer.
A machine model, instead of a list of conditions, weighs dozens of features at once: order book microstructure, volatility, history of similar opportunities. It finds nonlinear combinations that cannot be written manually and adapts to regime changes without code edits.
The downside is overfitting: on a short or homogeneous data segment, the model memorizes noise and loses quality on new data.
Therefore, the workable scheme is hybrid logic. Hard rules form the outer loop: exposure limits, liquidity cutoff, prohibition of entry during anomalies. The model works inside — ranking opportunities and choosing the moment.
Then a model failure does not go beyond explicitly set boundaries and does not turn into uncontrolled risk.
Overfitting is kept under control by procedure: the sample is split by time, not randomly, quality is checked on a period the model has not seen, training uses a rolling window, and divergence between forecast and fact is monitored continuously. If metrics drop, roll back to the previous version.
Interpretation of decisions is needed for incident review and risk control: it is visible which features contributed to a specific trade and why the bot entered. Decision logs and clear trigger thresholds make the model's behavior verifiable rather than a black box.
Technical concerns: reliability, risk, and system support
Before launching on a real account, the client checks not forecast accuracy but the bot's behavior in non-standard situations: loss of connection to the exchange, key compromise, strategy failure. Below are answers to four concerns that most often arise at this stage.
What happens if the connection to the exchange is lost with an open position?
Position state and placed orders are written to the journal on disk, not held only in process memory.
If the connection breaks, the bot stops sending instructions, and after recovery it reconciles the actual account with the internal ledger and closes the discrepancy before resuming trading. Duplicate orders, which usually turn a short failure into a loss, do not occur.
How are trading keys protected?
Keys are not stored in code or repository files: they are kept in a secure vault and issued to the process for the duration of operation. Key permissions are limited to trading — funds cannot be withdrawn with it, so compromise does not give access to the balance. Rotation happens without stopping the bot.
What should be done if the strategy stops working?
Trading rules are moved to configuration separately from code, so they can be changed without rebuilding the core.
Before rollout, the new version goes through a run on historical data and a test account; metrics — drawdown, share of canceled orders, behavior under low liquidity — are compared with the previous one. Rollback to previous rules takes minutes.
Who is responsible for failures after launch?
We fix the boundaries before start: our area is execution of instructions, logging, resilience to disconnects, and monitoring with alerts; yours is access, account, and strategy selection. System support includes incident response and planned improvements.
Let's discuss the task and come back with an estimate and work plan
An arbitrage bot is a combination of a model, an order executor, and risk control, so a rough estimate does not work here. To come back with a work plan and stage timelines rather than a range of assumptions, we need to see the data and constraints of the specific setup. Prepare for the conversation:
- list of venues and types of strategy events: quote divergence, line movement, lot mismatch;
- historical data — archive depth, order book snapshot frequency, whether event outcomes are recorded;
- venue and channel constraints: request limits, response latency, order placement methods;
- risk control rules — maximum drawdown, stop conditions, whether a manual confirmation step is needed;
- target metrics: acceptable false signal rate, time from event to order, resilience to connection loss;
- who on the client side validates signals and accepts stages.
This is enough to determine the team composition — data engineer, ML specialist, backend developer, infrastructure engineer — and fix timelines by stage: data review, model prototype, prediction service, integration with venues, monitoring.
We close each stage with a demonstration on your data and handover of documentation: flow diagrams, feature description, retraining and model rollback protocol. Describe the task — we will come back with an estimate and work plan.