Re: [Quantlib-users] How to use ql.FuturesRateHelper with EURIBOR futures trading on ICE Futures Europe (former LIFFE)

[Tom A. <tw...@ur...>]

On Fri, 3 Nov 2023, ze73 man via QuantLib-users wrote:

> I might be misunderstanding your last message, Trent. Take for example 
> the 3-Month EuriBor Nov '23, expiring on 13 Nov 2024 (as also confirmed 
> by ICE). What iborStartDate is ql.FuturesRateHelper expecting for this 
> contract? I thought this needed a "type" argument different than 
> Futures::IMM since none of these dates are IMM dates that are also not 
> matching the dates obtained with ql.IMM.nextDate()?

iborStartDate should be the start date, aka value date, of the notional 
deposit underlying the future [1], which should be the third wednesday of 
the month, which we somewhat loosely call an IMM date. The expiry date is 
two business days before this.

The name is a bit confusing, but reflects the fact that the future finally 
settles to the inter-bank offered rate for deposits starting on that date.

The FuturesRateHelper checks that the iborStartDate is an IMM date, with 
the mainCycle parameter set to false, which means it accepts the third 
wednesday of any month. This is exactly what you want.

You also mentioned calendars. The only use of the calendar in the 
FuturesRateHelper is to work out the maturity date of the notional 
deposit, based on the value date. That should be done using the calendar 
native to the market in which these notional deposits are made, which is 
the index's calendar (TARGET), not the exchange's calendar. You would only 
need the exchange calendar to work out the expiry date from the value 
date, but happily you already know the expiry date.

Does this sound like it addresses your concerns? Or have i misunderstood?

Incidentally, it seems like you are trying to build a curve using Euribor 
serials. Note that these are spaced at one month intervals, but are based 
on three month deposits, meaning that they sample heavily overlapping 
parts of the yield curve. Using a bootstrap process like QuantLib's, even 
the slightest inconsistency in their pricing will result in an extremely 
janky curve, which will give you implausible forecasts. I and others on 
this list have had a bad time with curve constructions like this. By all 
means try it, but i suggest you plot the daily instantaneous forward rates 
at your earliest opportunity - then when you see what a mess it is, try a 
different approach.

tom

[1] Futures like this are actually not formally defined in terms of 
notional deposits any more, but just in terms of the index and a formula 
which happens to match that for a deposit. This is to do with some silly 
risk rules which required derivatives on deposits to be treated as 
deposits in some situations, ie each contract counted as a million euros 
on your books.

> Thank you!
>
>
>    On Thursday, November 2, 2023 at 05:08:19 PM EDT, Trent Maetzold <tr...@ma...> wrote:
>
>  I’m looking at mine and they follow imm dates, monthly starts for the first six contracts then the standard imm dates for the next 6. Use ql.IMM.nextDate(date, False) to get the series of monthly IMM dates.
> Then pass the start and end date to the futures rate helper constructor.
> Sent from Proton Mail for iOS
>
> On Thu, Nov 2, 2023 at 15:55, ze73 man <ze7...@ya...> wrote:
>  Thanks, Trent. I followed your suggestion and created a new index.
> However ql.FuturesRateHelper expects IMM futures and checks for IMM dates here so I get the error below. It seems the only way to use the rate helper with non-IMM futures is to add support for it in C++ and recompile quantlib? These futures are trading on ICE Futures Europe (Three Month Euribor Futures) and the expiration schedules are different. I don't see a way to use the underlying RateHelper class or /BootstrapHelper template in Python.
> RuntimeError: November 13th, 2023 is not a valid IMM date
> Any thoughts on this are welcome. Thanks, everyone!
>    On Wednesday, November 1, 2023 at 06:33:11 PM EDT, Trent Maetzold <tr...@ma...> wrote:
>
>  Create the IborIndex directly. https://quantlib-python-docs.readthedocs.io/en/latest/indexes.html#ql.IborIndex
> Sent from Proton Mail for iOS
>
> On Wed, Nov 1, 2023 at 17:27, ze73 man via QuantLib-users <qua...@li...> wrote:
> Hi QuantLib Gurus!
> I am experimenting with ql.FuturesRateHelper to use this market data 3-Month EuriBor Futures Prices to evaluate if a EURIBOR forward curve created this way might be viable for my use-case. The index class ql.Euribor3M() in theory facilitates the setup however it represents the IMM index so the calendar is different, the expiration dates different, etc...
> I did see a FuturesEU calendar in the QuantExt project derived from QuantLib, meant to represent the ICE Futures Europe calendar, which could be a starting point, but is there no standard ql.Euribor3M() equivalent in quantlib for ICE? Does anyone know of an example set up of a ICE Europe futures contract using quantlib, please? Would this warrant a new rate helper or at least new index class?
> Kind regards
>
> Ze
>
> |
> |
> |
> |  |  |
>
> |
>
> |
> |
> |  |
> 3-Month EuriBor Prices and 3-Month EuriBor Futures Prices - Barchart.com
>
> Today's 3-Month EuriBor prices with latest 3-Month EuriBor charts, news and 3-Month EuriBor futures quotes.
> |
>
> |
>
> |
>
>  
>
>
>
>
>

-- 
"Ah", said Arthur, "this is obviously some strange usage of the word
'safe' that I wasn't previously aware of."