Plataformas · Software · Provedores · Mercados
The cost of choosing badly
A poor order interface choice can cost a broker $100,000 to $500,000 a year in engineering time, connectivity and incident handling. That is a planning range, not an audited result: the total depends on trading volume, asset class, venues and how many environments need support.
The expensive mistake is usually not picking a protocol with a slower benchmark. It is shipping an integration that loses order state, triggers repeated requests or needs manual recovery during a busy session.
Compare the whole operating path, from client submission to venue acknowledgement and back to the client. A protocol can be cheap to integrate and costly to operate.
The cost table below uses typical market ranges in US dollars for one production stack, a single asset class and moderate volumes. It excludes venue fees, market data and major vendor charges. Treat it as an initial budget, then check assumptions against your own connectivity model. For more infrastructure coverage, see Trading Technology.
Separate order entry from market data
REST, FIX and WebSockets are not always interchangeable products. REST is a request-response pattern commonly used to submit, amend and cancel orders. FIX is a message protocol with a session layer designed for persistent trading connections. WebSockets provide a persistent, two-way connection, often used for streaming prices and order updates. Some providers also accept order commands over a WebSocket.
Keep the interface for commands distinct from the feed that reports order state. A successful HTTP response or WebSocket write only proves that a request reached a component. It does not prove that an order was accepted by the venue. Model at least these states explicitly:
- Request sent, with a client-generated order identifier.
- Broker or gateway acknowledgement, distinct from venue acceptance.
- Working, partially filled, filled, rejected or cancelled status.
- Unknown outcome, requiring a lookup or reconciliation rather than a blind retry.
These distinctions matter more than headline throughput. A cancel request can be pending while a fill arrives. Systems that flatten both events into a single status create breaks that operations teams have to resolve by hand.
FIX: more setup, stronger session semantics
FIX gives the connection a defined session model. Sequence numbers, heartbeats and resend requests help participants detect gaps and recover messages after a disconnect.
Execution reports also provide a structured way to carry order and fill events. Those features are useful across broker gateways and institutional counterparties, but they do not remove the need to reconcile business state.
Implementation takes work. Teams need to agree on message versions, tags, session schedules, reset rules, duplicate handling and venue-specific conventions. Certification and separate test environments add time. FIX is a sensible fit for persistent institutional flow or multiple counterparties with established FIX support. It can be excessive for a small product with one API consumer and low order rates.
Budget for session monitoring and replay tests, not just message parsing. A sequence gap must trigger a controlled recovery path.
A disconnect during a cancel must leave the order marked uncertain until the system confirms what happened. Do not interpret a transport-level resend as permission to execute the business action twice.
REST: easy to expose, easy to misuse
REST is straightforward to document, secure and integrate with web and mobile clients. It fits request-response operations and can work well for low to moderate retail order rates. It also gives teams familiar tools for authentication, gateways and rate limits.
The weak point is ambiguity after a timeout. The server may have accepted an order even if the client never received the response. Retrying without an idempotency mechanism can create a duplicate. Require a stable client order ID, support lookup by that ID, and make retry behaviour explicit. A 429 response should feed backpressure, not an immediate retry loop.
Polling order status adds load and delays updates. Use a sensible interval, backoff and server-side limits.
Where updates need to arrive promptly, pair REST commands with a streaming channel or provide a controlled status endpoint. Measure the additional infrastructure and support burden rather than treating each HTTP request as free.
WebSockets: fast updates, stateful recovery
A WebSocket can reduce connection overhead for frequent updates and support low-latency, bidirectional messaging. It is useful for order events, market data and interactive clients that need a live view. But the connection is stateful. Proxies, network changes and idle timeouts can break it, and reconnecting does not automatically restore missed events.
Use heartbeats, bounded outbound queues and explicit subscription state. If the feed provides sequence numbers, detect gaps and request a snapshot or replay. If it does not, reconnect with a full order-state reconciliation. Treat events as potentially duplicated or out of order unless the provider documents stronger guarantees. The order command still needs a client identifier and a way to resolve an uncertain acknowledgement.
WebSockets can be efficient at high message rates, but they shift work into connection management and recovery. For a broker API, test what happens when thousands of clients reconnect together after an outage. A connection limit or queue that works in normal trading may fail during a market open.
Benchmark the full path
Use the following typical market ranges for early planning, not as audited figures or service-level promises. Implementation cost assumes loaded engineering at roughly $15,000 to $25,000 per engineer-month. Annual operating cost covers a moderate-volume production stack, including gateway, monitoring and ordinary network costs; FIX connectivity and certification can push it higher. Latency varies materially with geography, network path, venue and load.
| Interface | Initial implementation | Typical annual operating cost | Typical client-to-ack p99 to test |
|---|---|---|---|
| FIX | $45,000 to $200,000 | $25,000 to $120,000 | 5 to 30 ms on a private or colocated path |
| REST | $15,000 to $75,000 | $5,000 to $30,000 | 20 to 100 ms on a regional service path |
| WebSocket | $30,000 to $125,000 | $10,000 to $50,000 | 5 to 50 ms on a persistent regional path |
These latency ranges are reference points for test design, not protocol guarantees. Benchmark submission-to-acknowledgement and update delivery separately. Include normal load, burst load, reconnects and degraded network conditions. The comparison should cover:
- Record p50, p95 and p99 from client send to broker acknowledgement, then measure venue acceptance separately.
- Test duplicate submissions, delayed responses, partial fills and cancel-versus-fill races.
- Disconnect sessions and streams, then verify gap detection, replay or snapshot recovery.
- Measure rate-limit behaviour, queue depth, CPU and connection counts during bursts and mass reconnects.
- Price support, certification, monitoring and on-call time alongside engineering and infrastructure spend.
The cheapest protocol on a spreadsheet is often the one with the most expensive exception queue. Trading systems have always charged for state, one way or another.
Perguntas frequentes
Is FIX faster than REST for order entry?
FIX often has lower latency on a private or colocated connection because it uses a persistent session and avoids repeated HTTP setup. The network path and gateway implementation usually matter more than the protocol name. Benchmark p99 acknowledgement latency on the route you will run in production.
Can a broker use REST for orders and WebSockets for updates?
Yes. This is a common design: REST handles commands while WebSockets stream order and execution events. Add client order IDs, reconnect recovery and reconciliation so a missed event does not leave the displayed order state stale.
When should a broker choose FIX over a trading API?
FIX is a strong fit for persistent institutional flow, venue connectivity and counterparties that already support the protocol. REST or WebSockets can be simpler for client-facing APIs with lower rates or web application needs. Compare total support and recovery costs as well as implementation effort.
