Certain features of the FIX Protocol which were implemented in earlier versions of the FIX Protocol specification, have been removed and replaced by a different approach. Such features have been labeled as "Replaced" throughout the FIX Specification document. The replaced feature is no longer supported by this version of the FIX Protocol specification.
These features may or may not have been "Deprecated" in a previous version. Deprecation implies that implementations must support both approaches during the deprecation period. Removing and replacing a features without a deprecation period is based upon:
The rationale behind removing a feature is based upon either:
The new, supported approach for each removed feature is identified below:
1. Replaced Field: ExecTransType (tag 20) and values in ExecType and OrdStatus fields [replaced in FIX 4.3]
The ExecTransType field introduced in FIX 2.7 has been removed and its values have been incorporated within the ExecType field. The ExecType field introducted in FIX 4.1 has had several values removed and a new value to represent the combination of the removed values. The ExecTransType and ExecType fields have effectively been merged into the ExecType field thus the removal of ExecTransType. Each field attempted to designate the type of Execution Report message received in a slightly different way. Both fields were designated as required. This became confusing and should be simplified by a single, merged field with the following mapping table:
2. Replaced Fields: MaturityDay (tag 205) and UnderlyingMaturityDay (tag 314) [replaced in FIX 4.3]
The MaturityDay <205> field introduced in FIX 4.1 has been removed and replaced by the MaturityDate <541> field. The MaturityMonthYear <200> field can still be used for standardized derivatives which are typically only referenced by month and year (e.g. S&P futures).
The UnderlyingMaturityDay <314> field introduced in FIX 4.2 has been removed and replaced by the UnderlyingMaturityDate <542> field. The UnderlyingMaturityMonthYear <313> field can still be used for standardized derivatives which are typically only referenced by month and year (e.g. S&P futures).
3. Replaced Fields: ExecBroker (tag 76), BrokerOfCredit (tag 92), ClientID (tag 109), ClearingFirm (tag 439), ClearingAccount (tag 440), and SettlLocation (tag 166) [replaced in FIX 4.3]
The ExecBroker (tag 76), BrokerOfCredit (tag 92), ClientID (tag 109), ClearingFirm (tag 439), ClearingAccount (tag 440), and SettlLocation (tag 166) fields introduced prior to FIX 4.3 have been removed and the equivalent values can now be specified via PartyRole, PartyID, and PartyIDSource. In addition this <Parties> "component block" is flexible enough to allow new "roles" or types of firm identification to be specified without a corresponding increase in the number of FIX fields. All of the old field values can be specified via the following mapping table:
4. Replaced Field Enumerations for Futures and Options for SecurityType (tag 167) with CFICode (tag 461) [replaced in FIX 4.3]
The following Security Type values can be specified using CFICode via the following mapping table:
5. Replaced Field: PutOrCall (tag 201) and UnderlyingPutOrCall (tag 315) with CFICode (tag 461) [replaced in FIX 4.3]
The CFICode was introduced to improve granularity in specifying security type. The adoption of CFICode <461> has made the PutOrCall <201> and UnderlyingPutOrCall <315> redundant. The PutOrCall values are numeric and this has led to confusion on their usage as the data is not self describing. The CFICode uses a more readable format of "P" and "C" for put and call.
PutOrCall values can be specified using CFICode via the following mapping table:
6. Replaced Field: CustomerOrFirm (tag 204) with OrderCapacity (tag 528) [replaced in FIX 4.3]
The Rule80A <47> and CustomerOrFirm <204> values have been merged and generalized into the new OrderCapacity <528> field. This was done to provide a more generalized approach to identifying order capacity across markets.
CustomerOrFim values can be specified using OrderCapacity via the following mapping table:
7. Replaced values: OptAttribute (tag 206) with values in CFICode (tag 461) [replaced in FIX 4.3]
The CFICode (tag 461) permits specification of the expiration style for options using more meaningful acronyms "A" for American and "E" for European. These values will replace the values currently used by some markets in the OptAttribute field. OptAttribute will still be used for versioning the option contract in the event of a corporate action, such as a split or merger, but will eliminate the problem when both the expiration style and a version number must be specified.
Certain OptAttribute values can be specified using CFICode via the following mapping table:
8. Replaced values: AllocTransType (tag 71) with values in AllocType (tag 626) [replaced in FIX 4.3]
The AllocTransType (tag 71) field specified both the type of "transaction": new, cancel, replace and the type or purpose of the Allocation message. A new field AllocType was introducted in FIX 4.3 which specifies the type or purpose of the Allocation message. Three fields were removed from AllocTransType and are now part of AllocType. In addition, AllocType supports additional values which were not defined in AllocTransType.
Certain AllocTransType values can be specified using AllocType via the following mapping table:
9. Replaced Field: RelatdSym (tag 46) with Symbol (tag 55) [replaced in FIX 4.3]
The RelatdSym (tag 46) field used in the News and Email messages prior to FIX 4.3 has been replaced by the Symbol (tag 55) field thus allowing the News and Email messages to use the same <Instrument> component block as other FIX application messages.