Market Data & Execution Systems
Programming and network work for trading firms: market data coming in, orders going out, and the monitoring that tells you when either one has stopped. It’s unglamorous work. It’s also where the expensive failures start. A correct signal and a late one produce the same result, and only one of them shows up in the research.
Where Trading Systems Fail
The signal is defensible and the feed handler drops a message once a week without mentioning it. The rules are clear in conversation and applied three different ways by three different people. The backtest is written in one language and the live system in another, so the two agree right up until the day they don’t. None of that arrives labeled as a bad idea. It arrives as slippage nobody can account for, and a review meeting where the explanation is a shrug.
Ingestion, Execution & Backtesting
This is the shape of the work, in the order it’s usually done. Not every firm needs all five. Sometimes only one piece needs work.
Feeds arrive in whatever shape the venue or the vendor chose. They get normalized into one internal representation, timestamped at capture rather than at parse, and recorded so the same bytes can be replayed later. Everything downstream reads that one representation, which means a fix to a feed handler is a fix everywhere rather than in three places you have to remember.
A discretionary rules set gets read back to you as a list of conditions and actions, in plain language, until you agree the list is the thing you actually do. Then it becomes code, with the ambiguities resolved on paper instead of at three in the afternoon. What a trader says the rule is and what the rule turns out to be are two different things. That gap is the part worth spending time on.
Order construction, risk checks before the wire, order routing, and the state machine that keeps the system’s idea of a position and the venue’s idea of it in agreement. Every hop is timestamped. When something is slow, you get an answer instead of a theory. Reconciliation runs whether or not anyone is watching it.
The backtester feeds recorded data into the same strategy and execution code that runs live. Only two things change: where the clock comes from and where fills come from. That removes the usual source of a whole class of bug. With no second implementation, there’s nothing for the backtest to diverge from. It’s slower to build and less pleasant to experiment in, and worth it.
Gaps in sequence numbers, a feed going stale, an order that never got an ack, position drift against the broker, a process that stopped and told nobody. Each condition raises an alert with enough context to act on, and it goes to a person, not to a dashboard nobody has open. A system nobody watches fails silently. Silent failure gets expensive long before it’s visible.
Latency & Backtest Design
Before anything is made faster, the path is instrumented end to end: capture, decode, decision, encode, wire. The bottleneck is often somewhere nobody instrumented. A lock, a log line, a collection pause, a switch hop taken twice. Measure before you buy hardware. The work follows what the timestamps show, and it stops when the remaining cost is the distance itself.
A firm running one or two strategies gains more from certainty than from throughput, so that is what this design buys. Research code has to be production code, so fewer ideas get tested in a given week. What you buy is the absence of a second implementation. The backtest and the live system have nowhere to drift apart, because there’s only one of them. A shop testing twenty ideas a week should probably choose the other way. Just know that when the two versions do disagree, the disagreement gets found late.
We describe what a system is for and how it behaves, never how to rebuild it. No thresholds, no parameter values, no live positions. Not on this site, and not in a conversation before there’s a contract. That restraint is carried over from ADJL Capital, where the property scanner and the rules-based equities work run on the firm’s own capital. It points the same way for client work. Your rules set doesn’t get written up anywhere, for any audience. That’s deliberate, and it’s why this page argues from method instead of from names.
Start here
A feed handler that drops messages once a week, a backtest nobody trusts, a rules set that still lives in someone’s head. Describe what it is and what it’s supposed to do. You’ll get a straight answer about whether this is worth building, including when it isn’t.
