nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Symbol conversion using lseg.data

Huong

I wanted to convert between security identifiers depending on the identifier type I may have. I have checked the symbol conversion module and the fundamental reference module, both under content layer. There are some differences in their behaviors. Below is an example based on CUSIP to ISIN/RIC mapping.

Symbol Conversion returned data only for 6 out of the 12 bond CUSIP requested and among the 6 two of them don't have ISIN

For the same CUSIP when using Fundamental And Reference module response has 12 records, but data for only 6 of them with all the 6 having ISIN.

Below is a similar example based on equity CUSIPs. (For equity it seems like Symbol Conversion returns data only if TR.CUSIP is available (Canada/US))

Please help with the below queries

1. Why no data is returned for some of the securities and why does Symbol Conversion module return lesser data fields (missing ISINs) compared to Fundamental And Reference module?

2. Which one of these modules/methods is preferred in terms of performance and correctness?

3. What instrument types are supported by the param "universe" in "get_data()" method, it seems to work with ISIN, CUSIP and RIC values? Can we provide instrument type to this method to improve performance/correctness and avoid service from determining the instrument types?

Find more posts tagged with

python

symbology

#content

lseg-data-library

Accepted answers

Jirapongse

@Huong

Thank you for reaching out to us.

The symbol_conversion module returns IssueISIN. I think it is different from ISIN.

To get ISINs from the symbol_conversion, you can use this code.

I checked and found that the followings are the extended CUSIPs or CinCUSIPs.

 "J34684100, Q6775H104,Y7182M117,Y82594121"

To search these instruments, the code could be like this:

The search lookup is useful if you exactly know the instrument types.

However, the Fundamental and Reference module is more flexible, supporting multiple instrument types and automatically determining the instrument type based on the format. The Fundamental And Reference module is more suitable for this use case.

All comments

ujjawal_khandelwal

Hi @Huong,
Thank you for reaching out!

Can you please confirm if all the 12 CUSIPs are correct? Because for the ones there is no result, I do not find any result on Workspace either. E.g., No result for DL2612380

Looking forward to your confirmation. Thanks!

nick.zincone

Hi @Huong,

As mentioned in the previous answer, you need to ensure the specified instruments are correct, for example, some are not found within Workspace, or the API services. If you believe they are correct, you will have to open a content ticket within the LSEG Support helpdesk or use "Get Help & Support" within Workspace.

As for the data returned, both API calls are unable to resolve some of the instruments. However, the backend services will report the missing data differently. For example, the fundamental and reference reports null values within the response. The library is simply reporting what the backend reports.

In terms of choosing which function, that depends on your preference in what the service provides within the response - you prefer to see null values or not - the library typically does not manipulate the data response returned from the backend.

The 'get_data()' will support multiple instrument types as you highlighted. This service can determine the instrument type automatically based on the format - which is a convenience mechanism for the user community. Are you seeing incorrect behavior? The interpretation of the instrument type is a negligible operation vs the actual lookup of the symbols so there would likely be zero impact in terms of performance.