SecurityList

, ,
1

Imported from previous forum

2

[ original email was from Ainhoa Dewisme - ainhoa.dewisme@reuters.com ]
Hello,

Is it correct workflow to send a SecurityList message (that includes a set of instruments) to a client application when no SecurityListRequest was sent by the application in the first place?

I was thinking of using SecurityList message to notify client application of instrument permissions upon login.

Thanks and Regards

Ainhoa

3

Sending a list of securities for reference data in response to logon is an acceptable use of the protocol.

Unfortunately, we don’t have the UnsolicitedIndicator (tag 325) on the Security messages - which is the standard method within FIX to indicate that a message was sent unsolicited (without a request). However, the absence of this field does not prohibit you from sending Security List messages unsolicited.

Also, when you are designing your application - make sure that the time delay due to publication of the list of securities upon logon (re-logon) is acceptable for your intra-day recover scenarios. The time delay has to be balanced with the benefits in providing the security list to repopulate a counterparty’s system after a failure of a client application. There is no best answer - there are tradeoffs that have to be considered.

Hello,

Is it correct workflow to send a SecurityList message (that includes a
set of instruments) to a client application when no SecurityListRequest
was sent by the application in the first place?

I was thinking of using SecurityList message to notify client
application of instrument permissions upon login.

Thanks and Regards

Ainhoa

4

[ original email was from Ainhoa Dewisme - ainhoa.dewisme@reuters.com ]
Thanks very much for the reply. I will keep your suggestion in mind.

Regards

Ainhoa

Sending a list of securities for reference data in response to logon is
an acceptable use of the protocol.

Unfortunately, we don’t have the UnsolicitedIndicator (tag 325) on the
Security messages - which is the standard method within FIX to indicate
that a message was sent unsolicited (without a request). However, the
absence of this field does not prohibit you from sending Security List
messages unsolicited.

Also, when you are designing your application - make sure that the time
delay due to publication of the list of securities upon logon (re-logon)
is acceptable for your intra-day recover scenarios. The time delay has
to be balanced with the benefits in providing the security list to
repopulate a counterparty’s system after a failure of a client
application. There is no best answer - there are tradeoffs that have to
be considered.

Hello,

Is it correct workflow to send a SecurityList message (that includes a
set of instruments) to a client application when no
SecurityListRequest was sent by the application in the first place?

I was thinking of using SecurityList message to notify client
application of instrument permissions upon login.

Thanks and Regards

Ainhoa