Missing IRD knownAmountSchedule validation rules

[scolebourne]

There appear to be some validation rules missing in IRD around “knownAmountSchedule”.

If “knownAmountSchedule” is present, then “calculation” is not present. As such there will be no notional or day count. This means that it is not possible to perform a calculation based on a rate. Thus, “stubCalculationPeriodAmount” should only be allowed to contain a known amount (not a rate or index-based calculation). It also means that “resetDates” and “principalExchanges” are not applicable. These should all be added as validation rules.

Finally, “knownAmountSchedule” claims to be able to vary for each accrual period, however, without a compounding method setting available, that does not make sense. Surely, “knownAmountSchedule” should only be able to vary at the payment period boundaries? This affects validation rule ird-54.

[scolebourne]

Is there somewhere else that these issues should be raised?

[roma]

Hi, scolebourne

I believe that knownAmountSchedule must be used only with known amount payments, but not the rate schedule or notional schedule. For rate schedule you can use calculationPeriodAmount/calculation/fixedRateSchedule.

[h_mcallister]

Hi roma, scolebourne,

I suspect that ird-54 is redundant: knownAmountSchedule is used by convention to specify the single bullet payment at term on a zero coupon fixed leg – this is the only use case for the structure. The scenario considered by scolebourne (validation on the content of stubCalculationPeriodAmount) does not apply in this context, by definition.

Best regards,
Harry

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

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

[h_mcallister]

Hi, I’d be interested to understand how you interpret the components of the knownAmountSchedule …

Presumably the values within the schedule are interpreted as payment amounts exchanged between the payer- and receiver- parties in the containing swapStream. In that case, the stepDates of the schedule would correspond to the (unadjusted) payment dates implied by paymentDates.

However the initialValue of the schedule does not have an associated date. In other contexts (e.g. notionalStepSchedule), the initialValue is assumed to apply as at the effectiveDate. However in a conventional vanilla swap with payment in arrears, the first payment date falls on the first period end date. Is this date assumed for the initialValue when processing the knownAmountSchedule (then the first step/stepDate would correspond to the second payment date)?

Please confirm if my understanding is correct ..

Best regards,
Harry

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

[h_mcallister]

Hi,

Thanks for your very clear explanation. Interpreting the schedule as setting the amount for each period is consistent with the behaviour of schedules for other properties of the InterestRateStream, and also works in the case of the zero coupon fixed leg (represented as a single period spanning the term between effective- and termination- dates).

I agree that knownAmountSchedule/stepDates should be constrained to the (unadjusted) period dates corresponding to the boundaries of payment periods, as implied by the paymentDates block.

If there is a problem with knownAmountSchedule, it is that the expected usage not clearly documented, either in schema annotations or (at all) in the online documentation – we should fix this. We don’t see knownAmountSchedule used in the public domain (industry utilities, service providers etc.) for cases other than the zero coupon bullet payment – however that does not preclude other usages e.g. for internal processing with firms.

Best regards,
Harry

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

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

[h_mcallister]

This looks good – though I think references in the text to “notionalAmountSchedule” should (of course) read “knownAmountSchedule” (?)

Thanks,
Harry

[scolebourne]

Yes, my mistake!

[Author]

Posts