Trading stack · Engineering
Building a Trading Engine That Can Survive and Adapt
The strategy is one lit room. The engine is the building — built to keep standing when a piece fails and to grow when the market changes shape.
Trading stack · Engineering
The strategy is one lit room. The engine is the building — built to keep standing when a piece fails and to grow when the market changes shape.
In brief
In June 2026, Bloomberg reported that Blackstone is in talks to anchor a new quant fund with roughly $300 million. The founder spent nearly two decades at Two Sigma, most recently leading Asia-Pacific investment strategies. The track record is real. The capital is institutional. The pedigree is about as good as it gets.
The fund reportedly doesn’t expect to trade until the second quarter of 2027.
Not because the strategies aren’t ready — the strategies are the one thing an operator at that level carries with her. The year goes to everything underneath: data feeds, modeling systems, execution capabilities, compliance gates. A dollar can’t move until the machine that moves it exists.
If the infrastructure tax is real at that level — proven operator, anchor capital, nothing left to prove — it’s real for everyone. This piece is about what that machine actually is: what you’re building when you build a trading engine, where the calendar actually goes, and why the system that wins isn’t just the one that works today — it’s the one built to keep working as the market underneath it changes shape.
The common misconception is that a trading engine is code that sends orders when a signal fires. Exchange APIs are public, a weekend of work has always gotten you a bot that trades — and in the agent era it’s an afternoon: ask an AI to vibe-code a trading bot and it will, competently. The feeds are full of exactly that now — weekend systems with backtest screenshots and “goodbye, Two Sigma” captions. Some of them will get trusted with real money. The interesting question arrives later: the first partial fill during a websocket drop, the first venue error code no tutorial mentions — capital at risk, the bot doing something its author can’t explain, and no kill switch to reach for. A bot that trades was never the hard part.
That bot and a trading engine are different objects. A trading engine is a system that turns market data into positions, continuously, under constraints, with no human in the hot loop — and keeps behaving correctly when a feed dies, a venue lies, a fill goes missing, or a deploy goes wrong. The strategy is a tenant. The engine is the building: the plumbing, the wiring, the alarms, the structure that determines whether a fire is an incident or a total loss.
The difference between them is the difference between rent and equity. Tenants churn — every strategy decays, gets crowded, gets replaced; no lease is permanent. The building is the long-lived asset, and unlike the tenants it compounds instead of decaying: every venue integrated is capacity, every incident survived becomes a control, and each generation of the engine is built on the scars of the last. Strategies pay the rent. The building is the equity.
Before walking the floors of that building, the vocabulary — five concepts, built from first principles, that everything below stands on. If you trade for a living, skip ahead.
A market is a matching problem. Trading is two parties agreeing to exchange at a price. Everything else is machinery for finding that agreement. On an exchange, the machinery is the order book: resting buy orders (bids) and sell orders (asks), stacked by price. The gap between the best bid and the best ask is the spread. Most venues match by price-time priority — better price goes first; at the same price, whoever arrived first. Not every market runs on a book: in over-the-counter trading, a participant requests a quote (RFQ) from dealers and trades bilaterally — common for large blocks and less liquid assets. This piece lives in the order book.
An order is an instruction. What to trade, which direction, how much, at what price — and how: a market order takes whatever price is available now; a limit order trades only at its price or better, and rests in the book until it does. An order isn’t a trade. It’s a request that the market may grant, partially grant, or ignore.
A fill is what actually happened. The market’s reply to an order — possibly in pieces, possibly late, possibly never. The distance between the price asked and the price filled is where trading costs live, and most of what a trading engine does is manage the space between order and fill.
Every trade has a maker and a taker. The maker’s order was resting in the book — it made the liquidity. The taker’s order crossed the spread and consumed it. Venues price the two roles differently, and the difference — a few basis points per trade — decides the economics of entire strategy classes. Hold that thought.
A position is derived state. A position is the net of every fill an account has ever had — a conclusion computed from evidence, not a number written down. P&L stays unrealized until the position closes. The distinction sounds academic until the evidence and the conclusion disagree, which is what half the machinery below exists to catch.
That’s the vocabulary. Five concepts — enough to follow one order through the machine.
The honest way to show the build surface is to walk the path a single order takes. Every stop is a subsystem you have to build, and every subsystem has one problem that looks trivial from outside and isn’t.
Market data in. Streams from every venue, normalized into one internal language. Each venue has its own dialect — different message formats, different depth semantics, different notions of a timestamp. The hard problem isn’t parsing; it’s freshness: detecting that a feed which is still connected has quietly stopped telling you the truth. A stale feed looks exactly like a calm market until you trade against it.
Signal. The smallest box in the diagram — a function from data to desired position. In a real engine this is deliberately thin: the same strategy code should run against the backtester, the paper environment, and live without modification, or you can never trust what your backtest tells you. Most of what makes a signal safe to run lives outside the signal.
Pre-trade risk. Before an order leaves, it passes the checks: position limits, notional bounds, price sanity, rate budgets. The hard problem is that these checks sit in the hot path — they have to be strict enough to matter and fast enough that you’d never be tempted to bypass them. A risk check that traders route around is decoration. And note what pre-trade checks assume: that the order is the danger. That’s the easy half of risk management — the hard half comes later, when the system itself is what’s wrong.
Execution. The order state machine is bigger than anyone expects: acknowledged, partially filled, amended, cancel requested, cancel rejected because the fill beat your cancel, expired, rejected with an error code the documentation doesn’t list. Multiply by every venue’s own interpretation. The hard problem is idempotency under uncertainty — never re-sending an order because you weren’t sure, never losing one because you were.
Fills, positions, P&L. Fills arrive out of order, duplicated, or occasionally not at all. Position must be derived from a truth you can defend, not from what the strategy believes it did. The hard problem: your book and the venue’s book are two different documents that agree only if you force them to.
Reconciliation. The subsystem nobody puts on the architecture slide. Continuously compare internal state against every external source of truth — balances, positions, open orders — and treat every mismatch as an incident until explained. Run it nightly and you find out about drift the next morning; at trading speed, the next morning is archaeology.
We’ve met the two-documents problem in its purest form. A verification sweep flagged that one venue held about seventeen dollars more of one asset — and correspondingly less of another — than our books said, on an account trading normally. Nothing else was wrong. No error had been logged, no warning, nothing: an order had reached its terminal state with a fill missing, and every layer downstream had accepted the story. Seventeen dollars is not the point. The point is that the drift was silent — and a book that can silently drift by seventeen dollars can silently drift by any amount. The verifier that treats a $17 mismatch as an incident is the same one that catches the $17,000 one.
That’s one order. The engine is that path, hardened, multiplied by every venue, running unattended for years.
Everything above describes a build surface. It says nothing about the ground it stands on, and in this industry the ground moves.
Traditional finance’s plumbing is old and it barely changes. FIX, the protocol most exchanges and brokers still speak, dates to the early 1990s. Clearing, settlement, and market structure shift on a regulatory clock, measured in years. You can build against that surface and reasonably expect it to look the same in five years.
Crypto makes no such promise. A venue changes its API with no deprecation window, ships a new order type, loses a banking rail, or disappears over a weekend. Some of the instruments themselves are still new — perpetuals and funding-rate mechanics don’t have a decades-old rulebook behind them. The industry isn’t settled yet, and an engine built as if it were is the thing that breaks the day it doesn’t hold still.
Two properties follow, and neither is optional.
Extend or replace, without a rewrite. A new venue, a new instrument, a rate limit that changed overnight — the engine has to absorb it as a new implementation behind an existing seam, not a change to the seam itself. The practical version is one internal interface per concern: one for market data, one for order management, one for accounting. Every venue speaks its own dialect at the edge, and translates into the same shape before anything else touches it. Build it any other way and every new venue becomes a special case threaded through strategy code, risk code, and reconciliation code — and the tenth integration gets more expensive instead of less.
Assume failure, don’t hope it away. A feed disconnects mid-session. A message arrives malformed. A venue acknowledges an order it never intended to fill, or fills one it never acknowledged. None of that is exotic in a young industry — it’s Tuesday. The reconciliation loop above, which treats a mismatch as an incident rather than a rounding error, is one version of this posture; the kill switch below, which has to fire with no one watching, is another. The same posture has to run underneath every interface, not just the risk layer. An order interface that assumes a venue’s acknowledgment is truthful, or a market-data interface that assumes a still-connected socket is still telling the truth, will eventually be wrong in a way nothing catches.
Accounting is where this gets tested hardest, because the industry hands you a dozen-plus venues with a dozen-plus ideas of what a balance, a fee, and a transfer look like, and only one ledger is allowed to be right. The discipline that makes drift visible instead of assumed is the oldest one in finance: every fill is a debit and a credit, the two sides have to balance, and an entry that doesn’t is a bug, not a rounding difference. A unified accounting interface is what lets that many venues’ worth of diversity collapse into one set of books — the same kind of books where our own seventeen-dollar drift was caught as the incident, instead of surfacing later as the seventeen-thousand-dollar one it could have become.
Everything above is the system working. The harder half of risk management is the system wrong: a bug in a fresh deploy, a feed that’s quietly lying, a venue that stopped answering, a position that isn’t what the engine believes it is. Pre-trade checks can’t help here — they validate orders, and the orders are no longer the problem.
In Why Trading Firms Die we made the point that mistakes compound in milliseconds: in most businesses the loop between error and consequence is measured in sprints; in trading, a bug that runs for 45 minutes can end the firm. The corollary for engine design: when something goes wrong at machine speed, the response has to happen at machine speed. A human noticing, understanding, and deciding takes minutes on a good day — and minutes is the reaction time of someone who happened to be watching while the failure compounded in milliseconds.
Two capabilities decide whether a run-time failure is an incident or an ending.
An automatic kill switch. The engine must be able to take itself off the market — no human in the loop, no permission sought. In practice that’s tiered: halt one strategy that’s misbehaving, stop quoting one venue that is, or stop everything. Two hard problems. First, deciding wrongness from noisy evidence fast enough to matter — too sensitive and it halts on every hiccup, too tolerant and it watches the fire spread. Second, making it safe to fire: halting with open positions is itself a risk decision — freeze or flatten — and a kill switch the team hesitates to trust might as well not exist. There’s a trap inside that decision, too: flattening assumes the engine knows its position, and if the state is what’s wrong, closing “the position” can double the mistake instead of ending it. This is how failures cascade — a wrong book drives a wrong intervention, which creates a new wrong position, and each corrective step digs deeper. The kill switch has to reckon with the possibility that the thing it’s protecting you from is the thing it would use to protect you.
Observability. The kill switch converts a losing-money problem into a not-trading problem. Better — but not solved, because downtime has its own bill: idle capital, missed edge, and a clock that started the moment trading stopped. The question is now what is wrong, and why — and the engine either helps answer it or it doesn’t. An observable engine can say what changed, which subsystem diverged from expectation, and what the book actually is, in minutes. Without that, a team under downtime pressure is guessing: restarting blind into open positions, fixing the most recent thing instead of the broken thing, reading exchange status pages for clues about their own system.
The supporting cast is unglamorous but load-bearing: an alert budget (page too often and pages get ignored; too rarely and your P&L is your monitoring), and restart-safety — coming back up into a book of open positions and live orders and being provably correct before acting, because the market did not pause while you rebooted.
Without the kill switch, a firm can lose everything quickly. Without observability, it stands in the dark with the engine off, burning downtime, with no idea what to fix. Most teams build both only after their first real incident. The firms still operating are the ones whose first incident wasn’t fatal.
The cheapest incident we’ve had makes the case better than any hypothetical. A venue rounded a market-order fill by its lot size — a difference of a few cents — and our order validation, built strict, rejected the venue’s fill as malformed. Real fills, refused by our own books. Within the hour the divergence tripped verification, and the protective response moved the affected strategies to close-only. But close-only killed each strategy’s decision loop — and the stop-losses and time-limit exits lived inside it. The “safe” state was the dangerous one: a small position sat unmanaged for nineteen hours, took a five-percent adverse move, and force-closed at a loss hundreds of times the rounding that triggered it. We shipped the better validator the same day, but the fix that mattered was the lesson: a halt is not automatically safe. The alert that now exists pages on any exposure held by a strategy that isn’t actively managing it — stranded positions get caught in minutes, not the next morning.
Here’s the part that took us longest to believe: on a real engine, a simple strategy beats a clever one on a weak engine — and it isn’t close.
At short horizons, realized P&L decomposes into signal, fees, slippage, and downtime — and only the first one is the strategy. Fees are set by your venue tier and volume. Slippage is set by your execution quality. Downtime is set by your operations. A modest edge, executed cleanly at institutional fee tiers with boring uptime, compounds. A brilliant signal paying retail fees through sloppy fills bleeds — we’ve watched whole strategy classes die exactly this way, on costs rather than on ideas.
Simple strategies have a second, underrated property: they’re diagnosable. When a simple strategy’s live P&L deviates from expectation, you can usually tell whether the signal decayed or the plumbing broke. A complicated strategy hides engine failures inside its own variance — you find out much later, at much higher tuition.
A good engine converts a marginal edge into a business. A weak engine converts a real edge into a loss. That’s why the system can matter more than the signal it runs.
Three walls, in the order teams hit them. AI agents have collapsed the first: a venue integration that took a sprint now takes an afternoon. They have not touched the last 20%, because that part is bought with live trading time.
Integration. The first venue used to take a sprint and produced confidence. Then it turns out every venue is its own dialect of the same lie — different auth, different rate-limit regimes, different order semantics, error codes that exist only in production. The tenth integration is cheaper than the first, but none of them are free, and every one of them bites at least once.
The last 20%. A demo-grade engine — happy path, one venue, human nearby — comes together in months, which is exactly what makes the estimate wrong. Production-grade means the edge cases: the restart into open positions, the fill that arrives after the cancel, the sequence gap at the worst moment, the drift that reconciliation catches at 2am. That’s where most of the calendar goes, and none of it demos well, which is why it’s chronically unbudgeted. Worse, many of these edge cases don’t exist anywhere but production — they only surface once real orders meet real venues under real load. No amount of planning compresses this wall; part of the last 20% is simply bought with live trading time, which is why teams that have paid for it once are so hard to hire.
Talent. The person who has built all of the above before is scarce, expensive, and usually already employed by a firm that prices their retention accordingly. Hiring them takes quarters; hiring three of them takes longer than the build. AI agents have not changed this; they have raised the bar. Typing code is no longer the scarce skill. Verifying it is: knowing why the system made a decision, and catching the bug before capital does. This is the quiet reason that fund’s timeline is a year despite two decades of pedigree and nine figures of anchor capital — and it’s the honest benchmark for anyone budgeting a build. Our own version of that benchmark: eight years live, and we’re still iterating on the engine.
The engine described above isn’t hypothetical — it’s the system we’ve operated on our own capital since 2018, through every regime crypto has produced since.
And “built” undersells it: an engine that survives is never finished. Ours is multiple generations removed from the version that first traded — subsystems rewritten as venues changed, regimes turned, and our own incidents demanded it. That’s the one place the building metaphor breaks: this building is never done. Continuous iteration isn’t a maintenance cost; it’s the mechanism by which the asset compounds.
If you’re standing up a desk: the build above needs a team you have to find first, and its last 20% is bought with live trading time. If you’d rather run than build, run on our stack instead of building one.
Martian Mobile is a proprietary crypto trading firm operating since 2018. This is part of a series on survivability, building trading operations, and validating edges — the full series lives here.