The Systematic Execution Stack

A good strategy or portfolio can still die with poor infrastructure. The broker, data, hosting and monitoring layer that decides whether a systematic edge survives contact with live markets.

The truth about running systematic money is that the strategy is maybe a third of the job. The rest is infrastructure, and that is what actually decides whether a good edge survives contact with a live market.

Nearly all the effort goes into the signal generation and nearly none into what holds it up. Then you go live and discover that the market is the easy adversary. The hard one is your own setup.

Why does infrastructure decide whether an edge survives?

Because an edge is a statistical claim, and infrastructure is what determines whether you actually get to collect on it.

Your backtest makes a series of assumptions. That the order was sent. That it was accepted. That it filled at, or near, the price your model saw. That your system knew its true position at every moment. That the data feeding your signals was clean. Every one of those assumptions is a piece of engineering in the real world, and every one of them can fail.

When they fail, they fail in exactly the conditions where your strategy has the most at stake, because volatility and volume are what break brokers, feeds and connections. The market gives you the opportunity and the plumbing takes it away.

What actually breaks live that never breaks in a backtest?

A list worth sitting with.

The connection drops while you hold a position, and your system comes back up with no idea whether the exit order it sent was filled. The broker rejects an order in a fast market, and your code, which never modelled rejection, still believes it is in a trade it is not in. A data feed hiccups and prints a bad tick, and your model reacts to a price that never traded. Two strategies both want margin at the same moment and one of them cannot open. A weekend gap moves through a stop that only exists as a mental instruction in your code rather than a resting order at the broker.

Each of these is a specific, boring, solvable engineering problem. Collectively they are the reason a large share of profitable backtests never turn into profitable accounts.

The backtest cannot warn you about any of it, because in the backtest, the order simply just “happens”.

Why is your broker part of the system?

Two brokers, the same strategy, materially different results. The gap is all execution.

Requotes, rejection rates, asymmetric slippage, the exact spread schedule through the day, and how the venue behaves in the seconds around a news release all vary enough between brokers that a strategy can be comfortably viable at one and a slow bleed at another. This is especially true for anything with a short holding period or a high turnover, where cost is a large fraction of the edge.

So I treat the broker as a component of the system. Before I scale anything, I want to know how it behaves on the specific execution I will actually be trading.

The practical version of this is straightforward. Run the strategy small, live, on the venue you intend to use (I use a Darwinex Zero account for my testing, low cost and no capital at risk). Log every intended order and every actual fill.

What is your data actually lying to you about?

More than you would think.

Bar construction differs between providers. So does timestamping, and that is genuinely dangerous. If your data stamps a bar at its open but your code reads the bar’s close to make a decision, you are trading on information from the future of that bar. It backtests great but cannot be reproduced live, because live, that close has not happened yet when your signal fires. I have audited systems for people where this single convention mismatch was the entire edge.

Then there is cleaning. Fill a gap with the next valid price and you have leaked the future into the past. Normalise a whole series before you split it and your out-of-sample has already seen the mean and variance of the test set. Adjust for a roll using information that was not known on the day and your backtest knows things your live system never could.

Every transformation may only use data that was genuinely available at that timestamp. Clean your data as if it is arriving one bar at a time, because live, it is.

And run your backtest on a second provider’s feed before you trust it. If the edge survives on one and evaporates on another, it was keyed to artefacts in that single data source and it was never an edge.

Where should the system actually run?

On something that does not sleep.

For most retail systematic strategies, the real question is uptime. If your system needs to be running when you are not, and it does, then a home machine that reboots for an update, sleeps, or loses its broadband at the wrong moment will eventually do exactly that while you are holding risk. A VPS close to your broker’s server solves this problem: the thing stays on.

Latency matters far less than you think here, unless you are trading very short horizons. For systems holding positions for minutes to days across FX, indices and metals, execution reliability and cost modelling dominate. Milliseconds are rarely the bottleneck. What costs you is order certainty: knowing, at every moment, whether you are actually in the trade your code thinks you are in.

What does matter is redundancy of the boring kind. Alerting that reaches you when you are away from the desk. A way to flatten the book from a phone. Logs you can actually read after the fact, because you will need them.

What does monitoring and reconciliation look like?

Every day, match the fills the broker gave you against the fills your system intended. Every order, every price, every timestamp. The gap between the two is the earliest alarm you will get, if you bother to wire it up.

Slippage that creeps wider over weeks. A fill that keeps landing later than modelled. An order that gets rejected in a fast market with no warning and leaves you flat when you think you are long. All of it shows up in reconciliation long before it shows up in the P&L, and by the time a broken execution path reaches your equity curve it has already cost you real money.

On top of reconciliation, monitor the strategy’s behaviour against its expected envelope, not just its returns. If a system is trading twice as often as it should, or holding for half as long, something has changed in the data or the logic, and it will usually be visible in behaviour before it is visible in profit.

I would rather catch a problem on the morning a single fill drifts than in the month the returns finally do.

What should happen when something fails?

Every failure needs a defined destination.

What separates a resilient system from a fragile one is where it lands when it fails. Everything fails eventually; the design question is the destination. If the connection dies mid-position, does the system come back and reconcile against the broker’s truth before doing anything else, or does it act on a stale internal state? If an order is rejected, does the code know, retry sensibly, and stop after a bounded number of attempts, or does it hammer the venue? If the data feed prints something implausible, does the system trade it, or does it refuse to act on a tick that fails a sanity check?

Define the safe state. Usually that is flat, or held with resting protective orders at the broker instead of mental stops in your code. Then make every failure path lead there.

And put hard limits above everything: a ceiling on simultaneous open risk, a maximum daily loss that flattens the book, a cap on how many orders the system may send in a minute. These are not sophisticated, you can build them in a day.

Common questions

Do I need a VPS to trade algorithmically?
If your system needs to be running when you are not, yes. A home machine that sleeps, reboots for updates or loses its connection will eventually do so while you are holding a position. For most retail systematic traders a VPS is about uptime. The speed question barely applies.

Does latency matter for retail systematic trading?
Unless you trade very short horizons, I wouldn’t worry so much. For systems holding minutes to days, reliability and cost modelling matter enormously, and single-digit milliseconds do not.

How do I know if my broker is hurting my strategy?
Reconcile. Match every fill you received against the fill your system intended, daily. Creeping slippage, late fills and silent rejections appear in that comparison long before they appear in your returns.

Should I run one strategy per account or all of them together?
Together, if you want portfolio-level risk control, because margin and simultaneous exposure are portfolio problems. But log per-strategy attribution, or you will never work out which component is decaying.

What is the most common infrastructure mistake?
Assuming the order filled the way the code intended. The gap between what your system believes its position is and what the broker believes your position is, is where the genuinely frightening losses live.

The market is the easy adversary

There is a version of systematic trading that exists entirely in a backtest, where orders fill instantly at the price you saw, connections never drop, and data is clean. It is a pleasant place and none of us trade there.

The real job is the scaffolding. Reconnection logic that knows the difference between a dropped order and a filled one. Reconciliation that runs every single day. Hard limits on simultaneous risk. Monitoring that reaches you before the damage does. None of it will ever be the interesting part of your work, and all of it is what lets the interesting part pay.

The edge gets you into the game. The infrastructure is what keeps you in it long enough for the edge to matter.

Personal commentary, not advice. Capital at risk.