Suspension Monitoring process using Workspace Python implementation

avinash.sonde

We are currently enhancing our STOXX Suspension Monitoring process and would appreciate your guidance on the recommended Workspace Python implementation. 

Our objective is to monitor a universe of approximately 20,000+ active securities on a daily basis and identify securities that may be suspended, halted, or have ceased trading activity. 

We are currently using Python 3.11 together with the Refinitiv Workspace Data Library and would like to understand the most efficient and supported approach for retrieving trading status information for a large security universe. 

Our primary focus is on suspension detection and monitoring.

Specifically, we would like to retrieve the following information:

• Trading Status
• Suspension Status (if available)
• Halt Status (if available)
• Last Trade Date
• Last Traded Volume
• Delisting Indicators (if available)
• Any additional fields that may assist in identifying suspended or non-trading securities

We understand from previous discussions that trade date information may be relevant when assessing securities that have stopped trading. 

Could you please advise on the following:

1. Which Workspace fields are recommended for identifying suspended and halted securities?
2. Which field should be used as the preferred source for the last trading date?
3. Is there a recommended Python retrieval structure for monitoring approximately 20,000 securities efficiently?
4. Are there any batching recommendations, API limits, or performance best practices for large-scale daily monitoring?
5. Could you provide a sample Python code structure demonstrating how to retrieve:
   • Trading Status
   • Suspension/Halt Status
   • Last Trade Date
   • Trading Volume

For reference, we have previously used fields such as:

Python

fields = [

"trd_status",

"HSTCLSDATE"

]

Show more lines

However, we are looking to review whether there is a more robust and recommended approach for suspension-focused monitoring within Workspace. 

Any sample code, field recommendations, or implementation best practices would be greatly appreciated.

Jirapongse

@avinash.sonde

Thank you for reaching out to us.

Please contact the Content Support team directly to confirm which fields provide the required data. You should also verify whether the fields are real-time fields or TR.xxx fields.

For TR.xxx fields, clients can use the ld.get_data() method to retrieve the latest available data.

For real-time fields, clients can use the ld.get_data() method to retrieve the current snapshot data, or use the ld.open_pricing_stream() method to access snapshot or streaming real-time data.

The examples are available on GitHub (ld.get_data and ld.open_pricing_stream).

My concern is the requirement to monitor a universe of more than 20,000 active securities on a daily basis. For this type of large-scale monitoring use case, I would recommend considering enterprise-grade APIs and data feed solutions, such as Real-Time Optimized (RTO) and the LSEG Real-Time SDKs, which are designed to support high-volume, production-grade applications.

The client should also contact their LSEG account team or sales representative to discuss the requirements in detail and determine which products and deployment options are best suited for this use case.