Message rejections, wildcards, bid/offer & response times

, ,
1

Imported from previous forum

2

[ original email was from John Hardman - yiq12@dial.pipex.com ]
Please see list of questions below. I am a newcomer to FIX so please forgive me if I am asking questions that may seem obvious to you …

Regards,

John Hardman.

(1) I need to be able to reject a Security Definition Request using a Security Definition Message (MsgType = d). This may be for one of a number of application specific reasons. Would it be appropriate to set SecurityResponseType (field 323) to 5 (Reject Security Proposal) or does this value (5) have some more specific meaning (relating to the word Proposal)?

(2) In a Market Data Request message (MsgType = V) is there any value that can be placed in the Symbol field (field 55) to mean "all instruments"? I would like to use a wildcard of some sort in this field instead of having to list thousands of instruments. Alternatively, is there some other way of using a wildcard in this message, perhaps by setting NoRelatedSym to zero ?

(3) When transmitting best bid and/or offer prices which would be the preferred FIX message to use, "Quote" or "Market Data - Incremental Refresh"? Why?

(4) In a typical point-to-point FIX session, if a client requests data from a server that does not currently have the data but where the server knows it will have the data in perhaps 3 or 4 minutes, would the server typically reject the query, or would it leave the query outstanding for 3-4 minutes until the data becomes available and reply only then?

3

[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> (2) In a Market Data Request message (MsgType = V) is there any value that can be placed in the Symbol field (field 55) to mean "all instruments"? I would like to use a wildcard of some sort in this field instead of having to list thousands of instruments. Alternatively, is there some other way of using a wildcard in this message, perhaps by setting NoRelatedSym to zero ?

In developing the Market Data messages, we considered adding support for wildcard requests, and ways of constraining symbols, i.e. everything of one instrument type (options, futures, stocks…), all symbols on one exchange, all symbols in an index, etc.

Nothing ever happened with this. We felt it was outside the scope of the Market Data messages, as it is more of a general symbology issue which is applicable across many message types. It is my guess that Market Data Request and the associated Market Data Request Reject message are only an academic exercise. People will generally use just the Market Data - Incremental Refresh message in "unsolicited" mode, i.e. you connect to a given port at an ECN or Exchange and you will receive an unsolicited stream of the activity at that ECN or Exchange.

If this is needed functionality, I suggest people collaborate and draft a method of extending the FIX symbology fields to allow for specifying such wildcard requests in a way applicable to all request messages, and propose this for inclusion in the next FIX version.

> (3) When transmitting best bid and/or offer prices which would be the preferred FIX message to use, "Quote" or "Market Data - Incremental Refresh"? Why?

Quote is of extremely limited use. It can be used to transmit 2-sided quotes, i.e. top of book information.

Market Data - Incremental Refresh has the following advantages:

  • It can transmit depth of book, not just the top.

  • It can transmit more types of information. Quotes, trades, closing prices, and more can all be represented in the same message. It was designed to be a general solution for market data.

  • It is more bandwidth efficient. Quote allows for sending 2 sides on one security in one message. Market Data - Incremental Refresh allows you to send updates to many different symbols in the same message. This can significantly reduce the number of FIX messages sent, as well as reducing bandwidth because the data wasted in the FIX header and trailer can encapsulate the equivalent of many Quote messages.

> (4) In a typical point-to-point FIX session, if a client requests data from a server that does not currently have the data but where the server knows it will have the data in perhaps 3 or 4 minutes, would the server typically reject the query, or would it leave the query outstanding for 3-4 minutes until the data becomes available and reply only then?

FIX doesn’t tell you how to do your business. It only tells you how to represent that business over the wire. The behavior in this scenario is something which should be decided between counterparties.