FpML Issues Tracker

Robert,

Your issue raised with FpML re: stub date representation was discussed at today’s meeting of the FpML Coordination committee.

In fact, the committee members present were unable to recall the precise rationale for the introduction of StubCalculationPeriodAmount.stub[Start|End]Date, but the consensus was that these were created to support use of the InterestRateStream within the Equity Derivative sphere, and that these elements are not expected to be produced in the representation of Interest Rate products. The committee resolved to make further enquiries, and to update the relevant documentation once the matter is fully resolved.

To recap our conversation of last week, the presence of a stub on an IRS swapStream may be inferred from the existence of firstRegularPeriodStartDate / lastRegularPeriodEndDate, with the other stub dates determined from effectiveDate & terminationDate, depending on stub position. The exception would be in the case where interest on a short, start stub period is to be accrued as if for a regular period (i.e. full first period on an asset swap). In this case the start date of the accrual period precedes the effectiveDate, and this date is produced in firstPeriodStartDate (= firstRegularPeriodStartDate – 1 * calculationPeriodFrequency).

Finally, stubCalculationPeriodAmount is produced if, and only if, the stub references a different rate to the regular periods (e.g. a different fixed rate, different floating rate tenor or interpolated rate).

I hope this assists you with your implementation – please do get back to me if you need any further clarification.

Best regards,
Harry

Created a new StubValue type containing the choice between floatingRate, stubRate, and stubAmount that was part of the Stub type.

Stub type extends now StubValue by adding the start and end dates.

swapstream.stubCalculationPeriodAmount.initalStub and swapstream.stubCalculationPeriodAmount.finalStub are of type StubValue instead of Stub