Custom trading terminal development: order book, scalping panel, order state and FIX

What does a trading terminal contain?

How does the terminal keep the order book correct?

Exchanges publish the procedure for keeping a local book correct, and it is stricter than it looks. Binance's is typical of the snapshot-plus-updates pattern.

Binance's documented procedure is to open the stream, buffer the events received, get a depth snapshot, discard buffered events already contained in the snapshot, set the local book from the snapshot and then apply updates in order^[1].

Gaps are not tolerated: "If the event first update ID (U) is greater than the update ID of your local order book + 1, you have missed some events. Discard your local order book and restart the process from the beginning."^[1]

Snapshots are bounded: "Since depth snapshots retrieved from the API have a limit on the number of price levels (5000 on each side maximum), you won't learn the quantities for the levels outside of the initial snapshot unless they change."^[1]

Connections are temporary: "A single connection to stream.binance.com is only valid for 24 hours; expect to be disconnected at the 24 hour mark." The server "will send a ping frame every 20 seconds", and a connection that does not answer with a pong frame within a minute is disconnected^[1].

Two engineering consequences follow. Reconnecting is routine, not an incident: a terminal connected to Binance that stays open for a week reopens each stream connection at least once a day, so resynchronisation has to be fast and invisible to the order entry path. And the book is recoverable state with a sequence number, not a picture on screen: while it is resynchronising, the ladder should say so rather than show stale prices as live. Doing this for hundreds of sessions at once is the subject of sequence gaps under bursts.

Why draw frames, not ticks?

A busy instrument sends more updates per second than a display can show. Drawing each one is how terminals freeze during the moments that matter.

• Coalesce, then draw. The market data thread applies every update to the book; the screen reads the latest state once per display frame.
• Keep the UI thread free. Decoding, book maintenance and order handling run off the thread that draws, so a heavy chart never delays an order.
• Measure input to screen. The number that matters to a scalper is the time from a keypress to the order leaving, and from an exchange update to the pixel changing, measured as percentiles, not averages. Why milliseconds matter explains the stages in plain terms.

How does order state survive a reconnect?

The order manager is where the hard cases live, and they are timing problems: two messages crossing, or one arriving late.

• Cancel and fill race. A cancel sent while a fill is in flight arrives too late; the order manager must accept the fill and show the position, not the intended state.
• Replace can be two operations. On some venues a modify is a cancel plus a new order, with a moment in between where neither exists.
• Reconnect means reconcile. In the FIX session layer the counterparty may decline to resend old orders: "the sender may choose not to retransmit them because too much time has elapsed, causing the orders to become stale or no longer acceptable due to a change in market state"^[2]. After any reconnect the terminal asks the venue for the status of every open order instead of trusting its own memory.
• One-click needs limits. Maximum order size, price bands and per-account exposure belong on the order path; pre-trade risk inside the order path covers where each check runs.

Desktop, web or both?

How does a terminal build run?

1. 1.Scope. Venues, instruments, user types, the screens that matter on day one, and the latency target as a number.
2. 2.Core first. Market data client and order manager for one venue, tested with recorded market data before any screen is polished.
3. 3.Screens on the core. Ladder, scalping panel, charts and positions, each reading from the same state.
4. 4.More venues. Each adapter maps into the same internal model and passes the same recorded-data tests.
5. 5.Pilot. Real accounts, limited users, every order event journaled and reviewed.

What should you ask a trading terminal developer?

1. 1.Show a terminal you built running against a live venue, and trigger a reconnect during the demo.
2. 2.What does the ladder show while the book is resynchronising?
3. 3.How are client order IDs generated, and what happens if the same order is sent twice?
4. 4.What input-to-order and update-to-screen latency do you measure, on which machine, at which percentile?
5. 5.Which venues have you connected, and through which APIs or FIX versions?
6. 6.What do we receive at the end, and does any part stay yours?

Who should not commission a custom terminal?

• Traders who need a tool for their own account: an off-the-shelf terminal costs a subscription, not a project.
• A broker whose clients are well served by the platform it already rents; a terminal of your own pays when the screen is part of why clients choose you. What the rented platforms publish is on Match-Trader alternatives and what a brokerage trading platform costs.
• Anyone expecting a terminal to improve trading results. It changes how fast and how safely orders move, not whether they win.
• A team that needs the brokerage stack behind the screen as well: that is a larger scope, set out on trading platform development company.

Product and company names are trademarks of their respective owners and are used only to identify their products. No vendor named here reviewed or endorsed this page.