## 5 INTEREST RATE DERIVATIVE PRODUCT ARCHITECTURE

### 5.1 Interest Rate Swap

A swap component contains one or more instances of the swapStream component, zero or more instances of the additionalPayment component together with an optional cancelableProvision component,an optional extendibleProvision component and an optional earlyTerminationProvision 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. There can also be additionalPayment elements that contain fees. The additionalPayment component is identical to the otherPartyPayment component shown above.

FpML also supports option related features. These include cancelable, extendible swaps and early termination provisions. Combining these together with swaptions into a single component was considered but rejected in favor of identifying the different option types with their own components. This provided more clarity and allowed for easier combination of the different options into a single trade. As such a swap can contain a cancelableProvision, extendibleProvision and an earlyTerminationProvision. All these components are very similar (and similar to the swaption component), re-use is achieved by using shared entities within each of the components.

FpML supports two representations of a swap stream; a parametric representation, and a cashflows representation. The parametric representation is designed to capture all the economic information required regarding dates, amounts and rates to allow trade execution and confirmation. The parametric representation is mandatory. The cashflows representation specifies an optional additional description of the same stream. The main purpose of this is to allow the inclusion of adjusted dates within an FpML representation of a trade. It can also be used to represent adhoc trades not achievable by easy manipulation of the parameters of a stream (i.e. by changing the adjusted dates). This would lead to the cashflows not matching those generated by the parameters (see more discussion later) and would also render the representation of the trade unsuitable for a confirmation. The spirit of FpML is that such manipulation of cashflows would be achieved by splitting a single stream into a number of streams though it is recognized that this may be impractical in some systems.

The cashflows representation is not self contained as it relies on certain information contained within the stream's parametric definition. The elements required from the parametric definition to complete the cashflows representation are:

The following elements and their sub-elements within the calculationPeriodAmount element:

- floatingRateIndex
- indexTenor
- rateTreatment
- finalRateRounding
- averagingMethod
- negativeInterestRateTreatment
- dayCountFraction
- discounting
- compoundingMethod.

The following elements and their sub-elements within the stubCalculationPeriodAmount element:

- floatingRateIndex
- indexTenor.

The inclusion of the cashflows representation is intended to support Application integration. For example, a financial institution may have one application that captures trade parameters and constructs the trade schedules and then publishes the result for use by other applications. In this case it may be either undesirable, or impossible, for each of the subscribing applications to store and calculate schedules.

The flexibility of the cashflows representation also allows payment and calculation schedules which can not be fully represented by the parametric description. If this situation arises, the mandatory parametric data should still be included in the document and the flag cashflowsMatchParameters should contain the value false to indicate that it is not possible to generate the cashflows from this parametric data. The setting of this flag to true means that the cashflows can be regenerated at any time without loss of information.

Parties wishing to take advantage of the facility for specifying cashflows which are inconsistent with the parametric representation will need to specify additional rules for how the parametric representation should be processed. This applies to both the creation of the parametric data as well as its interpretation.

The cashflows representation specifies adjusted dates, that is, dates that have already been adjusted for the relevant business day convention using the relevant set of business day calendars (lists of valid business days for each business center). The FpML standard does not specify the source of these business day calendars. This may lead applications to generate differing cashflow representations from the same parametric representation if they use different business day calendars. The use of adjusted dates also produces schedules that are only valid at a particular instance of time. Additional holidays for a business center may subsequently be introduced that would result in changes to the adjusted dates, which would not be reflected in the cashflows representation.

Analogous to cashflows being used to represent adjusted dates, with the addition of options it was important to be able to represented the adjusted dates associated with an option. Thus, where appropriate, a component includes an optional element to represent a schedule of adjusted dates for the option. Such a schedule would include details of adjusted dates such as adjusted exercise dates and cash settlement dates.

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. However, certain types of trades may contain more than two legs. FpML does not restrict the number of legs that may be defined. From a modeling perspective, FpML does not distinguish between a swap leg referencing a fixed rate and a swap leg referencing a floating rate, the difference being indicated by the existence, for example, of the resetDates component in a floating rate leg.

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.

In FpML, the schedule of dates within a swapStream is based around the calculationPeriodDates component. The definition of a calculation period in FpML differs in some respects from the International Swaps and Derivatives Association (ISDA) definition of Calculation Period. In the case of a trade involving compounding, ISDA introduces the concept of a Compounding Period, with several Compounding Periods contributing to a single Calculation Period. The FpML calculation period is equivalent to the ISDA definition of Compounding Period when compounding is applicable, i.e. the calculation period frequency will correspond to the compounding frequency. An FpML calculation period is directly comparable to the ISDA defined Calculation Period when only one calculation period contributes to a payment.

