6.1 Introduction
This section provides an in-depth review of the product architecture of FpML 5.3 Credit Derivatives. The products covered by FpML 5.3 Credit Derivatives are the single name credit default swap, the credit default swap index, the credit default swap basket, the credit default swap on a mortgage, and the credit default swap on a loan.
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 5.3 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 5.3 Credit Derivatives that differ in name from their corresponding terms in the 2003 Definitions. In FpML 5.3 it is possible to represent credit default swap trades done under either the 1999 or the 2003 definitions.
The FpML 5.3 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 5.3 Credit Derivatives usable in all stages of the credit default swap trade lifecycle.
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.
Product support for the credit default swap on a mortgage was added to FpML in version 4.3. The support includes the representation of a mortgage underlyer and the addition of additional structures within the creditDefaultSwap product representation.
6.1.3.1 Main differences between Mortgage and Corporate CDS
| Underlying product | Mortgage | Corporate |
| Traded on | Reference obligation | Reference entity |
| Credit Events | Failure to pay principal; Write down – occurs when the reference obligation is written down (realized losses usually); Distressed ratings downgrade; Maturity extension; Failure to Pay Interest | Bankruptcy; Failure to pay; Restructuring; Sovereign failure to pay, in case of emerging market underlyers |
| Interest Shortfall | Interest does not have to be fully paid, and can be reimbursed at a later time | Not applicable |
| Factors | Bonds factor down, as mortgages are paid down | No factor issues |
| Payment frequency | Monthly | Quarterly |
| Maturity | Generally 30 year bonds. The CDS trade terminates with the maturity of the underlyer | Five or ten years are most common. CDS trades terminate with the maturity of the underlyer or a credit event |
6.1.3.2 The Pay-As-You-Go model
While single name corporate CDS are terminated once a credit event occurs, mortgage CDS persist.
A failure to pay principal or interest by some underlying mortgagors results in a shortfall, which is then compensated by the protection seller, in accordance to the contract terms. If those mortgagors reimburse those defaults at a later point, this will result into a corresponding ‘additional fixed payment amount’ that will be returned by the production buyer.
Those ‘floating rate payment events’ and ‘additional fixed payments’ can exist without occurrence of a credit event. A typical case would be when a failure to pay interests is not eligible as a credit event (but specified as an eligible floating rate payment event).
Product support for the credit default swap on a loan was added to FpML in version 4.3. The support includes the representation of a loan underlyer and the addition of additional structures within the creditDefaultSwap product representation.
The Loan CDS approach is tackled through two extensions to the reference information:
- the securedList element as an optional last child of Reference Information, which means that the reference obligation is not required if Secured List is present and true; this follows the normal naming convention in FpML for elements relating to ISDA Applicable or Non Applicable Legal Terms.
- the loan underlyer to the list of available products as part of the Reference Obligation.
Product support for credit default swap option was added to FpML in version 4.3. The support is based on the creation of a new creditDefaultSwapOption product. As part of this work, some option structures have been generalized to be reused across multiple types of options.
The credit default swap underlyer is supported by referencing the existing creditDefaultSwap product element within the new creditDefaultSwapOption product.
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
|
2003 Confirmation |
FpML creditDefaultSwap Element |
|
General Terms |
generalTerms |
|
Fixed Rate Payments |
feeLeg |
|
Floating Payment |
protectionTerms |
|
Settlement Terms |
Not included in Transparency view |
|
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 required for Transparency view. Therefore, the equivalent element (physicalSettlementTerms or cashSettlementTerms) are not supported in Transparency view of FpML 5.3.
- The Notice and Account Details and Offices sections of the confirmation do not have a direct analog in the FpML 5.3 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.
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 and transparency 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 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, a convertibleBond, a mortgage, or loan as one of its child elements. The bond, convertibleBond, mortgage, and loan 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.
6.3.3.1 bond and convertibleBond
For a credit default swap, bond or convertibleBond is used to specify a Reference Obligation's CUSIP/ISIN, Maturity and Coupon 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 Coupon and Maturity terms respectively.
6.3.3.2 mortgage
A mortgage underlyer was added to the underlying classes that are part of the ReferenceObligation structure in order to support cds on mortgage. This Mortgage type uses most of the structures present at other underlying assets.
|
|
The extensions specific to the mortgage structure are the following:
- The originalPrincipalAmount element, which schema definition is 'The initial issued amount of the mortgage obligation'.
- The pool, which specifies the underlying mortgage pool through an initialFactor and a currentFactor elements. An optional versionHistory group provides the ability to indicate the version of the pool. In the ISDA long form definition, this initialFactor is used as an input for specifying the 'Applicable Percentage' that is used throughout the life the trade for representing the effect of the mortgage factor updates.
- The sector, defined in the schema as 'The sector classification of mortgage obligations'. This element is specified as a normalized string that optionally refers to the mortgageSectorScheme. This scheme contains the mortgage typology currently in use by the marketplace: ABS, CDO, CMBS and RMBS.
- The tranche specifies the mortgage obligation tranche that is subject to the derivative transaction. There can only be one tranche. No scheme is associated with the tranche, as there is no current classification or normalization of those mortgage tranches.
6.3.3.3 loan
A loan underlyer was added to the list of available product classes as part of the Reference Obligation. This Loan type extends Underlying Asset structure.
|
|
The extensions specific to the loan structure are the following:
- The borrowerName or borrowerPartyReference on Loan CDS is meant to be used in the event that there is no Bloomberg Id or the Secured List isn't applicable, and has been modeled in the same way as the insurerName or insurerPartyReference on Mortgage CDS.
- The lien specifies the seniority level of the lien..
- The facilityType describes the type of the loan facility and is specified through the facility-type-1-0.xml scheme file. Defined values are “BridgeLoan”, “LetterOfCredit”, “RevolvingLoan”, “SwinglineFunding”, “TermLoan” and “TradeClaim”.
- The maturity is the maturity date of the loan.
- The creditAgreementDate is the closing date (the date where the agreement has been signed) for the loans in the credit agreement. Funding of the facilities occurs on (or sometimes a little after) the Credit Agreement date. This underlyer attribute is used to help identify which of the company's outstanding loans are being referenced by knowing to which credit agreement it belongs. ISDA Standards Terms Supplement term: Date of Original Credit Agreement.
- While the tranche element is present for both the mortgage and loan extensions, its usage is different across those 2 underlyers:
- In the mortgage case, the instrument Id is used to indicate the Bloomberg reference number of the mortgage, while the tranche element is used to qualify the specific tranche that is subject to the derivative transaction.
- With the loan, the Bloomberg number qualifies both the loan and the tranche. As a result, the instrument Id is used to specify the loan’s Cusip, while the tranche is used to specify the Bloomberg number. Consequently, a transcheIdScheme is being associated to the tranche element.
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.
|
|
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>
The referencePolicy element is applicable to the transactions on mortgage-backed security, which can make use of a reference policy. Presence of the element indicates that the reference policy is applicable; absence implies that it is not.
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>
6.3.5.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.
|
|
6.3.5.2 Settled Entity Matrix
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.
<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>
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.
The feeLeg element represents the information specified in the Fixed Payments section of the 2003 Confirmation. In other words, this is where the payment stream from Fixed Rate Payer to the Floating Rate Payer is specified. This element reuses types and elements from FpML 5.3 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 Rate, Regular Schedule
- Upfront Fee and Fixed Rate, Regular Schedule
In addition, it's important to note that the use of initialPayment allows the representation of the situation when the seller of protection pays a fee to the buyer as an upfront payment. An example of this scenario is the payment in exchange for an agreed modification of the first period start date.
|
|
Figure 7: feeLeg element
In transparency view, the fixed leg is limited to representing the fixed rate for a periodic payment, and optionally an upfront fee.
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 5.3 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>
<paymentFrequency>
<periodMultiplier>3</periodMultiplier>
<period>M</period>
</paymentFrequency>
<firstPaymentDate>2003-02-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
- 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>
Example 12 - Periodic payments - stepping notional
A credit default swap pays 100bp every 3 months. The notional starts at 5M but steps down twice throughout the life of the deal (only the relevant portions of FpML are shown):
<feeLeg>
<periodicPayment>
<paymentFrequency>
<periodMultiplier>3</periodMultiplier>
<period>M</period>
</paymentFrequency>
<rollConvention>1</rollConvention>
<fixedAmountCalculation>
<calculationAmount>
<currency>USD</currency>
<amount>5000000</amount>
<step>
<stepDate>2002-03-01</stepDate>
<stepValue>4000000</stepValue>
</step>
<step>
<stepDate>2002-09-01</stepDate>
<stepValue>3000000</stepValue>
</step>
</calculationAmount>
<fixedRate>0.010</fixedRate>
<dayCountFraction>ACT/360</dayCountFraction>
</fixedAmountCalculation>
</periodicPayment>
</feeLeg>
<protectionTerms>
<calculationAmount>
<currency>USD</currency>
<amount>5000000</amount>
<step>
<stepDate>2002-03-01</stepDate>
<stepValue>4000000</stepValue>
</step>
<step>
<stepDate>2002-09-01</stepDate>
<stepValue>3000000</stepValue>
</step>
</calculationAmount>
<creditEvents>
<defaultRequirement>
<currency>USD</currency>
<amount>10000000</amount>
</defaultRequirement>
...
Example 13 - Irregular Payments, stepping notional
In this example, payments are made at irregular intervals (note that there is no June payment). Also the amount of each payment is determined based on notional that change over time:
<feeLeg>
<singlePayment>
<adjustablePaymentDate>2001-12-01</adjustablePaymentDate>
<fixedAmount>
<currency>USD</currency>
<amount>230.50</amount>
</fixedAmount>
</singlePayment>
<singlePayment>
<adjustablePaymentDate>2002-03-01</adjustablePaymentDate>
<fixedAmount>
<currency>USD</currency>
<amount>219.20</amount>
</fixedAmount>
</singlePayment>
<singlePayment>
<adjustablePaymentDate>2002-9-01</adjustablePaymentDate>
<fixedAmount>
<currency>USD</currency>
<amount>500.00</amount>
</fixedAmount>
</singlePayment>
<periodicPayment>
<fixedAmountCalculation>
<calculationAmount>
<currency>USD</currency>
<amount>5000000</amount>
<step>
<stepDate>2002-03-01</stepDate>
<stepValue>4000000</stepValue>
</step>
<step>
<stepDate>2002-09-01</stepDate>
<stepValue>3000000</stepValue>
</step>
</calculationAmount>
<fixedRate>0.010</fixedRate>
<dayCountFraction>ACT/360</dayCountFraction>
</fixedAmountCalculation>
</periodicPayment>
</feeLeg>
<protectionTerms>
<calculationAmount>
<currency>USD</currency>
<amount>5000000</amount>
<step>
<stepDate>2002-03-01</stepDate>
<stepValue>4000000</stepValue>
</step>
<step>
<stepDate>2002-09-01</stepDate>
<stepValue>3000000</stepValue>
</step>
</calculationAmount>
...
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>
The paymentDelay has been added as a boolean element as part of the feeLeg construct to support the ISDA definition associated with the fixed amount:
| Fixed Amount: | [Fixed Amount definition for underlying with no payment delay]/[Fixed Amount definition for underlying with payment delay] |
Parties should make a selection that is appropriate in view of the interest basis of the Reference Obligation as set out in the Underlying Instruments. The former version may be preferred if the Reference Obligation does not have a payment delay, and the latter if it is a security with a payment delay.
The schema definition states: “Applicable to CDS on MBS to specify whether payment delays are applicable to the fixed Amount. RMBS typically have a payment delay of 5 days between the coupon date of the reference obligation and the payment date of the synthetic swap. CMBS do not, on the other hand, with both payment dates being on the 25th of each month.”
In Transparency view the protectionTerms element contains only the protection amount (trade notional); in futures versions of the schema it may contain indicators for some commonly negotiated credit events such as "restructuring".
There are several places in the FpML 5.3 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 5.3 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.