Proposed Operational Procedures for 100/500, Standardized Effective Date and Standardized

Proposed Operational Procedures for 100/500, Standardized Effective Date and Standardized Coupons/Full Accruals:

General summary:the market has agreed to a new North American CDS contract (called 100/500) which aims to further standardize a number of variables. The proposal includes Investment Grade names trading on a 100 bps spread and quoted with a flat curve spread, High Yield names trading on a 500 bps spread and quoted as points up-front, a 60 day look back rolling Effective Date, standardized accruals, and auction hardwiring

100/500:

Trade Bookings:

Effective date: what value should firms put in the effective date field? It is suggested that firms continue to book Trade Date + 1 as their effective dates. DTCC will ignore this value for accrual purposes.

Scheduled Termination Date: will always match a quarterly roll date

Coupon: should be booked as the respective 100/500 coupon. This will still be confirmed as a percentage per annum, thus 1% or 5%.

First payment date:is always the next Quarterly Date; we will no longer observe a minimum 30 day window that if not met, would push the First Payment Date to the second Quarterly Date. Thisis a required field for DTCC, but your submission will be overwritten by DTCC to reflect the next Quarterly Date, similar to the process for index trades.

Calculation agent: no change currently. Firms should continue to operate in a standard fashion.

Restructuring: changed to "No Restructuring"

Accrual start:full coupons and no short or long stubs. Rather than starting on the Effective Date, accrual will begin on and include the last Quarterly Date (March 20, June 20, September 20 or December 20) on or preceding the Trade Date plus one calendar day.

Upfront fees: will be standard inclusion, payable on T+3 Business Days. A standard calculator will be available to firms to allow for consistent calculation of upfront fees to prevent breaks.

Historic North American Corporate trades:cannot be updated to 100/500 terms as part of this transition. A North American Corporate trade alsocannot change to a Standard North American Corporate trade upon Novation.

Settlement Method: Trades will be subject to Auction Methodology, with Fallback Settlement Method of Physical Settlement. The ISDA Credit Derivatives Determinations Committees and Auction Settlement Supplement to the 2003 Credit Derivatives Definitions applies to these trades, whether confirmed on paper or in DTCC, and will be incorporated into the DTCC Operating Procedures as well as the Matrix and longform template.

Confirmations:

Matrix: ISDA will publish an updated Matrix that includes a new "Standard North American Corporate" Transaction Type. This is the preferred means of confirming a 100/500 trade.

Master Confirmation Agreement (MCA): the Transaction Type that a firm submits to DTCC will be called "ISDA2003StandardCreditNorthAmerican" for 100/500 confirmed under a MCA. As this will be defined in the DTCC Operating Procedures, no changes are necessary to executed MCAs.

Paper Confirmations: if firms are unable to confirm in DTCC, the trade will need to be confirmed on either a Matrix Confirmation or longform confirmation. A standard longform template is under development to ensure that paper trades match the intended terms of the 100/500 trades. These may be Backloaded or Novated onto DTCC at a future point.

DTCC: proposed field rules as per the below

100-500

Proposed field rules

February 9, 2009

For 100/500 transactions, there are no new fields or changes to any of the various messaging templates. The only messaging/submission change required for these transactions is the use of a new set of valid values to represent a standard transaction. The FpML committee has agreed on the valid value for the matrix as StandardNorthAmericanCorporate and is expected to agree on a value of ISDA2003StandardCreditNorthAmericanfor MCA transactions.

While there are no messaging changes, the Deriv/SERV confirmation system will institute a number of new validations on the data submitted. These validations may result in the rejection of the submitted transaction with an appropriate error code. An example of this would be the submission of a standard 100/500 trade with a scheduled termination date that is not a quarterly roll date.

Other validations will result in the overwrite of a specific value in a field. An example of this would be the submission of a standard transaction with a payment frequency of 6 months. This value would be overwritten with a value of 3 months as all standard North American trades are to have a payment frequency of 3 months. All overwritten values can be found on the overwrite report found in the Reports section of the DTCC GUI.

