Environment * LSEG Data Library for Python (lseg.data / formerly refinitiv.data) * Portfolio Analytics (PAL) via the portfolio-analytics and o-management endpoints * Python 3.11, running in CodeBook What I'm building I reconstruct a portfolio's closed positions (fully sold or redeemed in the past) from PAL transaction history, so I can produce a per-trade realized-P&L report. For each closed position I need the instrument identity (ISIN, issuer, coupon, maturity) to compute and label the trade. How identification normally works (and works fine for ~85% of positions) For active and most closed positions, I get the instrument identity from PAL holdings statements - each holdings snapshot lists the instrument with its issueName/ISIN. I match a transaction to a position via a shared internal id, and the position already carries its ISIN from the holdings snapshot. This works well. The problem (the remaining ~15%) Some positions were opened and fully closed between two holdings-snapshot dates. PAL apparently never took a holdings snapshot while these instruments were held, so they never appear in any holdings statement on any date. For these, the transaction record is the only trace - and the transaction's instrument reference contains only an internal TOPAS identifier, with no ISIN/CUSIP/RIC and an empty name. Concretely, the transaction's symbol/security item looks like: {"securityItem": {"symbolValues": [{ "type": "TOPASId", "value": "150462714" }]}} That's the entire instrument reference - type: "TOPASId" and a numeric value, nothing else. What I've already tried (and ruled out) * Holdings densification - I scanned the full set of available holdings dates, then added targeted extra dates around each transaction window (100+ extra dates). The instrument's TOPASId is simply absent from holdingsDetails on every probed date. PAL does not appear to retain it anywhere in holdings. * Ticker / name heuristics - not viable; these transactions carry no name, ticker, ISIN, or CUSIP at all. * Manual mapping - works but is not scalable and defeats the purpose of automation. The question Is there a supported way to resolve a PAL TOPASId to a standard instrument identifier (ISIN / RIC / PermID), outside the PAL holdings endpoint? Specifically: * Does lseg.data symbology / symbol_conversion accept a TOPASId as an input identifier type? If so, what is the correct from_symbol_type (or equivalent) value? * Is TOPASId queryable via the Search / discovery API (e.g. as an indexed field), so I could look the instrument up by that id? * Is there any other endpoint that maps PAL's internal TOPAS identifier to a public identifier - given that the instrument does exist in LSEG's universe (it's an LSEG-internal id), it's only the PAL portfolio endpoint that doesn't surface its public identifiers for these closed-out trades? Minimal anonymized example of what I'd like to achieve import lseg.data as ldld.open_session() This is the only identifier I have for a closed-out position: topas_id = "150462714" # PAL transaction securityItem -> symbolValues -> type "TOPASId" DESIRED: resolve TOPASId -> ISIN / RIC, without needing a PAL holdings snapshot. Attempt A - symbol conversion (does TOPASId work as a from-type here?): res = ld.symbol_conversion.Definition(symbols=[topas_id],from_symbol_type="???", # <-- is there a value that means "TOPASId"?to_symbol_types=["ISIN", "RIC"],).get_data()print(res.data.df) Attempt B - search by the id as a query / property: res2 = ld.discovery.search(query=topas_id,# or filter=f"TOPASId eq '{topas_id}'" <-- is TOPASId a searchable field?)print(res2) ld.close_session() I'm looking for either: * the correct symbol-type / field to make one of the above work, or * confirmation that PAL does not retain identification for positions closed entirely between holdings snapshots, so that a manual mapping is the only option. Any pointers from people who've dealt with TOPAS internal ids or PAL transaction-level enrichment would be much appreciated. Thank you.

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; } } }

Resolving a transaction-only "TOPASId" to ISIN/RIC when the instrument never appears in PAL holdings

ab0

Environment

LSEG Data Library for Python (lseg.data / formerly refinitiv.data)
Portfolio Analytics (PAL) via the portfolio-analytics and o-management endpoints
Python 3.11, running in CodeBook

What I'm building

I reconstruct a portfolio's closed positions (fully sold or redeemed in the past) from PAL transaction history, so I can produce a per-trade realized-P&L report. For each closed position I need the instrument identity (ISIN, issuer, coupon, maturity) to compute and label the trade.

How identification normally works (and works fine for ~85% of positions)

For active and most closed positions, I get the instrument identity from PAL holdings statements - each holdings snapshot lists the instrument with its issueName/ISIN. I match a transaction to a position via a shared internal id, and the position already carries its ISIN from the holdings snapshot. This works well.

The problem (the remaining ~15%)

Some positions were opened and fully closed between two holdings-snapshot dates. PAL apparently never took a holdings snapshot while these instruments were held, so they never appear in any holdings statement on any date. For these, the transaction record is the only trace - and the transaction's instrument reference contains only an internal TOPAS identifier, with no ISIN/CUSIP/RIC and an empty name.

Concretely, the transaction's symbol/security item looks like:

{"securityItem": {"symbolValues": [{ "type": "TOPASId", "value": "150462714" }]}}

That's the entire instrument reference - type: "TOPASId" and a numeric value, nothing else.

What I've already tried (and ruled out)

Holdings densification - I scanned the full set of available holdings dates, then added targeted extra dates around each transaction window (100+ extra dates). The instrument's TOPASId is simply absent from holdingsDetails on every probed date. PAL does not appear to retain it anywhere in holdings.
Ticker / name heuristics - not viable; these transactions carry no name, ticker, ISIN, or CUSIP at all.
Manual mapping - works but is not scalable and defeats the purpose of automation.

The question

