search

jim380 / Re

FIX protocol on blockchain
https://cyphercore.io/re
Apache License 2.0
3 stars 1 forks source link

Trading Session List Request, Trading Session List and Trading Session List Request Reject #78

Closed uwezukwechibuzor closed 1 year ago

uwezukwechibuzor commented 1 year ago

After a Trading Session List Request, a client can request for a Trading Session Status Request. The Trading Session Status Request message is used to request information about the status of a specific trading session. The Trading Session List Request message can be used to get a list of trading sessions that are available for trading, and then the client can use the Trading Session Status Request message to get more information about a specific trading session.

uwezukwechibuzor commented 1 year ago

Trading Session List Request and Trading Session Status Request are two different FIX messages that are used to request information about trading sessions.

Trading Session List Request is used to request a list of trading sessions from a market participant. The request can be modified to request status on a particular trading session (by specifying the TradingSessionID (336) and TradingSessionSubID (625) (if used by the market place). The request can be used to request a list of trading sessions that use a particular trading method or mode (such as electronic) by specifying the TradSesMethod (338). Trading Session Status Request is used to request information about the status of a specific trading session. The Trading Session List Request message can be used to get a list of trading sessions that are available for trading, and then the client can use the Trading Session Status Request message to get more information about a specific trading session. The following are the FIX message types for these messages:

Trading Session List Request - MsgType = BI Trading Session Status Request - MsgType = g The Trading Session List Request message has the following fields:

TradSesReqID - Unique identifier for the request. MarketID - Market for which trading session applies. MarketSegmentID - Market Segment for which trading session applies. TradSesMethod - Trading session method. TradSesMode - Trading session mode. The Trading Session Status Request message has the following fields:

TradSesReqID - Unique identifier for the request. MarketID - Market for which trading session applies. MarketSegmentID - Market Segment for which trading session applies. TradingSessionID - Identifier for trading session. TradingSessionSubID - Sub-identifier for trading session. The main difference between the two messages is that the Trading Session List Request message is used to request a list of trading sessions, while the Trading Session Status Request message is used to request information about the status of a specific trading session.

uwezukwechibuzor commented 1 year ago

In the FIX (Financial Information eXchange) protocol, the TradingSessionID field in the Trading Session Status Request message (MsgType = g) is not mandatory when the request is intended to retrieve the overall status of all trading sessions or when the trading venue does not require a specific TradingSessionID for the request.

The absence of a TradingSessionID in the Trading Session Status Request indicates that the client is interested in obtaining the collective status of all available trading sessions supported by the trading venue.

In this case, the Trading Session Status Request message would typically be constructed without the TradingSessionID field. Here is an example:

8=FIX.4.4|9=77|35=g|34=1|49=ClientID|52=20230529-10:15:30.123|56=TradingVenue|10=123| By omitting the TradingSessionID, the client signals its intention to retrieve the overall status information for all trading sessions.

However, it's important to note that the behavior and requirements regarding the TradingSessionID may vary depending on the specific trading system, trading venue, or counterparty you are interacting with. Some trading venues may still require the inclusion of a valid TradingSessionID in the Trading Session Status Request, even if the client wants to obtain the status of all sessions.

uwezukwechibuzor commented 1 year ago

It is possible to use the Trading Session Status Request message without first calling the Trading Session List Request message. The Trading Session List Request is not a mandatory prerequisite for initiating a Trading Session Status Request.

The Trading Session List Request message (MsgType = BJ) is typically used to retrieve a list of available trading sessions and their corresponding TradingSessionIDs from the trading venue. This allows the client to obtain information about the available sessions before making a specific request related to a particular trading session.

However, in some cases, the client may already have the necessary information about the TradingSessionID, either through prior knowledge or pre-negotiation with the trading venue. In such cases, the client can directly include the desired TradingSessionID in the Trading Session Status Request message (MsgType = g) and request the status of that specific trading session.

uwezukwechibuzor commented 1 year ago

If you want to enforce the usage of the Trading Session List Request before allowing users to utilize the Trading Session Status Request in your FIX protocol software, you can implement that requirement. You can design your software in such a way that it mandates the Trading Session List Request to be called first before allowing any subsequent interactions, including the Trading Session Status Request.

Here are the steps you can follow to enforce this sequence:

Implement validation: In your software, include a validation check that ensures the Trading Session List Request is the first message sent by the user. If a subsequent message, such as the Trading Session Status Request, is attempted before the Trading Session List Request, your software can reject it or prompt the user to send the Trading Session List Request first.

Provide clear instructions: Document and communicate the required sequence to the users of your software. Clearly explain that the Trading Session List Request must be sent as the first message to retrieve information about the available trading sessions before any other requests can be made.

Error handling: Handle any exceptions or errors that may occur if the Trading Session List Request is not sent before attempting other interactions. Provide appropriate error messages or notifications to guide users and inform them of the required sequence.

By enforcing this sequence, you ensure that users obtain the necessary information about the available trading sessions before making specific requests related to a particular session. It can help maintain consistency and prevent errors or issues that may arise from using the Trading Session Status Request without prior knowledge of the available sessions.

Remember to document this requirement clearly in your software's documentation or guidelines to guide users and ensure they follow the desired message sequence.