5.1.1 Relative Swap

The pricing and valuation working group required product definitions in order to support:

• Pricing requests
• Curve definitions

To support the above the Pricing and Risk Working Group required a Relative Swap – ie a swap where the dates are specified as periods relative to some other date. Eg – effective date is spot and the termination date is 5y after the effective date.

The working group considered including a separate product and extending the existing product. The group decided that many of the features of a relative swap could be very useful within the normal swap definition. Also, providing a separate product would add ambiguity in the standard allowing two ways to represent some products. As such is was decided to extend the existing InterestRateStream to include relative swap features.

To fully define any swap using relative dates then all places where a date is specified in the standard would need to be replaced by a relative date type. The group considered this but agreed that the initial proposal should limit the work to extending the calculation period dates to cover relative dates. This would cover the requirements of the Pricing and Valuation WG since it allows the definition of relatively simple swaps as relative. If a requirement arises to define more complex swaps (eg compounding with payment stubs) then the standard can be extended at that point.

An optional stubPeriodType element was added to allow the definition of how any irregular period should be handled. This element can be present along with the explicit dates but if this is the case there is a rule that the dates generated using the stubPeriodType should be consistent with the dates present within calculationPeriodDates.

5.1.2 Non-Deliverable Settlement Provision

The Interest Rate Stream component captures the necessary information to represent the non-deliverable terms of an interest rate swap.

These non-deliverable terms specify the conditions under which the cashflows will be made in a different currency (the “settlement currency”) than the currency in which a given leg is denominated (the “reference currency”).

The InterestRateStream type contains an optional settlementProvision component.

This structure supports both "Euro trades" (where settlement currency needs to be specified) and the non-deliverable settlement provision.

Five elements are required to characterize the non-deliverable settlement terms:

• The settlement currency;
• The reference currency;
• An indication/pointer to the reference currency of the swap as well as to the payments that need to be made in that specific currency;
• The determination of the date on which this FX rate will be specified (typically, in reference to the payment date);
• The specification of how this FX rate will be determined.

Here is how each of these requirements is addressed through this structure:

• The settlement currency is specified through the settlementCurrency element;
• The reference currency is specified through the referenceCurrency element (this approach has been considered as more straightforward than specifying it through an href into the calculatedAmount node);
• The indication of the payments that will be made in that settlement currency is done through the datesRelativeToPaymentDates element, which provides the ability to point to multiple payment nodes in the document through the unbounded paymentDatesReference. The example below illustrates how it works in the case of a swap leg that has resets as well as a principal exchange:

The regular payments of the swap get assigned an Id:

<paymentDates id="PaymentDatesID">
	<calculationPeriodDatesReference href="E2000098N10184"/>
	<paymentFrequency>
		<periodMultiplier>6</periodMultiplier>
		<period>M</period>
	</paymentFrequency>
	<firstPaymentDate>2005-06-16</firstPaymentDate>
	<payRelativeTo>CalculationPeriodEndDate</payRelativeTo>
	<paymentDatesAdjustments>
		<businessDayConvention>MODFOLLOWING</businessDayConvention>
		<businessCenters>
			<businessCenter businessCenterScheme=
"http://www.fpml.org/coding-scheme/business-center-2-0">USNY</businessCenter>
			<businessCenter businessCenterScheme=
"http://www.fpml.org/coding-scheme/business-center-2-0">GBLO</businessCenter>
		</businessCenters>
	</paymentDatesAdjustments>
</paymentDates>
        			

The principalExchanges node of the swap also gets assigned an Id:

<principalExchanges id="PrincipalExchanges">
	<initialExchange>false</initialExchange>
	<finalExchange>true</finalExchange>
	<intermediateExchange>false</intermediateExchange>
</principalExchanges>
        			

The dateRelativeToPaymentDates refers to each of those payments that need to be settled in the settlement currency of the swap:

<dateRelativeToPaymentDates>
	<paymentDatesReference href="PaymentDatesID"/>
	<paymentDatesReference href="PrincipalExchanges"/>
</dateRelativeToPaymentDates>
        			

• The determination of the date on which the FX rate will be specified is done through the FxFixingDate component, which uses the same structure than the RelativeDatOffset component, the only difference being that the relativeDateTo pointer is replaced by the dateRelativeToPaymentDates element, which has been described above.
• The specification of how the FX rate is determined is done through the Settlement Rate Option scheme. This scheme is specified as part of the ISDA 1998 FX and currency options definitions, and is effectively used in both the FX and Interest Rate markets to specify how a currency rate will be determined.

5.2 Asset Swap

5.2.1 Implementation

The representation of Asset Swaps reuses the Swap type adding an optional reference to a Bond underlyer.

