For a deeper look into our Elektron API, look into:
Overview | Quickstart | Documentation | Downloads | Tutorials | Articles
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....
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
!
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.
Hello @JTHIEDE ,
For the best guidance on how content is categorized, based on asset class and exchange, as suggested by @jirapongse.phuriphanvichai , 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.phuriphanvichai.