Expired futures RIC for new 2 digit year format
I'm trying to find the correct formatting for expired futures via the History API. I have no problem with futures that use a single digit year code. The problem is only with futures that started using 2 digit year codes in January of 2024. For example, I can extract data for the December 2023 Emini contract by using ESZ3^2, However, I can't get the March 24 contract with ESH4^2. I've also tried ESH24, ESH24^, ESH24^0 to no avail.
Best Answer
-
Hi @AspenJohn ,
According to the RIC construction rules, that should be ESH24^2 I believe.
Please find Data Notification here - Search Page | MyAccount (lseg.com)
Also, you find this article for futures RIC search useful (although I need to update to reflect this change!) - Reconstructing RICs for expired futures contracts | Devportal (lseg.com)
Best regards,
Haykaz
0
Answers
-
Did the trick, Thx!
0 -
Thanks for the solution. It occurs to me that this isn't a good deterministic approach for building expired future's RIC's. It seems probable that other exchanges will also be converted to 2 digit years at some point. The end result will be that to precisely determine the correct RIC you will need to know in advance what exchange the symbol is (or was) on and what date that exchange converted to the two digit year formatting. Since there is no additional identifying information (such as century) gained from the ESU24^2 format, it would be nice to see that reverted back to ESU4^2. Then no code changes would be required in the future if/when other exchanges switch to two digit years.
Humbly,
John
0 -
Hi @AspenJohn ,
I agree with your comment, that is why, when updating my article to account for the changes, instead of applying per exchange logic and I decided to check all exchanges for both logic to account for possible future changes in other exchanges. Basically, if I find with one digit year_code I simply return it, if not I check with two digit logic.
See below, the function from the article:
def get_futures(self, underlying, month, year):
month_num, month_code = self._get_month_number_and_code(month)
month_last_day = calendar.monthrange(year, int(month_num))[1]
# we define two possible year_codes to account for RIC structure change
year_codes = [str(year)[-1], str(year)[-2:]]
for year_code in year_codes:
query = f'{underlying}{month_code}{year_code}*'
filter_criteria = self._build_filter_criteria(year, month_num, month_last_day, query)
response = self._search_futures(query, filter_criteria)
if response is not None and not response.empty:
return response
print(f'No futures contract for {underlying} expiring on {month_num} month of {year}')
return NoneIf you have a better proposition to handle this I would be very happy to consider.
Best regards,
Haykaz
0 -
Hi Hayzak,
My code tries to pinpoint what the exact symbol should be on the first try by looking at the exchange and the estimated expiration. If that fails, it tries the other possible format. So, essentially what your code does, but with an attempt to make an educated first guess. It certainly isn't a significant problem. I'm just not a fan of "guessing" and would prefer to know the exact symbol I need in every instance. Not knowing what else dwells in the depth of the history database, I worry I might accidentally get the wrong contract in some circumstances.
Best,
Deterministic John
0 -
Hi John,
If I understood you correct, not picking up the wrong contract can be controlled by putting a filter on the RIC, smth like:
query = f'{underlying}{month_code}{year_code}*'
f"(RIC xeq '{query[:-1]}' or RIC xeq '{query[:-1]}^{str(year)[-2]}')"In this logic, if it finds with one digit and RIC matches then great, you have the correct contract, and if it founds with the two digit after failing with 1-digit, then again great. As much as I think there shouldn't be a case when you have both rics (with 1 digit and 2 digit) and you return the one with 1-digit whereas the correct one was the one with 2-digit.
Best,
Haykaz
0
Categories
- All Categories
- 6 AHS
- 37 Alpha
- 161 App Studio
- 4 Block Chain
- 4 Bot Platform
- 16 Connected Risk APIs
- 47 Data Fusion
- 30 Data Model Discovery
- 608 Datastream
- 1.3K DSS
- 577 Eikon COM
- 4.9K Eikon Data APIs
- 7 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- Trading API
- 2.7K Elektron
- 1.3K EMA
- 236 ETA
- 519 WebSocket API
- 33 FX Venues
- 10 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 20 Messenger Bot
- 2 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 59 Open Calais
- 264 Open PermID
- 39 Entity Search
- 2 Org ID
- PAM
- PAM - Logging
- 8.4K Private Comments
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 20 RDMS
- 1.4K Refinitiv Data Platform
- 367 Refinitiv Data Platform Libraries
- 3 Refinitiv Due Diligence
- LSEG Due Diligence Portal API
- 3 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.1K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 10 World-Check Customer Risk Screener
- 990 World-Check One
- 44 World-Check One Zero Footprint
- 45 Side by Side Integration API
- Test Space
- 3 Thomson One Smart
- 1.2K TR Internal
- Global Hackathon 2015
- 2 Specialists Who Code
- 10 TR Knowledge Graph
- 150 Transactions
- 142 REDI API
- 1.7K TREP APIs
- 4 CAT
- 21 DACS Station
- 117 Open DACS
- 1.1K RFA
- 103 UPA
- 172 TREP Infrastructure
- 224 TRKD
- 886 TRTH
- 5 Velocity Analytics
- 5 Wealth Management Web Services
- 59 Workspace SDK
- 9 Element Framework
- 5 Grid
- 13 World-Check Data File
- Yield Book Analytics
- 46 中文论坛