question

Upvotes
Accepted
646 21 31 40

AfxRt some data do not match data in DIB

Ticker: POSADASA.MX, request fields : CF_HIGH, CF_LOW

DIB shows : 42 and 42

AfxRt returns RT_FIELD_INVALID for both of them with Empty values.

I have more than 1 ticker. The question is: why is there the difference?

eikoneikon-com-api
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
Accepted
39.4k 77 11 27

Fields that start with CF_ are a peculiar construct. They do not exist on the datafeed. They are synthesized by Eikon application from other fields based on a certain logic that attempts to provide a single set of fields for most common data items such as last price, bid, ask etc across markets, geographies and asset classes. E.g. for listed stocks the bid price is typically found in field BID while for bonds it is usually found in field PRIMACT_1. CF_BID provides bid price that is taken from BID or PRIMACT_1 or another field depending on the instrument. For stocks the last price is found in field TRDPRC_1 and CF_LAST field will take it from there. For spot FX instruments there's no such thing as the last price, as this is an over the counter market where trades are not reported to any aggregator and all you have is indicative quotes that dealer banks contribute to market data vendors such as Refinitiv. CF_LAST field provides a quote for spot FX instruments like EUR=, which is taken from the real field BID.
CF_HIGH field takes value from the real field HIGH_1 and falls back on the real field BID_HIGH_1. For all the Mexican stocks you mentioned there haven't been any trades at the time you ran your test, hence real field HIGH_1 was empty. So was real field TRDPRC_1 which provides the value for CF_LAST, however CF_LAST falls back on HST_CLOSE, which contains previous close price and this is why CF_LAST returns value even when TRDPRC_1 is empty. Real field BID_HIGH_1 that CF_HIGH falls back on simply doesn't exist for Mexican stocks. This is how you end up having RT_FIELD_INVALID for CF_HIGH when there's been no trade on a stock. DIB returning a value for CF_HIGH under these conditions is a glitch. As you can see it doesn't return it consistently.
Since the time of the original post PAPPEL.MX, FCFE18.MX and VITROA.MX have traded. If you retrieve these RICs now you'll see CF_HIGH field populated.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

"So was real field TRDPRC_1 which provides the value for CF_LAST, however CF_LAST falls back on HST_CLOSE, which contains previous close price and this is why CF_LAST returns value even when TRDPRC_1 is empty."

So, I just want to confirm, the bottom line is AfxRT component gets the value of CF_HIGH from different field/source than DIB, correct? And this's applicable for other real-time data as well...

PAPPEL.MX, FCFE18.MX and VITROA.MX - yes, I receive the data now in both DIB and AfxRT

Yes, that is correct. All real-time data comes from the same real-time network, but the distribution layer used by AdfinX Real-Time and by DIB is not identical.

Upvotes
4.6k 26 7 22

@igorg this is a content issue, the POSADASA.MX does not have a CF_HIGH field. I suggest you contact your local support desk.

I am also not sure if DIB shows the value, it does not for me:


icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

@Zhenya Kovalyov Then my DIB has more data than yours :)

capture.png (42.6 KiB)

@igorg could you open Eikon Excel and paste this formula in any cell

=TR("POSADASA.MX","CF_HIGH")

does it show a value?

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.