FpML 4.2 Trial Recommendation

6 CREDIT DERIVATIVE PRODUCT ARCHITECTURE

6.1 Introduction

This section provides an in-depth review of the product architecture of FpML 4.2 Credit Derivatives. The two products covered by FpML 4.2 Credit Derivatives are the single name credit default swap and the credit default swap index.

6.1.1 credit default swap

In order to define the scope of the credit default swap work FpML adopted the definition used in the ISDA Year End 2001 Flash Survey:

"In a credit default swap one counterparty (the protection seller) agrees to compensate another counterparty (the protection buyer) if a specified company or Sovereign (the reference entity) experiences a credit event, indicating it is or may be unable to service its debts. The protection seller is paid a fee and/or premium, expressed as an annualized percent of the notional in basis points, regularly over the life of the transaction."

The FpML 4.2 Credit Derivatives Product Architecture draws heavily on the 2003 ISDA Credit Derivatives Definitions (hereafter referred to as the "2003 Definitions"). Wherever feasible the terminology and practice of the ISDA definitions has been adopted to ensure consistency between traditional and FpML contract representations. Appendix A lists the elements in FpML 4.2 Credit Derivatives that differ in name from their corresponding terms in the 2003 Definitions. In FpML 4.2 it is possible to represent credit default swap trades done under either the 1999 or the 2003 definitions.

The FpML 4.2 Credit Derivatives Subschema supports both a full confirmation and a transaction supplement (i.e. economics of the trade) representation of the credit default swap. The transaction supplement representation is a subset of the elements contained in the full confirmation representation. This flexible approach makes FpML 4.2 Credit Derivatives usable in all stages of the credit default swap trade lifecycle.

6.1.2 credit default swap index

Product support for the credit default swap index was added to FpML in version 4.1. The FpML representation for this product is closely based on the credit default swap work that first appeared in FpML 4.0. In fact, the index trade itself is described using the creditDefaultSwap element. Only a transaction supplement representation of a credit default swap index is supported.

Support for tranches on credit default swap indices was added in version 4.2.

6.1.3 credit default swap basket

Product support for the credit default swap basket was added to FpML in version 4.2. The FpML representation for this product is based on the existing creditDefaultSwap product element and it includes the support for tranches.

6.2 creditDefaultSwap

Like all other derivative products supported by FpML, the type used to represent the credit default swap, the credit default swap index, and the credit default swap basket, CreditDefaultSwap, is defined as an extension of the Product type and the corresponding creditDefaultSwap element belongs to the product substitution group. The creditDefaultSwap element appears in Figure 1.

Figure 1: creditDefaultSwap element

The structure of the creditDefaultSwap element corresponds to the structure of the Confirmation that appears in Exhibit A of the 2003 Definitions (hereafter referred to as the "2003 Confirmation"). The six sections that comprise the 2003 Confirmation and their corresponding FpML elements appear in Figure 2.

2003 Confirmation	FpML creditDefaultSwap Element
General Terms	generalTerms
Fixed Rate Payments	feeLeg
Floating Payment	protectionTerms
Settlement Terms	physicalSettlementTerms or cashSettlementTerms
Notice and Account Details	N/A
Offices	N/A

Figure 2: Sections of the 2003 Confirmation and their corresponding FpML creditDefaultSwap elements.

Additional points to note:

The id attribute and the productType and productId elements are inherited from the product type. They are not credit derivatives specific. Each product supported by FpML contains these elements.
Although Settlement Terms are specified on a full confirmation, they are not necessarily required for a transaction supplement or other activities in the trade lifecycle. Therefore, the equivalent element (physicalSettlementTerms or cashSettlementTerms) is optional in FpML 4.2.
The Notice and Account Details and Offices sections of the confirmation do not have a direct analog in the FpML 4.2 definition of the credit default swap. In FpML, the party elements that appear under the FpML root element serve the purpose these sections do in the traditional confirm.

The remainder of this document reviews each child element of the creditDefaultSwap.

6.3 generalTerms

The generalTerms element, which appears in Figure 3, represents the information specified in the General Terms section of the 2003 Confirmation.

Figure 3: generalTerms Element

The effectiveDate element represents the Effective Date term. In order to optionally allow the explicit specification of a particular business day convention per the 2003 Definitions this element is of type AdjustableDate2. The effectiveDate is optional for the transaction supplement representation of some credit default swap indices.

The scheduledTerminationDate element represents the Scheduled Termination Date term. This element can be specified as either an adjustable date or a relative date. For confirmation purposes a specific date will always be specified. Again, the AdjustableDate2 type allows the parties to explicitly specify a particular business day convention per the 2003 Definitions. The Interval type (e.g. 5 Y for a five year deal) is included because this way of expressing a scheduled termination date is quite commonly used in historical price databases. The scheduled termination date is optional for the transaction supplement representation of some credit default swap indices. The effectiveDate and scheduledTerminationDate should always be included for a credit default swap.

The sellerPartyReference element represents the protection seller. This party is referred to as the Floating Rate Payer in the 2003 Definitions. Similarly, the buyerPartyReference element represents the protection buyer and is referred to as the Fixed Rate Payer in the 2003 Definitions. These elements reference the party elements underneath the FpML root element.

The optional elements dateAdjustments.businessCenters and dateAdjustments.businessDayConvention are used to represent the terms Business Day and Business Day Convention respectively.

The referenceInformation element is used in the representation of a credit default swap. The indexReferenceInformation element is used in the representation of a credit default swap index. The basketReferenceInformation element is used in the representation of a credit default swap basket.

The full expansion of the referenceInformation element appears in figure 4. Two of its child elements, referenceEntity and referenceObligation, are used to represent the Reference Entity and Reference Obligation(s) terms respectively.

The referenceEntity element is of type LegalEntity and is required. The LegalEntity type requires an entityName and/or an entityId to be provided. Both the entityName and the entityId are represented using schemes, which allow the source (e.g. reference database) of the information to be recorded.

