FIX 4.4 API

Order entry, execution reporting and streaming market data over FIX 4.4. The FIX surface maps onto exactly the same engine command path, risk checks, rate limits and post-durable delivery as REST and the WebSocket: an ExecutionReport is never emitted before the journal made the event durable, and every execution carries the same ExecID that identifies it on the other two transports.

This page is the rules of engagement. It documents what the acceptor actually does, including the places where Kronos X deliberately departs from a textbook FIX engine. The most important departure is that the venue keeps no FIX message store: recovery after a disconnect is a REST call, not a ResendRequest. Read Sequence numbers and recovery below before you write a session layer.

Connectivity

• FIX 4.4 only. The first nine bytes of every inbound message must be 8=FIX.4.4. Any other BeginString is a framing error and the connection is dropped. There is no FIX 5.0 or FIXT session layer.
• TLS is mandatory (TLS 1.3, the same publicly trusted venue certificate as the REST API). Complete the handshake before writing a single FIX byte. There is no plaintext port, and there is no client-certificate requirement: authentication is the API key on Logon.
• Your CompID is whatever you send as SenderCompID(49) on Logon. The venue records it from that message and echoes it as TargetCompID(56) on everything it sends you. It is not pre-registered, so it must be stable across reconnects only for your own reconciliation.
• Credentials are the same API key and secret used on REST and WebSocket. The key carries a scope: a READ_ONLY credential logs on successfully but cannot trade on any transport. See Drop copy and credential scope below.

Wire format

Framing

Standard tag=value with SOH (0x01) as the field separator. The venue generates and validates both length fields; get them wrong and the session ends immediately.

8=FIX.4.4|9=<bodyLength>|35=<msgType>|49=<sender>|56=<target>|34=<seqNum>|52=<sendingTime>|...|10=<checkSum>|

Reading the stream

TCP will hand your reader half a message, or two and a half messages, in a single read. The venue does not pad, align or delay frames to make one read equal one message. Your codec must append every read to a buffer and then loop: parse the length prefix, wait until BodyLength plus the seven trailer bytes (10=xxx plus SOH) are present, take that message, and try again on the remainder. Assuming one read equals one message is the single most common cause of a first-day conformance failure.

Session layer

Logon (35=A)

Nothing but a Logon is accepted before authentication. Any other message type on a fresh connection produces a Logout with Text(58)=logon required and a close.

Checks run in the order 98, 141, 108, credentials, 34, so the first failure names the real cause. On success the venue replies with a Logon of its own on outbound sequence 1, echoing 98, 108, 141=Y and the effective values of 9003 and 9004, so a drop-copy session that sent 9004=Y reads N back. Treat that echo as the authoritative statement of what the session can do.

Cancel on disconnect (tags 9004/9005)

An opt-in protection, armed PER SESSION and in memory only: re-arm on every logon. When an armed session disconnects, for any reason, the venue waits the 9005 grace window and then, if the member has no live FIX TRADING session left, submits ONE member-scope cancel-all: every open order of the member, on every instrument, untriggered conditionals included, regardless of the transport that placed them (orders belong to members, not connections, so no per-connection cancel exists). The cancels arrive as ordinary 150=4 reports with Text(58)=USER_REQUESTED, the member's own standing instruction, and no ExecRestatementReason(378): by their tags they cannot be told apart from a member-wide cancel-all of the member's own or from the member portal's kill switch, which report USER_REQUESTED too (ADMIN_CANCEL is reserved for cancels by venue operations). What tells the protection apart is that it follows an armed session's disconnect and the grace window, that it is ONE command (every report carries the same engine sequence prefix in ExecID(17)), that it covers every open order of the member, and that it answers no request (revision 2.30 states it; the value stays USER_REQUESTED by design).

• Only a trading Logon disarms it. A FIX TRADING Logon within the grace window clears the pending timer. Timers are per transport: only a FIX Logon clears a FIX timer, a WebSocket reconnect does not and vice versa (the WebSocket arms its own via the session.cancelOnDisconnect op).
• Drop-copy sessions count for neither side. A drop-copy session (9003=Y or a READ_ONLY credential) cannot arm the protection, its presence does not satisfy the liveness probe, and a drop-copy Logon does not disarm a pending timer: an always-connected drop-copy feed can never silently void the protection a trading session armed. A credential that cannot manage orders neither triggers cancels nor vetoes them.
• Last-instant reconnects win. The venue re-checks liveness immediately before submitting the cancel-all, so a trading Logon landing even at the last instant still stops it. A second armed session of the same member dropping restarts the grace window on a BEST EFFORT basis: the restart can race a timer already at expiry, so treat it as advisory.
• A venue restart voids arming. Arming is in-memory by design: a restart or failover voids every pending timer and every armed session uniformly, nothing fires during or after it, and every re-logon starts unarmed.
• A leader change voids it too (clustered deployments, revision 2.25). A session the venue logged out for a leader change arms nothing, no session that closes on a node which is not the leader arms anything, and a pending timer whose node lost the leadership is voided. Your resting orders survive on the new leader.
• Orders only, never positions. The venue does not close, reduce or hedge any position on a disconnect.

Venue restarts

