14. Partner FIX gateway, rules of engagement

PM MTF Ltd, brokerage division (brand barriers). FIX 4.4 over TLS beside the Partner API; the development endpoint is dev.brokerage.perpetuals.com:9850.

Revision 15, 20 October 2026, for docs/11 revision 26 (OpenAPI 2.12.6). The FIX 4.4 order-entry, barrier RFQ and drop-copy gateway of the barriers Partner API, for a partner that integrates over FIX beside the REST routes and the webhooks of docs/11-partner-api.md. The gateway maps onto exactly the same router functions, pre-trade checks, sentences, codes and hook sites as the REST routes: whatever FIX answers, REST and the webhooks would answer about the same fact, and the three transports never disagree. This document is served at https://dev.brokerage.perpetuals.com/fix beside the Partner API reference at /docs. The tag tables marked as generated and the BodyLength(9), CheckSum(10) and SendingTime(52) of every example frame are produced from the router's own code and pinned by our tests (Appendix A), so the examples can be fed to a FIX engine as they stand.

Status: live in this revision are the session layer (section 1), the client attribution (section 2), order entry, cancel and status (section 3), the ExecutionReport stream (section 4), the drop-copy session and the routing of reports (section 5), the delivery semantics (section 6), the barrier RFQ vocabulary (section 7: 35=R, 35=S, 35=AJ, 35=Z, 35=AI and the two contract reports), the reject doctrine and the reply policy (section 8), the sessions panel of our operations desk and the fix block of GET /partner/v1/me. Staking swaps, margin, collateral and market data stay on the Partner API (section 9).

Endpoint: dev.brokerage.perpetuals.com:9850 on the development environment, the same hostname as the Partner API, over TLS with a publicly trusted certificate renewed automatically. Production connectivity (host, port) is confirmed by our operations at onboarding. There is no proxy in front of the FIX port: the address the router sees is your own, and your partner CIDR allowlist applies to it exactly as it does to the REST routes.

Contents

1. Session layer
2. Client attribution
3. Order entry (35=D, 35=F, 35=G, 35=H)
4. ExecutionReports (35=8)
5. Drop copy
6. Delivery semantics and loss
7. RFQ over FIX
8. Rejects and the reply policy
9. What FIX does NOT carry
10. Conformance checklist
11. Appendix A: the custom tags 9101 to 9199
12. Changelog

1. Session layer

