Multi-exchange crypto arbitrage monitoring: example scenario

This page does not describe a real client project. It is an example scenario that shows how Fincode approaches this kind of work. Technical details are based on official documentation; scope, timeline and price are set for each project.

Project summary
Who it is for	Professional crypto trading team with accounts on several exchanges (example scenario)
Service	Algorithmic trading software
Platforms	Crypto exchanges with REST and WebSocket APIs that the team may legally use in its jurisdiction
Technologies	WebSocket streams, local order books, time-series storage, Telegram alerts, monitoring dashboard
Deliverables	Exchange connectors, cost model, opportunity engine, alert dashboard, optional order module, test report

The need

A price gap on screen is rarely an opportunity. Taker fees on both legs, slippage from walking the book at the target size, the fee and duration of moving funds between exchanges, and the price risk during that transfer can all consume it. The team therefore monitors the gap left after every cost, not raw prices; see how a crypto arbitrage bot works for the economics.

Regulation shapes the design too. Which exchanges can be used depends on the team's jurisdiction and each exchange's terms; under Article 99/A of Turkish Capital Markets Law No. 6362, foreign platforms may not serve residents of Türkiye. On platforms licensed in Türkiye, Article 14 of Communiqué III-35/B.2 prohibits leveraged trading, short selling and lending of listed crypto assets. The model in this scenario therefore works with inventory pre-positioned on both exchanges: buy where the asset is cheap, sell existing inventory where it is expensive.

Solution architecture

Component	Role
Exchange connectors	Turn each exchange's WebSocket book stream and REST snapshot into one common format
Normalization	Map symbols (BTCUSDT, BTC-USDT and so on), store prices and sizes as exact decimals, keep event time and receive time separate
Cost model	Account-specific trading fees, per-network withdrawal fees and confirmations, volume-weighted average fill price for the target size
Opportunity engine	Computes the net spread and applies threshold and persistence rules
Alerting	Telegram and dashboard notifications, daily report
Order module (optional)	Two-leg orders within inventory and size limits, kill switch

Keeping order books correct

Each exchange has its own synchronization rules. On Binance, the diff stream is buffered, a REST snapshot is fetched and events up to its lastUpdateId are dropped; if an event's first update ID (U) is greater than the local book's ID plus one, an event was missed and the book is rebuilt from scratch. On OKX, each message's prevSeqId must match the previous message's seqId; as of October 2026 OKX has deprecated its order book checksum, which is now fixed at 0. Kraken sends a CRC32 checksum computed over the top 10 bid and ask levels with each update, and Bybit expects clients to reset the local book whenever a new snapshot arrives. More in maintaining a WebSocket order book.

Connection lifecycles are handled per exchange as well. As of October 2026, Binance keeps a connection open for at most 24 hours and sends a ping frame every 20 seconds; OKX drops a connection after 30 seconds without data and asks clients to send a ping string before then; Bybit recommends a ping every 20 seconds. Connectors open a fresh connection and rebuild the book before the old one expires.

How the cost stack is calculated

The engine does not use the best bid and ask but the volume-weighted average price (VWAP) at which the target size would fill. Fees are never hard-coded: on Binance, account-specific commission rates come from GET /api/v3/account/commission, and per-network withdrawal fees, deposit and withdrawal status and required confirmations from GET /sapi/v1/capital/config/getall.

net = sell_VWAP × (1 − fee_B) − buy_VWAP × (1 + fee_A) − rebalancing_share − safety_margin

Hypothetical example: 1 unit, figures are not any exchange's actual fees
Item	Value
Buy VWAP on exchange A	100.00
Sell VWAP on exchange B	100.40
Gross spread	0.40 (0.40%)
Trading fees (0.10% per leg)	−0.20
Rebalancing share (transfer fee per unit)	−0.08
Safety margin for latency	−0.07
Net spread	0.05

