Closed uwezukwechibuzor closed 1 year ago
The Security List Request message is used to obtain a list of securities that match certain criteria, such as security type, market, sector, or other attributes. It allows the requester to get a broad overview of available securities.
Once the requester has received the Security List and identified a specific security of interest from the list, they can then send a Security Definition Request message to obtain detailed information about that particular security. The Security Definition Request message typically includes the security's symbol, exchange code, or other identifiers to specify the security for which detailed information is being requested.
In the Security Definition Request message, specific fields can be included to indicate the type of information needed, such as contract specifications, trading characteristics, market data, or other relevant details. The exact fields and their usage in the Security Definition Request message depend on the specific implementation and requirements of the trading system or the FIX protocol version being used.
The Security List Request message is used to obtain a list of securities that match certain criteria, such as security type, market, sector, or other attributes. It allows the requester to get a broad overview of available securities.
Once the requester has received the Security List and identified a specific security of interest from the list, they can then send a Security Definition Request message to obtain detailed information about that particular security. The Security Definition Request message typically includes the security's symbol, exchange code, or other identifiers to specify the security for which detailed information is being requested.
In the Security Definition Request message, specific fields can be included to indicate the type of information needed, such as contract specifications, trading characteristics, market data, or other relevant details. The exact fields and their usage in the Security Definition Request message depend on the specific implementation and requirements of the trading system or the FIX protocol version being used.
the Security List Request can be used to obtain information about the available security types. When sending a Security List Request, you can include filters or criteria to request a list of securities based on their security type.
The Security List Response received in response to the Security List Request will include information about the securities that match the requested criteria, including their security type. By examining the security type field in the Security List Response, you can identify the different types of securities available in the market.
Once you know the security types from the Security List Response, you can then use that information to construct a Security Definition Request message. In the Security Definition Request, you can specify the desired security type in the securityType field to request detailed information about securities of that specific type.
So, while the Security List Request itself does not provide the securityType field directly, it helps you discover the available security types by providing a list of securities that match your criteria. You can then use that information in subsequent Security Definition Requests to retrieve detailed information about securities of a specific security type.
The Security List Request (x) message is used to return a list of securities from the counterparty that match criteria provided on the request
Subscription for security status can be optionally specified by including the SubscriptionRequestType (263) field on the message.
SecurityListRequestType (559) specifies the criteria of the request:
The Security List (y) message is used to return a list of securities that matches the criteria specified in a Security List Request (x) .
TAG | FIELD NAME | FIXML | REQ'D | COMMENTS | ||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
<Standard Message Header> | Y | MsgType = y | ||||||||||||||||||||||||||||||||||||||||
320 | SecurityReqID | @ReqID | Y | |||||||||||||||||||||||||||||||||||||||
322 | SecurityResponseID | @RspID | Y | Identifier for the Security List (y) message | ||||||||||||||||||||||||||||||||||||||
560 | SecurityRequestResult | @ReqRslt | Y | Result of the Security Request identified by the SecurityReqID (320) | ||||||||||||||||||||||||||||||||||||||
393 | TotNoRelatedSym | @TotNoReltdSym | N | Used to indicate if the total number of securities being returned for this request. Used in the event that message fragmentation is required. | ||||||||||||||||||||||||||||||||||||||
893 | LastFragment | @LastFragment | N | Indicates if this message in a fragmented response | ||||||||||||||||||||||||||||||||||||||
146 | NoRelatedSym | SecL | C | Specifies the number of repeating symbols (instruments) specified | ||||||||||||||||||||||||||||||||||||||
=> | <Instrument> | C | Instrument of the requested Security | |||||||||||||||||||||||||||||||||||||||
=> | <Instrument Extension> | N | ||||||||||||||||||||||||||||||||||||||||
=> | <Financing Details> | N | ||||||||||||||||||||||||||||||||||||||||
=> | 711 | NoUnderlyings | Undly | N | Number of underlyings | |||||||||||||||||||||||||||||||||||||
=> | => | <Underlying Instrument> | C | Must be provided if Number of underlyings > 0 | ||||||||||||||||||||||||||||||||||||||
=> | 15 | Currency | @Ccy | N | ||||||||||||||||||||||||||||||||||||||
=> | <Stipulations> | N | ||||||||||||||||||||||||||||||||||||||||
=> | 555 | NoLegs | SecL | C | Number of legs that make up the Security | |||||||||||||||||||||||||||||||||||||
=> | => | <Instrument Leg> | C | Required if NoLegs (555) > 0 | ||||||||||||||||||||||||||||||||||||||
=> | => | 690 | LegSwapType | @SwapTyp | N | |||||||||||||||||||||||||||||||||||||
=> | => | 587 | LegSettlType | @SettlTyp | N | |||||||||||||||||||||||||||||||||||||
=> | => | <Leg Stipulations> | C | Required if NoLegs (555) > 0 | ||||||||||||||||||||||||||||||||||||||
=> | => | <Leg Benchmark Curve Data> | C | Required if NoLegs (555) > 0 | ||||||||||||||||||||||||||||||||||||||
=> | <Spread or Benchmark Curve Data> | N | ||||||||||||||||||||||||||||||||||||||||
=> | <Yield Data> | N | ||||||||||||||||||||||||||||||||||||||||
=> | 561 | RoundLot | @RndLot | N | ||||||||||||||||||||||||||||||||||||||
=> | 562 | MinTradeVol | @MinTrdVol | N | ||||||||||||||||||||||||||||||||||||||
=> | 336 | TradingSessionID | @SesID | N | ||||||||||||||||||||||||||||||||||||||
=> | 625 | TradingSessionSubID | @SesSub | N | ||||||||||||||||||||||||||||||||||||||
=> | 827 | ExpirationCycle | @ExpirationCycle | N | ||||||||||||||||||||||||||||||||||||||
=> | 58 | Text | @Txt | N | Comment, instructions, or other identifying information. | |||||||||||||||||||||||||||||||||||||
=> | 354 | EncodedTextLen | @EncTxtLen | C | Must be set if EncodedText (355) field is specified and must immediately precede it. | |||||||||||||||||||||||||||||||||||||
=> | 355 | EncodedText | @EncTxt | C | Encoded (non-ASCII characters) representation of the Text (58) field in the encoded format specified via the MessageEncoding (347) field. | |||||||||||||||||||||||||||||||||||||
<Standard Message Trailer> | Y |
Field Name | FIXML | Required | Comments |
---|---|---|---|
MsgType | Y | Message type, set to "y" for Security List Request Reject | |
SecurityReqID | 320 | Y | ID of the security list request being rejected |
SecurityListRequestType | 559 | Y | Type of security list request being made |
SecurityRequestResult | 560 | Y | Result of the security list request |
Text | 58 | N | Comment, instructions, or other identifying information |
EncodedTextLen | 354 | C | Must be set if EncodedText (355) field is specified and must immediately precede it |
EncodedText | 355 | C | Encoded (non-ASCII characters) representation of the Text (58) field |
Standard Message Trailer | Y | The standard trailer section of the message |
The field SecurityRequestResult (tag 560) in the Security List Request Reject message indicates the result of the security list request that was made. It provides information about whether the request was successful or not, and if not, it may provide details about the reason for the rejection.
The values for the SecurityRequestResult field can vary depending on the implementation or specific system requirements. However, some common values for this field include:
0: Valid request. Request accepted. 1: Invalid or unsupported request. Request rejected due to invalid or unsupported parameters. 2: No instruments found that match the request criteria. The system did not find any securities that match the criteria specified in the request. 3: Not authorized to retrieve security list. The user or entity making the request does not have the necessary authorization to retrieve the security list. 4: Request for security list not completed. The system encountered an error or issue while processing the request. These values provide information about the outcome of the security list request, allowing the requesting party to understand why the request was rejected and take appropriate action if needed.
can any party send a security list request?
can any party send a security list request?
Yes, in the FIX protocol, any party participating in the FIX session can send a Security List Request message. While it is common for the client or initiator to send this message to request a list of securities from the counterparty or server, the protocol allows for flexibility in message exchange.
The FIX protocol is designed to facilitate communication and interaction between multiple parties, such as buy-side firms, sell-side firms, trading platforms, and market data providers. Each party can initiate and send various types of messages, including the Security List Request, based on their specific needs and requirements.
Therefore, depending on the context and the specific implementation of the FIX session, any party involved can send a Security List Request message. The protocol ensures that the messages are properly formatted and understood by both the sender and receiver, allowing for efficient and standardized communication within the financial industry.
In the context of financial markets and trading systems, the terms "Security List Request," "Security List," and "Security List Request Reject" are related to the FIX (Financial Information eXchange) protocol. FIX is a widely used messaging standard for electronic communication in the financial industry.
Security List Request: A Security List Request is a message sent by a trading system or a market participant to request a list of securities from a counterparty or an exchange. The request typically includes criteria such as security type, market, sector, or any other relevant attributes to filter the desired list of securities. It allows the requester to obtain information about available securities that meet specific criteria.
Security List: A Security List is the response to a Security List Request. It contains a list of securities that match the requested criteria. Each security in the list is identified by its symbol, exchange code, and other relevant information. The Security List message provides details about the securities that the counterparty or exchange supports, allowing the requester to make informed trading decisions.
Security List Request Reject: A Security List Request Reject is a message sent by the counterparty or exchange in response to a Security List Request when it cannot fulfill the request. This rejection message might be due to various reasons, such as invalid or unsupported request parameters, lack of permissions, or technical issues. The rejection message typically includes the reason for the rejection, allowing the requester to identify and resolve the issue.
Regarding the order of these messages, a Security List Request is typically sent before a Security Definition Request. The Security List Request allows the requester to obtain a list of available securities that meet certain criteria. Once the requester has identified the desired security from the list, they can then send a Security Definition Request to request detailed information about a specific security or a set of securities. The Security Definition Request is used to obtain information such as contract specifications, trading characteristics, market data, and other relevant details for a specific security.