Trading Terminal Development: Where Custom-Built Systems Break
A custom-built terminal almost always starts as a thin wrapper over exchange interfaces: order book subscription, order submission, local tracking of positions and balances.
On Binance and other major venues, such a prototype can be put together in a matter of weeks and genuinely works in a calm market. It breaks in the very first volatile session — and not in minor details, but in three or four predictable places.
Quote desynchronization occurs because the trade stream, order book, and private events travel through different channels with different latency.
If, when the connection drops, the terminal reconnects without requesting a full order book snapshot and rebuilding local state, a "hole" remains in the history: the interface shows one price while execution happens at another.
The trader makes a decision based on an outdated picture, and this is no longer a display cosmetic issue.
Lost orders are the second classic. An order was sent to the exchange, the connection dropped before the response, and the terminal doesn't know whether the order was accepted or not.
Without an idempotency key, a resend creates a duplicate; without reconciliation against the execution log, a "hanging" position remains in the system, and it is noticed only via margin.
Peak load finishes off what remains.
During a sharp move, the update rate grows by an order of magnitude, the event queue grows faster than the interface can process it, and pre-trade checks — per-instrument limit, maximum position size, slippage control — usually do not exist at all in a custom-built system.
Positions are reconciled manually, and discrepancies surface the next day. We'll break down how each of these failure classes is closed architecturally.
What a Production-Grade Terminal Provides: Speed, Resilience, Control
Order execution speed is assessed not by average response time, but by the tail of the distribution — the share of orders that stayed within the target threshold during peak load.
In a managed terminal, the hot path for placing and canceling orders is separated from analytics, history, and reporting: growth in the number of instruments and market data subscriptions no longer blurs the response of the trading core.
Terminal fault tolerance is verified by scenarios, not promises: loss of connection to the exchange, core restart, discrepancy between local and exchange state.
After a failure, the terminal reconciles positions and active orders against the operations log, completes what remained in an unfinished state, and cuts off duplicates — the failure classes "duplicated order" and "lost position" are eliminated from operations.
Limits and risk control trigger before an order reaches the exchange: per-instrument volume, total directional exposure, order placement frequency, and auto-stop after a series of losing trades are checked.
Rules are versioned, changes go through approval and are recorded in the log — you can see who weakened or tightened a restriction, and when.
Trading monitoring is built on on-duty metrics: share of executed orders, placement and cancellation time, depth of discrepancy with exchange state, number of rejections by risk rules. Thresholds are set so that the signal arrives before a discrepancy turns into a loss.
A terminal should be accepted along these four axes — with measured numbers, not claimed functionality.
Operating Modes: From Scratch, Enhancing an Existing Platform, Hybrid Scheme
The three modes differ not in the amount of code, but in who owns the core and how much time passes before the first real order.
The mode is chosen based on two signs: whether there is already a working product with live users, and how non-standard the execution and funds accounting logic is.
A separate axis of choice is connectivity to trading venues. Each new exchange means its own set of keys, limits, order formats, and balance reconciliation rules; this is exactly where modes are most often mixed so as not to rewrite an already working module.
| Option | When it fits | Limitations |
|---|---|---|
| Development from scratch | You need your own execution logic, non-standard risk contour, or a unified interface for several venues at once | Longer to first release: the core and connectors are written, tested, and debugged under load from scratch |
| Enhancement of an existing platform | The foundation already works; the task is to add venues, instruments, reporting, or fix behavior under peak load | You inherit the vendor's architecture, data schema, and licensing restrictions; some changes run into closed code |
| Hybrid scheme | The critical module — matching, portfolio, risk control — needs to be your own, while the rest is faster to take ready-made | A clear boundary is required between your core and external modules; without a stable exchange protocol, maintenance becomes more complex with every update |
A practical guideline: while the bottleneck is in one module, enhancement is enough; when limitations start dictating the product rather than the task, we move to a hybrid or to our own core. Next we'll break down exactly what we verify on each of these paths.
Workflow: From Order Logic Audit to Handover to Operations
A terminal is not an interface on top of exchange connections. The main work happens in order logic: order lifecycle, partial fills, cancellations, resends on connection loss.
Below is the route we follow in trading terminal development so that no untested scenarios remain by launch.
- Trading logic audit. We analyze the current contour: which order types are used, how partial fills are processed, where state is lost when the channel drops. We record discrepancies between terminal accounting and actual positions at the venue.
- Integration scheme. We describe connections to trading venues, quote and trade streams, storage of access keys, user roles. We agree on the scheme before code — redoing the exchange layer costs more than anything else.
- Core setup. Order queue, duplicate protection, risk limits per account and instrument, position reconciliation rules, and state recovery after reconnection.
- Load testing. We reproduce quote spikes, venue response delays, and channel breaks: we monitor whether duplicate orders and balance discrepancies appear.
- Terminal acceptance. We run scenarios on real but limited volumes, reconcile reports, and close remarks on logs and error handling.
- Handover to operations. We provide documentation, accesses, monitoring with failure alerts, and support instructions; we stay in touch during the first days of operation.
Handover Package: Configurations, Integration Schemes, Regulations
Terminal handover is not an archive with code, but a package by which your team can bring up a stand, investigate an incident, and release without us. We accept work according to a checklist.
- Environment configurations. Test and production environments: limits, commissions, trading pairs, exchange connection parameters. Each parameter has a purpose and consequences of error.
- Integration schemes. The order path from interface to exchange core: queues, confirmations, resends, failure points. Next to the code, so edits go together with the system.
- Access rights matrix. Roles from trader to administrator and auditor: allowed operations, where a second confirmation is required, who sees balances. Separately — fund withdrawal and limit changes.
- Operations regulations. Updates, restarts, actions for balance discrepancies and stuck orders. With criteria: when the on-duty operator stops trading, and when they fix it on the fly.
- Support instructions. Typical failures — stream break, exchange interface unavailability, queue growth: what to look at in logs, which metrics to collect, whom to escalate to.
- Terminal documentation. Module composition, internal interface contracts, message formats, load limits — so a new engineer can enter the project without the author.
- Deployment and recovery. Manifests, network schemes, environment variables, migration order, backup, and a proven recovery procedure on a clean environment.
Rules and schemes are versioned together with code; we review regulations after major releases. If during acceptance an artifact diverges from the system or is missing, we supplement it.
Case Study: How We Eliminated Order Losses at Peak Load
A terminal with instant order placement worked with several venues, including Bybit.
In a calm market everything reconciled, but at volatility peaks up to 6% of orders either did not reach the exchange or hung in an intermediate status: the trader saw "sent", while the order was not in the order book.
We broke the cause into three parts. Resending on connection loss created duplicates, the connection was restored without catching up on missed events, and discrepancies were caught manually — 3-4 hours of reconciliation per day, and there was still a tail of unresolved cases.
What We Changed
Each order was assigned an idempotency key: a retry on a network error does not create a second order but returns the status of the first.
A local state log and reconciliation with the exchange on reconnection closed the catch-up of missed events, and a separate queue with priority for order cancellation stopped being blocked by the stream of new orders.
| Metric | Before | After |
|---|---|---|
| Lost orders at peak | 4-6% | 0.1-0.3% |
| Recovery after connection loss | 40-90 seconds, partly manual | automatically, 2-3 seconds |
| Duplicates on resend | several per shift | 0 |
| Manual reconciliations | 3-4 hours per day | only discrepancy investigation |
Peak failures stopped being a separate class of incidents: order cancellation goes through even on an overloaded channel, and after a failure the terminal itself brings local state in line with the exchange state without requiring on-duty intervention.
What to Do If a Ready-Made Solution Is Already Deployed and Working?
A deployed terminal is not a sentence to rewrite. First, an inventory: which nodes are isolated, where state is stored, whether there are contracts between modules and tests for them. If boundaries exist, evolution proceeds pointwise and without stopping trading.
Pointwise extension — a new module is brought up next to the core: algorithmic orders, a second liquidity source, a separate risk contour. Node replacement — when one component cannot handle the load, only it is changed: exchange gateway, order router. Phased migration is needed when the core itself changes — matching or the balance subsystem.
We carry out migration through dual writes and a shadow run: the new node computes in parallel with the old one, and discrepancies are investigated before switching. We shift traffic canary-style, by share of users, with rollback to the old branch in one command.
Replacing a contractor in this scheme is not a separate project, but acceptance: reproducible build, contract tests, deployment scheme, and accesses.
If modules are isolated, a new contractor enters the system without stopping trading, and terminal expansion becomes planned work rather than emergency recovery.
Technical Questions: Data Stream, Orders, Fault Tolerance
Doubts before starting are usually the same: how quickly data reaches the terminal, what happens to an order when the connection drops, whether the system will survive a node failure, who has access to trading, and how long implementation takes. Below are direct answers on each point.
Are quotes delayed?
Data flows continuously rather than being polled once per second: the terminal receives order book and trade updates as they appear on the exchange. When the channel drops, it reconnects and loads missed events by sequence numbers, so the order book does not diverge from reality.
Can an order execute twice during a failure?
Each order goes out with a unique key, and a resend after a drop does not create a duplicate. State is derived from the exchange event log, not from application memory, so partial fills and cancel-replace are reflected correctly.
What happens if a node goes down?
The application and exchange gateways are duplicated, and traffic automatically moves to a live node. The user session and open positions are restored because state is stored outside the process, not in its RAM.
Who will get access to trading?
Roles are separated: trader, risk manager, administrator. Exchange keys are issued with trading-only permission, without fund withdrawal, and every action is recorded in the audit log.
How long does implementation take?
The first working contour with one exchange and basic order types is put together in a few weeks. Each subsequent exchange is a separate cycle: its own request limits, response formats, and execution specifics.
Let's Discuss the Task and Come Back with an Estimate and Work Plan
To discuss the task substantively and base the project estimate on facts, it is enough to send inputs on the product and infrastructure for the first conversation.
A formal technical specification is not needed — a description of trading scenarios and current work, if any, will suffice.
- List of exchanges and connection methods: public quotes, private account operations, number of trading pairs.
- Order types: market, limit, stop, linked orders, partial fills, cancellation rules.
- Accounting and reporting: balances and accounts, commissions, trade history, reconciliation exports, access roles.
- Key management: where exchange keys are stored, whether hardware signing is needed, how fund withdrawal is restricted.
- Load and latency: how many concurrent users, how quickly the order book updates and an order triggers.
- Interface and integrations: web, desktop, or mobile app, charts, notifications, external services.
The first conversation follows engineering logic: we analyze trading scenarios and, separately, system behavior during venue failures and state recovery after a failure.
Then we name the team composition for the task: who handles integrations, who handles accounting and settlements, who handles the interface. As a result, we send a project estimate with a work plan — stages, dependencies, acceptance points. Describe the task — we'll come back with an estimate and a plan.