Combinatorial Call Auctions

Beta

Note: Our FIX documentation is in beta and subject to change until this notice is removed. We will not employ semantic versioning during this period. Please report any errors or omissions to our engineering team.

Introduction

This document details the specification of OneChronos FIX, a variant of the FIX (Financial Interface eXchange) Protocol based on the FIX 4.2 protocol specification.

Those already familiar with FIX are free to skip directly to OneChronos FIX and everything thereafter. 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.

FIX Primer

The FIX protocol is a transport agnostic text based protocol widely used by financial institutions to send orders, receive execution reports, and disseminate market data. There are many versions of FIX, and individual institutions usually customize a specific version of FIX for their use case. OneChronos FIX is based on the FIX 4.2 protocol specification.

FIX is a session based, asynchronous, guaranteed message delivery protocol. Sessions are bidirectional streams of messages between two parties that may arrive out-of-order, but will always be processed by the receiving application in-order. A single FIX session can span multiple physical connections; sessions are independent of network connects and disconnects. Message sequence numbers are used to ensure orderly message processing and recovery of lost messages.

FIX messages are broadly divided into two types: administrative, which control the FIX session itself, and business, which exchange information on the application level. The messages themselves are key/value pairs, delimited by the SOH character (ASCII #001, hex 0x01). Given that SOH is an unprintable character, we'll use "|" in its place when displaying messages. All FIX messages start with the Standard Message Header and end with the Standard Message Trailer. The set of key/value pairs between the header and the trailer (referred to as the Body) are message type dependent. The type of the message is always given by a tag in the header: MsgType (tag #35).

As an example, the following is an order to buy 1,000 shares of GOOG at a limit price of $1040.48 per share.

Raw Message
8=FIX.4.2|9=158|35=D|34=5|49=p.s1.trader01|52=20171211-17:16:34.112|56=ICGX|11=20171211000000002|21=1|38=1000|40=2|44=1040.48|47=A|54=1|55=GOOG|59=0|60=20171211-17:16:34.112|10=203|

Formatted
Header
8        BeginString:         FIX.4.2
9        BodyLength:          158
35       MsgType:             ORDER_SINGLE (D)
34       MsgSeqNum:           5
49       SenderCompID:        p.s1.trader01
52       SendingTime:         20171211-17:16:34.112
56       TargetCompID:        ICGX

Body
11       ClOrdID:             20171211000000002
21       HandlInst:           AUTOMATED_EXECUTION_ORDER_PRIVATE_NO_BROKER_INTERVENTION (1)
38       OrderQty:            1000
40       OrdType:             LIMIT (2)
44       Price:               1040.48
47       Rule80A:             AGENCY_SINGLE_ORDER (A)
54       Side:                BUY (1)
55       Symbol:              GOOG
59       TimeInForce:         DAY (0)
60       TransactTime:        20171211-17:16:34.112

Trailer
10       CheckSum:            203

Message Format

Every FIX message is a stream of <tag>=<value> fields with a field delimiter (ASCII SOH) used between fields in the stream. Depending on the message type, some fields are required, others are conditionally required, and some are optional. All tags must have a value specified. Optional fields without values should not be included in the FIX message - the message will be rejected as malformed if they are. The general format of a FIX message is the standard header followed by the message body fields and terminated with the standard trailer.

Except where noted, fields within a message can be defined in any sequence. The relative position of a field within a message is inconsequential (although by convention they are displayed in ascending tag sorted order).

With the exception of data type fields (discussed in the data types section) FIX uses ASCII 128 encoding for all message content (tags, values, and delimiters).

Field Delimiter

All fields (including the last field in a message) are terminated by the ASCII SOH character (#001, hex 0x01). Given that this is an unprintable character, our documentation uses "|" in place of SOH, but SOH should always be used in actual FIX messages.

Data Types

The following data type descriptions were taken from the Financial Information Exchange Protocol (FIX) Version 4.2 with Errata 20010501. Data types are mapped to ASCII strings as follows:

  • int: Sequence of digits without commas or decimals and optional sign character (ASCII characters "-" and "0" - "9" ). The sign character utilizes one byte (i.e. positive int is "99999" while negative int is "-99999"). Note that int values may contain leading zeros (e.g. “00023” = “23”). Examples: 723 in field 21 would be mapped int as |21=723|. -723 in field 12 would be mapped int as |12=-723|
  • float: Sequence of digits with optional decimal point and sign character (ASCII characters "-", "0" - "9" and "."); the absence of the decimal point within the string will be interpreted as the float representation of an integer value. All float fields must accommodate up to fifteen significant digits. The number of decimal places used should be a factor of business/market needs and mutual agreement between counterparties. Note that float values may contain leading zeros (e.g. “00023.23” = “23.23”) and may contain or omit trailing zeros after the decimal point (e.g. “23.0” = “23.0000” = “23”).
  • qty: float field (see definition of “float” above) capable of storing either a whole number (no decimal places) of “shares” or a decimal value containing decimal places for non-share quantity asset classes.
  • price: float field (see definition of “float” above) representing a price. Note the number of decimal places may vary.
  • char: Single character value, can include any alphanumeric character or punctuation except the delimiter. All char fields are case sensitive (i.e. m ≠ M).
  • boolean: a char field (see definition of “char” above) containing one of two values: * 'Y' = True/Yes * 'N' = False/No
  • string: Alpha-numeric free format strings, can include any character or punctuation except the delimiter. All char fields are case sensitive (i.e. morstatt ≠̸ Morstatt).
  • multi_value_string: String field (see definition of “String” above) containing one or more space delimited values.
  • exchange: String field (see definition of “String” above) representing a market or exchange.
  • utctimestamp: Time/date combination represented in UTC (Universal Time Coordinated, also known as “GMT”) in either YYYYMMDD-HH:MM:SS (whole seconds) or YYYYMMDD-HH:MM:SS.sss (milliseconds) format, colons, dash, and period required. Valid values: * YYYY = 0000-9999, MM = 01-12, DD = 01-31, HH = 00-23, MM = 00-59, SS = 00- 5960 (60 only if UTC leap second) (without milliseconds). * YYYY = 0000-9999, MM = 01-12, DD = 01-31, HH = 00-23, MM = 00-59, SS = 00- 5960 (60 only if UTC leap second), sss=000-999 (indicating milliseconds).

* See the International Earth Rotation Service (IERS) guide to leap seconds for additional details on leap second handling.

Checksum Calculation

FIX uses a weak checksum to protect against obvious forms message corruption. The CheckSum (tag #10) is the last field of any FIX message. It is computed via the following procedure:

  1. Initialize an unsigned 32 bit integer (henceforth referred to as checksumTotal) to zero.
  2. Iterate over every character in the FIX message up to, but not including, the checksum field, and add its integer value to checksumTotal.
  3. Take the value of checksumTotal mod 256 and format it as a zero padded, three digit string.

In pseudocode:

String computeFixChecksum(String fixMessage) {
    unsigned int32 checksumTotal;
    for(char msgChar in fixMessage) {
        checksumTotal += (unsigned int32)msgChar;
    }
    checksumTotal = (unsigned int32)(checksumTotal % 256);
    return String.format("%03d", checksumTotal);
}

Message Delivery

FIX guarantees full, ordered, once-and-only-once processing (of application messages) between parties regardless of the network transport (e.g. TCP/IP, UDP) used. Formally, FIX provides bidirectional at-least-once message delivery semantics, and once-and-only-once processing semantics. A system of inbound and outbound sequence numbers tracked by both sides of the session dialogue makes this possible. Henceforth we will refer to the two parties in a FIX dialogue as P1 and P2. Note that P1's outbound sequence is P2's inbound sequence, and P1's inbound sequence is P2's outbound sequence. By tracking sequences and providing facilities for P1 to request that P2 resends messages (and vice versa) the protocol allows for asynchronous but orderly communication. Note that FIX uses an optimistic delivery model. Message receipt is never acknowledged on the protocol layer but message processing is (e.g. NewOrderSingle is acknowledged with an ExecutionReport indicating the order's status).

Sequence Numbers

Every FIX message contains a sequence number - MsgSeqNum (tag #34) - in its header. Parties to a FIX session use these sequence numbers to ensure that messages arriving from their counterparty are processed in the correct order, and that no messages were lost.

At the beginning of a FIX session both parties initialize their "inbound" and "outbound" sequence numbers to one. When a message is sent, they increment their outbound counter. When a message is received, they check that the message sequence number is equal to their inbound sequence number. If it is, they increment their inbound sequence number and process the message. If it is not, the process described in ordered message processing is used to recover the dropped messages. Note that in both cases the inbound/outbound sequence numbers were read and the appropriate action performed before incrementing.

Example:

  • Start of session: P1 sets her inbound and outbound sequence number to one, as does P2
  • P1 sends P2 a Logon message with sequence number one. After sending, she increments her sequence number to two
  • P2 receives the Logon message from P1, noting that one is the expected sequence number at the start of the session. He sends a Logon message in acknowledgement. The sequence number on his response is one (he hasn't sent anything yet). After sending, he increments his outbound sequence number to two
  • P1 receives the message, noting that one was the expected sequence number for P2's response
  • Both P1 and P2 now have their inbound and outbound sequence numbers set to two. Going forward P1 and P2 will not always increment their sequence numbers in lock step. Some messages never need a reply (market data) and others may need several replies (multiple execution reports when an order is filled). Having P1 and P2 maintain independent inbound/outbound sequence numbers ensures that this is never a problem

Ordered Message Processing

FIX supports two options for processing out-of-order/dropped messages. In both cases, a ResendRequest as outlined in the section on recovery is used to initiate retransmission. Of the two options below, option one is preferable, but both are valid:

When a message arrives with a sequence number higher than the expected inbound sequence number…

  1. Request the missing message(s) explicitly by sequence number while placing new arrivals into to a priority queue sorted by message sequence number. When the missing message is received as a retransmission, process it, process the queue, and resume processing of the inbound message stream.
    • Example: the receiver misses message five and receives messages six through ten. The receiver requests that message five be replayed and adds messages six through ten to a sorted list for processing after message five is received.
  2. Ignore all new messages after the gap and request replay of messages between the inbound sequence number and the largest message sequence number seen (or preferably set EndSeqNo=0 in the ResendRequest to indicate that all messages from BeginSeqNo on should be replayed). If new messages arrive while the replayed message(s) are in-flight, repeat the process iteratively.
    • Example: the receiver processes messages one through four, misses message five, and receives messages six through ten. It requests replay for messages five through ten by sending a ResendRequest with BeginSeqNo=5 and EndSeqNo=10 or ideally EndSeqNo=0.

Recovery

As noted in the section on ordered message processing, counterparties can request that missed messages are replayed via a ResendRequest message. Any message that is sent in response to a replay request must be sent with the PossDupFlag (tag #43) set to Y. The only fields that can change in a retransmission are: CheckSum (tag #10), OrigSendingTime (tag #122), SendingTime (tag #52), BodyLength (tag #9) and PossDupFlag (tag #43).

A counterparty may elect to send a SequenceReset message with the GapFillFlag (tag #123) in response to ResendRequest in lieu of replaying the original message. This is useful in situations where the original message is no longer relevant, e.g. an outdated order, or when the message requested is an administrative message (which typically aren't replayed).

When consecutive administrative messages are present it is recommended that only one SequenceReset be sent in their place. This is accomplished by setting the MsgSeqNum of the SequenceReset to the next expected outbound sequence number and the NewSeqNo (tag #36) to the sequence number of the highest administrative message in the group, plus one. Example: there are five consecutive administrative messages being resent. The first message has a sequence number of ten, the last a sequence number of fourteen. A SequenceReset is sent in their place, with MsgSeqNum=10 and NewSeqNo=15.

Logon Messages

Under the standard ordered message processing and recovery paradigm, out-of-order messages are never processed on the application layer. An exception is made for Logon messages. The recipient of a Logon should always process it immediately, even if their sequence number is too high. After sending a Logon confirmation back, a ResendRequest is sent if a message gap was detected in the Logon sequence number.

Duplicates

Messages may be duplicated in the course of typical ordered message processing and recovery procedures. Any message that may be a duplicate (transmitted in response to a ResendRequest) must be sent with PossDupFlag=Y. If PossDupFlag=Y is set and the message sequence number is less than the receiver's inbound sequence number, the message is dropped. Doing so ensures once-and-only-once processing semantics for the application layer.

If at any point a message is seen with an incoming sequence number less than expected and the PossDupFlag flag is not set to Y, a serious error has occurred. The only caveat to this rule which involves multiple overlapping ResendRequests, is covered in the sequence resets section. The recipient of a such a message should terminate the FIX session immediately via a Logout message. Further intervention may be required to ensure that no orders are outstanding and that all filled orders are accounted for.

Retransmissions

The FIX protocol specifies a method for application level retransmission when no gap was detected but there is concern that a message was not handled by the counterparty (e.g. an order was sent but no execution reports received). This is usually accomplished by setting PossResend (tag #97) to Y. OneChronos does not support this aspect of FIX. Resending messages in this fashion is unnecessary, potentially dangerous, and impossible to implement performantly.

Sequence Resets

A counterparty's incoming sequence number (the sender's outgoing sequence number) can be reset during message recovery via the SequenceReset message. There are two modes of doing so:

  • A SequenceReset message with GapFillFlag (tag #123) set to Y (henceforth referred to SeqReset-GapFill)
  • A SequenceReset message with GapFillFlag (tag #123) set to N (henceforth referred to SeqReset-Reset)

SequenceReset messages can also be sent to a counterparty, unsolicited, when standard ordered message handling procedures need to be bypassed (this is almost never necessary or advisable). Sending a SeqReset-Reset tells the counterparty to ignore the MsgSeqNum field and reset its expected incoming sequence number explicitly.

In all cases NewSeqNo (tag #36) should be set to the sequence number of the message being skipped, plus one. If multiple messages are being skipped, it should be set to the highest sequence number out of all messages being skipped, plus one.

SeqReset-GapFill messages must conform to the standard sequencing rules (i.e. their sequence numbers should match the counterpary's expected inbound sequence number). Both SeqReset-GapFill and SeqReset-Reset requests should only ever attempt to increase the counterparty's incoming sequence number. The note in the section on duplicates holds - any attempt to decrease a counterparty's sequence should (and will, for OneChronos) result in immediate termination of the session.

It is possible to have multiple ResendRequests in-flight simultaneously. When this happens a SeqReset-GapFill sent in response may be an implicit duplicate, even if the PossDupFlag is not set. This condition is easily detected by checking if the MsgSeqNum for a SeqReset-GapFill is less than the expected incoming sequence number. Such messages should be silently dropped, even though PossDupFlag is not set. As an example (adapted from the FIX 4.2 guide):

  • P1 sends a ResendRequests for sequence numbers five through ten followed immediately by a second request for five through eleven.
  • Messages eight, ten, and eleven are application messages. Messages five through seven, and nine, are administrative messages that should be skipped.
  • P2 replies to the first ResendRequests with (SeqReset-GapFill, MsgSeqNum=5, NewSeqNo=8), (Message eight, MsgSeqNum=8, PossDupFlag=Y), (SeqReset-GapFill, MsgSeqNum=9, NewSeqNo=10), (Message ten, MsgSeqNum=10, PossDupFlag=Y).
  • P2 replies to the second ResendRequests with (SeqReset-GapFill, MsgSeqNum=5, NewSeqNo=8), (Message eight, MsgSeqNum=8, PossDupFlag=Y), (SeqReset-GapFill, MsgSeqNum=9, NewSeqNo=10), (Message ten, MsgSeqNum=10, PossDupFlag=Y), (Message eleven, MsgSeqNum=11, PossDupFlag=Y).
  • P1 receives P2's first series of replies and processes them, after which P2's expected incoming sequence number is eleven.
  • P1 receives P2's second series of replies. The first of which, SeqReset-GapFill, MsgSeqNum=5, NewSeqNo=8, attempts to decrease P2's incoming sequence number. However P2 can determine that this is an implicit duplicate given that MsgSeqNum=5 is less than the expected sequence, so it ignores it. Message eight, MsgSeqNum=8, PossDupFlag=Y is ignored as a duplicate because PossDupFlag=Y and its sequence number is less than eleven. SeqReset-GapFill, MsgSeqNum=9, NewSeqNo=10 is ignored for the same reason that the first SeqReset-GapFill was ignored, and message ten is ignored for the same reason that message eight was. Message eleven is processed because MsgSeqNum=11 is equal to the expected incoming sequence number.

Logon Procedures

FIX sessions start with a Logon message and end with a Logout. Given the complexities of sequence number handling, several scenarios must be accounted for. We will refer the party initiating the logon as Initiator and the party receiving it as Acceptor.

Logging in and Resetting Sequence Numbers

A session Initiator can reset sequence numbers while logging in by including the field ResetSeqNum (tag #141)=Y. In such cases, Acceptor will reset their expected incoming sequence number to one before processing the Logon message, per the message delivery rules. Messages from any previous session will be dropped. Note: this is only advisable when establishing a new FIX session after the daily sequence number reset period.

The following logic applies when Acceptor receives a Logon message with ResetSeqNum (tag #141)=Y:

  1. Logon message received by Acceptor is valid and authentication succeeds?
    • Yes
      • Acceptor responds with Logon ResetSeqNum (tag #141)=Y. Initiator should set their expected incoming sequence number to one before processing the response from Acceptor. A session is now established.
    • No, the message was valid but authentication failed
      • Acceptor responds with Logout with the Text (tag #58) field set to a description of the reason for authentication failure.
    • No, the message was valid but the session was in use
      • Acceptor will not respond, given that doing so might corrupt sequence numbers for the active session.
    • No, the message was well formed but invalid
      • Acceptor will reply with a Reject message with SeqNum=1. An explanation as to why the message was invalid will be given in the Text (tag #58) field. When applicable SessionRejectReason (tag #373) and RefTagID (tag #371) will be populated.
    • No, the message was malformed
      • Acceptor will silently drop any packets containing malformed data.

Logging in Without Resetting Sequence Numbers

The following logic is used to negotiate a FIX session when Acceptor receives a Logon message with ResetSeqNum (tag #141)=N or unset:

  1. Logon message received by Acceptor is valid, authentication succeeds, and SeqNum is greater than or equal to the incoming sequence number that Acceptor expects?
    • Yes
      • Proceed to step 2.
    • No, the message was valid but authentication failed
      • Acceptor responds with Logout with the Text (tag #58) field set to a description of the reason for authentication failure.
    • No, the message was valid but the session was in use
      • Acceptor will not respond, given that doing so might corrupt sequence numbers for the active session.
    • No, the message was well formed but invalid
      • Acceptor will reply with a Reject message with SeqNum=1. An explanation as to why the message was invalid will be given in the Text (tag #58) field. When applicable SessionRejectReason (tag #373) and RefTagID (tag #371) will be populated.
    • No, the sequence number was less than expected
      • Per the note in the section on duplicate messages, Acceptor will not acknowledge the message as doing so might cause further problems.
    • No, the message was malformed
      • Acceptor will silently drop any packets containing malformed data.
  2. Are sequence numbers in sync for both the Initiator and Acceptor?
    • Yes
      • Proceed to step 3.
    • No, the Logon message received by Acceptor from Initiator has a sequence number that is higher than expected
      • Acceptor sends a ResendRequest for the missing messages. Initiator may wish to respond with SeqReset-GapFill if the original messages are no longer relevant. Repeat step 2.
    • No, the Logon message received by Initiator from Acceptor has a sequence number that is higher than expected
    • No, the Logon message received by Initiator from Acceptor has a sequence number that is lower than expected
  3. Has one second elapsed since a Logon message or a ResendRequest was sent or received by either party?
    • Yes
      • Acceptor sends a TestRequest indicating that a FIX session was established. Initiator is free to send business type messages to Acceptor, and vice versa.
    • No
      • Repeat step 3.

Logout

Once a FIX session is established, either party to the session can terminate it by sending a Logout message. Initiator should wait for Acceptor to respond with a reciprocal Logout message before closing the session. Heartbeat timeout rules apply if Acceptor does not acknowledge the Logout message in a timely fashion. The logout workflow is as follows:

  1. Initiator sends Acceptor a Logout message.
  2. Is the sequence number equal to Acceptors's expected incoming sequence number?
    • Yes
      • Acceptor responds with a Logout message
    • No
      • Acceptor sends Initiator a ResendRequest
      • Acceptor sends a Logout messages after receiving all missing messages. Initiator can now consider the session ended.

Heartbeats

FIX uses a bidirectional "heartbeat" to ensure that a session is logically alive, regardless of network state. When Initiator sends a Logon message, it must populate the HeartBtInt (tag #108) field with a value stipulating the maximum length of time (in seconds) that should elapse between messages. For example, if P1 sets an interval of thirty seconds (expressed as an integer number of seconds) in her Logon message, she expects to see a message from P2 at least every thirty seconds. If a message is not sent as part of normal session activity, P2 must send a Heartbeat message instead. When P2 replies to P1's Logon message he stipulates a heartbeat interval as well.

When either party to a FIX session notes that the heartbeat interval plus one second has elapsed without a message being sent they are responsible for sending a TestRequest message. If no message is received within another heartbeat interval, the session is considered lost. A Logout message should be sent (with the expectation that the counterparty might not receive it), after which logon procedures can be reinitiated.

OneChronos FIX

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

  1. We do not support sending messages with tag #97 (PossResend) set to Y. Application level resends as described in the original FIX specification are difficult to accommodate, potentially dangerous, and always unnecessary.
  2. 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. See Logon Procedures for additional details.

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), Conditionally Required fields as (C), 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.
  • Conditionally Required (C): A field that might be required, conditional upon the presence or value of another field. Example: Price (tag #44) is required for all NewOrderSingle messages where OrdType (tag #40) is set to LIMIT='2'.
  • Optional (N): A field that is never required, but might be useful for Subscriber. Example: OnBehalfOfSubID (tag #116) is never used by OneChronos, but some subscribers choose to include it to simplify their back office reporting process.

Connectivity

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

Market Hours

OneChronos supports trading during "normal" US equities market hours (9:30am-4pm EST). A pre-market order entry period runs from 9:15am-9:30am, during which Subscribers can enter orders that will participate in the first auction of the trading day, at or after 9:30am EST. Open FIX sessions are logged out and disconnected at 5:00pm. Subscribers can reestablish a session at or after 8am EST the following day. Incoming and outgoing sequence numbers are reset to one nightly.

All times EST, and on the half-closed interval [Start Time, End Time)    
Phase Start Time End Time
Pre-Market Order Entry 9:15am 9:30am
Regular Market Session 9:30am 4:00pm
Post-Market (ExecutionReport and TradeCancelCorrect only) 4:00pm 5:00pm
FIX Session Logout/Sequence Reset 5:00pm 5:01pm

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). However, many exchanges and regulators do. As a global trading venue, OneChronos seeks to accommodate as many use cases as possible. To that end, our identifier restrictions are designed to maximize global comparability.

When interfacing with OneChronos there are two types of identifier: OneChronos assigned and Subscriber assigned. Identifiers assigned by OneChronos are done so as part of the onboarding process. They 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 ≦ 255 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,255}$ are valid identifiers.

From OneChronos to Subscriber

OneChronos will only use:

  • Strings where 1 ≦ length ≦ 255
  • 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,255}$

ClOrdID Requirements

The ClOrdID (tag #11) and OrigClOrdID (tag #41) sent by Subscriber must be:

Depending on the geography/asset class of the instrument(s) being traded, additional regulatory requirements might apply.

A Note on ClOrdID Uniqueness Checks

We validate all ClOrdIDs for uniqueness against the active order book. Failure to ensure that ClOrdID values are trading day unique may cause significant clearing and back office problems for Subscriber, but order handling within OneChronos is unaffected.

ClOrdID Best Practices

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

Tag Name Description
17 ExecID

Type: string. A unique ID for each execution report sent from OneChronos to Subscriber.

37 OrderID

Type: string. An identifier assigned by OneChronos to all orders entered via NewOrderSingle.

49 SenderCompID

Type: string. OneChronos will assign this identifier as part of customer onboarding. Messages sent to OneChronos must always include Subscriber's assigned SenderCompID.

56 TargetCompID

Type: string. The logical mirror of SenderCompID. Messages received from OneChronos will always have this field set to the SenderCompID assigned to you by us.

112 TestReqID

Type: string. An identifier for use with TestRequest and Heartbeat messages.

Assigned by Customer

Tag Name Description
1 Account

Type: string. A client supplied account identifier.

11 ClOrdID

Type: string. A Subscriber provided order ID satisfying the requirements for Subscriber provided IDs.

41 OrigClOrdID

Type: string. The ClOrdID of the original order.

112 TestReqID

Type: string. An identifier for use with TestRequest and Heartbeat messages.

115 OnBehalfOfCompID

Type: string. Identifies the "end client" of a message sent by Subscriber to OneChronos. Messages from OneChronos will never populate this field. Service bureaus must populate this field with a valid NSCC MPID.

116 OnBehalfOfSubID

Type: string. A sub-identifier used in conjunction with OnBehalfOfCompID.

20000 TransactionBlockID

Type: string. A transaction block identifier. See the section on Transactional Processing for additional details.

Transactional Processing

OneChronos supports atomic transactions spanning groups of FIX messages. Transactional processing allows for greater precision and control over order management. It also allows market participants to leverage Computational Order logic without changes to their existing trading workflow.

When sending NewOrderSingle or OrderCancelRequest messages to OneChronos, Subscriber may optionally set TransactionBlockID (in which case TransactionBlockLength is required as well). When OneChronos encounters a message with TransactionBlockID set it defers processing it until all messages with the given ID (as determined by TransactionBlockLength) have been received, or until the transaction times out (timeouts can be set on the port or message level). If set on the first message sent for a given TransactionBlockID, TransactionBlockLength, TransactionBlockTimeout, ComputationalOrderPayload must be identical to or absent from all subsequent messages for the transaction (best practice states that they are omitted).

Transactions are sequential and atomic. If, for example, Subscriber wishes to place one order contingent on the successful cancellation of another, they may do so by submitting an OrderCancelRequest and NewOrderSingle that share a transaction ID. If the order cannot be canceled, the transaction will fail; the OrderCancelRequest will receive an OrderCancelReject and the NewOrderSingle will receive a BusinessReject.

Transactional processing is a powerful tool for combinatorial use cases, and when used in conjunction with a Computational Order. For example, a subscriber wishing to buy GOOG and sell MSFT at a specific delta would enter a NewOrderSingle for each leg with a shared TransactionBlockID and ComputationalOrderPayload expressing the spread. Their existing OMS and trading infrastructure can remain agnostic as to the contents of the Computational Order payload. OneChronos will send ExecutionReport messages for each leg independently but manage their execution jointly, evaluating the contents of Subscriber's Computational Order during each auction cycle.

Order Types

OneChronos supports market and limit order types, with optional Computational Order logic as an overlay; we utilize periodic, time randomized, uniform price combinatorial call auctions to clear the market. Our mechanism seeks to maximize a hierarchical objective function that targets economic surplus (price priority) as the primary objective with volume as a second objective, subject to all user supplied constraints. When multiple, equally optimal clearing prices exist for a single symbol, we take a midpoint between between the minimum and maximum clearing price. In the presence of an order imbalance, allocations between winners are done on a round robin basis. There is no time priority within or between auctions.

Market orders interact with the market at whatever clearing price is determined, ex market orders. In the event that every buyer and seller for a given symbol wishes to participate at market, the midpoint of NBBO is used instead.

Limit orders ensure execution at a price equal to or more favorable than the price specified. Unlike a traditional limit order book (continuous double auction) there is no notion of a maker/taker, and price improvement is possible for resting liquidity.

Computational orders contain a snippet of code written in our proxy bidding language. When OneChronos calls an auction, we evaluate every auction participant's proxy bidder against a snapshot of market data taken from away venues, as well as Subscriber's execution context (an object containing references to other orders that Subscriber has entered, and any global state that they define). Proxy bidders can perform actions such as canceling resting orders or placing constraints on the execution of one or more legs of an a transaction. Constraints are expressed in terms of our combinatorial bidding language. We are finalizing documentation for our proxy bidding language; please join our mailing list to receive notifications as we release additional documentation.

All Messages

General Notes

To ensure correctness and an easy interop, OneChronos uses a FIX engine and order management system programmatically generated from a formal specification. A copy of the specification is available here. The specification conforms to the JSON Schema available here. Note that certain FIX fields within this documentation contain the attributes required_when, validation, and value. All are written in terms of a domain specific language (DSL) designed for readability as pseudocode. Notably, validations are modeled off of the syntax for Active Record Validations.

The required_when attribute is present whenever a field is marked as conditional. The validation attribute references code used for validating the field. Note that the validation is only run when the field's value is set. Fields that are required but not set will result in a Reject message being sent before additional validations are run. Fields that are not required are only validated if present (allow_blank: true is implicitly set on all such fields).

Validators will only run after a field is considered valid on the FIX protocol level. For example, OnBehalfOfCompID must be present if subscriber is a service bureau, and must be a valid MPID in such cases. Implicit in this check is that this field is set, and that the field has type string. Furthermore, validators only target messages sent from Subscriber to OneChronos. For bidirectional fields (e.g. MsgType) we note this explicitly. In such cases, separate validations will apply to Subscriber and OneChronos. Both parties can send the other a Heartbeat, but only Subscriber can send OneChronos a NewOrderSingle, and only OneChronos can send Subscriber an ExecutionReport. Administrative messages are always bidirectional, with the exception of Reject. Directional messages are split into From Subscriber and To Subscriber sections.

Value fields can be static or computed. For example, get(parent, :on_behalf_of_sub_id) fetches the OnBehalfOfSubID field (if one is set) from the parent message. We define session, parent, and self when evaluating such functions.

  • session: A reference to the FIX session state.
  • parent: A context sensitive reference to the logical parent of a message, or null if there isn't one. For example, the parent of an ExecutionReport-Fill is always the original NewOrderSingle. However, the parent of Heartbeat could be a TestRequest if the Heartbeat resulted from one, or null otherwise.
  • self: A reference to the message being validated/populated.

Standard Header

The "Standard Header" is included at the beginning of every FIX message. The first three tags (BeginString, BodyLength, and MsgType) must appear in that exact order.

Tag Name Required? Description
8 BeginString Y

Type: string. A delimiter identifying the start of a new FIX message. BeginString must be the first field present in every FIX message.

Validation (from Subscriber): value: { is: 'FIX.4.2' }

Value (to Subscriber): FIX.4.2

9 BodyLength Y

Type: int. Message length, in bytes, of all characters up to and including the delimiter preceding the CheckSum field. BodyLength must be the second field present in every FIX message.

Validation (from Subscriber): length: { in: 0..10485760 }; valid_fix_body_length: true

Value (to Subscriber): fix_body_length(self)

35 MsgType Y

Type: string. The type of the FIX message. MsgType must be the third field present in every FIX message.

Enum values:
  • HEARTBEAT: 0
    Message is a Heartbeat.
  • TEST_REQUEST: 1
    Message is a TestRequest.
  • RESEND_REQUEST: 2
    Message is a ResendRequest.
  • REJECT: 3
    Message is a Reject.
  • SEQUENCE_RESET: 4
    Message is a SequenceReset.
  • LOGOUT: 5
    Message is a Logout.
  • EXECUTION_REPORT: 8
    Message is a ExecutionReport.
  • ORDER_CANCEL_REJECT: 9
    Message is an OrderCancelReject.
  • LOGON: A
    Message is a Logon.
  • ORDER_SINGLE: D
    Message is a NewOrderSingle.
  • ORDER_CANCEL_REQUEST: F
    Message is an OrderCancelRequest.
  • TRADE_CANCEL_CORRECT: UCC
    Message is an TradeCancelCorrect.

Validation (from Subscriber): inclusion: { in: [MsgType.HEARTBEAT, MsgType.TEST_REQUEST, MsgType.RESEND_REQUEST, MsgType.SEQUENCE_RESET, MsgType.LOGOUT, MsgType.LOGON, MsgType.ORDER_SINGLE, MsgType.ORDER_CANCEL_REQUEST] }

Value (to Subscriber): message_type(self)

34 MsgSeqNum Y

Type: int. The message sequence number, per the rules governing message sequence numbers.

Validation (from Subscriber): value: { greater_than: 0 }, if: { get(self, :poss_dup_flag) == PossDupFlag.POSSIBLE_DUPLICATE }; value: { greater_than: inbound_sequence(session) }, if: { get(self, :poss_dup_flag) == PossDupFlag.ORIGINAL_TRANSMISSION }

Value (to Subscriber): outbound_sequence(session)+1

43 PossDupFlag C

Type: boolean. A flag indicating whether a message is a possible session level retransmission, per the message delivery rules.

Required when: is_possible_duplicate(self)

Enum values:
  • POSSIBLE_DUPLICATE: Y
    Message is a possible retransmission.
  • ORIGINAL_TRANSMISSION: N
    Message is guaranteed to be an original transmission.

Value (to Subscriber): is_possible_duplicate(self) ? PossDupFlag.POSSIBLE_DUPLICATE : PossDupFlag.ORIGINAL_TRANSMISSION

49 SenderCompID Y

Type: string. OneChronos will assign this identifier as part of customer onboarding. Messages sent to OneChronos must always include Subscriber's assigned SenderCompID.

Validation (from Subscriber): valid_comp_id_for_session: true

Value (to Subscriber): get(session, :gateway_comp_id)

52 SendingTime Y

Type: utctimestamp. The time of message transmission (always in UTC). OneChronos supports UTC timestamps at second, millisecond, or microsecond precision.

Validation (from Subscriber): acceptable_clock_drift: true

Value (to Subscriber): sending_time()

56 TargetCompID Y

Type: string. The logical mirror of SenderCompID. Messages received from OneChronos will always have this field set to the SenderCompID assigned to you by us.

Validation (from Subscriber): value: { is: :gateway_comp_id }

Value (to Subscriber): get(session, :counterparty_comp_id)

97 PossResend N

Type: boolean. A flag indicating whether a message is a possible business level retransmission, per the message delivery rules. For messages sent to OneChronos, any value other than 'N' will trigger a rejection. OneChronos will never populate this field.

Enum values:
  • POSSIBLE_DUPLICATE: Y
    Message is a possible retransmission.
  • ORIGINAL_TRANSMISSION: N
    Message is guaranteed to be an original transmission.

Validation (from Subscriber): value: { is: 'N' }

115 OnBehalfOfCompID C

Type: string. Identifies the "end client" of a message sent by Subscriber to OneChronos. Messages from OneChronos will never populate this field. Service bureaus must populate this field with a valid NSCC MPID.

Directional: From Subscriber

Required when: is_service_bureau: true

Validation (from Subscriber): valid_mpid: true

116 OnBehalfOfSubID N

Type: string. A sub-identifier used in conjunction with OnBehalfOfCompID.

Directional: From Subscriber

Validation (from Subscriber): format: { with: /^[a-zA-Z0-9]{4,4}$/ }

122 OrigSendingTime N

Type: utctimestamp. Required by the FIX spec for orders where PossDupFlag=Y.

128 DeliverToCompID C

Type: string. When a Subscriber populates OnBehalfOfCompId, any message sent in response by OneChronos will populate this field with the value of OnBehalfOfCompId specified by Subscriber.

Directional: To Subscriber

Required when: get(parent, :on_behalf_of_comp_id)

Value (to Subscriber): get(parent, :on_behalf_of_comp_id)

129 DeliverToSubID C

Type: string. When a Subscriber populates OnBehalfOfSubID, any message sent in response by OneChronos will populate this field with the value of OnBehalfOfSubID specified by Subscriber.

Directional: To Subscriber

Required when: get(parent, :on_behalf_of_sub_id)

Value (to Subscriber): get(parent, :on_behalf_of_sub_id)

Standard Trailer

The "Standard Trailer" is included at the end of every FIX message. CheckSum must appear as the last field.

Tag Name Required? Description
10 CheckSum Y

Type: int. A message checksum per the checksum calculation instructions.

Validation (from Subscriber): fix_checksum_valid: true

Value (to Subscriber): fix_checksum(self)

Administrative Messages

Heartbeat (0)

Heartbeat messages should be sent whenever the HeartBtInt agreed to via login procedures has elapsed without another another message being sent. See the section on bidirectional heartbeats for additional information.

Tag Name Required? Description
112 TestReqID C

Type: string. Must be present if sent in response to a TestRequest message.

Required when: get(parent, :test_req_id)

Validation (from Subscriber): format: { with: /^(?!.*[,;|])[\x21-\x7E]{1,255}$/ }

Value (to Subscriber): get(parent, :test_req_id)

TestRequest (1)

TestRequest messages are used to explicitly request a Heartbeat from the counterparty when none is received. Applications should send a TestRequest whenever the agreed upon heartbeat interval plus one second (HeartBtInt+1) has elapsed without the receipt of a message, Heartbeat or otherwise. If a Heartbeat is not received promptly thereafter, the FIX session should be disconnected on the network level without attempting to send another message. Logon and message recovery procedures can proceed thereafter. A TestRequest can be sent by Subscriber to OneChronos, or by OneChronos to Subscriber.

Tag Name Required? Description
112 TestReqID Y

Type: string. An identifier for use with TestRequest and Heartbeat messages.

Validation (from Subscriber): format: { with: /^(?!.*[,;|])[\x21-\x7E]{1,255}$/ }

Value (to Subscriber): test_request_id(session)

ResendRequest (2)

Request that one or more messages be retransmitted, per the procedures outlined in the section on FIX message Recovery. A ResendRequest can be sent by Subscriber to OneChronos, or by OneChronos to Subscriber.

Tag Name Required? Description
7 BeginSeqNo Y

Type: int. Message sequence number of first message in range to be resent.

Validation (from Subscriber): value: { in: 1..outbound_sequence(session) }

Value (to Subscriber): inbound_sequence(session)+1

16 EndSeqNo Y

Type: int. Message sequence number of last message in range to be resent. If request is for a single message BeginSeqNo = EndSeqNo. If request is for all messages subsequent to a particular message, EndSeqNo = "0" (representing infinity).

Validation (from Subscriber): value: { in: 1..outbound_sequence(session) }; value: { greater_than_or_equal_to: get(self, :begin_seq_no) }, if: { get(self, :end_seq_no) != 0 }

Value (to Subscriber): get(parent, :msg_seq_num)-1

Reject (3)

Reject messages are used by OneChronos to indicate that a message received from Subscriber is invalid on the session level. Whereas business level rejections via ExecutionReport-BusinessReject are typical, Reject messages should not received outside of FIX certification. Transmitting additional messages without further investigation is not recommended.

Tag Name Required? Description
45 RefSeqNum Y

Type: int. The sequence number of the message being referenced.

Value: get(parent, :msg_seq_num)

58 Text N

Type: string. Free form text. Subscribers can populate this field for internal use; OneChronos may populate this field to provide additional context to Subscriber when sending a rejection.

371 RefTagID C

Type: int. Always present when the rejection was triggered by a specific tag. If multiple tags are invalid, RefTagID will be populated for the first invalid tag.

Required when: get(validator(parent), :ref_tag_id)

Value: get(validator(parent), :ref_tag_id)

372 RefMsgType C

Type: string. Always present when MsgType is parsable on the message being rejected.

Required when: get(validator(parent), :ref_msg_type)

Value: get(validator(parent), :ref_msg_type)

373 SessionRejectReason Y

Type: int. An error code indicating why a message was rejected on the session level.

Enum values:
  • INVALID_TAG_NUMBER: 0
    One or more tag numbers fall outside of the legal tag range [1, 39999].
  • REQUIRED_TAG_MISSING: 1
    A required tag is missing.
  • TAG NOT DEFINED FOR THIS MESSAGE TYPE: 2
    A tag that is valid for some message types but invalid for the given message type was present.
  • UNDEFINED_TAG: 3
    An unknown tag was included in the message.
  • TAG_SPECIFIED_WITHOUT_A_VALUE: 4
    A tag was present without a value.
  • VALUE_IS_INCORRECT: 5
    The referenced value is of the correct data type, but invalid.
  • INCORRECT DATA FORMAT FOR VALUE: 6
    The referenced value does not have the correct data type.
  • COMPID_PROBLEM: 9
    Either the SenderCompID, TargetCompID, OnBehalfOfCompID, or OnBehalfOfSubID is invalid.
  • SENDINGTIME_ACCURACY_PROBLEM: 10
    The differential between SendingTime and message receipt by OneChronos is too large.
  • INVALID_MESSAGE_TYPE: 11
    The message specifies a MsgType outside of the OneChronos FIX specification.

Value: get(validator(parent), :session_reject_reason)

SequenceReset (4)

Used by the sending application to modify the incoming sequence number of the application facing the sender. Further details are available in the section on Sequence Resets.

Tag Name Required? Description
36 NewSeqNo Y

Type: int. The next expected sequence number, per the rules governing message sequence numbers.

Validation (from Subscriber): value: { greater_than: 0 }

123 GapFillFlag N

Type: boolean. Indicates whether a SequenceReset is of type SequenceReset-Gap-Fill or SequenceReset-Reset. See Message Delivery for additional details.

Enum values:
  • GAP FILL MESSAGE MSGSEQNUM FIELD VALID: Y
    Message is a SequenceReset-Gap-Fill; this is the correct value to use for message recovery/non disaster situations.
  • SEQUENCE RESET IGNORE MSGSEQNUM: N
    Message is a SequenceReset-Reset; reset the counterparty's sequence expected incoming sequence number, without performing message recovery.

Logout (5)

Logout messages are used to initiate or acknowledge the orderly termination of a FIX session. Subscribers can initiate a logout at will. Under normal operating conditions OneChronos will only initiate a logout as part of the daily sequence number reset. See Logout for additional information.

Tag Name Required? Description
58 Text N

Type: string. Free form text. Subscribers can populate this field for internal use; OneChronos may populate this field to provide additional context to Subscriber when sending a rejection.

Logon (A)

Clients must send a Logon message to OneChronos immediately after establishing a TCP connection, and before sending any other messages. If the Logon request is valid, OneChronos will reply with a reciprocal Logon and wait one second before sending additional messages to ensure that no ResendRequest messages from Subscriber are in-flight. Clients should not send any business messages during this one second period. After the synchronization period has elapsed, OneChronos will send a Heartbeat to indicate that the waiting period has ended. See the section on Login Procedures for additional information.

Tag Name Required? Description
98 EncryptMethod Y

Type: int. An enum value representing the type of Layer 6 encryption that should be used for the FIX dialogue. Required by the FIX standard, but not used by OneChronos.

Enum values:
  • NONE: 0
    Do not use encryption.

Validation (from Subscriber): value: { is: EncryptMethod.NONE }

Value (to Subscriber): EncryptMethod.NONE

108 HeartBtInt Y

Type: int. The desired interval, in seconds, between heartbeats. See Heartbeats for additional details.

Validation (from Subscriber): value: { in: 5..180 }

Value (to Subscriber): get(parent, :heart_bt_int)

From Subscriber

NewOrderSingle (D)

NewOrderSingle messages are sent by Subscriber to OneChronos to initiate a new order. OneChronos supports OrdType=MARKET, OrdType=LIMIT, and OrdType=PEGGED orders. Any NewOrderSingle message sent with OrdType=PEGGED is treated as a Computational Order. See the section on Order Types for details on the matching mechanism and Computational Order usage. See Transactional Processing for documentation on how transaction blocks can be used for atomic (all or nothing) message processing across multiple NewOrderSingle and/or OrderCancelRequest messages.

Tag Name Required? Description
1 Account N

Type: string. A client supplied account identifier.

Validation: format: { with: /^(?!.*[,;|])[\x21-\x7E]{1,255}$/ }

11 ClOrdID Y

Type: string. A Subscriber provided order ID satisfying the requirements for Subscriber provided IDs.

Validation: format: { with: /^(?!.*[,;|])[\x21-\x7E]{1,255}$/ }

18 ExecInst N

Type: multi_value_string. Order handling instructions; multiple instructions can be specified in a space delimited list.

Enum values:
  • COMPUTATIONAL_ORDER: c
    Execute via Computational Order. See the section on Computational Orders for additional details.
  • DISALLOW_ISO: n
    Do not participate in any auction that will utilize an ISO sweep to clear outside of the NBBO.
21 HandlInst Y

Type: char. HandlInst is required by FIX, but not used by OneChronos.

Enum values:
  • AUTOMATED EXECUTION ORDER PRIVATE NO BROKER INTERVENTION: 1
    Required by FIX, but not used by OneChronos.
38 OrderQty Y

Type: qty. The number of shares for the order.

Validation: value: { in: 1..get(session, :max_order_quantity) }

40 OrdType Y

Type: char. The type of an order.

Enum values:
  • MARKET: 1
    Order is eligible for execution at the prevailing market price.
  • LIMIT: 2
    Order is eligible for execution at a price equal to or more favorable than Price.
  • PEGGED: P
    Order is eligible for execution at a price equal to or more favorable than a computed price, per the instructions given in ComputationalOrderPayload.
44 Price C

Type: price. The limit price of an order.

Required when: get(self, :ord_type) != OrdType.MARKET

Validation: valid_price_for_order: true, if: get(self, :ord_type) != OrdType.MARKET; absence: true, if: get(self, :ord_type) == OrdType.MARKET

47 Rule80A Y

Type: char. The capacity of an order. For US equities, order capacity is in reference to Rule 80A.

Enum values:
  • AGENCY_SINGLE_ORDER: A
    Broker is executing in an pure agency capacity.
  • PRINCIPAL: P
    Broker is executing as a principal in the transaction.
  • COMPETING_DEALER_TRADES_R: R
    Broker is executing as a riskless principal in the transaction.
54 Side Y

Type: char. The side of an order.

Enum values:
  • BUY: 1
    Order is a buy.
  • SELL: 2
    Order is a long sell.
  • SELL_SHORT: 5
    Order is a short sell.
  • SELL_SHORT_EXEMPT: 6
    Order is a short sell, exempt from restrictions such as Reg 201 in the case of US equities.

Validation: shorts_allowed: true, if: get(self, :side) == Side.SELL_SHORT or get(self, :side) == Side.SELL_SHORT_EXEMPT

55 Symbol Y

Type: string. The symbol (ticker) of the instrument being traded. See Symbology for additional details.

Validation: valid_symbol: true

58 Text N

Type: string. Free form text. Subscribers can populate this field for internal use; OneChronos may populate this field to provide additional context to Subscriber when sending a rejection.

59 TimeInForce Y

Type: char. A field governing how long an order will remain active for.

Enum values:
  • DAY: 0
    Order will remain active throughout the regular trading session.
  • IMMEDIATE_OR_CANCEL: 3
    Order will be canceled after participating in one auction.
  • FILL_OR_KILL: 4
    Order will be canceled unless it can be filled in entirety in one auction; partial fills are not allowed.
  • GOOD_TILL_DATE: 6
    Order will remain active until the time specified by ExpireTime.
60 TransactTime Y

Type: utctimestamp. A UTC timestamp indicating when a transaction occurred. Internally, OneChronos logs events at microsecond or higher precision but disseminates time fields with millisecond precision. Subscribers desiring microsecond precision timestamps can enable them on a port level.

Validation: acceptable_clock_drift: true

65 SymbolSfx N

Type: string. A suffix for the symbol (ticker) being traded, when applicable. See Symbology for additional details.

Validation: valid_symbol_suffix: true

110 MinQty N

Type: qty. The minimum permissible fill quantity for an order.

Validation: value: { in: 1..get(session, :max_order_quantity) }

114 LocateReqd C

Type: boolean. A boolean flag indicating whether a locate is required when selling short. For US equities orders, any order where LocateReqd is absent or set to Y will result in a rejection if Side=SELL_SHORT or Side=SELL_SHORT_EXEMPT.

Required when: get(self, :side) == Side.SELL_SHORT or get(self, :side) == Side.SELL_SHORT_EXEMPT

Enum values:
  • YES: Y
    Broker attests that a locate is required for the name being traded.
  • NO: N
    Broker attests that a locate is not required for the name being traded.

Validation: value: { is: 'N' }

126 ExpireTime C

Type: utctimestamp. When TimeInForce=GOOD_TILL_DATE ExpireTime must be populated with the desired expiry time.

Required when: get(self, :time_in_force) == TimeInForce.GOOD_TILL_DATE

Validation: absence: true, unless: get(self, :time_in_force) == TimeInForce.GOOD_TILL_DATE; in_future: true

20000 TransactionBlockID N

Type: string. A transaction block identifier. See the section on Transactional Processing for additional details.

Validation: format: { with: /^(?!.*[,;|])[\x21-\x7E]{1,255}$/ }

20001 TransactionBlockLength C

Type: int. The number of messages participating in the transaction. See the section on Transactional Processing for additional details.

Required when: get(self, :transaction_block_id)

Validation: length: { in: 1..1000 };

20002 TransactionBlockTimeout N

Type: int. The timeout for the transaction, in milliseconds. See the section on Transactional Processing for additional details.

Validation: value: { in: 100..30000 }

20003 ComputationalOrderPayload C

Type: string. A Base64 encoded smart order payload. See the section on Computational Orders for additional details.

Required when: get(self, :exec_inst) == ExecInst.COMPUTATIONAL_ORDER

Validation: valid_computational_order_payload: true

20004 AnalyticsKey N

Type: string. An optional Subscriber supplied identifier used by OneChronos to subset orders and fills for analytics and reporting. If specified, the rules outlined in the section on Identifiers apply.

Validation: format: { with: /^(?!.*[,;|])[\x21-\x7E]{1,255}$/ }

OrderCancelRequest (F)

Subscribers may request that an order entered via NewOrderSingle be canceled by sending OneChronos an OrderCancelRequest. Provided that the order is eligible for cancellation, OneChronos will do immediately and notify Subscriber via a ExecutionReport-Cancel message.

Tag Name Required? Description
11 ClOrdID Y

Type: string. A Subscriber provided order ID satisfying the requirements for Subscriber provided IDs.

Validation: format: { with: /^(?!.*[,;|])[\x21-\x7E]{1,255}$/ }

38 OrderQty Y

Type: qty. The number of shares for the order.

Validation: value: { is: get(parent, :order_qty) }

41 OrigClOrdID Y

Type: string. The ClOrdID of the original order.

Validation: value: { is: get(parent, :cl_ord_id) }

54 Side Y

Type: char. The side of an order.

Enum values:
  • BUY: 1
    Order is a buy.
  • SELL: 2
    Order is a long sell.
  • SELL_SHORT: 5
    Order is a short sell.
  • SELL_SHORT_EXEMPT: 6
    Order is a short sell, exempt from restrictions such as Reg 201 in the case of US equities.

Validation: value: { is: get(parent, :side) }

55 Symbol Y

Type: string. The symbol (ticker) of the instrument being traded. See Symbology for additional details.

Validation: value: { is: get(parent, :symbol) }

60 TransactTime Y

Type: utctimestamp. A UTC timestamp indicating when a transaction occurred. Internally, OneChronos logs events at microsecond or higher precision but disseminates time fields with millisecond precision. Subscribers desiring microsecond precision timestamps can enable them on a port level.

Validation: acceptable_clock_drift: true

65 SymbolSfx C

Type: string. A suffix for the symbol (ticker) being traded, when applicable. See Symbology for additional details.

Required when: get(parent, :symbol_sfx)

Validation: value: { is: get(parent, :symbol_sfx) }

20000 TransactionBlockID N

Type: string. A transaction block identifier. See the section on Transactional Processing for additional details.

Validation: format: { with: /^(?!.*[,;|])[\x21-\x7E]{1,255}$/ }

20001 TransactionBlockLength C

Type: int. The number of messages participating in the transaction. See the section on Transactional Processing for additional details.

Required when: get(self, :transaction_block_id)

Validation: length: { in: 1..1000 };

20002 TransactionBlockTimeout N

Type: int. The timeout for the transaction, in milliseconds. See the section on Transactional Processing for additional details.

Validation: value: { in: 100..30000 }

20003 ComputationalOrderPayload N

Type: string. A Base64 encoded smart order payload. See the section on Computational Orders for additional details.

Validation: valid_computational_order_payload: true

To Subscriber

ExecutionReport (8)

Execution reports are sent by OneChronos to Subscriber to acknowledge order entry and cancellation, communicate fills (both partial and complete), and notify Subscriber when the state of an order changes due to venue or order specific lifecycle events. The following fields are common to all execution reports. Order state specific reports contain additional fields, as indicated below this section.

Tag Name Required? Description
1 Account C

Type: string. A client supplied account identifier.

Required when: get(parent, :account)

Value: get(parent, :account)

6 AvgPx Y

Type: price. An average price computed across all fills for an order.

Value: average_price(parent)

11 ClOrdID Y

Type: string. A Subscriber provided order ID satisfying the requirements for Subscriber provided IDs.

Value: get(parent, :cl_ord_id)

14 CumQty Y

Type: qty. The aggregate filled quantity computed across all fills for an order.

Value: cum_quantity(parent)

17 ExecID Y

Type: string. A unique ID for each execution report sent from OneChronos to Subscriber.

Value: get(parent, :compute_exec_id)

18 ExecInst C

Type: multi_value_string. Order handling instructions; multiple instructions can be specified in a space delimited list.

Required when: get(parent, :exec_inst)

Enum values:
  • COMPUTATIONAL_ORDER: c
    Execute via Computational Order. See the section on Computational Orders for additional details.
  • DISALLOW_ISO: n
    Do not participate in any auction that will utilize an ISO sweep to clear outside of the NBBO.

Value: get(parent, :exec_inst)

20 ExecTransType Y

Type: char. Identifies the type of a transaction.

Enum values:
  • NEW: 0
    A new execution report.
  • CANCEL: 1
    Cancellation of a previously sent execution report.
  • CORRECT: 2
    Correction of a previously sent execution report.
  • STATUS: 3
    A replay of a previously transmitted execution report.

Value: get(self, :exec_trans_type)

21 HandlInst Y

Type: char. HandlInst is required by FIX, but not used by OneChronos.

Enum values:
  • AUTOMATED EXECUTION ORDER PRIVATE NO BROKER INTERVENTION: 1
    Required by FIX, but not used by OneChronos.

Value: HandlInst.AUTOMATED EXECUTION ORDER PRIVATE NO BROKER INTERVENTION

37 OrderID Y

Type: string. An identifier assigned by OneChronos to all orders entered via NewOrderSingle.

Value: get(parent, :compute_order_id)

38 OrderQty Y

Type: qty. The number of shares for the order.

Value: get(parent, :order_qty)

39 OrdStatus Y

Type: char. The state of the order. State transitions are governed per the FIX order state transition rules.

Enum values:
  • NEW: 0
    Order is acknowledged.
  • PARTIALLY_FILLED: 1
    Order is partially filled.
  • FILLED: 2
    Order is fully filled.
  • DONE_FOR_DAY: 3
    Order is done and will not receive any further fills.
  • CANCELED: 4
    Order was successfully canceled.
  • PENDING_CANCEL: 6
    Order is awaiting Cancellation.
  • REJECTED: 8
    Order was rejected.

Value: order_status(parent)

40 OrdType Y

Type: char. The type of an order.

Enum values:
  • MARKET: 1
    Order is eligible for execution at the prevailing market price.
  • LIMIT: 2
    Order is eligible for execution at a price equal to or more favorable than Price.
  • PEGGED: P
    Order is eligible for execution at a price equal to or more favorable than a computed price, per the instructions given in ComputationalOrderPayload.

Value: get(parent, :ord_type)

44 Price C

Type: price. The limit price of an order.

Required when: get(parent, :price)

Value: get(parent, :price)

47 Rule80A Y

Type: char. The capacity of an order. For US equities, order capacity is in reference to Rule 80A.

Enum values:
  • AGENCY_SINGLE_ORDER: A
    Broker is executing in an pure agency capacity.
  • PRINCIPAL: P
    Broker is executing as a principal in the transaction.
  • COMPETING_DEALER_TRADES_R: R
    Broker is executing as a riskless principal in the transaction.

Value: get(parent, :rule_80a)

54 Side Y

Type: char. The side of an order.

Enum values:
  • BUY: 1
    Order is a buy.
  • SELL: 2
    Order is a long sell.
  • SELL_SHORT: 5
    Order is a short sell.
  • SELL_SHORT_EXEMPT: 6
    Order is a short sell, exempt from restrictions such as Reg 201 in the case of US equities.

Value: get(parent, :side)

55 Symbol Y

Type: string. The symbol (ticker) of the instrument being traded. See Symbology for additional details.

Value: get(parent, :symbol)

58 Text N

Type: string. OneChronos may populate this field to assist Subscriber with troubleshooting when issuing an ExecutionReport-Reject for atypical reasons.

59 TimeInForce Y

Type: char. A field governing how long an order will remain active for.

Enum values:
  • DAY: 0
    Order will remain active throughout the regular trading session.
  • IMMEDIATE_OR_CANCEL: 3
    Order will be canceled after participating in one auction.
  • FILL_OR_KILL: 4
    Order will be canceled unless it can be filled in entirety in one auction; partial fills are not allowed.
  • GOOD_TILL_DATE: 6
    Order will remain active until the time specified by ExpireTime.

Value: get(parent, :time_in_force)

60 TransactTime Y

Type: utctimestamp. A UTC timestamp indicating when a transaction occurred. Internally, OneChronos logs events at microsecond or higher precision but disseminates time fields with millisecond precision. Subscribers desiring microsecond precision timestamps can enable them on a port level.

Value: get(session, :transact_time)

65 SymbolSfx C

Type: string. A suffix for the symbol (ticker) being traded, when applicable. See Symbology for additional details.

Required when: get(parent, :symbol_sfx)

Value: get(parent, :symbol_sfx)

110 MinQty C

Type: qty. The minimum permissible fill quantity for an order.

Required when: get(parent, :min_qty)

Value: get(parent, :min_qty)

126 ExpireTime C

Type: utctimestamp. When TimeInForce=GOOD_TILL_DATE ExpireTime must be populated with the desired expiry time.

Required when: get(parent, :expire_time)

Value: get(parent, :expire_time)

150 ExecType Y

Type: char. The type of an ExecutionReport. See the section on FIX order state transitions for additional details.

Enum values:
  • NEW: 0
    Report is an ExecutionReport-Acknowledgement.
  • PARTIAL_FILL: 1
    Report is an ExecutionReport-PartialFill.
  • FILL: 2
    Report is an ExecutionReport-Fill.
  • DONE_FOR_DAY: 3
    Report is an ExecutionReport-DoneForDay.
  • CANCELED: 4
    Execution report is an ExecutionReport-Cancel or ExecutionReport-UnsolicitedCancel.
  • PENDING_CANCEL: 6
    Execution report is an ExecutionReport-PendingCancel.
  • REJECTED: 8
    Execution report is an ExecutionReport-BusinessReject.

Value: get(self, :exec_type)

151 LeavesQty Y

Type: qty. The remaining (unfilled) quantity of an order open for additional fills. If OrdStatus is CANCELED, DONE_FOR_DAY, or REJECTED, LeavesQty=0. Otherwise, LeavesQty=OrderQty - CumQty.

Value: leaves_quantity(parent)

OrderCancelReject (9)

OrderCancelRequest messages are sent from OneChronos to Subscriber in response to OrderCancelRequest messages that are invalid on a business logic level, or that reference orders in a non-cancelable state.

Tag Name Required? Description
1 Account C

Type: string. A client supplied account identifier.

Required when: let order = find_order(session, get(parent, :orig_cl_ord_id)); order && get(order, :account)

Value: get(find_order(session, get(parent, :orig_cl_ord_id)), :account)

11 ClOrdID Y

Type: string. A Subscriber provided order ID satisfying the requirements for Subscriber provided IDs.

Value: get(parent, :cl_ord_id)

37 OrderID Y

Type: string. An identifier assigned by OneChronos to all orders entered via NewOrderSingle.

Value: let order = find_order(session, get(parent, :orig_cl_ord_id)); order ? get(order, :order_id) : 'NONE'

39 OrdStatus Y

Type: char. The state of the order. State transitions are governed per the FIX order state transition rules.

Enum values:
  • NEW: 0
    Order is acknowledged.
  • PARTIALLY_FILLED: 1
    Order is partially filled.
  • FILLED: 2
    Order is fully filled.
  • DONE_FOR_DAY: 3
    Order is done and will not receive any further fills.
  • CANCELED: 4
    Order was successfully canceled.
  • PENDING_CANCEL: 6
    Order is awaiting Cancellation.
  • REJECTED: 8
    Order was rejected.

Value: let order = find_order(session, get(parent, :orig_cl_ord_id)); order ? order_status(order) : OrdStatus.REJECTED

41 OrigClOrdID Y

Type: string. The ClOrdID of the original order.

Value: get(parent, :orig_cl_ord_id)

58 Text N

Type: string. Free form text. Subscribers can populate this field for internal use; OneChronos may populate this field to provide additional context to Subscriber when sending a rejection.

102 CxlRejReason Y

Type: int. An error code indicating why a OrderCancelRequest (MsgType=ORDER_CANCEL_REQUEST) was rejected.

Enum values:
  • TOO_LATE_TO_CANCEL: 0
    Cancellation request received after order was filled in entirety.
  • UNKNOWN_ORDER: 1
    The ClOrdID referenced in the OrderCancelRequest is unknown.
  • ALREADY_PENDING: 3
    A cancellation request was already received for the order referenced.

Value: cancel_reject_reason(parent)

434 CxlRejResponseTo Y

Type: char. Indicates the type of order cancel request that a OrderCancelReject is in response to. Given that OneChronos only supports OrderCancelRequest (MsgType=ORDER_CANCEL_REQUEST), CxlRejResponseTo will always be 'F'.

Value: F

TradeCancelCorrect (UCC)

TradeCancelCorrect messages are sent to Subscriber to report trade breaks (cancellations or corrections of a previous execution). This is a non-standard message that must be enabled on the port level. For corrections (ExecTransType=CORRECT), only the price (as indicated by CorrectedPrice) can change. ExecTransType=CANCEL indicates a full trade break.

Tag Name Required? Description
11 ClOrdID Y

Type: string. A Subscriber provided order ID satisfying the requirements for Subscriber provided IDs.

Value: get(parent, :cl_ord_id)

17 ExecID Y

Type: string. A unique ID for each execution report sent from OneChronos to Subscriber.

Value: get(parent, :compute_exec_id)

19 ExecRefID Y

Type: string. A reference to the original ExecID used for messages where ExecTransType=CANCEL or ExecTransType=CORRECT.

Value: get(parent, :exec_id)

20 ExecTransType Y

Type: char. Identifies the type of a transaction.

Enum values:
  • NEW: 0
    A new execution report.
  • CANCEL: 1
    Cancellation of a previously sent execution report.
  • CORRECT: 2
    Correction of a previously sent execution report.
  • STATUS: 3
    A replay of a previously transmitted execution report.
31 LastPx Y

Type: price. The price of the last fill.

Value: get(parent, :last_px)

32 LastShares Y

Type: qty. The quantity of the last fill.

Value: get(parent, :last_shares)

37 OrderID Y

Type: string. An identifier assigned by OneChronos to all orders entered via NewOrderSingle.

Value: get(parent, :compute_order_id)

42 OrigTime Y

Type: utctimestamp. The original sending time of an ExecutionReport.

Value: get(parent, :sending_time)

54 Side Y

Type: char. The side of an order.

Enum values:
  • BUY: 1
    Order is a buy.
  • SELL: 2
    Order is a long sell.
  • SELL_SHORT: 5
    Order is a short sell.
  • SELL_SHORT_EXEMPT: 6
    Order is a short sell, exempt from restrictions such as Reg 201 in the case of US equities.

Value: get(parent, :side)

55 Symbol Y

Type: string. The symbol (ticker) of the instrument being traded. See Symbology for additional details.

Value: get(parent, :symbol)

60 TransactTime Y

Type: utctimestamp. A UTC timestamp indicating when a transaction occurred. Internally, OneChronos logs events at microsecond or higher precision but disseminates time fields with millisecond precision. Subscribers desiring microsecond precision timestamps can enable them on a port level.

Value: get(session, :transact_time)

65 SymbolSfx C

Type: string. A suffix for the symbol (ticker) being traded, when applicable. See Symbology for additional details.

Required when: get(parent, :symbol_sfx)

Value: get(parent, :symbol_sfx)

9620 CorrectedPrice C

Type: price. The corrected price of a trade.

Required when: get(self, :exec_trans_type) == ExecTransType.CORRECT

Value: get(parent, :corrected_price)

ExecutionReport Specializations

ExecutionReport is used for many purposes, such as conveying the acceptance of an order or communicating fills to Subscriber. The ExecutionReport types sent by OneChronos are enumerated below. The rules that OneChronos uses to compute OrdStatus are strictly compliant with FIX, and outlined as a state transition matrix in the section on Order States

Acknowledgement (8)

ExecutionReport-Acknowledgement is sent to indicate the receipt and acceptance of an order entered by Subscriber via NewOrderSingle.

Tag Name Required? Description
20 ExecTransType Y

Type: char. Identifies the type of a transaction.

Enum values:
  • NEW: 0
    A new execution report.
  • CANCEL: 1
    Cancellation of a previously sent execution report.
  • CORRECT: 2
    Correction of a previously sent execution report.
  • STATUS: 3
    A replay of a previously transmitted execution report.

Value: NEW

150 ExecType Y

Type: char. The type of an ExecutionReport. See the section on FIX order state transitions for additional details.

Enum values:
  • NEW: 0
    Report is an ExecutionReport-Acknowledgement.
  • PARTIAL_FILL: 1
    Report is an ExecutionReport-PartialFill.
  • FILL: 2
    Report is an ExecutionReport-Fill.
  • DONE_FOR_DAY: 3
    Report is an ExecutionReport-DoneForDay.
  • CANCELED: 4
    Execution report is an ExecutionReport-Cancel or ExecutionReport-UnsolicitedCancel.
  • PENDING_CANCEL: 6
    Execution report is an ExecutionReport-PendingCancel.
  • REJECTED: 8
    Execution report is an ExecutionReport-BusinessReject.

Value: NEW

151 LeavesQty Y

Type: qty. The remaining (unfilled) quantity of an order open for additional fills. If OrdStatus is CANCELED, DONE_FOR_DAY, or REJECTED, LeavesQty=0. Otherwise, LeavesQty=OrderQty - CumQty.

Value: get(parent, :order_qty)

PartialFill (8)

ExecutionReport-PartialFill messages are sent whenever an order is partially (but not completely) filled upon the conclusion of an auction. If LeavesQty = 0, ExecutionReport-Fill will be sent instead.

Tag Name Required? Description
20 ExecTransType Y

Type: char. Identifies the type of a transaction.

Enum values:
  • NEW: 0
    A new execution report.
  • CANCEL: 1
    Cancellation of a previously sent execution report.
  • CORRECT: 2
    Correction of a previously sent execution report.
  • STATUS: 3
    A replay of a previously transmitted execution report.

Value: NEW

30 LastMkt C

Type: exchange. The market of the last fill; always CGX.

Required when: get(self, :exec_trans_type) != ExecTransType.STATUS

Value: CGX

31 LastPx C

Type: price. The price of the last fill.

Required when: get(self, :exec_trans_type) != ExecTransType.STATUS

Value: get(parent, :last_px)

32 LastShares C

Type: qty. The quantity of the last fill.

Required when: get(self, :exec_trans_type) != ExecTransType.STATUS

Value: get(parent, :last_shares)

150 ExecType Y

Type: char. The type of an ExecutionReport. See the section on FIX order state transitions for additional details.

Enum values:
  • NEW: 0
    Report is an ExecutionReport-Acknowledgement.
  • PARTIAL_FILL: 1
    Report is an ExecutionReport-PartialFill.
  • FILL: 2
    Report is an ExecutionReport-Fill.
  • DONE_FOR_DAY: 3
    Report is an ExecutionReport-DoneForDay.
  • CANCELED: 4
    Execution report is an ExecutionReport-Cancel or ExecutionReport-UnsolicitedCancel.
  • PENDING_CANCEL: 6
    Execution report is an ExecutionReport-PendingCancel.
  • REJECTED: 8
    Execution report is an ExecutionReport-BusinessReject.

Value: PARTIAL_FILL

151 LeavesQty Y

Type: qty. The remaining (unfilled) quantity of an order open for additional fills. If OrdStatus is CANCELED, DONE_FOR_DAY, or REJECTED, LeavesQty=0. Otherwise, LeavesQty=OrderQty - CumQty.

Value: get(parent, :order_qty) - get(parent, :cum_qty)

375 ContraBroker C

Type: string. Identifies the contra broker for a transaction.

Required when: get(self, :exec_trans_type) != STATUS

Value: CRON

382 NoContraBrokers C

Type: int. The number of ContraBroker fields contained in the message.

Required when: get(self, :exec_trans_type) != STATUS

Value: 1

20005 AuctionID C

Type: int. A unique identifier assigned by OneChronos to each auction.

Required when: get(self, :exec_trans_type) != STATUS

Value: auction_id()

20006 AuctionSubID C

Type: int. A unique identifier assigned by OneChronos to each atomic symbol within a given auction. Any given AuctionID can have zero or more values of AuctionSubID associated with it.

Required when: get(self, :exec_trans_type) != STATUS

Value: auction_sub_id(get(parent, :symbol), get(parent, :symbol_sfx))

Fill (8)

ExecutionReport-Fill messages are sent whenever an order is filled in entirety upon the conclusion of an auction. If LeavesQty > 0, ExecutionReport-PartialFill will be sent instead.

Tag Name Required? Description
20 ExecTransType Y

Type: char. Identifies the type of a transaction.

Enum values:
  • NEW: 0
    A new execution report.
  • CANCEL: 1
    Cancellation of a previously sent execution report.
  • CORRECT: 2
    Correction of a previously sent execution report.
  • STATUS: 3
    A replay of a previously transmitted execution report.

Value: NEW

30 LastMkt C

Type: exchange. The market of the last fill; always CGX.

Required when: get(self, :exec_trans_type) != STATUS

Value: CGX

31 LastPx C

Type: price. The price of the last fill.

Required when: get(self, :exec_trans_type) != ExecTransType.STATUS

Value: get(parent, :last_px)

32 LastShares C

Type: qty. The quantity of the last fill.

Required when: get(self, :exec_trans_type) != ExecTransType.STATUS

Value: get(parent, :last_shares)

150 ExecType Y

Type: char. The type of an ExecutionReport. See the section on FIX order state transitions for additional details.

Enum values:
  • NEW: 0
    Report is an ExecutionReport-Acknowledgement.
  • PARTIAL_FILL: 1
    Report is an ExecutionReport-PartialFill.
  • FILL: 2
    Report is an ExecutionReport-Fill.
  • DONE_FOR_DAY: 3
    Report is an ExecutionReport-DoneForDay.
  • CANCELED: 4
    Execution report is an ExecutionReport-Cancel or ExecutionReport-UnsolicitedCancel.
  • PENDING_CANCEL: 6
    Execution report is an ExecutionReport-PendingCancel.
  • REJECTED: 8
    Execution report is an ExecutionReport-BusinessReject.

Value: FILL

151 LeavesQty Y

Type: qty. The remaining (unfilled) quantity of an order open for additional fills. If OrdStatus is CANCELED, DONE_FOR_DAY, or REJECTED, LeavesQty=0. Otherwise, LeavesQty=OrderQty - CumQty.

Value: 0

375 ContraBroker C

Type: string. Identifies the contra broker for a transaction.

Required when: get(self, :exec_trans_type) != STATUS

Value: CRON

382 NoContraBrokers C

Type: int. The number of ContraBroker fields contained in the message.

Required when: get(self, :exec_trans_type) != STATUS

Value: 1

20005 AuctionID C

Type: int. A unique identifier assigned by OneChronos to each auction.

Required when: get(self, :exec_trans_type) != STATUS

Value: auction_id()

20006 AuctionSubID C

Type: int. A unique identifier assigned by OneChronos to each atomic symbol within a given auction. Any given AuctionID can have zero or more values of AuctionSubID associated with it.

Required when: get(self, :exec_trans_type) != STATUS

Value: auction_sub_id(get(parent, :symbol), get(parent, :symbol_sfx))

Cancel (8)

ExecutionReport-Cancel messages are used to acknowledge the receipt and acceptance of a cancellation request initiated by Subscriber via OrderCancelRequest. If the cancellation was initiated by a Computational Order, time in force/fill or kill/immediate or cancel instructions, or market events, ExecutionReport-UnsolicitedCancel is sent instead. ExecutionReport-Cancel will have ClOrdID set to the ClOrdID of the OrderCancelRequest and OrigClOrdID set to the ClOrdID of the order being canceled. Note that ExecutionReport-Cancel is sent in response to OrderCancelRequest. Thus, parent in the context below is a reference to the OrderCancelRequest, and not the original order.

Tag Name Required? Description
20 ExecTransType Y

Type: char. Identifies the type of a transaction.

Enum values:
  • NEW: 0
    A new execution report.
  • CANCEL: 1
    Cancellation of a previously sent execution report.
  • CORRECT: 2
    Correction of a previously sent execution report.
  • STATUS: 3
    A replay of a previously transmitted execution report.

Value: NEW

31 LastPx Y

Type: price. The price of the last fill.

Value: 0

32 LastShares Y

Type: qty. The quantity of the last fill.

Value: 0

41 OrigClOrdID Y

Type: string. The ClOrdID of the original order.

Value: get(find_order(session, get(parent, :orig_cl_ord_id)), :cl_ord_id)

150 ExecType Y

Type: char. The type of an ExecutionReport. See the section on FIX order state transitions for additional details.

Enum values:
  • NEW: 0
    Report is an ExecutionReport-Acknowledgement.
  • PARTIAL_FILL: 1
    Report is an ExecutionReport-PartialFill.
  • FILL: 2
    Report is an ExecutionReport-Fill.
  • DONE_FOR_DAY: 3
    Report is an ExecutionReport-DoneForDay.
  • CANCELED: 4
    Execution report is an ExecutionReport-Cancel or ExecutionReport-UnsolicitedCancel.
  • PENDING_CANCEL: 6
    Execution report is an ExecutionReport-PendingCancel.
  • REJECTED: 8
    Execution report is an ExecutionReport-BusinessReject.

Value: CANCEL

151 LeavesQty Y

Type: qty. The remaining (unfilled) quantity of an order open for additional fills. If OrdStatus is CANCELED, DONE_FOR_DAY, or REJECTED, LeavesQty=0. Otherwise, LeavesQty=OrderQty - CumQty.

Value: 0

UnsolicitedCancel (8)

ExecutionReport-UnsolicitedCancel are used to indicate that an order was canceled due to actions taken by a Computational Order, enforcement of time in force/fill or kill/immediate or cancel instructions, or a market/FIX session event (e.g. trading halts if Cancel-on-Halt is configured). If the cancellation was Subscriber initiated via OrderCancelRequest, an ExecutionReport-Cancel is sent instead. Unlike ExecutionReport-Cancel, ExecutionReport-UnsolicitedCancel will have ClOrdID set to the ClOrdID of the original order; OrigClOrdID is not set.

Tag Name Required? Description
20 ExecTransType Y

Type: char. Identifies the type of a transaction.

Enum values:
  • NEW: 0
    A new execution report.
  • CANCEL: 1
    Cancellation of a previously sent execution report.
  • CORRECT: 2
    Correction of a previously sent execution report.
  • STATUS: 3
    A replay of a previously transmitted execution report.

Value: NEW

31 LastPx Y

Type: price. The price of the last fill.

Value: 0

32 LastShares Y

Type: qty. The quantity of the last fill.

Value: 0

150 ExecType Y

Type: char. The type of an ExecutionReport. See the section on FIX order state transitions for additional details.

Enum values:
  • NEW: 0
    Report is an ExecutionReport-Acknowledgement.
  • PARTIAL_FILL: 1
    Report is an ExecutionReport-PartialFill.
  • FILL: 2
    Report is an ExecutionReport-Fill.
  • DONE_FOR_DAY: 3
    Report is an ExecutionReport-DoneForDay.
  • CANCELED: 4
    Execution report is an ExecutionReport-Cancel or ExecutionReport-UnsolicitedCancel.
  • PENDING_CANCEL: 6
    Execution report is an ExecutionReport-PendingCancel.
  • REJECTED: 8
    Execution report is an ExecutionReport-BusinessReject.

Value: CANCEL

151 LeavesQty Y

Type: qty. The remaining (unfilled) quantity of an order open for additional fills. If OrdStatus is CANCELED, DONE_FOR_DAY, or REJECTED, LeavesQty=0. Otherwise, LeavesQty=OrderQty - CumQty.

Value: 0

PendingCancel (8)

ExecutionReport-PendingCancel messages are used to indicate that an OrderCancelRequest has been received, but has not yet been processed. These messages are only sent when a valid OrderCancelRequest is received during an auction. In such cases OneChronos will wait until the conclusion of the auction before responding with one of the following message sequences, depending on the outcome of the auction: (ExecutionReport-Cancel), (ExecutionReport-PartialFill, ExecutionReport-Cancel), or (ExecutionReport-Fill, OrderCancelReject). Outside of the auction window, valid OrderCancelRequest messages will always receive an immediate ExecutionReport-Cancel. Invalid requests receive an immediate OrderCancelReject irrespective of when they are received.

Tag Name Required? Description
20 ExecTransType Y

Type: char. Identifies the type of a transaction.

Enum values:
  • NEW: 0
    A new execution report.
  • CANCEL: 1
    Cancellation of a previously sent execution report.
  • CORRECT: 2
    Correction of a previously sent execution report.
  • STATUS: 3
    A replay of a previously transmitted execution report.

Value: NEW

31 LastPx Y

Type: price. The price of the last fill.

Value: 0

32 LastShares Y

Type: qty. The quantity of the last fill.

Value: 0

41 OrigClOrdID Y

Type: string. The ClOrdID of the original order.

Value: get(parent, :cl_ord_id)

150 ExecType Y

Type: char. The type of an ExecutionReport. See the section on FIX order state transitions for additional details.

Enum values:
  • NEW: 0
    Report is an ExecutionReport-Acknowledgement.
  • PARTIAL_FILL: 1
    Report is an ExecutionReport-PartialFill.
  • FILL: 2
    Report is an ExecutionReport-Fill.
  • DONE_FOR_DAY: 3
    Report is an ExecutionReport-DoneForDay.
  • CANCELED: 4
    Execution report is an ExecutionReport-Cancel or ExecutionReport-UnsolicitedCancel.
  • PENDING_CANCEL: 6
    Execution report is an ExecutionReport-PendingCancel.
  • REJECTED: 8
    Execution report is an ExecutionReport-BusinessReject.

Value: PENDING_CANCEL

151 LeavesQty Y

Type: qty. The remaining (unfilled) quantity of an order open for additional fills. If OrdStatus is CANCELED, DONE_FOR_DAY, or REJECTED, LeavesQty=0. Otherwise, LeavesQty=OrderQty - CumQty.

Value: get(parent, :order_qty) - get(parent, :cum_qty)

DoneForDay (8)

ExecutionReport-DoneForDay messages indicate that an order has expired due to time in force constraints or actions taken by a Computational Order. OrdStatus=DONE_FOR_DAY is a terminal state; no additional executions are possible for the referenced order. Users can configure (at the port level) whether combinatorial leg elimination is communicated via ExecutionReport-UnsolicitedCancel or ExecutionReport-DoneForDay.

Tag Name Required? Description
20 ExecTransType Y

Type: char. Identifies the type of a transaction.

Enum values:
  • NEW: 0
    A new execution report.
  • CANCEL: 1
    Cancellation of a previously sent execution report.
  • CORRECT: 2
    Correction of a previously sent execution report.
  • STATUS: 3
    A replay of a previously transmitted execution report.

Value: NEW

31 LastPx Y

Type: price. The price of the last fill.

Value: 0

150 ExecType Y

Type: char. The type of an ExecutionReport. See the section on FIX order state transitions for additional details.

Enum values:
  • NEW: 0
    Report is an ExecutionReport-Acknowledgement.
  • PARTIAL_FILL: 1
    Report is an ExecutionReport-PartialFill.
  • FILL: 2
    Report is an ExecutionReport-Fill.
  • DONE_FOR_DAY: 3
    Report is an ExecutionReport-DoneForDay.
  • CANCELED: 4
    Execution report is an ExecutionReport-Cancel or ExecutionReport-UnsolicitedCancel.
  • PENDING_CANCEL: 6
    Execution report is an ExecutionReport-PendingCancel.
  • REJECTED: 8
    Execution report is an ExecutionReport-BusinessReject.

Value: DONE_FOR_DAY

151 LeavesQty Y

Type: qty. The remaining (unfilled) quantity of an order open for additional fills. If OrdStatus is CANCELED, DONE_FOR_DAY, or REJECTED, LeavesQty=0. Otherwise, LeavesQty=OrderQty - CumQty.

Value: 0

BusinessReject (8)

ExecutionReport-BusinessReject messages are sent in response to NewOrderSingle messages that are structurally valid (the message is well formed and all requisite tag/value pairs are in place) but invalid from a business logic standpoint. If the message is not structurally valid, Reject is sent instead. Note that ExecutionReport-BusinessReject is sent in response to NewOrderSingle or OrderCancelRequest. Thus, parent in the context below is a reference to the previous message - not a live order.

Tag Name Required? Description
20 ExecTransType Y

Type: char. Identifies the type of a transaction.

Enum values:
  • NEW: 0
    A new execution report.
  • CANCEL: 1
    Cancellation of a previously sent execution report.
  • CORRECT: 2
    Correction of a previously sent execution report.
  • STATUS: 3
    A replay of a previously transmitted execution report.

Value: NEW

31 LastPx Y

Type: price. The price of the last fill.

Value: 0

32 LastShares Y

Type: qty. The quantity of the last fill.

Value: 0

103 OrdRejReason Y

Type: int. An error code indicating why a NewOrderSingle (MsgType=ORDER_SINGLE) was rejected.

Enum values:
  • BROKER_OPTION: 0
    Order violates one or more aspects of the venue order entry specification not enumerated by OrdRejReason.
  • UNKNOWN_SYMBOL: 1
    Order references an unknown Symbol or SymbolSfx.
  • EXCHANGE_CLOSED: 2
    Order received outside of market hours.
  • ORDER_EXCEEDS_LIMIT: 3
    Order violates venue or user configured risk limits.
  • DUPLICATE_ORDER: 6
    Order specifies a ClOrdID that is currently in use.

Value: get(parent, :ord_rej_reason)

150 ExecType Y

Type: char. The type of an ExecutionReport. See the section on FIX order state transitions for additional details.

Enum values:
  • NEW: 0
    Report is an ExecutionReport-Acknowledgement.
  • PARTIAL_FILL: 1
    Report is an ExecutionReport-PartialFill.
  • FILL: 2
    Report is an ExecutionReport-Fill.
  • DONE_FOR_DAY: 3
    Report is an ExecutionReport-DoneForDay.
  • CANCELED: 4
    Execution report is an ExecutionReport-Cancel or ExecutionReport-UnsolicitedCancel.
  • PENDING_CANCEL: 6
    Execution report is an ExecutionReport-PendingCancel.
  • REJECTED: 8
    Execution report is an ExecutionReport-BusinessReject.

Value: REJECT

151 LeavesQty Y

Type: qty. The remaining (unfilled) quantity of an order open for additional fills. If OrdStatus is CANCELED, DONE_FOR_DAY, or REJECTED, LeavesQty=0. Otherwise, LeavesQty=OrderQty - CumQty.

Value: 0

Order State Transitions

OneChronos uses a subset of the legal FIX order state transitions. When an order is in multiple states at once (e.g. PENDING_CANCEL and PARTIALLY_FILLED) the FIX rules of precedence are used to determine which state is reported in the OrdStatus field of an ExecutionReport:

  • PENDING_CANCEL: 12(highest precedence)
  • DONE_FOR_DAY: 10
  • FILLED: 8
  • CANCELED: 5
  • PARTIALLY_FILLED: 4
  • NEW: 2
  • REJECTED: 2
  • PENDING_NEW: 2

Note that values are non-consecutive to maintain parity with the FIX 4.2 specification.

The following are legal transitions (from the perspective of OneChronos sending ExecutionReport messages). States that can only transition to themselves and for which no further messages will be sent (with the exception of trade breaks, when configured) are labeled TERMINAL.

  • NEW
    • PARTIALLY_FILLED
    • FILLED
    • DONE_FOR_DAY
    • CANCELED
    • PENDING_CANCEL
  • PARTIALLY_FILLED
    • PARTIALLY_FILLED
    • FILLED
    • DONE_FOR_DAY
    • CANCELED
    • PENDING_CANCEL
  • FILLED: TERMINAL
  • DONE_FOR_DAY: TERMINAL
  • CANCELED: TERMINAL
  • PENDING_CANCEL
    • PENDING_CANCEL
    • FILLED
    • DONE_FOR_DAY
    • CANCELED
  • REJECTED: TERMINAL
  • PENDING_NEW
    • NEW
    • REJECTED

Drop Copy

OneChronos offers two types of FIX drop copy:

  • Order-by-Order: All business level messages (including trade breaks, if configured) are forwarded to the drop copy session
  • Report Only: Only ExecutionReport-Fill and ExecutionReport-PartialFill messages are forwarded to the drop copy session

Drop copy functionality is configured on the port/session level.

Port Settings

The following parameters can be configured on the FIX port/session level:

Order Entry

Name Enabled by Default? Description
Allow ISO Sweeps Y

Allow orders to participate in auctions where an ISO sweep will take place as part of the clear. ISO sweeps can be disabled on a per-order basis.

Allow Short Sales Y

Allow short sales - orders where Side=SELL_SHORT or Side=SELL_SHORT_EXEMPT.

Allow Test Symbols N

If true, only orders for test symbols will be accepted. If false, only non-test (tradable) symbols will be allowed.

Cancel On Disconnect Y

Cancel all orders in the event of a FIX/network disconnect. Orders that are too late to cancel (actively participating in an auction) will not be canceled.

Cancel on Halt N

Cancel all orders for halted symbols. If the halt impacts any one leg of a combinatorial order, all legs will be canceled.

Combinatorial Leg Elimination Y

Dictates how legs of a combinatorial order that are no longer eligible for execution are reported to Subscriber. As an example, if an order with xor conditions across multiple legs is filled on one leg, all other legs are rendered infeasible and will remain unfilled.

Parameters:
  • Name: behavior
    Description: The action to take when legs of a combinatorial order are no longer eligible for execution.
    Type: enum
    Default: UNSOLICITED_CANCEL
    Enum values:
    • UNSOLICITED_CANCEL: 0
      OneChronos will send an ExecutionReport-UnsolicitedCancel for legs of a combinatorial auction that are no longer eligible for execution.
    • DONE_FOR_DAY: 1
      OneChronos will send an ExecutionReport-DoneForDay for legs of a combinatorial auction that are no longer eligible for execution.
Drop Copy Connection Disconnect Handling N

Controls the handling of drop copy session disconnects.

Validation: port_has_drop_copy_connection: true; drop_reject_set_if_cancel_set: true

Parameters:
  • Name: cancel_resting_orders
    Description: Cancel resting orders if a drop copy connection is not active, or if the connection disconnects.
    Type: boolean
  • Name: reject_new_orders
    Description: Reject new orders if a drop copy connection is not active, or if the connection disconnects.
    Type: boolean
  • Name: timeout
    Description: The number of seconds to wait for the drop copy connection to re-establish before taking action.
    Type: integer
    Default: 30
    Validation: value: { in: 30..180 }
Fat Finger Percent Delta N

Reject orders that are more than a given percent outside of the prevailing NBBO price upon the initiation of an auction. This calculation only applies to individual legs of a combinatorial order that specify a limit price.

Parameters:
  • Name: max_pct_delta
    Description: The maximum percent delta.
    Type: number
    Validation: value: { in: .000001..10 }
Maximum Notional Value N

The maximum permissible notional value (in USD) for a single order.

Parameters:
  • Name: notional_value
    Description: Max notional value.
    Type: integer
    Validation: value: { in: 1..1000000000 }
Maximum Order Size Y

The maximum number of shares allowed for a single order.

Parameters:
  • Name: max_size
    Description: Max shares.
    Type: integer
    Default: 25000
    Validation: value: { in: 100..10000000 }
Microsecond Timestamps N

Enable microsecond level timestamps for all utctimestamp fields.

Session Close Behavior Y

Dictates how orders left open after the conclusion of a OneChronos trading session are handled.

Parameters:
  • Name: behavior
    Description: The action to take upon orders resting after the close of a OneChronos trading session.
    Type: enum
    Default: UNSOLICITED_CANCEL
    Enum values:
    • UNSOLICITED_CANCEL: 0
      OneChronos will send an ExecutionReport-UnsolicitedCancel for every open order upon the close of a trading session.
    • DONE_FOR_DAY: 1
      OneChronos will send an ExecutionReport-DoneForDay for every open order upon the close of a trading session.
    • NONE: 2
      Do not send any messages. OneChronos will silently expire open orders and reject any message from Subscriber referencing them.
Symbology Type Y

Defines the symbology suffix convention to use for order entry.

Parameters:
  • Name: symbology_type
    Type: enum
    Default: CMS_CONCATENATED
    Enum values:
    • CMS_CONCATENATED: 0
      Use CMS Concatenated symbology for symbols requiring a suffix.
    • CMS_SUFFIX: 1
      Use CMS Suffix symbology for symbols requiring a suffix.
    • NASDAQ_INTEGRATED: 2
      Use NASDAQ Integrated symbology for symbols requiring a suffix.
Trade Break Reporting N

Enable TradeBreak reporting.

Drop Copy

Name Enabled by Default? Description
Drop Copy Type Y

Controls the type of drop copy reports that are sent to Subscriber.

Parameters:
  • Name: drop_copy_type
    Description: The type of drop copy reports that are sent.
    Type: enum
    Default: FILLS_ONLY
    Enum values:
    • ORDER_BY_ORDER: 0
      All business level messages (including trade breaks, if configured) are forwarded to the drop copy session.
    • FILLS_ONLY: 1
      Only ExecutionReport-Fill and ExecutionReport-PartialFill messages are forwarded to the drop copy session.
Trade Break Reporting N

Enable TradeBreak reporting.

Appendix

Symbology

OneChronos supports three symbology conventions:

  1. CMS Concatenated. Subscriber must populate the Symbol field with both the root symbol and a CMS suffix, for symbols requiring one. A single ASCII space must separate the root and the suffix. Example: Symbol=BRK A.
  2. CMS Suffix. Subscriber must populate the Symbol field with only the root suffix, and SymbolSfx with a CMS suffix for symbols requiring one. Example: Symbol=BRK, SymbolSfx=A.
  3. NASDAQ Integrated. Subscriber must populate the Symbol field with the root symbol and append a NASDAQ Integrated suffix for symbols requiring one. Example: Symbol=BRK.A.

Symbology election occurs on the port level. The table below is a comprehensive list of security categorizations (not all of which are necessarily tradable on OneChronos). Note that we include a column showing the mapping from CQS symbology to CMS/NASDAQ Integrated, but we do not support CQS.

Security Type CQS Suffix (not tradable) CMS Suffix Nasdaq Integrated Suffix
Called /CL CL *
Class 'A' When Issued /Aw AWI .A#
Class 'A' Called /A/CL ACL .A*
Class 'A' /A A .A
Class 'B' /B B .B
Class Convertible /A/CV ACV .A%
Convertible /CV CV %
Convertible Called /CV/CL CVCL %*
Emerging Company Marketplace /EC EC !
Partial Paid /PP PP @
Preferred p PR -
Preferred 'A' Called pA/CL PRACL -A*
Preferred 'A' When Issued pAw PRAWI -A#
Preferred (Class A) Convertible pA/CV PRACV -A%
Preferred (Class A) When Distributed pA/WD PRAWD -A$
Preferred Called p/CL PRCL -*
Preferred Class 'A' pA PRA -A
Preferred Class 'B' pB PRB -B
Preferred When Distributed p/WD PRWD -$
Preferred When Issued pw PRWI -#
Rights r RT ^
Rights When Issued rw RTWI ^#
TEST Symbol /TEST TEST ~
Units /U U =
Warrants /WS WS +
Warrants Class 'A' /WS/A WSA +A
Warrants Class 'B' /WS/B WSB +B
Warrrant When Issued /WSw WSWI +#
When Distributed /WD WD $
When Issued w WI #

Sample Messages

Heartbeat (0)

Raw Message
8=FIX.4.2|9=82|35=0|34=5|49=p.s1.trader01|52=20171211-17:16:34.112|56=ICGX|112=20171211000000001|10=097|

Formatted
Header
8        BeginString:         FIX.4.2
9        BodyLength:          82
35       MsgType:             HEARTBEAT (0)
34       MsgSeqNum:           5
49       SenderCompID:        p.s1.trader01
52       SendingTime:         20171211-17:16:34.112
56       TargetCompID:        ICGX

Body
112      TestReqID:           20171211000000001

Trailer
10       CheckSum:            097

TestRequest (1)

Raw Message
8=FIX.4.2|9=82|35=1|34=5|49=p.s1.trader01|52=20171211-17:16:34.112|56=ICGX|112=20171211000000001|10=098|

Formatted
Header
8        BeginString:         FIX.4.2
9        BodyLength:          82
35       MsgType:             TEST_REQUEST (1)
34       MsgSeqNum:           5
49       SenderCompID:        p.s1.trader01
52       SendingTime:         20171211-17:16:34.112
56       TargetCompID:        ICGX

Body
112      TestReqID:           20171211000000001

Trailer
10       CheckSum:            098

ResendRequest (2)

Raw Message
8=FIX.4.2|9=69|35=2|34=5|49=p.s1.trader01|52=20171211-17:16:34.112|56=ICGX|7=5|16=7|10=220|

Formatted
Header
8        BeginString:         FIX.4.2
9        BodyLength:          69
35       MsgType:             RESEND_REQUEST (2)
34       MsgSeqNum:           5
49       SenderCompID:        p.s1.trader01
52       SendingTime:         20171211-17:16:34.112
56       TargetCompID:        ICGX

Body
7        BeginSeqNo:          5
16       EndSeqNo:            7

Trailer
10       CheckSum:            220

Reject (3)

Raw Message
8=FIX.4.2|9=127|35=3|34=5|49=ICGX|52=20171211-17:16:34.112|56=p.s1.trader01|45=15|58=ClOrdID is required for NewOrderSingle|371=11|372=D|373=1|10=140|

Formatted
Header
8        BeginString:         FIX.4.2
9        BodyLength:          127
35       MsgType:             REJECT (3)
34       MsgSeqNum:           5
49       SenderCompID:        ICGX
52       SendingTime:         20171211-17:16:34.112
56       TargetCompID:        p.s1.trader01

Body
45       RefSeqNum:           15
58       Text:                ClOrdID is required for NewOrderSingle
371      RefTagID:            11
372      RefMsgType:          D
373      SessionRejectReason: REQUIRED_TAG_MISSING (1)

Trailer
10       CheckSum:            140

SequenceReset (4)

Raw Message
8=FIX.4.2|9=71|35=4|34=5|49=p.s1.trader01|52=20171211-17:16:34.112|56=ICGX|36=7|123=Y|10=092|

Formatted
Header
8        BeginString:         FIX.4.2
9        BodyLength:          71
35       MsgType:             SEQUENCE_RESET (4)
34       MsgSeqNum:           5
49       SenderCompID:        p.s1.trader01
52       SendingTime:         20171211-17:16:34.112
56       TargetCompID:        ICGX

Body
36       NewSeqNo:            7
123      GapFillFlag:         GAP_FILL_MESSAGE_MSGSEQNUM_FIELD_VALID (Y)

Trailer
10       CheckSum:            092

Logout (5)

Raw Message
8=FIX.4.2|9=88|35=5|34=5|49=ICGX|52=20171211-17:16:34.112|56=p.s1.trader01|58=Daily FIX session logout|10=221|

Formatted
Header
8        BeginString:         FIX.4.2
9        BodyLength:          88
35       MsgType:             LOGOUT (5)
34       MsgSeqNum:           5
49       SenderCompID:        ICGX
52       SendingTime:         20171211-17:16:34.112
56       TargetCompID:        p.s1.trader01

Body
58       Text:                Daily FIX session logout

Trailer
10       CheckSum:            221

Logon (A)

Raw Message
8=FIX.4.2|9=72|35=A|34=5|49=p.s1.trader01|52=20171211-17:16:34.112|56=ICGX|98=0|108=30|10=120|

Formatted
Header
8        BeginString:         FIX.4.2
9        BodyLength:          72
35       MsgType:             LOGON (A)
34       MsgSeqNum:           5
49       SenderCompID:        p.s1.trader01
52       SendingTime:         20171211-17:16:34.112
56       TargetCompID:        ICGX

Body
98       EncryptMethod:       NONE (0)
108      HeartBtInt:          30

Trailer
10       CheckSum:            120

NewOrderSingle (D)

Description: A limit buy order.

Raw Message
8=FIX.4.2|9=158|35=D|34=5|49=p.s1.trader01|52=20171211-17:16:34.112|56=ICGX|11=20171211000000002|21=1|38=1000|40=2|44=1040.48|47=A|54=1|55=GOOG|59=0|60=20171211-17:16:34.112|10=203|

Formatted
Header
8        BeginString:         FIX.4.2
9        BodyLength:          158
35       MsgType:             ORDER_SINGLE (D)
34       MsgSeqNum:           5
49       SenderCompID:        p.s1.trader01
52       SendingTime:         20171211-17:16:34.112
56       TargetCompID:        ICGX

Body
11       ClOrdID:             20171211000000002
21       HandlInst:           AUTOMATED_EXECUTION_ORDER_PRIVATE_NO_BROKER_INTERVENTION (1)
38       OrderQty:            1000
40       OrdType:             LIMIT (2)
44       Price:               1040.48
47       Rule80A:             AGENCY_SINGLE_ORDER (A)
54       Side:                BUY (1)
55       Symbol:              GOOG
59       TimeInForce:         DAY (0)
60       TransactTime:        20171211-17:16:34.112

Trailer
10       CheckSum:            203

OrderCancelRequest (F)

Raw Message
8=FIX.4.2|9=148|35=F|34=5|49=p.s1.trader01|52=20171211-17:16:49.112|56=ICGX|11=20171211000000003|38=1000|41=20171211000000002|54=1|55=GOOG|60=20171211-17:16:49.112|10=076|

Formatted
Header
8        BeginString:         FIX.4.2
9        BodyLength:          148
35       MsgType:             ORDER_CANCEL_REQUEST (F)
34       MsgSeqNum:           5
49       SenderCompID:        p.s1.trader01
52       SendingTime:         20171211-17:16:49.112
56       TargetCompID:        ICGX

Body
11       ClOrdID:             20171211000000003
38       OrderQty:            1000
41       OrigClOrdID:         20171211000000002
54       Side:                BUY (1)
55       Symbol:              GOOG
60       TransactTime:        20171211-17:16:49.112

Trailer
10       CheckSum:            076

OrderCancelReject (9)

Description: A cancel is rejected because the referenced order was already filled.

Raw Message
8=FIX.4.2|9=140|35=9|34=5|49=ICGX|52=20171211-17:16:49.112|56=p.s1.trader01|11=20171211000000003|37=20171211000000000|39=8|41=20171211000000002|102=0|434=F|10=056|

Formatted
Header
8        BeginString:         FIX.4.2
9        BodyLength:          140
35       MsgType:             ORDER_CANCEL_REJECT (9)
34       MsgSeqNum:           5
49       SenderCompID:        ICGX
52       SendingTime:         20171211-17:16:49.112
56       TargetCompID:        p.s1.trader01

Body
11       ClOrdID:             20171211000000003
37       OrderID:             20171211000000000
39       OrdStatus:           REJECTED (8)
41       OrigClOrdID:         20171211000000002
102      CxlRejReason:        TOO_LATE_TO_CANCEL (0)
434      CxlRejResponseTo:    F

Trailer
10       CheckSum:            056

TradeCancelCorrect (UCC)

Description: A trade break in which the original execution report is canceled.

Raw Message
8=FIX.4.2|9=236|35=UCC|34=5|49=ICGX|52=20171211-19:16:34.112|56=p.s1.trader01|11=20171211000000002|17=20171211000000081|19=20171211000000017|20=1|31=1040.470000|32=300|37=20171211000000000|42=20171211-17:16:35.112|54=1|55=GOOG|60=20171211-19:16:34.112|10=224|

Formatted
Header
8        BeginString:         FIX.4.2
9        BodyLength:          236
35       MsgType:             TRADE_CANCEL_CORRECT (UCC)
34       MsgSeqNum:           5
49       SenderCompID:        ICGX
52       SendingTime:         20171211-19:16:34.112
56       TargetCompID:        p.s1.trader01

Body
11       ClOrdID:             20171211000000002
17       ExecID:              20171211000000081
19       ExecRefID:           20171211000000017
20       ExecTransType:       CANCEL (1)
31       LastPx:              1040.470000
32       LastShares:          300
37       OrderID:             20171211000000000
42       OrigTime:            20171211-17:16:35.112
54       Side:                BUY (1)
55       Symbol:              GOOG
60       TransactTime:        20171211-19:16:34.112

Trailer
10       CheckSum:            224

PartialFill (8)

Description: An ExecutionReport-PartialFill.

Raw Message
8=FIX.4.2|9=325|35=8|34=5|49=ICGX|52=20171211-17:16:35.112|56=p.s1.trader01|6=1040.470000|11=20171211000000002|14=300|17=20171211000000017|20=0|21=1|30=CGX|31=1040.470000|32=300|37=20171211000000000|38=1000|39=1|40=2|44=1040.48|47=A|54=1|55=GOOG|59=0|60=20171211-17:16:35.112|150=1|151=700|375=CRON|382=1|20005=201712110000000004|20006=1337|10=181|

Formatted
Header
8        BeginString:         FIX.4.2
9        BodyLength:          325
35       MsgType:             EXECUTION_REPORT (8)
34       MsgSeqNum:           5
49       SenderCompID:        ICGX
52       SendingTime:         20171211-17:16:35.112
56       TargetCompID:        p.s1.trader01

Body
6        AvgPx:               1040.470000
11       ClOrdID:             20171211000000002
14       CumQty:              300
17       ExecID:              20171211000000017
20       ExecTransType:       NEW (0)
21       HandlInst:           AUTOMATED_EXECUTION_ORDER_PRIVATE_NO_BROKER_INTERVENTION (1)
30       LastMkt:             CGX
31       LastPx:              1040.470000
32       LastShares:          300
37       OrderID:             20171211000000000
38       OrderQty:            1000
39       OrdStatus:           PARTIALLY_FILLED (1)
40       OrdType:             LIMIT (2)
44       Price:               1040.48
47       Rule80A:             AGENCY_SINGLE_ORDER (A)
54       Side:                BUY (1)
55       Symbol:              GOOG
59       TimeInForce:         DAY (0)
60       TransactTime:        20171211-17:16:35.112
150      ExecType:            PARTIAL_FILL (1)
151      LeavesQty:           700
375      ContraBroker:        CRON
382      NoContraBrokers:     1
20005    AuctionID:           201712110000000004
20006    AuctionSubID:        1337

Trailer
10       CheckSum:            181