QL-ORE ON coupons alignment #2297

paolodelia99 · 2025-08-23T16:30:24Z

This PR tries to be an alignment for the difference of the overnight coupons and ON coupons pricers in QuantLib and ORE.

Changes to note for ORE (@pcaspers ):

the OvernightIndexedCouponPricer code is in the overnightindexedcouponpricer.hpp file not in the overnightindexedcoupon.hpp file anymore.
rateCutoff in ORE is lockoutDays in QuantLib
fixingDays in ORE is lookbackDays in QuantLib
there is no AverageONIndexedCoupon in QuantLib the averaging method is passed as a argument in the OvernightIndexedCoupon and it is an enum type:

 struct RateAveraging {
        enum Type {
            Simple, 
            Compound 
        };
    };

The QL OvernightIndexedCouponPricers pricing logic haven't been changes since I haven't noticed substantial differences (apart from the rateCutoff and fixingDays naming conventions). The only thing that I'm unsure of is the following line. I haven't seen such thing in QuantLib.

Changes to note in QL (@lballabio ):

Added CappedFlooredOvernightIndexedCoupon class under overnigthindexcoupon.hpp (imported from ORE)
Added BlackOvernightIndexedCouponPricer and BlackAverageONIndexedCouponPricer for pricing capped / floored compounded ON coupons (imported from ORE)
Added a bunch of other methods in the OvernightLeg class (includeSpread, withCaps, withFloors, withNakedOption, ...) imported from ORE
Added includeSpread, rateComputationStartDate, rateComputationEndDate arguments to the OvernightIndexedCoupon constructor (missing args from ORE)

…ormat code

coveralls · 2025-08-23T17:27:43Z

coverage: 74.137% (+0.3%) from 73.873%
when pulling 282e742 on paolodelia99:feature/ql-ore-coupons-alignment
into 7a6a9a2 on lballabio:master.

paolodelia99 · 2025-08-27T11:49:55Z

@lballabio I actually need help with the test testOvernightLegWithCapsAndFloors in overnightindexedcoupon.hpp. Don't know why I'm getting different results on different builds, at first I thought that I was due to the usingAtParCoupons optional, but apparently I was wrong. Can you please take a look at it when you have time?

lballabio · 2025-08-27T12:42:56Z

Not a lot of time now unfortunately, but I would try checking that we're not accessing some vector out of its bounds and getting garbage numbers.

lballabio · 2025-09-03T10:43:15Z

I pushed a fix for the failing tests—a couple of bools were left uninitialized.

I still have to do a proper review...

paolodelia99 · 2025-09-03T11:02:14Z

Thank you @lballabio! I didn't have much time to debug the tests lately

lballabio · 2025-09-26T07:50:07Z

Apologies for the long delay. One thing: currently the pricers are defined this way:

classDiagram

class FloatingRateCouponPricer
class CompoundingOvernightIndexedCouponPricer
class ArithmeticAveragedOvernightIndexedCouponPricer
class CappedFlooredOvernightIndexedCouponPricer
class BlackOvernightIndexedCouponPricer
class BlackAverageONIndexedCouponPricer

FloatingRateCouponPricer <|-- CompoundingOvernightIndexedCouponPricer
FloatingRateCouponPricer <|-- ArithmeticAveragedOvernightIndexedCouponPricer
FloatingRateCouponPricer <|-- CappedFlooredOvernightIndexedCouponPricer
CappedFlooredOvernightIndexedCouponPricer <|-- BlackOvernightIndexedCouponPricer
CappedFlooredOvernightIndexedCouponPricer <|-- BlackAverageONIndexedCouponPricer

Instead, I would try to turn it into

classDiagram

class FloatingRateCouponPricer
class CompoundingOvernightIndexedCouponPricer
class ArithmeticAveragedOvernightIndexedCouponPricer
class BlackOvernightIndexedCouponPricer
class BlackAverageONIndexedCouponPricer

FloatingRateCouponPricer <|-- CompoundingOvernightIndexedCouponPricer
FloatingRateCouponPricer <|-- ArithmeticAveragedOvernightIndexedCouponPricer
CompoundingOvernightIndexedCouponPricer <|-- BlackOvernightIndexedCouponPricer
ArithmeticAveragedOvernightIndexedCouponPricer <|-- BlackAverageONIndexedCouponPricer

