Tagvalue encoding (classic FIX)

The original FIX message encoding is known as tagvalue encoding. Each field consists of a unique numeric tag and a value. The tag identifies the field semantically. Therefore, messages are self-describing. Tagvalue encoding is character-based, using ASCII codes.

8=FIX.4.2 | 9=178 | 35=8 | 49=PHLX | 56=PERS | 52=20071123-05:30:00.000 | 11=ATOMNOCCC9990900 | 20=3 | 150=E | 39=E | 55=MSFT | 167=CS | 54=1 | 38=15 | 40=2 | 44=15 | 58=PHLX EQUITY TESTING | 59=0 | 47=C | 32=0 | 31=0 | 151=15 | 14=0 | 6=0 | 10=128 | 

8=FIX.4.2|9=65|35=A|49=SERVER|56=CLIENT|34=177|52=20090107-18:15:16|98=0|108=30|10=062|
     0   + 0  + 5  +   10    +   10    +  7   +        21          + 5  +  7   +   0    = 65

FIXML

FIXML^[7] is an XML schema for FIX messages. It is semantically equivalent to tagvalue encoded messages but takes advantage of XML parser technology. FIXML is commonly used for back-office and clearing applications rather than trading.

Simple Binary Encoding (SBE)

Simple Binary Encoding^[8] defines a wire format using primitive data types that are native to computing systems. Message encoding and decoding is therefore much lower latency than character-based protocols since no translation is needed to put data into a format that computers can use. Aside from latency advantages, performance is more deterministic because SBE messages are constrained by templates and fixed-length data elements are preferred. Another consequence is that fields are generally at a fixed position so that message filters and routers do not need to crack an entire message to access key fields.

SBE was developed by the FIX High Performance Working Group to support high performance trading. Tagvalue encoding was deemed no longer fit-for-purpose since it is character based rather than binary and its variable-length fields and messages result in non-deterministic performance.

Unlike tagvalue and FIXML, an SBE message is not self-describing. Only data is sent on the wire with a minimal header to identify the template that controls a message. Metadata that describes a message layout is exchanged out-of-band between peers.

FIX Trading Community publishes an XML schema for SBE message schemas. A message schema may contain any number of message templates. A template describes the fields that constitute a message. Additionally, a schema provides a listing of simple and composite data types that may be reused by any number of fields.

From a practical perspective, assuming a C/C++ implementation, and adjusting for endianness: most non-composite types in the message directly map to the same type in the language. For example, 32-bit integer maps to uint32_t, fixed strings maps const char *, floating point maps to float and so on. One can generate a C/C++ struct from the schema definition. Then, given a pointer to a message buffer, accessing non-composite fields of the message amount to type-casting it to a pointer to structure and accessing structure members directly.

/* Generated struct from schema */
struct Message {
  ...
  uint32_t qty;
  ...
  const char *symbol;
  ...
};

void consume_message(void *incoming_message) {
  const struct Message *msg = (const struct Message*) incoming_message;
  printf("Traded %u of %s\n", msg->qty, msg->symbol);
  ...
}

Other FIX encodings

FIX Trading Community has also developed standard mappings between FIX and other message protocols, including:

• Google Protocol Buffers
• ASN.1
• JSON

FIX Transport (FIXT)

The original FIX session protocol did not have its own name since it was part of a monolithic specification covering application layer semantics and message encoding as well. However, starting with FIX version 5.0, the session layer was split off as an independent specification with the introduction of FIXT.^[9] FIXT was largely the same as the original unnamed session layer in version 4.x, but it offered one significant innovation--it provided a mechanism to mix FIX application layer versions over a common session version. The current FIXT version is 1.1.

Theoretically, FIXT is transport independent. However, it is usually employed over Transmission Control Protocol (TCP).

FIXT is a point-to-point protocol. It guarantees message delivery in both directions. Messages sent in each direction carry a message sequence number in the message header. If there is a communication fault, a peer may request retransmission of missed messages. Message delivery is supported even in the event of disconnection and later reestablishment of a session.

To implement session establishment and guaranteed delivery, FIXT and classic FIX 4.x define these session message types:

• Heartbeat
• Test Request
• ResendRequest
• Reject
• SequenceReset
• Logout
• Logon
• XMLnonFIX

FIX Performance Session Layer (FIXP)

FIXP^[10] was developed by the FIX High Performance Working Group^[11] to meet the needs of high performance trading. The primary need is for low latency message encoding and decoding and control over message delivery guarantees.

To provide low latency, binary message encodings are supported both for session layer and application messages. The actual wire format is abstracted in the FIXP specification, so users may select a FIX encoding of their choice, so long as peers agree on a protocol to use. Early development has used Simple Binary Encoding.

FIXP covers both point-to-point and multicast use cases with common primitives.

When a point-to-point session is established, peers negotiate delivery guarantees from among the following choices:

• Recoverable: exactly-once message delivery. If gaps are detected, then missed messages may be recovered by retransmission.
• Idempotent: at-most-once delivery. If gaps are detected, the sender is notified, but recovery is under the control of the application, if it is done at all.
• Unsequenced: makes no delivery guarantees. This choice is appropriate if guarantees are unnecessary or if recovery is provided at the application layer or through a different communication channel.
• Note: No application messages should be sent in one direction of a session.

Delivery guarantees may be asymmetrical. For example, a trader may enter orders over an idempotent flow while executions are returned over a recoverable flow. In fast moving markets, the delay inherent in retransmission is often undesirable, resulting in missed opportunities or bad trades.