The heart of the system: one price–time priority matching model serving six asset classes, differentiated by configuration rather than by custom code. Every order, amendment, cancellation, trade and session transition is sequenced, journaled and exactly replayable.
Equities, fixed income, futures, options, rights and ETFs are all served by the same matching model. They are differentiated by configuration — instrument definitions, tick tables, lot sizes, price bands, session schedules and risk profiles — and not by custom code, so introducing a new market or a new instrument class does not require a software change.
Matching is price–time priority (FIFO). The matching algorithm itself is pluggable per instrument, so an alternative scheme such as pro-rata allocation can be introduced for a specific instrument class without disturbing the rest of the market.
Sessions are equally configurable. Continuous and auction-style trading sessions are schedulable at market and instrument level, including per-day overrides for IPOs and special events. The seven session types, and what each one admits, are set out on the market model page.
The book is swept in priority order, level by level, until the order is filled or the next price would breach its limit. Nothing about the outcome depends on timing or on which server ran the match.
An order’s behaviour is defined by its type and its validity. Which combinations a session admits is itself part of the market model, and the full matrix is published on the market model page.
| Type | Behaviour |
|---|---|
| Market | An unpriced order that executes against the best available prices. Market orders have priority over all priced orders. |
| Limit | An anonymous priced order, fully displayed in the order book, that may execute at prices equal to or better than its limit price. |
| Auction | A priced order with price priority over all other priced orders during an auction. Any unexecuted remainder is deleted automatically when the auction completes. |
| Iceberg | Publicly displays only a portion — the peak — of its total volume. Hidden size never leaks into public market data, but participates fully in auction price discovery. |
| Code | Name | Behaviour |
|---|---|---|
| DAY | Day | Expires at the end of the day on which it was entered. Assumed when no validity is stated. |
| GTD | Good Till Date | Expires at the end of trading on the specified day. Maximum expiry is the date of entry plus 89 calendar days. |
| GTC | Good Till Cancelled | Rests across days until filled or cancelled. |
| IOC | Immediate or Cancel | Executes on entry; any unexecuted volume expires immediately. |
| FOK | Fill or Kill | Executes in full on entry, or is immediately expired in full. |
The tick size is the minimum valid increment in which order prices can be entered and displayed. Each tick is a numeric amount representing a multiple of the unit of currency the instrument is listed in, and it may vary by price band — a wide-band instrument can trade in fine increments at low prices and coarser ones higher up.
If the price of an order is not a multiple of the applicable tick on entry, the order is rejected — immediately, before it can affect the market. Tick tables are configured per instrument from the Market Control Panel.
What happens to unexecuted volume is a property of the validity, not of the engine’s mood. An IOC order’s residue expires immediately; an FOK order either fills in full on entry or is expired in full; a DAY, GTD or GTC order rests in the book.
An Auction order does not persist into regular trading: any unexecuted remainder is deleted automatically when the auction completes. A GTD order with an expiry beyond the date of entry plus 89 calendar days is rejected.
The book resolves priority in four passes. Each pass applies only where the previous one ties, so the final tie-break — arrival sequence — settles cases that price, order type and volume disclosure have left level.
| Rank | Tier | Rule |
|---|---|---|
| First | Price | The highest bid and lowest offer rank first in their respective queues. Any change to an order’s price forfeits its priority; the order re-enters as new. |
| Second | Order type | Market orders have priority over all priced orders. During an auction, Auction orders outrank other priced order types. |
| Third | Volume disclosure | Fully visible orders have priority over iceberg orders at the same price. Increasing quantity forfeits priority; decreasing it does not. |
| Fourth | Time | The arrival sequence of the order is the final tie-break. |
An iceberg order publicly displays only a portion of its total volume — the peak. The displayed amount and the total size are both specified by the participant, subject to configured minimums, and hidden size never leaks into public market data.
When the peak is exhausted the engine refills it, and the order re-enters at the back of the time queue at its price level. Price, size and expiry can all be amended; if the disclosed quantity is set above the currently visible peak, the order loses time priority.
In auctions the distinction is deliberately dropped: the entire iceberg volume participates in price discovery, not just the displayed peak. Concealment is a protection against being read in continuous trading, not a way to withhold liquidity from an uncrossing.
Order volume, order price, validity date and time, and the client reference can all be updated — from the Client Trading Front-End or over the participant interface. Some amendments are free; others send the order to the back of the queue. The rule is published rather than inferred.
| Modified field | Modification | Effect on priority |
|---|---|---|
| Order volume | Iceberg total increased, visible peak unchanged | None |
| Order volume | Increase in volume of other orders | Time priority is lost |
| Order volume | Any decrease in volume | None |
| Order price | Change to a better price | Price priority increased; time priority lost |
| Order price | Change to a worse price | Price priority lost; time priority lost |
| Validity date/time | Any change | None |
Every print carries a trade type, so a downstream consumer never has to infer from a timestamp whether a price came out of continuous trading, an uncrossing or a fixed-price session.
Order books can move very fast. The engine tracks the prices at which automatic executions are due to occur and intervenes if the configured price-movement tolerances would be breached. The intervention is a refusal to print, not a correction after the fact.
Two instruments that do not interact do not compete for the same resources, so order books distribute across servers as the instrument count grows — from five on a single commodity server to several thousand across many. The configuration surface is the same at both ends of that range.
The matching path is entirely in memory, with no I/O and no locks on the critical path. Typical order round-trips are sub-millisecond to low-millisecond on commodity server hardware — no exotic hardware, no specialised network cards, no kernel tuning.
Every accepted command is processed in a single gap-free sequence and journaled before it executes. The same ordered input produces identical trades and book states, on any server and on any replay. Matching contains no randomness.
On any internal inconsistency the affected market segment halts rather than emit an incorrect trade. In a regulated market, a fast-but-occasionally-wrong matcher is worthless.
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.