Trading API
A modern API over HTTP/JSON with server-streamed events, for member firms’ electronic order entry.
Platform · Module 06
Connectivity & Market Data
The engine’s ingress is a protocol-agnostic command API: the same validated, sequenced path serves every access channel. Because all channels converge on one ingress, risk controls, entitlements and throttles hold uniformly regardless of how a participant connects.
- Ingress
- One command API
- Access channels
- Five
- Participant interfaces
- Four
- Recovery
- Snapshot, then stream
The protocol is a detail. The path is not.
A gateway that implements its own validation is a second set of rules to keep in step with the first, and the day they diverge is the day a control silently stops applying. So the gateways here translate, and nothing more: every command they produce enters the same ingress, is validated the same way, is risk-checked at the same point, and is sequenced and journaled before it executes.
Channel 01Channel 02 Channel 03 Channel 04 Channel 05
Client Trading Front-End
The bundled browser front-end, for interactive trading by licensed traders with no integration effort.
Read more →Market-data service
Publishes public order-book snapshots and incremental updates, statistics and instrument definitions.
FIX 4.4 gateway adapter
For firms standardized on FIX connectivity. An adapter onto the same command API, not a second engine path.
Market Control Panel
The operator channel: market-affecting commands and privileged supervision data.
Read more →Four interfaces, separated by purpose.
Trading, market data, post-trade and reference data are distinct interfaces with distinct sessions. A back-office system consuming trade capture does not hold a trading connection to do it, and a market-data consumer needs no trading entitlement at all.
- Trading interface
- Order entry, modification and cancellation, with immediate confirmation of automated trades.
- Market-data service
- Public order-book snapshots, incremental depth updates, statistics and instrument definitions.
- Post-trade / drop-copy service
- Enriched trade confirmations, including cancellations, and consolidated copies of a firm’s activity for its back office.
- Reference-data service
- Instrument and market configuration data: symbols, ISINs, tick tables, lot sizes and session schedules.
| Interface | Inbound | Outbound |
|---|---|---|
| Trading | New OrderOrder Cancel RequestOrder Cancel/Replace RequestMass Cancel Request | Execution ReportOrder Cancel RejectMass Cancel Report |
| Market data | Market Data RequestInstrument List Request | Snapshot / Full RefreshIncremental RefreshInstrument Definitions |
| Post-trade / drop copy | Trade Capture Report Request | Trade Capture ReportTrade Cancel / Correct |
Reference information is available through the reference-data service and also as instrument-definition messages on the market-data interface, so a consumer that only needs symbols and tick tables can take them from the feed it is already reading.
Authenticate, snapshot, stream.
All electronic interfaces follow the same pattern, which is worth stating because it is the part integrators usually have to invent for themselves.
An authenticated session
Identity — Firm, Node, User and Role — is established at the session and then enforced on every message from it, never taken from the message body. A session cannot act for another member.
A point-in-time snapshot
A full picture of the current state: the order book at a point in time, the instrument definitions, the firm’s working orders. Everything that follows is relative to it.
A live stream of increments
Incremental events applied to the snapshot. A consumer that falls behind or reconnects requests a fresh snapshot and resumes the stream — recovery is built into the protocol, not left to the integrator.
One order in, one report back, on the same session.
A participant sends an order message through their configured User. The engine returns an execution report over the same session, updating the status of the order: acknowledged and resting, filled or partially filled, or rejected with a precise, machine-readable reject reason.
| Reason | What it means | What the firm does |
|---|---|---|
| Tick violation | The price is not a multiple of the applicable tick for the instrument’s price band. | Round to the tick from the current reference-data bundle and resubmit. |
| Session admission | The current session does not admit this order type with this validity — IOC and FOK during an auction call, for example, or an Auction order during LPX. | Resubmit with an admitted combination, or wait for the session that admits it. |
| Buying-power breach | A risk limit failed, and the response names the limit and the scope that tripped: this client’s buying power, this firm’s maximum order quantity. | Reduce the order, or have the limit reviewed by the operator. |
| Duplicate client reference | A submission with this client reference has already been accepted. The engine is idempotent at the point of entry. | Reconcile against the existing order rather than retrying blind. |
Idempotent at the point of entry
Duplicate submissions are detected by client reference and rejected. A member firm that retries after a timeout therefore cannot accidentally double an order — the second submission is refused, not matched.
Two records for one trade
Should a trade occur, the execution report summarizes it: side, trade quantity, trade price, trade identifier and transaction time. An enriched trade-capture record follows on the post-trade interface, adding ISIN, matching type, clearing type, commissions and fees — linkable by trade identifier. See clearing.
Versioned, with full history.
Reference information tells participants what is tradable and under what rules: symbols, ISINs, tick tables, lot sizes and session schedules. It is available through the reference-data service and as instrument-definition messages on the market-data interface.
It is versioned. Every change to reference data is published as a new bundle version with full history, which is what makes an integration stable: a member firm pins a version, sees a new one arrive, and can tell exactly what changed. The same versioning is what lets a venue answer which tick table applied on the day of a disputed trade.
The bundles themselves are maintained by the operator in the Market Control Panel, and take effect without an engine restart.
The point
However a firm connects, it trades under the same rules.
Risk controls, entitlements and throttles hold uniformly across every channel because there is only one place where they are applied. A firm moving from the bundled front-end to the trading API, or from the trading API to a FIX session, changes how its messages are encoded and nothing about how they are treated.
For the venue, that is one rule set to configure, one to test and one to defend to a regulator — rather than one per gateway.
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.