Imported from previous forum
FIXimate says that SubscriptionRequestType for SecurityListRequest is used to “Subscribe or unsubscribe for security status to security specified in request.”
Shouldn’t the SubscriptionRequestType determine if SecurityListUpdateReports are sent and not if SecurityStatusUpdateReports are sent? Isn’t that what SecurityStatusRequest is for? Should SecurityListUpdateReport messages just always be sent unsolicited?
Hi Robert,
Indeed the description of SubscriptionRequestType(263) in SecurityListRequest(35=x) is misleading.
Note that the same misleading description (i.e. typo) is also on SecurityDefinitionRequest(35=c)!
SecurityListUpdateReport(35=BK) are usually sent back only after subscription; i.e. SubscriptionRequestType(263)=Snapshot+Updates(1) in a SecurityListRequest(35=x)
Whilst SecurityDefinitionUpdateReport(35=BP) are in some implementations sent unsolicited (i.e. without a previous subscription)
I hope this helps,
Yuval
The paradigm is as follows:
SubscriptionRequestType allows for specifying whether your SecurityListRequest is intended to request only a one-time snapshot, in which case only the SecurityListReport is the response. If you request a “snapshot+update” you’re suppose to get an initial SecurityListReport to establish the snapshot based on the data at the time the snapshot is sent, followed by a SecurityListUpdateReport when there are updates based on the “inquiry” criteria you provided in the request message.
Thanks all.
One thing that’s confusing still: was this always the behavior or did it change with FIX 5.0? FIX 4.4 SecurityListRequest includes SubscriptionRequestType but FIX 4.4 does not have SecurityListUpdateReport. Is the behavior in FIX 4.4 to send a new SecurityList message on an update or is it in fact appropriate in FIX 4.4 to interpret SubscriptionRequestType to mean a request for SecurityStatusUpdates?
Unfortunately the history files I have doesn’t go far enough to provide the rational and requirements behind what went into 4.4 itself for these messages, and what the intentions were. SecurityListUpdateReport was added in 5.0 to serve the original requirement from exchanges to send unsolicited bulk updates (add/modify/delete) but can also be a response in a subscription request via the SecurityListRequest when it is a subscription (as oppose to snapshot) request.
I would interpret the SubscriptionRequestType field in SecurityListRequest of FIX 4.4 as either “give me a single snapshot” which would be communicated via SecurityList, or “give me a snapshot and updates” via SecurityList and subsequent SecurityList messages. It gets messy and this is likely another reason why SecurityListUpdate was added with explicit the ListUpdateAction field.
In rereading your original posting and response, you mentioned a SecurityStatusUpdateReport and a SecurityStatusUpdate… there are no such FIX messages today; just SecurityStatusRequest and SecurityStatus.
You can see in the FIXimate for latest EP that there are triples for certain messages that form this new paradigm in 5.0.
Could I request please that the comment for the SubscriptionRequestType for Security List be updated ?
Hi David,
we can enter an issue to capture the error in the usage descriptions for SubscriptionRequestType in the messages SecurityListRequest and SecurityDefinitionRequest. They should not refer to a status. We do not issue separate Extension Packs for such corrections but may incorporate them into a Gap Analysis submitted by one of the FIX members to the Global Technical Committee.
Please note that you can use FIXwiki to post such errors, e.g. see http://fixwiki.org/fixwiki/SecurityListRequest.
Thanks,
Hanno.