The other date components within swapStream are related to the calculationPeriodDates component. The paymentDates and resetDates components contain the information necessary to construct a schedule of payment and reset dates relative to the calculation period dates.

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 and stubCalculationPeriodAmount components. fxLinkedNotionalSchedule is an alternative to notionalSchedule for defining notionals. This allows for the definition of FX Resetable trades by allowing for the notional of a stream to be linked to notionals from another stream by way of the spot fx rate.

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. Similarly, the stubCalculationPeriodAmount component will be required if the swap leg has either an initial or final stub, or indeed both, but should otherwise not be specified. The principalExchanges component is required in the case of cross currency swaps or other types of swap involving exchanges of principal amounts.

The payerPartyReference and receiverPartyReference elements indicate which party is paying and which receiving the stream payments. This is done by referencing the appropriate party within the party component.

The detailed structures within the swapStream are shown diagrammatically below:

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

The priceSourceDisruption element defines the parameters used to get a price quote to replace the settlement rate option that is disrupted.

### 5.2 Asset Swap

Asset Swaps can be represented in FpML since version 4.2 Second Working Draft. An Asset Swap is a swap agreement where one leg mimics the return of the underlying asset. No transfer of asset takes place. Sometimes the sale of the bond is included in the asset swap construct.

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

The support of Inflation Swaps is based on the extension of the IRD product schema through the use of a Substitution Group.

The representation focuses on the Floating Rate Calculation, which is the key component that differentiates an Inflation based product from other Interest Rate Products.

#### 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.3.2.1 Inflation Terms

There are two main types of Inflation Products that are commonly traded, the Zero Coupon Inflation Swaps and the Year On Year Inflation Swaps. The following elements extended the FloatingRateCalculation in order to support the correct representation of these products.

- inflationLag
- indexSource
- mainPublication
- interpolationMethod
- initialIndexLevel
- fallbackBondApplicable

Here is how the above structure addresses each of the following requirements:

- Inflation Index Name – element floatingRateIndex will be used to store the name of the Inflation Index itself.
- Index Source - indexSource element stores the main source of the inflation index such as Reuters or Bloomberg screens.
- Main Publication - mainPublication element represents the current main publication source of the inflation such as relevant web site or an official government or non-governmental organisation.
- Inflation Tenor, Day Count Fraction and Payment Frequency - elements of the InterestRateStream are reused to represent the inflation specific tenor, day count fraction (usually 1/1) and payment frequency.
- Inflation Lag - inflationLag element supports the period is used to determine the Reference Month(s) for fixing each Index Level.
- Fallback Bond Applicable - The applicability of a fallback bond as defined in the 2006 ISDA Inflation Derivatives Definitions, sections 1.3 and 1.8. Omission of this element imples a value of true.

- Reference Month for Initial/Final Index of each calculation period.
  - The Reference Month is usually calculated by offsetting the Index Level Fixing Date with the Inflation Lag. Example: Assuming Inflation Lag = 3M and Reset Date = 20-Apr-05, Reference Month = Apr-3M = January; Therefore, the index level used for the Fixing date of 20-Apr-05 will be the Inflation Index Level of January 2005.
- Initial Index Level – Unlike other interest rate products, the initial index of the first calculation period (even for non forward starting inflation swaps) is generally known at the time of entering the trade. This optional field will be used to store the initial value if it is known.
- Interpolation – there are several fields required to describe Inflation Interpolations.
  - Interpolation Method - The most common (and so far the only option) is Linear interpolation. The presence of this element indicates that the Inflation Index Level should be calculated from two different Index Levels and the resulting Inflation Index Level will be based on the weighting of each level.
  - Reference Month - for each point to be used for Interpolation is usually calculated as follows: Reference Month (point 2) = Month( Fixing Date ) – Inflation Lag; Reference Month (point 1) = Reference Month (point 1) – 1M
  - Weighting to be associated with each interpolation point’s Index Level. It determined by the Roll Day for each Fixing Date. For example, the Linear Interpolation between the inflation for the Reference Month of March (a) and April (b) as follows. Interpolated Index Level = (1-N/D).a + (N/D).b; where N = day part of the Fixing Date (i.e. 29) and D = number of days in the payment month (Juen)
- Formula to be used for Zero Coupon Inflation Leg. The same ComplexType used for Equity Swaps has been re-used for this.

- RelatedBond – If the Inflation Index can not be determined or has not been published continuously, an equivalent index level is obtained from an agreed related Bond. In order to support this the additionalTerms element is used to reference the bond.

### 5.4 Forward Rate Agreement

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:

### 5.5 Option Components

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.

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

The cash settlement component is used by mandatoryEarlyTermination, optionEarlyTermination and swaption. The language used within the component corresponds to the ISDA language for the various cash settlement methods. Of the five methods included, three share one underlying component and the other two share another component. Thus there is re-use whilst maintaining ease of identification of the type. Also, this approach allows for easy integration of other methods should they arise.

Previous | Top | Next
--- | --- | ---