Turnkey development of a cross-exchange arbitrage algorithm

Cross-exchange arbitrage: where profit is lost

Cross-exchange arbitrage looks like the simplest strategy: you see a price discrepancy between exchanges, buy lower, sell higher, and lock in the difference.

In practice, profit is eaten not by the market, but by execution latency — from the moment a quote enters our data stream to the moment the counter order actually lands in the order book on the second venue.

Price discrepancies live for fractions of a second. While the signal reaches the execution module, limit and risk checks pass, and the order is sent and confirmed, the spread collapses and both venues have already rebuilt their order books. We capture not the price we saw, but the one that remains after us.

The second bottleneck is price slippage. The level at which the required volume is visible is usually thin: part of the order is filled at the quoted price, and the remainder at the next, worse prices.

The larger the volume, the more noticeable the gap between the expected and actual average execution price.

The third problem is desynchronization of position state. One leg is executed on one venue, rejected or partially filled on the second, funds are spread across balances, and prices have already moved. A scheme without control of both legs turns into an unplanned position with market risk.

Therefore, work begins not with signals, but with a time budget and liquidity assessment for each venue: how long a full cycle takes, what volume passes without noticeable slippage, and what to do when one leg fails to execute. Below we break down how these points are addressed in the architecture.

Slippage reduction and execution control

An arbitrage trade lives for seconds: the discrepancy between venues opens and closes faster than an operator can glance at the order book.

Therefore, execution is built on rules that trigger without a human — the connection to Binance and other venues maintains a unified quote stream, and the entry decision is made by the algorithm.

Reaction speed to price discrepancies

The signal from the scanner is converted into a pair of counter orders automatically: volume is split between venues based on available depth, not by eye.

Reaction to a discrepancy has been reduced from a manual 20–30 seconds to fractions of a second, and the share of trades closed at the expected price has grown from 60–70% to 90%+.

An order that does not fill at the price is canceled and recalculated rather than left hanging in the order book.

Position risk control

Position limits are set per instrument and venue: the algorithm will not accumulate more than the specified volume, even if the discrepancy looks profitable.

Fees — trading and withdrawal — are factored into the spread calculation, so only discrepancies that remain profitable after all costs are considered.

If one leg fails to execute, the second is closed automatically: the number of unclosed discrepancies has dropped from dozens per month to isolated cases, and the failure class "stuck one-sided position" no longer occurs in well-tested scenarios.

Comparison of cross-exchange arbitrage modes

The mode is chosen not by convenience, but by the lifetime of the trade window: price discrepancies between venues close in seconds, while fund transfers take tens of minutes. Hence four options that are realistically chosen between.

Venue pairs and instrument types

We consider not venues, but their pairs, as working. Spot-spot offers simple logic but requires transferring funds between exchanges; spot-futures and futures-futures allow holding both legs without withdrawal.

The instrument on both sides must match in underlying asset and contract multiplier — otherwise the discrepancy calculation loses meaning.

What imposes limitations: liquidity, limits, withdrawal speed

Order book depth sets the volume limit: slippage eats the spread faster than the position grows. Venue limits restrict request frequency and the number of orders per account, so we filter signals before sending.

Where withdrawal does not fit within the window, we build the setup without transfer — via a futures leg and pre-trade check with recalculation after fees.

How the algorithm is built: stages of engineering work

Cross-exchange arbitrage lives on price differences between venues, and almost all margin is eaten by four things: latency between quote and execution, fees on both legs, order book depth, and partial fills.

Therefore, we do not start with code — first we document what already exists in the infrastructure and data, and only then write the logic. Below is a sequence of seven stages, each ending with a verifiable artifact.

Infrastructure and data audit

1. Infrastructure audit: we review connections to venues, key permissions, request limits, network latency to colocation points, and where position state is stored.
2. Collection and cleaning of historical data: we load order books and trades for the required period, remove outliers, restore gaps, and bring pair symbols and price steps to a unified format.
3. Logic and limits scheme: we describe what we consider an opportunity, the entry threshold taking fees into account, limits per pair and venue, behavior on partial fills, and stop rules.

Backtesting and small-volume testing

• Implementation: we build collection, calculation, and execution modules separately so that failure of one part does not drag down the others.
• Test environment: we run the logic on historical windows, including connection drops and sharp market moves.
• Small-volume testing: we launch minimum trade sizes, compare expected results with actual for each leg and for fee discrepancies.
• Handover and support: we provide documentation, threshold configuration, and the procedure for investigating deviations on the live setup.

After the sixth stage, the gap between calculation and actual execution becomes visible — it determines which thresholds to set and whether to launch the strategy at full volume at all.

Configurations, regulations, and handover documentation

Work is considered handed over not when the algorithm produces its first trade, but when your team can change its parameters, stop it, and restart it without our involvement.

Therefore, the handover package is assembled from the first day of development, not written at the end: configurations are separated from code, and all external touchpoints — exchanges, notifications, access — are described so they can be reproduced on a test bench.

Documentation and response regulations

• Configuration files for each exchange and pair: volume limits, entry and exit thresholds, fee and latency accounting — edited and applied without rebuilding the algorithm.
• Component interaction diagram: quote collection, price discrepancy calculation, execution module, balance control, and reconciliation with exchange reports — with intervals and failure points indicated.
• Event and alert logs with severity levels: trades, exchange rejections, balance discrepancies, channel downtime; export by period for incident investigation.
• Instructions for launch, normal stop, and emergency stop — describing states: where open positions remain and how to close them manually.
• Incident response regulation: sequence of steps, who decides to stop, how quickly we respond, and what data to attach to a request.