When the venue stops for a rollout or a restart, every FIX session receives Logout(35=5) with Text(58)="venue restart" before the TCP connection is closed (best effort: a session whose outbound queue is full is closed at the same bounded deadline). The venue sends the same Logout (revision 2.27), while it keeps running, to every session that may have missed an ExecutionReport when a venue-side fault lost the reports of one command or batch (the command itself executed); no other Logout text marks that case, and the recovery procedure below (the REST backfill of the order and execution families) brings your order state back in step. Before revision 2.27 this paragraph said that nothing is dropped for cause; that holds for a venue stop only. In both cases: reconnect with backoff, Logon again with 141=Y, re-arm 9004 if you use it, re-issue your MarketDataRequests, and run the recovery procedure below over the durable REST backfill. Neither the session nor its subscriptions nor its cancel-on-disconnect arming survive a restart. The WebSocket twin is close status 1001 with reason venue restart.

// client -> venue
8=FIX.4.4|9=130|35=A|49=MEMBER07|56=KRONOSX|34=1|52=20260801-09:14:03.117|98=0|108=30|141=Y|553=kx_live_7f3a9c21|554=s3cr3t-not-a-real-key|9003=N|10=172|

// venue -> client
8=FIX.4.4|9=83|35=A|49=KRONOSX|56=MEMBER07|34=1|52=20260801-09:14:03.129|98=0|108=30|141=Y|9003=N|10=217|

Leader change (clustered deployments, revision 2.25)

A single-node deployment is unchanged. On a clustered deployment one node, the leader, accepts orders, and the venue's entry address always leads to it. When the node your session is on hands the leadership to another node, every FIX session on it receives Logout(35=5) with Text(58)="leader change, reconnect" before the TCP close. The venue is not restarting: do what you do after a restart, only the reason on the wire differs. The clustered sandbox of revision 2.30 (three nodes behind sandbox.mtf.perpetuals.net, from the date venue operations announce) sends this Logout at every leader change there, including the leader hand-over venue operations stage at an agreed time for Conformance Test Plan case I-05.

1. A NewOrderSingle(35=D), OrderCancelRequest(35=F), OrderCancelReplaceRequest(35=G) or MarketDataRequest(35=V) received by a node that is not the leader is answered with Logout(35=5), Text(58) "leader change, reconnect", then the close; reconcile by ClOrdID(11) on the leader before you resubmit. Session-level messages are answered as before. A drop-copy session's order entry stays refused with BusinessMessageReject(35=3), 373=99 on every node, as before. Reconnect to the leader and recover through the event stream. Before revision 2.25 such a session was answered 9010=5001 "engine busy, retry" (or a 35=9 "engine busy") for as long as the node's demotion was delayed.
2. 9010=5001 "engine busy, retry" on an order and the 35=9 "engine busy" reject on a cancel or a replace now mean that the leader's intake is full; a node that no longer leads sends the leader-change Logout instead. An order appended just before a leader change may still execute: reconcile by ClOrdID(11) on the leader before you resubmit.
3. A session the leader change logged out arms no cancel-on-disconnect, like a restart; your resting orders survive on the new leader.
4. A FIX session receives the Logout on every leader change, also on a node that regains the leadership at once: every new leadership term starts a fresh acceptor, so log on again whenever you read the text.
5. (Revision 2.30 states it; nothing changed.) Reconnect with backoff to the FIX host and port you configured for the environment: node addresses are not published and are not member endpoints, so never pin a node. A reconnect just after a leader change can still fail, or be logged out with the same text: reconnect again after a short delay. FIX never answers 5030; the REST and WebSocket 5030 and its leader hint are on the REST and WebSocket pages. An order whose outcome you did not see before the Logout may still execute (the former leader answers an order it had already appended with the Logout, not with a report): reconcile by ClOrdID(11) on the leader, and never send it again under a new ClOrdID(11). A cancel or a replace whose 150=4 or 150=5 you did not see did not necessarily take effect: send it again on the new session at once, so a resting order you meant to pull does not stay on the book.
6. (Revision 2.30 states it; nothing changed.) An order, cancel or replace (35=D, 35=F, 35=G) whose commit the cluster does not confirm within 10 seconds (its pending-acknowledgement window, which a stalling disk on a follower can exhaust) ends the session: the venue closes the TCP connection without a Logout and without a report for that message. Unlike the leader-change Logout, that close counts as a disconnect for the cancel on disconnect: on a session that armed it (9004=Y) the protection cancels every open order of your member after its grace window unless a FIX TRADING Logon disarms it first. The outcome of the message is unknown and it may still execute: log on again at once, reconcile by ClOrdID(11) on the leader before you resubmit, and never send it again under a new ClOrdID(11). REST and, since revision 3.83 of the member reference, the WebSocket answer the same fault 5000.

Heartbeats and timeouts

• Send Heartbeat(0) whenever you have been silent for your HeartBtInt. The venue does the same on its own outbound direction.
• A TestRequest(1) from either side must be answered with a Heartbeat(0) echoing TestReqID(112). The venue answers yours immediately, on the session read path. Always send 112: the answering Heartbeat has to echo it, so a TestRequest without it leaves the venue nothing legal to send back and answers a session-level Reject(35=3) with 373=1, 371=112, 372=1, and no Heartbeat.
• After 1.2x HeartBtInt of inbound silence the venue sends a TestRequest with a generated TestReqID. After 2x it gives up: Logout(5) with Text(58)=heartbeat timeout, then close.
• Nothing follows a venue Logout (revision 2.26): until the disconnect the session acts on no message it receives, so a Logon that crosses the logon timeout Logout is not answered and disarms no pending cancel-on-disconnect, and it receives no further ExecutionReport. Reports of that window reach your other sessions and the event stream; recover them through GET /v1/stream/events.
• The liveness sweep runs once per second, so treat the thresholds as approximate to within a second and do not tune your own timers to sit exactly on them.

