TECHNICAL STANDARD - FIX Session Protocol

,
1

The FIX Global Technical Committee has reviewed and approved a refactored specification for the FIX Session Protocol. The specification had been part of the FIX Application Layer Specification (aka Volume 1-7) prior to FIX 5.0. As of FIX 5.0, a new FIX Session Protocol called FIXT Version 1.1 was introduced that supported transport independence. The refactored specification includes the FIX Session Protocol as defined in the following FIX specifications:

  • FIX Version 4.2 with Errata from May 1, 2001

  • FIX Version 4.4 Errata from June 18, 2003 (Volume 2)

  • FIXT Version 1.1 Errata from March 2008.

The refactored specification therefore supersedes the aforementioned specifications as the normative reference for the FIX Session Protocol standard. The FIX Session Protocol is now defined as a set of profiles:

  • FIX.4.2 session profile for FIX 4.2 application version of FIX.

  • FIX4 session profile backward compatible to FIX 4.4 that supports a single application version of FIX over a FIX session. If the default application version is not specified it is assumed to be FIX Latest .

  • FIXT session profile provides support for multiple application versions over a single FIX session. The default application version must be specified. Also usable for a single application version of FIX, especially if the implementer wants to retain the option to introduce applicationing in the future.

  • LFIXT session profile (lightweight FIXT) is a restricted subset of the FIXT session profile that is interoperable with FIXT in compatible mode. The succinct mode does not use session layer recovery.

The refactored specification was partially generated from the FIX Orchestra repository for the FIX session layer.

LFIXT is a new profile developed by the FIX Trading Community in China which is based upon FIXT. The main difference is the omission of session level recovery in favor of a more efficient application level recovery. The choice of profile is subject to bilateral agreement between counterparties. Note that the choice of profile is independent of a FIX application version. For example, FIX Latest (https://www.fixtrading.org/online-specification/) can be run over a FIX4 session profile BeginString(8)=“FIX.4.4” or the FIXT session profile BeginString(8)=“FIXT.1.1”. This means that one can use the latest Extension Packs (https://www.fixtrading.org/extension-packs/) without making changes to the FIX session profile. The FIX Latest version is updated with each approved extension pack. FIX users are encouraged to document their rules of engagement for their use of FIX Latest using the FIX Orchestra machine readable rules of engagement. FIX 4.2 continues to be a supported application version of FIX. Users of FIX 4.2 can incorporate fields, components, and messages from FIX Latest by counterparty agreement.

The question is hence no longer “Which FIX version do you support?” but “Which session profile do you support?”.

The GTC highly appreciates the work from China to provide LFIXT as a new profile to reduce the burden on FIX engines regarding session level recovery. What has become a common practice in some cases, i.e. sending SequenceReset(35=4) messages with GapFill(123)=“Y” instead of actually retransmitting lost messages, now has a name in the official standard for the FIX Session Protocol. LFIXT is able to interoperate with FIXT peers, leading the GTC to re-use the existing BeginString(8)=“FIXT.1.1” for the LFIXT profile. The usage of the LFIXT profile is to be agreed upon out-of-band.

The specification document for the new FIX Session Protocol is available here. A separate document defines a series of standardized test cases. Please provide any comments or questions you may have in this discussion thread.

PUBLIC COMMENT PERIOD – Application Version for FIXLatest
Is it correct to apply *any* checking to sequence number tag 34 of a sequence reset - Reset message
2

How about the fields, components, and messages that have been either deprecated or meanings updated between older versions and newer versions? Does it mean the FIX dictionary validations now apply based on the session profile?

3

@ramjeepenta thank you for the question. I am assuming that you are referring to examples like ExecTransType(20) that was deprecated with FIX 4.3. These are changes of the application layer and do not impact the session layer. There is no change to the validations that you currently have in place.

The FIX dictionary validations continue to be applied based on the application version being used. This information is based on the value of BeginString(8) for application versions prior to FIX 5.0. As of FIX 5.0, BeginString(8) changed to “FIXT.1.1” and ApplVerID(1128) became the source of information. Note that a proposal for a new value “FIXLatest” for ApplVerID(1128) has just been published for review (PUBLIC COMMENT PERIOD – Application Version for FIXLatest).

4

Thanks for the clarification.
One more question. Can we submit different messages with different profiles in the same session? Like a FIX4 and a FIX4.2 in the same session? Is that the flexibility FIXLatest offering us?

5

I think there is a misunderstanding here. A FIX message does not have a profile. A FIX message has an application version and this can also be “FIXLatest” in the future to indicate that it may take advantage of all FIX Extension Packs (https://www.fixtrading.org/extension-packs/). Only FIX sessions have profiles and a single FIX session only has a single profile, i.e. BeginString(8) of all messages exchanged during this session must have the same value. This has not changed and was always the case!

The FIX session profile FIXT allows you to run multiple application versions over the same session. BeginString(8) is always “FIXT.1.1” but ApplVerID(1128) can be different for every message. Note that this has also not changed from the time that the Technical Standard FIXT 1.1 was introduced together with FIX 5.0 back in 2009.

Please note that the session profile for the FIX 4.2 application version has a “.” after “FIX”, i.e. “FIX.4.2”. It was intentionally chosen to be identical to the value of BeginString(8). Note also that the names of session profiles are not part of the wire format of the FIX messages, only BeginString(8) values are.