Inconsistency in PAR sensitivity for XBS instrument

[noonediesalone]

Hi,

Just wanted to describe a small inconsistency wrt PAR sensitivity and yield bootstrap for cross currency swap instrument.

Example situation is for value date 2024-04-26 for cross currency basis spread of JPY on EUR.
CrossCurrencyBasis convention defines SettlementDays = 2 and a London + Tokyo as SettlementCalendar.
Note, on neither of these calendars is 2024-05-01 a holiday but 2028-05-01 will be a holiday in London calendar as 1st Monday in May.
Also, the convention defines OIS indexes as <FlatIndex>EUR-ESTER</FlatIndex> and <SpreadIndex>JPY-TONAR</SpreadIndex>.

If we run the curve build, this is fine. But if we run the PAR sensitivity with this convention on 4Y shift tenor will raise a degenerate schedule exception:

degenerate single date (May 2nd, 2024) schedule\n seed date: May 2nd, 2024\n exit date: May 1st, 2024\n effective date: May 1st, 2024\n first date: null date\n next to last date: null date\n termination date: May 2nd, 2024\n generation rule: Backward\n end of month: 0

We end up in this situation because applying settlement days (=2) to the value date (=2024-04-26) gives us an effective date of 2024-05-01 (because 2024-04-29 is holiday in joint settlement calendar) and for 4Y instrument it gives 2028-05-02 (because 2028-05-01 is holiday in joint settlement calendar). This is according to

Engine/OREAnalytics/orea/engine/parsensitivityanalysis.cpp

Line 1761 in 1efe568

Date end = conv->settlementCalendar().advance(start, term, conv->rollConvention());

where the termination date is adjusted. Then next a schedule is generated between effective and maturity dates, with flat resp. spread terms, but on the same settlement calendar. Because of the Backward date generation method, these schedules will have a short stub at the beginning of a single day [2024-05-01, 2024-05-02]. This is fine for the JPY leg (because both dates are working days according to the settlement calendar), but is not fine for the EUR leg (because 2024-05-01 is holiday according to EUR calendar) and this will raise the degenerate schedule exception.

Now, there are 2 points would like to raise:

1. CrossCurrencyBasis should probably have additional calendars for flat and spread legs. This also leads to an imprecision in the curve since the instrument schedules are not aligned to the calendars for each of the currencies. The instrument helper CrossCcyBasisSwapHelper has parameters for flatCalendar and spreadCalendar but are passed empty because the convention has none of them;
2. Inconsistency between PAR sensitivity instrument and yield bootstrap instrument. The curve builds because the helper instrument does not adjust the maturity:
   

   Engine/QuantExt/qle/termstructures/crossccybasisswaphelper.cpp

   Line 115 in 1efe568

   Date maturityDate = settlementDate + swapTenor_;

   which in this case removes the short start stub.

Regards,
Laurentiu.

[pcaspers]

Thank you! Do you know what the correct construction would be? I.e. would the separate calendars and adjusting the termination date in the curve helper lead to correct results?

I would think in reality there is no front stub in the traded swaps.

[noonediesalone]

Generally, for curve build, the termination date is adjusted with calendar and roll convention of the spread leg.
And the schedules of each leg follow it's respective (calendar, roll) adjustment rules.
Also, about stubs, I think usually it's a "short end" type, meaning the schedule is generated from the effective date, which corresponds to DateGeneration::Forward and maybe this should also be exposed as input to CrossCurrencyBasis convention.

So I think it would be great if convention could be enhanced to specify (Calendar, RollConvention and DateGeneration) for each of the legs and be used in the curve helper.

[pcaspers]

That makes sense.

Maybe it's a long stub at the end, i.e. a slightly prolonged last coupon period?

[noonediesalone]

Yes you're right, seems long end stub is the preferred choice for traded swaps.
Not sure if that's also the case for building the curve.
Looks Forward generation method behaves like short end stub in absence of nextToLastDate_.