or maybe, if we need to share something between compounded and averaged, something like

classDiagram

class FloatingRateCouponPricer
class OvernightIndexedCouponPricer
class CompoundingOvernightIndexedCouponPricer
class ArithmeticAveragedOvernightIndexedCouponPricer
class BlackOvernightIndexedCouponPricer
class BlackAverageONIndexedCouponPricer

FloatingRateCouponPricer <|-- OvernightIndexedCouponPricer
OvernightIndexedCouponPricer <|-- CompoundingOvernightIndexedCouponPricer
OvernightIndexedCouponPricer <|-- ArithmeticAveragedOvernightIndexedCouponPricer
CompoundingOvernightIndexedCouponPricer <|-- BlackOvernightIndexedCouponPricer
ArithmeticAveragedOvernightIndexedCouponPricer <|-- BlackAverageONIndexedCouponPricer

What do you think?

paolodelia99 · 2025-09-27T15:33:15Z

2nd and 3rd case make more sense to me. I would opt for the 3rd case. One question: is OvernightIndexedCouponPricer gonna be a virtual class that is just defining the interface for the child classes?

lballabio · 2025-09-29T06:49:23Z

The interface is already declared in FloatingRateCouponPricer. The base class might perhaps store the volatility term structure, but otherwise there's not a lot in common, which is why the existing pricers don't have a common base.

paolodelia99 · 2025-09-29T08:30:33Z

Got it. So the OvernightIndexedCoupon pricer class should do the same thing as the IborCouponPricer class, where the volatility term structure is set by the setCapletVolatility method. In this way, we are going to have a consistent interface among those "base classes".

paolodelia99 · 2025-09-29T15:37:32Z

One problem that I have noticed @lballabio: If BlackOvernightIndexedCouponPricer is going to become a child of CompoundingOvernightIndexedCouponPricer there is going to be a clash in the type of coupon_ attribute, since the the former is a CappedFlooredOvernightIndexedCoupon and in the latter is OvernightIndexedCoupon (They are both child of FloatingRateCoupon). How would you suggest me to tackle this problem?

lballabio · 2025-09-29T16:04:58Z

I think you can copy the approach in CappedFlooredIborCoupon. It inherits from CappedFlooredCoupon, not FloatingRateCoupon directly, and the setPricer method in the base class is overridden so that it sets the passed pricer to its underlying instead of the capped coupon itself. It should work in this case as well. Let me know if you need more details.

ql/cashflows/blackovernightindexedcouponpricer.cpp

ql/cashflows/overnightindexedcouponpricer.hpp

… inheritance among those classes

lballabio

Ok, another round of comments — sorry for the piecewise review, but it's a massive PR...

lballabio · 2025-10-15T08:56:34Z

ql/cashflows/overnightindexedcoupon.hpp

+                    const Date& rateComputationStartDate = Date(),
+                    const Date& rateComputationEndDate = Date());


Probably more for @pcaspers — these two don't seem to be used anywhere in the calculation. Should they be there at all?

@lballabio Apologies for the rather late reply. They can be used to overwrite start and end date

Date valueStart = rateComputationStartDate_ == Null<Date>() ? startDate : rateComputationStartDate_; Date valueEnd = rateComputationEndDate_ == Null<Date>() ? endDate : rateComputationEndDate_;

It's rarely used in practice, but there are exotic variants of on coupons where the compounding takes place over the previous (say) 3m period to get the rate for the current 3m period. We introduced these two fields to model cases like this.

Yes, I can see that was the intent, but those two fields are never assigned to valueStart or used anywhere in the code, hence the question.

We assign them here to valueStart and valueEnd. Sorry, I think I am missing something or we are talking about different branches / files?

Ok, I see, that bit of code wasn't migrated in this PR, which makes those two variables unused here. @paolodelia99, may you have a look?

Yes, I'll take a look at it in the upcoming days. It must have been an oversight of mine.

ql/cashflows/blackovernightindexedcouponpricer.hpp

