The Global Technical Committee has reviewed and preliminarily approved the Gap Analysis. It contains a large number of errors and omissions discovered in the FIX Standard, e.g. misspellings or gaffes in the description. The various changes are not necessarily linked to one another. Most of them were collected over time in the discussion forum (see FIX Standard Errors and Omissions 2018-2021) or collected via emails from members. A new thread FIX Standard Errors and Omissions 2022 has been created for errors and omissions detected by the FIX Trading Community going forward.
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 March 18, 2022.
Issue raised here that should be fixed asap. Field usage description of ClOrdID(11) in ExecutionReport(35=8) message was changed with EP159 to the following:
In the case of quotes can be mapped to:
QuoteID(117) of a single Quote(35=S)
QuoteEntryID(299) of a MassQuote(35=i)
BidID(390) or OfferID(1867) of a two-sided Quote(35=S)
The implementation somehow retrieved the previous text from before EP159, resulting in an erroneous text currently shown in FIXimate.
In the case of quotes can be mapped to:
QuoteMsgID(1166) of a single Quote(35=S)
QuoteID(117) of a MassQuote(35=i).
MassOrderReportID(2424) of a MassOrderAck(35=DK)
The concept for ClOrdID(11) is to refer to the entity identifier of the individual quote, not the message identifier. The latter is covered my QuoteMsgID(1166). That was corrected with EP159.
The error seems to have happened with FIX 4.4 already. FIX 4.3 did not yet have named components. The NoXXX field was basically used as a name. In FIX 4.3, both CrossOrderCancelReplaceRequest(35=t) and CrossOrderCancelRequest(35=u) had OrigClOrdID(41) and OrigOrdModTime(586). FIX 4.4 created separate components for them (SideCrossOrdModGrp and SideCrossOrdCxlGrp). Only SideCrossOrdCxlGrp had the fields and SideCrossOrdModGrp did not. This was an error in FIX 4.4, not in FIX 5.0.
FIX 5.0 added OrigClOrdID(41) to SideCrossOrdModGrp but did not also add OrigOrdModTime(586). SideCrossOrdCxlGrp is not affected as it had both fields from the beginning. OrigOrdModTime(586) needs to be added to SideCrossOrdModGrp.
This also seems to be an error in the transition from FIX 4.3 to FIX 4.4 when components were named. The sides repeating group of the TCR was named TrdCapRptSideGrp with FIX 4.4 and did not include ClearingFeeIndicator(635) that had been present in FIX 4.3 in the unnamed sides repeating group. This has nothing to do with Orchestra, it is missing since FIX 4.4.
LegProvisionPartyIDSource(40535) uses the code set PartyIDSourceCodeSet, i.e. the same values as PartyIDSource(447) that does not support user defined values. It is hence not related to incompatible types but to the fact that the field must not have a union datatype. It is still an error that needs to be fixed.
All three tags are stipulation types and use the same code set. The first one, StipulationType(233), was added with FIX 4.3 with a String datatype and without a union datatype. @xavierbruyet, why do you think the three fields should have a union datatype? The fields should not need it as the description defines “Other types may be used by mutual agreement of the counterparties.”
The field was actually present in FIX 4.4 in the original repository (before the unified 2010 format).
Because of the description you mentioned: “Other types may be used by mutual agreement of the counterparties.” Does it mean than the description is wrong or the code set can be extended without having to specify unionDataType?
The Basic and Unified repositories for FIX 4.4 should have always been in sync unless there was an error in the conversion tool. Are you sure it was SideCrossOrdModGrp and not SideCrossOrdCxlGrp where you find tag 586? Can you post the snippet from your FIX 4.4 MsgContents.xml file that shows this?
The error will not be fixed in either of them for FIX 4.4, only in the FIX 4.4 Orchestra repository on GitHub. SideCrossOrdModGrp is missing both tags 41 and 586 in that repository.
The latter. Union datatypes are always integer and cannot be used for this. The base datatype of StipulationType(233) is String. The only way to allow user-defined values is with the description. TradingSessionID(336) and TradingSessionSubID(625) have a similar description “Bilaterally agreed values of data type String that start with a character can be used for backward compatibility.”
<MsgContents>
<Indent>0</Indent>
<Position>1</Position>
<TagText>StandardHeader</TagText>
<Reqd>1</Reqd>
<Description>MsgType = t (lowercase T)
</Description>
<MsgID>53</MsgID>
</MsgContents>
<MsgContents>
<Indent>0</Indent>
<Position>2</Position>
<TagText>37</TagText>
<Reqd>0</Reqd>
<Description>Unique identifier of most recent order as assigned by sell-side (broker, exchange, ECN).
</Description>
<MsgID>53</MsgID>
</MsgContents>
<MsgContents>
<Indent>0</Indent>
<Position>3</Position>
<TagText>548</TagText>
<Reqd>1</Reqd>
<Description>CrossID for the replacement order
</Description>
<MsgID>53</MsgID>
</MsgContents>
<MsgContents>
<Indent>0</Indent>
<Position>4</Position>
<TagText>551</TagText>
<Reqd>1</Reqd>
<Description>Must match the CrossID of the previous cross order. Same order chaining mechanism as ClOrdID/OrigClOrdID with single order Cancel/Replace.
</Description>
<MsgID>53</MsgID>
</MsgContents>
<MsgContents>
<Indent>0</Indent>
<Position>5</Position>
<TagText>549</TagText>
<Reqd>1</Reqd>
<Description>
</Description>
<MsgID>53</MsgID>
</MsgContents>
<MsgContents>
<Indent>0</Indent>
<Position>6</Position>
<TagText>550</TagText>
<Reqd>1</Reqd>
<Description>
</Description>
<MsgID>53</MsgID>
</MsgContents>
<MsgContents>
<Indent>0</Indent>
<Position>7</Position>
<TagText>552</TagText>
<Reqd>1</Reqd>
<Description>Must be 1 or 2
</Description>
<MsgID>53</MsgID>
</MsgContents>
<MsgContents>
<Indent>1</Indent>
<Position>8</Position>
<TagText>54</TagText>
<Reqd>1</Reqd>
<Description>
</Description>
<MsgID>53</MsgID>
</MsgContents>
<MsgContents>
<Indent>1</Indent>
<Position>9</Position>
<TagText>41</TagText>
<Reqd>1</Reqd>
<Description>
</Description>
<MsgID>53</MsgID>
</MsgContents>
<MsgContents>
<Indent>1</Indent>
<Position>10</Position>
<TagText>11</TagText>
<Reqd>1</Reqd>
<Description>Unique identifier of the order as assigned by institution or by the intermediary with closest association with the investor.
</Description>
<MsgID>53</MsgID>
</MsgContents>
<MsgContents>
<Indent>1</Indent>
<Position>11</Position>
<TagText>526</TagText>
<Reqd>0</Reqd>
<Description>
</Description>
<MsgID>53</MsgID>
</MsgContents>
<MsgContents>
<Indent>1</Indent>
<Position>12</Position>
<TagText>583</TagText>
<Reqd>0</Reqd>
<Description>
</Description>
<MsgID>53</MsgID>
</MsgContents>
<MsgContents>
<Indent>1</Indent>
<Position>13</Position>
<TagText>586</TagText>
<Reqd>0</Reqd>
<Description>
</Description>
<MsgID>53</MsgID>
</MsgContents>
I was not aware about that. This is a kind of issue since our application is not able to know if it should accept any value or only those from the code set. Now I’m wondering what unionDataType means? Does it mean that the tag can accept additional values which are not specified in the code set or is it just a hint to let the ROE writer know that he can add values in its code set?
Your snippet is from FIX 4.3 and not FIX 4.4 and also seems to have stripped out the pedigree attribute (Added=“FIX.4.3”). <MsgID>53</MsgID> corresponds to the CrossOrderCancelReplaceRequest(35=t). OrigOrdModTime(586) was on the root level of the message in FIX 4.3 and intended to be moved into the SideCrossOrdModGrp component with FIX 4.4. That component has the ID 2059 (also encoded as MsgID reference in Basic). It was correctly added to SideCrossOrdCxlGrp (ID 2058) in FIX 4.4 where it looks as follows:
Union datatypes can be Reserved100/1000/4000Plus, which are formally defined as base type Pattern “100/1000/4000” and above. They are only used for integer fields. Then there is also the datatype Tenor (also has base type Pattern) for String fields, e.g. SettlType(63).
In the case of Reserved100/1000/4000Plus it means that the tag may take additional integer values not defined in the code set. The values need to start at 100/1000/4000 respectively.
What about the case of StipulationType then? If a counterpart sends StipulationType=XXX, how can my application know that it is an acceptable value if there is no unionDataType?
If you have not agreed any additional values bilaterally then you can reject such values. If you agree additional values, they should be part of your data dictionary. There are no specific additional values for StipulationType. Union datatypes are only used by FIX if the values are specific, e.g. “D5” in the case of SettlType(63) that is defined as follows in addition to SettlTypeCodeSet:
Dx = FX tenor expression for days, e.g. D5, where x is any integer > 0
Mx = FX tenor expression for months, e.g. M3, where x is any integer > 0
Wx = FX tenor expression for weeks, e.g. W13, where x is any integer > 0
Yx = FX tenor expression for years, e.g. Y1, where x is any integer > 0
That snippet does not show the version it is from and it does not show the component SideCrossOrdModGrp that was added with FIX 4.4. The file MsgContents.xml in the 2009 Basic repository shows the version at the top, e.g.
<dataroot xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
copyright="Copyright (c) FIX Protocol Ltd. All Rights Reserved."
edition="2009"
xsi:noNamespaceSchemaLocation="../../schema/MsgContents.xsd"
version="FIX.4.3">
or
<dataroot xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
copyright="Copyright (c) FIX Protocol Ltd. All Rights Reserved."
edition="2009"
xsi:noNamespaceSchemaLocation="../../schema/MsgContents.xsd"
version="FIX.4.4">