Controls
The cheapest bad trade is the one that never executed
Everything after execution is damage control. The only place a risk system genuinely saves money is in front of the order, and it has to be fast enough to be allowed to stay there.
An order larger than the client or firm is permitted
Effective leverage beyond the ceiling for that segment
Exposure that would crowd an instrument or counterparty
A size or price far outside this client's normal behaviour
Trading in something this segment is not entitled to
An order into an instrument outside its trading session
Three design constraints
Pre-trade controls fail for predictable reasons
Fast enough to sit in the path
A check that adds meaningful latency will be removed the first time somebody complains about execution speed. The only pre-trade control that survives is one nobody notices.
Specific enough to be actionable
A rejection that says the order was blocked teaches nobody anything. Each check returns which control fired and what the boundary was, so the client or the desk can respond sensibly.
Not every check is a hard block
Some should reject, some should require an override, some should only warn. Making everything a hard block means overrides become routine, and a routine override is not a control.
See it live
The checks that sit in front of the order
Notional caps, leverage ceilings and concentration limits are visible per group, recalculated continuously rather than checked after the fact.
FAQ
Pre-trade controls: common questions
6 short answers to what teams ask before a demo.
The checks are designed to sit in the order path without being noticeable. This is not a nice-to-have: a control that measurably slows execution will be switched off the first time someone complains, and then you have neither speed nor safety.
A size or price test against what this client normally does rather than against a fixed number. An order fifty times a client's usual size is worth stopping even when it is inside the formal limit, because it is far more likely to be an error than an intention.
No, and they should not. Each control is configured to reject, require an override, or warn. Making everything a hard block leads to overrides being granted as a matter of routine, at which point the control has stopped functioning.
Which control fired and what the boundary was. A generic rejection guarantees a support contact and teaches the client nothing about how to place an acceptable order.
Platform margin checks look at that client on that platform. These add firm-level context — concentration across everything you run, counterparty exposure, and limits that no single platform can see.
Yes. A professional account and a retail one should not share notional caps or leverage ceilings, and applying one set to both means it is wrong for at least one of them.
Still have a question?
A specialist will answer it directly, with your set-up in mind.
Ask a specialistWhat would stop an order fifty times too large?
On most setups the honest answer is that it would execute and somebody would notice afterwards.