FIX 5.0

Messages by Category

Appendix 6-A

Appendix 6-B

Appendix 6-C

Appendix 6-D

Appendix 6-E

Appendix 6-F

Appendix 6-G

Appendix 6-H

Appendix D

Appendix E

Appendix F

Appendix G

Glossary

Component Blocks
StandardHeader
StandardTrailer
CommissionData
DiscretionInstructions
FinancingDetails
Instrument
InstrumentExtension
InstrumentLeg
LegBenchmarkCurveData
LegStipulations
NestedParties
OrderQtyData
Parties
PegInstructions
PositionAmountData
PositionQty
SettlInstructionsData
SettlParties
SpreadOrBenchmarkCurveData
Stipulations
TrdRegTimestamps
UnderlyingInstrument
YieldData
UnderlyingStipulations
NestedParties2
NestedParties3
AffectedOrdGrp
AllocAckGrp
AllocGrp
BidCompReqGrp
BidCompRspGrp
BidDescReqGrp
ClrInstGrp
CollInqQualGrp
CompIDReqGrp
CompIDStatGrp
ContAmtGrp
ContraGrp
CpctyConfGrp
ExecAllocGrp
ExecCollGrp
ExecsGrp
InstrmtGrp
InstrmtLegExecGrp
InstrmtLegGrp
InstrmtLegIOIGrp
InstrmtLegSecListGrp
InstrmtMDReqGrp
InstrmtStrkPxGrp
IOIQualGrp
LegOrdGrp
LegPreAllocGrp
LegQuotGrp
LegQuotStatGrp
LinesOfTextGrp
ListOrdGrp
MDFullGrp
MDIncGrp
MDReqGrp
MDRjctGrp
MiscFeesGrp
OrdAllocGrp
OrdListStatGrp
PosUndInstrmtGrp
PreAllocGrp
PreAllocMlegGrp
QuotCxlEntriesGrp
QuotEntryAckGrp
QuotEntryGrp
QuotQualGrp
QuotReqGrp
QuotReqLegsGrp
QuotReqRjctGrp
QuotSetAckGrp
QuotSetGrp
RelSymDerivSecGrp
RFQReqGrp
RgstDistInstGrp
RgstDtlsGrp
RoutingGrp
SecListGrp
SecTypesGrp
SettlInstGrp
SideCrossOrdCxlGrp
SideCrossOrdModGrp
TrdAllocGrp
TrdCapRptSideGrp
TrdCollGrp
TrdInstrmtLegGrp
TrdgSesGrp
UndInstrmtCollGrp
UndInstrmtGrp
UndInstrmtStrkPxGrp
TrdCapDtGrp
EvntGrp
SecAltIDGrp
LegSecAltIDGrp
UndSecAltIDGrp
AttrbGrp
DlvyInstGrp
SettlPtysSubGrp
PtysSubGrp
NstdPtysSubGrp
HopGrp
NstdPtys2SubGrp
NstdPtys3SubGrp
StrategyParametersGrp
SecLstUpdRelSymGrp
SecLstUpdRelSymsLegGrp
UnderlyingAmount
ExpirationQty
InstrumentParties
InstrumentPtysSubGrp
SideTrdRegTS
TrdCapRptAckSideGrp
UndlyInstrumentParties
UndlyInstrumentPtysSubGrp
DisplayInstruction
TriggeringInstruction
RootParties
RootSubParties
TrdSessLstGrp
MsgTypeGrp
Data Types
Type Description
Pattern is used to build on and provide some restrictions on what is allowed as valid values in fields that uses a base FIX data type and a pattern data type. The universe of allowable valid values for the field would then be the union of the base set of valid values and what is defined by the pattern data type. The pattern data type used by the field will retain its base FIX data type (e.g. String, int, char).
=> Reserved1000Plus is used to allow additional billaterally agreed upon enumerations to be defined for the field by using enumeration values starting at "1000" and above
=> Reserved100Plus is used to allow additional billaterally agreed upon enumerations to be defined for the field by using enumeration values starting at "100" and above
=> Reserved4000Plus is used to allow additional billaterally agreed upon enumerations to be defined for the field by using enumeration values starting at "4000" and above.
=> Tenor used to allow the expression of FX standard tenors in addition to the base valid enumerations defined for the field that uses this pattern data type. This pattern data type is defined as follows: Dx = tenor expression for "days", e.g. "D5", where "x" is any integer > 0 Mx = tenor expression for "months", e.g. "M3", where "x" is any integer > 0 Wx = tenor expression for "weeks", e.g. "W13", where "x" is any integer > 0 Yx = tenor expression for "years", e.g. "Y1", where "x" is any integer > 0
String Alpha-numeric free format strings, can include any character or punctuation except the delimiter. All char fields are case sensitive (i.e. morstatt != Morstatt).
=> Country representing a country using ISO 3166 Country code (2 character) values.
=> Currency representing a currency type using ISO 4217 Currency code (3 character) values.
=> Exchange representing a market or exchange - ISO 10383 Market Identifier Code (MIC).
=> LocalMktDate represening a Date of Local Market (vs. UTC) in YYYYMMDD format. This is the “normal” date field used by the FIX protocol. Valid values: YYYY = 0000-9999, MM = 01-12, DD = 01-31.
=> MonthYear String field representing month of a year. An optional day of the month can be appended or an optional week code. Valid formats: YYYYMM YYYYMMDD YYYYMMWW YYYY = 0000-9999, MM = 01-12, DD = 01-31, WW = w1, w2, w3, w4, w5.
=> MultipleCharValue field containing one or more single character space delimited values.
=> MultipleStringValue field containing one or more space delimited values.
=> TZTimeOnly representing time field that contains the time represented based on ISO 8601. This is the time with a UTC offset to allow identification of local time and timezone of that time. Format is HH:MM[:SS][Z | [ + | - hh[:mm]]] where HH = 00-23 hours, MM = 00-59 minutes, SS = 00-59 seconds, hh = 01-12 offset hours, mm = 00-59 offset minutes. Example: 07:39Z is 07:39 UTC Example: 02:39-05 is five hours behind UTC, thus Eastern Time Example: 15:39+08 is eight hours ahead of UTC, Hong Kong/Singapore time Example: 13:09+05:30 is 5.5 hours ahead of UTC, India time
=> TZTimestamp representing a time/date combination representing local time with an offset to UTC to allow identification of local time and timezone offset of that time. The representation is based on ISO 8601. Format is YYYYMMDD-HH:MM:SS[Z | [ + | - hh[:mm]]] where YYYY = 0000 to 9999, MM = 01-12, DD = 01-31 HH = 00-23 hours, MM = 00-59 minutes, SS = 00-59 seconds, hh = 01-12 offset hours, mm = 00-59 offset minutes Example: 20060901-07:39Z is 07:39 UTC on 1st of September 2006 Example: 20060901-02:39-05 is five hours behind UTC, thus Eastern Time on 1st of September 2006 Example: 20060901-15:39+08 is eight hours ahead of UTC, Hong Kong/Singapore time on 1st of September 2006 Example: 20060901-13:09+05:30 is 5.5 hours ahead of UTC, India time on 1st of September 2006
=> UTCDateOnly Date represented in UTC (Universal Time Coordinated, also known as “GMT”) in YYYYMMDD format. This special-purpose field is paired with UTCTimeOnly to form a proper UTCTimestamp for bandwidth-sensitive messages. Valid values: YYYY = 0000-9999, MM = 01-12, DD = 01-31.
=> UTCTimeOnly Time-only represented in UTC (Universal Time Coordinated, also known as "GMT") in either HH:MM:SS (whole seconds) or HH:MM:SS.sss (milliseconds) format, colons, and period required. This special-purpose field is paired with UTCDateOnly to form a proper UTCTimestamp for bandwidth-sensitive messages. Valid values: HH = 00-23, MM = 00-60 (60 only if UTC leap second), SS = 00-59. (without milliseconds) HH = 00-23, MM = 00-59, SS = 00-60 (60 only if UTC leap second), sss=000-999 (indicating milliseconds).
=> UTCTimestamp representing Time/date combination represented in UTC (Universal Time Coordinated, also known as “GMT”) in either YYYYMMDD-HH:MM:SS (whole seconds) or YYYYMMDD-HH:MM:SS.sss (milliseconds) format, colons, dash, and period required. Valid values: * YYYY = 0000-9999, MM = 01-12, DD = 01-31, HH = 00-23, MM = 00-59, SS = 00-60 (60 only if UTC leap second) (without milliseconds). * YYYY = 0000-9999, MM = 01-12, DD = 01-31, HH = 00-23, MM = 00-59, SS = 00-60 (60 only if UTC leap second), sss=000-999 (indicating milliseconds). Leap Seconds: Note that UTC includes corrections for leap seconds, which are inserted to account for slowing of the rotation of the earth. Leap second insertion is declared by the International Earth Rotation Service (IERS) and has, since 1972, only occurred on the night of Dec. 31 or Jun 30. The IERS considers March 31 and September 30 as secondary dates for leap second insertion, but has never utilized these dates. During a leap second insertion, a UTCTimestamp field may read "19981231-23:59:59", "19981231-23:59:60", "19990101-00:00:00". (see http://tycho.usno. navy.mil/leapsec.html)
=> data containing raw data with no format or content restrictions. Data fields are always immediately preceded by a length field. The length field should specify the number of bytes of the value of the data field (up to but not including the terminating SOH). Caution: the value of one of these fields may contain the delimiter (SOH) character. Note that the value specified for this field should be followed by the delimiter (SOH) character as all fields are terminated with an “SOH”.
char char value, can include any alphanumeric character or punctuation except the delimiter. All char fields are case sensitive (i.e. m != M).
=> Boolean char field containing one of two values: 'Y' = True/Yes 'N' = False/No
float Sequence of digits with optional decimal point and sign character (ASCII characters "-", "0" - "9" and "."); the absence of the decimal point within the string will be interpreted as the float representation of an integer value. All float fields must accommodate up to fifteen significant digits. The number of decimal places used should be a factor of business/market needs and mutual agreement between counterparties. Note that float values may contain leading zeros (e.g. “00023.23” = “23.23”) and may contain or omit trailing zeros after the decimal point (e.g. “23.0” = “23.0000” = “23” = "23."). Note that fields which are derived from float may contain negative values unless explicitly specified otherwise.
=> Amt value typically representing a Price times a Qty
=> Percentage value representing a percentage (e.g. .05 represents 5% and .9525 represents 95.25%). Note the number of decimal places may vary.
=> Price value representing a price. Note the number of decimal places may vary. For certain asset classes prices may be negative values. For example, prices for options strategies can be negative under certain market conditions. Refer to Volume 7: FIX Usage by Product for asset classes that support negative price values.
=> PriceOffset value representing a price offset, which can be mathematically added to a "Price". Note the number of decimal places may vary and some fields such as LastForwardPoints may be negative.
=> Qty value capable of storing either a whole number (no decimal places) of “shares” (securities denominated in whole units) or a decimal value containing decimal places for non-share quantity asset classes (securities denominated in fractional units).
int Sequence of digits without commas or decimals and optional sign character (ASCII characters "-" and "0" - "9" ). The sign character utilizes one byte (i.e. positive int is "99999" while negative int is "-99999"). Note that int values may contain leading zeros (e.g. “00023” = “23”). Examples: 723 in field 21 would be mapped int as |21=723|. -723 in field 12 would be mapped int as |12=-723|
=> Length representing the length in bytes. Value must be positive.
=> NumInGroup value that represents the number of repeating values in a group
=> SeqNum representing a message sequence number. Value must be positive
=> TagNum field representing a field's tag number when using FIX "Tag=Value" syntax. Value must be positive and may not contain leading zeros.

 

Onix Solutions