The strategy is the part people want to discuss. It is also usually a small file.
The infrastructure around it decides whether the strategy can be run safely at size, and that is where the engineering effort actually goes.
Order state is the authoritative problem
Your system believes an order is live. The venue believes it was cancelled. One of you is wrong and money depends on which.
This happens constantly in crypto because venue APIs are less reliable than traditional market connectivity. Acknowledgements arrive late. Fills come out of sequence. A cancel races a fill and both appear to succeed. A websocket drops during a partial fill.
The only design that survives is a reconciliation loop: continuously compare your view of open orders and positions against each venue, resolve differences, and never assume your own record is authoritative because it was written locally.
Every serious trading system has this. Systems without it work in testing and produce position discrepancies in production.
Risk checks belong in the critical path
Pre-trade, in the path, with no bypass.
- Position limits per instrument and in aggregate.
- Order size caps, because a misplaced decimal is the classic catastrophic error.
- Price sanity bounds rejecting orders far from market.
- Rate limits preventing runaway loops from a strategy bug.
- A kill switch any operator can reach immediately.
Post-trade risk reporting is useful for oversight and it is not a control. By the time it fires, the order has executed.
The kill switch deserves particular attention: it needs to be reachable by whoever is on call, tested, and it must actually stop everything rather than stopping new orders while leaving working ones live.
Market data has to be normalised
Every venue has its own message format, its own conventions, its own quirks about how it reports a book.
Normalising into one internal representation early means strategy code is written once rather than per venue, and it means a new venue is an adapter rather than a change to everything downstream.
Handle sequence gaps explicitly. A missed update means your book is wrong, and a strategy trading against a wrong book will do so confidently.
Build where your edge is
Venue connectivity is a solved problem with competent vendors. Building it yourself is a large amount of unglamorous work that differentiates you from nobody.
Custom earns its place in execution logic, risk parameters, and anything specific to how you actually trade. That is where the edge lives and where a vendor product will not fit.
The sensible split is bought connectivity, built execution and risk.
Backtesting is not testing
A backtest tells you a strategy would have worked on historical data, assuming fills you did not get and latency you did not experience.
What actually validates infrastructure is different: replaying recorded market data through the live system, running in paper mode against real feeds, and starting live at a size where a bug is affordable.
The gap between backtest performance and live performance is mostly infrastructure — slippage, latency, partial fills, rejected orders. None of it appears in a simulation that assumed perfect execution.
Operations tooling is not optional
Whoever runs this needs to see open orders and positions across venues in one place, halt a strategy without halting everything, understand why an order was rejected, and reconcile a discrepancy quickly.
Without that console, operators work through venue web interfaces and logs, which is slow at exactly the moments speed matters most.
Where the line sits
Trading your own book is the lightest operating scope. Serving external clients is considerably heavier, and retail-facing activity heavier still.
Your counsel works out what applies to you. We architect the system to match what they specify — and those requirements reach into reporting, record-keeping and client-facing surfaces, so getting the answer before the build is materially cheaper.
Common questions
What does algorithmic trading infrastructure include?
An order management system holding the authoritative state of every order, an execution layer talking to venues, a risk layer checking limits before anything reaches a venue, market data ingestion, and monitoring. The strategy logic is usually the smallest component. Most of the engineering and almost all of the operational risk sits in order state and risk checks.
Why is order state management hard in crypto trading?
Because venues disagree with you. Acknowledgements arrive late or not at all, fills come out of order, cancels race against fills, and connections drop mid-operation. The system needs a reconciliation loop that continuously compares its view against each venue and resolves differences, rather than assuming its own record is correct.
Where should risk checks live in a trading system?
Before the order leaves your system, in the critical path, with no way to bypass them. Position limits, order size caps, price sanity bounds and rate limits enforced pre-trade. Post-trade risk reporting is useful and it is not a control - by the time it fires, the order has executed.
Should a trading firm build or buy execution infrastructure?
Buy where the venue connectivity is standard and build where your edge lives. Connectivity to major exchanges is a solved problem with good vendors. Custom earns its place in execution logic, risk parameters and anything specific to how you actually trade, which is where the differentiation is.
Does Corum8 build trading infrastructure?
Yes - order management, execution and smart routing, pre-trade risk layers, market data ingestion and normalisation, and the monitoring and operations surfaces. We integrate with venues and with the systems you already run.
