Const Notional Cross Currency Swaps

[paolodelia99]

Partially solving #2201 by adding const notional xccy swaps classes from ORE and readapting them to the current QuantLib version. MTM xccy swap will be added in another PR.

Classes added:

• CrossCcySwap: base class for a cross currency swap
• CrossCcyFixFloatSwap: cross currency swap with a fixed leg and a floating leg
• CrossCcyBasisSwap: cross currency swap with two floating legs
• CrossCcySwapEngine: the cross currency swap engine

[coveralls]

coverage: 73.854% (+0.04%) from 73.814% when pulling 9c82a36e02280f4a95cc99ba20e23350ebbdad33 on paolodelia99:feature/const-notional-xccy into 4460bb64b83fffe0a12cea39ba90d2ba0330600a on lballabio:master.

[lballabio]

@pcaspers — I'm assuming you're still ok with moving things here from ORE, give me a shout if things changed. Thanks!

[pcaspers]

@pcaspers — I'm assuming you're still ok with moving things here from ORE, give me a shout if things changed. Thanks!

We are ok with that. My only ask would be to keep ORE aligned, i.e. remove the classes from ORE and make sure ORE still works with the ql version.

[paolodelia99]

@pcaspers - One thing, in the CrossCcyBasisSwap class I haven't included the case when one of the of the legs are averaged ON indexes (recIsAveraged and payIsAveraged have been deleted from the constructors arguments). Should I also include those cases in the CrossCcyBasisSwap class?

[pcaspers]

@pcaspers - One thing, in the CrossCcyBasisSwap class I haven't included the case when one of the of the legs are averaged ON indexes (recIsAveraged and payIsAveraged have been deleted from the constructors arguments). Should I also include those cases in the CrossCcyBasisSwap class?

Yes please, CrossCcyBasisSwap is supposed to support overnight legs. I ddn't check this PR in detail, but as I said above, I would appreciate if all functionality is preserved and a corresponding PR is opened for ORE that allows to remove the migrated classes in ORE and rely on the then-ql classes.

[lballabio]

Yes please, CrossCcyBasisSwap is supposed to support overnight legs

Agreed — but should we use bools like recIsAveraged or autodetect overnight indexes based on the class? I think we started doing the latter of late and it might be more convenient.

[paolodelia99]

Another thing @pcaspers, I see that in ORE you are using a different OvernightLeg than in QuantLib (with a bunch of other additional methods like withCaps, withFloors, withNakedOptions, ...), on top of that AverageONLeg is not present in QuantLib but you have two different pricers for AverageONIndex pricers in ORE and QuantLib, AverageONIndexedCouponPricer in ORE and ArithmeticAverageOvernightIndexCouponPricer in QuantLib. Don't know If they are meant to price the same type (they are both using the Takada approximation) of copouns since the one in QuantLib can also take into account covexity adjustements.

How should I tackle this problem?

@lballabio seeking you guidance as well

[lballabio]

Another thing @pcaspers, I see that in ORE you are using a different OvernightLeg than in QuantLib (with a bunch of other additional methods like withCaps, withFloors, withNakedOptions, ...), on top of that AverageONLeg is not present in QuantLib but you have two different pricers for AverageONIndex pricers in ORE and QuantLib, AverageONIndexedCouponPricer in ORE and ArithmeticAverageOvernightIndexCouponPricer in QuantLib. Don't know If they are meant to price the same type (they are both using the Takada approximation) of copouns since the one in QuantLib can also take into account covexity adjustements.

Hmm, if that's the case it's probably better to make another PR first that sorts out the overnight leg and pricers. @pcaspers, do you happen to have a summary of the differences?

[pcaspers]

Ah yes, ORE and QuantLib diverged for the on coupons a while ago. I'd think they have roughly the same functional scope. QuantLib is more elegant. ORE might have some extensions like a freely definable rate computation period.

Also, ORE adds cap / floors on overnight coupons.

It would be great if someone could work on aligning QuantLib and ORE in this regard. It's on our roadmap for a while, but we never came around to actually do this.

And yes, we probably better do this before migrating dependent classes like the xccy swap.

[paolodelia99]

All right, make sense to work on the copouns differences before introducing these new classes.

I'll try to work on it, since I've already spotted some of the differences.

I'll ping you guys (@lballabio, @pcaspers) if I need any help with that.

[github-actions[bot]]

This PR was automatically marked as stale because it has been open 60 days with no activity. Remove stale label or comment, or this will be closed in two weeks.

[LZ1153]

I don't mean to rush you, it seems we are quite close to resolve this request @paolodelia99 ?

[paolodelia99]

Hi @LZ1153, once the #2297 will be merged then I can come back to work on this issue and make the some final adjustments based on the newer coupon classes. Please have a little bit of more patience.

[LZ1153]

Sure no problems at all. Apologies I've missed that PR Thanks for your vast efforts @paolodelia99 !