FIX Protocol Repeating Groups allow a subset of fields to repeat multiple times within the FIX Message.
Contents
- Example
- Number of Entries Field (NoXXX)
- First Field of Repeating Group Entry
- FIX Repeating Group Structure
- Repeating Group Fields Order
- Custom Repeating Group
- Nested Repeating Groups
- Required and Optional Repeating Group Fields
- Resources
FIX Protocol Repeating Groups allow a subset of fields to repeat multiple times within the FIX Message.
Example
For instance, an exchange can repeat the LegSecurityID (tag 602), LegSecurityIDSource (tag 603), LegSide (tag 624), and LegRatioQty (tag 623) fields in the Security Definition (35=d) message to describe all legs that make up the multileg security:
8=FIX.4.4<SOH>9=113<SOH>35=d<SOH>49=ONIXS<SOH>
...
<SOH>555=2<SOH>602=9131<SOH>603=8<SOH>624=2<SOH>623=1<SOH>602=2382<SOH>603=8<SOH>624=1<SOH>623=1<SOH>
...
<SOH>10=132<SOH>
- <SOH> is the non-printing ASCII "SOH", 0x01 character, which is used as the FIX message field terminator
- repeating group fields are marked with the blue color
A human-friendly representation of the FIX message portion above:
BeginString(8) = FIX.4.4
BodyLength(9) = 113
MsgType(35) = d (Security Definition)
SenderCompID(49) = ONIXS
...
// Begin of the repeating group
> NoLegs (555) = 2 (Number of the InstrumentLeg repeating group entries)
// Begin of the first repeating group entry
> LegSecurityID(602) = 9131
> LegSecurityIDSource(603) = 8 (Exchange Symbol)
> LegSide(624) = 2 (Sell)
> LegRatioQty(623) = 1 (The ratio of quantity for this individual leg relative to the entire multileg security)
// End of the first repeating group entry
// Begin of the second repeating group entry
> LegSecurityID(602) = 2382
> LegSecurityIDSource(603) = 8 (Exchange Symbol)
> LegSide(624) = 1 (Buy)
> LegRatioQty(623) = 1 (The ratio of quantity for this individual leg relative to the entire multileg security)
// End of the second repeating group entry
// End of the repeating group
...
CheckSum(10) = 132
Number of Entries Field (NoXXX)
The repeating group begins with a field that specifies the number of repeating group entries. The repeating group entries should immediately follow this field.
In the repeating group example above, this is the NoLegs (tag 555) field, so there are two entries (<SOH>555=2<SOH>). Other examples of such fields are: NoPartyIDs (tag 453),NoOrders (tag 73), NoAllocs (tag 78).
The FIX Specification refers to this field as the NoXXX field.
If the number of entries field is absent or its value is zero, the optional repeating group is absent.
First Field of Repeating Group Entry
The first field of the repeating group entry indicates its start. In the repeating group example above, this is the LegSecurityID (tag 602) field (<SOH>602=9131<SOH> and <SOH>602=2382<SOH>).
In the description of the repeating group, the first entry field is listed right after the number of entries field (NoXXX) and becomes conditionally if the NoXXX field is greater than zero.
FIX Repeating Group Structure
The following diagram shows the structure of a FIX Protocol Repeating Group:
Repeating Group Fields Order
The FIX Protocol requires that fields within repeating groups follow the same order as listed in the message definition within the FIX Specification document.
Custom Repeating Group
Due to the design of the FIX Protocol, the FIX Repeating Group cannot be parsed properly without the additional information that describes its structure. If the venue you work with uses non-standard fields in the repeating group, then the software that parses FIX repeating groups (e.g., FIX Engine) needs the description of these custom fields. Without this information, the software does not know when a repeating group begins or ends. Such FIX metadata definitions are known as FIX Dictionary, FIX Dialect, or Data Dictionary.
Nested Repeating Groups
Repeating groups can appear inside of another repeating group. In such cases, all entries of the inner repeating group belong to the single entry of the outer repeating group. There could be more than one level of nesting.
For example:
8=FIX.4.4<SOH>9=599<SOH>35=AE<SOH>49=ONIXS<SOH>
...
<SOH>552=2<SOH>54=1<SOH>453=2<SOH>448=Party1<SOH>447=D<SOH>452=11<SOH>448=Party2<SOH>447=D<SOH>452=56<SOH>54=2<SOH>453=2<SOH>448=Party3<SOH>447=D<SOH>452=11<SOH>448=Party4<SOH>447=D<SOH>452=56<SOH>...
<SOH>10=006<SOH>
- the outer repeating group fields are marked with the blue color
- the nested repeating group fields are marked with the brown color
- the number of entries fields (NoXXX) are marked with bold
- the first field of the repeating group entry is marked with italic
The portion of the TradeCaptureReport <AE> message above shows a nested Parties repeating group (NoPartyIDs, tag=453) for each report side. The Parties repeating group is nested within the Side repeating group (NoSides, tag=552), and as such, each entry of the Side repeating group contains two repeating group entries of Parties.
A human-friendly representation of the FIX message portion above:
BodyLength(9) = 599
MsgType(35) = AE (Trade Capture Report)
SenderCompID(49) = ONIXS
...
// Begin of the outer repeating group
> NoSides(552) = 2 (both sides)
// Begin of the first outer repeating group entry
> Side(54) = 1 (Buy)
// Begin of the inner repeating group of the first outer repeating group entry
>> NoPartyIDs(453)=2
// Begin of the first inner repeating group entry of the first outer repeating group entry
>> PartyID(448) = Party1
>> PartyIDSource(447) = D (Proprietary/Custom code)
>> PartyRole(452) = 11 (Order Origination Trader (associated with Order Origination Firm - e.g. trader who initiates/submits the order))
// End of the first inner repeating group entry of the first outer repeating group entry
// Begin of the second inner repeating group entry of the first outer repeating group entry
>> PartyID(448) = Party2
>> PartyIDSource(447) = D (Proprietary/Custom code)
>> PartyRole(452) = 56 (Acceptable Counterparty)
// End of the second inner repeating group entry of the first outer repeating group entry
// End of the inner repeating group of the first outer repeating group entry
// End of the first outer repeating group entry
// Begin of the second outer repeating group entry
> Side(54) = 2 (Sell)
// Begin of the inner repeating group of the second outer repeating group entry
>> NoPartyIDs(453) = 2
// Begin of the first inner repeating group entry of the second outer repeating group entry
>> PartyID(448) = Party3
>> PartyIDSource(447) = D (Proprietary/Custom code)
>> PartyRole(452) = 11 (Order Origination Trader (associated with Order Origination Firm - e.g. trader who initiates/submits the order))
// End of the first inner repeating group entry of the second outer repeating group entry
// Begin of the second inner repeating group entry of the second outer repeating group entry
>> PartyID(448) = Party4
>> PartyIDSource(447) = D (Proprietary/Custom code)
>> PartyRole(452) = 56 (Acceptable Counterparty)
// End of the second inner repeating group entry of the second outer repeating group entry
// End of the inner repeating group of the second outer repeating group entry
// End of the second outer repeating group entry
// End of the outer repeating group
...
CheckSum(10) = 006
Required and Optional Repeating Group Fields
- If the repeating group is used, the first field of the repeating group entry is required. In other words, it is conditionally required if the NoXXX field is greater than zero.
- The number of entries field (NoXXX) is required if at least one of the fields in the repeating group is required. If all members of a repeating group are optional, then the NoXXX field should also be optional.
- If the optional repeating group is absent, then it is recommended not to send the number of entries (NoXXX) field at all. Sending NoXXX=0 (e.g. NoLegs=0) for optional repeating group is valid but not recommended.
- If a repeating group field is listed as required, then it must appear in every entry of that repeating group.
- If a repeating group field is listed as optional, then it can appear on zero or more entry of that repeating group.