Sequence numbers and recovery

// gap detected: the Logout tells you exactly where to go
8=FIX.4.4|9=181|35=5|49=KRONOSX|56=MEMBER07|34=12|52=20260801-09:22:10.640|58=MsgSeqNum 14 where 12 expected: FIX resend is not supported, re-logon with 141=Y and recover via GET /v1/stream/events|10=149|

// answer to a ResendRequest: a GapFill, not a replay
8=FIX.4.4|9=71|35=4|49=KRONOSX|56=MEMBER07|34=18|52=20260801-09:21:00.500|123=Y|36=19|10=149|

Why not FIX resend

A FIX message store only recovers what one session missed, in that session's own numbering, and only as far back as the store is retained. It cannot help a member who trades on REST and watches on FIX, and it says nothing about venue-initiated activity that arrived while the process was down.

Kronos X instead journals every engine event once, durably, and serves it back over REST from a sequence cursor. ExecID(17) on a FIX ExecutionReport is {engineSeq}-{eventIndex}, the identical key that the REST backfill and the WebSocket private channels carry. One key reconciles all three transports, the ordering is total and engine-defined rather than per-session, and replaying it is idempotent by construction.

Recovery procedure after any disconnect, a venue restart Logout included:

1. Reconnect, Logon with 141=Y, and re-issue any MarketDataRequest: market data subscriptions are session state and do not survive.
2. Buffer inbound ExecutionReports. Do not apply them to your order state yet.
3. Take your resume point (below; on a first start with nothing persisted, GET /v1/stream/cursor).
4. Page GET /v1/stream/events?afterCursor=<resume point>&channels=order,execution (or with no channels filter) until hasMore is false and the store status is COMPLETE.
5. Apply the backfill, then drain the buffer, discarding anything whose ExecID you have already applied.
6. Resume live processing. Persist the nextCursor of your last page and the cursor of the last event you process as you go, so the next recovery is short.

Your resume point is the ordinal maximum of the nextCursor of your last backfill page and the cursor of the last event you processed; stop paging on hasMore false or count 0, never on nextCursor equal to the afterCursor you sent. A FIX recovery backfills the order and execution families together, or with no channels filter at all: since member API revision 3.73 the nextCursor of a last page is a position at the store watermark, valid only with the same filter, so discard buffered reports by your backfill cursor only for the families that backfill read.

A backfill page can answer HTTP 429 with 1003 (more reads of yours in flight on the node than it serves at once, or the node's shared budget of these reads full) or HTTP 503 with 5007 (the venue's history store did not answer in time, is held after a slow read, or is catching up): sleep data.retryAfterMs, retry the same page with the same cursor, never advance your cursor on a refusal, and narrow the read (a smaller limit) after repeated 5007.

Because this path is mandatory, a FIX-only integration is not viable. Provision REST credentials alongside your FIX session before go live. See REST API for the backfill endpoints.

Order entry (35=D)

Order semantics

• Trigger direction is derived from side, never sent: a buy stop triggers at or above StopPx, a sell stop at or below. That is conventional stop semantics and matches the native API.
• Prefer 9002=MARK for stop-losses. LAST can be moved by a single small print, which is exactly the condition under which a protective stop should not fire.
• MARKET with FOK is all or none inside the protection collar: either a complete set of fill reports or one Canceled with Text(58)=FOK_UNFILLABLE. Never a partial. MARKET with GTD or post-only is rejected outright.
• Market orders are margined at the collar price, not at the touch. An empty book gives 2007.
• Take-profit order types are not reachable over FIX. OrdType(40) accepts only 1 to 4, so TAKE_PROFIT_MARKET and TAKE_PROFIT_LIMIT must be placed on REST or the WebSocket. Their reports still arrive on your FIX session, because the session is a full-member drop copy.
• There are no iceberg, trailing-stop or pegged orders anywhere on the venue. MaxFloor(111) is not supported.

Reusing a ClOrdID

ClOrdID(11) is unique per member for 24 hours and is the venue's idempotency key. Reusing one while the venue still holds it never creates a second order, and the venue answers the NewOrderSingle either way, on the session that sent it:

The venue holds a reference for 24 hours, or until it releases it to stay inside its retention bound of the most recent 4,000,000 references venue-wide, whichever comes first. A released reference is unknown, so a reuse is accepted as a NEW order (150=0) rather than answered with either shape below. A reference whose order is still working or pending trigger is never released, so OrigClOrdID(41) on a cancel or replace resolves for the whole life of the order.

The 150=I restatement is the FIX shape of the REST and WebSocket duplicate: true response: the same idempotency path, reported in the form FIX has for it. It is a status snapshot rather than a lifecycle event, so like the 2009 rejection it is never written to the durable event stream and never appears in a backfill, and its ExecID(17) is a gateway-local dup-<n> value outside the cursor space.

Annotated example

A post-only, reduce-only buy of 25 BTC (base-asset units, as every OrderQty is) at 61250.50, on member CompID MEMBER07 for end client CLIENT-0007:

