PaymentDates
Type CDM 7.2.0Specifies the parameters to generate the payment date schedule, either through a parametric representation or by reference to specified dates.
Extends —
Extended by —
Attributes 7
Namespace cdm.product.common.schedule
Attributes
All 7 declared on PaymentDates. Cardinality in amber is required.
| Name | Type | Card. | Description |
|---|---|---|---|
| paymentFrequency | Frequency | 0..1 | The frequency at which regular payment dates occur. If the payment frequency is equal to the frequency defined in the calculation period dates component then one calculation period contributes to each payment amount. If the payment frequency is less frequent than the frequency defined in the calculation period dates component then more than one calculation period will contribute to the payment amount. A payment frequency more frequent than the calculation period frequency or one that is not a multiple of the calculation period frequency is invalid. If the payment frequency is of value T (term), the period is defined by the effectiveDate and the terminationDate. |
| firstPaymentDate | date | 0..1 | The first unadjusted payment date. This day may be subject to adjustment in accordance with any business day convention specified in paymentDatesAdjustments. This element must only be included if there is an initial stub. This date will normally correspond to an unadjusted calculation period start or end date. This is true even if early or delayed payment is specified to be applicable since the actual first payment date will be the specified number of days before or after the applicable adjusted calculation period start or end date with the resulting payment date then being adjusted in accordance with any business day convention specified in paymentDatesAdjustments. |
| lastRegularPaymentDate | date | 0..1 | The last regular payment date when specified as a date, as in the FpML interest rate construct. FpML specifies that this date may be subject to adjustment in accordance with any business day convention specified in the paymentDatesAdjustments attribute. |
| paymentDateSchedule | PaymentDateSchedule | 0..1 | The payment dates when specified as relative to a set of dates specified somewhere else in the instance document/transaction, e.g. the valuation dates as typically the case for equity swaps, or when specified as a calculation period schedule. |
| payRelativeTo | PayRelativeToEnum | 0..1 | Specifies whether the payments occur relative to each adjusted calculation period start date or end date, each reset date, valuation date or the last pricing date. Calculation period start date means relative to the start of the first calculation period contributing to a given payment. Similarly, calculation period end date means the end of the last calculation period contributing to a given payment. The valuation date is applicable for Brazilian-CDI and equity swaps. |
| paymentDaysOffset | Offset | 0..1 | If early payment or delayed payment is required, specifies the number of days offset that the payment occurs relative to what would otherwise be the unadjusted payment date. The offset can be specified in terms of either calendar or business days. Even in the case of a calendar days offset, the resulting payment date, adjusted for the specified calendar days offset, will still be adjusted in accordance with the specified payment dates adjustments. This element should only be included if early or delayed payment is applicable, i.e. if the periodMultiplier element value is not equal to zero. An early payment would be indicated by a negative periodMultiplier element value and a delayed payment (or payment lag) would be indicated by a positive periodMultiplier element value. |
| paymentDatesAdjustments | BusinessDayAdjustments | 0..1 | The definition of the business day convention and financial business centers used for adjusting the payment date if it would otherwise fall on a day that is not a business day in the specified business center. |
Conditions
Validation rules the model enforces on this type, in Rune. An instance that breaks one of these is invalid CDM, whatever produced it.
FpML_ird_35_cd_31 Condition
FpML validation rule ird-35 & cd-31- If firstPaymentDate exists, and if lastRegularPaymentDate exists, then firstPaymentDate must be before lastRegularPaymentDate.
if firstPaymentDate exists and lastRegularPaymentDate exists
then firstPaymentDate < lastRegularPaymentDate NonZeroPeriodMultiplier Condition
FpML specifies that paymentDaysOffset should only be included if early or delayed payment is applicable, i.e. if the periodMultiplier element value is not equal to zero.
if paymentDaysOffset exists
then paymentDaysOffset -> periodMultiplier <> 0Referenced by
6 types hold a PaymentDates as an attribute.
CommodityPayoutDateRelativeToPaymentDatesEquitySwapMasterConfirmation2018FixedPricePayoutInterestRatePayoutPerformancePayout
Functions
Model functions that produce or consume this type. These are the CDM's own behaviour — the logic a correct implementation has to match.
| Function | Role | Description |
|---|---|---|
| MapPaymentDatesReference | returns | — |
| MapPeriodicPaymentToPaymentDates | returns | — |
| MapCommodityRelativePaymentDates | returns | — |
| MapCommoditySwapNonPeriodicPaymentDates | returns | — |
| MapInterestLegPaymentDates | returns | — |
| MapSwapPaymentDates | returns | — |
Open PaymentDates in the Model Browser
Walk the tree and the reference graph interactively, and switch releases to see how the type has changed. Free, no signup.