Is there a supported way to resolve a PAL TOPASId to a standard instrument identifier (ISIN / RIC / PermID), outside the PAL holdings endpoint?

Specifically:

Does lseg.data symbology / symbol_conversion accept a TOPASId as an input identifier type? If so, what is the correct from_symbol_type (or equivalent) value?
Is TOPASId queryable via the Search / discovery API (e.g. as an indexed field), so I could look the instrument up by that id?
Is there any other endpoint that maps PAL's internal TOPAS identifier to a public identifier - given that the instrument does exist in LSEG's universe (it's an LSEG-internal id), it's only the PAL portfolio endpoint that doesn't surface its public identifiers for these closed-out trades?

Minimal anonymized example of what I'd like to achieve

import lseg.data as ldld.open_session()

This is the only identifier I have for a closed-out position:

topas_id = "150462714" # PAL transaction securityItem -> symbolValues -> type "TOPASId"

DESIRED: resolve TOPASId -> ISIN / RIC, without needing a PAL holdings snapshot.

Attempt A - symbol conversion (does TOPASId work as a from-type here?):

res = ld.symbol_conversion.Definition(symbols=[topas_id],from_symbol_type="???", # <-- is there a value that means "TOPASId"?to_symbol_types=["ISIN", "RIC"],).get_data()print(res.data.df)

Attempt B - search by the id as a query / property:

res2 = ld.discovery.search(query=topas_id,# or filter=f"TOPASId eq '{topas_id}'" <-- is TOPASId a searchable field?)print(res2)

ld.close_session()

I'm looking for either:

the correct symbol-type / field to make one of the above work, or
confirmation that PAL does not retain identification for positions closed entirely between holdings snapshots, so that a manual mapping is the only option.

Any pointers from people who've dealt with TOPAS internal ids or PAL transaction-level enrichment would be much appreciated.

Thank you.

Find more posts tagged with

symbology

trade

portfolio-history

PHYTON

lseg-data

Accepted answers

All comments

Jirapongse

@ab0

Thank you for reaching out to us.

I checked and found that symbol_conversion and discovery.search don't support TOPASId. They support RICs and other standard identifier types. This TOPASId may be specific to the PAL.

I will contact the product team to verify this.

ab0

@Jirapongse

Thanks for confirming and for escalating to the product team.

To give them concrete context: I am building a portfolio analytics workflow on
top of PAL and the LSEG Data Library, aggregating positions and transactions
across multiple family-office portfolios. I upload holdings + transactions to
PAL via Excel, both are visible in the PAL UI with full ISINs, but the
transactions API returns ~5–15% of positions identified only by TOPASId - with
no ISIN, RIC or other standard identifier attached.

Questions that would help the product team:

Is the original ISIN from the uploaded Excel retrievable via any read
endpoint? The PAL UI clearly has it, so the mapping exists somewhere
server-side - is it just not exposed in the transactions response?
Is there a roadmap item for TOPASId resolution (to ISIN / RIC / SEDOL) via
any LSEG API - either in symbol_conversion, discovery.search, or a
PAL-specific endpoint?
Our current workaround is to scan quarterly holdings snapshots, where some
TOPASId-only positions DO expose an ISIN, and build a topas→ISIN map from
that. It works for ~95% of my positions but fails for any position opened
and closed between two snapshots. Is there an officially supported pattern
we should use instead?

Impact for me: when a TOPASId can't be resolved, I can't fetch the bond's
coupon schedule, maturity or ratings from the Data Library - so coupon income
for that position is under-reported and P&L doesn't reconcile to the custodian
statement.

Happy to share specific PAL portfolio IDs and sample API responses
(privately) if it helps the product team reproduce.

Jirapongse

@ab0

I got a response back from the product team that you can use the PAL API to resolve the TOPASId.

The endpoint is /palapi/v2/getAttributeValues?classifiedBy=TickerName with the HTTP POST method and the payload is:

{

  "Symbols": [

    {

      "Type": "TOPASId",

      "Value": "150462714"

    }

  ],

  "Attributes": [

    "ISIN.VESTEK.VESTEK","RIC.VESTEK.VESTEK"


  ],

  "Date": "2026-05-21T00:00:00",

  "ReplaceWithPrimaryQuote": true

}

The response will be:

{

  "result": [

    {

      "symbol": "150462714",

      "error": null,

      "attributeValues": [

        {

          "name": "ISIN.VESTEK.VESTEK",

          "value": "US912828VS66",

          "error": null

        },

        {

          "name": "RIC.VESTEK.VESTEK",

          "value": "912828VS6=RRPS",

          "error": null

        }

      ]

    }

  ],

Jirapongse

You can also use the portfolio-management API in the Data Platform to resolve it but you need to directly use the endpoint_request module in the delivery layer to access the API. The code looks like this:

import lseg.data as ld
from lseg.data.delivery import endpoint_request
ld.open_session()

porfolio_matadata_attrvalues_url = '/user-data/portfolio-management/v1/metadata/attribute-values'
request_definition = ld.delivery.endpoint_request.Definition(
    url = porfolio_matadata_attrvalues_url,
    method = ld.delivery.endpoint_request.RequestMethod.GET,
    query_parameters = {
        "symbols": "150462714",
        "symbolType":"TOPASId",
        "attributes":"RIC.VESTEK.VESTEK,ISIN.VESTEK.VESTEK",
        "startDate":"2026-05-20",
        "endDate":"2026-05-21",
        "replaceWithPrimaryQuoteData":True
    }
)
response = request_definition.get_data()
response.data.raw

ab0

Thank you! It works!

EXPLORE OUR SITES