ql/cashflows/couponpricer.cpp

lballabio · 2025-10-15T09:18:16Z

ql/cashflows/overnightindexedcoupon.cpp

+            return spread();
+
+        if (averagingMethod_ == RateAveraging::Simple)
+            QL_FAIL("Average OIS Coupon does not have an effectiveSpread"); // FIXME: better error message


For @pcaspers — does not have yet, or it can't be defined, or in the simple case is the same as the spread?

Hm. I'd say for Simple the effective spread is equal to the spread, as you say. We don't expose a method therefore in our averaged coupon class, but no reason to fail here in my opinion.

lballabio · 2025-10-15T09:20:17Z

ql/cashflows/overnightindexedcouponpricer.cpp

+        if (!coupon_->includeSpread()) {
+            finalRate += coupon_->spread();
+            effectiveSpread = coupon_->spread();
+            effectiveIndexFixing = finalRate;
+        } else {
+            effectiveSpread = finalRate - (compoundFactorWithoutSpread - 1.0) / tau;
+            effectiveIndexFixing = finalRate - effectiveSpread;
+        }


I'm puzzled here — in the if the effective index fixing equals the final rate and therefore inlcudes the spread, but in the else it seems to exclude it.

You should ask it to @pcaspers, it took this logic from ORE. But I guess in the first case, where the spread is not included in the compounding logic, the effectiveIndexFixing is set to finalRate because the observable/effective fixing used downstream is the final coupon rate after the additive spread.

@pcaspers ?

Looking at the code in QuantExt, OvernightIndexedCouponPricer::compute(), the compoundFactor will include the spread component if and only if includeSpread == true. I.e. the same holds for rate (which is called finalRate here I think)

Rate rate = (compoundFactor - 1.0) / tau;

And for the includeSpread == true case we have to subtract the spread component to get the effective fixing.

Ok, but for the includeSpread == false case you're setting the effective fixing to the final rate, which includes the spread (it's added just two lines above). Shouldn't the spread be excluded?

again maybe we are talking about different branches / files? We set indexFixing to rate here. The spread is added to swapletRate though.

Same here, I'm looking at the code in this PR which differs from the ORE code.

ok then it's a question for @paolodelia99 I guess?

lballabio · 2025-11-10T11:55:03Z

@pcaspers no hurry, just bumping this in case it fell to the bottom of your inbox and got lost, we had a few questions for you above. Thanks!

pcaspers · 2025-11-10T12:28:39Z

I will take a look - I have flagged it in my mailbox :-)

pcaspers · 2025-11-12T07:07:26Z

Thanks for doing all this. @paolodelia99 do you plan to reintegrate the updated ql coupon classes in ore, so that we can get rid of the QuantExt versions of these classes?

paolodelia99 · 2025-11-12T13:18:24Z

Do mean in the ORE's QL fork? @pcaspers
But yeah, it shoudn't be that big of a problem to integrate those changes in ORE.

pcaspers · 2025-11-14T09:22:54Z

Do mean in the ORE's QL fork? @pcaspers But yeah, it shoudn't be that big of a problem to integrate those changes in ORE.

Ultimately yes. Maybe it is enough if you migrate the code to official ql such that we can merge this later into our ql fork and get rid of the QuantExt classes.

…xFixing

paolodelia99 · 2025-11-26T22:14:10Z

@lballabio don't know is it better to set lookbackDays = 0 in the OvernightIndexedCoupon ctor instead of Null<Natural>(), because If I had to use ORE's logic (ORE is using a Period instead of a Natural) in the conditional that I've just imported I would have a bug:

if (lookbackDays != 0) {  //by default lookbackDays is 2147483647
            BusinessDayConvention bdc = lookbackDays > 0 ? Preceding : Following;
            valueStart = overnightIndex->fixingCalendar().advance(valueStart, -lookbackDays, Days, bdc); //error is throw in here: QuantLib::Error: Date's serial number (366) outside allowed range [367-109574]
            valueEnd = overnightIndex->fixingCalendar().advance(valueEnd, -lookbackDays, Days, bdc);
}

lballabio · 2025-11-27T15:46:54Z

