[aarabadji]

effectiveDate/unadjustedDate = 2016-04-28
terminationDate/unadjustedDate = 2018-04-30
calculationPeriodFrequency/periodMultiplier = 6
calculationPeriodFrequency/period = M
calculationPeriodFrequency/rollConvention = EOM
(both firstRegularPeriodStartDate and lastRegularPeriodEndDate are not present)

Are these the calc period dates:
2016-04-28 – 2016-10-31 – 2017-04-30 – 2017-10-31 – 2018-04-30
Or is this definition invalid?

This FpML violates rule ird-10, therefore it is invalid. If you take a look at some of the invalid test cases, some of them look remarkably similar to your example.
I noticed that in some cases (particularly if effective date lands on last business day of the month), clients prefer to force roll convention to EOM. This implies a stub, in most cases, a long initial one. FpML requires to specify such stubs explicitly.

• This reply was modified 7 years, 7 months ago by aarabadji.
• This reply was modified 7 years, 7 months ago by aarabadji.

[aarabadji]

Hi ai,

I don’t think what you are trying to do is valid FpML.

There are 2 more important rules that govern how calc, pay and reset frequency relate to each other:
ird-2 – http://www.fpml.org/spec/fpml-5-6-5-rec-1/html/confirmation/validation-rules/rules-english-ird.html#ird-2
ird-5 – http://www.fpml.org/spec/fpml-5-6-5-rec-1/html/confirmation/validation-rules/rules-english-ird.html#ird-5

This means 2 things:
1) You can’t pay more frequently than you calculate payments
2) You can’t calculate payments more frequently than you reset the index

I.e. the scenario you describe is actually invalid, in order to satisfy ird-2 and ird-5:
paymentPeriod >= calculationPeriod >= resetPeriod.

[aarabadji]

Floating leg swap stream will have a /floatingRateCalculation element within it. Also if you are *not* using pretrade view, it should also have /resetDates. Note, however, that if you are working with pretrade view, /resetDates are optional.

[Author]

Posts