Per participant, per settlement date
Obligations are aggregated by the participant that owes or is owed them and by the date they fall due. Trades with different settlement dates are netted separately, because they are different obligations.
Platform · Module 05
Clearing
A clearing component operating on the trade stream: clearing and matching types stamped on every trade, multilateral netting per participant and settlement date, fees computed per trade, and enriched trade-capture records for whatever comes next.
- Operates on
- The trade stream
- Netting
- Multilateral, per settlement date
- Cycles
- Configurable
- Settlement
- Downstream, not here
Four things done to every trade, in order.
Clearing is built in, and it works on the output of the matching engine rather than alongside it. That means the clearing record and the trading record are produced from the same sequence of events, so they cannot disagree about what traded.
- Stamping
- Each trade is stamped with its clearing type and its matching type — regular or auction — so a downstream consumer never has to infer from a timestamp how a price was formed.
- Multilateral netting
- Netting per participant and settlement date, with configurable settlement cycles, produces net obligations rather than a list of gross trades to settle one by one.
- Fees and commissions
- Computed per trade, at the point the trade is captured, so the economics of a trade are on the record with the trade itself.
- Trade capture
- Enriched trade-capture records — ISIN, matching type, clearing type, fees — emitted for downstream consumers, linkable to the execution report by trade identifier.
Six trades, three obligations.
Netting is performed per participant and per settlement date, with configurable settlement cycles, and it produces net obligations. The gross trades remain on the record; what goes downstream for settlement is the net.
Gross trades, as matched Netting Net obligation Your systems
Configurable cycles
The settlement cycle is configuration, so a market settling on a different cycle from its neighbours — or changing cycle — does not require a change to the trading core.
Every trade knows what it cost and how it was formed.
Fees and commissions
Fees and commissions are computed per trade and carried on the enriched trade-capture record. A firm’s back office therefore books the charge from the same record that tells it what traded, rather than reconciling an execution against a separate invoice file at the end of the day.
Clearing type and matching type
Each trade carries its clearing type and its matching type. The matching type distinguishes a regular execution from an auction uncrossing, which matters for anyone valuing a position, publishing a closing price or investigating a print — the classification is on the record, not reconstructed from the clock.
Two records for one execution, joined by one identifier.
When a trade occurs, the entering session receives an execution report, and an enriched trade-capture record is delivered over the post-trade interface. Both carry the same trade identifier, so front office and back office reconcile by joining on a key rather than by inference.
| Record | Interface | Contents | Delivered to |
|---|---|---|---|
| Execution report | Trading | Order status, side, trade quantity, trade price, trade identifier and transaction time | The participant session that entered the order |
| Trade-capture report | Post-trade / drop copy | The same trade identifier, plus ISIN, matching type (regular or auction), clearing type, and commissions and fees | The firm’s post-trade or drop-copy user |
The back office does not need to watch the trading session.
The post-trade service delivers enriched trade confirmations, including cancellations and corrections, and consolidated copies of a firm’s activity for its back office. It is a separate interface with its own session, so a middle- or back-office system consumes it without sitting on a trading connection.
A drop-copy user can be configured to receive all trade-capture and execution reports for a firm. That is the mechanism behind most of what a firm actually wants here: one consolidated view of everything the firm did, regardless of which desk, which Node or which channel produced it — the front-end, the trading API or a FIX session.
Like every other electronic interface, it follows the same connection pattern: an authenticated session, a point-in-time snapshot, then a live stream of incremental events, with a fresh snapshot available to a consumer that falls behind. The message inventory is on the connectivity and market data page.
Scope, stated plainly
Mehrex clears and nets. It does not settle.
Settlement itself is performed by a downstream settlement module, or by the customer’s existing CSD or registry and banking integration, which consumes the engine’s clearing messages. That boundary is deliberate: it keeps the trading core independent of any particular settlement regime, and it means a venue does not have to replace working settlement arrangements in order to replace its trading platform.
The practical implication for a delivery is that your settlement people are needed early — early enough to agree the shape of the netting output and the trade-capture records they will consume, rather than discovering it during rehearsals.
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.