Live market data
Inside market, market depth and trade prints, streamed in real time. The same public view every other participant sees: hidden iceberg volume is not in it.
Platform · Module 03
Client Trading Front-End
A simple, clean front-end that lets professional and licensed traders participate in the market out of the box. No third-party software is required to launch a venue, and nothing a member firm has to build before it can trade.
- Deployment
- Browser, nothing to install
- Order types
- Market, Limit, Iceberg
- Validity
- All supported options
- Identity
- Bound to the firm
A venue with no traders on it is not a venue.
A matching engine on its own cannot open a market. Somebody has to be able to look at a book and send an order, and if that requires every member firm to procure or build a trading application first, the launch date is not yours to set.
So the platform ships with a front-end for professional and licensed traders, and it is deliberately plain. It is simple to deploy and simple to learn, which is what actually shortens member onboarding — a firm can be trading after a briefing rather than after a project.
It is not an attempt to compete with a member’s own order-management system, and it does not need to be. Firms with their own systems connect electronically instead, over the participant interface. Both paths are subject to identical risk controls.
Six things, done properly.
The feature list is short on purpose. Everything on it is fed by the same streams and the same validated path that serve an API integration, so nothing here is a simplified approximation of the real market.
Order entry
Market, Limit and Iceberg orders, with all supported time-in-force options. Which combinations the current session admits is enforced by the engine, not by the screen.
Orders and order history
Live status on working orders and a history of the day’s activity, including orders that never rested because they were rejected.
Own-trade confirmations
The firm’s own executions streamed as they happen, rather than assembled from a market-data feed and hope.
Positions monitoring
Positions derived from the participant’s own trade flow, so the trader and the venue are working from the same arithmetic.
Client-account trading
Trading on behalf of client accounts, with the client reference carried on every order and echoed on every report.
| 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. |
Order entry from the front-end covers the Market, Limit and Iceberg types. Order volume, order price, validity date and time, and the client reference can all be amended from here, with the priority consequences of each amendment set out on the matching engine page.
A rejection should tell the trader what to do next.
Status updates arrive live on the order and order-history views. The state shown is the engine’s state, not a client-side guess at it, and a refusal names its cause.
- Acknowledged
- The order passed validation and risk, was sequenced and journaled, and is resting in the book at a known priority.
- Partially filled
- Some volume executed and the remainder is still working. The execution report carries the trade details: side, trade quantity, trade price, trade identifier and transaction time.
- Filled
- The order is complete. An enriched trade-capture record follows on the post-trade interface, linkable to the execution report by trade identifier.
- Cancelled
- Withdrawn by the trader, expired by its validity, deleted at the end of an auction in the case of an Auction order, or cancelled on disconnect where that facility is enabled.
- Rejected
- Refused before it could affect the market, with a precise reject reason — a tick violation, a session-admission failure, or a limit breach naming the limit and the scope that tripped.
Credentials are bound to the firm.
A trader can act for the house or on behalf of a client account, and a client-account order carries the client’s reference on every message and every report. The clearing account — Client or House — is a required field on entry, so the intent is explicit rather than derived afterwards.
Identity enforcement is strict, and it is enforced by the engine rather than by the screen. A participant’s credentials are bound to their firm: a session can never act for another member. The full identity — Firm, Node, User and Role — is taken from the authenticated session on every message and never from the message body, so it cannot be forged by a modified client.
What the engine refuses outright
- Orders from an unknown or inactive user.
- Client-account orders for a client that is missing, inactive, or registered against another broker — end clients belong to exactly one broker.
- Anything that fails a risk limit at clearing member, trading member or end-investor level, before it can reach the book.
Two ways in, one set of controls.
Member firms are not all the same size, and they should not have to be. A firm can start on the bundled front-end and integrate its own systems later, and the rules it trades under do not change when it does.
| Bundled front-end | Participant interface | |
|---|---|---|
| Suits | Firms trading manually, and any firm that needs to be live before its integration is | Firms with their own order-management system, and algorithmic flow |
| Integration effort | None. A browser and a briefing | Development against the trading API over HTTP/JSON, or the FIX 4.4 gateway adapter |
| Market data | Inside market, depth and trade prints in the screen | Snapshot then incremental stream from the market-data service |
| Risk controls | Identical | Identical |
| Identity enforcement | From the authenticated session | From the authenticated session |
| Message throttling | Per User, at the engine’s ingress | Per User, at the engine’s ingress |
| Customer testing | The market’s session and order rules, walked through; nothing to build | Conformance against the interfaces the firm will use, before go-live |
The point
The front-end is a channel, not a rule set.
The engine’s ingress is a protocol-agnostic command API, and the front-end is simply one of the channels that reaches it. Validation, risk evaluation, sequencing and journaling happen in exactly the same place whichever channel an order arrives on, so a firm that upgrades from the screen to an API integration does not move to a different rule set — and the venue does not maintain two of them.
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.