Can a roll convention imply a stub?

[scolebourne]

We have always worked on the basis that FpML has no implied stubs. However, we have seen an example which challenges this. I’d like to get an official/practical opinion on it.

Consider a 2 year semi-annual swap with the following aspects:

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?
Note that the first period is an implied long stub.

Our (Strata – http://strata.opengamma.io/apidocs/com/opengamma/strata/basics/schedule/PeriodicSchedule.html) schedule builder decides this is invalid, because the start date (2016-04-28) does not match the EOM convention (it is not at the end of the month), so it must be an invalid date (as it would imply a stub).

However, the actual wording of rollConvention says “Used in conjunction with a frequency and the regular period start date of a calculation period, determines each calculation period end date within the regular part of a calculation period schedule.”

So, one way to read the specification is that the FpML document is declaring that the period from 2016-04-28 to 2018-04-30 is the “regular part of the calculation period schedule”. And that the roll convention determines *end dates* irrespective of whether the start date matches the convention. Thus, the first calculation period is obtained by adding 6 months to the 2016-04-28 and adjusting to EOM to get 2016-10-31. With this reading, the only validation of the start date is that it is a multiple of 6 months away from the end date.

But reading the spec this way would suggest that this swap:

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

would also be valid, with the calc periods:
2016-04-01 – 2016-10-20 – 2017-04-20 – 2017-10-20 – 2018-04-20
which is very definitely a long initial stub (and a short stub could also be setup this way).

So, are roll conventions within the regular part of the schedule supposed to be interpreted strictly (first regular start date must match roll convention) or leniently (which results in implied stubs)?

[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 8 years, 1 month ago by aarabadji.
• This reply was modified 8 years, 1 month ago by aarabadji.

[scolebourne]

Thanks for the reply, my opinion was that it is invalid FpML. As you say, the 29th and 30th April are holidays/weekends in this example, so someone is clearly misusing EOM to mean “last business day of the month”.

[h_mcallister]

I agree, a valid FpML swap has no implied stubs. By definition, the regular part of the calculation period schedule is the portion where (unadjusted) period start|end dates conform to the roll convention. This comprises (at a minimum) the period defined by the “internal” roll dates (i.e. between the first period end date and last period start date) – and also the effective|termination dates in the absence of initial|final stubs.

There is one way in which the example in question could constitute valid FpML: I don’t know which business centers are referenced, but if we allow that 2016-04-29 (Friday) is a holiday, then effectiveDate/unadjustedDate could be declared as 2016-04-28 (Thursday) with dateAdjustments/businessDayConvention=NONE, signifying that applicable adjustments have already been applied. Then the unadjusted effective date *implied* by the roll convention is 2016-04-30 (Sunday), which adjusts to 2016-04-28 under the MODFOLLOWING rule. Given these particular circumstances, the FpML would be valid.

[h_mcallister]

I note that the text description of ird-10 does not match the XPath definition (no mention of last-day-of-month in the English language description). This rule can fail in the legitimate edge case described above (pre-adjusted effectiveDate with businessDayConvention=”NONE”).

• This reply was modified 8 years, 1 month ago by h_mcallister.

[scolebourne]

So, in this case, 2016-04-28 is the last business day of the month (2016-04-29 is a holiday and 2016-04-30 is a Saturday). And the business day convention of the effective date is NONE, so it matches your special case. (For info, the trade date is 2016-04-26, so the 28th is perfectly reasonable as the effective date of the trade)

However, I have seen nothing in the FpML specs that allows businessDayConvention=NONE to be interpreted as “pre-adjusted”. The description of NONE says “The date will not be adjusted if it falls on a day that is not a business day”, which simply implies that no adjustment should occur, which is a different concept to pre-adjusted. Is NONE always interpreted this way?

In addition, I don’t see anything in FpML that could be used to imply the unadjusted date from the adjusted one. In your example, you have used MODFOLLOWING to justify treating the unadjusted date to 2015-04-31, but where does that come from? The only place I can see that could apply is calculationPeriodDatesAdjustments/businessDayConvention, but I see nothing in the spec to justify that interpretation. And even if that was the interpretation, there is insufficient data to say that 2016-04-31 is the unadjusted date, when either 2016-04-30 or 2016-04-29 would also result in the same adjusted date when MODFOLLOWING is applied.

The ird-10 rule xpath only applies when the roll convention is a number, so would not apply in this case where roll convention is “EOM”. Same for ird-11. And if EOM were allowed in ird-10, it would still say that 2016-04-29 invalid.

Am I missing something, or is this an undocumented edge case / de facto usage?

thanks!

• This reply was modified 8 years, 1 month ago by scolebourne. Reason: edited the dates in the first paragraph

[h_mcallister]

In fact it is common practice to confirm the effective date of a IR Swap as an *adjusted* value; being close to the trade date, the adjusted effective date can be specified with a high degree of confidence. Then conventional usage is to specify effectiveDate/dateAdjustments/businessDayConvention=”NONE”, signalling that no further adjustment is required (note, this usage pre-dates the availability of adjustedDate in the AdjustableDate type).

To determine whether the (implicitly adjusted) effective date implies a stub, it is necessary to consider whether the effective date value is consistent with the *unadjusted* date implied by calculationPeriodDatesAdjustments/businessDayConvention in conjunction with calculationPeriodFrequency. This in turn requires access to reference data (holiday calendar(s) for the relevant business centers), so cannot be determined from the content of the FpML document alone.

Provided the implicity adjusted effective date is derivable from the regular calculation period parameters, together with any applicable date adjustments, no stub exists. Where the effective date is not consistent with the regular period parameters plus adjustments, a stub exists and firstRegularPeriodStartDate must be specified.

So in answer to your final question: yes, this is de facto usage, consistent with the FpML specification.

With apologies for the delayed response.
Harry McAllister

• This reply was modified 8 years, 1 month ago by h_mcallister. Reason: changes to emphasis
• This reply was modified 8 years, 1 month ago by h_mcallister.
• This reply was modified 8 years, 1 month ago by h_mcallister.

[scolebourne]

Thanks for the clarification. We’ve updated Strata to match this as best we can, but its certainly tricky de facto usage – https://github.com/OpenGamma/Strata/blob/master/modules/basics/src/main/java/com/opengamma/strata/basics/schedule/PeriodicSchedule.java#L773

[h_mcallister]

The implementation looks reasonable, thanks.

I noticed this at line 774 in the comments:

// applies rule to handle misuse of EOM to mean last business day for startDate

I’m not sure why this is characterised as “misuse” (e.g. EOM + MODFOLLOWING would always imply an adjusted date falling on the last business day of the month)?

• This reply was modified 8 years ago by h_mcallister.

[scolebourne]

Thanks for taking a look. I think that comment pre-dates this discussion and probably needs rewording to refer to de facto usage. As I said above though, I haven’t seen anything in the schema or documentation that describes this de facto usage, and we certainly consider it surprising. If you think of any other corner cases that we might not have handled, we’d love to know!

[Author]

Posts