Question on fixing date used in notional adjustment of MtmCrossCurrencyBasisSwapRateHelper

[aaroncgw]

I have a question regarding the date used for notional adjustment calculation in MtmCrossCurrencyBasisSwapRateHelper.

In the current implementation (see link below), the notional adjustment appears to be taken on the coupon start date, without applying the fixingDays adjustment:

https://github.com/lballabio/QuantLib/blob/master/ql/experimental/termstructures/crosscurrencyratehelpers.cpp#L134

For MtM cross currency swaps, my understanding is that the notional adjustment factor should based on a date (fixingDate) such as:
fixingDate = accrualStartDate - fixingDays

Before assuming anything is missing, I wanted to check whether:

1. the FX fixing lag adjustment is applied elsewhere in the helper or swap construction, and I may have overlooked it, or
2. the fixing date is intentionally taken as the coupon start date, even when the fixingDays is set, or
3. the lagged fixing date should be used here but is currently not applied.

[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.

[marcin-rybacki]

Hi there!

The FX helpers that are currently available are modelling deliverable products. The feature that you are referring to seems to be something that is characteristic for non-deliverable instruments. There indeed one needs to provide the FX fixing settlement rule (delay) to convert the cash flow from foreign currency to domestic currency, in which it is settled.

[aaroncgw]

Thanks for the clarification. I believe there may be a misunderstanding about the role of fixingDays in FX-resettable cross-currency swaps.

In MtM (notional-reset) cross-currency swaps, the FX fixing date is not the settlement/payment date. The market convention is that the FX rate used for the notional reset is fixed a few business days before the accrual start date (e.g., T-2). The actual coupon or notional-exchange settlement happens later and follows its own payment-lag rules.

This convention applies to deliverable resettable cross-currency swaps as well — it is not specific to non-deliverable instruments. ISDA documentation and market references (e.g., Clarus FT and ARRC RFR XCCY conventions) explicitly describe FX resets being taken prior to the coupon start date, with payment occurring later.

The current implementation in the helper uses the start date directly as the fixing date, which bypasses the fixing days can lead to using an incorrect discount factor for the notional adjustment.

[marcin-rybacki]

Ok, thank you for clarifying and this is a valid point. At the moment the FX fixing delay simply follows the settlement delay, but we could extend the helper to address this.

[aaroncgw]

Thanks for the clarification — that makes sense, and extending the helper to handle FX fixing lags explicitly sounds like the right approach.

Since Luigi mentioned the next QuantLib release might be planned for early January: would this fix be targeted for that release? I’d be happy to test a patch or contribute if that helps.

While reviewing the implementation further, I also noticed a related issue in the handling of the notional exchange dates. In:

QuantLib/ql/experimental/termstructures/crosscurrencyratehelpers.cpp

Line 253 in 5945c89

initialNotionalExchangeDate_ = calendar_.advance(earliestDate_, paymentLag_, Days, convention_);

initialNotionalExchangeDate_ and finalNotionalExchangeDate_ are adjusted using the payment lag. However, earliestDate_ and maturityDate_ passed into the helper have already been adjusted by fixingDays, as done here:

QuantLib/ql/experimental/termstructures/crosscurrencyratehelpers.cpp

Line 47 in 5945c89

Date earliestDate = calendar.advance(referenceDate, fixingDays * Days, convention);

This seems to apply both the fixing-day and payment lag shifts to initialNotionalExchangeDate_ and finalNotionalExchangeDate_ ? And I’m not sure why the helper shifts earliestDate_ and maturityDate_ by the FX fixing lag in the first place — those dates represent accrual boundaries, not fixing dates?