5.2.2 Design Rationale

• All information required for supporting asset swaps existed in the Swap structure. Since within asset swaps there isn’t always a bond reference, a separate AssetSwap type would copy the existing Swap model without adding any value.
• Instead of referencing the generic underlying asset component, the group felt that narrowing the scope to bond (and maybe convertible bond in the future) would provide a more accurate definition. The existing underlying asset is too broad for this purpose, allowing coverage of cash and ETF that do not seem appropriate for this structure.
• The group agreed to make bondReference element optional within additionalTerms for extensibility purpose. Group envisioned that internal xml vocabularies would extend the additionaTerms element. Making bondReference required would be a problem for extensions.
• The group agreed that asset swap and Condition Precedent Bond are two different things. Condition Precedent Bond ties to the legal condition regarding the placement of the bond. The agreement was to support both within the existing Swap structure.
• The group agreed that the Condition Precedent Bond flag shouldn’t be placed in the Bond type since this element would be used in a very specific case. Placing the element within the Bond would overload the type.

5.3 Inflation Swap

5.3.1 Design Approach

A Floating Rate such as USD-LIBOR is observed daily as a percentage interest rate value and does not require any further calculation. In contrast, an Inflation Rate for a calculation period is usually determined as follows:

• Inflation Rate = (Index Final/Index Initial – 1) * 100%; where
• Index Initial is the published index level at the beginning of the period.
• Index Final is the published index level at the end of the period.
• Note: The index levels are usually taken for a Reference Month which is N months before the fixing date. This is known as the Inflation Lag. [ See below on Reference Month calculation ]

Apart from the above difference other features of inflation swaps are very much in line with the interest rate swaps. They have a concept of two cash flow streams, generally a fixed stream and an inflation stream. Both streams generate cash flows based on a function of the interest rate, notional and day count fraction for each calculation period. For this reason, the design approach focused on merging the functionality with the IRD schema instead of developing a new product.

Two options were considered in order to merge the Inflation Swaps into the IRD Schema. The first option was to extend the Floating Rate Leg to include Inflation specific elements. The second approach was to introduce a substitution group at the Floating Rate Leg level. Here are some of the advantages of using the substitution group instead of extending the schema.

• It does not weaken and add complexity to the existing floating rate definition through the addition of a number of optional elements.
• It allows the choice of the content of an FpML document to be determined at the time when the document is created.
• It is future proof by allowing the addition of new features to the Inflation or Floating rate elements without impacting each other (note: it also allows common features to be enhanced).
• It is entirely backward compatible. The Floating Rate Leg remains exactly the same as it is in the current version of the FpML.
• It adds no overhead to the existing schema.

5.3.2 Implementation

The InflationRateCalculation type is created by extension of the existing FloatingRateCalculation type, then addition of Inflation specific elements such as the Inflation Lag.

In order to implement the Substitution Group an abstract element rateCalcuation has been added to the schema. The rateCalcuation element can be substituted by the floatingRateCalculation element for standard Floating Rate legs, or the inflationRateCalculation element.

Any product that uses an InterestRateStream can elect to use this type by making use of the substitution group.

5.4 Forward Rate Agreement

5.5 Option Components

5.5.1 European Exercise

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.

5.5.2 American Exercise

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.

5.5.3 Bermuda Exercise

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.

5.5.4 Early Termination Provision

The right for one or both parties to terminate the trade and settle the remaining term of the swap for fair value. In the case of a mandatory early termination the termination is mandatory.

The Broker Working Group defined the requirement to be able to define early termination dates in a parametric form: “ At X years and every Y years thereafter “. The current FpML Specification quotes the actual unadjusted dates.

For example, FpML early termination dates: 10-Nov-2008, 10-Nov-2009, 10-Nov-2010, 10-Nov-2011. Assuming trade date was 10-Nov-2004 we would want “At 4 years and every year thereafter”.

The mandatoryEarlyTerminationDateTenor and optionalEarlyTerminationParameters elements allow specification of the mandatory early termination date in terms of a tenor, e.g. 5 years, or for optional early termination (mutual puts) the specification of the earliest termination date in terms of a tenor and a subsequent exercise frequency (in the case of Bermudan or American style early termination). American style exercise would be indicated by stating an exercise frequency of 1 day. European style exercise would omit the exercise frequency altogether.

5.5.5 Cancelable Provision

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.

5.5.6 Extendible Provision

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.

5.5.7 Swaption

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

5.5.8 Cap / Floor

Caps and Floors are defined as one or more capFloorStreams and zero or more additionalPayments. The capFloorStream re-uses the FpML_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

5.6 Cash Settlement