The expected behavior for each of the fields, for both matrix and MCA transactions, is written below (Red text represents “overwritten” values by the confirmation system. Blue text represents rejection criteria):

GUI Field / Matrix Behavior / MCA Behavior
Master Document Transaction Type / StandardNorthAmericanCorporate (SNAC) / ISDA2003StandardCreditNorthAmerican(MCA SNAC)
Documentation Type / CreditDerivativesPhysicalSettlementMatrix / “blank”
Notional amount / From confirm submission / From confirm submission
Notional currency / Reject if not in the matrix / Process all currencies
Buyer/seller / From confirm submission / From confirm submission
Trade date / From confirm submission / From confirm submission
Scheduled term date / From confirm submission
Reject if not on a quarterly roll date / From confirm submission
Reject if not on a quarterly roll date
Effective date / Trade date + 1 / Trade date + 1
Coupon / 100/500 or rejected / 100/500 or rejected
RED code / From confirm submission / From conf
Reference Entity Name
(Underlying) / From Markit XML based on RED submission IF submitter is a REDS subscriber,
Otherwise from confirm submission / From Markit XML based on RED submission IF submitter is a REDS subscriber,
Otherwise from confirm submission
Reference Obligation / From Markit XML based on RED submission IF submitter is a REDS subscriber,
Otherwise from confirm submission / From Markit XML based on RED submission IF submitter is a REDS subscriber,
Otherwise from confirm submission
Payment Frequency / 3 months / 3 months
First Fixed Rate Payer Payment Date - FFRPPD / Next quarterly roll based on T+1 – Identical to index payments
(unadjusted date) / Next quarterly roll based on T+1 – Identical to index payments
(unadjusted date)
First Payment Period Accrual Start Date - FPPASD / Previous quarterly roll date back from FFRPPD
(Adjusted date is used) / Previous quarterly roll date back from FFRPPD
(Adjusted date is used)
Restructuring / Overwrite to “N” / Overwrite to “N”
Calculation agent / From confirm submission / Not applicable
Calculation agent city / From Matrix values / Not applicable
Master agreement type / ISDA / Not applicable
Master agreement date / From confirm submission / Not applicable
Master Documentation date / From confirm submission – expected to be blank. It is the “publication date” of the matrix which , when blank, is defaulted to most current matrix as of trade date / From confirm submission – the bilateral MCA date (or other standard date agreed)
Single/Initial Payment amount / From confirm submission
Note: when the buyer is paying the upfront, the proper FpML is the <singlepayment> tag. When the seller is paying, the proper FpML is the <initialpayment> tag. This is the same as BAU today. / From confirm submission
Note: when the buyer is paying the upfront, the proper FpML is the <singlepayment> tag. When the seller is paying, the proper FpML is the <initialpayment> tag. This is the same as BAU today.
Single/Initial payment currency / Reject if not in the matrix / Process all currencies
Single/initial payment date / T+3 based on currency holidays directly from the matrix on the single/initial payment currency / T+3 based on currency holidays in payment table as agreed by PWG on the single/initial payment currency
Single/Initial payment payer/receiver / From confirm submission
Blank when buyer is the payer – Populated when seller is the payer / From confirm submission
Independent amount/payer/receiver / From confirm submission / From confirm submission
Additional provisions Monoline / From confirm submission / Not applicable
Additional terms / From confirm submission / From confirm submission
Assignment rules / The same general rules will apply to the new RP submission (known as R1) and the EE submission. Certain fields (trade date, effective date, FFRPPD, FPPASD) can not be submitted on the new leg of an assignment and will be carried over from the underlying Warehouse record. / The same general rules will apply to the new RP submission (known as R1) and the EE submission. Certain fields (trade date, effective date, FFRPPD, FPPASD) can not be submitted on the new leg of an assignment and will be carried over from the underlying Warehouse record.
Assignment transformation rules / SNAC trades can be assigned only into new SNAC trades / MCA SNAC can be assigned into MCA SNAC or SNAC trades (MCA to matrix conversion rules would apply)