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 five passes, and order type leads rather than price: a resting market order is matched before the best priced order on its side, whatever that price is. Price decides everything after that, and each remaining pass applies only where the one above it ties, down to arrival sequence.
| Rank | Tier | Rule |
|---|---|---|
| First | Order type: market | A resting market order is matched before any priced order on its side of the book, whatever the best price happens to be. Price only starts to decide once the market queue is empty. |
| Second | Price | Among priced orders, the highest bid and the lowest offer rank first in their respective queues. Any change to an order’s price forfeits its priority, whether the new price is better or worse; the order re-enters as new. |
| Third | Order type: auction | Within a price level, auction orders rank ahead of limit and iceberg orders. Auction orders are only accepted in the pre-open and pre-close, so this tier decides nothing during continuous trading. |
| Fourth | Display | Within a price level, displayed quantity ranks ahead of hidden quantity. An iceberg’s displayed peak queues by time alongside fully displayed orders; its hidden reserve only trades after a refill, which sends the order to the back of the queue. |
| Fifth | Time | The arrival sequence of the order is the final tie-break. |
An iceberg order publicly displays only part of its total volume, the peak. The participant sets both the peak and the total, subject to configured minimums, and when the order is entered or amended the peak must be at least one hundredth of what remains. Hidden size never leaks into public market data.
The displayed peak queues by time alongside fully displayed orders at its price. A match takes at most the displayed slice, so no single trade is larger than the peak. When the slice is used up, the engine refills it from the hidden reserve, gives the order a new arrival time and sends it to the back of the queue at that price. A partly used slice keeps its place.
Adding only to the hidden reserve keeps the order’s place, because nothing anyone can see has changed. Raising the peak or changing the price loses it.
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.
One buy price, three resting orders, and a seller who sells 850 at that price. A is an iceberg of 1,000 showing 100, arriving at 09:00:00. B is a fully displayed order for 500, arriving five seconds later. C is an iceberg of 800 showing 100, arriving at 09:20:00.
| Trade | Order filled | Quantity | What happens next |
|---|---|---|---|
| 1 | A, iceberg | 100 | A’s peak is used up. It refills from its hidden reserve, takes a new arrival time and goes to the back, behind B and C. |
| 2 | B, fully displayed | 500 | B is filled in full and leaves the book. |
| 3 | C, iceberg | 100 | C’s peak is used up. It refills and goes to the back, behind A. |
| 4 | A, iceberg | 100 | A refills again and goes to the back, behind C. |
| 5 | C, iceberg | 50 | The seller is done. C’s peak is only partly used, so C keeps its place at the front. |
A arrived first, so A traded first, but only the 100 it showed. B, which showed everything, was filled in full before A’s reserve traded at all. No single trade was larger than the peak the order displayed. At the end, A has 800 left showing 100, and C has 650 left showing 50.
Hiding size does not cost an order its place. It costs the place of everything it did not show: each slice of the reserve joins the queue again, like a new order.
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, peak and price unchanged | None |
| Order volume | Any other increase in volume | Time priority is lost |
| Order volume | Decrease in volume, displayed state unchanged | None |
| Displayed peak | Iceberg peak increased | Time priority is lost |
| Displayed peak | Change between displayed and fully hidden | Time priority is lost |
| Displayed peak | Change between limit and iceberg that still displays, with neither peak nor total raised | 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 within its matching engine, 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.