jim380 / Re

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

market data #61

Closed uwezukwechibuzor closed 1 year ago

uwezukwechibuzor commented 1 year ago

can an API contain market data requests, Market Data Snapshot/Full Refresh and market data request reject in the fix protocol?

uwezukwechibuzor commented 1 year ago

Can an API contain market data requests, Market Data Snapshot/Full Refresh and market data request reject in the fix protocol?

Yes, it is possible for an API to contain market data requests, Market Data Snapshots/Full Refresh, and market data request reject in the FIX Protocol.

In the FIX Protocol, market data request messages are used to request real-time or historical market data from a trading venue. The Market Data Snapshot/Full Refresh message is used by the trading venue to provide a snapshot of the requested market data. The Market Data Request Reject message is used by the trading venue to reject a market data request that cannot be processed.

An API can be designed to handle all three types of messages. For example, the API can include functions that allow a user to make a market data request, receive a Market Data Snapshot/Full Refresh message, and handle a Market Data Request Reject message in the event that the request is rejected by the trading venue. The API can also include error-handling mechanisms to ensure that any errors or exceptions that occur during the process are properly handled

uwezukwechibuzor commented 1 year ago

In general, market data snapshot messages do not have a button or any other mechanism for updating the data, since they are a static snapshot of the current state of the market at a particular point in time.

Market data snapshot messages are typically sent in response to a client's request for market data, and are designed to provide a "snapshot" of the market at the time the request is made. Once the snapshot is sent to the client, it is up to the client to process the data and use it as needed.

On the other hand, market data full refresh messages may be sent periodically to provide a complete update of all the market data attributes for all the securities being tracked. These messages may be triggered by a specific event (such as the start of a new trading session), or maybe sent on a regular schedule (such as every 5 minutes).

In summary, while market data snapshot messages do not have a button for updating the data, market data full refresh messages may be sent periodically to provide a complete update of all the market data attributes for all the securities being tracked

uwezukwechibuzor commented 1 year ago

market data request with multiple entries

8=FIX.4.4|9=381|35=V|34=123|49=ABC|52=20230419-10:00:00.000|56=XYZ|262=1|263=3|146=1|55=IBM.N|262=2|263=3|146=1|55=AAPL.OQ|10=101|

see the fields that should be repeated

In this example, the message type is "V" (Market Data Request), the message sequence number is 123, and the sender and target identifiers are "ABC" and "XYZ", respectively.

The message contains two repeating groups (tag 262), each with three fields: tag 262 (MDReqID), tag 263 (SubscriptionRequestType), and tag 146 (NoRelatedSym). The first group has an MDReqID of 1, a SubscriptionRequestType of 3 (snapshot plus updates), and a NoRelatedSym of 1 (indicating a single symbol to subscribe to, with a value of "IBM.N"). The second group has an MDReqID of 2, a SubscriptionRequestType of 3, and a NoRelatedSym of 1 (indicating a single symbol to subscribe to, with a value of "AAPL.OQ").

The message ends with the standard trailer containing the CheckSum field.

uwezukwechibuzor commented 1 year ago

is this possible in market data requests?

No, it is not possible to include a repeating group of MDEntry instances in a Market Data Request message in the FIX protocol. A Market Data Request message is used to request market data for a specific financial instrument or instruments, and it typically includes fields such as Symbol (tag 55), Market Depth (tag 264), and MDReqID (tag 262). However, it does not include a repeating group of MDEntry instances.

The Market Data Request message is sent from the client to the server to request market data, and the server responds with one or more Market Data Incremental Refresh messages that contain the requested market data. Each Market Data Incremental Refresh message can contain one or more MDEntry instances, each of which represents a unique price or trade for the requested financial instrument.

In summary, while repeating groups of MDEntry instances are used in Market Data Incremental Refresh messages to report current market data, they are not used in Market Data Request messages to request market data.

uwezukwechibuzor commented 1 year ago

mdEntry with repeating group, are the messages sent once?

No, if a Market Data message contains a repeating group of MDEntry instances, the message will be sent multiple times, once for each MDEntry instance within the repeating group. Each MDEntry instance represents a unique price or trade for the financial instrument being reported, and the message must be sent separately for each instance to ensure that each instance is processed correctly by the receiving system.

For example, if a Market Data Incremental Refresh message contains a repeating group with three MDEntry instances, the message will be sent three times, once for each instance in the group. Each message will contain a single MDEntry instance and will have a unique MDEntryID (tag 278) to identify the specific instance.

While sending the same MDEntry instance multiple times within a single message is not allowed in the FIX protocol, sending multiple instances of MDEntry within a repeating group is a common way to report current market data for a financial instrument, such as the current bid and ask prices, the last trade price, and the trade volume. Each MDEntry instance contains various fields that describe the market data, and the repeating group allows multiple instances to be included within a single message

uwezukwechibuzor commented 1 year ago

mdEntry with repeating group, are the messages sent once?

No, if a Market Data message contains a repeating group of MDEntry instances, the message will be sent multiple times, once for each MDEntry instance within the repeating group. Each MDEntry instance represents a unique price or trade for the financial instrument being reported, and the message must be sent separately for each instance to ensure that each instance is processed correctly by the receiving system.

For example, if a Market Data Incremental Refresh message contains a repeating group with three MDEntry instances, the message will be sent three times, once for each instance in the group. Each message will contain a single MDEntry instance and will have a unique MDEntryID (tag 278) to identify the specific instance.

While sending the same MDEntry instance multiple times within a single message is not allowed in the FIX protocol, sending multiple instances of MDEntry within a repeating group is a common way to report current market data for a financial instrument, such as the current bid and ask prices, the last trade price, and the trade volume. Each MDEntry instance contains various fields that describe the market data, and the repeating group allows multiple instances to be included within a single message

MarketDataSnapshotFullRefresh and MarketDataIncremental should have methods for updating

uwezukwechibuzor commented 1 year ago

can market data request be updated after it has been sent?

Yes, a Market Data Request message can be updated after it has been sent. The FIX protocol provides mechanisms for users to modify their subscription to market data in real-time based on changing market conditions, trading strategies, and risk management requirements.

To update a Market Data Request message, a user can send a new message with the same MDReqID (tag 262) as the original request and any changes to the subscription parameters, such as the desired market data depth, frequency, or specific financial instruments requested. The server will then use the MDReqID to identify the original request and modify the subscription accordingly