Skip to content

Allow negative paymentlag - #224

Open
kohnech wants to merge 2 commits into
OpenSourceRisk:masterfrom
Model-Validation:feature/allow-negative-paymentlag
Open

Allow negative paymentlag#224
kohnech wants to merge 2 commits into
OpenSourceRisk:masterfrom
Model-Validation:feature/allow-negative-paymentlag

Conversation

@kohnech

@kohnechkohnech commented Mar 8, 2024

Copy link
Copy Markdown
Contributor

This pull request incorporates modifications from QuantLib, enabling the handling of negative payment lags, as implemented in QuantLib PR #1818.

It is recommended to merge this pull request after updating ORE QuantLib with the corresponding changes.

Aligning with the modification in QuantLib (PR 1818), this commit implements the update to the payment lag in ORE. The adjustment now accommodates negative values using Integer data type.
@kohnechkohnech changed the title Feature/allow negative paymentlagAllow negative paymentlagMar 9, 2024
@kohnech

kohnech commented Mar 11, 2024

Copy link
Copy Markdown
ContributorAuthor

There are still some places left where Natural payment lag is still being used in ORE but these where not changed and we are not certain they should allow a negative payment lag:

  • EquityCoupon
  • EquityMarginCoupon
  • DurationAdjustedCMSCoupon
  • FormulaBasedCoupon/Leg

Should we add to the user guide that there are exceptions for a negative payment lag?

@pcaspers

pcaspers commented Mar 27, 2024

Copy link
Copy Markdown
Collaborator

Generally, all coupon types should support negative payment lag as long as the resulting payment date makes sense economically, i.e. the amount is fully determined before or on the payment date. But that's already the case for in arrears fixed term rates or the old ibor coupons.

In particular, DurationAdjustedCMSCoupon, FormulaBasedCoupon should support the feature, they are not different than any other coupon. The other two probably too, as long as the above restriction is fulfilled.

It's also generally desirable to have the same technical treatment in all coupon classes. They should throw an error instead if the resulting pay date does not make sense.

Does that make sense?

@damienbarkerdamienbarker self-assigned this Apr 19, 2024
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@kohnech@pcaspers@damienbarker