Read-only by design
How to add surveillance to a brokerage without ever introducing a new source of execution risk.
Propose putting anything new on a broker's trading servers and the first question is always the same. What happens to execution if it breaks during the London open.
It is the right question. It should be the first one. And the only acceptable answer is that it cannot, because it was never able to touch execution in the first place.
Execution is sacred
A brokerage has exactly one thing it cannot get wrong. Fills. Almost everything else can wobble for an hour and recover. A blown fill, a hung order, a matching engine that stalls at the wrong second, those are not inconveniences. They are the business failing at the one moment it is being measured. So anything that sits in the execution path, anything that can introduce latency or contention or a failure mode the desk did not already understand, is a liability before it has done a single useful thing.
This is why good operators are conservative about their servers, and they are right to be. The bar for adding something to a production trading environment is not is it useful. It is can it hurt execution. If the honest answer is maybe, the answer is no.
The design answer is to remove the question
There is a clean way through this, and it is architectural, not procedural. You do not manage the execution risk of a surveillance system. You design it so the risk cannot exist.
Read-only by design means the system observes and never acts. It has no write path to configuration. It does not place, modify or touch orders. It is not a plugin in the matching chain and it does not sit between your clients and your liquidity. It reads state. That is all it does and all it is able to do. A system that cannot change anything cannot break anything, and a system that is not in the execution path cannot degrade execution, by construction rather than by promise.
The distinction matters. Procedural safety is we will be careful. Architectural safety is it is not capable of the failure. Only one of those survives a bad night.
Read-only can also be narrow
Passive is half of it. Narrow is the other half.
Watching configuration does not require watching clients. The state that actually drifts, swaps, margins, leverage tiers, symbol setups, lives in your group and symbol settings, not in your clients' positions or their personal data. A surveillance layer built for config can stay entirely out of client trading activity and out of anything that looks like PII. That shrinks two things at once: the harm a read-only system could do if it were ever compromised, and the size of the question about what it is allowed to see in the first place. The less it can touch and the less it needs to know, the easier it is to say yes to.
What read-only actually buys you
Two things follow from designing it this way, and both are the point.
The first is independence. A surveillance layer that only reads can sit outside the platform entirely, independent of your vendor, watching the environment without being entangled in it. It is not part of the thing it is checking, which is exactly what you want from anything whose job is to tell you the truth about that thing.
The watcher should not share fate with the watched.
The second is that it makes continuous monitoring acceptable at all. The reason brokers tolerate quarterly audits and resist always-on tooling is that always-on usually means always-in-the-way. Read-only breaks that trade-off. Observation can run constantly, on production, through the London open, because there is nothing it can contend with and nothing it can corrupt. The constraint that makes it safe is the same constraint that lets it run all the time.
The constraint is the feature
It is tempting to read read-only as a limitation. It is the opposite. The whole value of surveillance is that you can trust what it tells you and run it without flinching, and both of those come directly from the fact that it cannot act. A tool that could change your config to fix a problem would also be a tool that could change your config by mistake, and you would be back at the London open question every single time it ran.
Surveillance does not need to act. It needs to see, and to tell you, accurately and continuously, so that you can act with a human in the loop and a decision on the record. The acting is yours. The seeing is the system's. Keeping that line clean is not a constraint you tolerate. It is the design that makes the whole thing safe enough to be worth having.
The right way to add eyes to a brokerage is to add eyes only. Nothing that can reach for the controls. Nothing that shares fate with execution. Read-only, by design, on purpose, all the way down.
Broker Intelligence is read-only by architecture, independent of your platform vendor, with zero execution impact. It watches your live MT4 and MT5 servers and never touches them. Book a 30-minute walk-through.