01
What did it earn?
P&L priced at settlement and computed with the venue’s exact fee law — not the fee field it reports, which is frequently wrong or empty. Rebates counted separately from trading net, so neither flatters the other.
Mission Operations Control Room
Know what your book actually did.
MOCR is the measurement and control layer for systematic trading operations. Settlement-priced P&L computed with your venue’s real fee law, every fill attributed to the build that made it, and an honest answer to whether the engine is still sending.
01 / Position
The venue’s numbers are not your numbers.
Every trading venue publishes a view of your activity. None of them are built to answer the question you actually have, which is whether the thing you deployed is making money, and how you would know.
Fee fields report zero. Positions settle late. A dashboard says “live” when it means the data is arriving, not that a single order has been sent. A configuration change goes out and nothing records which fills came from which build. Each of these is small. Together they are the difference between running an operation and watching one.
MOCR exists because we needed this for our own trading, and the reporting we were handed was not sufficient to run on.
02 / Capabilities
What the control room does.
Three questions an operator must be able to answer in seconds, and usually cannot.
02
Is it still trading?
A fresh page proves your data is arriving. It does not prove an order has been sent. MOCR reads the engine’s own decision log and reports sending as a separate state — and raises it the moment it stops.
03
Which build did that?
Every fill carries the version that produced it, from a deploy registry rather than from memory. Without it, a comparison between two configurations is a rumour, and a build that deployed cleanly but never armed looks exactly like a quiet market.
03 / Discipline
Instruments that refuse to flatter you.
The expensive failures in systematic trading are not bugs. They are conclusions drawn from evidence that could never have supported them.
- Power before the run
- How many observations would this question need? Answered before the experiment, not after it disappoints. A test that cannot resolve the effect you are looking for should not consume a week of live risk.
- Gates written in advance
- Acceptance signals and kill conditions defined before deploy, against the fingerprint each change should leave. What would prove this worked is a question to settle while you are still honest about it.
- Simulator parity
- Does the model agree with the engine on identical inputs? When live and sim disagree, one of them is lying, and which one it is determines whether you have a sizing problem or an execution defect.
- Observations, not conclusions
- The console marks what is interesting without licensing you to act on it. A striking asymmetry across two days and a changed fee regime is a reason to run the analysis, not a reason to move.
Enquiries
Tell us what your operation can’t currently see.
We will tell you honestly whether this is a problem we should be solving for you.