Query on PartyIDs repeating group tags


Do we need to follow a specific order when populating party related repeating group information in the fix message.What is the order that the below tags needs to be in
Can someone help me with the above query and provide a sample fix message.And would also like to know if there is any reference for these kind of information.


Sample Raw Message:

Common Structure for repeating groups
–separatorTag() – Mandatory tag act as a group separator (order specific)
–OtherTag -> It is not required to be in any order

Eg :

  • 453 will act as a repeating group tag
    – 448 will act as a group separator
    – 447,452,802 will be the other tags present in the group (not order specific)
    Correct Order:
    Case1 - 453,448,447,452,802,448,447,452,802
    Case2 - 453,448,452,447,802,448,447,802,452

Wrong Order:
Case1 - 453,448,447,452,802,447,452,448,802
Case2 - 453,448,452,447,802,802,447,452,448

We have used this type of repeating groups predominantly in our PhiFIX (FIX Engine, Test Suite, Monitoring, Certification, Simulation) Suite products.

For more, visit https://javarevisited.blogspot.com/2011/02/repeating-groups-in-fix-protcol.html#axzz5fDE46MUn


The canonical reference for this is the FIX specs - the Party repeating group was introduced in FIX4.3

The online FIXimate reference: (http://fiximate.fixtrading.org/latestEP/) is useful as a quick reference.

While many brokers and test tools like the above referenced may be liberal in what they accept there is a canonical ordering to group tags past the more mandatory count tag and first tag.

Here’s the link to the component in the latest version of FIX



First of all, ordering of tags only applies to the tag=value syntax (aka encoding) where it is needed to allow message parsing. Other FIX encodings such as FIXML, FAST and SBE have separate metadata (schema files) that removes the need for a specific order.

The FIX specification clearly defines the rules for ordering of repeating groups for tag=value syntax in Volume 1:

Fields within repeating data groups must be specified in the order that the fields are specified in the message definition within the FIX specification document. The NoXXX field where XXX is the field being counted specifies the number of repeating group instances that must immediately precede the repeating group contents.

Hence, it is officially not allowed to change the order inside a repeating group. Your counterparty may raise an error if you do not send the fields in the standard order. One or more fields inside a repeating group are mandatory. It is always the first field that serves as implicit delimiter for parsing of repeating group instances.

If the repeating group is used, the first field of the repeating group is required. This allows implementations of the protocol to use the first field as a “delimiter” indicating a new repeating group entry. The first field listed after the NoXXX, then becomes conditionally required if the NoXXX field is greater than zero.

Note that the first “field” may be another repeating group or (non-repeating) component. The first field of this element then becomes required and serves as an implicit delimiter for parsing.