MP domain market data update

ming.cheng

When user code receives an rfa::common::Event event and if it's a rfa::data::FieldListEnum data, can user assume that a FieldList data any time should only contain either BID or ASK side data? Not both?

wasin.w

Hello @ming.cheng

Please be informed that I am not a Market data expert, so I might not fully understand your ask side or bid side term.

Subscribing to the market data services is usually the best way to view what the actual Market Price FieldList data look like. I strongly suggest you try the RFA C++ StartConsumer example (in the API package) or the RFA C++ Tutorial application to connect to your Refinitiv Real-Time Market Data system and see the real data feed. It is a better way than just reading the specification.

• You can check how to set up the API from the RFA C++ API - Quick Start page.

In the Refinitiv Real-Time system, the Market Price data domain's FieldList does not contain duplicate fields (whatever the field/FID is). If data is available, it always presents in the FieldList only 1 time (1 BID, 1 ASK, 1 DSPLY_NAME, 1 ACVOL_1, etc).

I hope this help.

wasin.w

Hello @ming.cheng

It is the expected behavior of Refinitiv Real-Time that sends any fields that are updated to the API in the Update Message. The application cannot expect that some FIDs are always available in the Update.

I recommend that the client programmatically check incoming FIDs/Fields data from the incoming FieldList payload. The client can find more detail from the RFA C++ Tutorial 7 - MarketPrice Refinitiv Data Model (RDM), Part 2 tutorial page.

I hope this helps.

ming.cheng

Sorry, definitely not relevant I have to say. My question is the any FieldList data is either about BID or ASK if it's about a MP data update. Not possible that a FieldList could have BIS and ASK both at the same time.

wasin.w

Hello @ming.cheng

If you subscribe to Refinitiv Real-Time for BID and ASK fields as a streaming request message, the API cannot guarantee that BID and ASK prices are always present in the same Update message. It is based on the incoming data from Refinitiv Real-Time.

Alternatively, you can subscribe to Refinitiv Real-Time for BID and ASK fields as a snapshot request message, the BID and ASK prices are always present in the same Refresh message.

ming.cheng

Sounds possible that ONE FieldList could contain both BID and ASK data?

wasin.w

Hello @ming.cheng

Yes, it is possible. If the backend (RTDS/OMM Provider)/Refinitiv Real-Time sends BID and ASK data to the API in the same Update message.

The example is as follows:

BatchViewItemManager.processEvent: Received Item Event...
MESSAGE
    Msg Type: MsgType.UPDATE_RESP
    Msg Model Type: MARKET_PRICE
    Indication Flags: 
    Hint Flags: HAS_RESP_TYPE_NUM | HAS_SEQ_NUM
    SeqNum: 35264
    RespTypeNum: 1 (QUOTE)
    Payload: 19 bytes
        FIELD_LIST
            FIELD_ENTRY 22/BID: 36.75
            FIELD_ENTRY 25/ASK: 37.00

However, it is possible that the backend (RTDS/OMM Provider)/Refinitiv Real-Time sends only BID or ASK field in the Update message like in the following examples too:

BatchViewItemManager.processEvent: Received Item Event...
MESSAGE
    Msg Type: MsgType.UPDATE_RESP
    Msg Model Type: MARKET_PRICE
    Indication Flags: 
    Hint Flags: HAS_RESP_TYPE_NUM | HAS_SEQ_NUM
    SeqNum: 35168
    RespTypeNum: 1 (QUOTE)
    Payload: 13 bytes
        FIELD_LIST
            FIELD_ENTRY 25/ASK: 37.00
....
BatchViewItemManager.processEvent: Received Item Event...
MESSAGE
    Msg Type: MsgType.UPDATE_RESP
    Msg Model Type: MARKET_PRICE
    Indication Flags: 
    Hint Flags: HAS_RESP_TYPE_NUM | HAS_SEQ_NUM
    SeqNum: 35184
    RespTypeNum: 1 (QUOTE)
    Payload: 13 bytes
        FIELD_LIST
            FIELD_ENTRY 22/BID: 36.75

Note:

• I tested with the RFA API Java edition (the API behavior is the same as the C++ edition)
• subscribe to PTT.BK RIC streaming data for BID and ASK fields only

ming.cheng

So inside a fieldlist, there will be at most one Bid and one Ask; or can be m Bid and n Ask? Whatever situation, can I say there should be one effective update timestamp like FID 1025 or 14265? Or put this way, that one pair of 1025/14265.

wasin.w

Hello @ming.cheng

Please be informed that the exact list of FIDs you receive for a real-time instrument (regardless of which API you use) will depend on a variety of factors such as originating exchange/vendor/source, asset class, etc. The API just receives incoming data from Refinitiv Real-Time and passes it to the application "as it is".

I am sorry that I am not a Real-Time content expert, so I highly recommend you contact the Content Support team. The Content support team can help you with Real-Time field behavior in more detail. You can contact the team directly via the https://my.refinitiv.com/content/mytr/en/helpandsupport.html website.

Note: It would be nice if you provide the list of your RICs to them.

Hope this helps.

ming.cheng

Hi Wasin,

Thanks and now I got some idea. However I'd like to confirm further the following points:

1. So user code can receive an update of FieldList containing BID and ASK data. May I say at most 1 BID and 1 ASK? Is it possible that a FieldList could containing m BID and n ASK?
2. within a FieldList, there is a update timestamp (for example either FID 1025 or FID 14265; or both conceptually one bcos user should use only one of them)? And this timestamp is applicable to all BID/ASK data within the same FieldList
3. This n possible BID/ASK entries within a FieldList has nothing to do with subscription method/options used

If not sure about FID content, please leave item 2 and focus on 1 and 3. In fact even item 2 is more on concept than actual FID usage.

wasin.w

Hello @ming.cheng

Please see the answers below:

Question 1: So user code can receive an update of FieldList containing BID and ASK data. May I say at most 1 BID and 1 ASK? Is it possible that a FieldList could contain m BID and n ASK?

Answer: Do you mean "Is it possible that a FieldList could contain multiple BID and ASK?"?

Please be informed that the FieldList doe not contain duplicate FIDs. Each FID presents in a FieldList only 1 time as follows:

If the application subscribes a Market Price item for BID and ASK fields to Refinitiv Real-Time, 1 incoming FieldList data can be the following scenarios (depending on how the exchange/feed/server sends data to the API):

• 1 BID
• 1 ASK
• 1 BID and 1 ASK

Example with subscription PTT.BK and SCB.BK Market Price with View feature (BID and ASK):

BatchViewItemManager.processEvent: Received Item Event...
MESSAGE
    Msg Type: MsgType.UPDATE_RESP
    Msg Model Type: MARKET_PRICE
    Indication Flags: 
    Hint Flags: HAS_ATTRIB_INFO | HAS_RESP_TYPE_NUM | HAS_SEQ_NUM
    SeqNum: 35776
    RespTypeNum: 1 (QUOTE)
    AttribInfo
        ServiceName: API_ELEKTRON_EDGE_TOKYO
        ServiceId: 4591
        Name: PTT.BK
        NameType: 1 (RIC)
    Payload: 13 bytes
        FIELD_LIST
            FIELD_ENTRY 25/ASK: 37.25
BatchViewItemManager.processEvent: Received Item Event...
MESSAGE
    Msg Type: MsgType.UPDATE_RESP
    Msg Model Type: MARKET_PRICE
    Indication Flags: 
    Hint Flags: HAS_ATTRIB_INFO | HAS_RESP_TYPE_NUM | HAS_SEQ_NUM
    SeqNum: 10928
    RespTypeNum: 1 (QUOTE)
    AttribInfo
        ServiceName: API_ELEKTRON_EDGE_TOKYO
        ServiceId: 4591
        Name: SCB.BK
        NameType: 1 (RIC)
    Payload: 19 bytes
        FIELD_LIST
            FIELD_ENTRY 22/BID: 107.50
            FIELD_ENTRY 25/ASK: 108.00
...
BatchViewItemManager.processEvent: Received Item Event...
MESSAGE
    Msg Type: MsgType.UPDATE_RESP
    Msg Model Type: MARKET_PRICE
    Indication Flags: 
    Hint Flags: HAS_ATTRIB_INFO | HAS_RESP_TYPE_NUM | HAS_SEQ_NUM
    SeqNum: 35840
    RespTypeNum: 1 (QUOTE)
    AttribInfo
        ServiceName: API_ELEKTRON_EDGE_TOKYO
        ServiceId: 4591
        Name: PTT.BK
        NameType: 1 (RIC)
    Payload: 13 bytes
        FIELD_LIST
            FIELD_ENTRY 22/BID: 37.00

I highly recommend you find more detail from Section "9 – Fields are described by dictionaries" of the 10 important things you need to know before you write a Refinitiv Real-Time application article.

The RFA API C++ StartConsumer_BatchView example application is also a good example that you can test and experiment with various options of items and fields subscription.

Question 2: Within a FieldList, there is an update timestamp (for example either FID 1025 or FID 14265; or both conceptually one bcos user should use only one of them)? And this timestamp is applicable to all BID/ASK data within the same FieldList

Answer: I am sorry that I am not a Real-Time content expert, so I highly recommend you contact the Content Support team. The Content support team can help you with Real-Time field behavior in more detail. You can contact the team directly via the https://my.refinitiv.com/content/mytr/en/helpandsupport.html website (choose "I need help understanding content within the product" and product "Refinitiv Real-Time").

Question 3: This n possible BID/ASK entries within a FieldList has nothing to do with the subscription method/options used

Answer: I do not understand what the question is. Can you clarify this question?

If you mean duplicate FIDs/Fields, the API should not send duplicate FIDs/Fields in a single FieldList to the application.

ming.cheng

Hi Wasin,

Since a FieldList can at most contain a BID and a ASK, the item 3 is irrelevant. And we can ignore item 2 also as you said no duplicated FID in any FieldList. Then ans to item 2 should be clear also.

Thanks a lot!

wasin.w

Hello @ming.cheng

Please be informed that if you encounter a duplicate FID in a FieldList, it might be a bug or data issue.

ming.cheng

wasin.w

I'd like to touch this topic again. I should have made it clear that what I meant by BID/ASK is not Refinitiv' BID/ASK FIDs. Instead they are bid side or ask side market data include price and size.

So come to my original concern again that would a FIELDLIST object possibly contain multiple bid and/or ask groups of data? Hope at most 1 bid side and 1 ask side data in a FieldList object.

Keen to have your clarification.

ming.cheng

let's close it. thanks for your patience。