Requesting tenor points of 0#BBUSDUTIBMK= erroneously returns a point for the BBB curve

Hi,

When requesting all tenor point RICs for `0#BBUSDUTIBMK=` using

df,e = ek.get_data('0#BBUSDUTIBMK=','DSPLY_NAME')

We get the following list of RICs

"BBBUSDUTI2Y="
"BBUSDUTI3M="
"BBUSDUTI6M="
"BBUSDUTI1Y="
"BBUSDUTI2Y="
"BBUSDUTI3Y="
"BBUSDUTI4Y="
"BBUSDUTI5Y="
"BBUSDUTI6Y="
"BBUSDUTI7Y="
"BBUSDUTI8Y="
"BBUSDUTI9Y="
"BBUSDUTI10Y="
"BBUSDUTI12Y="
"BBUSDUTI15Y="
"BBUSDUTI20Y="
"BBUSDUTI25Y="
"BBUSDUTI30Y="

Most of these are expected, but why is BBBUSDUTI2Y in there??! This is the triple-B RIC but we requested the double-B RIC.

Something similar is visible in the data item browser.


screenshot-2023-03-21-at-141454.png

Best Answer

  • @tr105 Thanks for your question and sorry to hear about your issue. I get a slightly different response than you using the Eikon Data API:

    imageI think this chain contains some incorrect information - what version of the Eikon library are you using?

    I have also checked with our latest Refinitiv Data Library which uses a more robust chain decoding routine and it appears to be correct:

    import refinitiv.data as rd
    from refinitiv.data.discovery import Chain
    rd.open_session()
    rd.get_data(Chain('0#BBUSDUTIBMK='),'DSPLY_NAME')

    1679407933952.png

    I did not see any BBB entry here. I would suggest you use the Refinitiv Data Library as it is more robust and performant.

    However - I will also raise a content query on your behalf for the Eikon Data API return and report the case number here after I have done so.

    I hope this can help.



Answers

  • @jason.ramchandani01 Thanks for your swift reply, Jason.

    You're right that the actual response looks slightly different: I did not copy paste the entire thing. Sorry for the confusion.

    Thanks for raising the content query. It seems to me that that the most likely cause of the problem is somewhere upstream from the API.

    Also thanks for suggesting the Refinitv Data Library. I see that it uses a different endpoint ("/data/pricing/chains/v1/") from the library that I'm using, which may explain why it returns a different, correct response.

    The fact that there are multiple Python libraries in play is pretty confusing. Can you advise on which one is the most likely to receive long-term support and maintenance, and has the highest quality responses?

  • @tr105 Apols for delay I have opened Case number: 12419571 on your behalf and they will be in contact shortly - I have explained the issue. Yes I would recommend you use the Refinitiv Data (RD) Libraries as I stated earlier as they are the most modern, provide the best feature set (including enhanced historical pricing models, new Search service, Instrument Pricing Analytics and much more) and more performant and also robust. We also included a full port of the older but very popular Eikon Data API in the RD Library so you can use both APIs from one package:

    import refinitiv.data as rd
    rd.open_session()

    and also you could:

    import refinitiv.data.eikon as ek
    ek.set_app_key('YOUR APP KEY HERE')

    Let me know if you want more information - if you launch the CodeBook App under the Examples folder you can see many examples of RD usage:

    1679435918474.png

    We also have many articles which use the RD libraries. I hope this can help.

  • Thank you @jason.ramchandani01 , much appreciated. I will migrate to the RD libraries. How can I stay in the loop of the progress of case 12419571? This is just my forum account which I use for privacy reasons, so I can't log into Workspace with it.

  • @tr105 My pleasure - glad it is useful. For the case you can go to https://my.refinitiv.com/content/mytr/en/signin.html and use your Eikon login and you can see your outstanding support cases. They should already have been in contact via email. I hope this can help.