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.

Find more posts tagged with

expired-contract

#content

Accepted answers

aramyan.h

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

All comments

aramyan.h

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

AspenJohn

Did the trick, Thx!

AspenJohn

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

aramyan.h

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 None

If you have a better proposition to handle this I would be very happy to consider.

Best regards,

Haykaz

AspenJohn

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

aramyan.h

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

EXPLORE OUR SITES