Hello FIX community,
I am looking to add a custom field in 263= in order to include my trade history in the 35=W because I can’t find a field satisfying my requirement in the FIX latest. Can you please share with me the conventions that I should respect (what field number should I commence with etc) ?
Thank you in advance for your help
SubscriptionRequestType(263) is a field and you are asking about a custom value, not a custom field in a field. The field you mention does not support custom values.
I suggest that you rather look into the FIX market data statistics messages, e.g. MarketDataStatisticsReport(35=DP) to provide historical data. You can find detailed information on these messages in EP191. You can define date ranges to request trade data for a specific period in time.
Thank you @hanno.klein for your help. However, is it possible to adjust the 35=W and add a costum tag just like 263= and 265= in the same message to identify the trade history and what convention to respect ?
@amani99, conventions are defined here. However, it is also not FIX compliant to clone key fields that do not support custom values, e.g. to define MySubscriptionType(20000) or MyMDUpdateType(20001). If you describe your requirement in more detail, there may already be a standard way of doing this without needing custom fields.
Thank you for your precious help @hanno.klein .
If you describe your requirement in more detail, there may already be a standard way of doing this without needing custom fields.
My requirement consist in how to identify the subscription type requested (in 35=V) giving that the client can request either having the trades history or not. The trade history consist in having all the trades that accured in the system since the beginnig of the trading day until the moment when the the response is sent (in 35=W).
Assuming in 35=V, we have 20000 (MySubscriptionType) = Y; in this case the client will subscripe to the trade history, so he will receive snapshot + trade history.
I hope this can help inderstanding my requirement.
@amani99 the existing field SubscriptionRequestType(263) is only to subscribe for updates after issuing the request. One subscribes to a real-time feed if you will. I would strongly advise to separate real-time market data updates from historical information. Take a look at how exchanges like CME or Eurex do this. They have separate channels for this. Real-time data is primarily to take investment decisions. Historical data is more for analytical purposes.
Offering the possibility of requesting all information since the beginning of the trading day would offer a recovery method for your users. You could easily become overwhelmed with such requests, especially at the end of day when everybody would request all trades of the current day once more “just to be sure to have everything”.
Rather than adding a user-defined field cloning SubscriptionRequestType(263), I would use FIX Application Sequencing for your purposes. Assign ApplID(1180) and ApplSeqNum(1181) only to market data messages with trades. The user can then ask for all trades of the current day by setting ApplBegSeqNum(1182)=1 in ApplicationMessageRequest(35=BW). This is equivalent to a replay of previously sent messages on the application level. Note that this is not the same as the ResendRequest(35=2) message on the session level that is unable to distinguish between FIX message types, let alone different kinds of content sent with the same FIX message type.