Access rights and role separation

• Roles with different scopes of rights: observer, operator, configuration administrator. Changing limits and stopping the module are allowed only for the latter two.
• Exchange keys without withdrawal permission; stored on your side, with only references to them remaining in the configuration.
• Policy for key rotation and access revocation when an employee leaves — documented as a procedure, not a wish.
• Operator action log: who, when, and what was changed in parameters and when the algorithm was stopped.

Case study: transferring positions between exchanges without losses

A trading team held positions on four venues and transferred them manually: the main turnover went through Binance, the rest through less liquid exchanges.

They found a discrepancy in the terminal, withdrew funds, waited for the deposit, and only then opened the second leg — by which time the net price had already moved. During a shift, the on-duty trader managed to act on a few discrepancies; the rest were simply missed.

Before and after

We built a unified quote stream from all venues and calculate the net price taking fees, order book depth, and execution latency into account.

Legs are placed simultaneously, and balances are pre-distributed across exchanges — fund transfers become a rare exception and run in the background without blocking trades.

If the net price goes beyond the threshold, the algorithm does not open a position at all: it is better to skip a discrepancy than to enter at a bad price.

Slippage no longer eats into the result, and operations no longer depend on who is on shift. A log is kept for each pair of orders: you can see where latency occurred and why a trade did not happen.

Thresholds, volume limits, and the list of venues are moved to configuration and can be changed without rewriting the core.

What to do if a bot is already running between exchanges

A bot that already trades between exchanges is not a reason to rewrite the setup from scratch. It serves as a source of requirements: it embeds assumptions about fees, withdrawal limits, order book discrepancies, and the minimum spread at which a trade remains profitable. The task is to extract this logic and verify it against facts, not to guess it anew.

We start with an audit of the current code and execution logs. We reconstruct how the spread is calculated taking entry and exit fees into account, how position size is chosen, what happens on partial fills, and where the canceled remainder of an order goes.

Then we compare the discovered rules with the actual trade history — discrepancies reveal places where the logic was already adjusted manually.

Transferring the state of open positions is done via a snapshot and event log. We record what is open for each instrument on each venue, the average entry price, unfilled order parts, and accrued fees.

We reconcile the snapshot with exchange exports — for Binance and other venues via trade history and balance reports. If reconciliation does not match, the new setup will calculate incorrect returns and make decisions on distorted data.

Taking over control happens without interrupting operations. The new bot is launched in parallel in observation mode: it repeats the old bot's decisions and logs every discrepancy.

When behavior matches over a sufficient trade history, we switch over one instrument at a time — the old bot remains in position-closing mode and does not open new ones.

The reverse operation is returning control for a specific instrument, not restoring from a backup: open positions continue to be serviced, and exchange access keys are not reissued.

Client concerns about reliability and risks

Client concerns are usually the same: what happens if a venue starts lagging, how the algorithm behaves on a sharp move, and whether backtest results can be trusted. Below are answers to the technical questions most often raised before work begins.

Does a venue limit volume or request frequency?

Venue limits are built into the model rather than treated as a failure. The algorithm estimates available volume for each pair, splits large orders, and pauses when approaching the request limit.

When a venue closes a direction, its pair is disabled and the flow is redistributed to the others — without manual intervention.

How will it behave on a sharp market move?

Here the main risk is liquidity: on a sharp move, depth falls and price discrepancy grows faster than the order executes. Therefore, before sending, a check filters out opportunities where the expected difference is less than possible slippage. Some signals do not pass the filter — that is normal operation, not missed profit.

How much can backtest results be trusted?

Backtesting is performed taking fees, latency, and partial fills into account, not on an "ideal" order book fill.

The configuration goes live if the result holds under deliberately inflated costs; if it falls apart, we fix the logic rather than fitting parameters to a nice curve.

Who owns the source code?

The source code, configurations, and documentation are transferred to you — with a description of the logic, failure points, and recovery procedure after a failure. There is no hidden dependency on our side: the system can be developed by your team or another contractor.

Let's discuss the task and come back with a plan

To make the work estimate realistic rather than averaged across the market, we need a minimum of inputs from you. They are enough to calculate labor costs, assemble the team, and avoid including unnecessary stages in the plan.

• List of venues: where you trade now and where you plan to expand — this determines the number of connection modules and the scope of work for each.
• Account types and key permissions: trading, withdrawal, request limits — these determine which actions the algorithm handles on its own and where manual operation is needed.
• Access to venue test environments — we use them to test order placement and cancellation logic without risk to the balance.
• Responsible contacts on the client side: who makes decisions on trading logic and who is responsible for key security.
• Current work in progress — scripts, manual calculations, spreadsheets with spreads and fees: we take them as a basis rather than reinventing.
• Risk boundaries: acceptable drawdown, per-trade limit, algorithm behavior on connection loss and price desynchronization between venues.
• Deployment requirements: your server or ours, whether there are restrictions on network access and action logging.

Describe the task in free form — based on these inputs, we will come back with a scope estimate, a stage-by-stage work plan, and a team composition for your setup.