indicates that the requestor only wants a snapshot or the current status.
1
indicates that the requestor wants a snapshot (the current status) plus updates as the status changes. This is similar to subscribing for information and can be implemented in applications as a subscription mechanism.
2
indicates that the requestor wishes to cancel any pending snapshots or updates - in essence making this an unsubscribe operation.
SubscriptionRequestType (263)indicates to the other party what type of response is expected. A snapshot request only asks for current information. A subscribe request asks for updates as the status changes. Unsubscribe will cancel any future update messages from the counter party.)
Security Status Request (MsgType = e, FIXML = SecStatReq)
The [Security Status Request (e)](https://btobits.com/fixopaedia/fixdic44/message_Security_Status_Request_e.html) message provides for the ability to request the status of a security. One or more [Security Status (f)](https://btobits.com/fixopaedia/fixdic44/message_Security_Status_f.html) messages are returned as a result of a [Security Status Request (e)](https://btobits.com/fixopaedia/fixdic44/message_Security_Status_Request_e.html) message.
TheSecurity Status (f)message provides for the ability to report changes in status to a security. TheSecurity Status (f)message contains fields to indicate trading status, corporate actions, financial status of the company. TheSecurity Status (f)message is used by one trading entity (for instance an exchange) to report changes in the state of a security.
It is expected that theSecurity Status (f)message that is sent as a response should indicate what type of request is being provided. If the message is being generated as a result of a RequestType =1, then the response should have a RequestType=1 to permit the requestor to determine why the message was sent.
TAG | FIELD NAME | FIXML | REQ'D | COMMENTS
-- | -- | -- | -- | --
| Y | MsgType = f
324 | SecurityStatusReqID | @StatReqID | N |
| Y |
| N |
711 | NoUnderlyings | Undly | N | Number of underlyings
=> | | C | Must be provided if Number of underlyings > 0
555 | NoLegs | Leg | N | Required for multileg quotes
=> | | C | Required for multileg quotes. For Swaps one leg is Buy and other leg is Sell
15 | Currency | @Ccy | N |
336 | TradingSessionID | @SesID | N |
625 | TradingSessionSubID | @SesSub | N |
325 | UnsolicitedIndicator | @Unsol | N | Set to 'Y' if message is sent as a result of a subscription request not a snapshot request
326 | SecurityTradingStatus | @TrdgStat | N | Identifies the trading status applicable to the transaction.
291 | FinancialStatus | @FinclStat | N |
292 | CorporateAction | @CorpActn | N |
327 | HaltReason | @HaltRsn | N | Denotes the reason for the Opening Delay or Trading Halt.
328 | InViewOfCommon | @InViewOfCmn | N |
329 | DueToRelated | @DueToReltd | N |
330 | BuyVolume | @BuyVol | N |
331 | SellVolume | @SellVol | N |
332 | HighPx | @HighPx | N |
333 | LowPx | @LowPx | N |
31 | LastPx | @LastPx | N | Represents the last price for that security either on a Consolidated or an individual participant basis at the time it is disseminated.
60 | TransactTime | @TxnTm | N | Trade Dissemination Time
334 | Adjustment | @Adjmt | 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.
| Y
The client, who wants to buy or sell a security, submits an order to the trading venue. The client's order specifies the security they wish to trade and other relevant details.
Upon receiving the client's order, the trading venue evaluates the order and performs necessary checks, including verifying the security's status.
To determine the security's status, the trading venue may send a security status request to the relevant authorities or data providers. This request is typically made to obtain the most up-to-date information about the security, such as whether it is currently tradable, halted, or subject to any restrictions.
The trading venue receives the security status information in response to its request.
Based on the security status information obtained, the trading venue determines how to handle the client's order. For example, if the security is tradable, the trading venue may proceed with matching the client's buy or sell order with suitable counterparties. If the security is halted or restricted, the trading venue may reject the order or apply necessary restrictions.
The trading venue communicates the outcome of the order to the client. This communication typically includes information about whether the order was executed, partially executed, or rejected.
In summary, the trading venue is responsible for requesting and obtaining the security status information to make informed decisions about handling client orders. The trading venue uses this information internally to determine the order's execution or rejection and communicates the outcome to the client.
In most financial trading systems, the client's software typically does not initiate a security status request directly. The responsibility of retrieving and maintaining security status information usually lies with the trading venue or the infrastructure supporting the trading operations.
However, the design and capabilities of trading systems can vary, and it's conceivable to have a system where clients can initiate a security status request. While it is less common, there might be specific scenarios or custom systems where clients require direct access to security status information.
If you are designing your FIX protocol software, you have some flexibility in defining the functionality and interactions within your system. In such a case, you could explore incorporating a feature that allows clients to initiate security status requests. However, it's important to consider the following factors:
Data sources and integration: Clients would need access to reliable and up-to-date security status information from trusted sources. You would need to establish connections or integrate with relevant data providers or authorities to obtain this information.
Scalability and performance: Implementing a client-initiated security status request could introduce additional load and complexity to your system. Ensure that your infrastructure can handle the increased volume of requests and respond within acceptable timeframes.
Security and permissions: You must carefully consider the security implications of allowing clients to initiate security status requests. Implement appropriate authentication, authorization, and validation mechanisms to ensure that only authorized clients can access this functionality.
Compliance and regulations: Verify that providing clients with security status information aligns with the regulatory requirements of the jurisdictions in which your system operates. Ensure compliance with any relevant regulations, such as data privacy and market transparency rules.
Security Status Request (MsgType = e, FIXML = SecStatReq)
The Security Status Request (e) message provides for the ability to request the status of a security. One or more Security Status (f) messages are returned as a result of a Security Status Request (e) message.
The Security Status Request (e) message contains a SubscriptionRequestType (263) field. This tells the counter party what type of request is being made:
Security Status Request (MsgType = e, FIXML = SecStatReq) The [Security Status Request (e)](https://btobits.com/fixopaedia/fixdic44/message_Security_Status_Request_e.html) message provides for the ability to request the status of a security. One or more [Security Status (f)](https://btobits.com/fixopaedia/fixdic44/message_Security_Status_f.html) messages are returned as a result of a [Security Status Request (e)](https://btobits.com/fixopaedia/fixdic44/message_Security_Status_Request_e.html) message.
Security Status (MsgType = f, FIXML = SecStat)
The Security Status (f) message provides for the ability to report changes in status to a security. The Security Status (f) message contains fields to indicate trading status, corporate actions, financial status of the company. The Security Status (f) message is used by one trading entity (for instance an exchange) to report changes in the state of a security.
It is expected that the Security Status (f) message that is sent as a response should indicate what type of request is being provided. If the message is being generated as a result of a RequestType =1, then the response should have a RequestType=1 to permit the requestor to determine why the message was sent.
TAG | FIELD NAME | FIXML | REQ'D | COMMENTS -- | -- | -- | -- | --Security Status Request Reject message (MsgType = j, FIXML = SecStatReqRjct):
The client, who wants to buy or sell a security, submits an order to the trading venue. The client's order specifies the security they wish to trade and other relevant details.
Upon receiving the client's order, the trading venue evaluates the order and performs necessary checks, including verifying the security's status.
To determine the security's status, the trading venue may send a security status request to the relevant authorities or data providers. This request is typically made to obtain the most up-to-date information about the security, such as whether it is currently tradable, halted, or subject to any restrictions.
The trading venue receives the security status information in response to its request.
Based on the security status information obtained, the trading venue determines how to handle the client's order. For example, if the security is tradable, the trading venue may proceed with matching the client's buy or sell order with suitable counterparties. If the security is halted or restricted, the trading venue may reject the order or apply necessary restrictions.
The trading venue communicates the outcome of the order to the client. This communication typically includes information about whether the order was executed, partially executed, or rejected.
In summary, the trading venue is responsible for requesting and obtaining the security status information to make informed decisions about handling client orders. The trading venue uses this information internally to determine the order's execution or rejection and communicates the outcome to the client.
In most financial trading systems, the client's software typically does not initiate a security status request directly. The responsibility of retrieving and maintaining security status information usually lies with the trading venue or the infrastructure supporting the trading operations.
However, the design and capabilities of trading systems can vary, and it's conceivable to have a system where clients can initiate a security status request. While it is less common, there might be specific scenarios or custom systems where clients require direct access to security status information.
If you are designing your FIX protocol software, you have some flexibility in defining the functionality and interactions within your system. In such a case, you could explore incorporating a feature that allows clients to initiate security status requests. However, it's important to consider the following factors:
Data sources and integration: Clients would need access to reliable and up-to-date security status information from trusted sources. You would need to establish connections or integrate with relevant data providers or authorities to obtain this information.
Scalability and performance: Implementing a client-initiated security status request could introduce additional load and complexity to your system. Ensure that your infrastructure can handle the increased volume of requests and respond within acceptable timeframes.
Security and permissions: You must carefully consider the security implications of allowing clients to initiate security status requests. Implement appropriate authentication, authorization, and validation mechanisms to ensure that only authorized clients can access this functionality.
Compliance and regulations: Verify that providing clients with security status information aligns with the regulatory requirements of the jurisdictions in which your system operates. Ensure compliance with any relevant regulations, such as data privacy and market transparency rules.
This can be redesigned