Rejects, uncertain outcomes and acceptance
A minimum-notional rejection is an ordinary business outcome. It must not stop the venue or make the same session unusable. Durable result identity checks still apply: conflicting financial state, hashes or durable evidence must not be silently replaced with client-facing text.
Read codes, not prose
HTTP error bodies carry code and requestId; normalized business causes may
also appear as details.rejectCode. Retain the HTTP status and request ID.
ORIGIN_FORBIDDEN, DOMAIN_FORBIDDEN, APP_BINDING_MISMATCH,
INVALID_SIGNATURE and INVALID_DELEGATION_SIGNATURE are distinct failures.
Do not change a signed app/domain field without generating a fresh signature.
FIX/FIXP use their corresponding protocol error fields and execution reports,
not HTTP error bodies. BSL order-state reports carry rejectCode independently
of human-readable text. A gateway reject and an engine terminal are different
stages; both need correlation to the original request.
Package 1 preserves asynchronous FIX reject causes in OrdRejReason(103)
(standard value, usually 99), Senticore tag 9101 (stable numeric cause), and
Text(58) (public message). For example, minimum notional is 9101=1014.
FIXP keeps its existing SBE ExecutionReport layout: for a rejected execution,
the variable-length text is JSON with rejectCode and message. This is
distinct from FIXP BusinessReject codes. Historical replay keeps its original
wire bytes and may lack this metadata; do not demand retroactive enrichment.
Direct TCP transport outcomes
| Numeric reason | Meaning | Client action |
|---|---|---|
100 BackpressureFull | Bounded capacity refused admission | Back off; preserve command identity when retrying |
105 WriteLeaseFenced | Writer/session fencing | Reconnect and reconcile; no automatic replay |
106 DurabilityUnknown | Durable admission/execution may have happened; a response was lost or authority is uncertain | Query status/replay for the original order/sequence; never create a fresh order just because the response is missing |
108 IpcTransportUnavailable | Proven transport failure before this request was submitted | Reconnect/back off; retry only the identical request |
200 AuthFailed | Order authorization failed | Correct key, signature or policy; do not label as overload |
202 SessionViolation | Session identity, sequence or protocol mismatch | Inspect the specific diagnostic and reconcile session state |
Version boundary: reason 108 and the explicit gateway transport classification are part of the Package 1 release. Deploy compatible decoders before that gateway release. Older gateways may conflate IPC failures with 100; a 100 from an unverified older gateway is not sufficient proof that the order never ran. Reason 106 must not trigger automatic resubmission. Unknown numeric codes must remain visible and must not default to an automatic retry policy.
HTTP 202 Accepted is unrelated to BSL numeric reason 202. An HTTP acceptance
or COMMAND/Core ACK does not mean that matching or terminal delivery finished.
Per-account release gate
On an authorized isolated fixture first, then the approved live canary:
- Authenticate on the actual customer lane (HTTP, BSL TCP, FIXP, FIX).
- Submit a below-minimum order and require its correlated reject. Check that it did not reserve funds or leave a live order; a consumed nonce may be valid.
- Submit a valid order on the same session, then cancel it. Require terminal confirmation, not just PendingNew or a queue ACK.
- Retry/reconnect using original identities; verify no duplicate order/fill, no lost reject, no resurrected cancel and consistent durable replay.
- Exercise connection failure before send and after send/before response. Only the former permits a proven-not-submitted response.
No DMS guarantee follows from these tests. The new core-owned HTTP/BSL DMS is not yet generally available. Existing session-key cancel-on-disconnect behavior does not establish gateway-crash, full-Core-restart or failover protection.
Publish ACK, durable result and terminal-at-client latency separately, with offered load, completed OPS, session count, network location and errors. A successful handshake or a short localhost smoke is not an end-to-end SLA.