A referenceObligation element has either a bond or a convertibleBond as one of its child elements. The bond and convertibleBond elements are shared FpML elements. In other words, they were not created specifically to support credit derivatives and are also used in other asset classes. For a credit default swap one of these elements is used to specify a Reference Obligation's CUSIP/ISIN, Maturity andCoupon values. The instrumentId element is used to specify CUSIP/ISIN. The mandatory instrumentIdScheme is used to specify whether the id provided is a CUSIP or an ISIN. Since multiple occurrences of instrumentId are allowed, the schema supports the specification of both the obligation's CUSIP and ISIN, if they both exist. The couponRate and maturity elements are used to represent the Couponand Maturity terms respectively.

To represent the Primary Obligor term a referenceObligation element may optionally have either a primaryObligor or a primaryObligationReference element. If the Primary Obligor is the Reference Entity, then primaryObligorReference should be used. Its href attribute will contain the id attribute of the referenceEntity. Otherwise, the primaryObligor element, which is of type LegalEntity, should be used.

Similarly, to represent the Guarantor term a referenceObligation element may optionally have either a guarantor or a primaryObligationReference element. If the Guarantor is the Reference Entity, then guarantorReference should be used. Its href attribute will contain the id attribute of the referenceEntity. Otherwise, the guarantor element, which is of type LegalEntity, should be used.

The optional allGuarantees and referencePrice are used to represent the terms All Guarantees and Reference Price respectively.

Several terms that appear in the General Terms section of the 2003 Confirmation do not appear in the generalTerms element because elements to represent these terms already existed in the FpML trade element. The terms that belong to this category appear in Figure 6 along with their corresponding FpML element.

ISDA Confirmation Term	FpML Element
Trade Date	trade.tradeHeader.tradeDate
Calculation Agent	trade.calculationAgent.calculationAgentPartyReference
Calculation Agent City	trade.calculationAgentBusinessCenter

Figure 6 General Terms that do not appear in creditDefaultSwap.generalTerms element.

6.3.1 referenceInformation

Figure 4: referenceInformation element

Although the structure of referenceInformation appears to be somewhat complex, the specification of Reference Entity and Reference Obligation information in FpML documents is quite simple, straightforward and flexible. An example bears this out:

Reference Entity: Bundesrepublic Deutschland
Primary Obligor: Reference Entity
Guarantor: None
Coupon Rate: 5%
Date Maturity: 2012-7-4
ISIN/Cusip: DE0001135200
Reference Price: 100%

In order to support the full credit default swap trade lifecycle, the schema allows this information to be expressed in various degrees of detail:

Example 1 - Reference Entity only:

<referenceInformation>
  <referenceEntity>
    <entityName>Bundesrepublic Deutschland</entityName>
  </referenceEntity>
  <noReferenceObligation/>  
</referenceInformation>

Example 2 - Reference Entity and ISIN of the Reference Obligation with optional scheme attributes:

<referenceInformation>
  <referenceEntity>
    <entityName>Bundesrepublic Deutschland</entityName>
    </referenceEntity>
  <referenceObligation>
    <bond>
      <instrumentId instrumentIdScheme =
"http://www.fpml.org/spec/2002/instrument-id-ISIN-1-0">DE0001135200</instrumentId>
    </bond>
  </referenceObligation>
</referenceInformation>

Example 3 - Full Representation of Reference Entity and Reference Obligation terms:

<referenceInformation>
   <referenceEntity id ="DBR">
	<entityName>Bundesrepublic Deutschland</entityName>
  </referenceEntity>
  <referenceObligation>
    <bond>
      <instrumentId 
        instrumentIdScheme =
"http://www.fpml.org/spec/2002/instrument-id-ISIN-1-0">DE0001135200</instrumentId>
      <couponRate>.05</couponRate>
      <maturity>2012-07-04</maturity>
    </bond>
    <primaryObligorReference href =
"DBR"/>
  </referenceObligation>
  <referencePrice>1</referencePrice>
</referenceInformation>

6.3.2 indexReferenceInformation

The indexReferenceInformation element appears in the Figure 5. This element is used to identify the index referenced by a credit default swap index trade.

The indexReferenceInformation element is structurally very similar to the referenceEntity element. The indexReferenceInformation element identifies a collection of (Reference Entity, Reference Obligation) pairs issued by an index sponsor (e.g. iBoxx, TRAC-X). The referenceEntity element, on the other hand, identifies a specific Reference Entity.

Figure 5: indexReferenceInformation element

The identification is accomplished by a combination of the indexId and the indexName elements. There are optional elements to explicitly define the index series number, the version number of the index series annex, the annex publication date and the source of the relevant annex (the elements indexSeries, indexAnnexVersion, indexAnnexDate and indexAnnexSource respectively) (for a given series, multiple versions of the “annex” may be published over time). The indexSeries and indexAnnexVersion elements are of integer type, the indexAnnexDate element is of date type and the indexAnnexSource element is of complex type IndexAnnexSource (which is of base type string).

The indexAnnexSource element corresponds to the field ‘Source of Relevant Annex’ that appears in the Dow Jones CDX form of Transaction Supplement and it is proposed an FpML-defined Scheme is defined with initial possible values of “Publisher” and “Master Confirmation”. These values have the meanings ascribed to them in the Dow Jones CDX General Terms Confirmation (A value of “Publisher” implies the relevant annex for a transaction is the list for the relevant index with the relevant annex date published by Mark-it Partners).

