OnixS
Dictionary icon

Appendix 6-F. Replaced Features and Supported Approach – FIX 4.3 – FIX Dictionary

Messages by MsgType | Messages by Name | Fields by Tag | Fields by Name | FIX 4.3 | Home

Appendix 6-F

Replaced Features and Supported Approach
  1. Replaced Field: ExecTransType (tag 20) and values in ExecType and OrdStatus fields [replaced in FIX 4.3]
  2. Replaced Fields: MaturityDay (tag 205) and UnderlyingMaturityDay (tag 314) [replaced in FIX 4.3]
  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]
  4. Replaced Field Enumerations for Futures and Options for SecurityType (tag 167) with CFICode (tag 461) [replaced in FIX 4.3]
  5. Replaced Field: PutOrCall (tag 201) and UnderlyingPutOrCall (tag 315) with CFICode (tag 461) [replaced in FIX 4.3]
  6. Replaced Field: CustomerOrFirm (tag 204) with OrderCapacity (tag 528) [replaced in FIX 4.3]
  7. Replaced values: OptAttribute (tag 206) with values in CFICode (tag 461) [replaced in FIX 4.3]
  8. Replaced values: AllocTransType (tag 71) with values in AllocType (tag 626) [replaced in FIX 4.3]
  9. Replaced Field: RelatdSym (tag 46) with Symbol (tag 55) [replaced in FIX 4.3]

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:

  • Supporting both approaches would result in a high degree of complexity and/or ambiguity.

The rationale behind removing a feature is based upon either:

  • Actual use and implementation of the feature identified major shortcomings necessitating a re-design.
  • Additional business requirements have been identified which the feature is unable to expand and properly support in its present form.

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:

Removed Value within ExecTransType (20) field Removed Value within OrdStatus (39) field Removed Value within ExecType (150) field ExecType (150)
0 New (various)
1 Cancel H Trade Cancel
2 Correct G Trade Correct
3 Status H Order Status
5 Replaced 5 Replace
1 Partial Fill F Trade
2 Fill

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:

Removed Field PartyRole (452)
(also see Volume 1: "Glossary")		 PartyID (448) PartyIDSource (447) PartySubID (523)
ExecBroker (tag 76) 1 Executing Broker (value) (various)
BrokerOfCredit (tag 92) 2 Broker Of Credit (value) (various)
ClientID (tag 109) 3 Client ID (value) (various)
ClearingFirm (tag 439) 4 Clearing Firm (value) (various)
ClearingAccount (tag 440) 4 Clearing Firm (value)
SettlLocation (tag 166) 10 Settlement Location CED = CEDEL
DTC = Depository Trust Company
EUR = Euroclear
FED = Federal Book Entry
PNY = Physical
PTC= Participant Trust Company		 C Generally accepted market participant id
ISO Country Code (Local Market Settle Location) E ISO Country Code

4. Replaced Field Enumerations for Futures and Options for SecurityType (tag 167) 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 values for futures and options in SecurityType <167> redundant.

The following Security Type values can be specified using CFICode via the following mapping table:

Value Removed From
SecurityType (tag 167)		 CFICode (tag 461) value
"FUT" Future First position of CFICode = "F"
"OPT" Option First position of CFICode = "O"

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:

Removed PutOrCall value CFICode (tag 461) value
0 Put First position of CFICode = "O" Second position of CFICode = "P"
1 Call First position of CFICode = "O" Second position of CFICode = "C"

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:

Removed Field CustomerOrFirm (tag 204) values OrderCapacity (tag 528) value
0 Customer A - Agency
1 Firm P - Principal

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:

Values Removed From OptAttribute (tag 206) CFICode (tag 461)
L American First Position "O" Second Position "C" or "P" Third Position "A" for American Style Expiration
S European First Position "O" Second Position "C" or "P" Third Position "E" for European Style Expiration

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:

Values Removed From AllocTransType (tag 71) AllocType (tag 626)
0

New

(Note: "New" was dual-purpose:
  1. a new transaction (this meaning remains)
  2. buyside calculated allocation
The buyside calculated allocation meaning has been replaced by AllocType="Buyside Calculated") 		1 Buyside Calculated (includes MiscFees and NetMoney)
3 Preliminary (without MiscFees and NetMoney) 2 Buyside Preliminary (without MiscFees and NetMoney)
4 Calculated (includes MiscFees and NetMoney) 3 Sellside Calculated Using Preliminary (includes MiscFees and NetMoney)
5 Calculated without Preliminary (sent unsolicited by broker, includes MiscFees and NetMoney) 4 Sellside Calculated Without Preliminary (sent unsolicited by sellside, includes MiscFees and NetMoney)

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.

 
OnixS
OnixS

Search the site