FIX Standard Errors and Omissions 2024

Error in field usage comment of RootPartyID(1117) in RootParties component:

Used to identify source of RootPartyID. Required if RootPartyIDSource is specified. Required if NoRootPartyIDs > 0.

should be

Required if NoRootPartyIDs(1116) > 0.
Identification of the party.

Close to 100 NumInGroup fields of FIX Latest still have an abbreviated name in the Orchestra XML file. FIX Latest uses the Orchestra attribute “abbrName” only for FIXML encoding where NumInGroup fields are not present due to the syntax of XML. More than 400 NumInGroup fields of FIX Latest do not use this attribute, starting with fields added after FIX 5.0. [NoOfSecSizes(1177)] is probably the last one (https://fiximate.fixtrading.org/en/FIX.Latest/tag1177.html).

Note that FIXimate intentionally suppresses the display of the value of “abbrName” for fields with datatype NumInGroup but they are present in the Orchestra XML file. Proposal is to remove the attribute “abbrName” from all NumInGroup fields in FIX Latest.

Typo in elaboration of PosAmtType=ENDV (End value):

Principal amount of a securities financing transaction on matuity date.

In SecurityListRequest, field SubscriptionRequestType - 263 is described as pertaining to SecurityStatus messages rather than SecurityDefinition/SecurityListUpdateReport messages. It makes more sense to me if the SubscriptionRequestType relates to the Security List dialogue.

image

@davidcgibbs thanks for pointing this out. Looks like the same field usage comment is being used for four different messages and none of them provide a security status. Most of them were added with FIX 4.3.

A short analysis shows that there is a more serious issue with the request message SecurityTypeRequest(35=v) and the report message SecurityTypes(35=w). The message descriptions are identical but only make sense for the request. The request does not have SubscriptionRequestType(263) but the report message does. It should probably be the other way around but was introduced in FIX 4.3 in this manner, to be analyzed.

The message description for the report is correct up to and including FIX 4.4 and should be as follows:

The Security Type message is used to return a list of security types available from a counterparty or market.

1 Like

Missing “T” at the start of the message description for StreamAssignmentReport in OrchestraFIXLatest.md

            <fixr:annotation>
            <fixr:documentation purpose="SYNOPSIS">
                he StreamAssignmentReport message is in response to the StreamAssignmentRequest message. It provides information back to the aggregator as to which clients to assign to receive which price stream based on requested CCY pair. This message can be sent unsolicited to the Aggregator from the Price Maker.</fixr:documentation>
        </fixr:annotation>

Tablature (specifically md2orchestra) has an issue with a special case of a FIX NumInGroup field that has been implemented as a code set. The field is NoSides(552) and it is being used in four repeating groups (basically trade capture report and cross order messages). FIXimate shows it with a datatype (NumInGroup) and a code set (NoSidesCodeSet). Background is the objective to limit the cardinality of the repeating group to one or two. Trades as well as cross orders have either one or two sides being sent.

The Orchestra XML file of FIX Latest defines the datatype of the code set to NumInGroup. The field itself is defined as a code set (removed non-essential elements for clarity).

<fixr:field abbrName="NoSides" type="NoSidesCodeSet" added="FIX.4.3" name="NoSides" id="552">
    <fixr:annotation>
        <fixr:documentation purpose="SYNOPSIS">
            Number of Side repeating group instances.</fixr:documentation>
    </fixr:annotation>
</fixr:field>

<fixr:codeSet name="NoSidesCodeSet" id="552" type="NumInGroup" added="FIX.4.3">
    <fixr:code name="OneSide" id="552001" value="1" sort="1" added="FIX.4.3"/>
    <fixr:code name="BothSides" id="552002" value="2" sort="2" added="FIX.4.3"/>
</fixr:codeSet>

This causes Tablature to treat NoSides(552) as a normal field reference within the repeating group and raise the error “First group field not NumInGroup datatype” followed by a second error “Unknown group”. The resulting XML file then defines the repeating group as follows:

<fixr:group id="2061" name="TrdCapRptSideGrp">
    <fixr:fieldRef id="552"/>
    <fixr:fieldRef id="54"/>
    ...

Here is a simple bash command that can be used to correct this issue:

sed -i "" 's/fixr:fieldRef\(.*id="552"\)/fixr:numInGroup\1/g' "myOrchestra.xml"

If you want to express the limitation of the cardinality to 1 or 2, then you can use Orchestra attributes for the group definition as follows:

<fixr:group id="2061" name="TrdCapRptSideGrp" implMinOccurs="1" implMaxOccurs="2">
    <fixr:numInGroup id="552"/>
    <fixr:fieldRef id="54"/>
    ...

Typo in MiscFeeTypeCodeSet value 15 (added with EP204):

Trade reporting [Elaboration: The fee charged to recover the cost of trade reporting, e.g. corporate bonds and structured products reported to FINRA TRACE.

should be

The fee charged to recover the cost of trade reporting, e.g. corporate bonds and structured products reported to FINRA TRACE.

Duplicate of issue reported by GTCPM on April 16
http://forum.fixtrading.org/t/fix-standard-errors-and-omissions-2024/17472/11

Jira SPEC-2769 opened for data base datatype of String issue.

SPEC-2770 has been opened to correct documentation and implementation of SecuritiesReferenceData messages.