5.1 Interest Rate Swap
In Transparency view, a swap component contains two instances of the swapStream component. A swapStream contains the elements required to define an individual swap leg.
|
|
Within an FpML swap there is no concept of a swap header. Details of payment flows are defined within swapStreams which each contain their own independent parameters.
FpML Transparency view supports a parametric representation of a swap.
The following elements and their sub-elements within the calculationPeriodAmount element:
- floatingRateIndex
- indexTenor
- dayCountFraction
The following elements and their sub-elements within the stubCalculationPeriodAmount element:
- floatingRateIndex
- indexTenor.
In general, an interest rate swap will be a swap with a fixed leg and a floating leg, two floating legs, or two fixed legs.
The structure of a swapStream is shown diagrammatically below:
|
|
The components within a swapStream cannot be randomly combined and cannot be thought of as existing in their own right; they only make sense in the given context and in relationship to other components within the swapStream container.
The paymentDates and resetDates components contain the payment and reset frequency.
FpML uses the ISDA Floating Rate Option to specify the floating rate being observed. This scheme was used rather than attempting to parameterize into elements because although most floating rate indices are defined fully by a standard set of parameters (namely index, currency and fixing source) there are sometimes other details including fixing offsets and formulas. This approach allows for more flexibility in adding new floating rate indices without having to introduce new elements, although this comes at the expense of a self contained definition within the standard.
The information relating to amounts and rates is collected in the calculationPeriodAmount.
Certain swapStream components are designated as being optional (although it would be more accurate to say that they are conditional). Thus a fixed rate stream never includes a resetDates component, but this is required for a floating rate stream. The principalExchanges component is required in the case of cross currency swaps or other types of swap involving exchanges of principal amounts.
The detailed structures within the swapStream are shown diagrammatically below:
|
|
|
|
|
|
As noted above, the definition of a forward rate agreement trade is contained within a single component. A forward rate agreement is a simple and commoditized product. This means there is no variation in the product traded and it is not expected to become more complex in the future.
The structure of the fra component is shown diagrammatically below:
|
|
FpML also supports interest rate options. The supported components are:
- Early Termination Provision (Optional or Mandatory) for a swap
- Cancelable Provision for a swap
- Extendible Provision for a swap
- Swaption
- Cap / Floor
The ISDA 2000 Definitions have been followed closely in defining the various option dates and element names. Thus components for European, Bermuda and American exercise have been defined which are re-used in each of the first four components above. These components share an element called relevantUnderlyingDate whose meaning is dependent on the option component it is contained in:
- OptionalEarlyTermination - It represents the new terminationDate of the underlying swapStreams if the trade is terminated early.
- CancelableProvision - It represents the new terminationDate of the underlying swapStreams if the trade is cancelled.
- ExtendibleProvision - It represents the new terminationDate of the underlying swapStreams if the trade is extended.
- Swaption - It represents the effectiveDate of the underlying swapStreams if the swaption is exercised.
This is a style of option to which the right or rights granted are exercisable on a single date referred to as the expiration date. This date can be specified either as an adjustableDate or as a relativeDate though the latter is only expected to be used in the case of cash settled cancellations where the expiration date may be defined as an offset to the cash settlement payment date.
The relevantUnderlyingDate is optional, in its absence the effectiveDate of the underlying is the effectiveDate defined in the swapStreams. This can only be excluded for european swaptions.
|
|
This is a style of option to which the right or rights granted are exercisable during the exercise period which consists of a period of days. The underlying should specify its effective date based on the earliest possible exercise. When exercise implies a stub period this will be taken to be a short stub at the start, i.e. the underlying swap defines a series of flows, exercise merely brings the flows into existence from the relevantUnderlyingDate.
|
|
This is a style of option to which the right or rights granted are exercisable during an exercise period which consists of a number of specified dates. These dates can be defined as a list together with adjustments or by reference to an existing schedule elsewhere in the trade (e.g. resetDates). In the latter case bounds can be placed on the referenced schedule to define a subset of the whole schedule.
|
|
With a cancelableProvision the seller grants the buyer the right to terminate all swapStreams, typically in exchange for an upfront premium. Unlike optionalEarlyTermination, the cancellation of the swap does not require the parties to exchange a cash settlement amount on exercise representing the fair value of the remaining life of the swap although an exercise fee can be specified in the exerciseFeeSchedule.
|
|
With an extendibleProvision the seller grants the buyer the right to extend all swapStreams, typically in exchange for an upfront premium. This provision is very similar to a cancelableProvision and in fact the two share the same market risk profile. FpML makes a clear distinction between the two since the operational risk associated with misrecording the type of applicable provision can be high. For example, a 10 year swap with the right to cancel after 5 years has exactly the same risk profile as a 5 year swap with the right to extend for 5 years after 5 years. However, failing to give notice of exercise after 5 years will in one case (extendibleProvision) result in the swap terminating after 5 years and in the other case (cancelableProvision) result in the swap terminating after 10 years, i.e. action after 5 years is required in one case to lengthen the term of the swap in the other to shorten it.
|
|
The option to enter into a swap is defined as its own product and contains the underlying swap as a swap element. A swaption straddle is defined by setting the swaptionStraddle element to true: this implies that the swaption buyer has the right, on exercise, to decide whether to pay or receive fixed on the underlying swap. If the underlying does not contain a single fixed stream and a single floating stream then the straddle is invalid and thus this flag should be set to false..
|
|
Caps and Floors are defined as one or more capFloorStreams and zero or more additionalPayments. The capFloorStream re-uses the InterestRateStream entity and thus its content is identical to a swapStream.
|
|
Though a capFloorStream allows the definition of fixed streams or known amount streams these are not the intended use of this component and there use would be considered an invalid FpML trade.
The floatingRateCalculation component has been amended to allow the specification of cap/floor structures within a single stream (e.g. straddles, corridors). The changes are:
- The occurrence rules for the components capRateSchedule and floorRateSchedule have been changed from 'zero or one' to 'zero or more'.
- An optional buyer and seller reference have been added to these schedules
These additions allow for multiple cap and floor rates to be added to the stream and to define precisely which party bought and sold them. To maintain backward compatibility with FpML1.0 the buyer and seller are optional. When absent the following rules apply:
- CapRateSchedule: BUYER = Stream payer SELLER = Stream receiver
- floorRateSchedule: BUYER = Stream receiver SELLER = Stream payer