8=FIX.4.4|9=176|35=D|49=MEMBER07|56=KRONOSX|34=2|52=20260801-09:15:22.481|11=mm-4f21-000318|1=CLIENT-0007|55=BTC-USD-PERP|54=1|38=25|40=2|44=61250.50|59=1|18=6|9001=Y|60=20260801-09:15:22.481|10=118|

  8=FIX.4.4                    BeginString, always first, always exactly this
  9=176                        bytes from after this field's SOH to the SOH before 10=
  35=D                         NewOrderSingle
  49=MEMBER07                  your CompID (venue echoes it as 56)
  56=KRONOSX                   venue CompID, constant
  34=2                         second message of the session (Logon was 1)
  52=20260801-09:15:22.481     SendingTime, UTC, always .fff
  11=mm-4f21-000318            ClOrdID: your key, unique per 24 h, not KX- prefixed
  1=CLIENT-0007                Account: clientUid, mandatory, echoed on every report
  55=BTC-USD-PERP              Symbol
  54=1                         Side: buy
  38=25                        OrderQty, qtyStep-aligned decimal string
  40=2                         OrdType: limit
  44=61250.50                  Price, tick-aligned decimal string
  59=1                         TimeInForce: GTC
  18=6                         ExecInst contains 6: post-only, overrides 59
  9001=Y                       venue tag: reduce-only
  60=20260801-09:15:22.481     TransactTime, accepted and ignored
  10=118                       CheckSum over every preceding byte, mod 256, 3 digits

Rejections before the engine

Rate limiting, the order-to-trade gate and tag mapping are enforced in the gateway, before a command is ever built. Those rejections come back synchronously as an ExecutionReport with 150=8, 39=8 and OrderID(37)=0. A message MISSING a required tag is refused one step earlier still, at the session layer, with a Reject(35=3): that verdict is reached before any of these gateway checks run, so a 35=D that both omits a required tag and would have been rate limited answers the 35=3. Such a message was never accepted for processing, so its Reject is the whole answer to it, it is not one of the answers counted by the reply-completeness rule below, and it consumes no order-budget token and is not counted in your RTS 9 order-to-trade ratio. Anything answered with a business reject WAS accepted for processing and is charged and counted as usual. The same session-layer refusal applies to a Side(54) outside the FIX 4.4 enumeration (1 to 9, A to G), with SessionRejectReason(373)=5 instead of 1: Side is the one tag the venue echoes onto its own answer that FIX both marks required on an ExecutionReport and restricts to a value set, so echoing 54=X would produce a report your engine refuses. A Side inside the enumeration that the venue does not trade, 54=5 for example, keeps its unchanged 9010=2013. Engine rejections arrive through the post-durable report chain as the order's terminal report, 150=8, 39=8 and the code in 9010 (an order the engine accepted and then rejected inside the same command, a post-only order that would cross, first receives its 150=0 accept). That REST reports the same verdict inside an HTTP 200 as data.status REJECTED and the WebSocket in its ack is deliberate: each transport uses its own place for a verdict, and the convention stays.

8=FIX.4.4|9=204|35=8|49=KRONOSX|56=MEMBER07|34=8|52=20260801-09:15:52.311|37=0|11=mm-4f21-000502|17=rej-1794350118-4|150=8|39=8|55=FOO-USD-PERP|54=1|151=0|14=0|103=99|9010=2001|58=unknown symbol|60=20260801-09:15:52.311|10=166|

Cancel and cancel/replace

A PRESENT but invalid Price(44) or OrderQty(38) on a replace is rejected, never treated as "not supplied" and never partially applied: a 44 off the instrument tick grid, or a 38 off the qtyStep grid, answers OrderCancelReject(9) with 434=2 and 2002 in 9010, exactly the 2002 the same input earns on REST and WebSocket; a 44 or 38 that is not a decimal numeral at all (an exponent, a blank, letters) answers the same reject with 2013 in 9010, again exactly as REST and WebSocket do. Either way the working order keeps its original terms. Validate against the instrument grid from GET /v1/instruments before you send.

In production a member with no licensing profile receives OrderCancelReject(9) with 434=2, 102=0 and 9010=2034 on every 35=G (revision 2.20), the same fail-closed posture as 35=D and as the REST and WebSocket amend (Member API section 6f); the request never reaches the engine and the working order keeps its terms. The sandbox never answers it.

OrderCancelReject (35=9)

8=FIX.4.4|9=133|35=9|49=KRONOSX|56=MEMBER07|34=9|52=20260801-09:16:02.880|37=0|11=mm-4f21-000401|41=mm-4f21-000106|39=8|434=1|102=1|58=unknown order|10=026|

ExecutionReport (35=8)

Your session is a full-member drop copy. Reports cover every order of your member id regardless of which transport originated it: this FIX session, another FIX session, REST, the WebSocket, or the venue itself through liquidation and ADL. You do not need a second connection to observe your own flow.

ExecType and OrdStatus combinations

// partial fill: 15 of 25 done at 61250.50, 10 still working
8=FIX.4.4|9=213|35=8|49=KRONOSX|56=MEMBER07|34=7|52=20260801-09:15:41.204|37=880412|11=mm-4f21-000318|1=CLIENT-0007|17=4193887-2|150=F|39=1|55=BTC-USD-PERP|54=1|151=10|14=15|60=20260801-09:15:41.203|32=15|31=61250.50|9011=MEMBER|10=177|

Durability, dedupe and CumQty

No ExecutionReport is emitted before the journal made the event durable. Reports are constructed on the engine thread as events are produced, held in a pending list, and released to session queues only after the group commit that covers them. A report you have received therefore describes state that survives a venue restart. Pre-engine gateway rejections are the sole exception, and they are exceptional precisely because no state was created.

