Value-at-Risk margining
A Value-at-Risk methodology computes required margin and buying power, so the limit an order is measured against reflects the risk of the position rather than its notional alone.
Platform · Module 04
Risk Management
Pre-order-entry and post-trade controls, calculated at clearing member, trading member and end-investor level. An order is accepted only if every applicable level passes — and the check happens before the order can reach the book, not after it has traded.
- Levels evaluated
- Three, all must pass
- Enforced
- At order entry
- Limit changes
- Immediate, no restart
- Margining
- Value-at-Risk, derivatives
Risk is a series circuit, not a score.
Risks are calculated at multiple levels — clearing member, trading member or broker, and end investor. There is no aggregate that a strong reading at one level can rescue: every applicable level must pass, and one breach at any of them means the order never reaches the market.
The order Limit scope evaluated Gate outcome Reaches the book
Enforced at entry, before an order can reach the book.
The position of the check is the whole argument. A control that runs after execution produces a report; a control that runs at order entry produces a market in which the breach did not happen.
- Maximum order quantity
- A ceiling on the size of a single order, which is the cheapest available protection against a mistyped quantity reaching the book.
- Maximum order notional
- A ceiling on quantity times price, so the same protection holds for an expensive instrument as for a cheap one.
- Daily price range
- A limit on the price range within which a participant may enter orders over the trading day.
- Maximum open positions
- A bound on the position a participant may hold, evaluated as the order is entered rather than discovered at the end of the day.
- Buying power
- The value the participant may still commit. For derivatives it is computed by the Value-at-Risk methodology alongside required margin.
Risk sits alongside the engine’s other pre-order-entry controls — tick alignment, price bands, minimum and maximum order size and session admission. The order in which they are applied to one order is set out on the order lifecycle page.
Limit sets you assign, not limits you retype.
A named risk profile is a reusable set of limits. It is defined once and then assigned — per clearing member, per firm, per client, per instrument or per market — with a configurable default profile as the fallback for anything not explicitly assigned.
This is what keeps a growing membership administrable. A venue with eighty member firms does not maintain eighty independent limit sets; it maintains a handful of profiles and a set of assignments, and the default catches the rest. A new instrument inherits a profile rather than arriving unprotected.
Limit changes apply immediately, without a restart. Profiles and assignments are maintained from the Market Control Panel, under maker–checker approval, with the change recorded like any other market-affecting action.
Margin, collateral and a call that reaches somebody.
For derivatives, quantity-based limits are not sufficient on their own, because exposure is not proportional to size.
Collateral with haircuts
Cash or securities may be held as collateral, with configurable haircuts — so the venue decides how much credit a pledged security earns rather than accepting it at face value.
Real-time margin calls
Margin calls are raised in real time and can be routed to notification channels such as email and SMS, so the call reaches a person rather than waiting in a report.
Every limit needs something to attach to.
Risk, entitlements, throttling and cancel-on-disconnect all key off the same participant hierarchy: three tiers — Firm, Node and User — with a Role on every User, plus a register of end clients. The configuration is agreed with each customer; the structure below is the generic form.
- Firm
- The highest level: the membership under which business is routed to the market. Each Firm is identified by a unique Member ID and may be a brokerage, a proprietary trading firm, an investment bank or another member type. A Firm has one or more Nodes.
- Node
- A logical grouping of Users, which lets a firm segment its business — by clearing arrangement, for example. Users under a Node inherit its configuration.
- User
- A business or technical enablement such as a trading desk, an algorithmic flow or a gateway session, defined by its Role. A User belongs to exactly one Node.
- End client
- An investor, registered against exactly one broker. Every client-account order carries the client’s identity.
Refused before anything reaches the market
- Orders from an unknown or inactive user.
- Client-account orders for a client that is missing, inactive, or belongs to another broker.
The full identity — Firm, Node, User and Role — is enforced on every message from the authenticated session, and never taken from the message body. A member firm therefore cannot assert who it is; the engine already knows, and a modified client gains nothing by claiming otherwise.
Participant onboarding and maintenance is performed from the Market Control Panel, with maker–checker approval and a complete audit history.
Enforced in the engine
Two protections that are worthless in a gateway.
Both of the following could be implemented at the edge, and in many systems they are. Here they are enforced at the engine’s entry point instead, because a protection that lives in a gateway stops protecting you the moment that gateway restarts or a firm connects through a different one.
Cancel on disconnect, cancel on logout
An optional facility. A disconnect is defined as a drop in the session between the participant and the engine, whether initiated by either party. When enabled, the participant’s resting orders are cancelled on disconnect, and on reconnection the engine sends execution reports for the deleted orders — so the firm learns what was cancelled rather than inferring it from an empty book. Because it is enforced in the engine itself, it holds even across gateway restarts.
Message throttling
Each User is subject to a maximum message throughput, agreed with the customer, as a safeguard against abnormal participant behaviour. The limit is enforced at the engine’s entry point, so it holds uniformly across every connectivity channel: a firm cannot obtain more throughput by splitting its flow between the trading API and a FIX session.
Next step
Tell us about your market. We will show you the engine matching.
A live demonstration runs about an hour: the order book, the Control Panel, an auction uncrossing, and a replay of the journal that produced it.