Arbitrage bots: why most pairs never cover their fees
Where the spread goes in arbitrage — fees, slippage, transfers and funding. A worked example with illustrative numbers and what a bot must check before it enters.
Price gaps for the same asset across different venues are visible almost all the time. Looking at them, it is easy to conclude that an arbitrage bot is a way to collect the difference risk-free. In practice the bot earns not the spread but the spread minus every cost — and once those are deducted, most gaps leave nothing behind.
Here is where the spread goes, and what a bot therefore has to be able to do.
Where the spread goes
Fees
Arbitrage is at least two trades: buy where it is cheaper and sell where it is dearer. A fee is charged on each. In a spot-versus-futures pair the position is later closed with offsetting trades, which makes four.
The fee depends on the venue, the account’s trading volume and the order type. Market orders usually cost more than limit orders, but a limit order is not guaranteed to fill, and in arbitrage speed decides everything.
Slippage
The price you see is the best price in the order book, and it is only available for the volume sitting at that level. If your trade is larger, the order eats through the book and the average fill price gets worse. The thinner the liquidity, the stronger the effect.
Transfers and rebalancing
To buy on one venue and sell on another, you need cash and the asset on both. Trades gradually skew the balances: cash piles up on one exchange, the asset on the other. They have to be evened out with transfers, and transfers come with fees and with time for the price to move.
Cost of capital
Money parked on several venues for arbitrage is not working anywhere else and carries the risk of the venue itself. That is a cost too, even though it does not show up in the maths of a single trade.
Funding
Pairs involving perpetual futures add funding — periodic payments between long and short positions. The rate changes and can turn against your position.
A worked example with illustrative numbers
The numbers below are illustrative: real fees and spreads differ from venue to venue. What matters is the mechanics.
The asset trades at 100.00 on venue A and 100.30 on venue B. The visible spread is 0.30%.
| Item | Share of trade value |
|---|---|
| Visible spread | +0.30% |
| Buy fee on A | −0.10% |
| Sell fee on B | −0.10% |
| Slippage on both sides | −0.08% |
| What is left | +0.02% |
What is left is 0.02%, and that is before rebalancing and the cost of capital. A slightly larger size that increases slippage, or a single transfer between venues, and the trade is in the red. Yet on the ticker it looked like an obvious 0.30%.
Why the visible spread is misleading
- Depth. The price on the ticker is available for a small volume. The real spread for your size is calculated from the order book, not from the last trade.
- Latency. By the time the data reaches the bot and the order reaches the exchange, the price has moved. A spread everyone can see goes to whoever is fastest.
- A leg that does not fill. The first trade goes through, the second does not: the price moved, the order was rejected, the venue stopped responding. Instead of an arbitrage you are left with an open position and ordinary market risk.
That last point is the main danger in arbitrage, and it is where a bot’s quality really shows.
What an arbitrage bot needs to do
- Work out the result before entering — from the order book, with the account’s actual fees, slippage and transfer costs. If it does not come out positive, there is no trade.
- Cap the size at what the order book can actually fill.
- Have a plan for an unfilled leg — retry, close the first trade or hedge — and carry it out on its own, without a human.
- Track balances on every venue and stop if they become skewed.
- Stop on anomalies: sharp price moves, venue failures, conflicting data.
- Keep a log showing what each trade earned after all costs, not by the visible spread.
How to test a pair before building the bot
Before writing the bot, it is worth testing the pair itself on historical data — with costs, not just price differences:
- Collect quotes from both venues over a long enough period, and order book data where available.
- Find the gaps that exceeded the total costs, and for what volume.
- See how often they occurred and how long they lasted.
- Account for latency: how many of them could realistically have been executed on your infrastructure.
Often this step alone shows that the pair does not pay — and it is cheaper to find that out before development than after.
The kinds of arbitrage I build and what the work includes are on the Arbitrage bots page.