FIX order types & TIF¶
Source status
Primary text extracted from postman/Polaris-FIX-Document.postman_collection.json
(Pepperstone Crypto FIX API Institutional Integration Guide).
Local ptrader-fix-server checkout currently has README only (no src/).
Treat field tables as the published client contract pending source verification —
see Gap tracker.
NewOrderSingle & cancels (from guide)¶
NewOrderSingle (35=D)¶
WARNING: Supported order types: MARKET (
40=1) and LIMIT (40=2) only. STOP, STOP_LIMIT and other conditional types are rejected withExecutionReport (35=8, 150=8, 39=8, 103=11 UNSUPPORTED_ORDER_CHARACTERISTIC).
Required fields¶
| Tag | Field | Req? | Notes |
|---|---|---|---|
11 |
ClOrdID | Y | Client-assigned, unique per account. Reuse triggers a duplicate-order reject; see below. |
55 |
Symbol | Y | Format BASE_QUOTE, e.g. BTC_USDT. |
54 |
Side | Y | 1 = BUY, 2 = SELL |
40 |
OrdType | Y | 1 = MARKET, 2 = LIMIT |
21 |
HandlInst | Y | Required by FIX dictionary. Typical value 1. Server does not branch on this. |
38 |
OrderQty | Cond. | Required for LIMIT and for MARKET by base quantity. Must be > 0. Mutually exclusive with 152. |
152 |
CashOrderQty | Cond. | Quote-currency amount for MARKET (e.g. "buy 1000 USDT of BTC"). Must be > 0. Not allowed on LIMIT. |
44 |
Price | Cond. | Required for LIMIT; must be > 0. Ignored on MARKET (safe to send 44=0 for Java/proto3 clients). |
59 |
TimeInForce | N | 0 = DAY, 1 = GTC (default), 3 = IOC, 4 = FOK |
60 |
TransactTime | Y | UTC YYYYMMDD-HH:MM:SS.sss. |
Placement flow¶
Before acknowledging, the gateway runs:
- Structural validation — required fields, value ranges, exclusivity of
38/152. - Symbol + trading-rule check against the catalog.
- Duplicate-
ClOrdIDguard — the id is claimed atomically; a collision returns a reject without touching the incumbent order. - Pre-lock of the required balance on the asset service.
- Publish to the matching engine.
On success, the gateway forwards the matching engine's first ExecutionReport (150=0 NEW, 39=0 NEW). All subsequent lifecycle events (fills, partial fills, cancels, expirations) are driven by the matching engine and arrive as further ExecutionReports.
Inbound · NewOrderSingle (LIMIT BUY)
8=FIXT.1.1|9=...|35=D|34=70|49=CLIENT|56=PtradeFIXServer-AU|
11=cli-10001|55=BTC_USDT|54=1|21=1|38=0.50|40=2|44=62000.00|59=1|60=20260515-09:05:00.000|10=...
Outbound · ExecutionReport (NEW ack)
8=FIXT.1.1|9=...|35=8|34=71|49=PtradeFIXServer-AU|56=CLIENT|
37=1234567|17=exec-...|11=cli-10001|55=BTC_USDT|54=1|40=2|38=0.50|44=62000.00|
150=0|39=0|14=0|151=0.50|6=0|60=20260515-09:05:00.100|10=...
Duplicate ClOrdID¶
Sending a NewOrderSingle with a ClOrdID already known to the gateway returns:
Outbound · ExecutionReport (duplicate ClOrdID)
8=FIXT.1.1|9=...|35=8|34=72|49=PtradeFIXServer-AU|56=CLIENT|
37=O-cli-10001-...|17=rejected-...|11=cli-10001|55=BTC_USDT|54=1|40=2|
150=8|39=8|14=0|151=0|6=0|103=6|58=Duplicate ClOrdID: cli-10001|10=...
NOTE: The incumbent live order with this
ClOrdIDis not affected and remains cancellable. Make sure yourClOrdIDgenerator is collision-free per account.
OrderCancelRequest (35=F)¶
Cancel a working order by referencing its ClOrdID.
Required fields¶
| Tag | Field | Req? | Notes |
|---|---|---|---|
41 |
OrigClOrdID | Y | The ClOrdID of the original NewOrderSingle. |
11 |
ClOrdID | Y | A new unique id for this cancel request itself. |
55 |
Symbol | Y | Echo the symbol of the original order. |
54 |
Side | Y | Required by the dictionary; not used for routing. |
60 |
TransactTime | Y | UTC YYYYMMDD-HH:MM:SS.sss |
Response semantics¶
Cancel is asynchronous:
- The gateway does local validation only (order known, state is cancellable, session is authenticated).
- On success, it forwards the request to the matching engine and marks the order
PENDING_CANCELlocally. NoExecutionReportis produced synchronously. - The real
ExecutionReport (150=4 Canceled, 39=4 Canceled)arrives once the matching engine confirms. - If local validation fails, an
OrderCancelReject (35=9)is returned synchronously with a specificCxlRejReason (102).
Cancel-reject reasons¶
| 102 | Meaning | Trigger |
|---|---|---|
1 |
UNKNOWN_ORDER | OrigClOrdID is missing, or the order is not in the gateway's tracked cache. |
0 |
TOO_LATE_TO_CANCEL | The order is already in a terminal state (FILLED / CANCELED / REJECTED / EXPIRED). |
3 |
ORDER_ALREADY_IN_PENDING_CANCEL_OR_PENDING_REPLACE_STATUS | A previous cancel for the same order is still in flight (double-tap). |
99 |
OTHER | Session not authenticated, or downstream publish failed. |
NOTE: OrdStatus (39) on
35=9mirrors the underlying order's current state, not the rejected cancel:39=0if the order is stillNEW,39=2ifFILLED,39=4ifCANCELED,39=6ifPENDING_CANCEL,39=8only when the order was never known to the gateway.
Inbound · OrderCancelRequest
8=FIXT.1.1|9=...|35=F|34=80|49=CLIENT|56=PtradeFIXServer-AU|
41=cli-10001|11=cli-10001-cxl-1|55=BTC_USDT|54=1|60=20260522-09:06:00.000|10=...
Outbound · ExecutionReport (Canceled, driven by matching engine)
8=FIXT.1.1|9=...|35=8|34=81|49=PtradeFIXServer-AU|56=CLIENT|
37=1234567|17=cxl-...|41=cli-10001|11=cli-10001-cxl-1|55=BTC_USDT|54=1|
150=4|39=4|14=0|151=0|6=0|10=...
Outbound · OrderCancelReject (order already terminal)
8=FIXT.1.1|9=...|35=9|34=83|49=PtradeFIXServer-AU|56=CLIENT|
37=1234567|41=cli-10001|11=cli-10001-cxl-2|39=4|434=1|102=0|
58=Order not cancelable in current state|10=...
11 vs 41 on Canceled ER¶
On both the synchronous OrderCancelReject and the asynchronous ExecutionReport (150=4):
11 ClOrdID— the id of the cancel request itself.41 OrigClOrdID— the id of the original order.
OrderMassCancelRequest (35=q)¶
Cancel every working order on the session that matches a given symbol (optionally narrowed to one side). The gateway iterates internally, dispatches one cancel per affected order, and enumerates them in the outbound OrderMassCancelReport (35=r) via the NoAffectedOrders (534) repeating group.
Only MassCancelRequestType = 1 (CANCEL_ORDERS_FOR_A_SECURITY) is supported.
Required fields¶
| Tag | Field | Req? | Notes |
|---|---|---|---|
11 |
ClOrdID | Y | Echoed back in 35=r as both 11 and 1369 MassActionReportID. |
530 |
MassCancelRequestType | Y | Only 1 supported today. |
55 |
Symbol | Y | Required when 530=1. |
54 |
Side | N | Optional. 1 = BUY, 2 = SELL. Omit to sweep both sides. |
60 |
TransactTime | Y | UTC YYYYMMDD-HH:MM:SS.sss |
Response¶
| Outcome | Fields |
|---|---|
| Accepted | 35=r · 531=1 · 533=N · one 534/41/535 entry per affected order |
Rejected — unsupported 530 |
35=r · 531=0 · 532=0 MASS_CANCEL_NOT_SUPPORTED |
Rejected — missing Symbol |
35=r · 531=0 · 532=1 INVALID_OR_UNKNOWN_SECURITY |
Rejected — unsupported Side |
35=r · 531=0 · 532=99 OTHER |
WARNING:
35=ris an ACK of the mass-cancel request, not of each individual cancel outcome. Every affected order still generates its ownExecutionReport (150=4 Canceled)asynchronously from the matching engine — just like a single35=F. Use the534group to know whichOrigClOrdIDs to expect.
Inbound · OrderMassCancelRequest
8=FIXT.1.1|9=...|35=q|34=120|49=CLIENT|56=PtradeFIXServer-AU|
11=mc-001|530=1|55=BTC_USDT|54=2|60=20260522-09:10:00.000|10=...
Outbound · OrderMassCancelReport (accepted)
8=FIXT.1.1|9=...|35=r|34=121|49=PtradeFIXServer-AU|56=CLIENT|
11=mc-001|1369=mc-001|530=1|531=1|55=BTC_USDT|533=2|
534=2|41=cli-10001|535=1234567|41=cli-10002|535=1234568|10=...
OrderCancelRequest (35=F)¶
Cancel a working order by referencing its ClOrdID.
Required fields¶
| Tag | Field | Req? | Notes |
|---|---|---|---|
41 |
OrigClOrdID | Y | The ClOrdID of the original NewOrderSingle. |
11 |
ClOrdID | Y | A new unique id for this cancel request itself. |
55 |
Symbol | Y | Echo the symbol of the original order. |
54 |
Side | Y | Required by the dictionary; not used for routing. |
60 |
TransactTime | Y | UTC YYYYMMDD-HH:MM:SS.sss |
Response semantics¶
Cancel is asynchronous:
- The gateway does local validation only (order known, state is cancellable, session is authenticated).
- On success, it forwards the request to the matching engine and marks the order
PENDING_CANCELlocally. NoExecutionReportis produced synchronously. - The real
ExecutionReport (150=4 Canceled, 39=4 Canceled)arrives once the matching engine confirms. - If local validation fails, an
OrderCancelReject (35=9)is returned synchronously with a specificCxlRejReason (102).
Cancel-reject reasons¶
| 102 | Meaning | Trigger |
|---|---|---|
1 |
UNKNOWN_ORDER | OrigClOrdID is missing, or the order is not in the gateway's tracked cache. |
0 |
TOO_LATE_TO_CANCEL | The order is already in a terminal state (FILLED / CANCELED / REJECTED / EXPIRED). |
3 |
ORDER_ALREADY_IN_PENDING_CANCEL_OR_PENDING_REPLACE_STATUS | A previous cancel for the same order is still in flight (double-tap). |
99 |
OTHER | Session not authenticated, or downstream publish failed. |
NOTE: OrdStatus (39) on
35=9mirrors the underlying order's current state, not the rejected cancel:39=0if the order is stillNEW,39=2ifFILLED,39=4ifCANCELED,39=6ifPENDING_CANCEL,39=8only when the order was never known to the gateway.
Inbound · OrderCancelRequest
8=FIXT.1.1|9=...|35=F|34=80|49=CLIENT|56=PtradeFIXServer-AU|
41=cli-10001|11=cli-10001-cxl-1|55=BTC_USDT|54=1|60=20260522-09:06:00.000|10=...
Outbound · ExecutionReport (Canceled, driven by matching engine)
8=FIXT.1.1|9=...|35=8|34=81|49=PtradeFIXServer-AU|56=CLIENT|
37=1234567|17=cxl-...|41=cli-10001|11=cli-10001-cxl-1|55=BTC_USDT|54=1|
150=4|39=4|14=0|151=0|6=0|10=...
Outbound · OrderCancelReject (order already terminal)
8=FIXT.1.1|9=...|35=9|34=83|49=PtradeFIXServer-AU|56=CLIENT|
37=1234567|41=cli-10001|11=cli-10001-cxl-2|39=4|434=1|102=0|
58=Order not cancelable in current state|10=...
11 vs 41 on Canceled ER¶
On both the synchronous OrderCancelReject and the asynchronous ExecutionReport (150=4):
11 ClOrdID— the id of the cancel request itself.41 OrigClOrdID— the id of the original order.
OrderMassCancelRequest (35=q)¶
Cancel every working order on the session that matches a given symbol (optionally narrowed to one side). The gateway iterates internally, dispatches one cancel per affected order, and enumerates them in the outbound OrderMassCancelReport (35=r) via the NoAffectedOrders (534) repeating group.
Only MassCancelRequestType = 1 (CANCEL_ORDERS_FOR_A_SECURITY) is supported.
Required fields¶
| Tag | Field | Req? | Notes |
|---|---|---|---|
11 |
ClOrdID | Y | Echoed back in 35=r as both 11 and 1369 MassActionReportID. |
530 |
MassCancelRequestType | Y | Only 1 supported today. |
55 |
Symbol | Y | Required when 530=1. |
54 |
Side | N | Optional. 1 = BUY, 2 = SELL. Omit to sweep both sides. |
60 |
TransactTime | Y | UTC YYYYMMDD-HH:MM:SS.sss |
Response¶
| Outcome | Fields |
|---|---|
| Accepted | 35=r · 531=1 · 533=N · one 534/41/535 entry per affected order |
Rejected — unsupported 530 |
35=r · 531=0 · 532=0 MASS_CANCEL_NOT_SUPPORTED |
Rejected — missing Symbol |
35=r · 531=0 · 532=1 INVALID_OR_UNKNOWN_SECURITY |
Rejected — unsupported Side |
35=r · 531=0 · 532=99 OTHER |
WARNING:
35=ris an ACK of the mass-cancel request, not of each individual cancel outcome. Every affected order still generates its ownExecutionReport (150=4 Canceled)asynchronously from the matching engine — just like a single35=F. Use the534group to know whichOrigClOrdIDs to expect.
Inbound · OrderMassCancelRequest
8=FIXT.1.1|9=...|35=q|34=120|49=CLIENT|56=PtradeFIXServer-AU|
11=mc-001|530=1|55=BTC_USDT|54=2|60=20260522-09:10:00.000|10=...
Outbound · OrderMassCancelReport (accepted)
8=FIXT.1.1|9=...|35=r|34=121|49=PtradeFIXServer-AU|56=CLIENT|
11=mc-001|1369=mc-001|530=1|531=1|55=BTC_USDT|533=2|
534=2|41=cli-10001|535=1234567|41=cli-10002|535=1234568|10=...
Order-entry field reference¶
Order entry¶
| Tag | Field | Notes |
|---|---|---|
11 |
ClOrdID | Client-assigned, unique per account. |
21 |
HandlInst | Dictionary requires it; typical value 1. |
38 |
OrderQty | Base quantity. Mutually exclusive with 152 on MARKET. |
40 |
OrdType | 1=MARKET · 2=LIMIT |
44 |
Price | LIMIT only. Ignored on MARKET. |
54 |
Side | 1=BUY · 2=SELL |
55 |
Symbol | BASE_QUOTE |
59 |
TimeInForce | 0=DAY · 1=GTC · 3=IOC · 4=FOK |
60 |
TransactTime | UTC YYYYMMDD-HH:MM:SS.sss |
152 |
CashOrderQty | Quote-currency amount; MARKET only. |
Summary (quick)¶
| Tag | Name | Values (from guide) |
|---|---|---|
| 40 | OrdType | 1 MARKET, 2 LIMIT |
| 59 | TimeInForce | 0 DAY, 1 GTC (default), 3 IOC, 4 FOK |
REST OpenAPI supports additional order types (stop / take-profit / LIMIT_MAKER). FIX support beyond MARKET/LIMIT is [NEEDS-CONFIRMATION] against server handlers when source is available.