• FIX 4.4, tag=value, SOH delimited. BeginString must be FIX.4.4. One TLS connection per session; the certificate is the publicly trusted certificate of the Partner API hostname, renewed automatically. The TLS handshake must complete within 5 seconds of the TCP connect or the connection is closed.
• Logon deadline. A connection that has not completed a valid Logon within 10 seconds of connecting is closed; the router first attempts, best effort, a Logout(35=5) with Text(58) logon timeout. The deadline is measured from the TCP accept and inbound bytes do NOT extend it, so connect only when you are ready to log on.
• Connection ceilings, enforced at accept with the surplus connection closed immediately and no FIX frame sent: 256 FIX connections in total (authenticated sessions plus not-yet-logged-on connections plus TLS handshakes in progress), 32 connections that have not yet completed a Logon across all addresses, and 8 such not-yet-logged-on connections per remote address (an IPv6 peer counts as its /64 for that ceiling, the throttle's rule). Keep reconnect storms bounded on your side; an orderly client never approaches these. A connection from an address that is on NO partner's allowlist is closed at accept the same way, with no FIX frame, before it takes one of those slots and before the logon throttle sees it, so a stranger cannot hold the pre-logon slots against you; an address inside some partner's list but outside YOURS still reaches the Logon and hears its own Sign in again. answer. A silent close therefore tells a peer only whether its address is on some partner's list, which we accept.
• Sessions per partner. At most 4 authenticated sessions per partner (one per key, below): the fifth Logon is refused with Logout session ceiling reached for this partner and 9110=4290. A partner holds at most ten keys, so the session ceiling binds before the key cap does.
• CompIDs. Your SenderCompID(49) is your PARTNER CODE (the upper-case handle of your partner record, SWISSBORG, NEOBROKER1), on every message; your TargetCompID(56) is BARRIERS. The router sends 49=BARRIERS and 56=<your code>. Before a Logon has passed its credential checks (the logon required Logout, a refused Logon, the malformed-framing Logout), the router addresses you as 56=CLIENT: 49 and 56 are standard header fields that FIX 4.4 requires on every message and that can therefore be neither omitted nor left empty, so a documented placeholder is the only valid answer there. A 56 other than BARRIERS on the Logon is refused by name (TargetCompID(56) must be BARRIERS); a 49 that is not the code of the key's partner is refused with the credential sentence below, which reveals nothing about the key.
• Logon (35=A) must carry:
  • EncryptMethod(98)=0
  • HeartBtInt(108) between 5 and 120 seconds
  • ResetSeqNumFlag(141)=Y (required on EVERY logon)
  • Username(553) = the display prefix of your key, the ten characters pbk_ plus six that our operations desk and GET /partner/v1/me key.prefix show; Password(554) = the whole pbk_ key, over TLS
  • MsgSeqNum(34)=1
  • optionally 9120=Y for a drop-copy session (section 5)

Every one of those is checked and a failure closes the session with a Logout naming the reason, so a Logon is never partially honoured. The order of the checks: 98, 141, 108, 56, the credentials, 34, the partner ceiling, the one-session-per-key rule. The reply (35=A) echoes 98=0, 108, 141=Y and 9120 as applied (Y or N).

• Credential refusals are Logout(35=5) messages whose Text(58) is the REST sentence verbatim and whose 9110 is the REST code; the socket is closed after a short flush. The key must be ACTIVE and of scope TRADE, your partner record ACTIVE, and your address inside your allowlist.

The unknown-key answer is ONE sentence for seven causes on purpose: neither the existence of a key nor its validity is revealed to an address off the allowlist, the same rule the REST routes keep (docs/11 section 3).

• The logon throttle. Failed Logons are counted per (key prefix, remote address) pair and per remote address: five failures on a prefix FROM ONE ADDRESS, or fifty on an address, within 15 minutes lock that pair or that address for 15 minutes, during which every Logon carrying it is refused with the Sign in again. Logout before the key is even looked up. The prefix dimension is keyed on the caller's address on purpose: your key prefix is public (our operations desk, GET /partner/v1/me, your log notes), so a stranger anywhere on the internet can lock only itself out, never you. An IPv6 address counts as its /64. A successful Logon clears the pair's counter. A READ-key refusal does not count (the key is valid and the caller is its holder). The throttle is process-local and gone on a router restart; its aim is to bound guessing.
• Message rate limits. Every 35=D, 35=F, 35=R, 35=AJ and 35=Z accepted for processing counts against your partner's trade_per_minute bucket and every 35=H against read_per_minute, the SAME buckets as the REST routes (docs/11 section 3): a FIX order spends REST budget and a REST order spends FIX budget. A message refused at the session layer (Reject(35=3)) never reaches the meter. Over the limit the message's own business reject carries Too many requests. Please slow down and try again. with 9110=4290 (the shapes per message type in 8.2).
• ASCII values. FIX tag values are ASCII: a value carrying a byte above 0x7F is refused BY NAME before anything reads it, with Reject(35=3) SessionRejectReason(373)=6 (incorrect data format), RefTagID(371) = the tag, RefMsgType(372) and Text(58) non-ASCII value in tag <tag>: FIX tag values are ASCII; the session stays up and nothing is placed. A reference is therefore never silently rewritten (two references differing only in non-ASCII bytes can never read as one). Before the Logon such a byte is malformed framing (Logout malformed message: non-ASCII value in tag <tag>: FIX tag values are ASCII and the close). Your partnerClientRef obeys the same rule at onboarding (section 2).
• One session per key. A key holds at most one live session. A second Logon with a key whose session is live is refused with Logout session already active, UNLESS the live session has missed two heartbeats (the router has heard nothing from it for twice ITS OWN HeartBtInt, the same instant the heartbeat sweep would disconnect it): then the new Logon REPLACES it. The replaced session receives, best effort, Logout session replaced and is closed; the new session is registered before the old one's close completes, so the key never holds zero live sessions during a replacement. The check is on the live session's own interval, never the newcomer's, so a newcomer cannot shorten the window by declaring a short interval. Run one key per connection; a reconnect after a crash therefore waits at most twice the old session's HeartBtInt, or logs on with a second key at once.
• A key revoked, a partner suspended, an allowlist narrowed. The router re-checks the credential behind every live session at least every 30 seconds: a key revoked in our operations desk ends its session with Logout Sign in again. (9110=4010), a suspended partner's sessions end with the suspended sentence (9110=4037), and a session whose address is no longer inside your allowlist (you or our operations narrowed the list after the Logon) ends with Logout Sign in again. (9110=4010) within the same interval: the allowlist applies to a live session exactly as it applies to every REST request, so narrowing it is the way to cut off a decommissioned or compromised egress address. The key's lastUsedAt (GET /partner/v1/me) is refreshed at the Logon and then at most once a minute while the session is live.
• Sequence numbers reset on every logon. The router keeps no FIX message store. On an inbound gap the router sends Logout with the text MsgSeqNum {seq} where {expected} expected: FIX resend is not supported, re-logon with 141=Y and recover through GET /partner/v1/clients/{clientId}/orders/open and the order.*, rfq.* and barrier.closed webhooks and closes; a message with PossDupFlag(43)=Y and a MsgSeqNum(34) below the expected one is dropped silently (already processed); a SequenceReset(35=4) with NewSeqNo(36) above the expected number is honoured, one at or below it is ignored. An outbound ResendRequest(35=2) is answered with a GapFill SequenceReset(35=4) (GapFillFlag(123)=Y) that takes the next number in the router's own outbound sequence and points NewSeqNo(36) at the one after it. The router's MsgSeqNum(34) is strictly increasing for the life of a session and never renumbers. Recovery after any disconnect is the REST read plus the webhooks (section 6), which is complete, ordered and deduplicable across every transport.
• Heartbeats per HeartBtInt: the router sends a Heartbeat(35=0) when it has sent nothing for HeartBtInt, a TestRequest(35=1) after 1.2x silence from you, and disconnects after 2x (Logout heartbeat timeout, best effort). Malformed framing (a bad checksum, a bad BeginString, 10= off the BodyLength boundary, a frame above the 64 KiB BodyLength cap or a reassembly window that fills without a parse) answers Logout malformed message: <reason> and closes: FIX cannot resynchronise mid-stream.
• A TestRequest(35=1) must carry TestReqID(112). The answering Heartbeat has to echo it, so there is nothing legal for the router to send back when it is absent or empty: such a request answers a session-level Reject(35=3) with SessionRejectReason(373)=1, RefTagID(371)=112 and RefMsgType(372)=1, and no Heartbeat. The session stays up.
• The router never emits a zero-length value for any tag on any message. A tag the router cannot fill is either omitted, or carries a documented sentinel where FIX requires it to be present (section 3), or the message is refused with a session-level Reject(35=3) naming the tag. That holds on the standard header too, which is why a session that has not passed its credential checks is addressed as CLIENT rather than with an empty 56, and it holds for a tag you sent EMPTY as well as for one you omitted: the router reads a present-but-empty field as one you did not send, on every message.
• Router restarts. When the router stops for a rollout or a restart, every FIX session receives Logout(35=5) with Text(58) router restart before the TCP connection is closed (best effort, a session whose outbound queue is full is closed at the same bounded deadline). Nothing is dropped for cause: reconnect with backoff, Logon again with 141=Y, and recover as after any other disconnect (section 6). Neither the session nor anything queued for it survives a restart.
• Disconnected by our operations. Our operations desk can end a session from the partner's page; the session receives Logout disconnected by operations and is closed. The reason stays in our audit record and is never on the wire; ask your account manager.
• Logout texts, the complete list (key your runbooks on them): logon required, logon timeout, the five Logon shape sentences (EncryptMethod(98) must be 0: transport TLS only, ResetSeqNumFlag(141)=Y is required on every logon, HeartBtInt(108) must be 5..120 seconds, TargetCompID(56) must be BARRIERS, MsgSeqNum must be 1 on a 141=Y logon), the credential sentences of the table above, heartbeat timeout, slow consumer (the outbound queue of 4096 frames refused a report or a session message because you stopped reading), session replaced, session ceiling reached for this partner, malformed message: <reason>, the MsgSeqNum gap sentence, logout acknowledged (your own Logout confirmed, then the close), router restart, disconnected by operations.
• Your Logout(35=5) is confirmed with Logout logout acknowledged and the socket is closed after the flush. A peer Reject(35=3) is read and ignored.
• GET /partner/v1/me carries fix {enabled, port, sessions: [{keyPrefix, connectedAt, lastInboundAt}]}: whether the gateway is served on the host you reached, its port, and your live sessions (docs/11 section 8). enabled means our acceptor is LISTENING on that host: it reads false, with port null, while the acceptor is not listening (a start failure our operations are retrying), so a refused connection beside enabled: false is ours to fix, not yours. Use it to confirm a deployment from your side.

Example Logon and reply (| stands for SOH; the key is an example of the real shape, pbk_ plus 43 URL-safe base64 characters, the first ten of which are the prefix sent in 553):

8=FIX.4.4|9=145|35=A|49=SWISSBORG|56=BARRIERS|34=1|52=20260908-09:00:00.000|98=0|108=30|141=Y|553=pbk_1f9c2d|554=pbk_1f9c2dQ7xL0mW3vR8kT2nY5bH9pC4sJ6aF1dG8eK0zM|10=110|
8=FIX.4.4|9=85|35=A|49=BARRIERS|56=SWISSBORG|34=1|52=20260908-09:00:00.010|98=0|108=30|141=Y|9120=N|10=154|

A refused Logon (a key of another partner, an address off the allowlist, an unknown key: one answer):

8=FIX.4.4|9=85|35=5|49=BARRIERS|56=CLIENT|34=1|52=20260908-09:00:00.010|58=Sign in again.|9110=4010|10=059|

2. Client attribution

Every business message (35=D, 35=F, 35=H, 35=R, 35=AJ, 35=Z) names the end client it acts for with the standard Parties component. A partner never trades for itself; every order and request is a client's.

The resolver is the REST routes' (GET /partner/v1/clients/{clientId} for the uid, GET /partner/v1/clients/by-ref/{ref} for the reference; both refuse a client of another partner as if it did not exist): a 448 that is one of our client uids exactly as we issued it resolves by uid, any other value resolves as your reference. Our client uid is opaque (docs/11 section 7, revision 25): store it as we return it and send it back exactly as issued, letter case and digits as served; no digit count or other format is promised, and it may change for clients created later. Another spelling of a uid (BARR-412, barr-00000412) is therefore read as a reference, and since no partnerClientRef starts with BARR- in any letter case, it is refused as an unknown client (the last row below). Our numeric clientId, which the REST routes accept, is NOT read as our id on FIX, because a partner reference may itself be numeric and one field cannot carry both readings: a bare number in 448 is read as your own partnerClientRef, so it acts for the client you onboarded under that reference when you hold one, and it is refused (the last row below) only when no client of yours carries that reference.

Refusals are a BusinessMessageReject(35=j) with RefSeqNum(45), RefMsgType(372) = the message type, BusinessRejectRefID(379) = the message's own reference when it carried one (ClOrdID(11) on 35=D, OrigClOrdID(41) else OrderID(37) on 35=F and 35=H, QuoteReqID(131) on 35=R and 35=Z, QuoteRespID(693) on 35=AJ), and Text(58):

A 35=j is a verdict on the MESSAGE: no order, request or cancel is built, nothing reaches the router's functions, no report follows, the session stays up. The resolver runs BEFORE the message's own required-tag checks on purpose: a partner sending orders for a client it does not hold hears that first, whatever else is wrong with the message. The Parties component rides on every report: a report the gateway builds in answer to your message (a refusal before the venue, a restatement, a replay, the creation report of a request) echoes the three tags with the value you sent; a report built at a hook site (the acknowledgement, the fills, the cancel, the quotes, the accept, the contract reports) carries 448 = the client's partnerClientRef when set, else our uid, on every session that receives it, because the hook site does not see the message that placed the order (4.1 and section 5). A partner that sends its own reference sees one value throughout; a partner that sends our uid for a client with a reference on file reads the reference on the hook-built reports.

Because the reference rides on the wire as PartyID(448), a partnerClientRef is printable ASCII (0x20 to 0x7E, the FIX String domain): POST /partner/v1/clients refuses any other character with the field sentence partnerClientRef must use printable ASCII characters only (0x20 to 0x7E): it is carried on FIX as PartyID(448). (docs/11 section 9). For the same reason a partnerClientRef never starts with BARR-, our own client uid namespace: a 448 that is one of our uids resolves by uid, so a reference in that namespace could name another of your clients on every message, and the hook-built reports would print a 448 we read as the wrong client. The same prefix also begins references of ours that are NOT client identifiers: our order reference BARR-{orderId} (the order id unpadded, BARR-4185, the venue reference of 3.2 and the OrderID(37) form BARR-4185 of 3.5 and 3.7), our barrier request reference BARR-RFQ-{rfqId} and our staking swap reference BARR-SWP-{swapId}; never send one in 448: it is not a client identifier. POST /partner/v1/clients refuses such a reference, the prefix reserved case-insensitively, with the field sentence partnerClientRef must not start with BARR-: that prefix is our own client uid namespace and PartyID(448) on FIX reads such a value as our uid. (the "never starting with BARR-" rule of 3.1 and 7.1, which now covers the client reference too).

8=FIX.4.4|9=151|35=D|49=SWISSBORG|56=BARRIERS|34=2|52=20260908-09:00:00.200|11=ord-1001|453=1|448=cust-001|447=D|452=3|55=BTC-USD-PERP|54=1|38=0.01|40=2|44=60000|59=1|10=029|
8=FIX.4.4|9=119|35=j|49=BARRIERS|56=SWISSBORG|34=2|52=20260908-09:00:00.200|45=2|372=D|379=ord-1001|380=1|58=Unknown client.|9110=4004|10=164|

3. Order entry (35=D, 35=F, 35=G, 35=H)

Order entry over FIX goes through exactly the router function the REST route POST /partner/v1/clients/{clientId}/orders calls: every pre-trade check of docs/11 section 12.3 (the offered market and its family, the verification gate, restrictions and halts, the market controls, the lifecycle state, the shape of the order, the price and lot grid, the margin admission) runs unchanged and answers the SAME sentence, with the REST code in tag 9110. The order is attributed on your partner log stream and the client's with the words over FIX, and its record on GET .../orders and GET .../orders/open reads channel: "FIX", channelKeyId (the key of the session that placed it) and channelRef (your ClOrdID(11)).

"Named on absence" below means the tag is refused BY NAME with a session-level Reject(35=3) 373=1 371=<tag> 372=D when absent or empty, before an order is built (section 8.1): a field whose absence changes what the request MEANS is never guessed. "Default on absence" means absence selects the documented default. A PRESENT but invalid value keeps its business reject (3.4).

3.1 NewOrderSingle (35=D)

The five named-on-absence tags are checked in the order 11, 55, 54, 38, 40, after the client resolver of section 2, so the tag you hear about first is stable. Nothing else is required: a LIMIT GTC needs 11, the Parties component, 55, 54, 38, 40=2 and 44.

Not carried over FIX: attached take-profit and stop-loss legs, OCO groups, the leverage hint and a note (place brackets over REST; section 9).

3.2 What happens to an accepted order

The router places the order at the venue under its own reference (BARR-<orderId>) and reports to your session through the hook sites of section 4:

• The venue acknowledged: 35=8 150=0 39=0 from the same site that produces the order.accepted webhook, with our OrderID(37), your ClOrdID(11), LeavesQty(151) = the quantity, 9113=ACKED (or PENDING_TRIGGER for a conditional order the venue holds). When the venue's stream folded a fill or a cancel BEFORE its acknowledgement reached us (a marketable order, an IOC), the 150=F or 150=4 arrives first and the late 150=0 restates the record truthfully: 39 is then 1, 2, 4 or 6, 14 the filled quantity, 151 what is left and 9113 the state; a 150=0 never regresses an order to New (4.2).
• The venue refused: 35=8 150=8 39=8 with our OrderID(37) (the row exists, state REJECTED), the sentence in Text(58), 9110=4000 and the venue's own code in 9114 VenueRejectCode, from the order.rejected site.
• The acknowledgement was lost in transit (the venue may or may not have the order), or our side could not record it (revision 11: a failure of ours after the venue call), or the venue answered that it could not confirm the order (revision 13: its code 5000, or a 5xx without a venue code from a proxy between us and the venue; the order may still take effect there): NOTHING is answered on the session. Our reconciliation resolves the row against the venue within Recon:IntervalSeconds (300 by default) and the 150=0 or 150=8 then arrives from the same sites; a 35=H meanwhile reads 39=A 9113=SENT. Never re-enter the order under a new reference before that: read GET .../orders/open.

The session itself builds only the refusal of 3.4 (nothing was written), the restatement of a replay (3.3) and the answers of a 35=H (3.7).

3.3 ClOrdID(11): unique per client for 24 hours

The reference has the Idempotency-Key semantics of docs/11 section 5, on the same store: the reference is CLAIMED before the order is built and the outcome is kept for 24 hours under the client it named.

• First use: the order is placed and its reports follow (3.2).
• Reused with an IDENTICAL payload (the same 55, 54, 38, 40, 44, 59, 18, 99, 9101, 9102, 9103, 9104 and the same client): nothing is placed; the ORIGINAL order is restated as 35=8 150=I with 9117 Duplicate=Y, its real OrderID(37), 9110=4092 and its state at that moment (a terminal one when it has since ended: a restatement, never a lifecycle event). When the first use was a refusal before the venue (no order exists), the same 150=8 is answered again with 9117=Y.
• Reused with a DIFFERENT payload: 35=8 150=8 39=8 103=6 (duplicate order) Text(58) ClOrdID reused with a different payload 9110=4092, nothing placed.
• Reused while the first use is still in flight (a second session of yours sending the same order): the second waits up to 5 seconds for the stored outcome and answers as above; past that it answers 35=8 150=8 39=8 103=6 Text(58) A request with this ClOrdID is still in progress. 9110=4092, nothing placed. Read the state back before retrying.

The reference is held for 24 hours and never released early: run one reference per order attempt and never reuse a refused one for a corrected order. Only a failure of ours BEFORE the venue call gives the reference back (the session answers 35=j 380=4, 8.3; nothing reached the venue). Once the order reached the venue the reference is kept whatever fails on our side afterwards (revision 11, docs/11 revision 19): the order stands as sent, nothing is answered on the session (3.2) and a reuse with the IDENTICAL payload restates it as 150=I 9117=Y; it never places a second order. OrigClOrdID(41) on a 35=F or 35=H resolves through the same store when it holds the outcome of the reference, and through the order record itself (the newest order of that client placed over FIX under the reference) whenever the store has no completed outcome for it: once the store has forgotten the reference (after the 24 hours), and while the reference's first use is still in flight. That last arm matters to a partner running more than one session: the 150=0 of an order leaves before the store records the outcome, so a 35=F or 35=H naming the order by OrigClOrdID(41) from ANY session of yours (a risk desk cancelling on the first 150=0 of its drop copy) resolves it as soon as its acknowledgement has been reported, the reference in flight or not. A reference whose first use has not produced an order yet (before our record exists, or refused before the venue) answers as unknown: 102=1 on a 35=F, 103=5 on a 35=H, 9110=4004. A resting GTC order therefore stays cancellable and readable by your own reference for its whole life, and a partner that never reads our order ids can run an entire lifecycle on its own references. After the 24 hours a reference may be reused for a NEW order (the store no longer holds it): 41 then names the newest one, and never the earlier order while the new one is still being placed.

A reference is stored as sent and never trimmed, and one that begins or ends with whitespace never reaches the store: a ClOrdID(11) of that shape is refused at the door of 3.1, and an OrigClOrdID(41) of that shape is refused at the door BEFORE it is resolved, 35=9 102=99 9110=4000 on a 35=F and 35=j 380=0 9110=4000 on a 35=H, both with Text(58) OrigClOrdID(41) begins or ends with whitespace and is refused (revision 9). A padded twin of a live reference of yours (ABC beside ABC) therefore places nothing, replays nothing and cancels nothing: it is refused, not read as the reference without the blank.

3.4 Refusals of a 35=D before the venue: ExecutionReport 150=8

A refusal the router returns before anything is written answers a gateway-built 35=8 150=8 39=8 OrderID(37)=0 (nothing exists), your 11, a gateway ExecID(17), 55, 54, 38, 40 and 59 echoed (59=1 when you sent none), 9102 as applied, 151=0, 14=0, 6=0, the Parties component echoed, Text(58) = the router's sentence VERBATIM, 9110 = our code, 9113=REJECTED, 9121=FIX, 60, and OrdRejReason(103) classified as below. The reference is recorded (3.3).

103 is a coarse classification by sentence: key your handling on 9110 and Text(58), never on 103 alone (the venue's own guidance for its 103=99). A refusal by the VENUE is not gateway-built: it arrives from the hook site with the row's real OrderID(37) (3.2). Exactly one of the two shapes ever answers a given 35=D.

8=FIX.4.4|9=149|35=D|49=SWISSBORG|56=BARRIERS|34=3|52=20260908-09:00:00.300|11=ord-1002|453=1|448=cust-001|447=D|452=3|55=BTC-USD-PERP|54=1|38=0.00015|40=2|44=60000|10=223|
8=FIX.4.4|9=330|35=8|49=BARRIERS|56=SWISSBORG|34=3|52=20260908-09:00:01.000|37=0|11=ord-1002|17=rej-1788483600123-4|150=8|39=8|55=BTC-USD-PERP|54=1|151=0|14=0|6=0|453=1|448=cust-001|447=D|452=3|103=13|9110=4000|58=The quantity must be a multiple of the lot size 0.0001.|38=0.00015|40=2|59=1|9102=N|9113=REJECTED|9121=FIX|60=20260908-09:00:01.000|10=032|

3.5 OrderCancelRequest (35=F)

An accepted cancel answers NOTHING on the session: the venue confirms it and the 150=4 (or 150=C) arrives from the order.canceled site when the venue's frame lands; until then a 35=H reads 39=6 9113=PENDING_CANCEL. A cancel of an order already being cancelled is the same silence (its report is already on its way). The order need not have been placed on your session's key: a trading session may cancel any order of the client it names (one placed over REST, on another key of yours, or by our risk engine), and the key that asked for the cancel then receives the order's reports from the cancel on (the 150=4 or 150=C, or the fill that beat the cancel) beside the key that placed it and the drop copies, so a cancel never appears to hang (section 5). A refusal answers OrderCancelReject(35=9):

A 35=9 carries OrderID(37), ClOrdID(11) and OrigClOrdID(41) as FIX 4.4 requires: 37 is the order the request resolved to when the router knows it (a cancel by 41 alone), else what you sent; a reference you did not send, or sent EMPTY, is reported as the sentinel BARR-NONE for 11 and 41 and 0 for 37 (the BARR- namespace is refused on order entry, so the sentinel can never collide with a reference of yours). 39=8 and the Parties component ride on every 35=9. A 35=9 always means the request was REFUSED and the order is unchanged.

A cancel the venue answered that it could not confirm (revision 13: its code 5000, or a 5xx without a venue code) is NOT refused: the cancel may have taken effect. The session answers the reply policy's 35=j 380=4 9110=5030 (8.3), never a 35=9; the order is unchanged on our side and your session stays recorded as the cancelling key, so the 150=4 arrives from the hook site when the venue's frame lands. A cancel may be sent again at once (a 35=9 to it then means the order had already ended), or read the order back with a 35=H.

8=FIX.4.4|9=112|35=F|49=SWISSBORG|56=BARRIERS|34=4|52=20260908-09:00:00.400|11=cxl-1|41=ord-1001|453=1|448=cust-001|447=D|452=3|10=221|
                                       (nothing: the venue's frame produces the report below)
8=FIX.4.4|9=312|35=8|49=BARRIERS|56=SWISSBORG|34=5|52=20260908-09:00:00.500|37=4185|11=ord-1001|41=ord-1001|17=can-1788483600200-6|150=4|39=4|55=BTC-USD-PERP|54=1|38=0.01|40=2|44=60000|59=1|14=0|151=0|6=0|58=canceled|9102=N|9113=CANCELED|9115=order:4185:canceled|9121=FIX|60=20260908-09:00:00.500|453=1|448=cust-001|447=D|452=3|10=154|

3.6 OrderCancelReplaceRequest (35=G): not supported

No amend route exists on the Partner API; every OrderCancelReplaceRequest answers OrderCancelReject(35=9) with CxlRejResponseTo(434)=2, CxlRejReason(102)=99, OrdStatus(39)=8, Text(58) Cancel/Replace is not supported: cancel and re-enter., the sentinels of 3.5 for the references it carried, and nothing else happens. Cancel the order and enter a new one under a new ClOrdID(11).

8=FIX.4.4|9=133|35=G|49=SWISSBORG|56=BARRIERS|34=7|52=20260908-09:00:00.700|37=4185|11=new-ref|41=old-ref|55=BTC-USD-PERP|54=1|38=0.02|40=2|44=59000|10=009|
8=FIX.4.4|9=165|35=9|49=BARRIERS|56=SWISSBORG|34=7|52=20260908-09:00:00.700|37=4185|11=new-ref|41=old-ref|39=8|434=2|102=99|58=Cancel/Replace is not supported: cancel and re-enter.|10=075|

3.7 OrderStatusRequest (35=H)

OrigClOrdID(41) or OrderID(37) plus Parties, resolved as in 3.5 (a reference whose first use is in flight restates the row as soon as it exists; one that has not produced an order yet answers the unknown-order shape below); send Symbol(55) and Side(54) as FIX 4.4 requires (the unknown-order answer echoes them). The answer is ONE ExecutionReport(35=8) 150=I restating the order from its record: 37, 11 (your reference when the order was placed over FIX, absent otherwise), 41 echoed when you sent it, 39 per 4.2, 55, 54, 38, 40, 44, 99, 59, 14 = the filled quantity, 151 = the unfilled quantity on a live state and 0 on a terminal one, 6 = the average fill price, 9113 = the router's own state verbatim, 9121, the Parties component, 60, and, on a REJECTED order, 58 = the reject sentence. It is a STATUS report, never a lifecycle event (4.3). A 35=H is accepted on a drop-copy session and counts against your read_per_minute bucket.

An order the client does not hold answers 35=8 150=I 39=8 OrdRejReason(103)=5 (unknown order) 37=0 Text(58) This order was not found. 9110=4004, with 55 and 54 echoed when the request carried them and omitted otherwise (FIX 4.4's own convention for an unknown order on a status request), and without 38, 40, 59, 9102, 9113 and 9121 (no order exists to read them from: the one exception to the always-on set of 4.1, whose presence cells name it). A 35=H with neither 41 nor 37 is refused by name: Reject(35=3) 373=1 371=37 Text(58) OrderStatusRequest requires OrigClOrdID(41) or OrderID(37). An OrigClOrdID(41) that begins or ends with whitespace, or is whitespace only, is refused at the door before it is resolved, whether or not 37 is present: BusinessMessageReject(35=j) 380=0 379 = the value as sent 9110=4000 Text(58) OrigClOrdID(41) begins or ends with whitespace and is refused (revision 9), never the 150=I of the reference without the blank.

8=FIX.4.4|9=124|35=H|49=SWISSBORG|56=BARRIERS|34=8|52=20260908-09:00:00.800|41=ord-1001|55=BTC-USD-PERP|54=1|453=1|448=cust-001|447=D|452=3|10=123|
8=FIX.4.4|9=293|35=8|49=BARRIERS|56=SWISSBORG|34=9|52=20260908-09:00:00.900|37=4185|11=ord-1001|41=ord-1001|17=sta-1788483600300-7|150=I|39=1|55=BTC-USD-PERP|54=1|38=0.01|40=2|44=60000|59=1|14=0.004|151=0.006|6=60000.000000|9102=N|9113=PARTIAL|9121=FIX|60=20260908-09:00:00.900|453=1|448=cust-001|447=D|452=3|10=215|

4. ExecutionReports (35=8)

One report per state change of an order, built at the SAME hook sites as the order.* webhooks of docs/11 section 16.4 (the acknowledgement in the routing pipeline, the fills and the frames in the venue ingest, the resolutions of our reconciliation), so REST, the webhooks and FIX never disagree about an order. A report is built inside the router's transaction and queued to your session after the commit; a rolled-back fold never reaches you. 9115 SourceRef carries the webhook's own source_ref (order:4185:accepted, order:4185:fill:88002, order:4185:canceled, order:4185:rejected): a partner running both transports dedupes on it.

4.1 The tags

One row per tag, in the order the router's registry keeps them; the Presence column is the registry's own rule, generated from the code.

The tags the router commits to on EVERY 35=8 (the positive half of our tag-integrity pin): 37, 17, 150, 39, 55, 54, 38, 40, 59, 151, 14, 6, 60, 453, 448, 447, 452, 9102, 9113, 9121; the unknown-order status of 3.7 alone carries neither 38, 40, 59, 9102, 9113 nor 9121 (no order exists to read them from), and 55 and 54 on it are echoes. No tag is ever sent with an empty value: what is not known is omitted.

4.2 ExecType and OrdStatus per transition

Exactly one report with a terminal 39 and a 150 other than I ever closes a given order; a 150=I may carry a terminal 39 after it.

4.3 The 150=I rule

A restatement (a 35=H answer, a ClOrdID replay) is a STATUS report: it carries a gateway ExecID(17), no 9115, reports the order's state at the instant it is built, and never consumes the order's single terminal lifecycle report. Treat a 150=I as a snapshot to reconcile against, never as a transition to act on.

4.4 The dedupe keys

9115 SourceRef on every hook-built report is the same source_ref the webhook delivery carries, and 9111 TradeId on a fill is the same trade id fill.tradeId and GET .../trades carry. A partner running FIX beside the webhooks dedupes on those two; a partner running FIX alone still dedupes on 9115, because our emit is at-least-once per fact (section 6).

4.5 A lost acknowledgement

When the venue's answer to a placement is lost in transit, or the venue answered that it could not confirm it (revision 13), the session receives nothing (3.2). Our reconciliation resolves the row within Recon:IntervalSeconds (300 by default): the 150=0 or 150=8 then arrives from the same hook sites with the same 9115, before any fill of that order. A 35=H meanwhile reads 39=A 9113=SENT. Never re-enter the order under a new reference before the resolution: read GET .../orders/open.

8=FIX.4.4|9=288|35=8|49=BARRIERS|56=SWISSBORG|34=4|52=20260908-09:00:00.100|37=4185|11=ord-1001|17=acc-1788483600100-2|150=0|39=0|55=BTC-USD-PERP|54=1|38=0.01|40=2|44=60000|59=1|14=0|151=0.01|6=0|9102=N|9113=ACKED|9115=order:4185:accepted|9121=FIX|60=20260908-09:00:00.100|453=1|448=cust-001|447=D|452=3|10=150|
8=FIX.4.4|9=387|35=8|49=BARRIERS|56=SWISSBORG|34=5|52=20260908-09:00:05.100|37=4185|11=ord-1001|17=fil-1788483605100-3|150=F|39=1|55=BTC-USD-PERP|54=1|38=0.01|40=2|44=60000|59=1|32=0.004|31=60000|14=0.004|151=0.006|6=60000.000000|12=0.120000|13=3|15=USDC|9102=N|9111=88002|9112=0.000000|9113=PARTIAL|9115=order:4185:fill:88002|9116=TAKER|9121=FIX|60=20260908-09:00:05.100|453=1|448=cust-001|447=D|452=3|10=078|
8=FIX.4.4|9=382|35=8|49=BARRIERS|56=SWISSBORG|34=6|52=20260908-09:00:06.100|37=4185|11=ord-1001|17=fil-1788483606100-4|150=F|39=2|55=BTC-USD-PERP|54=1|38=0.01|40=2|44=60000|59=1|32=0.006|31=60100|14=0.010|151=0|6=60060.000000|12=0.180000|13=3|15=USDC|9102=N|9111=88003|9112=0.000000|9113=FILLED|9115=order:4185:fill:88003|9116=TAKER|9121=FIX|60=20260908-09:00:06.100|453=1|448=cust-001|447=D|452=3|10=060|

5. Drop copy

A drop-copy session is a session that receives every report of every client of the partner (REST-placed orders, orders of other FIX sessions, the orders your app placed by app order commands, the flattens of our risk engine, the quote and contract reports of every request and contract, section 7) and may not enter orders or requests. It is established at Logon with 9120=Y on a TRADE key of its own (one key, one session: section 1); the Logon reply echoes 9120=Y. On a drop-copy session a NewOrderSingle(35=D), OrderCancelRequest(35=F), OrderCancelReplaceRequest(35=G), QuoteRequest(35=R), QuoteResponse(35=AJ) or QuoteCancel(35=Z) is refused at the session level with Reject(35=3) SessionRejectReason(373)=99, RefMsgType(372) = the type and Text(58) drop-copy session: order entry is disabled, use a trading session; an OrderStatusRequest(35=H) is a read and is served. Run it with its own key so the trading and observing entitlements are separable; a drop-copy session shares the partner's rate limits.

The routing of a report is keyed on the KEY of the session:

• A TRADING session receives the reports of the orders whose channelKeyId is its key: what was placed ON that key, including after a reconnect or a replacement under the same key (section 1). An order placed before a disconnect therefore reports to the session that reconnects with the same key.
• A DROP-COPY session receives the reports of EVERY order of EVERY client of the partner: REST-placed orders, orders of your other FIX sessions, the orders of your app order commands, the flattens of our risk engine; never anything of another partner.
• An order placed by an app order command (revision 12, docs/11 section 22) has no session key, so its reports go to the drop-copy sessions only (and, from a cancel on, to a trading session whose key cancelled it, the rule below), with 9121=APP and without ClOrdID(11) or a derived OrigClOrdID(41): its channelRef is the token's jti, our record of the command, never a reference of yours. A 35=H naming it by OrderID(37) is served; it has no 41 to name it by.
• 9121 Origin marks every report: FIX (placed on a FIX session of yours), REST (placed over the Partner API), APP (placed by an app order command), CLOSE_OUT (an order of our risk engine: a flatten of a perpetual position, or the forced sale of a client's spot holdings after a close-out left its cash negative, a SELL MARKET IOC on the spot market in the client's name, docs/13 section 8; it runs for a client only once that client has accepted the Terms version carrying the right-of-sale clause, docs/11 section 12.3).
• A trading session whose key CANCELLED an order it did not place (a 35=F on a REST-placed order, on another key's order or on a flatten of our risk engine) receives that order's reports from the cancel on, beside the key that placed it: the 150=4 or 150=C, or a 150=F for a fill that beat the cancel, so the outcome of every cancel reaches the session that asked for it (3.5). The cancel of another key's order by its OrigClOrdID(41) works from the acknowledgement on: a risk desk that cancels on the first 150=0 of its drop copy is honoured even while the placing session's reference is still being recorded (3.3). A cancel over REST changes nothing here.
• A trading session that is neither the owner of the order, nor the key that cancelled it, nor a drop copy receives nothing for it.
• On a hook-built report PartyID(448) is the client's partnerClientRef when set, else our uid, on every session that receives it: the hook site does not see the message that placed the order, so the trading session is not echoed the exact value it sent (a gateway-built report is).

A partner wanting one feed of everything runs a drop-copy session on a second key beside its trading sessions; a risk desk that only observes runs the drop-copy key alone.

6. Delivery semantics and loss

• Reports are delivered in memory, per session, in the order the router committed the state changes; the reports of one order never overtake each other. A Heartbeat answering your TestRequest may take a MsgSeqNum between two reports (it is sent from the read loop). Nothing is persisted for FIX: no resend store, no replay. Your session receives reports from the Logon reply on: the 35=A is always the first frame of the session, with MsgSeqNum(34)=1, and a report built while your Logon is still being answered (our sessions register is being written) is lost for that session like one built with no live session.
• A report built while your key has no live session is lost for FIX. After any disconnect (a network fault, a restart, a replacement, a slow-consumer close) reconcile through GET /partner/v1/clients/{clientId}/orders/open, GET .../orders, GET .../rfq and GET .../barriers, and through the webhooks, which keep every event with retries; a 35=H per open order after the reconnect is the FIX-only way to the same facts (its 150=I folds the fills you missed into 14 and 6).
• A session whose outbound queue (4096 frames) refuses a report or a session message because you stopped reading is a slow consumer: Logout slow consumer and the close. Reports are never dropped to save a laggard; there is no best-effort class on this gateway.
• Reports and webhooks may arrive in either order relative to each other; both carry the same source_ref (9115 on FIX) and the same trade id, so a partner running both dedupes on those.
• The router's emit is at-least-once per fact. The gateway remembers, per partner, the last 10,000 (session, message type, source_ref) deliveries and skips a repeat within that window (the message type is part of the key, so the 35=AI and the 35=8 of one accepted request, which share one source_ref, both pass); after a router restart the memory is empty, so a fact re-emitted by our reconciliation can reach a session once more. Dedupe on 9115.

7. RFQ over FIX

The barrier lifecycle of docs/11 section 12.2 in FIX terms, on exactly the same router functions, gates and sentences as POST .../rfq, POST .../rfq/{rfqId}/accept, POST .../rfq/{rfqId}/cancel and POST .../barriers/{contractId}/close: whatever FIX answers about a request, REST and the rfq.* / barrier.closed webhooks answer about the same fact. Barrier markets are RFQ only: a 35=D on a KO symbol answers 150=8 with Barrier contracts are traded by request for quote, not by order: request quotes on the Barriers page (/barriers), or through POST /v1/rfq. (103=1), and a 35=R on a PERP or SPOT symbol answers 35=AI 297=5 Requests for quote are available on barrier markets only..

The messages:

The gateway itself builds only the creation-time 35=AI (297=16, or 297=10 when the venue could not be reached or, since revision 13, answered that it could not confirm the request, or 297=5 when the request was refused before a row existed), the replays of a reused reference and the refusals of an accept or a cancel (35=j 380=0). Every state change of a request and every contract report comes from the SAME hook sites as the rfq.quote, rfq.accepted, rfq.expired, rfq.canceled, rfq.rejected and barrier.closed webhooks (7.8), with the event's source_ref in 9115. A request made over FIX reads channel: "FIX", channelKeyId and channelRef (= your QuoteReqID(131)) on the records of docs/11 12.2.

7.1 QuoteRequest (35=R): an opening request, or an early close

The named-on-absence tags are checked in the order 131, then, on an opening request, 55, 54, 38, 9130, after the client resolver of section 2. Everything else of POST .../rfq applies unchanged and answers 297=5 with its own sentence and code (9110): the offered-market gate (This market is not offered., 4004), the tick and lot grids, the market's minimum quantity and its minimum request value at the current mark (revision 8, docs/11 revision 12, the venue's ADR-25: The request value is below the minimum for this market (100.00 USD). with 9110=4000, refused before a row like the grids, so no 9140 and no rfq.rejected webhook; a request the venue still refused for its minimum after the row keeps 297=5 with the same sentence, 9140 and 9160=REJECTED, and a close request the venue refused for it reads This contract is worth less than the market minimum (100.00 USD) at the current mark; it ends at its barrier, its take profit or its expiry.), the barrier floor, the verification gate (4030 with 9118), the TERMS re-consent gate (4035 with the sentence, no 9118; revision 6, an opening request only, never a close request), the partner close-only state of the settlement tier (4041 with the sentence, no 9118; revision 6, docs/11 15.7, an opening request only, never a close request), the key information document gate and the strict consent gate (revision 6 grown in place, docs/11 section 4 and 12.2: both 4035 with their sentence in Text(58) and no 9118; the KID gate on a RETAIL client's opening request without the acknowledged current document of the market and variant, refused while none is published, never on a close request; the strict consent gate on a strict take profit request while the current Risk Disclosure version is not accepted; the acknowledgement is recorded over REST, POST .../consents, and the next request passes), the account state, the restrictions and halts, the disabled market, the free-margin check. The request row carries channel FIX, the key of your session and your 131; the rate limit of section 1 (the shared trade_per_minute bucket) answers 297=5 Too many requests. Please slow down and try again. 9110=4290.

7.1.1 QuoteReqID(131) reuse, the Idempotency-Key semantics of docs/11 section 5 on the same store: the reference is CLAIMED before the request is built and the outcome kept for 24 hours under the client it named. Reused with an IDENTICAL payload (the same 55, 54, 38, 9130 to 9136, 9155 and the same client): nothing is created; the request's CURRENT state is restated as 35=AI with 9117 Duplicate=Y, 9140 RfqId and 9110=4092 (the original refusal again when the first use was refused before a row). Reused with a DIFFERENT payload: 35=AI 297=5 QuoteReqID reused with a different payload 9110=4092, nothing created. Reused while the first use is still in flight (a second session of yours): the second waits up to 5 seconds for the stored outcome and answers as above; past that it answers 297=5 A request with this QuoteReqID is still in progress. 9110=4092. Read the state back before retrying. Once the request reached the venue the reference is kept whatever fails on our side afterwards (revision 11, docs/11 revision 19): the request is answered with its creation report from the row (297=10 with 9110=5020 while the row carries no venue id yet, else 297=16) and a reuse restates it; it never opens a second request at the venue.

7.2 QuoteStatusReport (35=AI): the request's state, every time it changes

The tags the router commits to on EVERY 35=AI: 297, 60, 453, 448, 447, 452, 9121. A 35=AI carries no ExecID(17). The creation-time report is gateway-built after the request was created and carries everything the record of docs/11 12.2 carries that has a tag above; the state-change reports (297=0, 7, 17, 5 after a row) come from the hook sites with 9115. The creation report is 297=16 (or 297=10) by construction and is sent only while the request is still OPEN when the gateway reads it back: a request that the automatic accept (or the venue) moved before that read gets NO creation report, the hook-built 297=0 (7, 17, 5) alone. In the rare race where the read-back precedes the move and the send follows the hook's report, a creation 297=16 can reach you AFTER a 297=0 of the same request: a 35=AI WITHOUT 9115 is the creation acknowledgement, never a state change, and never supersedes one WITH 9115; key your request state on the reports that carry 9115.

8=FIX.4.4|9=180|35=R|49=SWISSBORG|56=BARRIERS|34=7|52=20260908-09:00:00.700|131=rfq-2001|453=1|448=cust-001|447=D|452=3|146=1|55=BTC-USD-KO|54=1|38=1.0|9130=63000.0|9131=66500.0|9134=N|9136=60000|10=144|
8=FIX.4.4|9=360|35=AI|49=BARRIERS|56=SWISSBORG|34=8|52=20260908-09:00:00.800|131=rfq-2001|297=16|9140=311|9161=5207|9160=OPEN|55=BTC-USD-KO|54=1|38=1.0|9130=63000.0|9131=66500.0|9132=N|9144=1819843200000|9149=Y|9134=N|62=20260908-09:01:00.000|9152=2222.130000|9143=9000|9146=26.51|9147=1031.000000|9139=65469.0|9121=FIX|60=20260908-09:00:00.800|453=1|448=cust-001|447=D|452=3|10=107|

7.3 Quote (35=S): one per live quote id

From the rfq.quote hook site, once per quote id: a quote the writer refreshes under the same id fires no second 35=S (the webhook's own rule); the accept is by quote id at the venue's current price for that id, bounded by our acceptability rules at accept.

The tags on every 35=S: 117, 55, 54, 38, 62, 9140, 9142, 9134, 9115, 9121, 60, the Parties component. A 35=S carries no ExecID(17). The webhook's pending cap does not apply to FIX; a session that cannot keep up with quotes is a slow consumer (section 6). On the development environment a market maker connected to the venue quotes every request within seconds: a session with several open requests receives a burst of 35=S.

8=FIX.4.4|9=310|35=S|49=BARRIERS|56=SWISSBORG|34=9|52=20260908-09:00:00.900|117=902|131=rfq-2001|9140=311|55=BTC-USD-KO|54=1|38=1.0|133=65471.5|62=20260908-09:00:31.000|9141=2224.350000|9143=9000|9142=Y|9146=26.49|9147=1028.500000|9134=N|9115=rfq:311:quote:902|9121=FIX|60=20260908-09:00:00.900|453=1|448=cust-001|447=D|452=3|10=168|

7.4 QuoteResponse (35=AJ): accept a quote

The accept runs the SAME function as POST .../rfq/{rfqId}/accept, with every check: the request open, the quote live and acceptable at a mark read now, the margin admission. On success the gateway sends NOTHING itself: the rfq.accepted hook site delivers the 35=AI 297=0 and the contract-open 35=8 of 7.6 (on a close request: the settlement 35=8 of 7.7, then the 297=0 and the early-close trade). A refusal answers BusinessMessageReject(35=j) 380=0 379=693 Text(58) = the sentence: This request was not found. (9110=4004, also for a 131 the store does not know and for another client's request), This request is no longer open., An acceptance is already in progress for this request., This quote is not available any more. (4004), the TERMS re-consent gate's sentence on the accept of an OPENING request (9110=4035, revision 6; the accept of a close request is never gated), the partner close-only sentence on the accept of an OPENING request (9110=4041, revision 6, docs/11 15.7; a close accept never), the acceptability sentences of 7.3, the margin sentence, the venue's refusal with 9114, The trading venue cannot be reached right now. Please try again shortly. with 9110=5020 and 9163 Accepting=Y (the accept is in flight at the venue: our poll resolves it, read the state back; since revision 13 also when the venue answered that it could not confirm the accept), 9110=4000 otherwise; the request is unchanged. A refused accept is a 35=j and never a 35=AI: the request did not change state.

QuoteRespID(693) reuse: identical (the same 117 and request) after a success replays the contract-open 35=8 with 9117=Y and a dup- ExecID; identical after a refusal replays the same 35=j with 9117=Y; a different payload answers 35=j 380=0 QuoteRespID reused with a different payload 9110=4092; in flight, A request with this QuoteRespID is still in progress. 9110=4092 after the wait.

8=FIX.4.4|9=133|35=AJ|49=SWISSBORG|56=BARRIERS|34=10|52=20260908-09:00:01.000|693=acc-2001|694=1|117=902|131=rfq-2001|453=1|448=cust-001|447=D|452=3|10=186|
8=FIX.4.4|9=418|35=AI|49=BARRIERS|56=SWISSBORG|34=10|52=20260908-09:00:28.000|131=rfq-2001|297=0|9140=311|9161=5207|9160=ACCEPTED|55=BTC-USD-KO|54=1|38=1.0|9130=63000.0|9131=66500.0|9132=N|9144=1819843200000|9149=Y|9134=N|62=20260908-09:01:00.000|9152=2224.350000|9143=9000|9146=26.49|9147=1028.500000|9139=65469.0|9150=4711|9151=65471.5|9162=902|9115=rfq:311:accepted|9121=FIX|60=20260908-09:00:28.000|453=1|448=cust-001|447=D|452=3|10=026|

7.5 QuoteCancel (35=Z): withdraw the request

The cancel runs POST .../rfq/{rfqId}/cancel. On success the gateway sends nothing itself: the rfq.canceled hook site delivers 35=AI 297=17; a request the venue had already expired reads 297=7 from the same site. A refusal answers 35=j 380=0 with the sentence (This request was not found. 4004, This request is no longer open., An acceptance is already in progress for this request., the venue's refusal with 9114, the venue unreachable with 5020). Since revision 13 a cancel the venue answered that it could not confirm (its code 5000, or a 5xx without a venue code) is never refused: it answers the transport answer, 35=j 380=0 9110=5020 without 9114, with The trading venue could not confirm whether the cancel took effect. Please check whether it is still open and cancel it again if it is.; the request is unchanged until our poll sees the venue's state, which the hook site then reports (297=17 when the cancel took effect).

7.6 The contract open, and the early-close trade: 35=8 on the KO symbol

From the rfq.accepted hook site, one report per accepted request: the contract open on an opening request, the closing TRADE on a close request (the settlement of the contract is 7.7's report). The table below is the one registry of the three contract reports (the open, the early-close trade and the end of 7.7), one row per tag in the code's order; the Presence column says on which of them the tag rides.

On a CLOSE request's acceptance the same shape reports the closing trade: 54 the closing side, 31 / 6 / 9151 the close price, 9155 CloseContractId = the contract, 9154 the contract's direction, 9111 the close trade id, 9140 the close request, 9161 the close request's venue id and 9162 the accepted close quote, 12 our early-close commission (since revision 6 grown in place, BROKER-14: the client's BARRIER scheme on the premium at the accepted close price; 0 before), no 9152, no 9153, no terms. It is the trade confirmation; the settlement is 7.7.

8=FIX.4.4|9=459|35=8|49=BARRIERS|56=SWISSBORG|34=11|52=20260908-09:00:28.000|37=0|11=rfq-2001|17=rfq-1788483628000-5|150=F|39=2|55=BTC-USD-KO|54=1|38=1.0|32=1.0|31=65471.5|14=1.0|151=0|6=65471.5|12=22.243500|13=3|15=USDC|9111=771310|9140=311|9161=5207|9162=902|9150=4711|9151=65471.5|9152=2224.350000|9153=22.243500|9154=LONG|9130=63000.0|9131=66500.0|9132=N|9144=1819843200000|9143=9000|9115=rfq:311:accepted|9121=FIX|60=20260908-09:00:28.000|453=1|448=cust-001|447=D|452=3|10=134|

7.7 The contract end, any reason: 35=8 on the KO symbol

From the barrier.closed hook site, one report per contract, whatever ended it: the knock-out, the take profit, the expiry, an early close, a tear-up. Its tags are the rows of the table in 7.6 whose Presence says "on the end" or "always": OrderID(37) 0, ClOrdID(11) = the OPENING request's QuoteReqID(131) when it was made over FIX, a bar- ExecID, 150=F 39=2, the KO symbol, Side(54) = the CLOSING side (a LONG closes with 2, a SHORT with 1), the quantity in 38 / 32 / 14 with 151=0, the settlement price in 31 / 6 / 9157 SettlePrice (all three ABSENT when the close has none, a tear-up reported without a price; 9156 still says why; omitted rather than 0, which would read as a price), 9150 ContractId and 9140 RfqId (the opening request, when one exists), 9154 Direction, 9156 CloseReason (knockOut, takeProfit, expiry, earlyClose, tearUp, other, the webhook's reason), 9164 VenueCloseReason when the record's own word differs (liquidation, finalSettlement, reconciler:ledger), 9158 Pnl (the realised P&L in USDC, signed), 9152 Premium and 9153 Commission (the contract's premium and opening commission), 9159 ClosedAt (Unix ms), the terms 9151 Entry, 9130 BarrierLevel and 9131 TakeProfit (with one), 9111 TradeId = the close trade id when known (absent when the venue's close frame settled the contract first, docs/11 16.4), 9155 CloseContractId on an early close (so the two 35=8 of an early close correlate), 9115 SourceRef = barrier:4711:closed, 9121 Origin = the opening request's channel, the Parties component and TransactTime(60) = the close time.

The tags on every contract 35=8 (7.6 and 7.7): 37, 17, 150, 39, 55, 54, 38, 32, 14, 151, 60, the Parties component, 9150, 9154, 9115, 9121.

Routing (section 5 applied to contracts): the contract-end report reaches the key that OPENED the contract (the opening request's key), the key that requested the early close when that is another key of yours, and every drop-copy session; a contract opened over REST reports to drop-copy sessions only. On an early close accepted over FIX the settlement is booked BEFORE the request is marked accepted, so the 35=8 of 7.7 arrives first, then the 297=0, then the early-close trade of 7.6: correlate the three by 9155 and 9150, never by order.

8=FIX.4.4|9=433|35=8|49=BARRIERS|56=SWISSBORG|34=12|52=20260908-11:00:00.000|37=0|11=rfq-2001|17=bar-1788490800000-6|150=F|39=2|55=BTC-USD-KO|54=2|38=1.0|32=1.0|31=63000.0|14=1.0|151=0|6=63000.0|9140=311|9150=4711|9154=LONG|9156=knockOut|9157=63000.0|9158=-2224.350000|9152=2224.350000|9153=22.243500|9159=1788490800000|9151=65471.5|9130=63000.0|9131=66500.0|9115=barrier:4711:closed|9121=FIX|60=20260908-11:00:00.000|453=1|448=cust-001|447=D|452=3|10=110|

7.8 The hook sites

rfq.quote to 35=S; rfq.accepted to 35=AI 297=0 plus the 35=8 of 7.6; rfq.expired, rfq.canceled, rfq.rejected to 35=AI 297 7 / 17 / 5; barrier.closed to the 35=8 of 7.7. Every one of them is built inside the router's transaction and released after the commit (section 6). The gateway itself builds only the creation-time 35=AI, the replays and the refusals of 7.1.1, 7.4 and 7.5. Nothing about the barrier module's own behaviour changes: the automatic accept runs as it does for REST and its accept reaches FIX through the same rfq.accepted site.

7.9 The QuoteStatus(297) values chosen

Of FIX 4.4's enumeration the router uses six: 16 Active, 0 Accepted, 7 Expired, 17 Canceled, 5 Rejected, 10 Pending; every other value never appears. 9160 RfqState carries the router's own state beside it so nothing is lost in the mapping (CANCELLED is spelled with two Ls on the REST wire and rides verbatim).

8. Rejects and the reply policy

8.1 The doctrine

Three clauses, the venue's, kept word for word:

1. A required tag ABSENT or EMPTY is refused BY NAME at the session layer: Reject(35=3) with SessionRejectReason(373)=1, RefTagID(371) = the tag, RefMsgType(372) = the type, RefSeqNum(45) and a Text(58) naming it, decided before anything is built, so nothing reaches the router's functions and no report follows.
2. A required tag PRESENT with an invalid value keeps its BUSINESS reject with the router's sentence verbatim and our code in 9110.
3. Nothing narrows: an absent optional field takes its documented default, a field you DID send is never quietly replaced.

The one exception: Side(54) outside the FIX 4.4 enumeration (1 to 9, A to G) answers 35=3 373=5, because an echoed 54 would make the router's own ExecutionReport invalid FIX.

8.2 Which reject answers what

Every reject carries RefSeqNum(45) (35=3, 35=j) or the message's own references (35=8, 35=9, 35=AI) so you correlate it; a 35=3 carries no 11 and no 17: correlate it by 45.

8.3 The reply policy

• When the router's function did not answer normally because it THREW (a database failure, a transport failure mid-request) after it may have written, the session answers 35=j 380=4 (application not available) with 379 = the message's reference, Text(58) The request could not be completed; read the state back before retrying. and 9110=5030, and NEVER a 35=8 150=8 or a 35=9: the order or the cancel may exist, and its truthful report comes from the hook sites when our reconciliation resolves it. Read GET .../orders/open before retrying after a 380=4, the same advice the REST guide gives after a 502. The session stays up. Since revision 11 this answers a throw BEFORE the venue call alone: once a 35=D or a 35=R reached the venue, a throw of ours is answered as its pending outcome (the next bullet for an order, the creation report for a request, 7.1.1) and its reference is never given back (3.3). Since revision 13 the same 35=j answers a 35=F the venue could not confirm (its code 5000, or a 5xx without a venue code, which our venue client raises as a transport failure): the cancel may exist (3.5).
• A request the venue received but whose acknowledgement was lost, or not recorded on our side (revision 11), or that the venue answered it could not confirm (revision 13: its code 5000), answers NOTHING on the session; its report arrives when our reconciliation resolves the order (within Recon:IntervalSeconds, 300 by default; 3.2 and 4.5).

9. What FIX does NOT carry

Margin state and the risk-state transitions (poll GET .../margin or take the margin.* webhooks), collateral and settlement (/collateral, /settlement/*, the collateral.* and settlement.* webhooks), onboarding and KYC, MiFID appropriateness (the questionnaire, its announced versions and the served languages of docs/11 revision 17 included: FIX carries neither appropriateness_test.version_changed nor appropriateness_test.text_changed, and no sink for them is offered on this gateway), categorisation, statements, market data (GET /partner/v1/ticker, /orderbook, /market-trades, /klines, /instruments, /market-info; a 35=V answers 35=j 380=3), staking swaps (POST .../staking/{offerId}/accept and its reads), attach and OCO legs and the leverage hint (place brackets over REST), and cancel-on-disconnect (the router cancels nothing on a partner's disconnect; your own risk controls and our close-out engine stand) remain on the Partner API and the webhooks. There is no resend store and no amend. The app order commands of docs/11 section 22 (revision 12) have no FIX twin either: your app sends them over REST with the token you sign, and FIX only reports their orders to your drop-copy sessions (section 5). FIX is order entry, execution reporting and the barrier RFQ vocabulary: run it alongside a REST client and the webhooks for everything else.

10. Conformance checklist

1. Logon with 141=Y, 553 = your key prefix, 554 = the key, 49 = your partner code, 56=BARRIERS, 108 between 5 and 120; expect the Logon echo as the FIRST frame of the session, 34=1, with 9120=N. Repeat with a wrong 554: expect Logout Sign in again. with 9110=4010 and 56=CLIENT, then a closed socket. Repeat with a READ key: expect the 4034 sentence. Repeat from an address off your allowlist: expect the SAME Sign in again. as a wrong key, and prove your client does not read the two apart.
2. TestRequest answered by Heartbeat with your TestReqID(112). Send one without 112: expect Reject(35=3) 371=112 and no Heartbeat, and a session that stays up.
3. Stay silent for 1.2x your HeartBtInt: expect a TestRequest; answer it. Stay silent for 2x: expect Logout heartbeat timeout.
4. Log on a second connection with the same key while the first is healthy: expect Logout session already active on the second and nothing on the first. Drop the first without a Logout, wait twice its HeartBtInt, log on again with the same key: expect the Logon echo.
5. Send a deliberate MsgSeqNum gap: expect Logout naming the REST route, then a closed socket. Re-logon with 141=Y and prove your client treats the router's 34 as starting at 1 again.
6. Send a ResendRequest(35=2): expect a SequenceReset(35=4) 123=Y whose 34 is the next number of the router's outbound sequence and whose 36 is the one after it; prove your client does not wait for a resend.
7. Send any business message without the Parties component: expect 35=j 380=5 with the sentence and your reference in 379. Send it naming a client you do not hold: expect 35=j 380=1 Unknown client. 9110=4004. Prove your client correlates a 35=j by 45 and 379.
8. Send a 35=G: expect 35=9 434=2 102=99 with the sentence. Send it with 37=, 11= and 41= all EMPTY: expect 37=0, 11=BARR-NONE, 41=BARR-NONE, all three PRESENT, and confirm your session layer accepts the answer.
9. Send a 35=V: expect 35=j 380=3 naming the REST market-data routes. Send a 35=ZZ: expect Reject(35=3) 373=3.
10. Log on with 9120=Y on a second key: expect the echo 9120=Y; send a 35=D: expect Reject(35=3) 373=99; send a 35=H: expect an application answer, never a 35=3.
11. Kill the connection mid-flow and prove your reconciliation (the REST reads, the webhooks) rebuilds your order and request state without a FIX resend.
12. Read GET /partner/v1/me while a session is live: expect fix.enabled true, fix.port the port you connected to, and your session's key prefix in fix.sessions; after your Logout, an empty list (fix.enabled reads false with fix.port null only while our acceptor is not listening on that host).
13. During a router rollout on the development environment: expect Logout router restart, reconnect with backoff, re-logon with 141=Y.

14. Enter a LIMIT far from the market (35=D with 40=2, 59=1, your ClOrdID(11), the Parties component): expect 35=8 150=0 39=0 with our 37, your 11, 151 = the quantity, 9113=ACKED, 9115 and 9121=FIX. Read GET .../orders/open: expect channel: "FIX" and channelRef = your reference on the record.
15. Cancel it by OrigClOrdID(41) (35=F): expect NOTHING until the venue confirms, then 35=8 150=4 39=4 58=canceled with 11 and 41 = your reference. Cancel it again by 37: expect 35=9 102=0 This order has already been cancelled..
16. Enter a MARKET order that crosses (or have a crossing order placed over REST on the development environment) and expect 35=8 150=F with 32, 31, 14, 151, 6, 12, 9111 and 9112; on a partial fill 39=1 then 39=2, 6 the volume-weighted average.
17. Enter an order off the lot grid: expect 35=8 150=8 37=0 103=13 9110=4000 with the sentence verbatim, and no order on GET .../orders/open. Enter one for a client below the market's verification level: expect 9110=4030 and 9118.
18. Send the same 35=D twice: expect 150=0 then 150=I 9117=Y with the same 37. Send it a third time with another price: expect 150=8 103=6 ClOrdID reused with a different payload 9110=4092 and no second order.
19. Send a 35=H by 41 for each state you can reach (working, partially filled, being cancelled, filled, cancelled): expect one 150=I each with 39 per 4.2 and 9113 the router's state. Send one for an id you do not hold: expect 150=I 39=8 103=5 37=0.
20. Omit each of 11, 55, 54, 38, 40 in turn: expect Reject(35=3) 373=1 naming the tag, no report, and a session that stays up. Send 54=X: expect 373=5.
21. On your drop-copy session, expect every report of steps 14 to 16 with 9121=FIX, the report of an order placed over REST with 9121=REST and no 11, and nothing of another partner's clients.
22. Kill your trading connection with an order working, let a fill land (on the development environment, cross it over REST), reconnect with the same key: expect no replay of the fill, the next reports of that order on the new session, and a 35=H that folds the missed fill into 14 and 6.

23. Send a 35=R on a KO market with 9134=N (your QuoteReqID(131), the Parties component, 55, 54=1, 38, 9130, optionally 9131): expect 35=AI 297=16 with 9140, 9161, 9160=OPEN, the terms, 62, 9152, 9143 and 9121=FIX. Read GET .../rfq/{rfqId}: expect channel: "FIX" and channelRef = your reference.
24. Wait for the market maker of the development environment: expect one 35=S per quote id with 117, 133 (a BUY request), 62, 9141, 9142 and 9115; prove your engine dedupes a repeated 9115 and handles a burst of several 35=S.
25. Send a 35=AJ (693, 694=1, 117 = a quote with 9142=Y, 131): expect 35=AI 297=0 with 9150, 9151, 9162 and 9115, then 35=8 150=F 39=2 on the KO symbol with 37=0, 11 = your reference, 31 = the entry, 12, 9150 to 9154 and 9130 to 9144. Send the same 35=AJ again: expect the 35=8 again with 9117=Y and a dup- ExecID, and no second contract on GET .../barriers.
26. Send a 35=R without 9134: expect 297=16 with 9134=Y, then, when an acceptable quote arrives, the 35=S, the 297=0 and the 35=8 without any 35=AJ from you.
27. Send a 35=R with 9136=1000 and let the window pass: expect 35=AI 297=7 9160=EXPIRED 9115=rfq:<id>:expired. Send a 35=Z on it: expect 35=j 380=0 This request is no longer open.. Send a 35=R and a 35=Z (131, 298=5) while it is open: expect 297=17 9160=CANCELLED.
28. Send a 35=R off the terms (an expiry more than 8 hours ahead, a quantity of 0, a PERP symbol): expect 35=AI 297=5 with the sentence verbatim, 9110, no 9140, and nothing on GET .../rfq. Send the same 35=R twice: expect 297=16 then 297=16 9117=Y 9110=4092 with the same 9140; a third time with another 9130: expect 297=5 QuoteReqID reused with a different payload.
29. With a contract open, send a 35=R with 9155 = its contractId and 9134=N: expect 297=16 with 9155, 54 the closing side and no 9130; expect the close quotes with 132 (a LONG) and 9148; accept one inside the terms: expect the settlement 35=8 (9156=earlyClose, 9157, 9158, 9159, 9155), the 297=0 and the early-close trade 35=8 (9155, 9161 and 9162 the close request's venue id and the accepted close quote, 12 = our early-close commission with 13=3 15=USDC, the client's BARRIER scheme on the premium at the accepted close price, the same figure as the close's COMMISSION ledger item with reason: "earlyClose" (docs/11), no 9152, no 9153, no terms), in that order. Accept a quote at the barrier first: expect 35=j with the barrier sentence and an unchanged request.
30. Let a contract knock out (on the development environment, wait for the mark to reach the barrier): expect 35=8 150=F 39=2 on the KO symbol with 54 the closing side, 31 = 9157, 9156=knockOut, 9158, 9159, 9115=barrier:<id>:closed, on the session whose key opened it and on your drop-copy session; on a drop-copy session, expect the reports of a request made over REST with 9121=REST and no 131.
31. Feed the example frames of this document to your parser as they stand (| to SOH): every one carries a real BodyLength(9), CheckSum(10) and SendingTime(52) computed over its bytes, so a parser that refuses one of them is wrong about the framing, not the example.
32. Send a 35=D whose ClOrdID(11) carries a byte above 0x7F: expect Reject(35=3) 373=6 371=11, no report, no order on GET .../orders/open, and a session that stays up.
33. Place an order over REST, then cancel it from a trading session by 37: expect nothing until the venue confirms, then the 150=4 with 9121=REST on THAT session and on your drop copy, and nothing on another trading session of yours.
34. Enter a marketable order (a MARKET, or an IOC that crosses on the development environment): when the fill lands before the acknowledgement expect the 150=F first and then a 150=0 whose 39, 14 and 151 match the fill, never a 39=0 after a 39=2.
35. Place an order on a trading session B and, from a second trading session A of yours, cancel it by OrigClOrdID(41) on the first 150=0 of your drop copy: expect silence on A, then the 150=4 on A, on B and on the drop copy, once each, and never 35=9 102=1 9110=4004 for an order whose acknowledgement you hold.
36. Send a 35=D whose ClOrdID(11) ends in a blank (a space as the last character of the value): expect the gateway-built 150=8 103=99 9110=4000 Text(58) ClOrdID(11) begins or ends with whitespace and is refused with 11 echoed as sent, no order on GET .../orders/open, and the same message without the blank accepted. Then cancel that order by OrigClOrdID(41) with a trailing blank: expect 35=9 102=99 9110=4000 OrigClOrdID(41) begins or ends with whitespace and is refused and the order still open; the same 35=F without the blank cancels it. The same door on 131 (a 35=R answers 297=5, a 35=AJ or 35=Z a 35=j) and on 693 (a 35=j).
37. Read the mark and priceBandBps of a perpetual (GET /market-info), then send a 35=D 40=4 54=2 with a StopPx(99) under the mark and a Price(44) far below the band around it (for example 44=1): expect the gateway-built 150=8 103=99 9110=4000 with the conditional limit band sentence of 3.4 naming the bounds, nothing placed; the same message with Price(44) inside the bounds is accepted (150=0, 9113=PENDING_TRIGGER) (revision 15).

Appendix A: the custom tags 9101 to 9199

The router's custom tags live in 9101 to 9199 and none of them is in the venue's own list (9001 to 9028), so a partner that also connects to the Kronos X venue can load both dictionaries side by side. The registry in code is PartnerFixTags.Registry; this table is generated from it row for row (the tag, the name, the direction, the message types it rides on, the meaning). The same build generates the Tag and Presence columns of the four outbound tag tables (4.1 for the 35=8 of an order, 7.2 for the 35=AI, 7.3 for the 35=S, 7.6 for the three contract 35=8) from the router's presence registries, in the code's order, and computes BodyLength(9), CheckSum(10) and the SendingTime(52) of every example frame of this document over the frame's own bytes; our test suite refuses a build in which any of them drifted from the code, and it checks that every custom tag on an example rides on a message type the registry lists for it. 9165 is reserved and never sent in this revision.

Standard tags read inbound in this revision: 8, 9, 10, 34, 35, 43, 49, 52, 56, 98, 108, 112, 141, 553, 554 (session); 1, 11, 18, 37, 38, 40, 41, 44, 54, 55, 59, 60, 99 (orders); 62, 117, 131, 146, 298, 693, 694 (RFQ); 447, 448, 452, 453 (Parties); 36, 123 (SequenceReset); 7 and 16 (ResendRequest, ignored beyond parsing). Standard tags written outbound: the header, 58, 45, 371, 372, 373, 98, 108, 141 (the Logon reply), 112 (the Heartbeat answering a TestRequest), 36, 123 (the GapFill SequenceReset answering a ResendRequest) (session), 6, 11, 12, 13, 14, 15, 17, 18, 31, 32, 37, 38, 39, 40, 41, 44, 54, 55, 59, 60, 99, 102, 103, 150, 151, 434 (orders), 62, 117, 131, 132, 133, 297 (RFQ), 379, 380 (business rejects), 447, 448, 452, 453.

Changelog