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.092% (+0.2%) from 73.873%
when pulling b8a116f 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.

paolodelia99 · 2025-09-30T09:27:08Z

ql/cashflows/blackovernightindexedcouponpricer.cpp

+    Rate BlackAverageONIndexedCouponPricer::swapletRate() const { return swapletRate_; }
+
+    Rate BlackAverageONIndexedCouponPricer::capletRate(Rate effectiveCap) const {
+        return coupon_->localCapFloor() ? optionletRateLocal(Option::Call, effectiveCap)


The thing is that the CappedFlooredOvernightIndexedCoupon has the localCapFloor_ attribute which I think is more a property of the coupon than a property of the pricer.

Hmm, I see. The Black Ibor pricer doesn't have this problem because it doesn't need other data from the coupon besides the effective cap which is passed through the interface. Let me think a bit about it. And of course you're welcome do to some thinking of your own.

I was thinking that defining an overload of capletRate(Rate) (and similarly floorletRate(Rate)) with the signature capletRate(Rate effectiveCap, bool localCapFloor) might be a good approach. After all, these functions are only ever called by the coupon. The implementation provided by the FloatingRateCouponPricer interface could simply call this overload, passing false for the localCapFloor parameter.

lballabio · 2025-10-08T15:58:43Z

ql/cashflows/overnightindexedcouponpricer.hpp

    };
+
+    //! capped floored overnight indexed coupon pricer base interface
+    class CappedFlooredOvernightIndexedCouponPricer : virtual public OvernightIndexedCouponPricer {


This can probably be folded into OvernightIndexedCouponPricer so you can avoid the double inheritance in the Black pricers. With methods like capletPrice, floorletPrice and setCapletVolatility, OvernightIndexedCouponPricer is already supposed to be used for capped coupons too.

The double inheritance is avoided because I've used virtual inheritance, but yeah at this point it makes more sense to put everything under the OvernightIndexedCouponPricer at this point since I've already pass the optionletVolatilityTermStructure in the class constructor.

… 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 · 2025-10-15T09:00:21Z

ql/cashflows/blackovernightindexedcouponpricer.hpp

+    highly experimental and ad-hoc. As soon as a market best practice has evolved, the pricer
+    should be revised. */
+    class BlackOvernightIndexedCouponPricer : public CompoundingOvernightIndexedCouponPricer {
+    using CompoundingOvernightIndexedCouponPricer::CompoundingOvernightIndexedCouponPricer;


You're importing the base-class constructor but you're also declaring in this class a constructor with the same signature. (Maybe it's the cause of the error in the Appveyor build?) You only need one.

lballabio · 2025-10-15T09:01:01Z

ql/cashflows/blackovernightindexedcouponpricer.hpp

+    highly experimental and ad-hoc. As soon as a market best practice has evolved, the pricer
+    should be revised. */
+    class BlackAverageONIndexedCouponPricer : public ArithmeticAveragedOvernightIndexedCouponPricer {
+    using ArithmeticAveragedOvernightIndexedCouponPricer::ArithmeticAveragedOvernightIndexedCouponPricer;


Here the signature is different, but do you really want to import the base-class constructor?

lballabio · 2025-10-15T09:02:32Z

ql/cashflows/couponpricer.cpp

+                const ext::shared_ptr<BlackOvernightIndexedCouponPricer> overnightCouponPricer =
+                    ext::dynamic_pointer_cast<BlackOvernightIndexedCouponPricer>(pricer_);
+                QL_REQUIRE(overnightCouponPricer,
+                       "pricer not compatible with capped-floored overnight indexed coupon");


This way you're making it impossible to define and use another capped/floored pricer which is not Black. Same below.

Should I only check whether the pricer is a child of OvernightIndexedCouponPricer then?

Yes, I think so.

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?

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 ?

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

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

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

		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

Uh oh!

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!

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!

paolodelia99 Oct 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

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!

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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

paolodelia99 commented Aug 23, 2025 •

edited by lballabio

Loading

coveralls commented Aug 23, 2025 •

edited

Loading

paolodelia99 Oct 10, 2025 •

edited

Loading