Cross-exchange arbitrage bot: where manual arbitrage pairs fall apart
The spread between venues lives for seconds. While an arbitrageur manually compares order books in two tabs, the difference either collapses due to someone else's order or moves into a zone where the trade no longer covers costs.
A cross-exchange arbitrage bot solves not the task of “finding a discrepancy” but the task of executing both legs of the trade before the window closes.
Manual arbitrage hits three things at once: reaction speed, data freshness, and execution discipline.
The price discrepancy between exchanges that is visible on the screen has already gone stale by the time the order is entered — the order book depth has been rebuilt, and entry and exit fees eat up half the spread.
The wider the spread, the faster someone's bots arrive for it, and the less time remains for a human.
Next comes order execution latency. The legs on Binance and the second venue do not close synchronously: part of the volume is filled, part hangs in the queue, and the position remains open on one side.
Price slippage then finishes off the margin — the actual entry price differs from the one used to calculate the difference, and the trade turns into an unplanned bet on market movement.
The human factor adds missed signals, mixed-up pairs, and incorrectly calculated volume adjusted for venue liquidity. Manual arbitrage therefore scales to one or two instruments and holds only until the first connection failure or the market going into a trend.
Below we break down how this is solved: continuous calculation across multiple venues, execution control for each leg, and automatic rebalancing of balances between exchanges.
What changes after automation: speed, signal selection, risk
Reaction to price discrepancies is the first thing that changes. In manual mode, a trader sees the difference between venues, switches windows, checks available volume, and places an order — this takes several seconds, during which the arbitrage pair often has time to close.
Automation of arbitrage trading reduces signal reaction time to fractions of a second: the discrepancy is confirmed across both order books, and orders are sent to both venues simultaneously rather than sequentially.
Selection of arbitrage pairs stops relying on the last trade price — it shows only that price, but not how much can be bought and sold.
We calculate by order book levels: how much volume is actually available at the required price and how quickly it recovers after being taken, so pairs with a beautiful difference but an empty order book are filtered out before entry.
Exchange fees are accounted for net, not by the quote difference. The calculation includes entry and exit fees, withdrawal fees, and the settlement procedure between venues.
After that, some signals disappear on their own — but closed arbitrage pairs stop going negative out of nowhere.
We keep slippage control at the execution level: order volume is limited by order book depth, orders are limit orders, and an unfilled second leg is handled by a separate rule, because it is what turns arbitrage into a position. We predefine what to do in case of partial execution — chase the market or unwind the first leg.
The disappearing failure classes become measurable: missed arbitrage opportunities, typos in volume, orders left overnight unattended, disputes over “whether there was volume.” Market risks remain, but they are managed by limits, not by human reaction.
We calculate three metrics: average reaction time, share of arbitrage pairs completed to the end, and share of signals filtered out by fees.
Execution options: signal, semi-automatic, fully automatic
The operating mode determines where analytics ends and the trade begins. A signal bot calculates the price discrepancy between venues and provides a ready signal — the decision remains with the human.
Semi-automatic mode fills in the order parameters itself but leaves confirmation to the operator. Fully automatic closes the cycle without human involvement: calculation, placement, execution control, and removal of the remainder.
Infrastructure is chosen for the same choice. Cloud deployment of the service is easier to migrate and restart; a dedicated server gives predictable latency between the signal and order placement. Below are the conditions of use and limitations of the operating modes.
| Mode | When it fits | Limitations |
|---|---|---|
| Signal | Testing the strategy on a live market, manual capital management | Latency between signal and entry eats part of the discrepancy; the result depends on the operator's discipline |
| Semi-automatic | Volume and risk control are needed, but the routine of calculation and parameter substitution is removed | Constant operator presence is required; during sharp market movement, confirmation arrives late |
| Fully automatic | A stable flow of trades where manual reaction cannot keep up with price | Strict requirements for exchange access and limits; protection against a series of losses and a manual stop are mandatory |
The modes are compatible with each other: the calculation and position accounting layer is shared, and the automatic order execution module connects to it as a separate circuit.
Moving to the next level of autonomy does not require rewriting the core — accumulated statistics and configured limits are enough.
Work stages: from venue audit to handover of the circuit
We start with an audit of trading venues: each has its own rate limits, fee tiers, order book depth, and behavior during sharp price movement. This determines where cross-exchange arbitrage makes sense and where the price difference is eaten up by costs and execution latency.
Before code, we fix the trade execution scheme — otherwise the logic becomes patched up at the first failure.
- Venue audit. We collect trading rules for each exchange: minimum order size, available order types, rate limits, settlement procedure. The output is a list of candidate venues and a list of constraints for the logic.
- Trade execution scheme. We design how orders are placed and canceled: simultaneity of legs, what to do if the first leg goes through and the second does not, where we keep the reserve. The scheme is agreed upon before development begins.
- Exchange connectivity. We set up keys with trading permission only, without withdrawal rights, configure streaming channels for quotes and trade confirmations, connection loss monitoring, and automatic reconnection.
- Logic and protection setup. Entry thresholds, liquidity filters, position size limit, stop on balance mismatch, and a full log of bot actions.
- Testing on a test circuit. Run on historical data and in test mode of venues where it is available: we look at behavior during sharp movements, disconnections, and order rejections.
- Handover and team training. Documentation, scheme walkthrough, access, update regulations, and emergency bot shutdown procedure.
After that, the circuit operates on your side: adjustments for new venue rules, adding trading pairs, and incident analysis — by separate agreement.
What remains in the client's circuit: settings, schemes, regulations
The solution is not handed over as a “black box”: along with the working bot, the client receives a set of artifacts that their team can use to operate the system independently, check its behavior, and change parameters without us. Everything related to keys and account access remains in the client's circuit.
- Configurations — a separate set for each exchange and pair: spread entry and exit thresholds, per-trade volume limits, maximum simultaneous positions, list of excluded pairs. Edits do not require a rebuild.
- Solution architecture scheme — modules for quote collection, spread calculation, order execution, and risk control, connections between them, failure points, secret storage locations.
- Failure response regulations — behavior on exchange connection loss, balance mismatch, rejected order: what the automation does, whom it notifies, who stops trading manually.
- Trade log — a record for each leg: time, pair, direction, entry and exit price, fee, result. Export in tabular form for reconciliation with exchange reports.
- Operation manual — start and stop, switching to safe mode, updating the pair list, key rotation, troubleshooting typical errors.
- Access and permissions separation — trading-only keys without withdrawal rights, separate accounts for monitoring and manual operations, secret storage on the client side.
The kit closes the main risk — dependence on the contractor: settings are readable, regulations are reproducible, and the system can be developed in-house.
Case study: how the share of closed arbitrage pairs grew after implementation
The client ran cross-exchange arbitrage between two venues manually: quotes were compared in two terminal windows, and trade confirmation went through two independent interfaces.
In an active market, up to a third of arbitrage pairs did not close — while the price was being confirmed, the difference disappeared.
The share of unclosed arbitrage pairs reached 34%, and the morning review of leftovers took half a shift. The time from signal to both confirmed orders was 4-6 seconds, which on a volatile market was enough for the difference to disappear.
What was changed
We built a trading bot: it maintains local copies of order books on both exchanges (including Binance) and recalculates the net difference taking fees and depth into account.
A signal appears only where the arbitrage pair is fully executable, and balances are reconciled before orders are sent.
If the second leg cannot be filled at the required price, the bot does not chase the market but closes the remainder with a reverse trade and writes the event to the log with timestamps for each leg.
Previously, such a remainder hung until manual review — now the position closes within the same minute.
Over six months, the share of unclosed arbitrage pairs fell from 34% to 9%, reaction time — from 4-6 seconds to fractions of a second, and the number of failures due to unsynchronized balance decreased almost to zero.
Manual work became noticeably less: the on-duty operator reviews notifications rather than the entire trade feed.
A daily summary is compiled from the log: share of closed arbitrage pairs, average shortfall versus the calculated difference, list of legs closed with a reverse trade. Comparison of metrics before and after implementation shows where the difference is still being lost.
What to do if the bot is already running but arbitrage pairs are not closing
An unclosed arbitrage pair is not a bot failure but an execution failure: one leg went through, the second did not. While the second position is open, the decision carries market risk instead of arbitrage profit, and every minute makes the exit more expensive.
We start diagnostics not with the code but with the order log: each signal must leave a trace of identifiers, statuses, and venue responses.
The causes fall into four classes, and the order of checking them differs.
| What broke | How it shows in the log | What we check |
|---|---|---|
| Venue limits | stream of “too frequent” rejections | request window, method weight, reserve for urgent orders |
| Rejected leg | order not created or canceled | available volume, minimum lot, price precision |
| Partial execution | status “partially filled” | remainder, distribution across levels, fill timeout |
| Retries | duplicate orders for one signal | idempotency by client identifier |
Most often, everything comes down to venue limits: request rate, maximum order volume, minimum price step. Some restrictions are not explicitly documented and only appear under load — as with Binance, where weight is calculated separately for each request.
We build a margin into the configuration: an order queue, priority for the closing leg, and a pause instead of hammering on rejection.
Execution retries are the second typical cause. A response timeout does not mean the order was not created: without a client identifier, a retry becomes a duplicate and doubles the position. Idempotent sending and status reconciliation before retry close this class of failures.
We handle partial order execution separately — we fill the remainder with a limit order with a limited time to live or cancel both legs according to an “all or nothing” rule.
Technical concerns: access, failures, limits, responsibility
Before launch, clients check four things: where trading keys live, what happens during a connection loss, how the solution coexists with venue limits, and where the boundary of responsibility lies.
Below are answers without smoothing over the sharp edges, because it is precisely these points that most often determine whether the bot will survive the first week of real trading.
Where are trading keys stored and who has access to them?
Keys with trading permission but without withdrawal rights. Storage is on an isolated node with closed network access: either on your infrastructure or on ours with transfer of control to you.
Keys do not go into the repository or configuration files — only into a secure secret storage, access to which is logged. Rotation is performed after every change in team composition and at your request.
What does the bot do when the connection to a venue is lost?
The position state is not taken from memory but recalculated from actual balances and trade history when the connection is restored.
While the channel is unavailable, new entries are blocked, and unclosed legs are closed according to a rule fixed by you in advance — not based on a guess about price.
Every such episode is written to the log and sent as a notification, so you see not the fact of a failure but its cost in specific positions.
How does the bot stay within venue limits?
Each venue limits request rate, order size, and the number of simultaneously open positions. The bot maintains its own request counter and keeps a margin below the ceiling so that partial execution and a burst of activity do not turn into a block.
As the limit approaches, priority is given to closing positions rather than opening new ones: the pause between retries grows, but risk does not accumulate.
Who is responsible for the result and how is this formalized?
We are responsible for the code, execution logic, and predictable behavior within the boundaries of the parameters you set — this is tested on historical data and on the test circuit of the venues.
Market risk remains on the client's side, and we state this directly in the contract, without vague wording. At the launch stage, you receive a failure action regulation and an escalation procedure.
Let's discuss the task: what to send for an estimate and plan
To come back with an estimate and plan, we need a snapshot of your infrastructure and strategy — without it, any timeline will be pulled out of thin air.
The more accurate the source data on venues and execution rules, the fewer surprises during implementation and the sooner it becomes clear where the strategy hits venue limits.
- List of venues: where accounts already exist, verification levels, available order types, and trading limits for each pair.
- Access: trading keys without withdrawal rights, venue test environments if supported, and your requirements for secret storage.
- Execution conditions: fees for limit and market orders, deposit/withdrawal fees, minimum price and volume step, rate limits.
- Strategy: which pairs and venues are in focus, trade entry threshold, allowable slippage, exit and emergency stop rules.
- Reaction requirements: how quickly a price discrepancy must be responded to, where the bot is hosted, and what latency margin you consider acceptable.
- Accounting and reporting: in what form you need the trade log, per-trade result calculation, and notifications about operational deviations.
Then the estimation order is simple: we analyze the data and confirm the calculation model on historical quotes, build a price collector and execution simulator, reconcile the calculation with real venue conditions, then bring it to a pilot on small volumes, and only after that enable working mode.
We give timelines after the first two steps — usually these are stages of one to two weeks with a clear result at the output of each.
Describe the task and send what you already have — we will come back with an estimate, work plan, and implementation calendar.