Most trading engine failures are not execution failures — they are reconciliation failures. The trade happened; the books do not agree on what happened.
A trading engine that routes orders to exchanges but cannot reconcile fills, handle partial fills correctly, manage order state across websocket disconnections, or account for exchange fees in the position ledger is not a trading engine — it is an order submission proxy with unknown financial state. The hard problems in trading engine development are not the exchange API calls. They are: order state management across connectivity failures, idempotent order submission that prevents duplicates, fee model accuracy across multiple exchanges with different fee structures, and a reconciliation process that catches every discrepancy before it becomes a financial dispute. PROPELOO designs trading engines with these requirements as first-class concerns — not afterthoughts discovered in production.
Frequently Asked Questions
What exchanges can you connect to?
Any exchange with a REST and WebSocket API. We have built connectors for Binance, Bybit, OKX, Kraken, Coinbase, Deribit and others. For institutional clients requiring FIX connectivity, we build or integrate FIX engines.
How do you handle exchange API changes?
Exchange APIs change — sometimes with short notice. We version-control adaptor code separately from OMS logic, maintain integration test suites against exchange sandboxes, and monitor for exchange API deprecation announcements. We also build in configuration-driven rate limits so API limit changes do not require a code deploy.
Can the engine support multiple asset classes?
Yes. The OMS and position engine are asset-class agnostic — the exchange adaptor handles asset-specific normalisation. Spot, futures, options and perpetuals can be managed in the same OMS with asset-class-specific position calculation logic.
How do you handle partial fills?
Partial fills are tracked as fill events against an open order. The OMS maintains remaining quantity, average fill price, and total fees paid. Parent orders (bracket, OCO) are updated based on partial fill state. Slippage is calculated against the order arrival price.
What matching algorithms do you implement?
We support multiple execution and matching algorithms: Price-Time Priority (FIFO) for standard competitive markets, Pro-Rata allocation for institutional fixed income/derivatives, and volume-weighted allocation. We also build custom order routing logic including Iceberg orders, TWAP (Time-Weighted Average Price), and VWAP algorithms.
How do you minimize latency and jitter in high-frequency trading (HFT)?
We optimize the engine using memory-aligned C++ / Rust data structures, cache-friendly CPU cache line layouts, zero-allocation matching paths during hot-loop execution, kernel bypass networking (Solarflare OpenOnload / DPDK), and dedicated CPU core pinning to maintain sub-10-microsecond matching latency.
What pre-trade risk controls and fat-finger protections are enforced?
Every inbound order passes through an inline, microsecond risk engine before hitting the order book. The system validates account margin adequacy, price collars (rejecting orders deviating excessively from current mid-price), maximum notional order sizes, short-selling restrictions, and credit limit utilization in real time.
Can the trading engine connect with FIX Protocol and low-latency WebSockets simultaneously?
Yes. We architect dual gateway topologies: FIX 4.2 / 4.4 / 5.0 engines for institutional broker and proprietary trading desk integration, alongside ultra-high-concurrency binary or JSON WebSocket gateways for retail and programmatic algorithmic traders.
