Building an algorithmic trading stack on our trading platform

We get asked this constantly: why not write everything from scratch in Rust against raw FIX feeds? The honest answer is that our platform already solves a large set of operational problems that would otherwise consume months of engineering — broker integration, order routing, deal history persistence, account state management, VPS hosting, and a stable scripting language with two decades of accumulated patterns.

For a self-trading book in FX, indices, metals and CFDs, our platform sits at a pragmatic sweet spot. Broker coverage is deep. Execution against ECN venues is genuinely low-latency when hosted near the broker's matching engine. The scripting language is mature, statically typed, and capable enough to express almost any strategy we have wanted to run. And nothing in the platform locks us in — every artefact we produce is portable, every line of our scripting language is readable, and our research stack lives entirely outside our platform.

Our platform is not the right answer for every market. US equities and most listed futures live in different stacks for us. But for the book we actually run, the platform is the right tool, and a large number of the criticisms levelled at it tend to come from people who have never operated a serious strategy in production.

Research is fully outside our platform. We use Python — pandas for cleaning, vectorbt and a custom event-driven simulator for backtests, statsmodels and scikit-learn for the modelling work, and notebooks for documenting every hypothesis we test. The simulator is the part most people get wrong: a vectorised backtest is fast but it cannot handle path-dependent logic (trailing stops, scaling in, intrabar fills) correctly. Anything with that shape needs an event loop.

Every strategy candidate has to survive a defined gauntlet before it gets near production. Walk-forward on multi-year out-of-sample data. Cost sensitivity analysis at realistic spreads, not idealised ones. Drawdown distribution analysis, not just headline Sharpe. Regime breakdown — does the equity curve come from one favourable regime or is it broad-based?

What survives the gauntlet is a small fraction of what is tested. That filter is the entire point of the research layer. It exists to kill bad ideas before they cost real money, not to find good ones.

The strategy layer is a portfolio of algorithmic strategies, each one encoding a single well-defined edge. Position sizing, entry conditions, exit conditions, and hard risk limits are coded into the strategy itself — not configured from a parameter file that can be changed without a code review.

We treat each strategy the way a chip designer treats a circuit. Minimal surface area. Single responsibility. No shared state with other strategies running on the same account. If a system breaks, it breaks alone, and the failure is contained to one strategy and one risk envelope rather than cascading across the book.

strategies are versioned in git, reviewed before deployment, and tagged with the research notebook that produced them. Every live deal carries the strategy version it was produced by, so post-trade attribution and incident review are unambiguous.

The supervision layer is the part most retail algo setups skip. It is a separate service — running outside our platform, on different infrastructure — that monitors every account in real time. It can flatten positions, freeze new entries, or kill a strategy outright if exposure drifts outside tolerance.

Critically, the supervision layer has authority the trader does not. There is no intraday override. If the daily loss budget is breached, the book is flat until the next session, regardless of what the trader thinks about the setup. This rule feels paranoid until the day it saves the account, at which point it stops feeling paranoid.

Most large blowups we have studied — retail and institutional — share the same root cause. The risk system was advisory, not enforcing. Building a layer that the trader is structurally unable to override is the single highest-leverage operational decision we have made.

Our platform terminals run on dedicated VPS instances physically close to the broker's matching engine. Latency-sensitive strategies benefit; latency-insensitive ones do not care, but the consistency is valuable for testing. We avoid running multiple unrelated strategies on the same terminal — process isolation is cheap, debugging shared-state weirdness is not.

The Python research layer talks to our platform over sockets and ZeroMQ when live signal handoff is required. Most strategies, however, are self-contained in our scripting language and only talk to the research stack offline, for journaling and performance attribution.

Everything is logged. Every order, every fill, every state transition in every strategy, every supervision-layer decision. The audit trail is searchable and survives the lifetime of the firm. When a strategy misbehaves, the question is not 'what do you remember happening' — it is 'what does the log say'.

We have considered, several times, rebuilding everything from scratch in a more fashionable stack. Each time, the honest assessment has been the same: the marginal value of a custom platform, for the markets we actually trade and the size we actually run, does not justify the engineering cost or the operational risk during migration.

Our platform is, in 2026, the most boring choice we could have made. That is a feature, not a bug. The platform is not where our edge lives — the research, the discipline, and the supervision layer are. The platform's job is to not get in the way, and on that score it has earned its place.