Imported from previous forum
Hi, I don’t quite understand the use of tha tags 63 and 64 (SettlType and SettlDate) in the context of market data messages. When one sends a market data request they are included at the instrument level (inside InstrmtMDReqGrp) which makes sense to me. However in the Marketdata Response they are included at the market data level (inside MDFullGrp). Does it mean that if I suscribe to a particular instrument that trades with different settlement types, say T, T+1, T+2 and T+3 but I’m only interested in T+3; then I have to clarify every MDEntry in the response with the settlmnt type, even though that they will be all the same?
Ej:
REQUEST:
264=1,146=1,55=InstrumentA,63=4,267=2,269=0,269=1
RESPONSE:
55=InstrumentA,268=2,269=0,270=1.5,271=1000,63=4,269=1,270=1.6,271=500,63=4
Thnaks
You do not have to attach SettlType and SettlDate to every instance of MDFullGrp even if it is technically possible. You could choose the first MDEntryType value of the request and populate the two fields only for that entry. You could also omit the fields from the response completely as MDReqID will link back to what the user requested and define the scope of what he is getting. As long as your Rules of Engagement are clear, your counterparties should know what to expect in the response you provide to them. Keep in mind that MarketDataSnapshotFullRefresh can be sent as a response to a request or unsolicited (no MDReqID), in which case it makes sense to populate SettlType and SettlDate but again also only on an entry type of the sender’s choice, e.g. MDEntryType = 6 (Settlement Price).
Hi, I don’t quite understand the use of tha tags 63 and 64 (SettlType and SettlDate) in the context of market data messages. When one sends a market data request they are included at the instrument level (inside InstrmtMDReqGrp) which makes sense to me. However in the Marketdata Response they are included at the market data level (inside MDFullGrp). Does it mean that if I suscribe to a particular instrument that trades with different settlement types, say T, T+1, T+2 and T+3 but I’m only interested in T+3; then I have to clarify every MDEntry in the response with the settlmnt type, even though that they will be all the same?
Ej:
REQUEST:
264=1,146=1,55=InstrumentA,63=4,267=2,269=0,269=1RESPONSE:
55=InstrumentA,268=2,269=0,270=1.5,271=1000,63=4,269=1,270=1.6,271=500,63=4Thnaks
Hello again Hanno,
After speaking with some of dev guys here at HSBC, we are attempting to reduce the amount of data sent in the 35=W message ( 35=X is not an option to use) and tag 63 and 64 have been highlighted as they are repeated with the same value.
If a client requests for a 35=V for a spt, then the spt information would be the same for the repeating group 268.(63/64)
Currently what we have as en example is:
8=FIX.4.4|9=1242|35=W|34=612|49=HSBCUKFIX|52=20130424-09:19:23|56=COBLOH01|57=COBLOH1|55=EUR/USD|262=181969972696529|268=17|269=0|270=1.30092|271=500000|64=20130426|299=008000093:A|63=SP|269=0|270=1.30091|271=500000|64=20130426|299=008000093:A|63=SP|269=0|270=1.30089|271=2000000|64=20130426|299=008000093:A|63=SP|269=0|270=1.30088|271=2000000|64=20130426|299=008000093:A|63=SP|269=0|270=1.30084|271=5000000|64=20130426|299=008000093:A|63=SP…
As you can see when there is a large number of rungs, the message can be large and can be sent numerous time within 1 second if the price/amount changes.
So what i was originally thinking was to take tag 63/64 and place them as part of the Instrument component but obviously the issue with this is that 63/64 are not defined here. Do you think this is possible or would you suggest as you did below to send it on the initial entry and the remove from the rest?
Ps Martin Habermann is one of the dev gus now working on this with me, he says hi.
Nadeem
You do not have to attach SettlType and SettlDate to every instance of MDFullGrp even if it is technically possible. You could choose the first MDEntryType value of the request and populate the two fields only for that entry. You could also omit the fields from the response completely as MDReqID will link back to what the user requested and define the scope of what he is getting. As long as your Rules of Engagement are clear, your counterparties should know what to expect in the response you provide to them. Keep in mind that MarketDataSnapshotFullRefresh can be sent as a response to a request or unsolicited (no MDReqID), in which case it makes sense to populate SettlType and SettlDate but again also only on an entry type of the sender’s choice, e.g. MDEntryType = 6 (Settlement Price).
Hi, I don’t quite understand the use of tha tags 63 and 64 (SettlType and SettlDate) in the context of market data messages. When one sends a market data request they are included at the instrument level (inside InstrmtMDReqGrp) which makes sense to me. However in the Marketdata Response they are included at the market data level (inside MDFullGrp). Does it mean that if I suscribe to a particular instrument that trades with different settlement types, say T, T+1, T+2 and T+3 but I’m only interested in T+3; then I have to clarify every MDEntry in the response with the settlmnt type, even though that they will be all the same?
Ej:
REQUEST:
264=1,146=1,55=InstrumentA,63=4,267=2,269=0,269=1RESPONSE:
55=InstrumentA,268=2,269=0,270=1.5,271=1000,63=4,269=1,270=1.6,271=500,63=4Thnaks
Shifting standard fields to a different level of nesting in the message is not a good idea and I would not advise to do that. The parser of your recipient should reject your message if you do that. The most compliant option is still to have the fields in the MDFullGrp component and omit values in entries where the value does not change compared to the previous entry. The second best option is to use user-defined fields on the root level, i.e. 5459 for SettlType and 5020 for SettlDate. Then it is up to the application level of your recipient to validate the content as opposed to the FIX engine. I also see that you seem to use a non-standard valid value for SettlType, i.e. “SP”. What does it stand for?
Regards,
Hanno.
Hello again Hanno,
After speaking with some of dev guys here at HSBC, we are attempting to reduce the amount of data sent in the 35=W message ( 35=X is not an option to use) and tag 63 and 64 have been highlighted as they are repeated with the same value.
If a client requests for a 35=V for a spt, then the spt information would be the same for the repeating group 268.(63/64)
Currently what we have as en example is:
8=FIX.4.4|9=1242|35=W|34=612|49=HSBCUKFIX|52=20130424-09:19:23|56=COBLOH01|57=COBLOH1|55=EUR/USD|262=181969972696529|268=17|269=0|270=1.30092|271=500000|64=20130426|299=008000093:A|63=SP|269=0|270=1.30091|271=500000|64=20130426|299=008000093:A|63=SP|269=0|270=1.30089|271=2000000|64=20130426|299=008000093:A|63=SP|269=0|270=1.30088|271=2000000|64=20130426|299=008000093:A|63=SP|269=0|270=1.30084|271=5000000|64=20130426|299=008000093:A|63=SP…
As you can see when there is a large number of rungs, the message can be large and can be sent numerous time within 1 second if the price/amount changes.
So what i was originally thinking was to take tag 63/64 and place them as part of the Instrument component but obviously the issue with this is that 63/64 are not defined here. Do you think this is possible or would you suggest as you did below to send it on the initial entry and the remove from the rest?
Ps Martin Habermann is one of the dev gus now working on this with me, he says hi.
Nadeem
You do not have to attach SettlType and SettlDate to every instance of MDFullGrp even if it is technically possible. You could choose the first MDEntryType value of the request and populate the two fields only for that entry. You could also omit the fields from the response completely as MDReqID will link back to what the user requested and define the scope of what he is getting. As long as your Rules of Engagement are clear, your counterparties should know what to expect in the response you provide to them. Keep in mind that MarketDataSnapshotFullRefresh can be sent as a response to a request or unsolicited (no MDReqID), in which case it makes sense to populate SettlType and SettlDate but again also only on an entry type of the sender’s choice, e.g. MDEntryType = 6 (Settlement Price).
Hi, I don’t quite understand the use of tha tags 63 and 64 (SettlType and SettlDate) in the context of market data messages. When one sends a market data request they are included at the instrument level (inside InstrmtMDReqGrp) which makes sense to me. However in the Marketdata Response they are included at the market data level (inside MDFullGrp). Does it mean that if I suscribe to a particular instrument that trades with different settlement types, say T, T+1, T+2 and T+3 but I’m only interested in T+3; then I have to clarify every MDEntry in the response with the settlmnt type, even though that they will be all the same?
Ej:
REQUEST:
264=1,146=1,55=InstrumentA,63=4,267=2,269=0,269=1RESPONSE:
55=InstrumentA,268=2,269=0,270=1.5,271=1000,63=4,269=1,270=1.6,271=500,63=4Thnaks
Thanks for the reply Hanno.
I agree, i wasnt keen on moving the fields either.
I will put the 2 options out there to the dev team. The non-standard ‘63=SP’ will not be used, we previously used 9063=SP ( for spt, i will make sure we use the correct values.
thanks for the help
Nadeem
Shifting standard fields to a different level of nesting in the message is not a good idea and I would not advise to do that. The parser of your recipient should reject your message if you do that. The most compliant option is still to have the fields in the MDFullGrp component and omit values in entries where the value does not change compared to the previous entry. The second best option is to use user-defined fields on the root level, i.e. 5459 for SettlType and 5020 for SettlDate. Then it is up to the application level of your recipient to validate the content as opposed to the FIX engine. I also see that you seem to use a non-standard valid value for SettlType, i.e. “SP”. What does it stand for?
Regards,
Hanno.Hello again Hanno,
After speaking with some of dev guys here at HSBC, we are attempting to reduce the amount of data sent in the 35=W message ( 35=X is not an option to use) and tag 63 and 64 have been highlighted as they are repeated with the same value.
If a client requests for a 35=V for a spt, then the spt information would be the same for the repeating group 268.(63/64)
Currently what we have as en example is:
8=FIX.4.4|9=1242|35=W|34=612|49=HSBCUKFIX|52=20130424-09:19:23|56=COBLOH01|57=COBLOH1|55=EUR/USD|262=181969972696529|268=17|269=0|270=1.30092|271=500000|64=20130426|299=008000093:A|63=SP|269=0|270=1.30091|271=500000|64=20130426|299=008000093:A|63=SP|269=0|270=1.30089|271=2000000|64=20130426|299=008000093:A|63=SP|269=0|270=1.30088|271=2000000|64=20130426|299=008000093:A|63=SP|269=0|270=1.30084|271=5000000|64=20130426|299=008000093:A|63=SP…
As you can see when there is a large number of rungs, the message can be large and can be sent numerous time within 1 second if the price/amount changes.
So what i was originally thinking was to take tag 63/64 and place them as part of the Instrument component but obviously the issue with this is that 63/64 are not defined here. Do you think this is possible or would you suggest as you did below to send it on the initial entry and the remove from the rest?
Ps Martin Habermann is one of the dev gus now working on this with me, he says hi.
Nadeem
You do not have to attach SettlType and SettlDate to every instance of MDFullGrp even if it is technically possible. You could choose the first MDEntryType value of the request and populate the two fields only for that entry. You could also omit the fields from the response completely as MDReqID will link back to what the user requested and define the scope of what he is getting. As long as your Rules of Engagement are clear, your counterparties should know what to expect in the response you provide to them. Keep in mind that MarketDataSnapshotFullRefresh can be sent as a response to a request or unsolicited (no MDReqID), in which case it makes sense to populate SettlType and SettlDate but again also only on an entry type of the sender’s choice, e.g. MDEntryType = 6 (Settlement Price).
Hi, I don’t quite understand the use of tha tags 63 and 64 (SettlType and SettlDate) in the context of market data messages. When one sends a market data request they are included at the instrument level (inside InstrmtMDReqGrp) which makes sense to me. However in the Marketdata Response they are included at the market data level (inside MDFullGrp). Does it mean that if I suscribe to a particular instrument that trades with different settlement types, say T, T+1, T+2 and T+3 but I’m only interested in T+3; then I have to clarify every MDEntry in the response with the settlmnt type, even though that they will be all the same?
Ej:
REQUEST:
264=1,146=1,55=InstrumentA,63=4,267=2,269=0,269=1RESPONSE:
55=InstrumentA,268=2,269=0,270=1.5,271=1000,63=4,269=1,270=1.6,271=500,63=4Thnaks