Potential flaw in Actual/Actual Day Count Convetion when compared to ISDA docs, LSEG and Bloomberg

[denisgeogeo]

It seems as if the ActualActual dc method is producing results different from what the documentation says.

I tried the examples from https://www.isda.org/a/pIJEE/The-Actual-Actual-Day-Count-Fraction-1999.pdf page 2:

Below delivers 150, which is fine
ql.ActualActual(ql.ActualActual.ISMA).dayCount(d1=ql.Date('1999-02-01', '%Y-%m-%d'),
d2=ql.Date('1999-07-01', '%Y-%m-%d'))

Below delivers 183, based on the examples from ISDA, it should deliver 184
ql.ActualActual(ql.ActualActual.ISMA).dayCount(d1=ql.Date('1999-07-01', '%Y-%m-%d'),
d2=ql.Date('1999-12-31', '%Y-%m-%d'))

Below delivers 183, based on examples from ISDA, it should deliver 182
ql.ActualActual(ql.ActualActual.ISMA).dayCount(d1=ql.Date('1999-12-31', '%Y-%m-%d'),
d2=ql.Date('2000-07-01', '%Y-%m-%d'))

I found this issue when trying to compare against Bloomberg and LSEG, which both calculate 107 days with settlement = "2025-07-08" on XS2320031383. Using Actual/Actual.ISMA on QuantLib delivers 106 days, however.

[boring-cyborg]

Thanks for posting! It might take a while before we look at your issue, so don't worry if there seems to be no feedback. We'll get to it.

[martinbrose]

Hi, I'm not sure I can follow your problem here...

Could it be that you are just mixing what .dayCount() is doing compared to accruedDays() in a bond coupon context?

I believe the following is true:

• .dayCount() returns the difference in serial numbers between two dates, excluding the end date:
  https://github.com/martinbrose/QuantLib/blob/master/ql/time/daycounter.hpp#L117-L126

• .accruedDays() computes the difference between the accrual start and end dates:
  https://github.com/martinbrose/QuantLib/blob/master/ql/cashflows/coupon.cpp#L71-L76

So if you would check what accruedDays returns, I'm pretty sure you'll arrive at 184 days and 182 days. The payment dates are 1st of July 1999 and 1st of July 2000. And 31st of December is just an end of year calculation point in the example you reference.

[lballabio]

No, accruedDays calls dayCount, so they return the same number.

The implementation of dayCount that returns the difference between days is a default and should be overridden in ActualActual, but it isn't. The good news is that it doesn't enter accrual calculations; they use yearFraction instead, which doesn't use dayCount and should be implemented correctly (which is probably the reason this wasn't noticed until now).

Thanks for the heads-up.

[bc-davin]

@lballabio can I have this?

[lballabio]

@bc-davin sure, thanks

[lballabio]

On second thought I don't think there's a problem with the day counter as such. It seems that the 31st December 1999 in the figure on page 2 is a red herring.

184 and 182 are not the day counts between 1st July 1999 and 31st Dec 1999 and between 31st Dec 1999 and 1st July 2000.
According to the ISDA documentation "The numerator will, in all three cases, be equal to the actual number of days from and including the last coupon payment date (or period end date) to, but excluding, the current value date (or period end date)".
This means in the first case the days including 1st July 1999 and excluding 31st Dec 1999, and in the second case the days including 31st Dec 1999 and excluding 1st July 2000. If you calculate those, you get 183 and 183.

Instead, 184 and 182 are, among the number of days calculated as above between 1st July 1999 included and 1st July 2000 excluded, those falling in 1999 and 2000 respectively. To calculate them, you need to take the day counts between 1st July 1999 and 1st January 2000 and between 1st Jan 1999 and 1st July 2000 (you can try the actual counting to persuade yourself). This is what the code does, for instance, at https://github.com/lballabio/QuantLib/blob/v1.39/ql/time/daycounters/actualactual.cpp#L298-L299. So I would say the library does the right thing.

This said, the issue with XS2320031383 might be a different one. Can you post what the evaluation date was when you did the calculation, and what you were calculating exactly? Thanks!

[DanielWangZe]

Looks like results are compared against different date pairs than what QuantLib is computing. The ISDA document's 184 and 182 are the lengths of the reference coupon periods (Jan 1/Jul 1 coupon dates), not the raw day counts.

Day Pair | Actual Days | What it represents
1999-07-01 -> 1999-12-31 | 183 | test case
1999-07-01 -> 2000-01-01 | 184 | ISDA reference
1999-12-31 -> 2000-07-01 | 183 | test case
2000-01-01 -> 2000-07-01 | 182 | ISDA reference

The ISDA document's examples use bonds with coupon dates on January 1 and July 1. The 184 and 182 are the lengths of those semi-annual coupon periods:

• Jul 1, 1999 → Jan 1, 2000 = 31+31+30+31+30+31 = 184 days
• Jan 1, 2000 → Jul 1, 2000 = 31+29+31+30+31+30 = 182 days (2000 is a leap year)

While test uses 1999-12-31 instead of 2000-01-01, which is one day off from the actual coupon dates in the ISDA examples. QuantLib is returning the correct actual calendar day counts for the dates provided.