7.1 Introduction
This section provides an in-depth review of the product architecture of FpML 5.6 Credit Derivatives. The products covered by FpML 5.6 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.6 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.6 Credit Derivatives that differ in name from their corresponding terms in the 2003 Definitions. In FpML 5.6 it is possible to represent credit default swap trades done under either the 1999 or the 2003 definitions.
The FpML 5.6 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.6 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 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.
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.
7.1.4.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 |
7.1.4.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
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.
In Transparency view, the structure of the creditDefaultSwap element corresponds to a subset of the structure of the Confirmation that appears in Exhibit A of the 2003 Definitions (hereafter referred to as the "2003 Confirmation"). The sections that comprise the 2003 Confirmation and their corresponding Transparency View 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 5.6.
- The Notice and Account Details and Offices sections of the confirmation do not have a direct analog in the FpML 5.6 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 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, 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.
7.3.1.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.
7.3.1.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.
7.3.1.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>
7.3.3.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.
|
|
|
7.3.3.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>
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.
7.3.4.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.
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>
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.6 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
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.
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 5.6 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 5.6 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.”
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 element with its value set to true. 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 Credit Event with the "applicable" element's value set to true. If in an element doesn't appear it means that it's not applicable or its applicability is defined within the master confirmation. In general, the value set to false will be specified only in case the default in the master confirmation needs to be overridden.
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>true</bankruptcy>
<failureToPay>
<paymentRequirement>
<currency>USD</currency>
<amount>1000000</amount>
</paymentRequirement>
</failureToPay>
<restructuring>
<applicable>true</applicable>
<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> true</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.
Five credit event elements have been added as part of the CreditEvents container in order to support cds on derivatives: failureToPayPrincipal, failureToPayInterest, distressedRatingsDowngrade, maturityExtension and writedown.
- failureToPayInterest and failureToPayPrincipal have been positioned as eligible credit events besides the pre-existing failureToPay element. The idea is that those new elements are distincts from this latter one, as they qualify the failure to pay in a manner that is explicit as part of the ISDA definitions. As such, there is no ambiguity. An alternative approach that consisted in qualifying this pre-existing failureToPay element was considered, but rejected because of its perceived level of indirection vis-à-vis the ISDA definitions.
- distressedRatingsDowngrade, maturityExtension and writedown: these three additional credit events have similarly been specified as boolean elements. Presence of the element as part of the instance document will then suffice to qualify any of those as an applicable credit event.
Mortgage CDS introduce the concept of floating amount events, which is not applicable to corporate CDS contracts.
|
|
|
- Specifies the eligible floating rate payment events through the following elements which are contained within the FloatingAmountEvents complex type:
- principalShortfall;
- interestShortfall;
- writedown.
- The provisions that might be applicable in case the interest short fall applies (non-optional floatingAmountProvision extension).
- The events that can constitute to additional fixed payments (non-optional additionalFixedPayment extension):
- interestShortfallReimbursement;
- principalShortfallReimbursement;
- The writedownReimbursement.
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 boolean 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.
If settlement terms are specified in an FpML 5.6 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
The creditDefaultSwapOption element defines the CDS option product in FpML.
The strike can be defined as spread, price or as the fixed rate.
|
|
|
7.7.1.1 OptionBase
|
|
The OptionBase type defines the schema structure associated with optionType: The type of option transaction. From a usage standpoint, put/call is the default option type, while payer/receiver indicator is used for options index credit default swaps as well as the swaptions. Straddle is used for the case of straddle strategy, which combines a call and a put with the same strike. The optionType is to be used if the underlyer does not carry any mention of the resulting trade direction as well as in the case of a straddle. The forward entry will be deprecated as part of the 5.0 version and the integration of the equity option into this schema. |
7.7.1.2 OptionBaseExtended
Incorporates features that are not underlyer-specific and cannot be integrated as part of the OptionBase because of backward compatibility reasons with the eqd schema.
|
|
|
7.7.1.2.1 Premium
The premium construct has a similar approach to the swaption (i.e. premium based upon a premium construct), but introduces a simplified payment that does not incorporate the settlement features. In order to make this construct forward applicable to the equity options, this new SimplePayment is then extended to incorporate some premium-specific concepts that currently exist as part of the eqd schema.
|
|
|
There are several places in the FpML 5.6 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.6 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.