# Multi-exchange crypto arbitrage monitoring: example scenario

URL: https://fincodelabs.com/en/projects/multi-exchange-arbitrage-monitoring · Publisher: Fincode (Fincode Yazılım ve Teknoloji A.Ş.), Istanbul, Turkey · Published: 2026-10-24 · Updated: 2026-10-24

In this example scenario, a professional trading team wants to watch the price of the same crypto asset on several exchanges in real time and act only when the gap exceeds the full cost stack. The system keeps order books in sync over WebSocket, prices in fees and transfer costs, raises alerts and can optionally place orders within inventory limits.

> 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](https://fincodelabs.com/en/blog/crypto-arbitrage-bot) 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](https://fincodelabs.com/en/blog/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

1. **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.
2. **Monitoring only:** the system first runs without sending orders, reporting how often after-cost alerts occur and how long they last.
3. **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.
4. **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](https://fincodelabs.com/en/projects/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

- [Binance Spot API: WebSocket streams and local order book management](https://github.com/binance/binance-spot-api-docs/blob/master/web-socket-streams.md)
- [Binance Spot API: REST API (depth, commission rates, 429/418 limits, 5xx)](https://github.com/binance/binance-spot-api-docs/blob/master/rest-api.md)
- [Binance Wallet API: All Coins' Information (per-network withdrawal fees and confirmations)](https://developers.binance.com/en/docs/catalog/core-trading-wallet/api/rest-api/capital#all-coins-information)
- [OKX API v5 (WebSocket ping, order book seqId/prevSeqId and checksum, API key security, demo trading)](https://www.okx.com/docs-v5/en/)
- [Bybit V5: Orderbook WebSocket](https://bybit-exchange.github.io/docs/v5/websocket/public/orderbook)
- [Bybit V5: WebSocket connect (heartbeat, testnet URLs)](https://bybit-exchange.github.io/docs/v5/ws/connect)
- [Kraken: Book checksum (WebSocket v2)](https://docs.kraken.com/exchange/guides/websockets/book-checksum-v2)
- [Binance Spot Test Network](https://testnet.binance.vision/)
- [Capital Markets Law No. 6362, Article 99/A (Turkish)](https://www.mevzuat.gov.tr/mevzuatmetin/1.5.6362.pdf)
- [Official Gazette: Communiqué III-35/B.2 on crypto-asset service providers, Articles 14 and 18 (Turkish)](https://www.resmigazete.gov.tr/eskiler/2025/03/20250313-6.htm)

---

Published by Fincode (Fincode Yazılım ve Teknoloji A.Ş.), a software company in Istanbul, Turkey: https://fincodelabs.com/en/projects/multi-exchange-arbitrage-monitoring