FIX 4.2 Specification

This document details the specification of OneChronos FIX, a modern variant of the FIX (Financial Interface eXchange) Protocol based on the FIX 4.2 protocol specification. Note that the FIX protocol includes support for many message types, fields, and field values that are not supported by OneChronos. Any message referenced in the FIX 4.2 specification but not referenced by OneChronos is unsupported.

Those who are not familiar with FIX can refer to the FIX Primer for background information before proceeding.

OneChronos FIX

All aspects of OneChronos FIX are strictly FIX 4.2 compliant with three exceptions:

1. We do not support sending messages with tag #97 (PossResend) set to Y.
2. We expose (optional) custom message types to simplify Expressive Bidding.
3. We (optionally) report trade breaks to Subscriber via a custom message type: TradeCancelCorrect=UCC.

Within the FIX 4.2 specification we note that:

• The replay of application level FIX messages (especially orders) as part of an application recovery plan is strongly discouraged. Best practice dictates that recovery scenarios are not left to the FIX engine alone. Applications should handle order cancellation and retransmission explicitly, sending corrective messages instead of replaying (potentially stale) ones.
• Our logon and logout procedures follow FIX protocol recommendations in additional to the minimum session protocol requirements. This is detailed in Logon Procedures.

Any field required by FIX 4.2 is required by OneChronos but not every field required by OneChronos is required by (or included in) FIX. Our documentation denotes Required fields as (Y) and Optional fields as (N). These marks are defined as:

• Required (Y): A field that is always required for the referenced message type. Messages without the field will be rejected. Example: ClOrdID (tag #11) is required for all NewOrderSingle messages.
• Optional (N): A field that is not always required but may be required in certain contexts, e.g. Price (tag #44) when sending a limit order. Please see message field and message wide validations to determine when a field is conditionally required or needs to take a fixed value.

Connectivity

Please contact [email protected] to discuss market connectivity. We offer a testing environment via WireGuard or IPsec VPN; certification and production connections must be made via private cross connect in one of our data centers. All FIX connections are made via TCP/IP.

Identifiers

Identifiers in FIX are fields such as ClOrdID (tag #11), an identifier supplied by Subscriber as part of any new order. FIX itself places few restrictions on the format of such identifiers (beyond the standard ASCII character requirement).

When interfacing with OneChronos there are two types of identifier: OneChronos assigned and Subscriber assigned. Identifiers assigned by OneChronos contain a more restrictive character set than what we accept. Subscriber assigned identifiers must comply with the standards below; messages containing invalid identifiers will be rejected.

Permitted Identifier Characters

From Subscriber to OneChronos

Any string with 1 ≦ length ≦ 32 comprised solely of characters from the ASCII range 0x21-0x7e exclusive of comma (ASCII 0x2c), semicolon (ASCII 0x3b), and pipe (ASCII 0x7c) is considered a valid identifier. Stated in terms of a regular expression strings accepted by ^(?!.*[,;|])[\x21-\x7E]{1,32}$ are valid identifiers.

From OneChronos to Subscriber

OneChronos will only use:

• Strings where 1 ≦ length ≦ 32
• Upper and lowercase characters from the alphabet (ASCII 0x41-0x7a)
• Digits (ASCII 0x30-0x39)
• Symbol in the set {#, -, ., :, _} (ASCII 0x23, 0x2d, 0x2e, 0x3a, 0x5f)

Identifiers sent/assigned by OneChronos will always be accepted by the regular expression ^[a-zA-Z0-9#\-\.:_]\{1,32\}$

ClOrdID Requirements

The ClOrdID (tag #11) and OrigClOrdID (tag #41) sent by Subscriber must be compliant with the character restrictions outlined in the permitted identifier characters section. It is highly recommended that every ClOrdID sent be unique within a trading day but OneChronos will not validate uniqueness unless a ClOrdID is "live."

Ideally, any ClOrdID sent by Subscriber should:

• Remain unique across FIX sessions (if the customer has multiple SenderCompIDs assigned) and never be reused even across trading days. This can be accomplished by prepending the trade day and a session identifier to any compliant ClOrdID, e.g. 20160710S10000000001, 20160710S10000000002, etc.
• Contain only characters from the character set that OneChronos uses as outlined in permitted identifier characters.

Identifier Types

Assigned by OneChronos

string

string

string

string

string

Assigned by Subscriber

string

string

string

string

string