Is it ok to nest SettlType and SettlDate and SettlCurrency in InstrmntGrp component?

1

My firm is about to launch an API to support NDF markets for order submission and planning to include 63, 64 and 120 within the Instrument Group component which describes the actual NDF contract as a Security.

Is it ok to nest SettlType and SettlDate and SettlCurrency as part of InstrumntGrp component?

Thanks!

2

No, it is non-compliant to change the structure of a FIX message. This includes fields from outside of non-repeating components such as being moved into the component. The wire format would change for some encodings (e.g. FIXML) and break applications. What is the underlying problem leading to the question?

3

Thanks Hanno,
We are looking to use SecurityList(35=y) to provide a list of valid NDF instruments allowed on our system. We would like to provide the Value Date of an NDF via tag 64 and the Fixing Date via tag 541 and assigning this combination (among other attributes) to a specific SecurityID (tag 48).
Is 63 also not compliant to use in SecurityList35=y)?

4

FIX is not 100% consistent when it comes to the attributes that are part of the Instrument component and those that are not. Whatever the design decision was at the time, they can no longer be changed, e.g. Currency(15) and SettlType(63) are not part of the Instrument component. This simply means that whenever such attributes are needed to go along with an instrument they have to be added to the message, typically on the same level as the instrument itself. FIX has not consistently added such attributes to all messages containing an instrument and is rather waiting for related business requirements to come up from the FIX community (like you have).

SettlDate(64) typically changes based on the trade date and is not static for the major asset classes. This is different for NDFs and hence is perceived as part of the instrument definition. MaturityDate(541) is part of the instrument and hence not an issue.

The ideal solution is to submit a standard Gap Analysis as a FIX member through a FIX working group to the Global Technical Committee in order to add fields to messages. The second best solution is to add the fields in a FIX-compliant manner and using the discussion forum to validate your choices. This allows others to follow although it is formally still a user-defined approach until someone submits a Gap Analysis to extend the FIX standard.

So let’s be specific. My suggestion is to add SettlType, SettlDate and SettlCurrency to the SecListGrp component of SecurityList(35=y). This is the same level as Currency(15) which falls into the same category as the fields you would like to add. Make sure you point out the user-defined addition in your Rules of Engagement. 100% compliant FIX engines would otherwise reject the message based on the FIX Repository which does not have these fields in the message.

5

After further internal discussions, we’ve decided to take your suggestion and place 63, 64 and 120 SecListGrp component in SecurityList(35=y). We also will be adding these tags in (35=W) as part of MDFullGrp component. Thanks for your help and your valuable input in these forums. We will be looking to apply for FIX membership as well.

Thanks

6

Please edit your response as I guess you put something inside angle brackets “<…>”, e.g. <MDFullGrp>. This is taken as an instruction and does not show in the text. You need to escape it with a backslash “\” character.