See the Mark-it Partners website (http://www.mark-it.com) for examples of published annexes for the CDX and iTraxx index families.

An additional optional repeating element excludedReferenceEntity is also proposed to support the iTraxx and CDX forms of Transaction Supplement which allow for specific reference entities in the index to be excluded by making reference to them in the Transaction Supplement. This element uses the existing LegalEntity type.

Identifying a credit default swap index with indexReferenceInformation is quite straightforward. Like referenceInformation, it allows for this information to be expressed in various degrees of detail.

Some illustrative example FpML snippets including the optional elements follow:

<generalTerms>
  ...
  <indexReferenceInformation>
    <indexName>Dow Jones CDX.NA.IG.3 Version 1</indexName>
    <indexId indexIdScheme="http://www.fpml.org/spec/2003/instrument-id-RED-pair-1-0">123456789</indexId>
    <indexSeries>3</indexSeries>
    <indexAnnexVersion>1</indexAnnexVersion>
    <indexAnnexDate>2004-09-20</indexAnnexDate>
    <indexAnnexSource>Publisher</indexAnnexSource>
  </indexReferenceInformation>
  ...
</generalTerms>


<generalTerms>
  ...
  <indexReferenceInformation>
    <indexName>Dow Jones iTraxx Europe Series 2 Version 1</indexName>
    <indexId indexIdScheme="http://www.fpml.org/spec/2003/instrument-id-RED-pair-1-0">123456789</indexId>
    <indexSeries>2</indexSeries>
    <indexAnnexVersion>1</indexAnnexVersion>
    <indexAnnexDate>2004-09-17</indexAnnexDate>
    <excludedReferenceEntity>
      <entityName>Acme Inc.</entityName>
      <entityId entityIdScheme="http://www.fpml.org/spec/2003/entity-id-RED-1-0">123456</entityId>
    </excludedReferenceEntity>
  </indexReferenceInformation>
  ...
</generalTerms>

	
<generalTerms>
  ...
  <indexReferenceInformation>
	<indexName>Dow Jones iTraxx Europe Consumers Series 2 Version 1</indexName>
	<indexSeries>2</indexSeries>
	<indexAnnexVersion>1</indexAnnexVersion>
	<tranche>
		<attachmentPoint>0.03</attachmentPoint>
		<exhaustionPoint>0.07</exhaustionPoint>
	</tranche>
	<settledEntityMatrix>
		<matrixSource>NotApplicable</matrixSource>
	</settledEntityMatrix>
  </indexReferenceInformation>
  ...
</generalTerms>

6.3.2.1 Index Tranche

The optional tranche element allows the specification of index tranches. The structure requires an attachment point and an exhaustion point and optionally the applicability of the legal term Incurred Recovery.

The Dow Jones CDX Tranche Transactions Standard Terms Supplement requires the "Source of Relevant Settled Entity Matrix" field on a Confirmation. The optional settledEntityMatrix element supports it. It contains a required matrixSource element and an optional publicationDate element.

6.3.3 basketReferenceInformation

The basketReferenceInformation element appears in the figure below. This element is used to define the composition of the basket by a credit default swap basket.

The identification of the basket using basketId and/or basketName is optional since each component of the basket must be specified using the referencePoolItem element.

The constituentWeight (weight of each component of the basket) is optional since if the element is not present, it means that flat weight is assumed.

Some illustrative example FpML snippets follow:

<generalTerms>
  ...
  <basketReferenceInformation>
   <referencePool>
     <referencePoolItem>
	<referencePair>
		<referenceEntity id="agriumEntity">
			<entityName>Agrium Inc.</entityName>
			<entityId entityIdScheme="http://www.fpml.org/spec/2003/entity-id-RED-1-0">
008HA7</entityId>
		</referenceEntity>
		<referenceObligation>
			<bond>
				<instrumentId instrumentIdScheme="http://www.fpml.org/spec/2002/
instrument-id-CUSIP-1-0">008916AB4</instrumentId>
				<couponRate>0.077</couponRate>
				<maturity>2017-02-01</maturity>
			</bond>
			<primaryObligorReference href="agriumEntity"/>
		</referenceObligation>
		<entityType>NorthAmericanInvestmentGrade</entityType>
	</referencePair>
   </referencePoolItem>
   <referencePoolItem>
	<referencePair>
		<referenceEntity id="tenetEntity">
			<entityName>Tenet Healthcare Corporation</entityName>
			<entityId entityIdScheme="http://www.fpml.org/spec/2003/entity-id-RED-1-0">
8G836J</entityId>
		</referenceEntity>
		<referenceObligation>
			<bond>
				<instrumentId instrumentIdScheme="http://www.fpml.org/spec/2002/
instrument-id-CUSIP-1-0">88033GAT7</instrumentId>
				<couponRate>0.06</couponRate>
				<maturity>2011-12-01</maturity>
			</bond>
			<primaryObligorReference href="tenetEntity"/>
		</referenceObligation>
		<entityType>NorthAmericanInvestmentGrade</entityType>
	</referencePair>
     </referencePoolItem>
   </referencePool>
   <nthToDefault>1</nthToDefault>
  </basketReferenceInformation>
  ...
</generalTerms>

6.3.3.1 Basket Tranche and Nth to Default

The ability to specify either Nth and Mth to default or tranche details on baskets has been included within basketReferenceInformation.

The tranche element is available to specify an attachment and exhaustion point as well as the legal applicability of Incurred Recovery. The Nth and Mth to Default sequence is available to express trades in which there is a triggered reference obligation to payout. The tranche and nthToDefault are features are both optional structures.

6.4 feeLeg

6.4.1 credit default swap

The feeLeg element represents the information specified in theFixed Payments section of the 2003 Confirmation. In other words, this is where the payment stream from Fixed Rate Payer to theFloating Rate Payer is specified. This element reuses types and elements from FpML 4.2 Interest Rate Derivatives.

The feeLeg allows representation of the following types of payment schedules for a credit default swap using a combination of the singlePayment and periodicPayment elements:

Fixed Amount, Regular Schedule
Fixed Rate, Regular Schedule
Fixed Rate, Month-End Rolls
Fixed Rate, Initial (Short) Stub
Fixed Rate, Initial (Long) Stub
Fixed Rate, Final (Short) Stub
Fixed Rate, Final (Long) Stub
Fixed Amount, Single Payment
Upfront Fee and Fixed Rate, Regular Schedule
Irregular Payment Schedule

An optional cashflow representation is also permitted. The feeLeg element appears in Figure 7.

Figure 7: feeLeg element

This structure allows specification of a single payment (zero or more) or a periodic series of payments. Therefore, it allows representation of a single upfront payment, a single upfront payment combined with a schedule of regular payments or a schedule of totally irregular payment dates and amounts. Note that payments specified in the singlePayment and periodicPayment elements are always assumed to be payments made by the Fixed Rate Payer (protection buyer) to the Floating Rate Payer (protection seller).

When a ‘New Transaction’ arises following a Novation it is market practice for a CDS that the initial Calculation Period with respect to the New Transaction shall commence on and include the (a) the Fixed Rate Payer Period End Date of the ‘Old Transaction’ that immediately precedes the Novation Date; or (b) in the event the Novation Date occurs during the initial Calculation Period of the Old Transaction, the Effective Date (see 2004 ISDA Novation Definitions at http://www.isda.org/publications/pdf/2004-Novation-Definitions.pdf for further background, specifically Section 1.20).

firstPeriodStartDate supports a CDS FpML representation for a New Transaction arising from a Novation to be useful as a standalone document (without needing reference to the Old Transaction). It allows specification of the initial Calculation Period Start Date where it is not equal to the trade’s Effective Date.

The periodicPayment.rollConvention element is used to address the ambiguities that can otherwise occur with regard to the actual payment dates, particularly when considering month-end rolls and any initial stub. The rollConvention element typically takes a value of 1-30 or EOM. It represents the actual unadjusted day in the month on which payments would occur.

As in FpML 4.2 Interest Rate Derivatives, the periodicPayment.firstPaymentDate element is only needed when the first period is irregular, i.e. there is a short or long initial stub. For a regular set of payment periods knowing the Effective Date, Scheduled Termination Date, payment frequency and roll convention is sufficient to define the schedule.

In keeping with the 2003 Definitions either a Fixed Rate Calculation or known Fixed Amount may be specified. The optional periodicPayment.fixedAmountCalculation.dayCountFraction element should be omitted in the case of a Transaction Supplement. Similarly, the optional periodicPayment.fixedAmountCalculation.calculationAmount element provides support for the full confirmation but should be omitted in the case of a Transaction Supplement.

The addition of the adjustedPaymentDate element within singlePayment and adjustedPaymentDates component in periodicPayment allows the optional inclusion of a 'cashflows' like structure consistent with what was done in FpML 4.2 Interest Rate Derivatives. Note these structures are intended more for internal application integration use rather than external communication, i.e. Wouldn't be applicable for confirmations.

Here are some example fee schedules:

Example 1 - Fixed Rate - Regular Schedule:

Effective Date: 1 November, 2002
Scheduled Termination Date: 1 November, 2007
Notional Amount: USD 5,000,000
Fixed Rate: .85%
Payment Frequency: Quarterly
Day Count Fraction: ACT/360

<feeLeg>
  <periodicPayment>
    <paymentFrequency>
      <periodMultiplier>3</periodMultiplier>
      <period>M</period>
    </paymentFrequency>
    <rollConvention>1</rollConvention>
    <fixedAmountCalculation>
	    <calculationAmount>
		    <currency>USD</currency>
		    <amount>5000000</amount>
	    </calculationAmount>
      <fixedRate>0.0085</fixedRate>
      <dayCountFraction dayCountFractionScheme="http://www.fpml.org/spec/2004/
day-count-fraction-1-0">ACT/360</dayCountFraction>
    </fixedAmountCalculation>
  </periodicPayment>
</feeLeg>

or in a Transaction Supplement

<feeLeg>
  <periodicPayment>
    <paymentFrequency>
      <periodMultiplier>3</periodMultiplier>
      <period>M</period>
    </paymentFrequency>
    <rollConvention>1</rollConvention>
    <fixedAmountCalculation>
      <fixedRate>0.0085</fixedRate>
    </fixedAmountCalculation>
  </periodicPayment>
</feeLeg>

Example 2 - Fixed Amount - Regular Schedule:

Effective Date: 1 November, 2002
Scheduled Termination Date: 1 November, 2007
Notional Amount: USD 5,000,000
Fixed Amount: USD 10,625
Payment Frequency: Quarterly
Day Count Fraction: ACT/360

<feeLeg>
  <periodicPayment>
    <paymentFrequency>
      <periodMultiplier>3</periodMultiplier>
      <period>M</period>
    </paymentFrequency>
    <rollConvention>1</rollConvention>
    <fixedAmount>
      <currency>USD</currency>
      <amount>10625.00</amount>
    </fixedAmount>
  </periodicPayment>
</feeLeg>

Example 3 - Fixed Rate - Month-End Rolls:

Effective Date: 30 September, 2002
Scheduled Termination Date: 30 September, 2007
Notional Amount: USD 5,000,000
Fixed Rate: .85%
Payment Frequency: Quarterly on each December 31, March 31, June 30 and September 30
Day Count Fraction: ACT/360

<feeLeg>
  <periodicPayment>
    <paymentFrequency>
      <periodMultiplier>3</periodMultiplier>
      <period>M</period>
    </paymentFrequency>
    <rollConvention>EOM</rollConvention>
    <fixedAmountCalculation>
      <calculationAmount>
        <currency>USD</currency>
        <amount>5000000</amount>
      </calculationAmount>
      <fixedRate>0.0085</fixedRate>
      <dayCountFraction dayCountFractionScheme="http://www.fpml.org/spec/2004/
day-count-fraction-1-0">ACT/360</dayCountFraction>
    </fixedAmountCalculation>
  </periodicPayment>
</feeLeg>

or in a Transaction Supplement

<feeLeg>
  <periodicPayment>
    <paymentFrequency>
      <periodMultiplier>3</periodMultiplier>
      <period>M</period>
    </paymentFrequency>
    <rollConvention>EOM</rollConvention>
    <fixedAmountCalculation>
      <fixedRate>0.0085</fixedRate>
    </fixedAmountCalculation>
  </periodicPayment>
</feeLeg>

Example 4 - Fixed Rate - Initial (Short) Stub:

Effective Date: 30 September, 2002
Scheduled Termination Date: 1 November, 2007
Notional Amount: USD 5,000,000
Fixed Rate: .85%
Payment Frequency: 1 November 2002 and each February 1, May 1, August 1 and November 1
Day Count Fraction: ACT/360

<feeLeg>
  <periodicPayment>
    <paymentFrequency>
      <periodMultiplier>3</periodMultiplier>
      <period>M</period>
    </paymentFrequency>
    <firstPaymentDate>2002-11-01</firstPaymentDate>
    <rollConvention>1</rollConvention>
    <fixedAmountCalculation>
      <fixedRate>0.0085</fixedRate>
    </fixedAmountCalculation>
  </periodicPayment>
</feeLeg>

Example 5 - Fixed Rate - Initial (Long) Stub:

Effective Date: 30 September, 2002
Scheduled Termination Date: 1 November, 2007
Notional Amount: USD 5,000,000
Fixed Rate: .85%
Payment Frequency: 1 February 2003 and each May 1, August 1, November 1 and February 1
Day Count Fraction: ACT/360

<feeLeg>
 <periodicPayment>
    <firstPaymentDate>2003-02-01</firstPaymentDate>
    <paymentFrequency>
      <periodMultiplier>3</periodMultiplier>
      <period>M</period>
    </paymentFrequency>
    <firstPaymentDate>2002-11-01</firstPaymentDate>
    <rollConvention>1</rollConvention>
    <fixedAmountCalculation>
      <fixedRate>0.0085</fixedRate>
    </fixedAmountCalculation>
  </periodicPayment>
</feeLeg>

Example 6 - Fixed Amount - Single Payment:

Effective Date: 1 November, 2002
Scheduled Termination Date: 1 November, 2007
Notional Amount: USD 5,000,000
Fixed Amount: USD 100,000
Payment Date: 2 November 2002

<feeLeg>
  <singlePayment>
    <adjustablePaymentDate>2002-11-02</adjustablePaymentDate>
    <fixedAmount>
      <currency>USD</currency>
      <amount>100000.00</amount>
    </fixedAmount>
  </singlePayment>
</feeLeg>

Example 7 - Upfront Fee combined with Fixed Rate Regular Schedule

Effective Date: 1 November, 2002
Scheduled Termination Date: 1 November, 2007
Notional Amount: USD 5,000,000
Upfront Payment Amount: USD 100,000
Upfront Payment Date: 2 November 2002
Fixed Rate: .85%
Payment Frequency: Quarterly
Day Count Fraction: ACT/360

<feeLeg>
  <singlePayment>
    <adjustablePaymentDate>2002-11-02</adjustablePaymentDate>
    <fixedAmount>
      <currency>USD</currency>
      <amount>100000.00</amount>
    </fixedAmount>
  </singlePayment>
  <periodicPayment>
    <paymentFrequency>
      <periodMultiplier>3</periodMultiplier>
      <period>M</period>
    </paymentFrequency>
    <rollConvention>1</rollConvention>
    <fixedAmountCalculation>
      <fixedRate>0.0085</fixedRate>
    </fixedAmountCalculation>
  </periodicPayment>
</feeLeg>

Example 8 - Irregular Payment Schedule

Effective Date: 1 November, 2002
Scheduled Termination Date: 1 November, 2007
Notional Amount: USD 5,000,000
Fixed Amount of USD 100,000 on 2 November 2002 and USD 50,000 on 2 December 2002 .

<feeLeg>
  <singlePayment>
    <adjustablePaymentDate>2002-11-02</adjustablePaymentDate>
    <fixedAmount>
      <currency>USD</currency>
      <amount>100000.00</amount>
    </fixedAmount>
  </singlePayment>
  <singlePayment>
    <adjustablePaymentDate>2002-12-02</adjustablePaymentDate>
    <fixedAmount>
      <currency>USD</currency>
      <amount>50000.00</amount>
    </fixedAmount>
  </singlePayment>
</feeLeg>

Example 9 - Fixed Rate - Final (Short) Stub:

Effective Date: 18 February, 2003
Scheduled Termination Date: 20 March, 2008
Notional Amount: USD 5,000,000
Fixed Rate: .9%
Payment Frequency: 20 March 2003 and each June 20, September 20 and March 20.
Day Count Fraction: ACT/360

<feeLeg>
  <periodicPayment>
    <paymentFrequency>
      <periodMultiplier>3</periodMultiplier>
      <period>M</period>
    </paymentFrequency>
    <lastRegularPaymentDate>2003-03-20</lastRegularPaymentDate>
    <rollConvention>20</rollConvention>
    <fixedAmountCalculation>
      <fixedRate>0.009</fixedRate>
    </fixedAmountCalculation>
  </periodicPayment>
</feeLeg>

Example 10 - Fixed Rate - Regular Schedule (Including Optional Cashflows):

Effective Date: 1 November, 2002
Scheduled Termination Date: 1 November, 2003
Notional Amount: USD 5,000,000
Fixed Rate: .85%
Payment Frequency: Quarterly
Day Count Fraction: ACT/360

Note that the adjustedPaymentDate element values have not been adjusted for any applicable business days.

<feeLeg>
  <periodicPayment>
    <paymentFrequency>
      <periodMultiplier>3</periodMultiplier>
      <period>M</period>
    </paymentFrequency>
    <rollConvention>1</rollConvention>
    <fixedAmountCalculation>
      <calculationAmount>
        <currency>USD</currency>
        <amount>5000000</amount>
      </calculationAmount>
      <fixedRate>0.0085</fixedRate>
      <dayCountFraction dayCountFractionScheme="http://www.fpml.org/spec/2004/
day-count-fraction-1-0">ACT/360</dayCountFraction>
    </fixedAmountCalculation>
    <adjustedPaymentDates>
      <adjustedPaymentDate>2003-02-01</adjustedPaymentDate>
      <fixedAmount>
        <currency>USD</currency>
        <amount>10625.00</amount>
      </fixedAmount>
    </adjustedPaymentDates>
    <adjustedPaymentDates>
      <adjustedPaymentDate>2003-05-01</adjustedPaymentDate>
      <fixedAmount>
        <currency>USD</currency>
        <amount>10625.00</amount>
      </fixedAmount>
    </adjustedPaymentDates>
    <adjustedPaymentDates>
      <adjustedPaymentDate>2003-08-01</adjustedPaymentDate>
      <fixedAmount>
        <currency>USD</currency>
        <amount>10625.00</amount>
      </fixedAmount>
    </adjustedPaymentDates>
    <adjustedPaymentDates>
      <adjustedPaymentDate>2003-11-01</adjustedPaymentDate>
      <fixedAmount>
        <currency>USD</currency>
        <amount>10625.00</amount>
      </fixedAmount>
    </adjustedPaymentDates>
  </periodicPayment>
</feeLeg>

Example 11 - firstPeriodStartDate - Novations Support

Suppose the following Old Transaction is Novated with the following information:

Effective Date: 9 June, 2004
Scheduled Termination Date: 20 June, 2009
First Fixed Rate Payer Payment Date: 20 September, 2004
Novation Trade Date: 21 September, 2004
Novation Date: 22 September, 2004

Old Transaction FpML (abbreviated) representation:

<creditDefaultSwap>
  <generalTerms>
    <effectiveDate>
      <unadjustedDate>2004-06-09</unadjustedDate>
      <dateAdjustments>
        <businessDayConvention>NONE</businessDayConvention>
      </dateAdjustments>
    </effectiveDate>
    <scheduledTerminationDate>
      <adjustableDate>
        <unadjustedDate>2009-06-20</unadjustedDate>
        <dateAdjustments>
          <businessDayConvention>NONE</businessDayConvention>
        </dateAdjustments>
      </adjustableDate>
    </scheduledTerminationDate>
    ...
  </generalTerms>
  <feeLeg>
    <periodicPayment>
      <paymentFrequency>
        <periodMultiplier>3</periodMultiplier>
        <period>M</period>
      </paymentFrequency>
      <firstPaymentDate>2004-09-20</firstPaymentDate>
      <rollConvention>20</rollConvention>
      <fixedAmountCalculation>
        <calculationAmount>
          <currency>EUR</currency>
          <amount>5000000.0</amount>
        </calculationAmount>
        <fixedRate>0.0125</fixedRate>
        <dayCountFraction dayCountFractionScheme="http://www.fpml.org/spec/2004/
day-count-fraction-1-0">ACT/360</dayCountFraction>
      </fixedAmountCalculation>
    </periodicPayment>
  </feeLeg>
  ...
</creditDefaultSwap>

For the New Transaction the FpML representation would show:

Effective Date: 22 September, 2004 (the Novation Date)
Scheduled Termination Date: 20 June, 2009
Scheduled Termination Date: 20 June, 2009
First Fixed Rate Payer Payment Date: 20 December, 2004
Initial Calculation Period Start Date (element firstPeriodStartDate): 20 September, 2004

New Transaction FpML (abbreviated) representation:

<creditDefaultSwap>
  <generalTerms>
    <effectiveDate>
      <unadjustedDate>2004-09-22</unadjustedDate>
      <dateAdjustments>
        <businessDayConvention>NONE</businessDayConvention>
      </dateAdjustments>
    </effectiveDate>
    <scheduledTerminationDate>
      <adjustableDate>
        <unadjustedDate>2009-06-20</unadjustedDate>
        <dateAdjustments>
          <businessDayConvention>NONE</businessDayConvention>
        </dateAdjustments>
      </adjustableDate>
    </scheduledTerminationDate>
    ...
  </generalTerms>
  <feeLeg>
    <periodicPayment>
      <paymentFrequency>
        <periodMultiplier>3</periodMultiplier>
        <period>M</period>
      </paymentFrequency>
      <firstPeriodStartDate>2004-09-20</firstPeriodStartDate>
      <firstPaymentDate>2004-12-20</firstPaymentDate>
      <rollConvention>20</rollConvention>
      <fixedAmountCalculation>
        <calculationAmount>
          <currency>EUR</currency>
          <amount>5000000.0</amount>
        </calculationAmount>
        <fixedRate>0.0125</fixedRate>
        <dayCountFraction dayCountFractionScheme="http://www.fpml.org/spec/2004/
day-count-fraction-1-0">ACT/360</dayCountFraction>
      </fixedAmountCalculation>
    </periodicPayment>
  </feeLeg>
  ...
</creditDefaultSwap>

6.4.2 credit default swap index

The payment information that appears in the transaction supplement representation of a credit default swap index trade is expressed in FpML by using the initialPayment and periodicPayment/fixedAmountCalculation elements.

Trades on credit default swap indices generally have an upfront payment associated with them. Unlike upfront payments on credit default swap trades, the initial payment can be from either protection buyer to protection seller or from protection seller to protection buyer. To address this requirement, an additional optional element called initialPayment has been added to feeLeg in FpML 4.1. This element is intended to be used solely in the representation of a credit default swap index trade.

The structure of initialPayment can be seen in figure 6. The major difference between initialPayment and singlePayment is that initialPayment allows the specification of which party is making the payment (payerPartyReference) and which is receiving it (receiverPartyReference).

Unlike a credit default swap trade, a credit index trade has two fixed rates associated with it:

Fixed Rate: Credit spread (“premium”) set at the time the index series is issued. Payments from the protection buyer to the protection seller are based on this value. It’s roughly analogous to the coupon on a fixed rate bond.
Market Fixed Rate: Credit spread (“fair value”) of the index at a particular time. Varies over the life of the index depending on market conditions. This is the price quoted by the trading desks. It’s roughly analogous to the yield on a fixed rate bond.

The present value of the difference between these two fixed rates is one of the two inputs to the calculation of the initial (e.g. upfront) payment. The other component is accrued interest.

Here is an example of the payment information associated with a trade and how that information appears in FpML:

Initial Payment: EUR 10,000
Initial Payment Payer: XYZ Bank
Fixed Rate: .70%
Market Fixed Rate: .40%

<feeLeg> 
        <initialPayment> 
                <payerPartyReference href="partyA"/> 
                <receiverPartyReference href="partyB"/> 
                <paymentAmount> 
                        <currency>EUR</currency> 
                        <amount>10000</amount>                 
                </paymentAmount>             
        </initialPayment> 
        <periodicPayment> 
                <fixedAmountCalculation> 
                        <fixedRate>0.0070</fixedRate> 
                </fixedAmountCalculation> 
        </periodicPayment> 
        <marketFixedRate>0.0040</marketFixedRate>   
</feeLeg>

6.5 protectionTerms

The protectionTerms element, which appears in Figure 8, represents the information specified in the FloatingPayment section of the 2003 Confirmation. This is where the credit events and obligations that are applicable to the credit default swap trade are specified.

Figure 8: protectionTerms element

The only required child element of protectionTerms is calculationAmount. It represents the term Floating Rate Payer Calculation Amount in the 2003 Definitions.

In order to indicate that a particular Credit Event is applicable in an FpML credit default swap trade, an element whose name is the Credit Event it represents appears as a child of the creditEvents element. If a particular Credit Event has no attributes of its own (e.g. Bankruptcy), it appears as an empty element. On the other hand, if it does have attributes (e.g. Failure to Pay - Grace Period, Payment Requirement) then those attributes appear as child elements of the creditEvent.

In the following example, these credit events are applicable:

Bankruptcy
Failure to Pay with Grace Period Extension not applicable and Payment Requirement of USD 1,000,000.
Restructuring (R)
Default Requirement of USD 10,000,000.

And these conditions to credit event notice settlement apply:

Both the Buyer and Seller are notifying parties.
Notice of Publicly Available Information is a Condition to Payment - defaults apply for Public Source(s) and Specified Number.

<creditEvents>
  <bankruptcy/>
  <failureToPay>
    <paymentRequirement>
      <currency>USD</currency>
      <amount>1000000</amount>
    </paymentRequirement>
  </failureToPay>
  <restructuring>
    <restructuringType restructuringScheme =
      "http://www.fpml.org/spec/2003/restructuring-1-0">R</restructuringType>
  </restructuring>
  <creditEventNotice>
    <notifyingParty>
      <buyerPartyReference href = "abc"/>
      <sellerPartyReference href = "def"/>
    </notifyingParty>
    <publiclyAvailableInformation>
      <standardPublicSources/>
      <specifiedNumber>2</specifiedNumber>
    </publiclyAvailableInformation>
  </creditEventNotice>
</creditEvents>

Please note the following regarding the representation of the Restructuring credit event:

If the Restructuring credit event is not applicable, no restructuring element should appear in the creditEvents element.
If Restructuring as defined in the 2003 Definitions is applicable and a full confirmation is being represented, then the restructuring element should appear and the restructuringType element contains one of the three restructuring codes (see below).
If Restructuring as defined in the 2003 Definitions is applicable and a transaction supplement is being represented, then only the restructuring element should appear (the actual restructuring type will be defined in the relevant master confirmation associated with the transaction supplement).
If the 1999 Definitions are used and a transaction supplement is being represented, the actual restructuring type needs to be explicitly specified in the XML instance using the restructuringType element (same as one would do for a long form) since the 1999 master agreements are silent on the actual restructuring type.

The legal restructuring codes are:

ModR: If Restructuring Maturity Limitation and Fully Transferable Obligation (Section 2.32 of the 2003 Definitions) applies.
ModModR: If Modified Restructuring Maturity Limitation and Conditionally Transferable Obligation (Section 2.33 of the 2003 Definitions) applies.
R: If neither Restructuring Maturity Limitation and Fully Transferable Obligation or Modified Restructuring Maturity Limitation and Conditionally Transferable Obligation are applicable.

The optional obligations element has a category child element that represents the Obligation Category term. The ObligationCategory type is an enumeration that consists of values representing the following categories:

Payment
Borrowed Money
Reference Obligations Only
Bond
Loan
Bond or Loan

ISDA published in September 2004 additional provisions for U.S. Municipal Entity as Reference Entity (see http://www.isda.org/publications/pdf/additionalprovisions.pdf) and the associated form of confirmation (see http://www.isda.org/publications/docs/municdsconfirmation.doc) introduced three additional terms which could be selected as Obligation Characteristics and Deliverable Obligation Characteristics. These were:

Full Faith and Credit Obligation Liability
General Fund Obligation Liability
Revenue Obligation Liability

The confirmation implied only one can be selected at a time.

These three elements were added as empty elements within an optional choice group to the corresponding Obligations and DeliverableObligations complex types.

Obligation Characteristics are defined in a manner similar to credit events. In other words, each Obligation Characteristic has its own element. The applicability of the characteristic is indicated by the appearance of its corresponding obligationCharactersitic element.

6.6 physicalSettlementTerms and cashSettlementTerms

If settlement terms are specified in an FpML 4.2 credit default swap, then the settlement method of Physical Settlement or Cash Settlement is specified by the presence of either the physicalSettlementTerms or the cashSettlementTerms element respectively.

The physicalSettlementTerms element, which appears in Figure 8, represents the information specified in the Settlement Terms- Terms Relating to Physical Settlement section of the 2003 Confirmation.

The physicalSettlementPeriod contains one of three elements to represent the following conditions:

businessDaysNotSpecified: Section 8.5/8.6 of the 1999/2003 CD Definitions applicable.
businessDays: Explicit number of business days.
maximumBusinessDays: Section 8.5/8.6 of the 1999/2003 CD Definitions capped at a specific number of business days, e.g. 10 days.

The optional deliverableObligations element is defined in a manner similar to the obligations element. The Deliverable Obligation Category is specified with the category element, which is of type ObligationCategory. Similar to an Obligation Characteristic, the applicability of a Deliverable Obligation Characteristic is indicated by the appearance of its corresponding element. It also bears mentioning that the applicability of Partial Cash Settlementappears as child element of the corresponding Deliverable Obligation Characteristic element.

Figure 9: physicalSettlementTerms element

The cashSettlementTerms element, which appears in Figure 10, represents the information specified in the Settlement Terms- Terms Relating to Cash Settlement section of the 2003 Confirmation. The mapping between this element and its corresponding section of the confirm is very straightforward.

Figure 10: cashSettlementTerms element

6.7 Credit Event Notice

6.7.1 Background

The 2003 ISDA Credit Derivatives Definitions define "Credit Event Notice" as an irrevocable notice from a Notifying Party to the other party that describes a Credit Event that occurred.

A Credit Event Notice must contain a description in reasonable detail of the facts relevant to the determination that a Credit Event has occurred.

EXHIBIT B to 2003 Credit Derivatives Definitions (pdf file)

FpML 4.2 supports Credit Event Notices. Credit Event Notice is implemented in FpML as static document (DataDocument) and notification message ( both described below).

The existence of a static document representation (DataDocument) was a result of two main requirements defined by the Credit Derivatives Working Group:

It makes the relationship to the corresponding ISDA legal framework more understandable.
Other messaging standards allow an FpML document as payload.

6.7.2 Implementation

The representation as static document required the introduction of a new "event" element in the DataDocument. As mentioned before, Credit Event Notice is also modeled in the messaging framework as notification message.
The static document approach constrains the current DataDocument structure, introducing an "xsd:choice" element. The reason for that was to avoid permutations between the existing elements.

<xsd:complexType name="DataDocument">
        <xsd:annotation>
            <xsd:documentation xml:lang="en">A type defining a content model that is backwards
                compatible with older FpML releases and which can be used to contain sets of data
                without expressing any processing intention.</xsd:documentation>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="Document">
                <xsd:sequence>
                    <xsd:group ref="Validation.model"/>
                    <xsd:choice>
                        <xsd:sequence>
                            <xsd:element name="trade" type="Trade"  minOccurs=”0” maxOccurs="unbounded">
                                <xsd:annotation>
                                    <xsd:documentation xml:lang="en">The root element in an FpML
                                        trade document.</xsd:documentation>
                                </xsd:annotation>
                            </xsd:element>
                            <xsd:element name="portfolio" type="Portfolio" minOccurs="0" maxOccurs="unbounded">
                                <xsd:annotation>
                                    <xsd:documentation xml:lang="en">An arbitrary grouping of trade
                                        references (and possibly other portfolios).</xsd:documentation>
                                </xsd:annotation>
                            </xsd:element>
                        </xsd:sequence>
                        <xsd:sequence>
                            <xsd:element ref="event" maxOccurs="unbounded">
                                <xsd:annotation>
                                    <xsd:documentation xml:lang="en">A business event.</xsd:documentation>
                                </xsd:annotation>
                            </xsd:element>
                        </xsd:sequence>
                    </xsd:choice>
                    <xsd:element name="party" type="Party" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation xml:lang="en">The parties obligated to make payments
                                from time to time during the term of the trade. This will include,
                                at a minimum, the principal parties involved in the swap or forward
                                rate agreement. Other parties paying or receiving fees, commissions
                                etc. must also be specified if referenced in other party payments.</xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>

The “event” element is a substitution group for "creditEventNotice". This means that "creditEventNotice will appear in the instance document, not "event".
The "creditEventNotification" message is an extension of a "NotificationMessage". It adds a single element called "creditEventNotice" with type "CreditEventNoticeDocument" to the notification message content.

Why "CreditEventNoticeDocument" type? Because the "CreditEventNotice" type was already defined in the Credit Derivatives subschema (This type is used to represent the Credit Event Notice information specified on a full confirmation. It is used to specify things like the notifying party and number of public sources. There was a name collision so the group decided to define "CreditEventNoticeDocument" as type containing the business document model.
"creditEventNoticeDocument" is an extension of "Event" type. "Event" type is a container of events. It only contains "eventId" (an optional element to provide a unique id for each event). The idea is that this container will group other event structures.

The "creditEventNotice" element defines the content model for Credit Event Notice:

6.7.2.1 Description of some of the elements

eventId - An event reference identifier allocated by a party. FpML does not define the domain values associated with this element. Note that the domain values for this element are not strictly an enumerated list.

affectedTransactions - Trades affected by this event.

The rationale for introducing a container for trade identifiers is because an individual trade can be referenced by 2 different partyTradeIdentifier elements - each allocated by a different party. So Bank A may know the trade as 123 and also know that their counterparty Bank B knows it as 567 and they'd wish to include both identifiers in the credit event notice but need to make it clear that 123 and 567 refer to the same trade.

referenceEntity:

creditEvent - Modeled as a substitution group in order to facilitate its extension. Each one of the possible values (bankruptcy, failureToPay, obligationDefault, obligationAcceleration, repudiationMoratorium, and restructuring) has its own complex type which extends the CreditEvent type. It has exactly the same behavior as an xsd:choice but it’s more extensible.

publiclyAvailableInformation - Modeled to describe the resource that contains the media representation of the business event. For example, can describe a file or a URL that represents the resource. This is the description of the different elements describing the resource:

resourceId (mandatory): The unique identifier of the resource within the event.
language (optional): Indicates the language of the resource, described using the ISO 639-2/T Code.
sizeInBytes (optional): Indicates the size of the resource in bytes. Could be used by the end user to estimate the download time and storage needs.
length (optional): Indicates the length of the product. For example, if the product were a PDF file, the length would be in pages.
mimeType (mandatory): Indicates the type of media used to store the content. mimeType is used to determine the software product(s) that can read the content. MIME Types are described in RFC 2046.
name (optional): The name of the resource.
comments (optional): Any additional comments that are deemed necessary. For example, which software version is required to open the document? Or, how does this resource relate to the others for this event?
url (optional): Indicates the URL at which the resource can be found.

6.7.2.2 Examples

This is an example of Credit Event Notice document: Credit Event Notice Sample (pdf file)

The following two FpML instance documents are based on this example:

6.8 Appendix A: Naming differences between FpML 4.2 Credit Derivatives Subschema and 2003 ISDA Credit Derivatives Definitions

There are several places in the FpML 4.2 Credit Derivatives Subschema where the element names diverge from the names used for terms in the 2003 Definitions. These names are listed in the table that appear in Figure 11.

FpML Element Name	2003 Definitions	Existing FpML Element	Clarity
sellerPartyReference	Floating Rate Payer	X	X
buyerPartyReference	Fixed Rate Payer	X	X
dateAdjustments	Business Day, Business Day Convention	X
obligationId	CUSIP/ISIN		X
feeLeg	Fixed Payments		X
protectionTerms	Floating Payment		X
calculationAmount	Fixed Rate Payer Calculation Amount, Floating Rate Payer Calculation Amount		X
valuationDate	Valuation Date	X
valuationTime	Valuation Time	X
accruedInterest	Quotations	X
excluded	Excluded Obligations	X
excluded	Excluded Deliverable Obligations	X
category	Obligation Category	X
category	Deliverable Obligation Category	X
calculationAgentPartyReference	Calculation Agent	X

Figure 11: Naming differences between FpML 4.2 and the 2003 definitions (incomplete).

The table also indicates the reason why the FpML name diverges from the name used in the 2003 definitions. There are only two reasons for diverging:

An appropriate FpML element already existed, but this element did not have the same name as the corresponding term in the 2003 Definitions.
WG members thought a different name would provide greater clarity to FpML users.