Hi Paolo, I'm not sure I understand the question. Right now you have if (lookbackDays != Null<Natural>()) which is correct. Why should it become if (lookbackDays != 0)?

paolodelia99 · 2025-11-27T16:58:39Z

I was just wondering whether to set lookbackDays = Null<Natural>() was the correct approach instead of setting it to 0. Anyway the initial check is correct, so there is no need to change it. Just asking for consistency reasons since lockoutDays = 0 by the ctor, by default

paolodelia99 and others added 11 commits August 7, 2025 12:18

First alignment ORE/QL ON coupon and ON coupon pricer

93e3a24

Add test for the overnightLeg

85216a2

Fix tolerance in overnightleg test

633167f

Added blackovernigthindexedcouponpricer and updated pricesetter methods

121b3f3

Update generated headers

1dc90fd

Update copyright list in license

5092a67

Fix typo in vcxproj file

c8a9a43

Removed pragma once and use ifdef

8081384

removed redundant attributes, add first test for black pricer and ref…

fabeac9

…ormat code

add test for capped-floored on coupons and leg

c4deaad

Fix at par Coupon error

a16c479

paolodelia99 and others added 3 commits August 29, 2025 22:40

add a futher cap and floor rate to match the schedule size in the tests

cf06707

More realistic tests when calculating ON leg npv

db54efa

Initialize flags properly

25c0cd5

paolodelia99 marked this pull request as ready for review September 6, 2025 10:30

paolodelia99 commented Sep 30, 2025

View reviewed changes

ql/cashflows/blackovernightindexedcouponpricer.cpp Outdated Show resolved Hide resolved

paolodelia99 added 2 commits October 4, 2025 16:59

Adjustements to the ON coupon pricers class as suggested

c84af72

made some ctors explicit

9ad665a

lballabio reviewed Oct 8, 2025

View reviewed changes

ql/cashflows/overnightindexedcouponpricer.hpp Outdated Show resolved Hide resolved

paolodelia99 added 4 commits October 10, 2025 17:11

Make onIndexedCouponPricer the base class for the blackONPricers, adj…

40fb327

… inheritance among those classes

Fix compilation error, overload virtual functions

972bace

use ext::dynamic_pointer_cast

87f381b

ovveride cap/floorletRate(Real, bool) and in direct childs

12f9d13

lballabio reviewed Oct 15, 2025

View reviewed changes

Small adjustments as suggested in the PR

b8a116f

paolodelia99 added 2 commits November 26, 2025 23:00

Added adj in ONCoupoon ctor, fix bug when computing the effectiveInde…

6399fca

…xFixing

fix win compilation error using static_cast of lookbackDays

282e742

		const Date& rateComputationStartDate = Date(),
		const Date& rateComputationEndDate = Date());

QL-ORE ON coupons alignment #2297

Are you sure you want to change the base?

QL-ORE ON coupons alignment #2297

Conversation

paolodelia99 commented Aug 23, 2025 • edited by lballabio Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

coveralls commented Aug 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

paolodelia99 commented Aug 27, 2025

Uh oh!

lballabio commented Aug 27, 2025

Uh oh!

lballabio commented Sep 3, 2025

Uh oh!

paolodelia99 commented Sep 3, 2025

Uh oh!

lballabio commented Sep 26, 2025

Uh oh!

paolodelia99 commented Sep 27, 2025

Uh oh!

lballabio commented Sep 29, 2025

Uh oh!

paolodelia99 commented Sep 29, 2025

Uh oh!

paolodelia99 commented Sep 29, 2025

Uh oh!

lballabio commented Sep 29, 2025

Uh oh!

Uh oh!

Uh oh!

lballabio left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lballabio commented Nov 10, 2025

Uh oh!

pcaspers commented Nov 10, 2025

Uh oh!

pcaspers commented Nov 12, 2025

Uh oh!

paolodelia99 commented Nov 12, 2025

Uh oh!

pcaspers commented Nov 14, 2025

Uh oh!

paolodelia99 commented Aug 23, 2025 •

edited by lballabio

Loading

coveralls commented Aug 23, 2025 •

edited

Loading