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

[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

[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

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

[scolebourne]

Yes, my mistake!

[scolebourne]

I would change the text of notionalAmountSchedule to something like this:

“The known calculation period amount or a known amount schedule expressed as explicit known amounts and dates. In the case of a schedule, the step dates must match the unadjusted dates implied by paymentDates. The schedule is applied to the payment periods and does not define payment dates. For example, consider a schedule with an initial amount of 1000 and a step amount of 1200 on 2016-01-10. Any payment period before 2016-01-10 uses 1000 and any payment period after 2016-01-10 uses 1200. If paying in arrears, then a payment will occur on of near 2016-01-10. This will refer to the period that ends on 2016-01-10 and thus pay 1000. When notionalAmountSchedule is specified, resetDates must be absent and stubCalculationPeriodAmount must, if present, refer only to a known amount. In general, notionalAmountSchedule is only used for a zero coupon bullet payment and the step dates/values are not present.”

[scolebourne]

The code we use can be seen here:
https://github.com/OpenGamma/Strata/blob/master/modules/loader/src/main/java/com/opengamma/strata/loader/impl/fpml/SwapFpmlParserPlugin.java#L145

We parse the knownAmountSchedule from FpML, ensuring that the stubCalculationPeriodAmount and resetDates elements are not present. This is parsed to form a KnownAmountSwapLeg, which also contains the parsed schedule. The swap leg class interprets the schedule as related to periods, not dates. The initial known amount is allocated to the first period and all subsequent periods until the known amount schedule indicates a change.

For example, consider a two year swap where each payment period is 3 months long. The known amount schedule could define two entries, one that defines the payment amounts as GBP 1000 for the first year and one that defines the amount as GBP 500 for the second year. (ie. in FpML an initialValue of 1000 and a single step of 500 at the one year point). In this case there will be eight payments in total, four payments of GBP 1000 in the first year and four payments of GBP 500 in the second year. Each payment will occur on the payment date related to the period.

Note that with payment in arrears, the payment date at the one year point will refer to 1000, as that is the applicable value for that period, even though the step change date in notionalStepSchedule might be the same date. (Because we always interpret steps as setting a value for the period, not defining actual action dates, which vary based fixing start/end or payment start/end.)

This is the documentation of the schedule:
http://strata.opengamma.io/apidocs/com/opengamma/strata/product/swap/KnownAmountSwapLeg.html#getAmount–

Hope that helps explain what we do. Feel free to ask if not clear.

[scolebourne]

Thanks for responding Harry. We at OpenGamma Strata provide full ability to define a swap leg using known amounts for each period, and can parse this from FpML using a sensible interpretation of the spec (outlined above). Adding additional rules to clarify this would have been helpful, but makes little difference to us.

[scolebourne]

Is there somewhere else that these issues should be raised?

[scolebourne]

Thanks for replying.

For me, a float leg of 20.02.2005-22.05.2005 is a stub, as the dates do not both match the implied roll convention of 22. If your reply is correct, then I’d have to assume that the intended rule is to calculate the schedule of periods using the effective date first, then replace the effective date with the firstPeriodStartDate extending the first period as necessary. (I’d also have to assume that the fact that the roll convention is “NONE” rather than “22” is significant.)

I don’t see how to get 20.02.2005-31.12.2005 for the fixed leg. Nothing in the example indicates periods based on calendar years. IIUC, the yearly frequency is just that, periods of one year rolling just like periods of 3 months would. Thus, if we adopt the rule outlined above, I’d calculate 20.02.2005-22.02.2005 for the fixed leg.

On compounding, the example has calculation period of 1Y and payment period of 1T (term), hence my belief that a compounding method is needed. For a 30 year swap, accruing yearly but paying once at the end, compounding would be quite significant!

[Author]

Posts