Pre-trade risk checks
Pre-trade risk checks are the validations an order passes before it can reach the market: the trading application's own guards, the broker's and futures commission merchant's limits on size, position and margin, and the exchange's price and order-type controls. Each layer can refuse an order, and none replaces the others.
Senzoukria · Glossary · Updated September 2026
Three layers
| Layer | Examples of checks |
|---|---|
| Application | Maximum quantity per order, trading enabled for this connection, confirmation step, correct account |
| Broker / FCM | Account permissions, margin, maximum position and order size, product permissions |
| Exchange | Price banding, protection on market and stop orders, market state, order-type rules |
Worked example
An application cap is set to 3 contracts per order. A trader types 5: the order is refused before it leaves the machine. The trader corrects it to 3; the broker's limit allows a 4-contract position, and the account already holds 2 in the same direction, so the new order would bring the position to 5 and the broker refuses it. The trader sends 2; the exchange then rejects the limit price, typed 100 points through the market, as outside the price band. Three refusals, three different owners.
Why layers matter
An application guard is fast and visible but only protects orders sent from that application. Broker limits cover every platform on the account but vary by firm. Exchange controls protect the market as a whole, not your account. A trader who knows which layer refused an order knows whom to ask and whether a setting can change the outcome.
In Senzoukria
Before an order leaves, the backend applies the connection's guards: trading must be enabled on the connection (it stays disabled on funded-account profiles until explicitly enabled), a 'Contracts per order' cap in the trading settings refuses larger orders, and an optional 2-click mode shows a confirmation with side, quantity, instrument, type, price and account. The order carries the account shown, and the backend refuses it if the order-plant session routes to another account. On Rithmic, an order is also refused until a trade route for its exchange has been resolved. The ticket mirrors these guards so they are visible before the round trip, never as the only line of defence.
Common mistakes
- Treating an application cap as a broker limit, or the reverse.
- Disabling confirmations on a funded account to save a click.
- Assuming a rejected order was never sent anywhere; it may have been refused by the broker or the exchange.
Related
In the same section
- Price banding
- Pre-open and IOP
- Price discovery
- Post-only order
- Price level grouping
- Positive gamma regime
- Price-time priority
- Position sizing
This page in other languages
Frequently asked questions
- Why was my order rejected when the application accepted it?
- Because the broker, the futures commission merchant or the exchange applies its own checks after the application's. The rejection text usually names the reason, such as margin, a position limit or a price outside the band.
- Are software guards enough to protect a prop firm account?
- They reduce the cost of a wrong click, but the firm's rules, such as maximum contracts or loss limits, are enforced by the firm and can be breached by orders sent from other platforms or by market moves.