The Global Technical Committee has reviewed and preliminarily approved the Gap Analysis. It extends the values of BeginString(8) for FIX Latest to include the session profile identifiers for the FIX Session Layers of FIX 4.2 and FIX 4.4. Currently, FIX Latest requires BeginString(8)=”FIXT.1.1”, i.e. to reference FIX Transport, the FIX Session Layer introduced with FIX 5.0. With this extension, you no longer need to change your session layer, i.e. you can continue to use BeginString(8)=”FIX.4.2” or BeginString(8)=”FIX.4.4” together with the latest extensions made to the FIX Protocol.
The document now enters a public comment period in which public review and feedback is encouraged. Once the public comment period closes, the GTC will review public comments before final approval by the GTC Governance Board.
Please post feedback, comments, and questions as replies to this discussion thread. The public comment period ends on December 2, 2021.
A link to the proposal can be found at: https://www.fixtrading.org/packages/extension-of-beginstring-for-fix-latest/ .
Just general questions for my understanding:
-
According to https://www.fixtrading.org/standards/fix-session-layer-online#fix-session-profiles
for FIX4 session profile it is assumed that FIX Latest is used when tag DefaultApplVerID(1137) is absent.
Is there anything that differentiates a “normal” FIX.4.4 session from a session using the FIX4 session profile?
-
Because DefaultApplVerID will not be used for FIX.4.2 you cannot make any assumptions (e.g. when looking at a log file) about if FIX Latest is used on a FIX.4.2 connection or not? This is simply agreed between counterparties, correct?
-
So basically speaking this Gap Analysis proposes what counterparties are probably doing anyway: to take fields from newer FIX versions (speak FIX Latest) and use them with FIX4.2 or FIX4.4?
Thanks in advance.
@christophjohn thanks for your questions.
-
FIX4 session profile is the “normal” FIX 4.4 session. We are not trying to create something different here and rather want to reflect the fact that a typical FIX 4.4 interface will be using tags from higher versions. That said, I would like to hear back what people think is meant when DefaultApplVerID(1137)=6 (FIX44) is actually used by somebody. Does this forbid the use of tag numbers above 956? Or does this imply that FIX 4.2 semantics (e.g. ExecTransType(20)) are not supported?
-
Yes, and we recommend that this “agreement” be made in a machine-readable format that precisely defines what is supported. A PDF document should be generated from the machine-readable format. Today, somebody writes a document which then gets keyed in by software developers and testers. That is error-prone and a significant effort compared to the usage of Orchestra and Tablature.
-
Yes, we wanted to provide the formal basis for what is already out there. BeginString(8) having more than one value supports this.
1 Like
I’m definitely in two minds about this.
On a practical level, what we see when we inter-op with various institutions it is definitely the case that this is what they do. So in terms of making documentation match reality, this change definitely does that.
Our internal FIX engine is forced as a consequence to makes no assumption about FIX session capabilities based on BeginString - if you pick a “dictionary” based validation method then we start from the FIX.4.2 spec or the FIX.4.4 spec but we also allow a custom dictionary which written either from customer specification or more commonly, adapted from the FIX.4.x spec version during a time-intensive conformance phase. The BeginString becomes little more than a session identifier like “TargetCompID”.
It would be nice to see Orchestra based conformance but right now we’re not seeing demand for it (but in early phases of adding support in hopeful anticipation).
Even for FIXT, we broadly only see a single application version running on top, so it’s much the same, only with changes made to application “dictionary” and not the transport.
On the other hand, this is sort of anti-spec-ing - and eroding the specifications which is disappointing. 
@philipwhiuk which FIX version do you currently assume when you see BeginString(8)=“FIXT.1.1”? Do you assume FIX 5.0, FIX 5.0 SP1, FIX 5.0 SP2 or FIX Latest? Only legacy versions below FIX 5.0 have something in BeginString that matches 1:1 with a FIX version number. FIX was monolithic in nature prior to FIX 5.0 introducing Transport Independence.
I do not see why you cannot continue to make assumptions about FIX session capabilities based on BeginString. As of FIX 5.0 you were no longer able to make assumptions on FIX application capabilities based on BeginString other than that they are FIX 5.0 or higher. FIX Latest is not about the session layer, even if the latest session messages still show up in FIXimate for convenience.
You have a valid point in terms of supported capabilities, i.e. the fact that the FIX Session Layer specification does not have explicit appendices for the messages, fields and code sets (aka values) for the different session profiles. It is worth a discussion whether, for example, the capability of the Logon(35=A) having a username and password (added after FIX 4.2) should be allowed when BeginString(8)=“FIX.4.2”. How do you handle that today?
For the FIXT deployments we’d be doing the same but based on the ApplVerID. So then we’d use the relevant spec-generated dictionary as a starting point and then blend in functionality from later EPs / custom tags when needed.
Essentially the BeginString (FIX4) / ApplVerID (FIXT) is a strong hint rather than a definition.
I’m mostly talking about application-layer not session-layer properties. It is the application-layer capabilities that counter-parties tend to want to add to, preserving their original (well tested) session-layer implementation. So that’s the area where we are flexible. We use the FIX standards as best practice and guidance - if a counter-party wants a new feature that’s in a later version / EP we’ll try to adopt the tags and definitions rather than use custom tags for the same purpose.
To be honest we don’t have huge use of Username/Password in Logon. In general, and in concert with the FIX community security best practices last time I looked, we tend to authorise connections (which are generally institutional) using TLS client certificates (and/or network-layer security - VPN, private line etc). FIX tags end in logs and audit trails and so forth and obscuring them is ugly. Obviously for some set-ups it may makes sense to keep the fields (though TLS certs are getting easier to obtain and handle which might make this less true long term).
However we handle Username/Password checks/insertion beyond the FIX-version specific code, so it would work in FIXT / FIX4.2.
ApplVerID(1128) is only about the application level. It does not have a value for FIXT, what do you mean with “ApplVerID (FIXT)”?
I agree that both fields are only a “strong hint” as you put it. That is why we strongly recommend the use of the meta-standard Orchestra to exchange exact definitions by means of an XML file. For legibility, the XML file can be converted to a markdown format.
Sorry for the late reply: for me the latter, i.e. no FIX4.2 semantics are supported.
1 Like