Code 5005: the venue could not finish

5005 COMMAND_FAILED means the venue accepted your command, made it durable, and then could not finish processing it. Trading continues normally, and whatever the command achieved before it stopped is kept. That is the same contract REST and the WebSocket publish, where 5005 arrives as data.rejectCode and the rest of data describes what the command did, so an orderId there is a real order. FIX says the same thing in FIX terms, and always in exactly one further report. Which row you are in is decided by what the command DID, read top to bottom:

Cancel reasons in Text(58)

One of a closed enumeration: USER_REQUESTED, IOC_REMAINDER, FOK_UNFILLABLE, GTD_EXPIRED, STP_CANCEL, LIQUIDATION_CANCEL, ADMIN_CANCEL, INSTRUMENT_HALT, MEMBER_SUSPENDED, REDUCE_ONLY_VIOLATION, SPOT_UNFUNDED, POSITION_SIZE_LIMIT, MARKET_ACCESS (revision 3.65: the venue cancelled the order on a DENIED access decision or an admission flip), FUNDING_CATCH_UP (revision 3.70, venue-initiated: a conditional that triggered while the market's GRID funding catch-up was pending; reduce-only conditionals execute), POST_ONLY_WOULD_CROSS (revision 3.70, venue-initiated, drop copy only since FIX carries no post-only time in force: a post-only order that rested through a call on a scheduled SECURITY market and would cross on the entry into continuous trading). USER_REQUESTED covers a cancel of yours on any transport, a member-wide cancel-all, the member portal's kill switch and the cancel on disconnect you armed; no ExecRestatementReason(378) tells them apart. INSTRUMENT_HALT also marks the cancels of a delisting, which is how a re-listing begins: a tickSize or qtyStep change is never made in place (the REST page, Instruments), and FIX carries no instrument reference or status message, so re-read GET /v1/instruments after an announced date and on any unexpected 9010=2001, 2002 or 3006.

Venue-initiated closes

Liquidation and ADL reach your book as ordinary trade reports on orders you never sent. They carry 9011=VENUE and a ClOrdID in the reserved KX- namespace. That namespace cannot collide with yours: any member ClOrdID beginning KX- is rejected at submission with 2020, so the two spaces are disjoint by construction. Branch on 9011 rather than on the shape of the reference, because 9011 is the field whose meaning is defined; the prefix is an implementation of it. Your order state machine must tolerate reports for order ids it has never seen. See Trading rules for liquidation and ADL mechanics.

Drop copy and credential scope

Every FIX session is already a full-member drop copy, so a separate connection is not needed merely to observe your own flow. A dedicated drop-copy session exists for back-office, risk and surveillance consumers that must not be able to trade. There are two ways to get one and they compose: the effective state is drop-copy if either applies.

The Logon reply echoes the effective value in 9003, so a client can always tell which mode it got. On a drop-copy session, ExecutionReports and market data flow normally, and D, F and G are refused at the session layer with a Reject(3) naming the message type, without ever reaching the engine.

8=FIX.4.4|9=143|35=3|49=KRONOSX|56=RISK01|34=3|52=20260801-09:20:44.010|45=2|372=D|373=99|58=drop-copy session: order entry is disabled, use a trading session|10=225|

Market data (35=V, 35=W, 35=X)

Market data is available on any session, trading or drop copy. A subscription covers one instrument and is session state: it is lost on disconnect and must be re-issued after re-logon. A session may hold up to 32 instrument subscriptions at once.

Body field order is not significant. The venue parses tag=value pairs into a map and reads every field by tag, so the order in which you place 264, 265, 267/269 or any other non-group body field changes nothing. Three things are positional and always have been: the standard header must open 8=FIX.4.4, 9= must follow it, and 10= must sit exactly at the BodyLength(9) boundary. Any of those three wrong is unframable rather than rejectable, so the venue logs out and closes the connection instead of answering 35=3. Repeating-group entries are read in arrival order, which is the only place body order matters, and 269 is the only group the venue reads inbound.

Required fields are never defaulted. A field marked required above is rejected by name when it is absent or carries an empty value; the venue does not substitute a value, because on this message a substituted value silently changes what the request means. 263 is the case that matters most: it decides whether you get one snapshot or a stream, so an absent 263 read as 0 would give you one W and then permanent silence, indistinguishable from a subscription on an instrument that never trades. The optional fields are the deliberate contrast: their absence selects the documented default in the same column and can never change whether the feed exists, so a request carrying only 262, 263, 146 and 55 works exactly as it always has.

And a value you DID send is never replaced. That is the same rule read from the other side, and it is what MarketDepth(264) follows: an ABSENT 264 takes the documented 5 level default, while a 264 the venue cannot serve is REFUSED by name rather than adjusted to something else. The venue adjusts no field on this message.

• 263 and 55: MarketDataRequestReject(35=Y) with MDReqRejReason(281) 4 and 0 respectively, and a Text(58) naming the tag. Nothing is subscribed.
• 264 present and outside 1 to 25, or not an integer: MarketDataRequestReject(35=Y) with MDReqRejReason(281)=5 and a Text(58) naming the tag and the servable range. Nothing is subscribed. An ABSENT 264 is not this case and is unaffected.
• 262: a session-level Reject(35=3) with SessionRejectReason(373)=1 (required tag missing), RefTagID(371)=262 and RefMsgType(372)=V. A 35=Y cannot answer this one, because 35=Y must itself carry the MDReqID that is missing. The session stays up.

This applies to every 263 value including the 2 disable: a disable with no 262, no 263 or no 55 is rejected rather than guessed at.

Re-issuing a request for an instrument you already hold replaces that subscription and is never refused, so recovery works even at the subscription limit.

The body carries MDReqID(262), Symbol(55), then NoMDEntries(268) followed by that many repetitions of MDEntryType(269), MDEntryPx(270) and MDEntrySize(271). Entries are ordered bids first, then offers, then the last trade. All prices and sizes are exact decimal strings. Entry types you did not ask for are simply absent.

268 is the true entry count: bid levels plus offer levels plus one when the instrument has traded. A book with no resting orders and no prints yields a valid W with 268=0, so your parser must handle an empty group. Because the last-trade entry has no 271, drive the repeating-group parser off 269 rather than assuming a fixed three-tag stride.

The body carries MDReqID(262), NoMDEntries(268), then that many entries. Each entry begins with MDUpdateAction(279), which is the group delimiter.

Inside one X the order is fixed: the trade entries of that commit batch, in engine order, then the book entries, bid entries before offer entries. The book entries describe the state at the end of the batch, that is the state after those trades. Do not depend on that ordering to parse: split the group on MDUpdateAction(279) and read MDEntryType(269) on each entry.

// request: snapshot plus incremental updates, 5 levels a side, book and tape
8=FIX.4.4|9=135|35=V|49=MEMBER07|56=KRONOSX|34=3|52=20260803-09:15:04.988|262=md-btc-1|263=1|265=1|264=5|146=1|55=BTC-USD-PERP|267=3|269=0|269=1|269=2|10=107|

// snapshot: 2 bids, 2 offers, 1 last trade
8=FIX.4.4|9=217|35=W|49=KRONOSX|56=MEMBER07|34=4|52=20260803-09:15:05.002|262=md-btc-1|55=BTC-USD-PERP|268=5|269=0|270=61250.00|271=42|269=0|270=61249.50|271=118|269=1|270=61250.50|271=37|269=1|270=61251.00|271=90|269=2|270=61250.00|10=128|

// increment: one print, then the resulting book state, bid entries before offer
// entries (the best bid grew, the best offer was partly consumed by that print)
8=FIX.4.4|9=293|35=X|49=KRONOSX|56=MEMBER07|34=5|52=20260803-09:15:07.114|262=md-btc-1|268=3|279=0|269=2|278=880412|55=BTC-USD-PERP|270=61250.50|271=12|272=20260803|273=09:15:07.109|9013=1|9014=NORMAL|279=1|269=0|55=BTC-USD-PERP|270=61250.00|271=50|290=1|279=1|269=1|55=BTC-USD-PERP|270=61250.50|271=25|290=1|10=067|

// re-baseline after this session fell behind: discard the book and rebuild from this W.
// The 269=2 entry is the last trade price, which every W carries for a subscriber
// that asked for trades, so 268 counts it.
8=FIX.4.4|9=164|35=W|49=KRONOSX|56=MEMBER07|34=6|52=20260803-09:15:09.771|262=md-btc-1|55=BTC-USD-PERP|268=3|269=0|270=61250.00|271=50|269=1|270=61251.00|271=90|269=2|270=61250.50|10=235|

// reject
8=FIX.4.4|9=108|35=Y|49=KRONOSX|56=MEMBER07|34=7|52=20260803-09:15:31.777|262=md-xyz-9|281=0|58=unknown symbol FOO-USD-PERP|10=054|

What the incremental feed guarantees

• The snapshot and the increments are consistent. The venue registers the subscription and builds the W in one step on the engine thread, and the snapshot is released to your session through the same post-durability gate as your ExecutionReports, in the order it was built. So an increment for a change that happened after that snapshot can never overtake it, and the snapshot is never ahead of the durable state it describes. Apply the W, then apply every following X in order.
• A re-subscribe wins immediately. Re-issuing the request for a symbol replaces the subscription. Anything the venue had already built for the subscription you replaced is discarded rather than delivered after the new snapshot, so narrowing MarketDepth(264) or the MDEntryType(269) set can never leave your book holding entries the new window would not have sent.
• Loss is detectable, by MsgSeqNum(34). Market data shares the session's outbound sequence with ExecutionReports, so a missing message is a sequence gap like any other. The venue never renumbers and never re-sends.
• The venue never silently gaps your book. If your session falls behind, the venue stops sending increments for it rather than racing your queue to the disconnect line, and the next message it sends you for that instrument is a fresh complete W. Treat any W arriving mid-stream as a re-baseline: discard your book for that symbol and rebuild from it.
• Trade entries are best effort. While a session is behind, prints for that instrument are dropped rather than queued, and the re-baseline W restores the book but not the missed prints. Reconcile against GET /v1/trades if you need a gap-free tape: it returns the venue's prints for an instrument in engine order with nothing missing inside the window it covers, which is the most recent 1000 prints of that instrument. It is a recent-trades route and not an archive, so reconcile while you are still inside that window.
• Depth is 1 to 25 levels a side. 25 is the maximum SERVABLE depth, and a request for more is refused with 281=5 rather than trimmed to fit. The diff is taken against the window you subscribed at, so a level that rises into your window because a better one was deleted arrives as a New. You never have to infer it.

Recovery

Re-issue the MarketDataRequest. The venue answers with a fresh W and re-seeds the incremental baseline from it, so everything that follows is consistent with the new snapshot. That is the recovery procedure for every case: after a reconnect, after a detected sequence gap, after an unexpected re-baseline W, or any time you doubt your book. There is no market-data resend and none is needed.

A rejected request subscribes nothing: there is no partial subscription.

A MarketDataRequest with no MDReqID(262) is answered by a session-level Reject(35=3) instead, carrying SessionRejectReason(373)=1, RefTagID(371)=262 and RefMsgType(372)=V. Treat it as a rejected request: nothing is subscribed and the session continues. Text(58) on every one of these names the tag at fault, and the venue never answers a MarketDataRequest it REFUSES with silence: every refusal above is an explicit message naming the field that caused it, and it adjusts no field on this message, so an unservable value is refused rather than quietly turned into a servable one. A refusal is also never dropped to save a slow consumer: 35=Y and 35=3 are guaranteed-class like your ExecutionReports, so a session too far behind to receive one is disconnected rather than left with an unanswered request. Only the refresh stream (35=W, 35=X) is best effort.

Rate limits and controls

• There are two independent full-capacity token buckets per member, shared across the member's keys: 6000 reads/min and a 40000/min order budget. Order placements, batch entries (REST/WS only), and amendments all consume the order budget; cancels are never throttled. Order entry does not consume a read token. Because both refill to full capacity, a quiet period leaves the whole minute available for a burst. FIX order entry shares the per-second ceiling your class publishes (STANDARD 1,000 orders/s on production, none on the sandbox; Member API section 4); a burst above it answers a report with Text(58) carrying retryAfterMs under one second.
• Batch order entry (POST /v1/orders/batch, WS orders.batch) is not offered over FIX: submit NewOrderSingle messages in a loop instead. Nor are batch amendment (POST /v1/orders/batch/amend, WS orders.batchAmend) and batch cancellation (POST /v1/orders/batch/cancel, WS orders.batchCancel), Member API revision 3.74: FIX 4.4 has no message that amends or cancels a list of orders by id, so send OrderCancelReplaceRequest(35=G) or OrderCancelRequest(35=F) per order, or use those routes on a native connection alongside.
• The buckets refill continuously, not at a window boundary, and a rate-limit reject tells you the wait: Text(58) reads rate limit, retry after 2ms. Sleep that long and resend. Treating the limit as a fixed window costs you up to a minute of dead time for a wait that is usually a couple of milliseconds. After ten 5005 answers of yours within 60 seconds the reject reads rate limit: repeated engine faults (5005), retry after 41250ms, and that wait can be up to 60 seconds (Member API section 4, revision 3.79): sleep it, and never resend the commands that answered 5005 unchanged. A reduce-only D (9001=Y) and a cancel are not refused by that budget; a replace (G) is.
• FIX order entry is metered at member granularity: all FIX sessions of one member draw on a single order bucket, accounted separately from the REST and WebSocket bucket of the key you logged on with. Do not size a FIX burst on the assumption that it shares tokens with your REST traffic, in either direction.
• Cancels are always admitted so that a member can always flatten its resting exposure, including while the order-to-trade regime is blocking new orders. They still count toward the ratio, so a cancel storm will eventually block your new orders with 1004.
• A rate-limit or ratio refusal on D is an ExecutionReport 150=8 with 9010=1003 or 9010=1004. On G it is an OrderCancelReject(9) with 102=0 and 434=2.

What FIX does not carry

FIX is order entry, execution reporting and market data. Everything else stays on the native API and needs a REST credential:

Conformance checklist

Run this against the sandbox before requesting production access. Each item maps to a behaviour above that has broken a real integration.

1. Round-trip your codec against a known-good message: parse it, rebuild it byte for byte, and confirm BodyLength and CheckSum match. Then corrupt one checksum digit and assert the venue closes the connection.
2. Feed your parser a message split across three TCP reads, and two messages in one read. Assert both are decoded correctly.
3. Logon with 141=Y and valid credentials; assert the Logon echo carries 98, 108, 141=Y and 9003. Then logon with a bad secret and assert a Logout naming 1001.
4. Omit 141, and separately send 34 other than 1; assert the venue refuses each logon with the matching reason.
5. Answer a venue TestRequest(1) with a Heartbeat(0) echoing TestReqID(112). Then stay silent past 2x HeartBtInt and assert the venue sends Logout(5) with Text(58)=heartbeat timeout and disconnects.
6. Place a STOP LIMIT (40=4) with 9002=MARK and a 99 the mark will cross; assert one 150=L, 39=0 with your 37, 11 and 99 when it does, and that your order state moves from pending trigger to working without booking a fill.
7. Place a far-from-market LIMIT GTC; assert 150=0 with your ClOrdID(11), your Account(1) and 151 equal to the full quantity. Cancel it; assert an ExecutionReport with 150=4 and 58=USER_REQUESTED, and that your state machine did not wait for a 35=9.
8. Cancel an unknown order; assert OrderCancelReject(9) with 102=1 and 434=1.
9. Replace with only OrigClOrdID(41); assert it is refused. Replace correctly by OrderID(37) with a reduced total quantity; assert 150=5 with 39=0 or 39=1, not 39=5.
10. Cross against a second session; assert 150=F on both sides with correct 31, 32, 151, 14, the correct per-side 54, and 9011=MEMBER, each side's 151, 14 and 39 being its own order's after that fill.
11. Rest a SELL of 1, then send an IOC BUY of 2 at its price: assert 150=F with 39=1, 151=1, 14=1, then 150=4 with 39=4, 151=0, 14=1, and that only the second carries a terminal 39. Rest two SELLs of 1 at two prices and send a BUY of 2 through both: assert 39=1, 151=1, 14=1, then 39=2, 151=0, 14=2. Partly fill a resting order, log a second session on and fill it again: assert that session's 14 counts both fills. Fill 1 of a post-only BUY of 3 (18=6) and reprice it by a 35=G across a resting SELL: assert 150=5 with 151=2, 14=1, then 150=8 with 151=0, 14=1.
12. Cross two of your own end clients (different Account(1)); assert you receive two reports sharing one ExecID(17) and that your dedupe key kept both.
13. Send an unknown symbol; assert 150=8 with 37=0, 103=99 and 9010=2001, and that your code branched on 9010.
14. Send OrdType(40)=5; assert 9010=2004 and that your mapper routes take-profit orders to REST instead.
15. Resend a working order's ClOrdID(11) with a changed Price(44); assert 150=8 with 9010=2009. Resend it with the byte-identical payload; assert 150=I with 9015=Y and the original OrderID(37). Assert your client booked no second order in either case, and that every D you sent has exactly one answer outstanding at zero.
16. Prove your order state machine treats 150=I as a restatement and never as a terminal state, and that a report carrying 9010 does not by itself close an order. On a 5005 the 39, 151 and 14 of a 150=I describe an order you still own and still have to manage. Then cancel that order and resend its ClOrdID with the identical payload: the restatement now carries the terminal 39=4 of the canceled order, after the 150=4 that closed it. Assert your client books it as neither a second cancel nor a resurrection, and that any "one terminal 39 per order" check you run excludes 150=I.
17. Send a deliberate MsgSeqNum gap; assert a Logout naming the backfill route, then re-logon cleanly with 141=Y.
18. Kill the connection mid-flow. Recover using the buffer-then-backfill procedure, and prove the merged log is gap-free and duplicate-free by ExecID ordering. Assert the cumulative quantity you rebuilt for each order equals the 14 of its latest report and the sum of 32 over its fills, never OrderQty minus LeavesQty, which overstates an order whose remainder was canceled.
19. MarketDataRequest with 263=0: assert one W with bid and offer entries. With 263=1 and no tag 265: assert an unsolicited full W after a book change. With 263=2: assert refreshes stop. Unknown symbol: assert 35=Y with 281=0. Assert your group parser handles 268=0 and the last-trade entry with no 271.
20. 263=1 with 265=1: assert a W, then rest an order at a new price from a second session and assert an X with 279=0 at that price; add size at the same price and assert 279=1 with the summed size; remove it all and assert 279=2 with 271=0. Rebuild the book from snapshot plus increments and reconcile it against GET /v1/orderbook?symbol= while the market is quiet.
21. Subscribe with 267=1, 269=2 and cross a trade: assert an X trade entry whose 278 matches the GET /v1/trades id for the same execution, and whose 270 and 271 match its price and quantity. Assert your book code ignored the entry and your tape code recorded it.
22. Send 265=9: assert 35=Y with 281=6. Send 269=4: assert 281=8 and that no W follows, so nothing was partially subscribed. Send 264=0, then 264=50, then 264=abc: assert 281=5 and no W on each.
23. Required fields on 35=V. Omit 263: assert 281=4 naming the tag, no W, and no stream after a later book change. Omit 55: assert 281=0 naming the tag. Omit 262: assert a session-level Reject(3) with 373=1 and 371=262, and a session that stays up. Then send the same request with 264 and 265 in the opposite order, and again with 264, 265 and 267 omitted entirely: assert both behave exactly like the fully specified request. Keep the ABSENT case and the PRESENT unservable case separate in your matrix: they are the two halves of the rule and they answer differently.
24. Disable with an unservable depth: subscribe with 263=1, then send 263=2 with 55 and a 264=0 echoed from the original request. Assert it is accepted silently and the stream stops.
25. Required fields on 35=D. Omit 55, then 54, then 38, then 40, one at a time: assert a session-level Reject(35=3) with 373=1, the matching 371, 372=D, that NO ExecutionReport follows, and that the session stays up. Assert your client clears its outstanding-request counter without waiting for a 150=8, and correlates the reject by RefSeqNum(45). Then send a PRESENT but unknown 55 and assert the unchanged 150=8 with 9010=2001.
26. Send a NewOrderSingle with no ClOrdID(11): assert your parser accepts an ExecutionReport with no tag 11. Send a 35=F by OrderID(37) alone against an unknown order: assert your parser accepts 11=KX-NONE and 41=KX-NONE without matching them to a real order. Send a TestRequest(1) with no 112: assert Reject(35=3) with 371=112 and no Heartbeat.
27. Send 54=X: assert Reject(35=3) with 373=5 and 371=54. Send 54=5: assert the unchanged 150=8 with 9010=2013. Send a 35=F with 37=, 41= and 11= all EMPTY: assert an OrderCancelReject(9) carrying 37=0, 11=KX-NONE and 41=KX-NONE, all three PRESENT. Log on with SenderCompID(49) empty, and separately send anything before your Logon: assert both answers carry TargetCompID(56)=CLIENT, never an empty 56.
28. Log on a READ_ONLY credential, or send 9003=Y; assert the Logon echoes 9003=Y, that D is refused with Reject(3), and that ExecutionReports for orders placed on your trading session still arrive on it.