Best way to normalize raw FIDs to an internal data model

Historically we have used a combination of PROD_PERM, RECORDTYPE and RDNDISPLAY to determine how to map raw FIDs to our internal data model members. Obviously this needs to be done because every exchange publishes data differently and adding different asset classes only further complicates where data lives in the incoming ticks. CONTEXT_ID seems to help a bit, but I'm still finding RICs that don't follow the published spec in Data Model Discovery. I'm curious how others are managing these mappings and if CONTEXT_ID is truly the new standard for grouping like RICs where similar data is consistently published to the same FIDs.

A simple example here would be were a "price" lives. Could be TRDPRC_1, BID, ASK, SEC_ACT_1, PRIMACT_1, MID_1, MID_PRICE, GEN_VAL* (based on GV*_TEXT) and so on....

Find more posts tagged with

elektron

fields

elektron-sdk

refinitiv-realtime

rrt

Accepted answers

Jirapongse

@JTHIEDE

Yes, Eikon has its own logic to map fields to CF fields and the mapping can be different among exchanges.

You need to contact the content support team via MyRefinitiv to verify the field mappings used in exchanges.

All comments

JTHIEDE

If anyone has Eikon you can see Refinitiv already maintains some kind of mapping themselves, since they populate the CF_* fields.

CF_ASK "CF ASK" 5358 NULL PRICE 17

CF_BID "CF BID" 5359 NULL PRICE 17

CF_CLOSE "CF CLOSE" 5360 NULL PRICE 17

CF_DATE "CF DATE" 5361 NULL DATE 11

CF_EXCHNG "CF EXCHNG" 5362 NULL ENUMERATED 5 ( 3 )

CF_HIGH "CF HIGH" 5363 NULL PRICE 17

CF_LAST "CF LAST" 5364 NULL PRICE 17

CF_LOTSIZE "CF LOTSIZE" 5365 NULL INTEGER 15

CF_LOW "CF LOW" 5366 NULL PRICE 17

CF_NETCHNG "CF NETCHNG" 5367 NULL PRICE 17

CF_OPEN "CF OPEN" 5368 NULL PRICE 17

CF_SOURCE "CF SOURCE" 5369 NULL ALPHANUMERIC 16

CF_TICK "CF TICK" 5370 NULL ENUMERATED 3 ( 2 )

CF_TIME "CF TIME" 5371 NULL TIME_SECONDS 8

CF_VOLUME "CF VOLUME" 5372 NULL INTEGER 15

CF_YIELD "CF YIELD" 5373 NULL PRICE 17

! DESKTOP USE ONLY. Consolidated FIDs

Jirapongse

@JTHIEDE

Yes, Eikon has its own logic to map fields to CF fields and the mapping can be different among exchanges.

You need to contact the content support team via MyRefinitiv to verify the field mappings used in exchanges.

JTHIEDE

Thanks for the response, but that doesn't answer my question on how other users generally map incoming FIDs to internal values. I've asked the Content Support team specific questions in the past when outliers to the general logic are found.

zoya faberov

Hello @JTHIEDE ,

For the best guidance on how content is categorized, based on asset class and exchange, as suggested by @Jirapongse , Refinitiv content experts would be your go-to resource.

As a developer, my thinking would be that your suggested combination of PROD_PERM, RECORDTYPE and RDNDISPLAY is at least a very good starting point, if not a total coverage of the use case. By finding any instances where differentiation is not covered and mapping is still different and working into these specific cases with content experts, you should be the complete the required map, is my thinking.

I would think also that any additional delineating factors would be asset-specific, i.e. the next level of fid to look into should differ between asset types, based on the ones you already have identified for example, for bonds there are specific types of bond defined and BOND_TYPE defines this info. However, suggesting to work through this with Refinitiv content as suggested by @Jirapongse.

EXPLORE OUR SITES