In this hypothetical case, only about 0.05 of the visible 0.40 survives, and no alert fires if the team's threshold is higher. The opportunity must also persist across several consecutive updates, with both books fresh. Because price risk is carried while funds are in transit, rebalancing transfers belong to the inventory plan, not to the per-opportunity calculation.

Risk and security controls

No withdrawal permission: API keys carry read and trade permissions only and are restricted to the servers' IP addresses. The system proposes rebalancing transfers; the team executes them through the exchange interface. On OKX, keys with trade permission and no linked IP expire after 14 days of inactivity, which IP binding also prevents.
Rate limits: Binance returns HTTP 429 when a limit is exceeded, and an IP that keeps going can be banned (HTTP 418) for 2 minutes to 3 days. Connectors track the used-weight headers and take market data from WebSocket rather than REST.
Stale data guard: an exchange whose book has not updated within a set interval is removed from the calculation.
Leg risk: if one leg fills only partially, the open amount is reported and the client's unwind rule applies. When the execution status is unknown, as with a 5xx response on Binance, the order is queried instead of resent.
Limits and kill switch: per-exchange inventory floors and caps, maximum order size, a daily loss limit and a kill switch that stops all new orders in one step.
Market integrity: the system only sends orders that are meant to execute. Wash trading, spoofing with orders placed to be canceled and volume inflation are market abuse and outside the design; Article 18 of Communiqué III-35/B.2 requires Turkish platforms to set trading rules that detect and prevent such conduct.

Testing and go-live

Record and replay: live WebSocket streams are recorded raw and replayed to test the book logic, with sequence gaps, disconnects and checksum mismatches injected on purpose.
Monitoring only: the system first runs without sending orders, reporting how often after-cost alerts occur and how long they last.
Testnets: the order module is exercised on the Binance Spot Test Network, OKX demo trading (with the x-simulated-trading: 1 header) and the Bybit testnet. Binance's Spot Test Network uses virtual balances and only offers /api endpoints, so network and withdrawal data from /sapi cannot be tested there.
Controlled go-live: trading starts with small inventory and size limits, raised only after log review and client approval.

Deliverables

Exchange connectors and a normalized order book service
Cost model with fee, transfer and inventory parameters
Opportunity engine, alert rules and monitoring dashboard
Optional order module with risk limits and kill switch
Raw stream recordings, replay test suite and test report
Operations runbook for key rotation, adding exchanges and incident response

For a single view of balances and positions across accounts, see the crypto portfolio risk dashboard scenario.

How success is measured

Success is judged by accuracy and control, not profit; arbitrage trades can lose money and no software can guarantee returns. The criteria are:

Every sequence gap detected and the book rebuilt in replay tests
Latency from exchange event to alert measured and reported as a distribution
Alerts consistent with the after-cost spread recomputed from recorded data
Inventory and size limits never breached in any test scenario
The kill switch proven to stop new orders on every exchange

Frequently asked questions

Does an arbitrage monitoring system guarantee profits?

No. It calculates price gaps net of costs and raises alerts according to defined rules. Strategy and trading decisions remain with the client, and trades can lose money.

Does the system move funds between exchanges?

No. Fincode does not request withdrawal permission, so API keys are limited to reading and trading. The system reports inventory imbalances and proposes transfers; the team carries them out.

Why is a visible price gap often not an opportunity?

Once taker fees on both legs, slippage at the target size, transfer fees and time, and latency risk are deducted, the gap usually shrinks or disappears.

Which exchanges can a team in Türkiye use?

That depends on the law and the exchange's terms. Under Article 99/A of Capital Markets Law No. 6362, foreign platforms serving residents of Türkiye are acting without authorization, so exchange selection is settled with legal advice at the start of the project.

Sources

Planning a similar project?

Tell us the platform, what the software should do and your timeline in a short form; a written proposal follows the initial review. Fincode is a software company and does not provide investment advice, portfolio management or crypto asset services.

Custom trading bot development Send a project brief