FIX Protocol repeating group
In this FIX protocol tutorial, I am going to share my experience about FIX repeating block or group. This is a fundamental concept of FIX protocol and used to carry repeating data. A correct understanding of various available FIX repeating groups e.g. PartyID block, Allocation repeating group etc is very important for writing FIX based software. In this FIX tutorial, I will explain about how to parse a repeating group, how to prepare a repeating group and how to understand a repeating group. If you like to know more about basic concepts in FIX protocol then you may find my FIX Protocol tutorial interesting.
In FIX protocol when a group of tags appears multiple time in an FIX message, they are called repeating group. These are essential to denote repeating entity in an FIX message e.g. take an example of PartyID repeating group which is used to denote Party trading on ID (India, Korea, Taiwan, China etc) market. I will keep our discussion around this particular repeating group to illustrate different points.
PartyID repeating group is made of following tags:
453 NoPartyIDs
448 PartyID
447 PartyIDSource
452 PartyRole
Every repeating group starts with a particular tag which specifies how many repeating tags are present within repeating group e.g. in case of PartyID repeating group NoPartyIDs(tag 453) denotes how many Party ID repeating entries are present in the message.
In this FIX protocol tutorial, I am going to share my experience about FIX repeating block or group. This is a fundamental concept of FIX protocol and used to carry repeating data. A correct understanding of various available FIX repeating groups e.g. PartyID block, Allocation repeating group etc is very important for writing FIX based software. In this FIX tutorial, I will explain about how to parse a repeating group, how to prepare a repeating group and how to understand a repeating group. If you like to know more about basic concepts in FIX protocol then you may find my FIX Protocol tutorial interesting.
In FIX protocol when a group of tags appears multiple time in an FIX message, they are called repeating group. These are essential to denote repeating entity in an FIX message e.g. take an example of PartyID repeating group which is used to denote Party trading on ID (India, Korea, Taiwan, China etc) market. I will keep our discussion around this particular repeating group to illustrate different points.
PartyID repeating group is made of following tags:
453 NoPartyIDs
448 PartyID
447 PartyIDSource
452 PartyRole
Every repeating group starts with a particular tag which specifies how many repeating tags are present within repeating group e.g. in case of PartyID repeating group NoPartyIDs(tag 453) denotes how many Party ID repeating entries are present in the message.
For example, NoPartyIDs=2 will state two Parties are present that there are two repeating groups are present in the message also such tag must come immediately before start of repeating group entries for example in case of PartyID block NoPartyIDs must come before repeating tags e.g. PartyRole
According to FIX protocol, each entry of a repeating group should have a specific field which in turn identifies the beginning of a group new entry. This field must occur in the raw message before any other tag from a single repeating group entry. In other words, these fields separate repeating group entries from each other. In the case of PartyID block see tag 448 PartyID which is the first tag of repeating group and mark the start of one group and end of other.
Repeating group inside repeating group
As per FIX protocol specification it is possible for repeating groups to appear inside of another repeating group on this case all entries of the inner repeating group belong to the single entry of the outer repeating group, they are commonly referred as SubIDs e.g. in PartyID instance block we could have another repeating group called NoOfSubIDs which is made of SubIDType and SubID.
The number of instances of a repeating group must match with the value specified by Number tags e.g. NoPartyIDs, otherwise, FIX Engine will not able to understand FIX message will reject as malformed FIX message.
2) Finding the leading tag which marks start and end of the repeating group.
According to FIX protocol, each entry of a repeating group should have a specific field which in turn identifies the beginning of a group new entry. This field must occur in the raw message before any other tag from a single repeating group entry. In other words, these fields separate repeating group entries from each other. In the case of PartyID block see tag 448 PartyID which is the first tag of repeating group and mark the start of one group and end of other.
Important aspects of FIX repeating group’s structure:
Well defined FIX messages assume all tags of a repeating group come in a particular order and appearance of any tag which doesn't belong to repeating group (according to the FIX specification) automatically indicates the end of the repeating group. The subsequent further appearance of tags from the repeating group is not allowed by the FIX Standard.Repeating group inside repeating group
As per FIX protocol specification it is possible for repeating groups to appear inside of another repeating group on this case all entries of the inner repeating group belong to the single entry of the outer repeating group, they are commonly referred as SubIDs e.g. in PartyID instance block we could have another repeating group called NoOfSubIDs which is made of SubIDType and SubID.
The number of instances of a repeating group must match with the value specified by Number tags e.g. NoPartyIDs, otherwise, FIX Engine will not able to understand FIX message will reject as malformed FIX message.
Parsing of a repeating group
While parsing a repeating group we must consider two important tags 1) Number tag (NoXXX) e.g. NoPartyIDs to check how many repeating groups are present2) Finding the leading tag which marks start and end of the repeating group.
Generally, every Repeating group has a particular tag that is used as a marker tag but in most cases they follow the order specified in FIX specification. But there is no hard line on that in most cases a FIX messages parser use Number tag to identify number of repeating group and then typically use the occurrence of the first documented tag of the repeating group to determine start and end of repeating group.
Formatting FIX message with repeating group
It’s good to follow the order of tags specified in the FIX Message specification while constructing a repeating group that allows FIX parser to use the first tag specified in FIX documents as marker tag for start and end of the repeating group.In Summary
1. When the group of tags appears multiple times in an FIX message we call them repeating group.
2. Number tag is a leading tag that specifies how many repeating groups are present in the FIX message e.g. NoPartyIDs
3. First tag specified in FIX Message specification is used as marker tag to mark start and end of a FIX message.
4. No of repeating groups must match with the number specified by No### tag e.g. NoPartyIDs
5. Follow the order of tags specified in the FIX Message specification while constructing a repeating group
6. A Repeating group can contain another repeating group within it.
7. PartyID blocks are introduced in FIX 4.3 so it will not work on earlier FIX protocol versions.
5 comments :
good tutorial ..have been searching for this info
In FX trading, MarketDataSnapshotFullReferesh, message type W got a repeating group called
NoMDEntries, tag 268
This specify details to each market data entry, quite useful.
Nice article and explaination. It would help a greate deal if you could demonstrate a sample FIXML to build to feed to a FIX Engine, that is where it is getting confusing (multiple instances of same tag can not exist in xml side by side)!
Hi,
How can I edit a FIX message. As part of my fx project I have to remove a value against a tag(523). How can I do that
Please add some example of Parties
Post a Comment