Futures System Development: Where the Trading Core Breaks
A futures exchange rests on its trading core: order book, matching, margin recalculation, and position liquidation are interconnected modules, and desynchronization between them is not immediately visible.
Futures system development usually fails not at the interface but here: some trades are recorded in the order book but not reflected in the user's position, reconciliation shows a discrepancy, and it has to be closed manually, already in live trading.
The discrepancy first appears under peak load. When the price moves sharply, the flow of orders and cancellations grows many times over, the processing queue lengthens, and margin recalculation cannot keep up with the market.
The trader sees one position value, the system holds another in its calculation — and the liquidation decision is made at a price that no longer exists.
Hence an avalanche of liquidations: the engine sequentially wipes out positions at the last trade, without checking the depth of the book and without accounting for the fact that some closures themselves move the price.
The cascade also takes out solvent participants, and the insurance fund does not cover the gap. At the same time, withdrawals stall — the queue is not cleared because the hot and cold accounting balances have diverged and have no unambiguous reconciliation point.
All these failures are design-related, not accidental: they are built in at the moment of choosing the core architecture, margin model, and order processing order. Below we analyze how this is closed — from the accounting scheme to system behavior during peak volatility.
Measurable Effect: Response Speed, Resilience, Order Book Depth
The effect of a futures system is measured not by feelings but by a list of metrics that are taken before release and repeated after each update. Each line below is an acceptance criterion: we record the value at the start of work and defend it at acceptance.
- Response time — the path of an order from acceptance to confirmation and from placement in the book to execution. We look not at the average but at the tail of the distribution: rare slow responses are more irritating than a steady background.
- Share of rejected orders — breakdown by cause: timeout, margin check race, balance desynchronization. Every rejection is logged; the goal is isolated cases instead of a stable percentage of losses.
- Order book depth — density of limit orders at several levels from the best price. It grows when market-maker strategies see a predictable response and are not afraid to place large volumes.
- Load resilience — behavior during an order spike: the system degrades in a controlled manner, cutting off excess, instead of falling. We test with a trading day profile, not a synthetic maximum.
- Recovery time — from node failure to resumption of trading and position reconciliation. Hot standby and automatic failover reduce the pause to minutes.
- Eliminated class of settlement failures — balance discrepancies, double debits, errors in funding rate accruals. Idempotent operations and post-session reconciliation remove them as a class.
The list shows both progress and regression: a metric drop is visible before release, not from trader complaints. We provide external connections via the market standard FIX — response is measured on the live channel.
Implementation Formats: Ready-Made Core, In-House Order Matching, Hybrid
The implementation format is chosen based on two inputs: whether the venue has its own liquidity and support team, and how strictly margin and liquidation rules are defined.
This determines where the boundary lies between the platform and our modules, and which failures each side closes.
Below are four working options and the conditions under which each of them ceases to be convenient.
| Option | When it fits | Limitations |
|---|---|---|
| In-house trading core | Full control over order matching, funding rates, and liquidation is needed, and there is an in-house support team | Time to market is measured in months; fault tolerance and failure recovery are built from scratch |
| Licensed platform | Priority is fast launch and predictable support | Order types, margin logic, and admin panels are limited by the vendor; integration with internal accounting goes through adapters |
| Hybrid scheme | We take the ready-made core as is, while keeping the risk circuit and liquidity showcase for ourselves | Two teams on one circuit: strict boundaries for data and contracts are needed; core updates require regression of our own modules |
| External settlement circuit | Clearing and position accounting are moved to a separate service — unified accounting across venues, transparent audit | Latency on every settlement, dependence on external network availability, instant liquidation is harder to guarantee |
Worth mentioning separately is the combination of a hybrid with an external circuit: order matching remains in the trading core, while position calculation moves outside.
This gives flexibility in accounting but requires separate consistency control — a discrepancy between the core and the settlement service must be detected within seconds, not during reconciliation.
Implementation Stages: From Settlement Audit to Acceptance
Work proceeds sequentially, and each stage is closed with an artifact that the client checks independently. The order is structured so that a calculation error surfaces before live launch, not after the first liquidations among clients.
- Settlement audit. We analyze how margin requirements, funding rate, average position price, and liquidation queue are currently calculated. We record discrepancies between documentation and the working code.
- Integration scheme. We describe the flows between the trading core, risk module, and accounting: where a quote becomes an order, where collateral is recalculated. We agree on the scheme before the first line of code.
- Mode configuration. We set margin tiers, position limits, partial liquidation rules, and instrument parameters. We take values from the audit rather than selecting them by eye.
- Load testing. We reproduce the peak order flow and a sharp price move. We look at where processing latency grows and how the risk module handles mass liquidation.
- Settlement reconciliation. We run historical data and compare collateral, payouts, and commissions against the benchmark for every trade. A discrepancy is an error in the formula, not an acceptable tolerance.
- Handover to operations. We provide configurations, regulations, and monitoring: collateral drawdown, number of liquidations, order processing latency. Plus instructions for the on-duty shift.
Handover Artifacts: Schemes, Configurations, Regulations
We do not close the project with the word "done" — we hand over a set with which your team operates the system, changes parameters, and investigates failures on its own.
All artifacts are written for your circuit: service names, node addresses, and role boundaries correspond to the working environment, not a demo stand.
- Flow scheme — the path of an order from the external gateway to the order book and position calculation: where queues are, at what moment margin is fixed, what happens when the connection to the price source breaks, and where latency arises.
- Environment configurations — separate sets of parameters for test and production circuits: leverage limits, tick size, funding rates, forced-close thresholds. Changes undergo review and are versioned; rollback to the previous set is one command.
- Access policies — a role matrix with separation of duties: who changes risk parameters, who withdraws funds, who only reads logs. A separate item is key rotation procedure and key lifetimes.
- Documentation — description of services and message formats, list of failure points, release rollback procedure, and instructions for the on-duty shift.
- Incident regulations — failure classes, response time for each, escalation procedure, actions for balance discrepancies, and trading suspension procedure.
- Update procedure — how to roll out a new version without stopping trading, who approves the rollout, and by what signs a rollback decision is made.
The set remains in your repository and is updated together with the code — a new team enters the system through documentation, not through stories from those who wrote it.
Case Study: Moving Futures Settlement to an In-House Margin Model
What It Was Like Before the Migration
Margin calculation was handled by an external provider: the exchange sent positions and received collateral requirements back.
During sharp moves, the response arrived with a delay, and some orders were rejected before even reaching the book — at peaks, the rejection rate reached 6%.
Reconciliation was done via exports: it took about 40 minutes after the close of the day, and the discrepancy was found only after it had affected client accounts.
A whole class of failures was especially disruptive — a cascade of forced closes: one liquidation dragged neighboring positions with it, and the chain could not be stopped with standard tools.
What We Did and What Resulted
Settlement was moved inside our own system, and we built an in-house margin model: portfolio calculation across a group of instruments, risk limits, recalculation on every price change rather than on a schedule.
The logic was taken from the practice of derivatives venues — CME maintains a similar portfolio margin principle — and adapted to the liquidity and volatility of the exchange's specific instruments.
Rejected orders at peaks fell below 1%: the collateral decision is made at the moment of checking, without waiting for an external response. Reconciliation time dropped from 40 minutes to 4 and runs continuously — a discrepancy is visible immediately, not the next day.
Cascade liquidations as a class of failures are gone: before liquidation, the system recalculates risk across the entire portfolio and reduces the position in parts, so the chain does not start.
What to Do If the Exchange Is Already Running and Cannot Be Stopped?
Execution cannot be stopped: while the exchange is not running, open positions remain without risk control, liquidations and the funding rate are not calculated, and this already means client losses, not a technical pause.
Therefore, the new futures trading circuit is brought up alongside the running one: both receive the same order flow, but margin, liquidation, and settlement decisions are applied only by the live one — it remains the source of truth until the end of the transition.
While the circuit runs in the shadows, shadow recalculation is performed: on trade history and on the live flow, the new system calculates positions, margin, commissions, and funding, and the result is reconciled line by line with the current one.
A discrepancy in even one digit is a migration blocker, not a reason to "tune it later." Usually the cause is found in rounding, the order of applying rates, or the handling of partial fills.
Instruments are migrated one contract at a time, starting with low-liquidity ones: we open them in the new circuit while keeping limits and maximum position size understated. Then we migrate client groups — first those trading small volume, then market makers.
Each step is a separate window with monitoring for discrepancies, response latency, and rejection rate.
Rollback to the previous circuit remains available at any stage: the flow for an instrument is switched back, positions and history are reconciled, and the client sees neither a quote gap nor an account reset.
This way downtime is reduced to zero, and migration risk is exchanged for a series of verifiable steps.
Technical Concerns: Settlements, Risks, Integrations
Before launch, the client's technical team has questions that are resolved not in presentations but on the bench and in code.
Below are the five most common: settlement reconciliation, safety of open positions during migration, behavior during sharp moves, responsibility for the risk model, and integration with an external settlement circuit.
How do you verify that settlement reconciliation matches?
The event log and balance ledger are written separately, and settlement is periodically replayed from scratch based on the log — the results are compared with the current state by checksums.
Any discrepancy goes into a separate registry with a timestamp and participant, rather than being offset by rounding.
What happens to open positions during migration?
A snapshot of positions, orders, and collateral is taken, the system is switched to read-only mode, then the state on the new version's side is calculated.
Order identifiers are idempotent, so resending does not create duplicates, and rollback returns the exchange to the last taken snapshot.
How does the risk engine behave during sharp market moves?
Pre-trade checks cut off orders before they reach the book, instrument and account limits are recalculated on every price update, and the margin cascade triggers at pre-set thresholds.
We test behavior on historical volatility spikes: what matters is not average load but response time in the worst second.
Who is responsible for the risk model and its parameters?
Rates, margin thresholds, and liquidation rules are agreed with the client and moved into a versioned configuration — every edit undergoes review and leaves a trace in the change history.
The risk profile changes without rebuilding the core, and the selected values can always be matched to a specific version of the rules.
How is the external settlement circuit structured and access separated?
Clearing, a custodian, or a partner bank are connected via a separate circuit on the industry protocol FIX, isolated from the trading core: exchange goes through a queue with confirmations and retries.
Access is separated by roles and keys — the margin operator, support service, and external participant see only their own data and cannot confirm others' operations.
Let's Discuss the Task and Come Back with an Estimate and Plan
To come back with the scope of work and a plan, rather than general wording, we need a minimum of input data on the task statement.
The discussion order is simple: you send a description of the current circuit and requirements, we ask clarifying questions on risk, load, and accounting, after which we fix the scope and plan for the first stage.
- Instrument set: contracts, leverage, expiration dates, margin mode — isolated or cross-account.
- Risk logic: how funding rates, liquidation thresholds, position limits, and tick size are calculated.
- Expected load: peak orders per second, simultaneous connections, required order book depth.
- What is already working: order matching, cash desk, deposits and withdrawals, exchange interfaces, liquidity providers.
- Accounting and reporting: segregated accounts, trade and operation log, exports for audit.
- Constraints: timelines, team composition on your side, access to test environments.
- Acceptance criteria: scenarios that must pass — order spike, node failure, balance discrepancy.
After the review, we will come back with a list of modules, implementation order, and a plan for the first stage.
Usually work goes from trading simulation in the test circuit to a limited set of contracts and then to the full list — this way discrepancies in margin and liquidation calculations are caught before reaching client accounts.