Revisions to the Markitserv Operating Procedures and the Warehouse Trust Operating Procedures – Credit Derivatives

IMPORTANT NOTICE

#: MS# 82 ; TIW# 109 Date: February 17, 2011 To: Distribution From: Legal Department Subject: Revisions to the MarkitSERV Operating Procedures and the Warehouse Trust Operating Procedures – Credit Derivatives

At the close of business (NY) on Friday, February 25, 2011, MarkitSERV and the Warehouse Trust will implement enhancements to DSMatch and the Trade Information Warehouse for Credit products (see Important Notices MS#81; TIW#108 dated February 16, 2011 for information regarding the enhancements. This notice refers to updates specific to the MarkitSERV and Warehouse Trust Operating Procedures. Capitalized terms used herein and not otherwise defined shall have those meanings referenced in the applicable Operating Procedures.

Beginning on February 28, 2011, firms may begin confirming single name CDS on European CMBS and RMBS and Fixed Recovery CDS transactions. The MarkitSERV and Warehouse Trust Operating Procedures have been updated to support these enhancements. See attached blacklines of MarkitSERV Appendix K (Single Reference Entity Credit Default Swap Incorporating the ISDA Physical Settlement Matrix) and Appendix L (Single Reference Entity Credit Default Swap on Mortgage-backed Security and Single Reference Entity Credit Default Swap on Loan) with updated Appendix L Field Parameters. See also attached blackline of the Warehouse Trust Trade Warehouse Appendix. . The enhancements referred to above are reflected on the attached documents and are effective upon implementation, unless otherwise noted. By submitting affected transactions to the applicable system, the User agrees to waive any applicable notice requirements relating to the changes.

Any questions or comments regarding this Important Notice or MarkitSERV in general should be directed to your account manager, [email protected] or to:

Credit Derivatives Product Management Simon Todd +44-203-367-0535 [email protected]

MarkitSERV DSMatch Trade Upload - Field Parameters

Matching CreditDefaultSwap CMBS ECMBS RMBS ERMBS LCDS ELCDS # Ref Data Field Cell Format Valid Entry ? Applicable Transaction Types CreditDefaultSwapShort CreditDefaultSwapIndex IndexTranche 1 A Comment Text * (i.e. the asterisk character) When an asterisk is present the entire No All Optional Optional Optional Optional Optional Optional Optional Optional Optional line is treated as a comment 2 B Activity Text New, Modify, Cancel, DK Yes All Required Required Required Required Required Required Required Required Required 3 C Transaction Type Text Trade, Backload, PartialTermination, Increase, Amendment, Yes All Required Required Required Required Required Required Required Required Required Assignment, Exit, Exercise 4 D Product Type Text CreditDefaultSwapShort or CreditDefaultSwapIndex or Yes All Required, must be "CreditDefaultSwapShort" Required, must be "CreditDefaultSwapIndex" Required, must be Required, must be "CreditDefaultSwapShort" Required, must be "CreditDefaultSwapShort" Required, must be "CreditDefaultSwapShort" Required, must be "CreditDefaultSwapShort" Required, must be "CreditDefaultSwapShort" Required, must be "CreditDefaultSwapShort" CreditDefaultSwapIndexTranche "CreditDefaultSwapIndexTranche" 5 E Originator ID Text A 1-20 Character Participant ID (e.g., 00006101) Yes All Required Required Required Required Required Required Required Required Required 6 F Trade Reference Number Text Up to 40 alphanumeric characters Contains the Originator's Trade No All Required Required Required Required Required Required Required Required Required Reference Number. When Activity is DK, this field contains the Counterparty's Trade Reference Number.

7 G Counterparty ID Text A 1-20 Character Participant ID (e.g., 00006101) Yes All Required Required Required Required Required Required Required Required Required 8 H Trade Date YYYY-MM-DD Any valid date. Yes Trade, Backload, Amendment, Assignment*, Required Required Required Required Required Required Required Required Required PartialTermination* 9 I Effective Date YYYY-MM-DD Any valid date. For a Transferee Assignment record, must equal Yes Trade, Backload, Amendment, Assignment*, Required Required Required Required Required Required Required Required Required Post Trade Effective Date (which is the Novation Date). PartialTermination*, Exercise

10 J Scheduled Term Date YYYY-MM-DD Any valid date. Yes Trade, Backload, Amendment, Assignment*, Required Required Required Required Required Required Required Required Required PartialTermination*, Exercise

11 K First Payment Date YYYY-MM-DD Any valid date. Yes Trade, Backload, Amendment, Assignment* Conditional; required when Fixed Rate is provided, Not Allowed Conditional; Optional when Initial Optional Optional Optional Optional Conditional; required when Fixed Rate is provided, Conditional; required when Fixed Rate is provided, (Remaining Party and Transferor records only) Optional in an Assignment, Not Allowed otherwise Payment Amount is provided, Optional in an Assignment, Not Allowed otherwise Optional in an Assignment, Not Allowed otherwise otherwise Required. Valid Value: Any valid date Valid Value: Any valid date Valid Value: Any valid date Valid Value: Any valid date Valid Value: Any valid date Valid Value: Any valid date Valid Value: The MM-DD portion of the First Payment Valid Value: Any valid date Date must be one of the values "03-20","06-20","09- 20" or "12-20" and must be at least 30 days after the specified Trade Date.

12 L Reference Obligation Text Any valid ISIN or CUSIP (up to 12 characters) Yes Trade, Backload, Amendment, Assignment*, Required Not Allowed Not Allowed Required Required Required Required Conditional; Required when Secured List Applicable Required PartialTermination*, Exercise equals "N", Otherwise Optional The Reference Obligation will be overwritten by DTCC when a valid 9 character Reference Entity Id is supplied.

13 M Reference Entity Name Text REDS Name Text or Alphanumeric Text up to 250 alphanumeric Yes Trade, Backload, Amendment, Assignment*, Required Required Required Required Required Required Required Required Required characters PartialTermination*, Exercise

The Reference Entity Name will be overwritten by DTCC when a valid 6 or 9 character Reference Entity Id is supplied.

14 N Reference Entity ID Text REDS ID ( 6 or 9 characters) Yes when Trade, Backload, Amendment, Assignment*, Required Required Optional Optional Optional Optional Optional Optional present PartialTermination*, Exercise Will be used to overwrite Reference Entity Name and Reference Obligation if specified.

15 O Master Document Transaction Text Represents the "Master Confirmation Transaction Type" for a Single- Yes Trade, Backload, Amendment, Assignment* Required. Required Required Required Required Required Required Required Required Type Name or Index trade that uses the Master Confirm form of documentation. For the Remaining Party record of an Assignment, see Valid Value: Must be 2003CreditIndex for an Index Master Valid Value: Must be a valid value for Valid Value: must be the value Valid Value: must be the value "EuropeanCMBS" Valid Value: Must be the value "StandardTermsSupplement" Valid Value: Must be the value "EuropeanRMBS" Valid Value: Must be the value Valid Value: Must be the value also New Master Document Transaction Type. Confirm Trade . Otherwise, must be a valid value for an Index an Index Tranche trade. See "Valid "StandardTermsSupplement" "StandardTermsSupplement" "CDSonLeveragedLoans" Represents the "Transaction Type" for a Single-Name trade that trade that uses the Standard Terms Supplement form of Values" tab for valid values for this field uses the Matrix form of documentation. Valid Value: See "Valid Values" tab for valid values for documentation. See "Valid Values" tab for valid values for this this field field Represents the "Standard Terms Supplement Type" that uses the Standard Terms form of documentation.

16 P Master Document Date YYYY-MM-DD Any valid date. Yes when Trade, Backload, Amendment, Assignment* Conditional; required when the Documentation Type field Required for Trade, Amendment, and Assignment. Required for Trade, Amendment, and Required Required Required Required Required Required present is blank. Assignment. Represents the "Master Confirmation Date" for a Single-Name or For the Remaining Party record of an Assignment, see also Index trade that uses the Master Confirm form of documentation. Optional for Trade, Amendment, and Assignment when New Master Document Date. For the Remaining Party record of an the Documentation Type field has a value of Assignment, see also New Master Represents the Matrix Publication Date for a Single-Name trade that CreditDerivativesPhysicalSettlementMatrix. Document Date. uses the Matrix form of documentation. For the Remaining Party record of an Assignment, see Represents the Standard Terms Supplement Publication Date for also New Master Document Date. an Index or Index Tranche trade that uses the Standard Terms form of documentation. Represents the Publication Date of a Standard Terms Supplement for MBS and LCDS

17 Q Fixed Rate Payer (Buyer)/ Text A 1-20 Character Participant ID (e.g., 00006101) Yes Trade, Backload, Amendment, Assignment*, Required Required Required Required Required Required Required Required Required Swaption Buyer PartialTermination*, Exercise

18 R Float Rate Payer (Seller)/ Text A 1-20 Character Participant ID (e.g., 00006101) Yes Trade, Backload, Amendment, Assignment*, Required Required Required Required Required Required Required Required Required Swaption Seller PartialTermination*, Exercise 19 S Fixed Rate (per annum) Number with 0 to 8 Enter 1.50000000 for 1.5% Do not enter % sign in cell Yes when Trade, Backload, Amendment, Assignment*, Conditional; required when Single Payment is not Conditional; Optional when Initial Payment Amount is provided, Conditional; Optional when Initial Conditional; required when Single Payment is not Conditional; required when Single Payment is not Conditional; required when Single Payment is not provided, Conditional; required when Single Payment is not provided, Conditional; required when Single Payment is not provided, Conditional; required when Single Payment Amount is decimal places present PartialTermination*, Exercise provided, Optional when Single Payment is provided. otherwise Required. Payment Amount is provided, provided, Optional when Single Payment is provided. provided, Optional when Single Payment is provided. Optional when Single Payment is provided. Optional when Single Payment is provided. Optional when Single Payment is provided. not provided, Optional when Single Payment Amount otherwise Required. is provided. 20 T Float Rate Amount Number with 0 to 5 Notional Amount. For a Transferee Assignment record, must equal Yes Trade, Backload, Amendment, Assignment*, Required Required Required Required Required Required Required Required Required decimal places Affected Notional Amount (which is the Novated Amount). PartialTermination*, Exercise

21 U Float Rate Currency Text Valid 3-character currency code. Yes Trade, Backload, Amendment, Assignment*, Required Required Required Required; Required; Required Required Required Required PartialTermination*, Exercise

22 V Payment Frequency (Months) Number with 0 decimal Between 1 and 12 Yes Trade, Backload, Amendment, Assignment* Conditional; required when Fixed Rate is provided, Not Allowed Not Allowed Conditional; required when Fixed Rate is provided, Conditional; required when Fixed Rate is provided, Conditional; required when Fixed Rate is provided, otherwise Conditional; required when Fixed Rate is provided, otherwise Conditional; required when Fixed Rate is provided, Conditional; required when Fixed Rate is provided, places otherwise Not Allowed otherwise Not Allowed otherwise Not Allowed Not Allowed Not Allowed otherwise Not Allowed otherwise Not Allowed

Valid Value: must be '3' indicating 3 months.

23 W Restructuring Events (Y/N) Text For a Master Confirm trade: Y or N only. Y means Applicable and N Yes when Trade, Backload, Amendment, Assignment* Optional Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed or blank mean Not Applicable. present For the Remaining Party record of an Assignment, see For a Matrix trade where the Master Document Transaction Type is also New Restructuring Events (Y/N). NorthAmericanCorporate: Y or N only. Y means Applicable and N or blank mean Not Applicable.

For a Matrix trade where the Master Document Transaction Type is not NorthAmericanCorporate: The Matrix sets Restructuring Events to always be Applicable. Therefore, any entries in this field will be ignored.

24 X Additional Terms Text Free-form text up to 255 characters Yes when Trade, Backload, Amendment, Assignment* Optional Optional Optional Optional Optional Optional Optional Optional Optional present For the Remaining Party record of an Assignment, see For the Remaining Party record of an Assignment, see also For the Remaining Party record of an For the Remaining Party record of an Assignment, For the Remaining Party record of an Assignment, For the Remaining Party record of an Assignment, see also For the Remaining Party record of an Assignment, see also For the Remaining Party record of an Assignment, see For the Remaining Party record of an Assignment, also New Additional Terms. New Additional Terms. Assignment, see also New Additional see also New Additional Terms. see also New Additional Terms. New Additional Terms. New Additional Terms. also New Additional Terms. see also New Additional Terms. Terms. For a Single-Name or Index trade that uses the Master For a Single-Name or Index trade that uses the Master Confirm For a Single-Name or Index trade that uses the For a Single-Name or Index trade that uses the For a Single-Name or Index trade that uses the Master Confirm For a Single-Name or Index trade that uses the Master Confirm For a Single-Name or Index trade that uses the Master For a Single-Name or Index trade that uses the Confirm form of documentation: Free-form text up to form of documentation: Free-form text up to 255 characters. For an Index or Index Tranche trade Master Confirm form of documentation: Free-form Master Confirm form of documentation: Free-form form of documentation: Free-form text up to 255 characters. form of documentation: Free-form text up to 255 characters. Confirm form of documentation: Free-form text up to 255 Master Confirm form of documentation: Free-form 255 characters. "Y" or free-form text means Applicable "Y" or free-form text means Applicable and "N" or blank mean that uses the Standard Terms form of text up to 255 characters. "Y" or free-form text means text up to 255 characters. "Y" or free-form text means "Y" or free-form text means Applicable and "N" or blank mean "Y" or free-form text means Applicable and "N" or blank mean characters. "Y" or free-form text means Applicable and "N" text up to 255 characters. "Y" or free-form text means and "N" or blank mean Not Applicable. Not Applicable. documentation: free-form text up to Applicable and "N" or blank mean Not Applicable. Applicable and "N" or blank mean Not Applicable. Not Applicable. Not Applicable. or blank mean Not Applicable. Applicable and "N" or blank mean Not Applicable. 255 characters (Y and N do not have For a Single-Name trade that uses the Matrix form of For an Index or Index Tranche trade that uses the Standard any special meaning. Leave the field For a Single-Name trade that uses the Matrix form of For a Single-Name trade that uses the Matrix form of For a Single-Name trade that uses the Matrix form of For a Single-Name trade that uses the Matrix form of For a Single-Name trade that uses the Matrix form of For a Single-Name trade that uses the Matrix form of documentation: free-form text up to 255 characters (Y Terms form of documentation: free-form text up to 255 blank if there are no additional terms). documentation: free-form text up to 255 characters (Y documentation: free-form text up to 255 characters (Y documentation: free-form text up to 255 characters (Y and N documentation: free-form text up to 255 characters (Y and N documentation: free-form text up to 255 characters (Y and documentation: free-form text up to 255 characters (Y and N do not have any special meaning. Leave the field characters (Y and N do not have any special meaning. Leave and N do not have any special meaning. Leave the and N do not have any special meaning. Leave the do not have any special meaning. Leave the field blank if there do not have any special meaning. Leave the field blank if there N do not have any special meaning. Leave the field blank if and N do not have any special meaning. Leave the blank if there are no additional terms). the field blank if there are no additional terms). field blank if there are no additional terms). field blank if there are no additional terms). are no additional terms). are no additional terms). there are no additional terms). field blank if there are no additional terms).

25 Y Independent Amount Payment Number with 0 to 5 Enter 1.50000 for 1.5% Do not enter % sign in cell Yes when Trade, Backload, Amendment, Assignment* Optional Optional Optional Optional Optional Optional Optional Optional Optional Percent decimal places present 26 Z Independent Amount Payer Text A 1-20 Character Participant ID (e.g., 00006101) Yes when Trade, Backload, Amendment, Assignment* Conditional; required when Independent Amount Conditional; required when Independent Amount Payment Conditional; required when Conditional; Required when Independent Amount Conditional; Required when Independent Amount Conditional; Required when Independent Amount Payment Conditional; Required when Independent Amount Payment Conditional; Required when Independent Amount Payment Conditional; Required when Independent Amount present Payment Percent is present; Not Allowed otherwise Percent is present; Not Allowed otherwise Independent Amount Payment Percent Payment Percent is present; Otherwise Not Allowed Payment Percent is present; Otherwise Not Allowed Percent is present; Otherwise Not Allowed Percent is present; Otherwise Not Allowed Percent is present; Otherwise Not Allowed Payment Percent is present; Otherwise Not Allowed is present; Not Allowed otherwise

27 AA Independent Amount Receiver Text A 1-20 Character Participant ID (e.g., 00006101) Yes when Trade, Backload, Amendment, Assignment* Conditional; required when Independent Amount Conditional; required when Independent Amount Payment Conditional; required when Conditional; Required when Independent Amount Conditional; Required when Independent Amount Conditional; Required when Independent Amount Payment Conditional; Required when Independent Amount Payment Conditional; Required when Independent Amount Payment Conditional; Required when Independent Amount present Payment Percent is present; Not Allowed otherwise Percent is present; Not Allowed otherwise Independent Amount Payment Percent Payment Percent is present; Otherwise Not Allowed Payment Percent is present; Otherwise Not Allowed Percent is present; Otherwise Not Allowed Percent is present; Otherwise Not Allowed Percent is present; Otherwise Not Allowed Payment Percent is present; Otherwise Not Allowed is present; Not Allowed otherwise

28 AB Single Payment Amount / Number with 0 to 5 Single Yes when Trade, Backload, Amendment, Assignment* Conditional; required when Fixed Rate is not provided, Not Allowed Not Allowed Conditional; Required when Fixed Rate is not Conditional; Required when Fixed Rate is not Conditional; Required when Fixed Rate is not provided, Conditional; Required when Fixed Rate is not provided, Conditional; Required when Fixed Rate is not provided, Conditional; Required when Fixed Rate is not Premium Payment Amount decimal places present (Remaining Party and Transferor records only), Optional when Fixed Rate is provided; required to provided, Optional when Fixed Rate is provided; provided, Optional when Fixed Rate is provided; Optional when Fixed Rate is provided; Required to identify the Optional when Fixed Rate is provided; Required to identify the Optional when Fixed Rate is provided; Required to identify provided, Optional when Fixed Rate is provided.; PartialTermination*, Exercise identify the direction for Float Rate Payer (Seller) is a Required to identify the direction for Float Rate Payer Required to identify the direction for Float Rate Payer direction for Float Rate Payer (Seller) is a 'Single Payment direction for Float Rate Payer (Seller) is a 'Single Payment the direction for Float Rate Payer (Seller) is a 'Single Direction for the up-front amount is defined by Single 'Single Payment Payer' of the upfront payment (Seller) is a 'Single Payment Payer' of the upfront (Seller) is a 'Single Payment Payer' of the upfront Payer' of the upfront payment Payer' of the upfront payment Payment Payer' of the upfront payment / Initial Payer and Receiver fields. payment payment 29 AC Single Payment Currency / Text Valid 3-character currency code. Yes when Trade, Backload, Amendment, Assignment* Conditional; required when Single Payment is provided; Not Allowed Not Allowed Conditional; Required when Single Payment is Conditional; Required when Single Payment is Conditional; Required when Single Payment is provided; Conditional; Required when Single Payment is provided; Conditional; Required when Single Payment is provided; Conditional; Required when Single Payment Amount Premium Payment Currency present (Remaining Party and Transferor records only), required to identify the direction for Float Rate Payer provided; Required to identify the direction for Float provided; Required to identify the direction for Float Required to identify the direction for Float Rate Payer (Seller) Required to identify the direction for Float Rate Payer (Seller) Required to identify the direction for Float Rate Payer is provided; Not Allowed otherwise PartialTermination*, Exercise (Seller) is a 'Single Payment Payer' of the upfront Rate Payer (Seller) is a 'Single Payment Payer' of the Rate Payer (Seller) is a 'Single Payment Payer' of the is a 'Single Payment Payer' of the upfront payment; Not is a 'Single Payment Payer' of the upfront payment; Not (Seller) is a 'Single Payment Payer' of the upfront payment; Not Allowed otherwise upfront payment; Not Allowed otherwise upfront payment; Not Allowed otherwise Allowed otherwise Allowed otherwise payment; Not Allowed otherwise

Matching CreditDefaultSwap CMBS ECMBS RMBS ERMBS LCDS ELCDS # Ref Data Field Cell Format Valid Entry ? Applicable Transaction Types CreditDefaultSwapShort CreditDefaultSwapIndex IndexTranche 30 AD Single Payment Date / YYYY-MM-DD Any valid date. Yes when Trade, Backload, Amendment, Assignment* Conditional; required when Single Payment is provided. Not Allowed Not Allowed Conditional; Required when Single Payment is Conditional; Required when Single Payment is Conditional; Required when Single Payment is provided. Conditional; Required when Single Payment is provided. Conditional; Required when Single Payment is provided. Conditional; Required when Single Payment Amount Premium Payment Date present (Remaining Party and Transferor records only), Required to identify the direction for Float Rate Payer provided. provided. Required to identify the direction for Float Rate Payer (Seller) Required to identify the direction for Float Rate Payer (Seller) Required to identify the direction for Float Rate Payer is provided; Not Allowed otherwise PartialTermination*, Exercise (Seller) is a 'Single Payment Payer' of the upfront Required to identify the direction for Float Rate Payer Required to identify the direction for Float Rate Payer is a 'Single Payment Payer' of the upfront payment; Not is a 'Single Payment Payer' of the upfront payment; Not (Seller) is a 'Single Payment Payer' of the upfront payment; Not Allowed otherwise . (Seller) is a 'Single Payment Payer' of the upfront (Seller) is a 'Single Payment Payer' of the upfront Allowed otherwise . Allowed otherwise . payment; Not Allowed otherwise . payment; Not Allowed otherwise . payment; Not Allowed otherwise .

31 AE Calculation Agent Business Text 4-Character ISDA Business Center code Yes Trade, Backload, Amendment, Assignment* Conditional; Not Allowed if Master Document Conditional, Optional when Documentation Type has a value of Optional Required Required Required Required Not Allowed Not Allowed Center Transaction Type is ISDA2003CreditNorthAmerican or StandardTermsSupplement. Otherwise, Not Allowed. ISDA2003CreditEuropean. Required when Master For the Remaining Party record of an Document Transaction Type is any other value. For the Remaining Party record of an Assignment, see also Assignment, see also New Calculation (Optional when the Documentation Type field has a value New Calculation Agent Business Center. Agent Business Center. of CreditDerivativesPhysicalSettlementMatrix).

For the Remaining Party record of an Assignment, see also New Calculation Agent Business Center.

32 AF Excluded Deliverables Text Alphanumeric Text up to 255 alphanumeric characters. Yes when Trade, Backload, Amendment, Assignment* Conditional; Optional when Master Document Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed present Transaction Type contains one of the following values: Only used for a Sovereign trade done under the Master Confirm ISDA2004CreditSovereignAsia, form of documentation. For a Sovereign trade done under the Matrix ISDA2004CreditSovereignEmergingEuropeanAndMiddl form of documentation, use the free-form Additional Terms field. eEastern, ISDA2004CreditSovereignJapan, ISDA2004CreditSovereignLatinAmerican, or ISDA2004CreditSovereignWesternEuropean. Otherwise Not Allowed.

For the Remaining Party record of an Assignment, see also New Excluded Deliverables.

33 AG Initial Payment Amount Number with 0 to 5 Initial Payment Amount Yes when Trade, Backload, Amendment, Assignment* Not Allowed Optional Optional Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed decimal places present (Remaining Party and Transferor records only)

34 AH Initial Payment Currency Text Valid 3-character currency code. Yes when Trade, Backload, Amendment, Assignment* Not Allowed Conditional; required when Initial Payment Amount is present; Conditional; required when Initial Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed present (Remaining Party and Transferor records only) Not Allowed otherwise Payment Amount is present; Not Allowed otherwise 35 AI Single / Initial Payment Amount Text A 1-20 Character Participant ID (e.g., 00006101) Yes when Trade, Backload, Amendment, Assignment* Conditional; required to identify the direction for Float Conditional; required when Initial Payment Amount is present; Conditional; required when Initial Conditional; Required to identify the direction for Conditional; Required to identify the direction for Conditional; Required to identify the direction for Float Rate Conditional; Required to identify the direction for Float Rate Conditional; Required to identify the direction for Float Conditional; required when Single Payment Amount is Payer present (Remaining Party and Transferor records only) Rate Payer (Seller) of the upfront payment; Not Allowed Not Allowed otherwise Payment Amount is present; Not Float Rate Payer (Seller) of the upfront payment; Not Float Rate Payer (Seller) of the upfront payment; Not Payer (Seller) of the upfront payment; Not Allowed otherwise . Payer (Seller) of the upfront payment; Not Allowed otherwise . Rate Payer (Seller) of the upfront payment; Not Allowed present; Not Allowed otherwise otherwise . Allowed otherwise Allowed otherwise . Allowed otherwise . otherwise .

36 AJ Single / Initial Payment Amount Text A 1-20 Character Participant ID (e.g., 00006101) Yes when Trade, Backload, Amendment, Assignment* Conditional; required to identify the direction for Fixed Conditional; required when Initial Payment Amount is present; Conditional; required when Initial Conditional; Required to identify the direction for Conditional; Required to identify the direction for Conditional; Required to identify the direction for Fixed Rate Conditional; Required to identify the direction for Fixed Rate Conditional; Required to identify the direction for Fixed Conditional; required when Single Payment Amount is Receiver present (Remaining Party and Transferor records only) Rate Payer (Buyer) of the upfront payment; Not Allowed Not Allowed otherwise Payment Amount is present; Not Fixed Rate Payer (Buyer) of the upfront payment; Not Fixed Rate Payer (Buyer) of the upfront payment; Not Payer (Buyer) of the upfront payment; Not Allowed otherwise . Payer (Buyer) of the upfront payment; Not Allowed otherwise . Rate Payer (Buyer) of the upfront payment; Not Allowed present; Not Allowed otherwise otherwise . Allowed otherwise Allowed otherwise . Allowed otherwise . otherwise .

37 AK Annex Date YYYY-MM-DD Any valid date. Yes when Trade, Backload, Amendment, Assignment* Conditional; Optional when Documentation Type is blank. Optional Optional Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed present Not allowed when Documentation Type has a value of CreditDerivativesPhysicalSettlementMatrix.

38 AL Trade Reference Number Text Up to 16 alphanumeric characters No PartialTermination*, Exercise, Increase, Required Required Required Required Required Required Required Required Required Supplement Amendment or Assignment 39 AM Post Trade Transaction Date YYYY-MM-DD Any valid date. 'Termination Trade Date' for a Partial Termination. Yes PartialTermination*, Exercise, Increase, Required Required Required Required Required Required Required Required Required 'Increase Trade Date for an Increase. 'Amendment Trade Date' for Amendment or Assignment an Amendment. 'Exercise Date' for an Exercise. "New Transaction Trade Date" for the Remaining Party for an Assignment.

40 AN Post Trade Effective Date YYYY-MM-DD Any valid date. 'Termination Effective Date' for a Partial Termination. Yes PartialTermination*, Exercise, Increase, Required Required Required Required Required Required Required Required Required 'Increase Effective Date for an Increase. 'Novation Date' for an Amendment or Assignment Assignment. 'Amendment Effective Date' for an Amendment. 'Exercise Effective Date' for an Exercise.

41 AO Affected Notional Amount Number with 0 to 5 'Novated Amount' for an Assignment. 'Increase in Notional Amount' Yes PartialTermination*, Exercise, Increase or Required Required Required Required Required Required Required Required Required decimal places for an Increase. 'Decrease in Notional Amount' for a Partial Assignment Termination. 'Exercised Amount' for an Exercise.

42 AP Affected Notional Currency Text Valid 3-character currency code. 'Novated Amount Currency' for an Yes PartialTermination*, Exercise, Increase or Required when Affected Notional is provided. Conditional, Required when Affected Notional is provided. Conditional, Required when Affected Conditional, Required when Affected Notional is Conditional, Required when Affected Notional is Conditional, Required when Affected Notional is provided. Conditional, Required when Affected Notional is provided. Conditional, Required when Affected Notional is provided. Conditional, Required when Affected Notional is Assignment. 'Increase in Notional Currency' for an Increase. Assignment Otherwise it is Optional. Notional is provided. Otherwise it is provided. Otherwise it is Optional. provided. Otherwise it is Optional. Otherwise it is Optional. Otherwise it is Optional. Otherwise it is Optional. provided. Otherwise it is Optional. 'Decrease in Notional Currency' for a Partial Termination. Optional. 'Exercised Amount Currency' for an Exercise.

43 AQ Outstanding Notional Amount Number with 0 to 5 'Outstanding Notional Amount' after the decrease for a Partial Yes PartialTermination*, Exercise or Increase Required Required Required Required Required Required Required Required Required decimal places Termination. 'Outstanding Notional Amount' after the increase for an Increase. 'Outstanding Notional Amount' for an Exercise.

44 AR Outstanding Notional Currency Text Valid 3-character currency code. Yes PartialTermination*, Exercise or Increase Required when Outstanding Notional Amount is provided Conditional, Required when Outstanding Notional Amount is Conditional, Required when Conditional, Required when Outstanding Notional Conditional, Required when Outstanding Notional Conditional, Required when Outstanding Notional Amount is Conditional, Required when Outstanding Notional Amount is Conditional, Required when Outstanding Notional Amount Conditional, Required when Outstanding Notional provided. . Otherwise it is Optional. Outstanding Notional Amount is Amount is provided. Otherwise it is Optional. Amount is provided. Otherwise it is Optional. provided. Otherwise it is Optional. provided. Otherwise it is Optional. is provided. Otherwise it is Optional. Amount is provided. Otherwise it is Optional. provided. Otherwise it is Optional. 45 AS Post Trade Payment Amount Number with 0 to 5 Payment by one of the parties for the right to transact this post-trade Yes when PartialTermination*, Exercise, Increase, Optional Optional Optional Optional Optional Optional Optional Optional Optional decimal places transaction. 'Assignment Payment Amount' for an Assignment. present Amendment or Assignment 'Increase Payment Amount' for an Increase. 'Termination Payment Amount' for a Partial Termination. 'Amendment Payment Amount' for an Amendment. 'Exercise Payment Amount' for an Exercise.

46 AT Post Trade Payment Currency Text Valid 3-character currency code. 'Assignment Payment Currency' Yes when PartialTermination*, Exercise, Increase, Required when Post Trade Payment Amount is provided Conditional, Required when Post Trade Payment Amount is Conditiohnal, Required when Post Required when Post Trade Payment Amount is Required when Post Trade Payment Amount is Required when Post Trade Payment Amount is provided Required when Post Trade Payment Amount is provided Required when Post Trade Payment Amount is provided Required when Post Trade Payment Amount is for an Assignment. 'Increase Payment Currency' for an Increase. present Amendment or Assignment provided. Otherwise it is Optional. Trade Payment Amount is provided. provided provided provided 'Termination Payment Currency' for a Partial Termination. Otherwise it is Optional. 'Amendment Payment Currency' for an Amendment. 'Exercise Payment Currency' for an Exercise.

47 AU Post Trade Payment Date YYYY-MM-DD Any valid date. 'Assignment Payment Date' for an Assignment. Yes when PartialTermination*, Exercise, Increase, Required when Post Trade Payment Amount is provided Conditional, Required when Post Trade Payment Amount is Conditional, Required when Post Required when Post Trade Payment Amount is Required when Post Trade Payment Amount is Required when Post Trade Payment Amount is provided Required when Post Trade Payment Amount is provided Required when Post Trade Payment Amount is provided Required when Post Trade Payment Amount is 'Increase Payment Date' for an Increase. 'Termination Payment present Amendment or Assignment provided. Otherwise it is Optional. Trade Payment Amount is provided. provided provided provided Date' for a Partial Termination. 'Amendment Payment Date' for an Otherwise it is Optional. Amendment. 'Exercise Payment Date' for an Exercise.

48 AV Post Trade Payment Payer Text A 1-20 Character Participant ID (e.g., 00006101). 'Assignment Yes when PartialTermination*, Exercise, Increase, Required when Post Trade Payment Amount is provided Conditional, Required when Post Trade Payment Amount is Conditional, Required when Post Required when Post Trade Payment Amount is Required when Post Trade Payment Amount is Required when Post Trade Payment Amount is provided Required when Post Trade Payment Amount is provided Required when Post Trade Payment Amount is provided Required when Post Trade Payment Amount is Payment Payer' for an Assignment. 'Increase Payment Payer' for an present Amendment or Assignment provided. Otherwise it is Optional. Trade Payment Amount is provided. . provided provided provided Increase. 'Termination Payment Payer' for a Partial Termination. Otherwise it is Optional. 'Amendment Payment Payer' for an Amendment. 'Exercise Payment Payer' for an Exercise. 49 AW Post Trade Payment Receiver Text A 1-20 Character Participant ID (e.g., 00006101). 'Assignment Yes when PartialTermination*, Exercise, Increase, Required when Post Trade Payment Amount is provided Conditional, Required when Post Trade Payment Amount is Conditional, Required when Post Required when Post Trade Payment Amount is Required when Post Trade Payment Amount is Required when Post Trade Payment Amount is provided Required when Post Trade Payment Amount is provided Required when Post Trade Payment Amount is provided Required when Post Trade Payment Amount is Payment Receiver' for an Assignment. 'Increase Payment Receiver' present Amendment or Assignment provided. Otherwise it is Optional. Trade Payment Amount is provided. provided provided provided for an Increase. 'Termination Payment Receiver' for a Partial Otherwise it is Optional. Termination. 'Amendment Payment Receiver' for an Amendment. 'Exercise Payment Receiver' for an Exercise.

50 AX Full First Calculation Period Text Y or N ONLY Yes when Assignment Optional (omission is equivalent to specifying 'Y' ) Optional (omission is equivalent to specifying 'Y' ) Optional (omission is equivalent to Optional (omission is equivalent to specifying 'Y' ) Optional (omission is equivalent to specifying 'Y' ) Optional (omission is equivalent to specifying 'Y' ) Optional (omission is equivalent to specifying 'Y' ) Optional (omission is equivalent to specifying 'Y' ) Optional (omission is equivalent to specifying 'Y' ) Applicable (Y/N) present specifying 'Y' ) 51 AY Transferee Text A 1-20 Character Participant ID (e.g., 00006101) Yes Assignment Required Required Required Required Required Required Required Required Required 52 AZ Transferor Text A 1-20 Character Participant ID (e.g., 00006101) Yes Assignment Required Required Required Required Required Required Required Required Required 53 BA Remaining Party Text A 1-20 Character Participant ID (e.g., 00006101) Yes Assignment Required Required Required Required Required Required Required Required Required 54 BB Remaining Party Two Text A 1-20 Character Participant ID (e.g., 00006101) Yes when Assignment (Remaining Party record only) Optional Optional Optional Optional Optional Optional Optional Optional Optional present 55 BC New Trade Reference Number Text Up to 40 alphanumeric characters. Represents the Remaining No Assignment (Remaining Party record only) Required for a Remaining Party 'Partial Assignment' Conditional, Required for a Remaining Party 'Partial Conditional, Required for a Remaining Required for a Remaining Party 'Partial Assignment' Required for a Remaining Party 'Partial Assignment' Required for a Remaining Party 'Partial Assignment' record; Required for a Remaining Party 'Partial Assignment' record; Required for a Remaining Party 'Partial Assignment' Required for a Remaining Party 'Partial Assignment' Party's New Trade Reference Number for the 'New Transaction' with record; Optional for a Remaining Party 'Full Assignment' Assignment' record; Optional for a Remaining Party 'Full Party 'Partial Assignment' record; record; Optional for a Remaining Party 'Full record; Optional for a Remaining Party 'Full Optional for a Remaining Party 'Full Assignment' record Optional for a Remaining Party 'Full Assignment' record record; Optional for a Remaining Party 'Full Assignment' record; Optional for a Remaining Party 'Full the Transferee. record Assignment' record Optional for a Remaining Party 'Full Assignment' record Assignment' record record Assignment' record Assignment' record

56 BD New Master Document Date YYYY-MM-DD Any valid date. Yes Assignment (Remaining Party record only) Conditional; Required Required Optional Optional Optional Optional Optional Optional

Represents the Remaining Party's New Master Confirmation Date MCA>MCA* or Matrix>MCA*: Required. with the Transferee for a Single-Name or Index trade that uses the Master Confirm form of documentation. Matrix>Matrix* or MCA>Matrix*: Optional.

Represents the Remaining Party's New Matrix Publication Date with the Transferee for a Single-Name trade that uses the Matrix form of documentation.

Represents the Remaining Party's New Standard Terms Supplement Publication Date with the Transferee for an Index or Index Tranche trade that uses the Standard Terms form of documentation.

57 BE New Independent Amount Number with 0 to 5 Enter 1.50000 for 1.5% Do not enter % sign in cell. Represents Yes when Assignment (Remaining Party record only) Optional Optional Optional Optional Optional Optional Optional Optional Optional Payment Percent decimal places the Remaining Party's New Independent Amount Payment Percent present with the Transferee.

Matching CreditDefaultSwap CMBS ECMBS RMBS ERMBS LCDS ELCDS # Ref Data Field Cell Format Valid Entry ? Applicable Transaction Types CreditDefaultSwapShort CreditDefaultSwapIndex IndexTranche 58 BF New Independent Amount Text A 1-20 Character Participant ID (e.g., 00006101). Represents the Yes when Assignment (Remaining Party record only) Required when New Independent Amount Payment Required when New Independent Amount Payment Percent is Required when New Independent Conditional; Required when New Independent Conditional; Required when New Independent Conditional; Required when New Independent Amount Conditional; Required when New Independent Amount Conditional; Required when New Independent Amount Conditional; Required when New Independent Payer Payer of the Remaining Party's New Independent Amount Payment present Percent is present; Not Allowed otherwise present; Not Allowed otherwise Amount Payment Percent is present; Amount Payment Percent is present; Otherwise Not Amount Payment Percent is present; Otherwise Not Payment Percent is present; Otherwise Not Allowed Payment Percent is present; Otherwise Not Allowed Payment Percent is present; Otherwise Not Allowed Amount Payment Percent is present; Otherwise Not Percent with the Transferee. Not Allowed otherwise Allowed Allowed Allowed 59 BG New Independent Amount Text A 1-20 Character Participant ID (e.g., 00006101). Represents the Yes when Assignment (Remaining Party record only) Required when New Independent Amount Payment Required when New Independent Amount Payment Percent is Required when New Independent Conditional; Required when New Independent Conditional; Required when New Independent Conditional; Required when New Independent Amount Conditional; Required when New Independent Amount Conditional; Required when New Independent Amount Conditional; Required when New Independent Receiver Receiver of the Remaining Party's New Independent Amount present Percent is present; Not Allowed otherwise present; Not Allowed otherwise Amount Payment Percent is present; Amount Payment Percent is present; Otherwise Not Amount Payment Percent is present; Otherwise Not Payment Percent is present; Otherwise Not Allowed Payment Percent is present; Otherwise Not Allowed Payment Percent is present; Otherwise Not Allowed Amount Payment Percent is present; Otherwise Not Payment Percent with the Transferee. Not Allowed otherwise Allowed Allowed Allowed 60 BH DK Reason Text Up to 255 alphanumeric characters No All Optional when Activity is "DK"; Not Allowed otherwise Optional when Activity is "DK"; Not Allowed otherwise Optional when Activity is "DK"; Not Optional when Activity is "DK"; Not Allowed otherwise Optional when Activity is "DK"; Not Allowed otherwise Optional when Activity is "DK"; Not Allowed otherwise Optional when Activity is "DK"; Not Allowed otherwise Optional when Activity is "DK"; Not Allowed otherwise Optional when Activity is "DK"; Not Allowed otherwise Allowed otherwise 61 BI Exit Message Text "1" (Novation Outside DTCC), "2" (Partial Termination Outside Yes Exit Required when Transaction Type is Exit; Not Allowed Required when Transaction Type is Exit; Not Allowed Required when Transaction Type is Required when Transaction Type is Exit; Not Allowed Required when Transaction Type is Exit; Not Allowed Required when Transaction Type is Exit; Not Allowed Required when Transaction Type is Exit; Not Allowed Required when Transaction Type is Exit; Not Allowed Required when Transaction Type is Exit; Not Allowed DTCC), "3" (Additional Documents Outside DTCC) , "4" (Other) or otherwise otherwise Exit; Not Allowed otherwise otherwise otherwise otherwise otherwise otherwise otherwise "7" (Termination for Clearing) 62 BJ Exit Additional Message Text Up to 255 alphanumeric characters No Exit Optional when Transaction Type is Exit; Not Allowed Optional when Transaction Type is Exit; Not Allowed otherwise Optional when Transaction Type is Optional when Transaction Type is Exit; Not Allowed Optional when Transaction Type is Exit; Not Allowed Optional when Transaction Type is Exit; Not Allowed otherwise Optional when Transaction Type is Exit; Not Allowed otherwise Optional when Transaction Type is Exit; Not Allowed Optional when Transaction Type is Exit; Not Allowed otherwise Exit; Not Allowed otherwise otherwise otherwise otherwise otherwise 63 BK Block Reference Number Text Up to 40 characters No Allocation Not Applicable Not Applicable Not Applicable Not Applicable Not Applicable Not Applicable Not Applicable Not Applicable Not Applicable 64 BL Block Originator ID Text A 1-20 Character Participant ID (e.g., 00006101). No Allocation Not Applicable Not Applicable Not Applicable Not Applicable Not Applicable Not Applicable Not Applicable Not Applicable Not Applicable 65 BM New Annex Date YYYY-MM-DD Any valid date. Represents the Remaining Party's New Annex Date Yes when Assignment (Remaining Party record only) Conditional; Optional Optional Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed with the Transferee. present MCA>MCA* or Matrix>MCA*: Optional.

Matrix>Matrix* or MCA>Matrix*: Not allowed.

66 BN Documentation Type Text For a Master Confirm trade, leave blank Yes when Trade, Backload, Amendment, Assignment* Conditional; required when the Master Document Conditional, Required when Master Document Transaction Required. Required Required Required Required ` Required present Transaction Type field contains a Matrix-related value. Type contains one of the Standard Terms Supplement values. For a Matrix trade, use the value Otherwise Not Allowed (leave blank). Otherwise, Not Allowed Valid Value: Must have a value of For a Master Confirm trade, leave blank For a Master Confirm trade, leave blank For a Master Confirm trade, leave blank For a Master Confirm trade, leave blank For a Master Confirm trade, leave blank CreditDerivativesPhysicalSettlementMatrix StandardTermsSupplement For a Master Confirm trade, leave blank For a Master Confirm trade, leave blank For a Matrix trade, use the value For a Matrix trade, use the value For a Matrix trade, use the value For a Matrix trade, use the value For a Matrix trade, use the value CreditDerivativesPhysicalSettlementMatrix CreditDerivativesPhysicalSettlementMatrix CreditDerivativesPhysicalSettlementMatrix CreditDerivativesPhysicalSettlementMatrix CreditDerivativesPhysicalSettlementMatrix For a Matrix trade, use the value For a Matrix trade, use the value CreditDerivativesPhysicalSettlementMatrix CreditDerivativesPhysicalSettlementMatrix

For a Standard Terms Index trade, use the value StandardTermsSupplement

67 BO Calculation Agent Text A 1-20 Character Participant ID (e.g., 00006101) or Yes when Trade, Backload, Amendment, Assignment* Conditional; required when Documentation Type has a Conditional, Required when Documentation Type has a value Required Required Required Required Required Required Required "AsSpecifiedInMaster" or "AsSpecifiedInSTS". present value of CreditDerivativesPhysicalSettlementMatrix. of StandardTermsSupplement. Otherwise, Not Allowed Otherwise Not Allowed.

68 BP Additional Matrix Provisions Text Array Will be allowed to select two provisions at once. Eg Monoline and Yes when Trade, Backload, Amendment, Assignment* Conditional; Optional when Documentation Type is Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Fixed Recovery. present 'CreditDerivativesPhysicalSettlementMatrix' otherwise Not Allowed. NorthAmericanCorporate ONLY: ISDA2003CreditMonolineInsurers2005 For the Remaining Party record of an Assignment, see ISDA2003DeliveryRestrictions also New Additional Matrix Provisions. ISDA2003SecuredDeliverableObligationCharacteristic

69 BQ New Calculation Agent Text A 1-20 Character Participant ID (e.g., 00006101) or Yes when Assignment (Remaining Party record only) Conditional; Conditional, Required when Documentation Type has a value Required Required Required Required Required Required Required "AsSpecifiedInMaster". Represents the Calculation Agent on the present MCA>MCA* or Matrix>MCA*: Not allowed. of StandardTermsSupplement. Otherwise, Not Allowed New Transaction between the Remaining Party and the Transferee. Matrix>Matrix* or MCA>Matrix*: Required.

70 BR New Calculation Agent Text 4-Character ISDA Business Center code. Represents the Yes when Assignment (Remaining Party record only) Conditional; Conditional, Optional when Documentation Type has a value of Optional Required Required Required Required Not Allowed Not Allowed Business Center Calculation Agent Business Center on the New Transaction between present StandardTermsSupplement. Otherwise, Not Allowed. the Remaining Party and the Transferee. MCA>MCA*: Not allowed. (The value entered above in Calculation Agent Business Center will be applied to both the Old Transaction and New Transaction).

Matrix>Matrix* or MCA>Matrix*: Optional.

Matrix>MCA*: Not allowed when New Master Document Transaction Type has a value of ISDA2003CreditNorthAmerican or ISDA2003CreditEuropean. Otherwise required.

71 BS New Additional Terms Text Represents the Additional Terms on the New Transaction between Yes when Assignment (Remaining Party record only) Conditional; Conditional, Optional when Documentation Type has a value of Optional Optional Optional Optional Optional Optional Optional the Remaining Party and the Transferee. present StandardTermsSupplement. Otherwise, Not Allowed because MCA>MCA*: Not allowed. (The value entered above in the value entered above in Additional Terms will be applied to For Matrix>MCA*: Free-form text up to 255 characters only. "Y" or Additional Terms will be applied to both the Old both the Old Transaction and New Transaction. free-form text means Applicable and "N" or blank mean Not Transaction and New Transaction). Applicable. Matrix>Matrix* or MCA>Matrix* or Matrix>MCA*: Optional. For Matrix>Matrix* or MCA>Matrix*: free-form text up to 255 (The value entered above in Additional Terms will only characters (Y and N do not have any special meaning. Leave the be applied to the Old Transaction, and the value entered field blank if there are no additional terms). here will be used for the New Transaction).

72 BT Master Agreement Type Text Any valid value from the DTCC scheme (AFB, German, ISDA, Yes when Trade, Backload, Amendment, Assignment* Conditional; required when the Documentation Type field Conditional, Required when Documentation Type has a value Required Required Required Required Required Required Required Swiss, Other, ICETrustUS, ICEClearEurope). present has a value of of StandardTermsSupplement. Otherwise, Not Allowed CreditDerivativesPhysicalSettlementMatrix. Otherwise Documentation Type must be either Not Allowed. CreditDerivativesPhysicalSettlementMatrix or StandardTermsSupplement cleared transactions in order to use a value of "ICETrustUS" or "ICEClearEurope"

73 BU Master Agreement Date YYYY-MM-DD Any valid date. Yes when Trade, Backload, Amendment, Assignment* Conditional; required when the Documentation Type field Conditional, Required when Documentation Type has a value Required Required Required Required Required Required Required present has a value of of StandardTermsSupplement. Otherwise, Not Allowed CreditDerivativesPhysicalSettlementMatrix. Otherwise Not Allowed.

74 BV New Master Agreement Type Text Any valid value from the DTCC scheme (AFB, German, ISDA, Yes when Assignment (Remaining Party record only) Conditional; Conditional, Required when Documentation Type has a value Required Required Required Required Required Required Required Swiss, Other, ICETrustUS, ICEClearEurope). present MCA>MCA* or Matrix>MCA*: Not allowed. of StandardTermsSupplement. Otherwise, Not Allowed

Represents the Master Agreement Type of the New Transaction Matrix>Matrix* or MCA>Matrix*: Required. between the Remaining Party and the Transferee.

75 BW New Master Agreement Date YYYY-MM-DD Any valid date. Represents the Master Agreement Date of the New Yes when Assignment (Remaining Party record only) Conditional; Conditional, Required when Documentation Type has a value Required Required Required Required Required Required Required Transaction between the Remaining Party and the Transferee. present MCA>MCA* or Matrix>MCA*: Not allowed. of StandardTermsSupplement. Otherwise, Not Allowed

Matrix>Matrix* or MCA>Matrix*: Required. 76 BX New Documentation Type Text Represents the Documentation Type of the New Transaction Yes when Assignment (Remaining Party record only) Conditional; required when the New Master Document Conditional; required when the New Master Document Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed between the Remaining Party and the Transferee. When the New present Transaction Type field contains a Matrix-related value. Transaction Type field contains a Matrix-related value. Transaction is a Master Confirm trade, leave blank. When it is a Otherwise Not Allowed (leave blank). Otherwise Not Allowed (leave blank). Matrix Trade, use the value CreditDerivativesPhysicalSettlementMatrix. 77 BY New Master Document Text Used for the New Transaction between the Remaining Party and the Yes when Assignment (Remaining Party record only) Conditional; Conditional; Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Transaction Type Transferee. Represents the "Master Confirmation Transaction present Type" when the New Transaction is a Master Confirm trade and MCA>MCA*: Not allowed. (The value entered above in MCA>MCA*: Not allowed. (The value entered above in Master "Transaction Type" when it is a Matrix trade. See "Valid Values" tab Master Document Transaction Type will be applied to Document Transaction Type will be applied to both the Old for valid values for this field. both the Old Transaction and New Transaction). Transaction and New Transaction).

For Matrix>Matrix*, the value in this field should be the exact same Matrix>Matrix* or MCA>Matrix* or Matrix>MCA*: StandardTerms>StandardTerms* or MCA>StandardTerms* or as the value in the Master Document Transaction Type field. Required. (The value entered above in Master Document StandardTerms>MCA*: Required. (The value entered above in Transaction Type will only be applied to the Old Master Document Transaction Type will only be applied to the For MCA>Matrix or Matrix>MCA, the value in this field should map to Transaction, and the value entered here will be used for Old Transaction, and the value entered here will be used for the value in the Master Document Transaction Type field. See the New Transaction). the New Transaction). "Valid Values" tab for the mapping between Master Confirmation Transaction Type and Matrix Transaction Type values.

For MBS, use the value "StandardTermsSupplement" For LCDS, use the value "StandardTermsSupplement" For ELCDS, use the value "CDSonLeveragedLoans"

78 BZ New Additional Matrix Text Array NorthAmericanCorporate ONLY: Yes when Assignment (Remaining Party record only) Conditional; Optional when Documentation Type is Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Provisions ISDA2003CreditMonolineInsurers2005 present 'CreditDerivativesPhysicalSettlementMatrix' otherwise ISDA2003DeliveryRestrictions Not Allowed. ISDA2003SecuredDeliverableObligationCharacteristic MCA>MCA* or Matrix>MCA*: Not allowed.

Represents the Matrix Additional Provisions of the New Transaction Matrix>Matrix* or MCA>Matrix*: Optional when the New between the Remaining Party and the Transferee. Master Document Transaction Type is NorthAmericanCorporate,Otherwise Not Allowed. For Matrix>Matrix*, the value in this field should be the same as the value in the applicable Matrix Additional Provisions.

Matching CreditDefaultSwap CMBS ECMBS RMBS ERMBS LCDS ELCDS # Ref Data Field Cell Format Valid Entry ? Applicable Transaction Types CreditDefaultSwapShort CreditDefaultSwapIndex IndexTranche 79 CA New Restructuring Events (Y/N) Text Represents the Restructuring Events (Y/N) for the New Transaction Yes when Assignment (Remaining Party record only) Conditional; Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed between the Remaining Party and the Transferee. present MCA>MCA*: Not allowed. (The value entered above in For Matrix>MCA*: Y or N only. Y means Applicable and N or blank Restructuring Events Y/N will be applied to both the Old mean Not Applicable. Transaction and New Transaction).

For MCA>Matrix* or Matrix>Matrix* where the New Master Document Matrix>Matrix* or MCA>Matrix* or Matrix>MCA*: Transaction Type is NorthAmericanCorporate: Y or N only. Y means Optional. (The value entered above in Restructuring Applicable and N or blank mean Not Applicable. Events Y/N will only be applied to the Old Transaction, and the value entered here will be used for the New For MCA>Matrix* or Matrix>Matrix* where the New Master Document Transaction). Transaction Type is not NorthAmericanCorporate: The Matrix sets Restructuring Events to always be Applicable. Therefore, any entries in this field will be ignored.

80 CB New Excluded Deliverables Text Alphanumeric Text up to 255 alphanumeric characters. Represents Yes when Assignment (Remaining Party record only) Conditional; Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed the Excluded Deliverables of the New Transaction between the present Remaining Party and the Transferee. MCA>MCA*: Not allowed. (The value entered above in Excluded Deliverables will be applied to both the Old (Only used when assigning a Sovereign trade done under the Matrix Transaction and New Transaction). to one done under a Master Confirm). Matrix>Matrix* or MCA>Matrix*: Not allowed. (because this field is not used for Matrix).

Matrix>MCA*: Optional when New Master Document Transaction Type contains one of the following values: ISDA2004CreditSovereignAsia, ISDA2004CreditSovereignEmergingEuropeanAndMiddl eEastern, ISDA2004CreditSovereignJapan, ISDA2004CreditSovereignLatinAmerican, or ISDA2004CreditSovereignWesternEuropean. Otherwise Not Allowed.

81 CC Attachment Point Number with 0 to 2 Only values from (and including) 0.00 to 100.00 are valid Yes when Trade, Backload, Amendment, Assignment* , Not Allowed Not Allowed Required Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed decimal places present PartialTermination*, Exercise 82 CD Exhaustion Point Number with 0 to 2 Only values from (and including) 0.00 to 100.00 are valid Yes when Trade, Backload, Amendment, Assignment* , Not Allowed Not Allowed Required Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed decimal places present PartialTermination*, Exercise

83 CE Modified Equity Delivery Text Valid values are "Y" and "N" Yes when Trade, Backload, Amendment, Assignment* Not Allowed Not Allowed Optional Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed present When Modified Equity Delivery is not included on a trade record, it is assumed to be Not Applicable or N 84 CF Settled Entity Matrix Source Text Valid values are ‘Publisher’ or ‘NotApplicable’. Yes when Trade, Backload, Amendment, Assignment* Not Allowed Not Allowed Required Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed present 85 CG Settled Entity Matrix Date YYYY-MM-DD Any valid date. Yes when Trade, Backload, Amendment, Assignment* Not Allowed Not Allowed Optional Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed present 86 CH New Settled Entity Matrix Text Valid values are ‘Publisher’ or ‘NotApplicable’. Yes when Assignment (Remaining Party record only) Not Allowed Not Allowed Required Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Source present 87 CI New Settled Entity Matrix Date YYYY-MM-DD Any valid date. Yes when Assignment (Remaining Party record only) Not Allowed Not Allowed Optional Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed present

88 CJ New Reference Obligation Text Any valid ISIN or CUSIP (up to 12 characters) Yes Assignment (Remaining Party record only) Optional Optional Optional Optional Optional Optional Optional Conditional; Required when Secured List Applicable Optional equals "N", Otherwise Optional The Reference Obligation will be overwritten by DTCC when a valid 9 character Reference Entity Id is supplied.

89 CK New Reference Entity Name Text REDS Name Text or Alphanumeric Text up to 250 alphanumeric Yes Assignment (Remaining Party record only) Optional Optional Optional Optional Optional Optional Optional Optional Optional characters

The Reference Entity Name will be overwritten by DTCC when a valid 6 or 9 character Reference Entity Id is supplied.

90 CL New Reference Entity ID Text REDS ID ( 6 or 9 characters) Yes Assignment (Remaining Party record only) Optional Optional Optional Optional Optional Optional Optional Optional Optional

Will be used to overwrite Reference Entity Name and Reference Obligation if specified.

91 CM Submitter Role Text Represents the Submitter Role in an Assignment ("EE", "OR", "RP" Yes Assignment Required Required Required Required Required Required Required Required Required only)

92 CN Comment Text Up to 250 alphanumeric characters No All Optional Optional Optional Optional Optional Optional Optional Optional Optional

93 CO Super ID Text Up to 40 characters alphanumeric characters No All Optional Optional Optional Optional Optional Optional Optional Optional Optional

94 CP E-trading TRN Text Up to 40 characters alphanumeric characters No All Optional Optional Optional Optional Optional Optional Optional Optional Optional

95 CQ Broker Name Text Up to 40 characters free format text No All Optional Optional Optional Optional Optional Optional Optional Optional Optional

96 CR Desk ID Text Up to 50 characters free format text No All OptionaL Optional Optional Optional Optional Optional Optional Optional Optional

97 CS Designated Party ID Text Up to 20 characters free format text No All Optional Optional Optional Optional Optional Optional Optional Optional Optional

98 CT New Comment Text Up to 250 alphanumeric characters No Assignment (Remaining Party record only) Optional Optional Optional Optional Optional Optional Optional Optional Optional 99 CU New Super ID Text Up to 40 characters alphanumeric characters No Assignment (Remaining Party record only) Optional Optional Optional Optional Optional Optional Optional Optional Optional 100 CV New Desk ID Text Up to 50 characters free format text No Assignment (Remaining Party record only) Optional Optional Optional Optional Optional Optional Optional Optional Optional 101 CW New E-trading TRN Text Up to 40 characters alphanumeric characters No Assignment (Remaining Party record only) Optional Optional Optional Optional Optional Optional Optional Optional Optional 102 CX New Designated Party ID Text Up to 20 characters free format text No Assignment (Remaining Party record only) Optional Optional Optional Optional Optional Optional Optional Optional Optional 103 CY New Broker Name Text Up to 40 characters free format text No Assignment (Remaining Party record only) Optional Optional Optional Optional Optional Optional Optional Optional Optional 104 CZ Back Load Effective Date YYYY-MM-DD Any valid date. Yes Backload Required Required Required Required Required Required Required Required Required 105 DA DTCC TRI Text 19 characater text. E.g. YYYYMMDD.1234567890 N/A PartialTermination, Exercise Conditional: Conditional: Conditional: Conditional: Conditional: Conditional: Conditional: Conditional: Conditional: Optional if the Pariticpant TRI is present, otherwise Optional if the Pariticpant TRI is present, otherwise required. Optional if the Pariticpant TRI is Optional if the Participant TRI is present, otherwise Optional if the Participant TRI is present, otherwise Optional if the Participant TRI is present, otherwise Required. Optional if the Participant TRI is present, otherwise Required. Optional if the Participant TRI is present, otherwise Optional if the Participant TRI is present, otherwise required. present, otherwise required. Required. Required. Required. Required. 106 DB First Payment Period Accrual YYYY-MM-DD Any valid date. Yes when Trade, Backload, Amendment, Assignment Optional Not Allowed Optional Optional Optional Optional Optional Optional Optional Start Date present 107 DC New First Payment Period YYYY-MM-DD Any valid date. Yes when Assignment (Remaining Party record only) Optional Not Allowed Optional Optional Optional Optional Optional Optional Optional Accrual Start Date present

108 DD CreditTieOut Type Text CreditDefaultSwap N/A None Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed CreditDefaultSwapIndex CreditDefaultSwapIndexTranche CreditDefaultSwapOnLoan CreditDefaultSwapOnABS CreditDefaultSwapOnCMBS CreditDefaultSwapOnRMBS CreditDefaultCDO CreditDefaultCDOSquared CreditDefaultSwaption CreditDefaultSwapBespokeTranche CreditDefaultSwapDigital Other

109 DE Other TieOut Type Text Up to 255 alphanumeric characters N/A None Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed

110 DF Business Day Text Array ISDA Business Center code: "GBLO, USNY" Yes Trade, Backload, Amendment, Assignment* Not Allowed Not Allowed Not Allowed Required Required Required Required Not Allowed Not Allowed

111 DG Reference Policy Applicable Text Y or N only Yes Trade, Backload, Amendment, Assignment* Not Allowed Not Allowed Not Allowed Required Required Required Required Not Allowed Not Allowed 112 DH Reference Price Number with 0 to 5 % Number with 0 to 5 decimal places (will default on web application Yes Trade, Backload, Amendment, Assignment* Not Allowed Not Allowed Not Allowed Required Required Required Required Not Allowed Not Allowed decimal places to 100%) 113 DI Fixed Amount Payment Delay Text Y or N only No Trade, Backload, Amendment, Assignment* Not Allowed Not Allowed Not Allowed Optional Optional Optional Optional Not Allowed Not Allowed Applicable 114 DJ Step-Up Provisions Applicable Text Y or N only Yes Trade, Backload, Amendment, Assignment* Not Allowed Not Allowed Not Allowed Not Allowed Required Required Required Not Allowed Not Allowed

115 DK WAC Cap Interest Provision Text Y or N only Yes Trade, Backload, Amendment, Assignment* Not Allowed Not Allowed Not Allowed Required Required Not Allowed Not Allowed Not Allowed Not Allowed Applicable 116 DL Interest Shortfall Cap Text Y or N only Yes Trade, Backload, Amendment, Assignment* Not Allowed Not Allowed Not Allowed Required Required Required Required Not Allowed Not Allowed Applicable 117 DM Interest Shortfall Cap Basis Text Specify: Fixed or Variable Yes when Trade, Backload, Amendment, Assignment* Not Allowed Not Allowed Not Allowed Conditional; Required if Interest Shortfall Cap Conditional; Required if Interest Shortfall Cap Conditional; Required if Interest Shortfall Cap Applicable is Conditional; Required if Interest Shortfall Cap Applicable is Not Allowed Not Allowed present Applicable is "Y". Otherwise Not Allowed Applicable is "Y". Otherwise Not Allowed "Y". Otherwise Not Allowed "Y". Otherwise Not Allowed 118 DN Interest Shortfall Compounding Text Y or N only Yes when Trade, Backload, Amendment, Assignment* Not Allowed Not Allowed Not Allowed Conditional; Required if Interest Shortfall Cap Conditional; Required if Interest Shortfall Cap Conditional; Required if Interest Shortfall Cap Applicable is Conditional; Required if Interest Shortfall Cap Applicable is Not Allowed Not Allowed Applicable present Applicable is "Y". Otherwise Not Allowed Applicable is "Y". Otherwise Not Allowed "Y". Otherwise Not Allowed "Y". Otherwise Not Allowed 119 DO Rate Source Text Any Rate Source Option supported by DTCC, see list available for Yes when Trade, Backload, Amendment, Assignment* Not Allowed Not Allowed Not Allowed Conditional; Required if Interest Shortfall Cap Conditional; Required if Interest Shortfall Cap Conditional; Required if Interest Shortfall Cap Applicable is Conditional; Required if Interest Shortfall Cap Applicable is Not Allowed Not Allowed Rates. (Ex: USD-LIBOR-BBA) present Applicable is "Y". Otherwise Not Allowed Applicable is "Y". Otherwise Not Allowed "Y". Otherwise Not Allowed "Y". Otherwise Not Allowed 120 DP Optional Early Termination Text Y or N only Yes Trade, Backload, Amendment, Assignment* Not Allowed Not Allowed Not Allowed Required Required Required Required Not Allowed Not Allowed Applicable 121 DQ Designated Maturity Number with 0 decimal Between 1 and 12 Yes Trade, Backload, Amendment, Assignment* Not Allowed Not Allowed Not Allowed Required Required Required Required Not Allowed Not Allowed places 122 DR Date of Credit Agreement YYYY-MM-DD Any valid date. Yes when Trade, Backload, Amendment, Assignment* Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Conditional; Required when Secured List Applicable Not Allowed present equals "N", Otherwise Optional 123 DS Facility Type Text Either "Term" or "Revolving" Yes when Trade, Backload, Amendment, Assignment* Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Conditional; Required when Secured List Applicable Not Allowed present equals "N", Otherwise Optional

124 DT Bloomberg ID Text A 1-30-digit alphanumeric Yes when Trade, Backload, Amendment, Assignment* Not Allowed Not Allowed Not Allowed Optional Optional Optional Optional Conditional; Required when Secured List Applicable Optional present equals "N" and Name of Borrower is blank; Otherwise Optional

125 DU Name of Borrower Text Array Can be an array of names; DTCC shouldn't match on order; The Yes when Trade, Backload, Amendment, Assignment* Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Conditional; Required when Secured List Applicable Optional fields used to identify the underlying may be different on the new present equals "N" and Bloomberg ID is blank; Otherwise Optional trade and old trade portions of a Remaining Party Assignment record.

126 DV Insurer Text Specify "Not Applicable; Applicable" Yes Trade, Backload, Amendment, Assignment* Not Allowed Not Allowed Not Allowed Required Required Required Required Not Allowed Not Allowed

Matching CreditDefaultSwap CMBS ECMBS RMBS ERMBS LCDS ELCDS # Ref Data Field Cell Format Valid Entry ? Applicable Transaction Types CreditDefaultSwapShort CreditDefaultSwapIndex IndexTranche 127 DW Legal Final Maturity Date YYYY-MM-DD Any valid date. Yes Trade, Backload, Amendment, Assignment* Not Allowed Not Allowed Not Allowed Required Required Required Required Not Allowed Not Allowed

128 DX Designated Priority Text First, Second, Third Yes Trade, Backload, Amendment, Assignment* Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Required Required

129 DY Original Principal Amount Number with 0 to 2 Number with 0 to 2 decimal places Yes when Trade, Backload, Amendment, Assignment* Not Allowed Not Allowed Not Allowed Optional Optional Optional Optional Not Allowed Not Allowed decimal places present 130 DZ Initial Factor Number with 0 to 9 Number with 0 to 9 decimal places Yes when Trade, Backload, Amendment, Assignment* Not Allowed Not Allowed Not Allowed Optional Optional Optional Optional Not Allowed Not Allowed decimal places present Will be overwritten by DTCC to blank upon Will be overwritten by DTCC to blank upon Will be overwritten by DTCC to blank upon submission. Will be overwritten by DTCC to blank upon submission. submission. submission.

131 EA Secured List Applicable Text Y or N only Yes Trade, Backload, Amendment, Assignment* Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Required Not Allowed

132 EB New Facility Type Text Either "Term" or "Revolving" Yes when Assignment (Remaining Party record only) Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Conditional; Required when Secured List Applicable Not Allowed present equals "N"; Otherwise Optional. 133 EC New Bloomberg ID Text A 1-30-digit alphanumeric Yes when Assignment (Remaining Party record only) Not Allowed Not Allowed Not Allowed Optional Optional Optional Optional Conditional; Required when Secured List Applicable Optional present equals "N" and Name of Borrower is blank; Otherwise Optional 134 ED New Name of Borrower Text Array Can be an array of names; DTCC shouldn't match on order; The Yes when Assignment (Remaining Party record only) Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Conditional; Required when Secured List Applicable Optional fields used to identify the underlying may be different on the new present equals "N" and Bloomberg ID is blank; Otherwise Optional trade and old trade portions of a Remaining Party Assignment record. 135 EE New Insurer Text Specify "Not Applicable; Applicable" Yes Assignment (Remaining Party record only) Not Allowed Not Allowed Not Allowed Required Required Required Required Not Allowed Not Allowed 136 EF New Legal Final Maturity Date YYYY-MM-DD Any valid date. Yes Assignment (Remaining Party record only) Not Allowed Not Allowed Not Allowed Required Required Required Required Not Allowed Not Allowed

137 EG New Designated Priority Text Either "First", "Second", or "Third" Yes Assignment (Remaining Party record only) Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Required Required 138 EH New Original Principal Amount Number with 0 to 2 Number with 0 to 2 decimal places Yes when Assignment (Remaining Party record only) Not Allowed Not Allowed Not Allowed Optional Optional Optional Optional Not Allowed Not Allowed decimal places present 139 EI New Initial Factor Number with 0 to 9 Number with 0 to 9 decimal places Yes when Assignment (Remaining Party record only) Not Allowed Not Allowed Not Allowed Optional Optional Optional Optional Not Allowed Not Allowed decimal places present Will be overwritten by DTCC to blank upon Will be overwritten by DTCC to blank upon Will be overwritten by DTCC to blank upon submission. Will be overwritten by DTCC to blank upon submission. submission. submission. 140 EJ New Secured List Applicable Text Y or N only Yes when Assignment (Remaining Party record only) Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Optional Not Allowed present 141 EK New Fixed Rate Payer (Buyer) Text A 1-20 character participant id (e.g., 00006101) Yes when Assignment (Remaining Party record only) Conditional; Optional when OR = RP or not allowed Conditional; Optional when OR = RP or not allowed otherwise Conditional; Optional when OR = RP or Conditional; Optional when OR = RP or not allowed Conditional; Optional when OR = RP or not allowed Conditional; Optional when OR = RP or not allowed otherwise Conditional; Optional when OR = RP or not allowed otherwise Conditional; Optional when OR = RP or not allowed Conditional; Optional when OR = RP or not allowed present otherwise not allowed otherwise otherwise otherwise otherwise otherwise 142 EL New Optional Early Termination Text Y or N only Yes Assignment (Remaining Party record only) Not Allowed Not Allowed Not Allowed Required Required Required Required Not Allowed Not Allowed Applicable 143 EM Cash Settlement Only Text Specify "Not Applicable; Applicable" Yes Trade, Backload, Amendment, Assignment* Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Optional omission is equivalent to specifying "Not Applicable" 144 EN Delivery of Commitments Text Specify "Not Applicable; Applicable" Yes Trade, Backload, Amendment, Assignment* Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Optional omission is equivalent to specifying "Applicable" 145 EO Continuity Text Specify "Not Applicable; Applicable" Yes Trade, Backload, Amendment, Assignment* Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Optional omission is equivalent to specifying "Applicable" 146 EP New Cash Settlement Only Text Specify "Not Applicable; Applicable" Yes Assignment (Remaining Party record only) Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Optional omission is equivalent to specifying "Not Applicable" 147 EQ New Delivery of Commitments Text Specify "Not Applicable; Applicable" Yes Assignment (Remaining Party record only) Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Optional omission is equivalent to specifying "Applicable" 148 ER New Continuity Text Specify "Not Applicable; Applicable" Yes Assignment (Remaining Party record only) Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Optional omission is equivalent to specifying "Applicable" 149 ES Expiration Date YYYY-MM-DD Any valid date. For a Transferee Assignment record, must equal Yes Trade, Backload, Amendment, Assignment*, Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Post Trade Effective Date (which is the Novation Date). PartialTermination*, Exercise

150 ET Underlying Fixed Rate Payer Text A 1-20 Character Participant ID (e.g., 00006101). Yes Trade, Amendment, Assignment, Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed (Buyer). PartialTermination , Exercise 151 EU Underlying Float Rate Payer Text A 1-20 Character Participant ID (e.g., 00006101). Yes Trade, Amendment, Assignment, Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed (Seller). PartialTermination, Exercise 152 EV Quoting Style Text Spread or Price Yes All Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed

153 EW Option Style Text European Yes Trade, Amendment, Assignment, Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed PartialTermination, Exercise 154 EX Strike Price Number with 0 to 5 Enter 1.50000 for 1.5% Do not enter % sign in cell Yes Trade, Backload, Amendment, Assignment*, Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed decimal places PartialTermination*, Exercise 155 EY Swaption Settlement Style Text Physical Yes Trade, Amendment, Assignment, Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed PartialTermination, Exercise 156 EZ Underlying Master Document Text Yes Trade, Backload, Amendment, Assignment Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Transaction Type Represents the "Transaction Type" for a Single-Name trade that uses the Matrix form of documentation.

Represents the "Standard Terms Supplement Type" that uses the Standard Terms form of documentation.

See "Valid Values" tab for valid values for this field

157 FA Underlying Master Document YYYY-MM-DD Any valid date. Yes when Trade, Backload, Amendment, Assignment* Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Date present Represents the Matrix Publication Date for a Single-Name trade that uses the Matrix form of documentation.

Represents the Standard Terms Supplement Publication Date for an Index or Index Tranche trade that uses the Standard Terms form of documentation.

158 FB Exercise Event Type Text Physical/Cash Yes Exercise Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed 159 FC Recovery Price Number with 0 to 8 Enter 1.50000000 for 1.5% Do not enter % sign in cell Yes All Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed decimal places 160 FD Fixed Settlement Text Specify "Not Applicable; Applicable" Yes All Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Not Allowed Omission is equivalent to specifying "Applicable"

All text highlighted in red are changes or new features in the 9.0 version of the spreadsheet.

Trade Reference Number values Any newly submitted Trade Reference Number or Trade Reference Number Supplement value must not begin with the literal string "DTCC". Existing "DTCC" prefixed TRNs can be submitted and/or modified as BAU.

Date values A valid date for Deriv/SERV processing is in the YYYY-MM-DD format. All dates except for "1900-01-01" are valid.

Partial Termination and Partial Termination* explained For an "inside" Partial Termination (i.e. the underlying trade was previously submitted to DTCC), include the fields marked Partial Termination. For an "outside" Partial Termination (i.e. the underlying trade was not previously submitted to DTCC), include the fields marked Partial Termination and the fields marked Partial Termination*.

Assignment and Assignment* explained For an "inside" Assignment (i.e. the underlying trade was previously submitted to DTCC), the Transferor and Remaining Party only need to include the fields marked Assignment. For an "outside" Assignment (i.e. the underlying trade was not previously submitted to DTCC), include the fields marked Assignment and the fields marked Assignment*.

Key Terms for Assignments Documentation Type and New Documentation Type are blank because both the Old Transaction between OR-RP and the New Transaction between EE-RP were done under Master Confirmations. Documentation Type and New Documentation Type have a value of CreditDerivativesPhysicalSettlementMatrix because both the Old Transaction between OR-RP and the New Transaction between EE-RP were done under the Matrix. Documentation Type is blank and New Documentation Type has a value of CreditDerivativesPhysicalSettlementMatrix because the Old Transaction between OR-RP was done under a Master Confirmation while the New Transaction between EE-RP was done under the Matrix. Documentation Type has a value of CreditDerivativesPhysicalSettlementMatrix and New Documentation Type is blank because the Old Transaction between OR-RP was done under the Matrix while the New Transaction between EE-RP was done under a Master Confirmation.

Key Terms for CDX Assignments Documentation Type and New Documentation Type have a value of StandardTermsSupplement because both the Old Transaction between OR-RP and the New Transaction between EE-RP were done under a Standard Term Supplement. Documentation Type is blank and New Documentation Type has a value of StandardTermsSupplement because the Old Transaction between OR-RP was done under a Master Confirmation while the New Transaction between EE-RP was done under a Standard Term Supplement. Documentation Type has a value of StandardTermsSupplement and New Documentation Type is blank because the Old Transaction between OR-RP was done under a Standard Term Supplement while the New Transaction between EE-RP was done under a Master Confirmation.

Rev. 2011-1 (Release Date February 28, 2011) Appendix L to MarkitSERV Operating Procedures

TRANSACTION RECORD DESCRIPTION: SINGLE REFERENCE ENTITY CREDIT DEFAULT SWAP ON MORTGAGE- BACKED SECURITY AND SINGLE REFERENCE ENTITY CREDIT DEFAULT SWAP ON LOAN

This Transaction Record Description relates to the Eligible Product and Eligible Transactions set forth below. It is a part of, and subject in all respects to, the most recent version of the Company Operating Procedures for Automated Confirmation and Matching System, published by MarkitSERV to which it is an Appendix (the “Operating Procedures”). Unless the context otherwise indicates, all terms defined in the Operating Procedures shall have the same meanings in this Transaction Record Description.

Eligible Product: Single Reference Entity Credit Default Swap on Mortgage- Backed Security and Single Reference Entity Credit Default Swap on Loan

Eligible Transactions: New Trades Partial Terminations (can apply only all Eligible Products, regardless of whether the partially terminated trade was originally confirmed through the System) Assignments (can apply to all Eligible Products, regardless of whether the assigned trade was originally confirmed through the System) Increases (can apply only to Eligible Products where the amended trade was originally confirmed through the System) Amendments (can apply only to Eligible Products where the amended trade was originally confirmed through the System)

Transaction Record Description for New Trades

Replaced Document:

The Replaced Document for new trades that are single reference entity credit default swaps on mortgage-backed securities or single reference entity credit default swaps on loans shall in all cases be a “Confirmation” (or any similar document not so named) that is referred to (or described) in a standard terms supplement (as described below), and that has been executed by two Users for the purpose of evidencing such new trades between them (each, a “Confirmation”). Related Master Documents shall be:

• Master Agreement –identified pursuant to the Transaction Record– consisting of an ISDA Master Agreement (or other applicable type of master agreement described below) that has been executed by the relevant two Users. Any reference in a Transaction Record to a Master Agreement shall be to the Master Agreement as it may have been, and may subsequently be, amended, supplemented or modified by the parties thereto. All provisions contained in, or incorporated by reference in, the Master Agreement shall govern the Replaced Document except as expressly modified herein or in the applicable Standard Terms Supplement. With respect to such other Master Agreement types: • If the Master Agreement Type is “German”, the German Master Agreement for Financial Derivatives Transactions (Rahmenvertrag für Finanztermingeschäfte) • If the Master Agreement Type is “AFB”, the AFB/FBF Convention-cadre relative aux opérations de marché à terme. • If the Master Agreement Type is “Swiss”, the Swiss Master Agreement for over-the-counter (OTC) Derivatives.

• Standard Terms Supplement –the Users shall be deemed to have incorporated into the Replaced Document the following standard terms supplement (a “Standard Terms Supplement”): • (a) if Interest Shortfall Cap is specified as applicable or not applicable in the Transaction Record (unless the Master Document Transaction Type is “EuropeanCMBS” or “EuropeanRMBS”), the ISDA Standard Terms Supplement for Use with Credit Derivative Transactions on Mortgage-Backed Security with Pay-As-You-Go or Physical Settlement, as published by the International Swaps and Derivatives Association, Inc. (“ISDA”) as of the date specified in Master Document Date in the Transaction Record. With respect to such Standard Terms Supplement, the following additional elections and provisions shall apply: the Floating Rate Amount/ Notional Amount specified in the Transaction Record shall be the Initial Face Amount for purposes of the Standard Terms Supplement; if the Step-Up Provisions are specified as applicable or not applicable in the Transaction Record, Distressed Ratings Downgrade shall be deemed to be specified as an Additional Credit Event; otherwise, no Additional Credit Event shall be deemed to be specified; and if the WAC Cap Interest Provision is specified as applicable or not applicable in the Transaction Record, CMBS Convention shall be deemed to be specified for purposes of the Standard Terms Supplement; otherwise Not CMBS Convention shall be deemed to be specified. • (b) if Secured List Applicable is specified as applicable or not applicable in the Transaction Record or if “Standard LCDS Bullet” is specified in Master Document Transaction Type, the Syndicated 2

Secured Loan Credit Default Swap Standard Terms Supplement or the Bullet Syndicated Secured Loan Credit Default Swap Standard Terms Supplement, as the case may be, as published by ISDA as of the date specified in Master Document Date in the Transaction Record. • (c) if “CDSonLeveragedLoans” is specified in Master Document Transaction Type, the ISDA Standard Terms Supplement for Use with Credit Derivative Transactions on Leveraged Loans, as published by ISDA as of the date specified in Master Document Date in the Transaction Record. • (d) if “EuropeanCMBS” is specified in Master Document Transaction Formatted: Bullets and Numbering Type, the ISDA Standard Terms Supplement for Use with Credit Derivative Transactions on Mortgage-Backed Security with Pay-As- You-Go or Physical Settlement, as published by ISDA as of the date specified in Master Document Date in the Transaction Record. With respect to such Standard Terms Supplement, the following additional elections and provisions shall apply: the Floating Rate Amount/ Notional Amount specified in the Transaction Record shall be the Initial Face Amount for purposes of the Standard Terms Supplement; CMBS Convention shall be applicable; and Distressed Ratings Downgrade shall be an Additional Credit Event. Formatted: Indent: Left: 108 pt • (e) if “EuropeanRMBS” is specified in Master Document Transaction Formatted: Bullets and Numbering Type, the ISDA Standard Terms Supplement for Use with Credit Derivative Transactions on Mortgage-Backed Security with Pay-As- You-Go or Physical Settlement, as published by ISDA as of the date specified in Master Document Date in the Transaction Record. With respect to such Standard Terms Supplement, the following additional elections and provisions shall apply: the Floating Rate Amount/ Notional Amount specified in the Transaction Record shall be the Initial Face Amount for purposes of the Standard Terms Supplement; Not CMBS Convention shall be applicable; and Distressed Ratings Downgrade shall be an Additional Credit Formatted: Bulleted + Level: 3 + Aligned at: Event. 144 pt + Tab after: 162 pt + Indent at: 162 pt

Users agree that data elements specified in certain fields may be overwritten by the System as set forth in these Operating Procedures or other publications of the Company from time to time.

The Company shall not be responsible for a User’s failure to properly identify the Master Agreement or relevant Standard Terms Supplement.

Notwithstanding any provision in the related Master Documents, each User agrees that the submission of Transaction Records by it and any other User through the System shall 3

constitute an acceptable method under such Master Documents for evidencing and confirming the terms to be specified in any Confirmation referenced in or to be governed by such Master Documents. Each User further agrees that Confirmed Transaction Records designating the Eligible Product and Eligible Transaction governed by this Transaction Record Description and referencing the relevant Master Documents shall (1) have the same legal effect as a fully executed Replaced Document entered into pursuant to and subject to the terms of such Master Documents and (2) shall evidence a new credit default swap transaction agreed between two Users whose terms and provisions will be set forth in, governed by, construed in accordance with and subject to the Confirmed Transaction Records themselves, such Master Documents and these Operating Procedures, including this Transaction Record Description.

In the event that the features specified in a Transaction Record differ from those specified in the relevant Master Document, the features specified in such Transaction Record shall govern unless otherwise agreed between the relevant Users.

The governing law of the Master Documents shall also govern the obligations created by any Transaction Record.

Transaction Record Data Elements:

Each Transaction Record governed by this Transaction Record Description will include the data elements set out in the “Field Parameters” worksheet applicable to this Appendix, as published by the Company from time to time. Such data elements shall have the meanings set forth or contemplated in the relevant Master Documents (unless the context clearly indicates an intent to identify product and transaction type, trade reference numbers, a transaction date or the Master Documents themselves), including meanings that may be set forth in the Applicable Publications or any other resource identified in the Master Documents (e.g., designated ISDA Credit Derivatives Definitions). In the event of any inconsistency between a Transaction Record and the relevant Master Documents, the Transaction Record shall govern (unless otherwise agreed between Users).

The data elements specified in the “Field Parameters” worksheet that are applicable to this Appendix set out information relating to certain data elements that Users will be required to provide. In addition, Users may indicate that the Independent Amount applicable to the Eligible Transaction to which the Transaction Record relates is linked to another transaction confirmed through the System (the “Linked Transaction”) by specifying “Linked to [trade id of Linked Transaction]” in the data element “Additional Terms”. In the event such Linked Transaction is terminated, novated or otherwise amended, the Independent Amount may be reassessed in the sole discretion of the counterparty to the party with respect to which the Independent Amount applies (the “Independent Amount Determining Party”). Such reassessment shall be effective immediately upon the date of termination, novation or amendment of the Linked Transaction, unless otherwise delayed beyond such date by the Independent Amount

Determining Party. The foregoing may be amended in accordance with, and is subject to, any relevant contract between the parties.

Actual Transaction Records submitted by Users may be different in terms of appearance and in the manner in which information is to be provided (e.g., data elements may be specified in FpML). Users should consult the Applicable Publications for further information on the inputting of data.

Transaction Record Description for Full Terminations

From and after May 7, 2009, full termination messages in respect of Eligible Products may no longer be submitted to the System. A termination in full of a transaction may be submitted through a partial termination message that reduces the notional amount of the transaction to zero.

The following shall apply to full termination messages submitted prior to May 7, 2009.

Replaced Document and Data Elements:

The Replaced Document in respect of full terminations shall in all cases be a termination agreement that would have been fully executed between the parties to a transaction in an Eligible Product that is being terminated in full (regardless of whether the Eligible Product was confirmed through the System, outside the System through the use of standard terms supplements and confirmations, or through some other means). The purpose of the termination agreement would be to evidence: the identity of the transaction being terminated in full, the effective date of the termination in full and the payment, if any, to be made between the parties in connection with the termination. Notwithstanding any provision in any document evidencing and/or governing any Eligible Product intended to be terminated, each User agrees that the submission of Transaction Records by it and any other User through the System for full termination of such transaction shall constitute an acceptable method under such document(s) for evidencing and confirming the termination of such transaction. Each User further agrees that Confirmed Transaction Records designating the product and transaction type governed by this Transaction Record Description and relating to the full termination of a transaction in an Eligible Product shall constitute such User’s agreement to terminate such transaction as of the Termination Effective Date identified in such Confirmed Transaction Records and to receive or pay the Payment Amount identified in such Confirmed Transaction Records on the Payment Settlement Date identified in such Confirmed Transaction Records, and that following such termination and payment, neither party shall have any obligation to the other under such transaction.

Where the transaction being terminated was originally confirmed through the System, it will be identified by User Trade Reference Numbers for the original transaction, which numbers are recorded by the System for each Confirmed Transaction Record. Where the transaction being terminated was not originally confirmed through the System, it will be identified by certain data elements set forth in the “Field Parameters” worksheet applicable to this Appendix that contain the designation “Full Termination” and “Full Termination*” in the column named “Applicable Transaction Types”. Users are responsible for assuring that these elements are sufficient to uniquely identify the transaction to be terminated. Matching on these elements is for identification purposes only, and shall not be effective to retroactively change the terms of the transaction being terminated.

Transaction Record Description for Partial Terminations

Replaced Document and Data Elements:

The Replaced Document in respect of partial terminations shall in all cases be a termination agreement that would have been fully executed between the parties to a transaction in an Eligible Product that is being terminated in part or in full (where the outstanding notional amount of the related transaction is reduced to zero). The purpose of the termination agreement would be to evidence: the identity of the transaction being terminated in part or in full, the effective date of the termination in part or in full, the decrease in the notional amount, the outstanding notional amount after the partial termination or the reduction of the outstanding notional amount to zero after the full termination, and the payment, if any, to be made between the parties in connection with the termination. Notwithstanding any provision in any document evidencing and/or governing any Eligible Product intended to be terminated, each User agrees that the submission of Transaction Records by it and any other User through the System for partial termination of such transaction shall constitute an acceptable method under such document(s) for evidencing and confirming the partial or full termination of such transaction. Each User further agrees that Confirmed Transaction Records designating the product and transaction type governed by this Transaction Record Description and relating to the termination of a transaction in an Eligible Product shall constitute such User’s agreement to partially or fully terminate such transaction as of the Partial Termination Effective Date identified in such Confirmed Transaction Records and to receive or pay the Payment Amount identified in such Confirmed Transaction Records on the Payment Settlement Date identified in such Confirmed Transaction Records, and that following such termination and payment, neither party shall have any obligation to the other under such transaction with respect to the portion of the notional amount so terminated (and in cases where as a result of the termination the outstanding notional amount of such transaction is reduced to zero, with respect to such transaction in its entirety).

Where the transaction being partially terminated was originally confirmed through the System, it will be identified by User Trade Reference Numbers for the original transaction, which numbers are recorded by the System for each Confirmed Transaction Record. Where the transaction being terminated was not originally confirmed through the System, it will be identified by certain data elements set forth in the “Field Parameters” worksheet applicable to this Appendix that contain the designation “Partial Termination” and “Partial Termination*” in the column named “Applicable Transaction Types”. Users are responsible for assuring that these elements are sufficient to uniquely identify the transaction to be terminated. Matching on these elements is for identification purposes only, and shall not be effective to retroactively change the terms of the transaction being terminated.

The transaction that is being partially terminated is terminated only to the extent of the decrease in the notional amount indicated in the relevant Confirmed Transaction Record that corresponds to the data element named “Affected Notional Amount”, with the outstanding Notional Amount (if any) effective after the effective date of the partial termination being the amount indicated in the relevant Confirmed Transaction Record that corresponds to the data element named “Outstanding Notional Amount”, in each case, specified in the “Field Parameters” worksheet applicable to this Appendix, as published by the Company from time to time.

Transaction Record Description for Assignments

Replaced Document:

The Replaced Document for assignments of trades that are single reference entity credit default swaps in an Eligible Product shall in all cases be a “Novation Confirmation” that is in the form of Exhibit C to the 2004 ISDA Novation Definitions (or, if applicable, the form specified in the relevant Standard Terms Supplement) and that confirms the terms and conditions of a novation transaction, or assignment, entered into among three or four Users. Pursuant to such a novation transaction, an existing transaction (which may or may not have been confirmed through the System) (the “Old Transaction”) between two Users may be assigned in whole or in part by one or both such Users (each, a “Transferor”) to another User or two other Users (each, a “Transferee”), resulting in a new transaction (the “New Transaction”) between the Transferee and the remaining party to the Old Transaction (the “Remaining Party”) or between two Transferees. The Novation Confirmation permits the parties to a Novation Confirmation to attach an Old Confirmation and a New Confirmation (as such terms are defined in the 2004 ISDA Novation Definitions) to a Novation Confirmation; therefore, the Old Confirmation and New Confirmation are also Replaced Documents. Related Master Documents for Old Transactions shall be:

• Old Master Agreement – identified pursuant to the Transaction Record– consisting of an ISDA Master Agreement (or similar document not so named) that has been executed by the Transferor and the Remaining Party. Any reference in a Transaction Record to a Master Agreement shall be to the Master Agreement as it may have been, and may subsequently be, amended, supplemented or modified by the parties thereto.

• Standard Terms Supplement –as determined in the subheading “Standard Terms Supplement” in the Transaction Record Description for New Trades below.

The Company shall not be responsible for a User’s failure to properly identify the Master Agreement or relevant Standard Terms Supplement.

Related Master Documents for New Transactions shall be:

• New Master Agreement – identified pursuant to the Transaction Record– consisting of an ISDA Master Agreement (or other applicable master agreement described below) that has been executed by the Transferee and the Remaining Party. Any reference in a Transaction Record to a Master Agreement shall be to the Master Agreement as it may have been, and may subsequently be, amended, supplemented or modified by the parties thereto. All provisions contained in, or incorporated by reference in, the Master Agreement shall govern the Replaced Document except as expressly modified herein or in the applicable Standard Terms Supplement. With respect to such other Master Agreement types:

• Standard Terms Supplement – the Transferee and the Remaining Party shall be deemed to have incorporated into the Replaced Document a standard terms supplement (a “Standard Terms Supplement”) as follows: • (a) if Interest Shortfall Cap is specified as applicable or not applicable in the Transaction Record (unless the Master Document Transaction Type is “EuropeanCMBS” or “EuropeanRMBS”), the ISDA Standard Terms Supplement for Use with Credit Derivative Transactions on Mortgage-Backed Security with Pay-As-You-Go or Physical Settlement, as published by the International Swaps and Derivatives Association, Inc. (“ISDA”) as of the date specified in Master Document Date in the Transaction Record. With respect to such Standard Terms Supplement, the following additional elections and provisions shall apply: the Floating Rate Amount/ Notional Amount specified in the Transaction Record shall be the Initial Face Amount for purposes of the Standard Terms Supplement; if the Step-Up Provisions are specified as applicable or not applicable in the Transaction Record, Distressed Ratings Downgrade shall be deemed to be specified as an Additional Credit Event; otherwise, no Additional Credit Event shall be deemed to be specified; and if the WAC Cap Interest Provision is specified as applicable or not applicable in the Transaction Record, CMBS Convention shall be deemed to be specified for purposes of the Standard Terms Supplement; otherwise Not CMBS Convention shall be deemed to be specified. • (b) if Secured List Applicable is specified as applicable or not applicable in the Transaction Record or if “Standard LCDS Bullet” is specified in Master Document Transaction Type, the Syndicated Secured Loan Credit Default Swap Standard Terms Supplement or the Bullet Syndicated Secured Loan Credit Default Swap Standard Terms Supplement, as the case may be, as published by ISDA as of the date specified in Master Document Date in the Transaction Record. • (c) if “CDSonLeveragedLoans” is specified in Master Document Transaction Type, the ISDA Standard Terms Supplement for Use with Credit Derivative Transactions on Leveraged Loans, as published by ISDA as of the date specified in Master Document Date in the Transaction Record. Formatted: Font color: Black

• (d) if “EuropeanCMBS” is specified in Master Document Transaction Formatted: Bullets and Numbering Type, the ISDA Standard Terms Supplement for Use with Credit Derivative Transactions on Mortgage-Backed Security with Pay-As- You-Go or Physical Settlement, as published by ISDA as of the date specified in Master Document Date in the Transaction Record. With respect to such Standard Terms Supplement, the following additional elections and provisions shall apply: the Floating Rate Amount/ Notional Amount specified in the Transaction Record shall be the Initial Face Amount for purposes of the Standard Terms Supplement; CMBS Convention shall be applicable; and Distressed Ratings Downgrade shall be an Additional Credit Event. Formatted: Bulleted + Level: 2 + Aligned at: • (e) if “EuropeanRMBS” is specified in Master Document Transaction 108 pt + Tab after: 126 pt + Indent at: 126 pt Type, the ISDA Standard Terms Supplement for Use with Credit Formatted: Bullets and Numbering Derivative Transactions on Mortgage-Backed Security with Pay-As- You-Go or Physical Settlement, as published by ISDA as of the date Formatted: Bullets and Numbering specified in Master Document Date in the Transaction Record. With respect to such Standard Terms Supplement, the following additional elections and provisions shall apply: the Floating Rate Amount/ Notional Amount specified in the Transaction Record shall be the Initial Face Amount for purposes of the Standard Terms Supplement; Not CMBS Convention shall be applicable; and Distressed Ratings Downgrade shall be an Additional Credit Event. Formatted: Bullets and Numbering Formatted: Font color: Auto Formatted: Indent: Left: 108 pt Users agree that data elements specified in certain fields may be overwritten by the System as set forth in these Operating Procedures or other publications of the Company from time to time.

The Company shall not be responsible for a User’s failure to properly identify the Master Agreement or relevant Standard Terms Supplement, as applicable.

Matching Process:

The Transferor, the Transferee, and the Remaining Party will submit records that collectively identify the Old Transaction, describe the terms of the assignment, and detail the terms of the New Transaction. Each assignment transaction record submitted is matched against the submissions of the two other parties. Regardless of the submission order, the Transferor and Transferee records are matched first; then, the Remaining Party record is compared with this matched pair of records. Only when all three records match

is the status of the assignment “Confirmed”. When only the Transferee and Transferor records match, the status of the assignment is “Matched”.

Certain Trade Record Data Elements are not shown to all parties to the Novation Transaction.

Novation Confirmation Items:

The Transaction Record Data Elements set forth in a Transaction Record cover the items set forth in the Novation Confirmation. Except as otherwise indicated herein, capitalized terms used herein but not defined herein are used as defined in the Novation Confirmation. Paragraph numbers indicated below correspond to the paragraph numbers in the Novation Confirmation.

Paragraph 1:

▪ The appropriate ISDA definitional booklet referenced in Item 1 is the 2003 ISDA Credit Derivatives Definitions.

Paragraph 2:

▪ Novation Date is the equivalent of Novation Date in the Transaction Record Data Elements.

▪ Novated Amount is the equivalent of Novated Amount, Currency in the Transaction Record Data Elements.

▪ Where a Transaction Record does not designate a Remaining Party 2, Transferor, Transferee and Remaining Party are the equivalents of Transferor, Transferee and Remaining Party, respectively, in the Transaction Record Data Elements. Where a Transaction Record does designate a Remaining Party 2, Transferor 1 is the equivalent of the Transferor in the Transaction Record Data Elements; Transferor 2 is the equivalent of the Remaining Party in the Transaction Record Data Elements; Transferee 1 is the equivalent of Transferee in the Transaction Record Data Elements; and Transferee 2 is the equivalent of Remaining Party 2 in the Transaction Record Data Elements.

▪ New Agreement is the ISDA Master Agreement referred to in the applicable Transaction Record. The Users’ obligations to each other under the New Transaction shall be governed by the governing law of the New Master Documents.

Paragraph 3:

In lieu of attaching a copy of the Old Confirmation to the Novation Confirmation, the parties agree to specify the information that would otherwise have been contained in the Old Confirmation by electronically designating both the date of the relevant Standard Terms Supplement and the transaction terms that were (or but for electronic confirmation of the Old Transaction would have been) specified in a related Confirmation (or similar document not so named).

The terms of the Old Transaction are so specified for identification purposes only, and shall not be effective to retroactively change the terms of the Old Transaction being assigned. Users are responsible for assuring that these elements are sufficient to uniquely identify the Old Transaction to be assigned.

As set forth in the “Field Parameters” worksheet applicable to this Appendix, as published by the Company from time to time, or in the Applicable Publications, certain Transaction Record Data Elements relating to the Old Transaction are subject to matching for all parties to the Novation Confirmation and certain Transaction Record Data Elements are, when used, subject to matching for the Transferor and Remaining Party only.

Paragraph 4:

In lieu of attaching a copy of the New Confirmation to the Novation Confirmation, the parties agree to specify the information that would otherwise have been contained in the New Confirmation by electronically designating both the date of the relevant Standard Terms Supplement and the transaction terms that would otherwise have been specified in a related Confirmation (or similar document not so named).

As set forth in the “Field Parameters” worksheet applicable to this Appendix, as published by the Company from time to time, or in the Applicable Publications, certain Transaction Record Data Elements relating to the New Transaction are subject to matching for all parties to the Novation Confirmation and certain Transaction Record Data Elements are, when used, subject to matching for the Transferor and Remaining Party only.

Paragraph 7:

Given that the Novation Transaction is being confirmed through the System, the parties agree that the Notice Details are not necessary for completion of the Novation Confirmation.

Paragraph 8:

In lieu of Paragraph 8, the parties agree as follows: The parties confirm their acceptance to be bound by a Novation Confirmation as of the Novation Date by submitting Transaction Records through the System. The Transferor, by so submitting Transaction Records, agrees to the terms of the Novation Confirmation as it relates to each Old Transaction. The Transferee, by so submitting Transaction Records, agrees to the terms of the Novation Confirmation as it relates to each New Transaction.

Eligible Transaction governed by this Transaction Record Description and referencing the relevant Master Documents shall (1) have the same legal effect as a fully executed Replaced Document entered into pursuant to and subject to the terms of such Master Documents and (2) evidence a novation transaction agreed among the Transferor, Transferee and Remaining Party whose terms and provisions will be set forth in, governed by, construed in accordance with and subject to the Confirmed Transaction Records themselves, such Master Documents, Novation Confirmation and these Operating Procedures, including this Transaction Record Description.

Transaction Record Data Elements:

The data elements specified in the “Field Parameters” worksheet that are applicable to this Appendix set out information relating to certain data elements that Users will be required to provide. In addition, Users may indicate that the Independent Amount applicable to the Eligible Transaction to which the Transaction Record relates is linked to another transaction confirmed through the System (the “Linked Transaction”) by specifying “Linked to [trade id of Linked Transaction]” in the data elements “Additional Terms” or “New Additional Terms”. In the event such Linked Transaction is terminated, novated or otherwise amended, the Independent Amount may be reassessed in the sole discretion of the counterparty to the party with respect to which the Independent Amount applies (the “Independent Amount Determining Party”). Such reassessment shall be effective immediately upon the date of termination, novation or amendment of the Linked Transaction, unless otherwise delayed beyond such date by the Independent Amount Determining Party. The foregoing may be amended in accordance with, and is subject to, any relevant contract between the parties.

Transaction Record Description for Increases

Replaced Document and Data Elements:

The Replaced Document in respect of increases shall in all cases be an increase agreement that would have been fully executed between the parties to a transaction in an Eligible Product that is being increased (where the Eligible Product was confirmed through the System). The purpose of the increase agreement would be to evidence: the identity of the transaction being increased, the effective date of the termination in part, the increase in the notional amount, the outstanding notional amount after the increase, and the payment, if any, to be made between the parties in connection with the increase. Notwithstanding any provision in any document evidencing and/or governing any transaction in an Eligible Product intended to be increased, each User agrees that the submission of Transaction Records by it and any other User through the System for increase of such transaction shall constitute an acceptable method under such document(s) for evidencing and confirming the increase of such transaction. Each User further agrees that Confirmed Transaction Records designating the product and transaction type governed by this Transaction Record Description and relating to the increase of a transaction in an Eligible Product shall constitute such User’s agreement to increase such transaction as of the Increase Effective Date identified in such Confirmed Transaction Records and to receive or pay the Payment Amount identified in such Confirmed Transaction Records on the Payment Settlement Date identified in such Confirmed Transaction Records.

Where the transaction being increased was originally confirmed through the System, it will be identified by User Trade Reference Numbers for the original transaction, which numbers are recorded by the System for each Confirmed Transaction Record. Where the transaction being increased was not originally confirmed through the System, (i) if the original transaction has been submitted to the System but is not yet confirmed, Users will be able to input Transaction Record Data Elements regarding the increase into the System, but such Transaction Record Data Elements will not be viewed by counterparties until the original transaction is confirmed through the System, and (ii) if the original transaction has not been submitted to the System, the increase will be rejected by the System.

The transaction that is being increased is increased to the extent of the increase in notional amount indicated in the relevant Confirmed Transaction Record that corresponds to the data element named “Affected Notional Amount”, with the outstanding Floating Rate Payer Calculation Amount effective after the effective date of the increase being the amount indicated in the relevant Confirmed Transaction Record that corresponds to the data element named “Outstanding Notional Amount”, in each case, specified in the “Field Parameters” worksheet applicable to this Appendix, as published by the Company from time to time.

Transaction Record Description for Amendments

Replaced Document:

The Replaced Document for amendments of Eligible Products shall in all cases be a “Confirmation” (or any similar document not so named) that is referred to (or described) in a standard terms supplement, and that has been executed by two Users for the purpose of evidencing such amendments between them (each, a “Confirmation”). Related Master Documents shall be:

Credit Event; otherwise, no Additional Credit Event shall be deemed to be specified; and if the WAC Cap Interest Provision is specified as applicable or not applicable in the Transaction Record, CMBS Convention shall be deemed to be specified for purposes of the Standard Terms Supplement; otherwise Not CMBS Convention shall be deemed to be specified. • (b) if Secured List Applicable is specified as applicable or not applicable in the Transaction Record or if “Standard LCDS Bullet” is specified in Master Document Transaction Type, the Syndicated Secured Loan Credit Default Swap Standard Terms Supplement or the Bullet Syndicated Secured Loan Credit Default Swap Standard Terms Supplement, as the case may be, as published by ISDA as of the date specified in Master Document Date in the Transaction Record. • (c) if “CDSonLeveragedLoans” is specified in Master Document Transaction Type, the ISDA Standard Terms Supplement for Use with Credit Derivative Transactions on Leveraged Loans, as published by ISDA as of the date specified in Master Document Date in the Transaction Record. Formatted: Font color: Black • (d) if “EuropeanCMBS” is specified in Master Document Transaction Formatted: Bullets and Numbering Type, the ISDA Standard Terms Supplement for Use with Credit Derivative Transactions on Mortgage-Backed Security with Pay-As- You-Go or Physical Settlement, as published by ISDA as of the date specified in Master Document Date in the Transaction Record. With respect to such Standard Terms Supplement, the following additional elections and provisions shall apply: the Floating Rate Amount/ Notional Amount specified in the Transaction Record shall be the Initial Face Amount for purposes of the Standard Terms Supplement; CMBS Convention shall be applicable; and Distressed Ratings Downgrade shall be an Additional Credit Event. Formatted: Bullets and Numbering • (e) if “EuropeanRMBS” is specified in Master Document Transaction Formatted: Bullets and Numbering Type, the ISDA Standard Terms Supplement for Use with Credit Derivative Transactions on Mortgage-Backed Security with Pay-As- You-Go or Physical Settlement, as published by ISDA as of the date specified in Master Document Date in the Transaction Record. With respect to such Standard Terms Supplement, the following additional elections and provisions shall apply: the Floating Rate Amount/ Notional Amount specified in the Transaction Record shall be the Initial Face Amount for purposes of the Standard Terms Supplement; Not CMBS Convention shall be applicable; and Distressed Ratings Downgrade shall be an Additional Credit Event.

Formatted: Font color: Auto Formatted: Bulleted + Level: 2 + Aligned at: Users agree that data elements specified in certain fields may be overwritten by the 108 pt + Tab after: 126 pt + Indent at: 126 pt System as set forth in these Operating Procedures or other publications of the Company from time to time. Formatted: Bullets and Numbering

The Company shall not be responsible for a User’s failure to properly identify the Master Agreement or relevant Standard Terms Supplement.

Notwithstanding any provision in the related Master Documents, each User agrees that the submission of Transaction Records by it and any other User through the System shall constitute an acceptable method under such Master Documents for evidencing and confirming the terms to be specified in any Confirmation referenced in or to be governed by such Master Documents. Each User further agrees that Confirmed Transaction Records designating the Eligible Product and Eligible Transaction governed by this Transaction Record Description and referencing the relevant Master Documents shall (1) have the same legal effect as a fully executed Replaced Document entered into pursuant to and subject to the terms of such Master Documents and (2) shall evidence an amended and restated credit default swap transaction agreed between two Users whose terms and provisions will be set forth in, governed by, construed in accordance with and subject to the Confirmed Transaction Records themselves, such Master Documents and these Operating Procedures, including this Transaction Record Description.

The governing law of the Master Documents shall also govern the obligations created by any Transaction Record.

Amendments Processing:

Any terms of the original trade may be changed through the amendment process with the exception of the parties to the trade (although the trade direction (i.e., which party is the Buyer and which is the Seller) may be changed). An amendment Transaction Record includes all the fields of a new trade plus Amendment Trade Date, Amendment Effective Date, and the fields required to describe the payment, if any, associated with the amendment (Payer, Payment Date, and Payment Amount). The identification of the parties to the trade (submitter or counterparty), but not the trade direction, submitted on an amendment Transaction Record must be the same as the original confirmed trade, or the Transaction Record will be rejected.

Provisions of the transaction as amended are set forth as if a new Confirmation were executed. Amendment Trade Date sets forth the trade date of the amendment, and Amendment Effective Date sets forth the effective date of the amendment. Otherwise, the Transaction Record amends and restates the amended trade. The optional fields that

describe the payment specify which party pays the other party.

Amendment transactions will only be accepted for transactions that are confirmed in the System. If an amendment is submitted with a transaction reference number that is not found in the Company’s database or is associated in the Company’s database with an unconfirmed transaction of any type (including new trades, terminations and assignments), the Transaction Record will be rejected.

Transaction Record Data Elements:

Rev. 2011-21 (Release Date January 28February 28, 2011) Appendix K to MarkitSERV Operating Procedures

TRANSACTION RECORD DESCRIPTION: SINGLE REFERENCE ENTITY CREDIT DEFAULT SWAP INCORPORATING ISDA CREDIT DERIVATIVES PHYSICAL SETTLEMENT MATRIX

Eligible Product: Single Reference Entity Credit Default Swap incorporating the ISDA Credit Derivatives Physical Settlement Matrix (“Single Entity Matrix Transaction”)

Eligible Transactions: New Trades Partial Terminations (can apply to all Single Entity Matrix Transactions, regardless of whether the partially terminated trade was originally confirmed through the System) Assignments (except as set forth below, can apply to all Single Entity Matrix Transactions, regardless of whether the assigned trade was originally confirmed through the System) Increases (can apply only to Single Entity Matrix Transactions where the increased trade was originally confirmed through the System) Amendments (can apply only to Single Entity Matrix Transactions where the amended trade was originally confirmed through the System)

Transaction Record Description for New Trades

Replaced Document:

The Replaced Document for new trades in the Eligible Product shall in all cases be a “Confirmation” (or any similar document not so named) that has been executed by two Users for the purpose of evidencing such new trades between them (each, a “Confirmation”). The provisions of this Appendix K shall only apply to Single Entity Matrix Transactions for which “CreditDerivativesPhysicalSettlementMatrix” (or any other term for this purpose specified by the Company) is specified in the applicable “Documentation Type” field of the Transaction Record. Related Master Documents shall be:

• Master Agreement –identified by date and type pursuant to the Transaction Record– consisting of an ISDA Master Agreement (or other applicable type of master agreement described below) that has been executed by the relevant two Users. Any reference in a Transaction Record to a Master Agreement shall be to the Master Agreement as it may have been, and may subsequently be, amended, supplemented or modified by the parties thereto. With respect to such other Master Agreement types specified in Data Element 11: • If the Master Agreement Type is “German”, the German Master Agreement for Financial Derivatives Transactions (Rahmenvertrag für Finanztermingeschäfte) • If the Master Agreement Type is “AFB”, the AFB/FBF Convention-cadre relative aux opérations de marché à terme. • If the Master Agreement Type is “Swiss”, the Swiss Master Agreement for over-the-counter (OTC) Derivatives. • If the Master Agreement Type is “ICETrustUS”, the ICE Trust U.S. L.L.C. Standard Terms Annex to the ISDA Master Agreement. • If the Master Agreement Type is “ICEClearEurope”, the ICE Clear Europe Standard Terms Annex to the ISDA Master Agreement.

The Users shall be deemed to have incorporated into the Replaced Document the definitions and provisions contained in the 2003 ISDA Credit Derivatives Definitions, as supplemented by the May 2003 Supplement and the 2005 Matrix Supplement (the “Matrix Supplement”) to the 2003 ISDA Credit Derivatives Definitions (as so supplemented, the “Definitions”), each as published by the International Swaps and Derivatives Association, Inc. (“ISDA”) and available at www.isda.org; provided that notwithstanding Section 11.2 of the Matrix Supplement, the Credit Derivatives Physical Settlement Matrix shall be the Credit Derivatives Physical Settlement Matrix (or any successor document) (the “ISDA Matrix”) published as of the date specified in “Master Document Date” (or, if no date is specified therein, the most recent ISDA Matrix published as of the Trade Date). In the event of any inconsistency between the Definitions and the Replaced Document, the Replaced Document shall govern. The Users agree that the Replaced Document shall supplement, form a part of, and be subject to the applicable Master Documents. All provisions contained in, or incorporated by reference in, the Master Documents shall govern the Replaced Document except as expressly modified herein or therein.

Solely with respect to Transaction Records for New Trades in Single Entity Matrix Transactions (other than Excluded Transactions) with a Trade Date on or after July 27, 2009 but for which the specified ISDA Matrix was published prior to July 27, 2009, notwithstanding anything to the contrary herein, in the specified ISDA Matrix or in a Transaction Record, but without derogation of any other relevant term of the Matrix Supplement or ISDA Matrix, the Users shall be deemed to have (i) incorporated into the Replaced Document the 2009 ISDA Credit Derivatives Determinations Committees, Auction Settlement and Restructuring Supplement to the 2003 ISDA Credit Derivatives Definitions, as published by ISDA on July 14, 2009 (the “July 2009 Auction

Supplement”) (and, unless the context otherwise requires, references therein to the 2003 ISDA Credit Derivatives Definitions shall be deemed to refer to such definitions as supplemented by the July 2009 Auction Supplement) and (ii) specified Auction Settlement as the Settlement Method and Physical Settlement as the Fallback Settlement Method.

With respect to Transaction Records with a Master Document Transaction Type of Standard North American Corporate, Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Japan Corporate, Standard Japan Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, Users agree that data elements specified in certain fields may be overwritten by the System as set forth in these Operating Procedures or other publications of the Company from time to time. As used herein, “Excluded Transactions” are Single Entity Matrix Transactions with a Master Document Transaction Type of “USMunicipalFullFaithAndCredit”, “USMunicipalGeneralFund”, or “USMunicipalRevenue”.

The Company shall not be responsible for a User’s failure to properly identify a transaction as subject to this Appendix K, to properly identify the Master Agreement, the Matrix Supplement or the applicable ISDA Matrix (or any relevant terms thereunder) or to take into account the provisions of the preceding paragraph.

Notwithstanding any provision in the related Master Documents, each User agrees that the submission of Transaction Records by it and any other User through the System shall constitute an acceptable method under such Master Documents for evidencing and confirming the terms to be specified in any Confirmation referenced in or to be governed by such Master Documents. Each User further agrees that Confirmed Transaction Records designating the Eligible Product and Eligible Transaction governed by this Transaction Record Description and referencing the relevant Master Documents shall (1) have the same legal effect as a fully executed Replaced Document entered into pursuant to and subject to the terms of such Master Documents and (2) shall evidence a new credit default swap transaction agreed between two Users whose terms and provisions will be set forth in, governed by, construed in accordance with and subject to the Confirmed Transaction Records themselves, such Master Documents and these Operating Procedures, including this Transaction Record Description.

The governing law of the Master Documents shall also govern the obligations created by any Transaction Record.

Transaction Record Data Elements:

Each Transaction Record governed by this Transaction Record Description will include the data elements set out in the table below, which shall have the meanings set forth or contemplated in the relevant Master Documents (unless the context clearly indicates an intent to identify product and transaction type, trade reference numbers, a transaction date or the Master Documents themselves), including meanings that may be set forth in the Applicable Publications or any other resource identified in the Master Documents (e.g., designated ISDA Credit Derivatives Definitions). Transaction Records that do not contain required values for certain data elements will be rejected by the System. In the event of any inconsistency between a Transaction Record and the relevant Master Documents, the Transaction Record shall govern (unless otherwise agreed between Users). The table below sets forth information relating to certain data elements that Users will be required to provide. Actual Transaction Records submitted by Users may be different in terms of appearance and in the manner in which information is to be provided (e.g., data elements may be specified in FpML). Users should consult the Applicable Publications for further information on the inputting of data.

Required/Optional/ Matching # Data Element Name Means of Specifying Information Validation Conditional (R/O/C) (Y/N)* 1Transaction Type R Y New Trades Company will maintain a table of valid Transaction Type identifiers

2Product Type R Y Specify “CreditDefaultSwapShort” “CreditDefaultSwapShort”

3Submitting User Trade Reference R N Unique identifier input by User 40 character limit Number 4Submitting User Message ID O N Users may include an additional processing number 70 character limit for internal purposes (e.g., tracking) 5Super ID O N Identifier that may be used to group or link related 40 character limit transactions 6Desk ID O N Identifier that may be used to identify the relevant Valid identifier desk that executed the transaction 7Designated Party ID O N Identifier that may be used by prime brokers to 20 character limit identify the prime broker’s relevant customer with respect to the transaction 8E-trading TRN O N Transaction identifier assigned to the transaction by 40 character limit an applicable execution platform (e.g., TradeWeb or Market Axess) 9Broker Name O N Identifier that may be used to identify any applicable 40 character limit broker with respect to the transaction 10Master Document Transaction Type* R Y Specify the applicable Master Document Transaction The applicable valid values in the list maintained Type as set forth in the list maintained by the by the Company from time to time. * Company from time to time. 11Master Agreement Type R Y Specify “AFB, “German”, “ISDA”, “Swiss”, “AFB, “German”, “ISDA”, “Swiss”, “ICETrustUS”, “ICETrustUS”, “ICEClearEurope” or “Other” “ICEClearEurope” or “Other” 12Master Agreement Date R Y Identified by date of Master Agreement Valid date format 13Documentation Type R Y Specify “CreditDerivativesPhysicalSettlementMatrix” “CreditDerivativesPhysicalSettlementMatrix” 14Master Document Date* O Y Identified by date of publication of the relevant ISDA Valid date format Matrix

15Calculation Agent* R Y Specify company number assigned to relevant party Company number assigned to relevant party or or “As specified in Master Agreement” “As specified in Master Agreement” 16Trade Date R Y Any date Valid date format 17Effective Date* R Y Any date Valid date format 18Scheduled Termination Date* R Y Any date Valid date format

Required/Optional/ Matching # Data Element Name Means of Specifying Information Validation Conditional (R/O/C) (Y/N)* 19Floating Rate Payer ("Seller")* R Y Company number assigned to User Company will maintain table of User IDs 20Fixed Rate Payer ("Buyer")* R Y Company number assigned to User Company will maintain table of User IDs 21Reference Entity* R Y Identified by unique identifier maintained in Company will validate against unique Reference Company’s Reference Entity database and by text Entity database identifiers. 250 character limit for legal name. text legal name.* Only one Reference Entity permitted. 22Reference Obligation* R Y Identified by ISIN. Credit Default Swaps with Correct number and type of characters for ISIN. Reference Obligations that cannot be identified by Only one Reference Obligation permitted. ISIN cannot be processed through use of this System will not validate against Company’s own Transaction Record. internal list of ISIN numbers.

23First Payment Date; Payment C- optional if Item 28 Y One date and a frequency -- the First Payment Date Valid date format and an integer from 0 through Frequency (Fixed Rate Payer is submitted; specified will be the first Fixed Rate Payer Payment 12 Payment Date(s))* otherwise required Date; the frequency will specify the number of months between payments (e.g., 6 for semi-annual, 3 for quarterly, etc.), with the last scheduled payment date being the Scheduled Termination Date. Each Fixed Rate Payer Payment Date after the first shall be determined by starting with the Scheduled Termination Date and working backwards to the first Fixed Rate Payer Payment Date. 24Fixed Rate* C- optional if Item 28 Y Expressed as a percentage (numerical - 5.550 would Any decimal number with up to 3 digits to the left is submitted; match 5.55) of the decimal point and up to 8 to the right otherwise required 25Floating Rate Payer Calculation R Y Positive integer and currency Positive integer and ISO currency code Amount* 26Restructuring Credit Event R* Y "Applicable" or "Not Applicable" "Applicable" or "Not Applicable" 27Independent Amount* O Y Expressed as a Percentage (numerical - Any decimal number with up to 3 digits to the left 5.550 would match 5.55); in addition, credit of the decimal point and up to 5 to the right; support provider (payer) and credit support Company will maintain table of User IDs to be receiver (receiver) would be indicated by used for payer and receiver Company number assigned to the relevant User 28Single/Initial Payment * O Y Positive integer, date and, if necessary, identification Positive integer, valid date format and, if of payer by Company assigned ID necessary, Company assigned ID of payer 29Calculation Agent City * O Y Identified by ISDA identifier Validated against ISDA list of business centers* 30First Payment Period Accrual Start O Y Any date Valid date format Date *

Required/Optional/ Matching # Data Element Name Means of Specifying Information Validation Conditional (R/O/C) (Y/N)* 31Additional Matrix Provisions* O Y Specify “ISDA2003CreditMonolineInsurers2005”, “ISDA2003CreditMonolineInsurers2005”, “ISDA2003DeliveryRestrictions”, or “ISDA “ISDA2003DeliveryRestrictions”, or “ISDA 2003SecuredDeliverableObligationCharacteristic” or 2003SecuredDeliverableObligationCharacteristic” “ISDA2010FixedRecovery” (or other applicable valid or “ISDA2010FixedRecovery” (or other applicable value), if applicable. valid value) 32Recovery Price C-required if Y Expressed as a percentage Any decimal number with up to 3 digits to the left “ISDA2010FixedRec of the decimal point and up to 8 digits to the right. overy” is specified in Item 31; otherwise, not allowed 332Additional Terms* O Y Text 255 character limit 343Comment* O N Text 250 character limit

*The following Notes apply to the above table: • General: No data element subject to matching will have a matching tolerance. All such data elements must match exactly. • Valid date format: Valid date formats will be set forth in the Applicable Publications. • Item 10, Master Document Transaction Type: This refers to a “Transaction Type” that would otherwise be specified in a written Confirmation. The related ISDA Matrix provides that certain terms apply to the subject Eligible Transaction depending on the designated Transaction Type. The Company may, by Important Notice, amend the available categories of Master Document Transaction Types that may be specified in a Transaction Record, including to reflect amendments to the ISDA Matrix. • Item 14, Master Document Date: This refers to the date of publication of the applicable ISDA Matrix. If this item is left blank, the Users will be deemed to have incorporated the ISDA Matrix most recently published as of the Trade Date. Notwithstanding the foregoing, (i) in the case of a Single Entity Matrix Transaction that results from the occurrence of a restructuring credit event with respect to a component reference entity in an index credit default swap transaction relating to an iTraxx Europe index or an iTraxx Japan index, if this item is left blank and the Trade Date is prior to the publication date of the first ISDA Matrix that includes the relevant Transaction Type for such Single Entity Matrix Transaction, the Master Document Date will be the publication date of the first ISDA Matrix that includes such Transaction Type, (ii) in the case of Master Document Transaction Type "Latin American Corporate B", if this item is left blank, the Users will be deemed to have incorporated the ISDA Matrix most recently published as of the Trade Date of the Transaction, provided, however, that if the Transaction is subject to a version which precedes February 1, 2007, the terms affiliated with the Latin America Corporate Transaction Type shall apply and (iii) in the case of Master Document Transaction Types, "Sukuk Corporate",

"Sukuk Sovereign", "Standard Sukuk Corporate" and "Standard Sukuk Sovereign", Users will be deemed to have incorporated the later of (a) the ISDA Matrix most recently published as of the Trade Date of the Transaction and (b) the ISDA Matrix dated November 8, 2010 that first included these Master Document Transaction Types. • Item 15, Calculation Agent: If “As specified in Master Agreement” is specified in Item 15, the Calculation Agent will be the party identified as such pursuant to the Master Agreement. In other cases, the party identified as the Calculation Agent must be a party to the transaction. • Item 17, Effective Date: Any identification of Effective Date shall mean the exact date identified regardless of any business day convention adopted in any Master Document. Where the Master Document Transaction Type is Standard North American Corporate, Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Japan Corporate, Standard Japan Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, the data in this field will be overwritten to be the calendar day following the Trade Date. • Item 18, Scheduled Termination Date: If the Master Document Transaction Type is Standard North American Corporate, Standard European Corporate, Standard Subordinated European Insurance Corporate or Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Japan Corporate, Standard Japan Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, this date must be one of March 20, June 20, September 20 or December 20 (each, a “Quarterly Roll Date”). • Items 19 and 20, Floating Rate Payer (“Seller”) and Fixed Rate Payer (“Buyer”): These are the designations of the Users that are parties to the transaction. The submitted transmission must be identified as originating from the Family of either the Seller or the Buyer, or it will not be accepted. • Item 21, Reference Entity: The Reference Entity identifiers referred to in the above table will be provided by a vendor designated by the MarkitSERV Board (including any successor oversight body). Initially such vendor shall be Markit Group, who will provide 6 digit identifiers for each Reference Entity maintained in their database. The

System will accept either the 6 digit identifiers or else 9 digit identifiers (also provided by Markit Group, with the first 6 digits identifying the Reference Entity and the last 3 linking the Reference Entity to a Reference Obligation). All Users with access to the identifiers provided by the designated vendor shall be obliged to submit them in their Transaction Records. The System will match identifiers and names as follows: (i) if names and identifiers are submitted, both must match; if one party submits only a name (permissible only if that party does not have access to the identifiers), then only the names must match; (ii) the system will match 6 digit and 9 digit identifiers exactly; if one party submits a 6 digit identifier and the other a 9 digit identifier, then the System will match the 6 digit identifier against the first 6 digits of the 9 digit identifier; (iii) the system will convert text names to all capital letters and will match the names, including punctuation and spacing exactly. As an operational matter, the Company will, with respect to transactions between Users who have access to the identifiers and Users who do not, periodically check identifiers submitted by Users with access against the names associated with them in its database (as supplied by the designated vendor) and will inform such Users of any apparent discrepancies between the text names submitted by such Users and the names in the Company’s database. • Item 22, Reference Obligation: A Transaction Record may indicate that the Eligible Transaction has no Reference Obligation by using the following “dummy” ISIN in place of a Reference Obligation identifier: XSNOREFOBL00. • Item 23, First Payment Date, Payment Frequency (Fixed Rate Payer Payment Date(s)): These fields are used to determine the Fixed Rate Payer Payment Dates as set forth above, and will be ignored if the Fixed Rate is zero. If the Master Document Transaction Type is Standard North American Corporate, Standard European Corporate, Standard Subordinated European Insurance Corporate or Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Japan Corporate, Standard Japan Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, these fields will be overwritten such that the specified First Payment Date will be the first Quarterly Roll Date following the calendar day after the Trade Date and the Payment Frequency will be three months. • Item 24, Fixed Rate: If the Master Document Transaction Type is Standard North American Corporate, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Sukuk Corporate or Standard Sukuk

Sovereign, the Fixed Rate must be either 1.00% or 5.00%. If the Master Document Transaction Type is Standard European Corporate, Standard Subordinated European Insurance Corporate or Standard Western European Sovereign, the Fixed Rate must be 0.25%, 1.00%, 3.00%, 5.00%, 7.50% or 10.00%. If the Master Document Transaction Type is Standard Japan Corporate or Standard Japan Sovereign, the Fixed Rate must be either 0.25%, 1.00% or 5.00%. • Item 25, Floating Rate Payer Calculation Amount: If the Master Document Transaction Type is Standard North American Corporate, Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Japan Corporate, Standard Japan Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, the currency must be one of the applicable currencies specified in the ISDA Matrix for that transaction type. • Item 26, Restructuring Credit Event: If the Master Document Transaction Type is not North American Corporate or Standard North American Corporate, Restructuring must be applicable. • Item 27, Independent Amount: A Transaction Record relating to an Eligible Transaction may indicate the Independent Amount (as defined in the governing Credit Support Annex, or similar document not so named, relating to the Master Agreement). The Independent Amount must be expressed as a percentage and should be understood as a percentage of the Floating Rate Payer Calculation Amount. If an Independent Amount is indicated, the parties must also identify the credit support provider (payer) and credit support receiver (receiver) by Company assigned ID, similar to how Buyer and Seller are designated. One or another of the Buyer or Seller must also be the credit support provider or receiver. If an Independent Amount is not indicated, it does not mean that there is no Independent Amount, rather that any Independent Amount applicable to the transaction or a portfolio containing the transaction is specified in a different document (e.g., an applicable Credit Support Annex, Master Agreement or similar document) and is not specified in the related Transaction Record. Users may indicate that the Independent Amount applicable to the Eligible Transaction to which the Transaction Record relates is linked to another transaction confirmed through the system (the “Linked Transaction”) by specifying “Linked to [trade id of Linked Transaction]” in Item 32. In the event such Linked Transaction is terminated, novated or otherwise amended, the Independent Amount may be reassessed in the sole discretion of the counterparty to the party with respect to which the Independent Amount applies (the “Independent Amount Determining Party”). Such reassessment shall be effective immediately upon the date of termination, novation or amendment of the

Linked Transaction, unless otherwise delayed beyond such date by the Independent Amount Determining Party. The foregoing may be amended in accordance with, and is subject to, any relevant contract between the parties. • Item 28, Single/Initial Payment: Indicates the amount of an agreed payment owed by one party to the other party on the date specified. If the Buyer is payer, the parties do not need to identify the payer or payee as the System will automatically identify the Buyer as payer and the other party as payee. If the Seller is payer, the Transaction Record must identify the payer by use of the Company assigned ID. The currency shall be identical to the currency of the Floating Rate Payer Calculation Amount, which, if the Master Document Transaction Type is Standard North American Corporate, Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Japan Corporate, Standard Japan Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, must be one of the applicable currencies specified in the ISDA Matrix for that transaction type. An initial payment shall be in lieu of or in addition to the payments determined by items 23 and 24. If the Master Document Transaction Type is Standard North American Corporate, Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Japan Corporate, Standard Japan Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, the payment date will be overwritten to be the third Business Day following the Trade Date. • Item 29, Calculation Agent City: The Calculation Agent City may be identified by codes used for FpML purposes and published by ISDA. The Company may, after Important Notice issued in accordance with these Operating Procedures, choose to validate submissions against these codes. If this field is left blank, the System will automatically specify the Calculation Agent City based on the applicable default set forth in the ISDA Matrix. If the Master Document Transaction Type is Standard North American Corporate, this field will be overwritten with the applicable business center set forth in the ISDA Matrix for such transaction type. If the Master Document Transaction Type is Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging

European Corporate, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, this field will be overwritten to be London. If the Master Document Transaction Type is Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan or Standard Latin America Sovereign, this field will be overwritten to be New York. If the Master Document Transaction Type is Standard Japan Corporate or Standard Japan Sovereign, this field will be overwritten to be Tokyo. • Item 30, First Payment Period Accrual Start Date: If a date is specified, the first Fixed Rate Payer Calculation Period will commence on, and include, such date. If specified, the First Payment Period Accrual Start Date should be a date before the Effective Date. If the Master Document Transaction Type is Standard North American Corporate, Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Japan Corporate, Standard Japan Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, this field will be overwritten to be the Fixed Rate Payer Payment Date falling on or immediately prior to the calendar day immediately following the Trade Date (and for this purpose, Section 2.10 of the 2003 ISDA Credit Derivatives Definitions will be deemed amended by deleting the words “during the term of the Transaction”). • Item 31, Additional Matrix Provisions: Optional. For a fixed recovery swap, “ISDA2010FixedRecovery” must be specified. “ISDA2003CreditMonolineInsurer2005”, “ISDA2003DeliveryRestrictions”, or “ISDA2003SecuredDeliverableObligationCharacteristic” may only be specified if Master Document Transaction Type is North American Corporate or Standard North American Corporate. Notwithstanding anything to the contrary in the Operating Procedures, if the Reference Entity specified in a Transaction Record is a monoline insurer (determined solely based on its RED code’s matching one of the RED codes on a list maintained for this purpose by the Company from time to time), “ISDA2003CreditMonolineInsurers2005” must be specified in Additional Matrix Provisions. • Item 32, Recovery Price: The specified Recovery Price will be the “Final Price” for purposes of the Additional Provisions for Fixed Recovery CDS Transactions.

• Item 332, Additional Terms: Users may insert up to 255 characters of free text specifying, among other things, additional terms applicable to the transaction (e.g., credit linkage terms). A submission of “N” or “n” as the sole character in this data element will be treated for matching purposes as if the data element had been left blank. • Item 343, Comment: This data element is visible only to each User (and not its counterparty) and will only appear in each such User’s Transaction Record.

Transaction Record Description for Full Terminations

The following shall apply to full termination messages submitted prior to May 7, 2009.

Replaced Document and Data Elements:

The Replaced Document in respect of full terminations shall in all cases be a termination agreement that would have been fully executed between the parties to a Single Entity Matrix Transaction that is being terminated in full (regardless of whether the Single Entity Matrix Transaction was confirmed through the System, outside the system, or through some other means). The purpose of the termination agreement would be to evidence: the identity of the transaction being terminated in full, the effective date of the termination in full and the payment, if any, to be made between the parties in connection with the termination. Notwithstanding any provision in any document evidencing and/or governing any Single Entity Matrix Transaction intended to be terminated, each User agrees that the submission of Transaction Records by it and any other User through the System for full termination of such transaction shall constitute an acceptable method under such document(s) for evidencing and confirming the termination of such transaction. Each User further agrees that Confirmed Transaction Records designating the product and transaction type governed by this Transaction Record Description and relating to the full termination of a transaction in a Single Entity Matrix Transaction shall constitute such User’s agreement to terminate such transaction as of the Termination Effective Date identified in such Confirmed Transaction Records and to receive or pay the Payment Amount identified in such Confirmed Transaction Records on the Payment Settlement Date identified in such Confirmed Transaction Records, and that following such termination and payment, neither party shall have any obligation to the other under such transaction.

Where the transaction being terminated was originally confirmed through the System, it will be identified by User Trade Reference Numbers for the original transaction, which numbers are recorded by the System for each Confirmed Transaction Record. Where the transaction being terminated was not originally confirmed through the System, it will be identified by data elements 17-24 on the below table, which are intended to correspond to the same named items in the transaction being terminated. Users are responsible for assuring that these elements are sufficient to uniquely identify the transaction to be terminated. Matching on items 18-24 are for identification purposes only, and shall not be effective to retroactively change the terms of the transaction being terminated.

Required/Optional/ Matching # Data Element Name Means of Specifying Information Validation Conditional (R/O/C) (Y/N) For All Terminations 1Transaction Type R Y Full Termination Company will maintain a table of valid Transaction Type identifiers.

2Product Type R Y Specify “CreditDefaultSwapShort” “CreditDefaultSwapShort”

3Submitting User Reference R* N* Unique identifier input by User. To terminate a 40 character limit Number for Original Transaction* transaction confirmed through System, must match data element 3 in original Transaction Record.

4Submitting User Message ID O N Users may include in an additional processing 70 character limit number for internal purposes (e.g., tracking)

5Super ID O N Identifier that may be used to group or link related 40 character limit transactions

6Desk ID O N Identifier that may be used to identify the relevant Valid identifier desk that executed the transaction

7Designated Party ID O N Identifier that may be used by prime brokers to 20 character limit identify the prime broker’s relevant customer with respect to the transaction 8E-trading TRN O N Transaction identifier assigned to the transaction by 40 character limit an applicable execution platform (e.g., TradeWeb or Market Axess) 9Broker Name O N Identifier that may be used to identify any applicable 40 character limit broker with respect to the transaction

10Payer* R Y Company number assigned to User Company will maintain a table of User IDs* 11 Payee * R Y Company number assigned to User Company will maintain a table of User IDs* 12Payment Amount R Y Amount of termination payment; matching tolerance Positive Integer of one currency unit 13Payment Currency R Y Currency of termination payment ISO currency code 14Payment Settlement Date R Y Date of termination payment Valid date format

15Termination Trade Date R Y Trade Date of the termination transaction Valid date format 16Termination Effective Date R Y Effective date of termination Valid date format Additional Elements for When Original Trade not in System 17Original Trade Date C - required if terminated N Trade Date of the original transaction Valid date format contract not confirmed through System 18Scheduled Termination Date C Y Scheduled Termination Date of original transaction Valid date format 19Floating Rate Payer ("Seller") C Y Company number assigned to User Company will maintain a table of User IDs 20Fixed Rate Payer ("Buyer") C Y Company number assigned to User Company will maintain a table of User IDs 21Reference Entity* C Y Identified by unique identifier maintained in Company will validate against unique Company’s Reference Entity database. Database Reference Entity database identifiers. Only will link identifier with text name supplied by an one Reference Entity permitted. external supplier, including date of last supplier update 22Reference Obligation * R Y Identified by ISIN. Credit Default Swaps with Correct number and type of characters for Reference Obligations that cannot be identified by ISIN. Only one Reference Obligation ISIN cannot be processed through use of this permitted. System will not validate Transaction Record against Company’s own internal list of ISIN numbers. 23Fixed Rate C Y Original Fixed Rate for terminated trade, expressed Any decimal number with up to 3 digits to as a percentage; (numerical - 5.550 would match the left of the decimal point and up to 8 to 5.55) the right 24Floating Rate Payer Calculation C Y Original notional amount and currency of terminated Positive Integer and ISO currency code Amount trade 25Comment* O N Text 250 character limit

*The following Notes apply to the above table:

• General: Items 17-24 are required for terminations of transactions not originally confirmed through the System, but should not be included in Transaction Records for terminations of transactions originally confirmed through the System. • General: No data element subject to matching will have a matching tolerance other than item 12, which has a matching tolerance of one currency unit (e.g., 1 Euro if the currency is Euro). All other data elements subject to matching must match exactly. • Valid date format: Valid date formats will be set forth in the Applicable Publications.

• Item 3, Submitting User Reference Number for Original Transaction: Although the Submitting User Reference Numbers for Original Transaction that are submitted by the separate parties to a termination need not, and will not, match, the status of Confirmed for a termination of a transaction originally confirmed through the System will require that each such Submitting User Reference Numbers for Original Transaction match exactly data element 3 in the Transaction Record submitted by that User for the original transaction as Confirmed. Where the terminated trade was not originally confirmed through the System, this number will be used solely as the transaction reference number for the termination itself. In that case, this data element will not be used to identify the transaction to be terminated (rather items 17-24 will be so used) and the termination will not be ineffective due to the failure of this number to conform to the actual User trade reference number for the original transaction. • Items 10 and 11, Payer and Payee: These are the designations of the Users that are parties to the transaction. The submitted transmission must be identified as originating from the Family of either the Payer or Payee, or it will not be accepted. • Item 21, Reference Entity: The Reference Entity identifiers referred to in the above table will be provided by a vendor designated by the MarkitSERV Board (including any successor oversight body). Initially such vendor shall be Markit Group, who will provide 6 digit identifiers for each Reference Entity maintained in their database. The System will accept either the 6 digit identifiers or else 9 digit identifiers (also provided by Markit Group, with the first 6 digits identifying the Reference Entity and the last 3 linking the Reference Entity to a Reference Obligation). All Users with access to the identifiers provided by the designated vendor shall be obliged to submit them in their Transaction Records. The System will match identifiers and names as follows: (i) if names and identifiers are submitted, both must match; if one party submits only a name (permissible only if that party does not have access to the identifiers), then only the names must match; (ii) the system will match 6 digit and 9 digit identifiers exactly; if one party submits a 6 digit identifier and the other a 9 digit identifier, then the System will match the 6 digit identifier against the first 6 digits of the 9 digit identifier; (iii) the system will convert text names to all capital letters and will match the names, including punctuation and spacing exactly. As an operational matter, the Company will, with respect to transactions between Users who have access to the identifiers and Users who do not, periodically check identifiers submitted by Users with access against the names associated with them in its database (as supplied by the designated vendor) and will inform such Users of any apparent discrepancies between the text names submitted by such Users and the names in the Company’s database. • Item 22, Reference Obligation: A Transaction Record may indicate that the Eligible Transaction has no Reference Obligation by using the following “dummy” ISIN in place of a Reference Obligation identifier: XSNOREFOBL00. • Item 25, Comment: This data element is visible only to each User (and not its counterparty) and will only appear in each such User’s Transaction Record.

Transaction Record Description for Partial Terminations

Replaced Document and Data Elements:

The Replaced Document in respect of partial terminations shall in all cases be a termination agreement that would have been fully executed between the parties to a Single Entity Matrix Transaction that is being terminated in part or in full (where the outstanding notional amount of the related transaction is reduced to zero). The purpose of the partial termination agreement would be to evidence: the identity of the transaction being terminated in part or in full, the effective date of the termination in part or in full, the decrease in the notional amount, the outstanding notional amount after the partial termination or the reduction of the outstanding notional amount to zero after the full termination, and the payment, if any, to be made between the parties in connection with the termination. Notwithstanding any provision in any document evidencing and/or governing any Single Entity Matrix Transaction intended to be terminated, each User agrees that the submission of Transaction Records by it and any other User through the System for termination of such transaction shall constitute an acceptable method under such document(s) for evidencing and confirming the partial or full termination of such transaction. Each User further agrees that Confirmed Transaction Records designating the product and transaction type governed by this Transaction Record Description and relating to the termination of a Single Entity Matrix Transaction shall constitute such User’s agreement to partially or fully terminate such transaction as of the Partial Termination Effective Date identified in such Confirmed Transaction Records and to receive or pay the Payment Amount identified in such Confirmed Transaction Records on the Payment Settlement Date identified in such Confirmed Transaction Records, and that following such termination and payment, neither party shall have any obligation to the other under such transaction with respect to the portion of the notional amount so terminated (and in cases where as a result of the termination the outstanding notional amount of such transaction is reduced to zero, with respect to such transaction in its entirety).

Where the transaction being partially terminated was originally confirmed through the System, it will be identified by User Trade Reference Numbers for the original transaction, which numbers are recorded by the System for each Confirmed Transaction Record. Where the transaction being terminated was not originally confirmed through the System, it will be identified by data elements 20-27 on the below table, which are intended to correspond to the same named items in the transaction being terminated. Users are responsible for assuring that these elements are sufficient to uniquely identify the transaction to be terminated. Matching on items 21-27 is for identification purposes only, and shall not be effective to retroactively change the terms of the transaction being terminated.

The transaction that is being partially terminated is terminated to the extent of the decrease in notional amount indicated in item 17 of the Transaction Record Data Elements, with the outstanding Floating Rate Payer Calculation Amount (if any) effective after the effective date of the partial termination being the amount specified in item 18 of the Transaction Record Data Elements.

Required/Optional/ Matching # Data Element Name Means of Specifying Information Validation Conditional (R/O/C) (Y/N) For All Partial Terminations 1Transaction Type R Y Partial Termination Company will maintain a table of valid Transaction Type identifiers.

2Product Type R Y Specify “CreditDefaultSwapShort” “CreditDefaultSwapShort”

4Submitting User Reference R N Unique identifier input by User to distinguish between 40 character limit Number Supplement multiple unconfirmed transactions.

5Submitting User Message ID O N Users may include in an additional processing 70 character limit number for internal purposes (e.g., tracking)

6Super ID O N Identifier that may be used to group or link related 40 character limit transactions

7Desk ID O N Identifier that may be used to identify the relevant Valid identifier desk that executed the transaction

8Designated Party ID O N Identifier that may be used by prime brokers to 20 character limit identify the prime broker’s relevant customer with respect to the transaction 9E-trading TRN O N Transaction identifier assigned to the transaction by 40 character limit an applicable execution platform (e.g., TradeWeb or Market Axess) 10Broker Name O N Identifier that may be used to identify any applicable 40 character limit broker with respect to the transaction

11Payer* R Y Company number assigned to User Company will maintain a table of User IDs

12Payment Amount R Y Amount of termination payment; matching tolerance Positive Integer of one currency unit 13Payment Currency R Y Currency of termination payment ISO currency code 14Payment Settlement Date R Y Date of termination payment Valid date format* 15Partial Termination Trade Date R Y Trade Date of the partial termination transaction Valid date format 16Partial Termination Effective Date R Y Effective date of partial termination Valid date format 17Decrease in Notional* R Y Notional amount being terminated and currency Positive Integer and ISO currency code 18Outstanding Notional* R Y Notional amount remaining following partial Positive Integer and ISO currency code termination and currency 19Comment* O N Text 250 character limit Additional Elements for When Original Trade not in System 20Original Trade Date C - required if terminated N Trade Date of the original transaction Valid date format contract not confirmed through System 21Scheduled Termination Date C Y Scheduled Termination Date of original transaction Valid date format 22Floating Rate Payer ("Seller") C Y Company number assigned to User Company will maintain a table of User IDs 23Fixed Rate Payer ("Buyer") C Y Company number assigned to User Company will maintain a table of User IDs 24Reference Entity* C Y Identified by unique identifier maintained in Company will validate against unique Company’s Reference Entity database. Database Reference Entity database identifiers. Only will link identifier with text name supplied by an one Reference Entity permitted. external supplier, including date of last supplier update* 25Reference Obligation * R Y Identified by ISIN. Credit Default Swaps with Correct number and type of characters for Reference Obligations that cannot be identified by ISIN. Only one Reference Obligation ISIN cannot be processed through use of this permitted. System will not validate Transaction Record against Company’s own internal list of ISIN numbers. 26Fixed Rate C Y Original Fixed Rate for terminated trade, expressed Any decimal number with up to 3 digits to as a percentage; (numerical - 5.550 would match the left of the decimal point and up to 8 to 5.55) the right 27Floating Rate Payer Calculation C Y Original notional amount and currency of terminated Positive Integer and ISO currency code Amount trade

*The following Notes apply to the above table: • General: No data element subject to matching will have a matching tolerance other than item 12, which has a matching tolerance of one currency unit (e.g., 1 Euro if the currency is Euro). All other data elements subject to matching must match exactly.

• General: Items 20-27 are required for terminations of transactions not originally confirmed through the System, but should not be included in Transaction Records for terminations of transactions originally confirmed through the System. • Valid date format: Valid date formats will be set forth in the Applicable Publications. • Item 3, Submitting User Reference Number for Original Transaction: Although the Submitting User Reference Numbers for Original Transaction that are submitted by the separate parties to a partial termination need not, and will not, match, the status of Confirmed for a partial termination of a transaction will require that each such Submitting User Reference Numbers for Original Transaction match exactly data element 3 in the Transaction Record submitted by that User for the original transaction as Confirmed. • Item 11, Payer: This is the designation of the User that is the Payer of the Payment Amount under the transaction. • Item 17, Decrease in Notional, and Item 18, Outstanding Notional: The transaction that is being terminated is terminated to the extent of the decrease in notional amount indicated in item 17, with the outstanding Floating Rate Payer Calculation Amount (if any) effective after the effective date of the partial termination being the amount specified in item 18. • Item 19, Comment: This data element is visible only to each User (and not its counterparty) and will only appear in each such User’s Transaction Record. • Item 24, Reference Entity: The Reference Entity identifiers referred to in the above table will be provided by a vendor designated by the MarkitSERV Board (including any successor oversight body). Initially such vendor shall be Markit Group, who will provide 6 digit identifiers for each Reference Entity maintained in their database. The System will accept either the 6 digit identifiers or else 9 digit identifiers (also provided by Markit Group, with the first 6 digits identifying the Reference Entity and the last 3 linking the Reference Entity to a Reference Obligation). All Users with access to the identifiers provided by the designated vendor shall be obliged to submit them in their Transaction Records. The System will match identifiers and names as follows: (i) if names and identifiers are submitted, both must match; if one party submits only a name (permissible only if that party does not have access to the identifiers), then only the names must match; (ii) the system will match 6 digit and 9 digit identifiers exactly; if one party submits a 6 digit identifier and the other a 9 digit identifier, then the System will match the 6 digit identifier against the first 6 digits of the 9 digit identifier; (iii) the system will convert text names to all capital letters and will match the names, including punctuation and spacing exactly. As an operational matter, the Company will, with respect to transactions between Users who have access to the identifiers and Users who do not, periodically check identifiers submitted by Users with access against the names associated with them in its database (as supplied by the designated vendor) and will inform such Users of any apparent discrepancies between the text names submitted by such Users and the names in the Company’s database.

• Item 25, Reference Obligation: A Transaction Record may indicate that the Eligible Transaction has no Reference Obligation by using the following “dummy” ISIN in place of a Reference Obligation identifier: XSNOREFOBL00.

Transaction Record Description for Assignments

Replaced Document:

The Replaced Document for assignments of trades that are Single Entity Matrix Transactions shall in all cases be a “Novation Confirmation” that is in the form of Exhibit C to the 2004 ISDA Novation Definitions and that confirms the terms and conditions of a novation transaction, or assignment, entered into among three or four Users. Pursuant to such a novation transaction, an existing transaction (which may or may not have been confirmed through the System) (the “Old Transaction”) between two Users may be assigned in whole or in part by one or both such Users (each, a “Transferor”) to another User or two other Users (each, a “Transferee”), resulting in a new transaction (the “New Transaction”) between the Transferee and the remaining party to the Old Transaction (the “Remaining Party”) or between two Transferees. The Novation Confirmation permits the parties to a Novation Confirmation to attach an Old Confirmation and a New Confirmation (as such terms are defined in the 2004 ISDA Novation Definitions) to a Novation Confirmation; therefore, the Old Confirmation and New Confirmation are also Replaced Documents. Except as provided herein, the provisions of this Appendix K shall only apply to Single Entity Matrix Transactions for which the Transaction Record for the Old Transaction and New Transaction each specifies “CreditDerivativesPhysicalSettlementMatrix” (or any other term for this purpose specified by the Company) in the applicable “Documentation Type” field (or, in the case of an Old Transaction not confirmed through the System, otherwise incorporates the Matrix Supplement and applicable ISDA Matrix). Related Master Documents for Old Transactions shall be:

• Old Master Agreement –identified by date and type pursuant to the Transaction Record– consisting of an ISDA Master Agreement (or any similar document not so named) that has been executed by the Transferor and the Remaining Party (or by the two Transferees). Any reference in a Transaction Record to a Master Agreement shall be to the Master Agreement as it may have been, and may subsequently be, amended, supplemented or modified by the parties thereto.

Related Master Documents for New Transactions shall be:

• New Master Agreement –identified by date and type pursuant to the Transaction Record– consisting of an ISDA Master Agreement (or other applicable type of master agreement described below) that has been executed by the Transferee and the Remaining Party (or by the two Transferees). Any reference in a Transaction Record to a Master Agreement shall be to the Master Agreement as it may have been, and may subsequently be, amended, supplemented or modified by the parties thereto. With respect to such other Master Agreement types specified in the Transaction Record:

• If the Master Agreement Type is “German”, the German Master Agreement for Financial Derivatives Transactions (Rahmenvertrag für Finanztermingeschäfte) • If the Master Agreement Type is “AFB”, the AFB/FBF Convention-cadre relative aux opérations de marché à terme. • If the Master Agreement Type is “Swiss”, the Swiss Master Agreement for over-the-counter (OTC) Derivatives. • If the Master Agreement Type is “ICETrustUS”, the ICE Trust U.S. L.L.C. Standard Terms Annex to the ISDA Master Agreement. • If the Master Agreement Type is “ICEClearEurope”, the ICE Clear Europe Standard Terms Annex to the ISDA Master Agreement

In the case of the New Transaction, the Users shall be deemed to have incorporated into the Replaced Document the definitions and provisions contained in the 2003 ISDA Credit Derivatives Definitions, as supplemented by the May 2003 Supplement and the 2005 Matrix Supplement (the “Matrix Supplement”) to the 2003 ISDA Credit Derivatives Definitions (as so supplemented, the “Definitions”), each as published by ISDA and available at www.isda.org; provided that notwithstanding Section 11.2 of the Matrix Supplement, the Credit Derivatives Physical Settlement Matrix shall be the ISDA Matrix published as of the date specified in “Master Document Date (New)” (or, if no date is specified therein, the most recent ISDA Matrix published as of the Novation Date). In the event of any inconsistency between the Definitions and the Replaced Document, the Replaced Document shall govern. The Users agree that the Replaced Document shall supplement, form a part of, and be subject to the applicable Master Documents. All provisions contained in, or incorporated by reference in, the Master Documents shall govern the Replaced Document except as expressly modified herein or therein.

The System will allow Users to enter into an assignment where the Old Transaction is subject to a Master Confirmation Agreement pursuant to Appendix B to the Operating Procedures and the New Transaction is a Single Entity Matrix Transaction (or vice versa). In such cases, the Transaction Record Description in Appendix B shall govern the identification and termination or entry into of the transaction subject to the Master Confirmation Agreement and this Transaction Record Description shall govern the identification and termination or entry into of the transaction that is a Single Entity Matrix Transaction. In addition, in the Remaining Party’s Transaction Record, the Master Document Transaction Type applicable to the Single Entity Matrix Transaction must correspond to the applicable Master Confirm Transaction Type for the transaction subject to the Master Confirmation Agreement (as set forth in the table below), otherwise the Transaction Record will be rejected:

Master Confirm Transaction Type under Master Document Transaction Type under Master Confirmation Agreement Matrix “North American” “North American Corporate” “European” “European Corporate” “Japan” “Japan Corporate” “Australia and New Zealand” Either “Australia Corporate” or “New Zealand

Corporate” “Asia” “Asia Corporate” “Asia (Sovereign)” “Asia Sovereign” “Singapore” “Singapore Corporate” “Emerging European and Middle Eastern” “Emerging European and Middle Eastern Sovereign” “Japan (Sovereign)” “Japan Sovereign” “Latin American” “Latin American Sovereign” “Western European” “Western European Sovereign” “Standard North American Corporate” “Standard North American Corporate” “Standard European Corporate” “Standard European Corporate” “Standard Western European Sovereign” “Standard Western European Sovereign” “Standard Emerging European and Middle “Standard Emerging European and Middle Eastern Sovereign” Eastern Sovereign” “Standard Latin American Sovereign” “Standard Latin America Sovereign” “Standard Australia New Zealand” Either “Standard Australia Corporate” or “Standard New Zealand Corporate” “Standard Asia” “Standard Asia Corporate” “Standard Asia Sovereign” “Standard Asia Sovereign” “Standard Singapore” “Standard Singapore Corporate” “Standard Japan” “Standard Japan Corporate” “Standard Japan Sovereign” “Standard Japan Sovereign”

To the extent that the Remaining Party specifies a Master Document Transaction Type for a Single Entity Matrix Transactions that is not listed on the above table (e.g., “Latin America Corporate”), such a transaction cannot be assigned where the Old Transaction is subject to a Master Confirmation Agreement and the New Transaction is a Single Entity Matrix Transaction (or vice versa). Users should refer to Appendix B to the Operating Procedures for more information on specifying a Master Confirmation Agreement as a related Master Document. Notwithstanding the foregoing, where the Old Transaction is a Single Entity Matrix Transaction with a Master Document Transaction Type of Standard North American Corporate, Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Japan Corporate, Standard Japan Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, the New Transaction cannot be subject to a Master Confirmation Agreement and must also be a Single Entity Matrix Transaction.

Notwithstanding anything to the contrary herein, in the specified ISDA Matrix or in a Transaction Record, with respect to all Transaction Records for Assignments of Single Entity Matrix Transactions (other than Excluded Transactions) with a Novation Date on

or after July 27, 2009 where the original Trade Date for the novated transaction occurred prior to July 27, 2009, the Users shall be deemed to have incorporated the amendments set forth in clause (3)(c)(i) of Part 1 of Schedule 1 to the 2009 ISDA Credit Derivatives Determinations Committees, Auction Settlement and Restructuring CDS Protocol (the “July 2009 Auction Protocol”), as though such transaction were a Protocol Covered Transaction that is a New Novation Transaction, notwithstanding that (i) the Novation Trade Date and/or the Trade Date of the Old Transaction may occur after January 31, 2011 and/or (ii) either the Remaining Party and/or the Transferee is not a July 2009 Adhering Party (as defined in the July 2009 Protocol). In addition, solely with respect to Transaction Records for Assignments in Single Entity Matrix Transactions (other than Excluded Transactions) with a Novation Date on or after July 27, 2009 but for which the specified ISDA Matrix for the New Transaction was published prior to July 27, 2009, notwithstanding anything to the contrary herein, in the specified ISDA Matrix or in a Transaction Record, but without derogation of any other relevant term of the Matrix Supplement or ISDA Matrix, the Users shall be deemed to have (i) incorporated into the Replaced Document the July 2009 Auction Supplement (and, unless the context otherwise requires, references therein to the 2003 ISDA Credit Derivatives Definitions shall be deemed to refer to such definitions as supplemented by the July 2009 Auction Supplement) and (ii) specified Auction Settlement as the Settlement Method and Physical Settlement as the Fallback Settlement Method.

Matching Process:

record is compared with this matched pair of records. Only when all three records match is the status of the assignment “Confirmed”. When only the Transferee and Transferor records match, the status of the assignment is “Matched”.

The Notes to the Transaction Record Data Elements indicate, for each item that specifies “Y” (yes) for matching, whether the item must match for all three parties to the Novation Confirmation, or whether it must match only with respect to two parties (and, if for two parties, which two parties).

Certain Trade Record Data Elements are not shown to all parties to the Novation Transaction, as indicated in the Notes to the Transaction Record Data Elements below.

Novation Confirmation Items:

The Transaction Record Data Elements set forth below cover the items set forth in the Novation Confirmation. Except as otherwise indicated herein, capitalized terms used herein but not defined herein are used as defined in the Novation Confirmation. Paragraph numbers indicated below correspond to the paragraph numbers in the Novation Confirmation.

Paragraph 1:

▪ The appropriate ISDA definitional booklet referenced in Item 1 is the 2003 ISDA Credit Derivatives Definitions.

Paragraph 2:

▪ Novation Date is the equivalent of Novation Date in the Transaction Record Data Elements.

▪ Novation Trade Date is the equivalent of Novation Trade Date in the Transaction Record Data Elements.

▪ Novated Amount is the equivalent of Novated Amount, Currency in the Transaction Record Data Elements.

▪ New Agreement is the ISDA Master Agreement that is designated in the applicable Transaction Record. The Users’ obligations to each other under the New Transaction shall be governed by the governing law of the New Master Documents.

Paragraph 3:

In lieu of attaching a copy of the Old Confirmation to the Novation Confirmation, the parties agree to specify the information that would otherwise have been contained in the Old Confirmation by electronically designating both the date of the Old Master Agreement and the transaction terms that were (or but for electronic confirmation of the Old Transaction would have been) specified in a related Confirmation (or similar document not so named).

The following Transaction Record Data Elements relating to the Old Transaction are subject to matching for all parties to the Novation Confirmation: Transaction Type, Product Type, Payment Frequency, Fixed Rate and Scheduled Termination Date, all of which shall be applicable to both the Old and New Transaction, as well as Fixed Rate Payer (“Buyer”), Floating Rate Payer (“Seller”) (with respect to Buyer and Seller, see the Notes to those Data Elements in the tables below).

The following Transaction Record Data Elements relating to the Old Transaction are, when used, subject to matching for the Transferor and Remaining Party only: Reference Entity (Old), Reference Obligation (Old), Restructuring Credit Event (Old), Initial Payment (Old), Calculation Agent (Old), Calculation Agent City (Old), Additional Matrix Provisions (Old), Additional Terms (Old), Notional Amount, Currency (Old), Master Agreement Type (Old), Master Agreement Date (Old), Documentation Type (Old), Master Document Date (Old), Master Document Transaction Type (Old), Trade Date (Old), Effective Date (Old), First Payment Period Accrual Start Date (Old) and First Fixed Rate Payer Payment Date (Old).

Paragraph 4:

In lieu of attaching a copy of the New Confirmation to the Novation Confirmation, the parties agree to specify the information that would otherwise have been contained in the New Confirmation by electronically designating both the date of the New Master Agreement and the transaction terms that would otherwise have been specified in a related Confirmation (or similar document not so named).

The following Transaction Record Data Elements relating to the New Transaction are subject to matching for all parties to the Novation Confirmation: Transaction Type, Product Type, Payment Frequency, Fixed Rate and Scheduled Termination Date, all of which shall be applicable to both the Old and New Transaction, as well as Fixed Rate Payer (“Buyer”), Floating Rate Payer (“Seller”) (with respect to Buyer and Seller, see the Notes to those Data Elements in the tables below), and Full First Calculation Period.

The following Transaction Record Data Elements relating to the New Transaction are, when used, subject to matching for the Transferee and Remaining Party only: Master

Agreement Type (New), Master Agreement Date (New), Master Document Date (New), Documentation Type (New), Reference Entity (New), Reference Obligation (New), Calculation Agent (New), Floating Rate Payer Calculation Amount (New), Restructuring Credit Event (New), Independent Amount (New), Calculation Agent City (New), Additional Matrix Provisions (New), Additional Terms (New) and Master Document Transaction Type (New).

Paragraph 7:

Given that the Novation Transaction is being confirmed through the System, the parties agree that the Notice Details are not necessary for completion of the Novation Confirmation.

Paragraph 8:

Notwithstanding any provision in the related Master Documents or the Novation Confirmation, each User agrees that the submission of Transaction Records by it and any other User through the System shall constitute an acceptable method under such Master Documents for evidencing and confirming the terms to be specified in any Novation Confirmation referenced in or to be governed by such Master Documents. Each User further agrees that Confirmed Transaction Records designating the Eligible Product and Eligible Transaction governed by this Transaction Record Description and referencing the relevant Master Documents shall (1) have the same legal effect as a fully executed Replaced Document entered into pursuant to and subject to the terms of such Master Documents and (2) evidence a novation transaction agreed among the Transferor(s), Transferee(s) and Remaining Party whose terms and provisions will be set forth in, governed by, construed in accordance with and subject to the Confirmed Transaction Records themselves, such Master Documents, Novation Confirmation and these Operating Procedures, including this Transaction Record Description.

Transaction Record Data Elements:

that may be set forth in the Applicable Publications or any other resource identified in the Master Documents (e.g., designated ISDA Credit Derivatives Definitions). Transaction Records that do not contain required values for certain data elements will be rejected by the System. In the event of any inconsistency between a Transaction Record and the relevant Master Documents or the Novation Confirmation, the Transaction Record shall govern (unless otherwise agreed between Users). The table below sets forth information relating to certain data elements that Users will be required to provide. Actual Transaction Records submitted by Users may be different in terms of appearance and in the manner in which information is to be provided (e.g., data elements may be specified in FpML). Users should consult the Applicable Publications for further information on the inputting of data.

The following are the data elements to be included in the Transferee’s Transaction Record:

Required/Optional/Condition Matching # Data Element Name Means of Specifying Information Validation al (R/O/C) (Y/N)* 1Transferor* R Y Company number assigned to User Company will maintain table of User IDs*

2Transferee* R Y Company number assigned to User Company will maintain table of User IDs*

3Remaining Party* R Y Company number assigned to User Company will maintain table of User IDs*

4Super ID O N Identifier that may be used to group or link related 40 character limit transactions

5Desk ID O N Identifier that may be used to identify the relevant Valid identifier desk that executed the transaction

6Designated Party ID O N Identifier that may be used by prime brokers to 20 character limit identify the prime broker’s relevant customer with respect to the transaction 7E-trading TRN O N Transaction identifier assigned to the transaction by 40 character limit an applicable execution platform (e.g., TradeWeb or Market Axess) 8Broker Name O N Identifier that may be used to identify any applicable 40 character limit broker with respect to the transaction

9Novation Date R Y Any date Valid date format

9ANovation Trade Date R Y Any date Valid date format

10Novated Amount, Currency* R Y Positive integer and currency Positive integer and ISO currency code

11Transaction Type R Y Assignments Company will maintain a table of valid Transaction Type identifiers.

Required/Optional/Condition Matching # Data Element Name Means of Specifying Information Validation al (R/O/C) (Y/N)* 12Product Type R Y Specify “CreditDefaultSwapShort” “CreditDefaultSwapShort”

13Master Agreement Type R N/Y Specify “AFB”, “German”, “ISDA”, “Swiss”, “AFB”, “German”, “ISDA”, “Swiss”, (New) “ICETrustUS”, “ICEClearEurope” or “Other” “ICETrustUS”, “ICEClearEurope” or “Other” 14Master Agreement Date (New) R N/Y Identified by date of Master Agreement Valid date format 15Documentation Type (New) R N/Y Specify “CreditDerivativesPhysicalSettlementMatrix” “CreditDerivativesPhysicalSettlementMatrix” 16Master Document Date O N/Y Identified by date of applicable ISDA Matrix Valid date format (New)* 17Calculation Agent (New)* R N/Y Specify company number assigned to relevant party Company number assigned to relevant party or “As specified in Master Agreement” or “As specified in Master Agreement” 18Fixed Rate Payer ("Buyer")* R Y Company number assigned to User Company will maintain table of User IDs

19Floating Rate Payer R Y Company number assigned to User Company will maintain table of User IDs ("Seller")* 20Reference Entity (New)* R N/Y Identified by unique identifier maintained in Company will validate against unique Company’s Reference Entity database and by text Reference Entity database identifiers. 250 legal name. character limit for text legal name. Only one Reference Entity permitted. 21Reference Obligation (New)* R N/Y Identified by ISIN. Credit Default Swaps with Correct number and type of characters for Reference Obligations that cannot be identified by ISIN. Only one Reference Obligation ISIN cannot be processed through use of this permitted. System will not validate against Transaction Record Company’s own internal list of ISIN numbers. 22Payment Frequency* R Y The frequency will specify the number of months An integer from 0 through 12 between payments (e.g., 6 for semi-annual, 3 for quarterly, etc.). 23Fixed Rate * O Y Expressed as a percentage (numerical - 5.550 would Any decimal number with up to 3 digits to the match 5.55) left of the decimal point and up to 8 to the right 24Scheduled Termination Date * R Y Any date Valid date format

25Floating Rate Payer R N/Y Positive integer and currency Positive integer and ISO currency code Calculation Amount (New)* 26Restructuring Credit Event R* N/Y Specify "Applicable" or "Not Applicable" "Applicable" or "Not Applicable" (New)* 27Independent Amount (New)* O N/Y Expressed as a Percentage (numerical - 5.550 would Any decimal number with up to 3 digits to the match 5.55); in addition, credit support provider left of the decimal point and up to 5 to the (payer) would be indicated by Company number right; Company will maintain table of User

Required/Optional/Condition Matching # Data Element Name Means of Specifying Information Validation al (R/O/C) (Y/N)* assigned to the relevant User IDs to be used for payer

28Calculation Agent City (New)* O N/Y Identified by ISDA identifier Validated against ISDA list of business centers 29Additional Matrix Provisions O N/Y Specify “ISDA2003CreditMonolineInsurers2005”, “ISDA2003CreditMonolineInsurers2005”, (New)* “ISDA2003DeliveryRestrictions”, or “ISDA2003DeliveryRestrictions”, or “ISDA2003SecuredDeliverableObligationCharacterist “ISDA2003SecuredDeliverableObligationCh ic” or “ISDA2010FixedRecovery” (or other applicable aracteristic” or “ISDA2010FixedRecovery” valid value), if applicable (or other applicable valid value) 30Additional Terms (New)* O N/Y Text 255 character limit

31Submitting User New Trade O N Unique identifier input by User 40 character limit Reference Number* 32Submitting User New O N Users may include an additional processing number 70 character limit Message ID* for internal purposes (e.g., tracking) 33Master Document R N/Y Specify the applicable Master Document Transaction The applicable valid values in the list Transaction Type (New)* Type as set forth in the list maintained by the maintained by the Company from time to Company from time to time. time. 34Full First Calculation Period* O Y Specify “Y” or “N” “Y” or “N” 35Payer * R Y/N Company number assigned to User Company will maintain table of User IDs* 36Payment Date* R Y/N Any date Valid date format 37Payment Amount* R Y/N Positive integer and currency Positive integer and ISO currency code 38Recovery Price C-required if Y Expressed as a percentage Any decimal number with up to 3 digits to the “ISDA2010FixedRecovery” is left of the decimal point and up to 8 digits to specified in Item 29; otherwise, the right not allowed. 39Comment* O N Text 250 character limit 8

For items indicating a “Y/N”, Transferee’s Transaction Record must match the equivalent item in Transferor’s Transaction Record. With respect to Items 3, 18 and 19, see the Notes to those items below. • Items 1 through 3, Transferor, Transferee and Remaining Party, 18 and 19, Floating Rate Payer (“Seller”) and Fixed Rate Payer (“Buyer”), and 35, Payer: These are the designations of the Users that are parties to the transaction. The submitted transmission must be identified as originating from the Family of the appropriate User, or it will not be accepted. The Seller and Buyer indicated herein are the Seller and Buyer in the New Transaction. Matching with respect to Buyer and Seller is as follows: Transferee will name itself in the position of either Buyer or Seller, and will name Remaining Party in the other position (i.e., Buyer or Seller). On the Transferor’s Transaction Record, in order to match Transferee’s Transaction Record, Transferor must name (i) itself in the same position (i.e., Buyer or Seller) as Transferee had named itself, and (ii) its Remaining Party in the other position (i.e., either Buyer or Seller). On the Remaining Party’s Transaction Record, in order to match Transferee’s Transaction Record, Remaining Party must name (i) itself in the same position (i.e., Buyer or Seller) as Transferee had named its Remaining Party, and (ii) Transferor in the same position (i.e., Buyer or Seller) as Transferee had named itself. • Item 3, Remaining Party: For a four party assignment, the Transferee names the Remaining Party 2. For matching with respect to four party assignments, see the Note to Items 3 and 3A in the Remaining Party’s Transaction Record Data Elements. • Item 10, Novated Amount, Currency: This is the same amount as the Notional Amount for the New Transaction. If the Master Document Transaction Type is Standard North American Corporate, Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Japan Corporate, Standard Japan Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, the currency must be one of the applicable currencies specified in the ISDA Matrix for that transaction type. • Item 16, Master Document Date (New): This refers to the date of publication of the applicable ISDA Matrix. If this item is left blank, the Users will be deemed to have incorporated the ISDA Matrix most recently published as of the Novation Date. • Item 17, Calculation Agent (New): If “As specified in Master Agreement” is specified in Item 17, the Calculation Agent will be the party identified as such pursuant to the New Master Agreement. In other cases, the party identified as the Calculation Agent must be a party to the New Transaction.

• Item 20, Reference Entity (New): The Reference Entity identifiers referred to in the above table will be provided by a vendor designated by the MarkitSERV Board (including any successor oversight body). Initially such vendor shall be Markit Group, who will provide 6 digit identifiers for each Reference Entity maintained in their database. The System will accept either the 6 digit identifiers or else 9 digit identifiers (also provided by Markit Group, with the first 6 digits identifying the Reference Entity and the last 3 linking the Reference Entity to a Reference Obligation). All Users with access to the identifiers provided by the designated vendor shall be obliged to submit them in their Transaction Records. The System will match identifiers and names as follows: (i) if names and identifiers are submitted, both must match; if one party submits only a name (permissible only if that party does not have access to the identifiers), then only the names must match; (ii) the system will match 6 digit and 9 digit identifiers exactly; if one party submits a 6 digit identifier and the other a 9 digit identifier, then the System will match the 6 digit identifier against the first 6 digits of the 9 digit identifier; (iii) the system will convert text names to all capital letters and will match the names, including punctuation and spacing exactly. As an operational matter, the Company will, with respect to transactions between Users who have access to the identifiers and Users who do not, periodically check identifiers submitted by Users with access against the names associated with them in its database (as supplied by the designated vendor) and will inform such Users of any apparent discrepancies between the text names submitted by such Users and the names in the Company’s database. Where there will be a change in Reference Entity between the Old Transaction and the New Transaction, this field should reflect the Reference Entity under the New Transaction. • Item 21, Reference Obligation (New): A Transaction Record may indicate that the Eligible Transaction has no Reference Obligation by using the following “dummy” ISIN in place of a Reference Obligation identifier: XSNOREFOBL00. Where there will be a change in Reference Obligation between the Old Transaction and the New Transaction, this field should reflect the Reference Obligation under the New Transaction. • Item 22, Payment Frequency: This field will be ignored if the Fixed Rate is zero. If the Master Document Transaction Type is Standard North American Corporate, Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Japan Corporate, Standard Japan Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, this field will be overwritten such that the payment frequency will be three months.

• Item 23, Fixed Rate: If the Master Document Transaction Type is Standard North American Corporate, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, the Fixed Rate must be either 1.00% or 5.00%. If the Master Document Transaction Type is Standard European Corporate, Standard Subordinated European Insurance Corporate or Standard Western European Sovereign, the Fixed Rate must be 0.25%, 1.00%, 3.00%, 5.00%, 7.50% or 10.00%. If the Master Document Transaction Type is Standard Japan Corporate or Standard Japan Sovereign, the Fixed Rate must be either 0.25%, 1.00% or 5.00%. • Item 24, Scheduled Termination Date: If the Master Document Transaction Type is Standard North American Corporate, Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Japan Corporate, Standard Japan Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, this date must be a Quarterly Roll Date. • Item 25, Floating Rate Payer Calculation Amount (New): This is the same amount as the Novated Amount, Currency and is matched against Item 10, Novated Amount, Currency, in the Remaining Party’s Transaction Record. If the Master Document Transaction Type is Standard North American Corporate, Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Japan Corporate, Standard Japan Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, the currency must be one of the applicable currencies specified in the ISDA Matrix for that transaction type. • Item 26, Restructuring Credit Event (New): If the Master Document Transaction Type (New) is not North American Corporate or Standard North American Corporate, Restructuring must be applicable.

• Item 27, Independent Amount (New): A Transaction Record relating to an Eligible Transaction may indicate the Independent Amount (New) (Independent Amount, as defined in the governing Credit Support Annex, or similar document not so named, relating to the New Master Agreement). The Independent Amount (New) must be expressed as a percentage and should be understood as a percentage of the Floating Rate Payer Calculation Amount (New). If an Independent Amount (New) is indicated, the parties must also identify the credit support provider (payer) by Company assigned ID, similar to how Buyer and Seller are designated. One or another of the Buyer or Seller must also be the credit support provider. If an Independent Amount (New) is not indicated, it does not mean that there is no Independent Amount (New), rather that any Independent Amount (New) applicable to the transaction or a portfolio containing the transaction is specified in a different document (e.g., an applicable Credit Support Annex, Master Agreement or similar document) and is not specified in the related Transaction Record. Users may indicate that the Independent Amount applicable to the Eligible Transaction to which the Transaction Record relates is linked to another transaction confirmed through the system (the “Linked Transaction”) by specifying “Linked to [trade id of Linked Transaction]” in Item 30. In the event such Linked Transaction is terminated, novated or otherwise amended, the Independent Amount may be reassessed in the sole discretion of the counterparty to the party with respect to which the Independent Amount applies (the “Independent Amount Determining Party”). Such reassessment shall be effective immediately upon the date of termination, novation or amendment of the Linked Transaction, unless otherwise delayed beyond such date by the Independent Amount Determining Party. The foregoing may be amended in accordance with, and is subject to, any relevant contract between the parties. • Item 28, Calculation Agent City (New): The Calculation Agent City may be identified by codes used for FpML purposes and published by ISDA. The Company may, after Important Notice issued in accordance with these Operating Procedures, choose to validate submissions against these codes. If this field is left blank, the System will automatically specify the Calculation Agent City (New) based on the applicable default set forth in the ISDA Matrix. If the Master Document Transaction Type is Standard North American Corporate, this field will be overwritten with the applicable business center set forth in the ISDA Matrix for such transaction type. If the Master Document Transaction Type is Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, this field will be overwritten with London. If the Master Document Transaction Type is Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan or Standard Latin America Sovereign, this field will be overwritten to be New York. If

the Master Document Transaction Type is Standard Japan Corporate or Standard Japan Sovereign, this field will be overwritten to be Tokyo. • Item 29, Additional Matrix Provisions (New): For fixed recovery swap, “ISDA2010FixedRecovery” must be specified. Notwithstanding anything to the contrary in the Operating Procedures, if the Reference Entity specified in a Transaction Record is a monoline insurer (determined solely based on its RED code’s matching one of the RED codes on a list maintained for this purpose by the Company from time to time), “ISDA2003CreditMonolineInsurers2005” must be specified in Additional Matrix Provisions (New). • Item 30, Additional Terms (New): Users may insert up to 255 characters of free text specifying, among other things, additional terms applicable to the transaction (e.g., credit linkage terms). A submission of “N” or “n” as the sole character in this data element will be treated for matching purposes as if the data element had been left blank. • Item 31, Submitting User New Trade Reference Number: Required if the assignment is a partial assignment. • Item 33, Master Document Transaction Type (New): This refers to a “Transaction Type” that would otherwise be specified in a written Confirmation. The related ISDA Matrix provides that certain terms apply to the subject Eligible Transaction depending on the designated Transaction Type. The Company may, by Important Notice, amend the available categories of Master Document Transaction Types that may be specified in a Transaction Record, including to reflect amendments to the ISDA Matrix. The Master Document Transaction Type for the New Transaction may not be Standard North American Corporate, Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Japan Corporate, Standard Japan Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, unless the Master Document Transaction Type for the Old Transaction is Standard North American Corporate, Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Japan Corporate, Standard Japan Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, respectively.

• Item 34, Full First Calculation Period: If “Y” is specified or if this item is left blank, Full First Calculation Period will be applicable. If “N” is specified, Full First Calculation Period will not be applicable. • Items 35 through 37, Payer, Payment Date, and Payment Amount: Remaining Party does not see these items on its Transaction Record. • Item 38, Recovery Price: The specified Recovery Price will be the “Final Price” for purposes of the Additional Provisions for Fixed Recovery CDS Transactions. • Item 398, Comment: This data element is visible only to the Transferee and will only appear in the Transferee’s Transaction Record.

The following are the data elements to be included in the Transferor’s Transaction Record:

Required/Optional/Conditional Matching # Data Element Name Means of Specifying Information Validation (R/O/C) (Y/N)* 1 Transferor* R Y Company number assigned to User Company will maintain table of User IDs*

2 Transferee* R Y Company number assigned to User Company will maintain table of User IDs*

3 Remaining Party* R Y Company number assigned to User Company will maintain table of User IDs*

4 Super ID O N Identifier that may be used to group or link related 40 character limit transactions

5 Desk ID O N Identifier that may be used to identify the relevant Valid identifier desk that executed the transaction

6 Designated Party ID O N Identifier that may be used by prime brokers to 20 character limit identify the prime broker’s relevant customer with respect to the transaction 7 E-trading TRN O N Transaction identifier assigned to the transaction 40 character limit by an applicable execution platform (e.g., TradeWeb or Market Axess) 8 Broker Name O N Identifier that may be used to identify any 40 character limit applicable broker with respect to the transaction

9 Novation Date R Y Any date Valid date format

9A Novation Trade Date R Y Any date Valid date format

Required/Optional/Conditional Matching # Data Element Name Means of Specifying Information Validation (R/O/C) (Y/N)* 10 Novated Amount, R Y Positive integer and currency Positive integer and ISO currency code Currency*

11 Transaction Type R Y Assignments Company will maintain a table of valid Transaction Type identifiers.

12 Product Type R Y Specify “CreditDefaultSwapShort” “CreditDefaultSwapShort”

13 Fixed Rate Payer R Y Company number assigned to User Company will maintain table of User IDs ("Buyer")* 14 Floating Rate Payer R Y Company number assigned to User Company will maintain table of User IDs ("Seller")* 15 Reference Entity (Old)* R N/Y Identified by unique identifier maintained in Company will validate against unique Company’s Reference Entity database and by Reference Entity database identifiers. 250 text legal name. character limit for text legal name. Only one Reference Entity permitted. 16 Reference Obligation R N/Y Identified by ISIN. Credit Default Swaps with Correct number and type of characters for (Old)* Reference Obligations that cannot be identified ISIN. Only one Reference Obligation by ISIN cannot be processed through use of this permitted. System will not validate against Transaction Record Company’s own internal list of ISIN numbers. 17 Payment Frequency* R Y The frequency will specify the number of months An integer from 0 through 12 between payments (e.g., 6 for semi-annual, 3 for quarterly, etc.). 18 Fixed Rate * O Y Expressed as a percentage (numerical - 5.550 Any decimal number with up to 3 digits to would match 5.55) the left of the decimal point and up to 8 to the right 19 Scheduled Termination R Y Any date Valid date format Date * 20 Restructuring Credit Event R* N/Y Specify "Applicable" or "Not Applicable" "Applicable" or "Not Applicable" (Old)* 21 Independent Amount O N/Y Expressed as a Percentage (numerical - 5.550 Any decimal number with up to 3 digits to (Old)* would match 5.55); in addition, credit support the left of the decimal point and up to 5 to provider (payer) would be indicated by Company the right; Company will maintain table of number assigned to the relevant User User IDs to be used for payer 22 Single/Initial Payment O N/Y Positive integer, date and, if necessary, Positive integer, valid date format and, if (Old)* identification of payer by Company assigned ID* necessary, Company assigned ID of payer*

Required/Optional/Conditional Matching # Data Element Name Means of Specifying Information Validation (R/O/C) (Y/N)* 23 Calculation Agent (Old) R N/Y Specify company number assigned to relevant Company number assigned to relevant party or “As specified in Master Agreement” party or “As specified in Master Agreement” 24 Calculation Agent City O N/Y Identified by ISDA identifier Validated against ISDA list of business (Old) centers 25 Additional Matrix O N/Y Specify “ISDA2003CreditMonolineInsurers2005”, “ISDA2003CreditMonolineInsurers2005”, Provisions (Old)* “ISDA2003DeliveryRestrictions”, or “ISDA2003DeliveryRestrictions”, or “ISDA2003SecuredDeliverableObligationCharact “ISDA2003SecuredDeliverableObligationCh eristic” or “ISDA2010FixedRecovery” (or other aracteristic” or “ISDA2010FixedRecovery” applicable valid value), if applicable (or other applicable valid value) 26 First Payment Period O N/Y Any date Valid date format Accrual Start Date (Old)* 27 Additional Terms (Old) O N/Y Text 255 character limit

28 Submitting User Old Trade R N* Unique identifier input by User 40 character limit Reference Number* 29 Trade Reference Number R N Unique identifier input by User 40 character limit Supplement* 30 Submitting User Old O N Users may include an additional processing 70 character limit Message ID* number for internal purposes (e.g., tracking) 31 Notional Amount, R N/Y Positive integer and currency Positive integer and ISO currency code Currency (Old)* 32 Master Agreement Type R N/Y Specify “AFB”, “German”, “ISDA”, “Swiss”, “AFB”, “German”, “ISDA”, “Swiss”, (Old) “ICETrustUS”, “ICEClearEurope” or “Other” “ICETrustUS”, “ICEClearEurope” or “Other” 33 Master Agreement Date R N/Y Identified by date of Master Agreement Valid date format (Old) 34 Documentation Type (Old) R N/Y Specify “CreditDerivativesPhysicalSettlementMatrix” “CreditDerivativesPhysicalSettlementMatrix” 35 Master Document Date R N/Y Identified by date of publication of the relevant Valid date format (Old)* ISDA Matrix 36 Master Document R N/Y Specify the applicable Master Document The applicable valid values in the list Transaction Type (Old)* Transaction Type as set forth in the list maintained by the Company from time to maintained by the Company from time to time. time. 37 Trade Date (Old) R N/Y Any date Valid date format 38 Effective Date (Old)* R N/Y Any date Valid date format 39 First Fixed Rate Payer O N/Y The first payment date Valid date format Payment Date (Old) 40 Full First Calculation O Y Specify “Y” or “N” “Y” or “N” Period 41 Payer* R Y/N Company number assigned to User Company will maintain table of User IDs

Required/Optional/Conditional Matching # Data Element Name Means of Specifying Information Validation (R/O/C) (Y/N)* 42 Payment Date* R Y/N Any date Valid date format 43 Payment Amount* R Y/N Positive integer and currency Positive integer and ISO currency code 44 Recovery Price C-required if Y Expressed as a percentage. Any decimal number with up to 3 digits to “ISDA2010FixedRecovery” is the left of the decimal point and up to 8 specified in Item 25; otherwise, digits to the right not allowed. 454 Comment* O N Text 250 character limit

*The following Notes apply to the above table: • General: No data element subject to matching will have a matching tolerance. All such data elements must match exactly. • Valid date format: Valid date formats will be set forth in the Applicable Publications. • Matching (Y/N) column: For items indicating a “Y”, Transferor’s Transaction Record must match the equivalent items in both Transferee’s Transaction Record and Remaining Party’s Transaction Record. For items indicating a “N/Y”, Transferor’s Transaction Record must match the equivalent item in Remaining Party’s Transaction Record. For items indicating a “Y/N”, Transferor’s Transaction Record must match the equivalent item in Transferee’s Transaction Record. With respect to Items 3, 13 and 14, see the Notes to those items below. • Items 1 through 3, Transferor, Transferee and Remaining Party, 13 and 14, Floating Rate Payer (“Seller”) and Fixed Rate Payer (“Buyer”), and 41, Payer: These are the designations of the Users that are parties to the transaction. The submitted transmission must be identified as originating from the Family of the appropriate User, or it will not be accepted. The Seller and Buyer indicated herein are the Seller and Buyer in the Old Transaction. Matching with respect to Buyer and Seller is as follows: Transferor will name itself in the position of either Buyer or Seller, and will name Remaining Party in the other position (i.e., Buyer or Seller). On the Transferee’s Transaction Record, in order to match the Transferor’s Transaction Record, Transferee must name (i) itself in the same position (i.e., Buyer or Seller) as Transferor had named itself, and (ii) its Remaining Party in the other position (i.e., Buyer or Seller). On the Remaining Party’s Transaction Record, in order to match the Transferor’s Transaction Record, Remaining Party must name (i) itself in the same position (i.e., Buyer or Seller) as Transferor had named its Remaining Party, and (ii) Transferee in the same position (i.e., Buyer or Seller) as Transferor had named itself. • Item 3, Remaining Party: For a four party assignment, the Transferor names the Remaining Party. For matching with respect to four party assignments, see the Note to Items 3 and 3A in the Remaining Party’s Transaction Record Data Elements below.

• Item 10, Novated Amount, Currency: If the Master Document Transaction Type is Standard North American Corporate, Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Japan Corporate, Standard Japan Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, the currency must be one of the applicable currencies specified in the ISDA Matrix for that transaction type. • Item 15, Reference Entity (Old): The Reference Entity identifiers referred to in the above table will be provided by a vendor designated by the MarkitSERV Board (including any successor oversight body). Initially such vendor shall be Markit Group, who will provide 6 digit identifiers for each Reference Entity maintained in their database. The System will accept either the 6 digit identifiers or else 9 digit identifiers (also provided by Markit Group, with the first 6 digits identifying the Reference Entity and the last 3 linking the Reference Entity to a Reference Obligation). All Users with access to the identifiers provided by the designated vendor shall be obliged to submit them in their Transaction Records. The System will match identifiers and names as follows: (i) if names and identifiers are submitted, both must match; if one party submits only a name (permissible only if that party does not have access to the identifiers), then only the names must match; (ii) the system will match 6 digit and 9 digit identifiers exactly; if one party submits a 6 digit identifier and the other a 9 digit identifier, then the System will match the 6 digit identifier against the first 6 digits of the 9 digit identifier; (iii) the system will convert text names to all capital letters and will match the names, including punctuation and spacing exactly. As an operational matter, the Company will, with respect to transactions between Users who have access to the identifiers and Users who do not, periodically check identifiers submitted by Users with access against the names associated with them in its database (as supplied by the designated vendor) and will inform such Users of any apparent discrepancies between the text names submitted by such Users and the names in the Company’s database. Where there will be a change in Reference Entity between the Old Transaction and the New Transaction, this field should reflect the Reference Entity under the Old Transaction. • Item 16, Reference Obligation (Old): A Transaction Record may indicate that the Eligible Transaction has no Reference Obligation by using the following “dummy” ISIN in place of a Reference Obligation identifier: XSNOREFOBL00. Where there will be a change in Reference Obligation between the Old Transaction and the New Transaction, this field should reflect the Reference Obligation under the Old Transaction.

• Item 17, Payment Frequency: This field will be ignored if the Fixed Rate is zero. If the Master Document Transaction Type is Standard North American Corporate, Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Japan Corporate, Standard Japan Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, this field will be overwritten such that the payment frequency will be three months. • Item 18, Fixed Rate: If the Master Document Transaction Type is Standard North American Corporate, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, the Fixed Rate must be either 1.00% or 5.00%. If the Master Document Transaction Type is Standard European Corporate, Standard Subordinated European Insurance Corporate or Standard Western European Sovereign, the Fixed Rate must be 0.25%, 1.00%, 3.00%, 5.00%, 7.50% or 10.00%. If the Master Document Transaction Type is Standard Japan Corporate or Standard Japan Sovereign, the Fixed Rate must be either 0.25%, 1.00% or 5.00%. • Item 19, Scheduled Termination Date: If the Master Document Transaction Type is Standard North American Corporate, Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Japan Corporate, Standard Japan Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, this date must be a Quarterly Roll Date. • Item 20, Restructuring Credit Event (Old) : If the Master Document Transaction Type (Old) is not North American Corporate or Standard North American Corporate, Restructuring must be applicable.

• Item 21, Independent Amount (Old): A Transaction Record relating to an Eligible Transaction may indicate the Independent Amount (Old) (Independent Amount, as defined in the governing Credit Support Annex, or similar document not so named, relating to the Old Master Agreement). The Independent Amount (Old) must be expressed as a percentage and should be understood as a percentage of the Floating Rate Payer Calculation Amount (Old). If an Independent Amount (Old) is indicated, the parties must also identify the credit support provider (payer) by Company assigned ID, similar to how Buyer and Seller are designated. One or another of the Buyer or Seller must also be the credit support provider. If an Independent Amount (Old) is not indicated, it does not mean that there is no Independent Amount (Old), rather that any Independent Amount (Old) applicable to the transaction or a portfolio containing the transaction is specified in a different document (e.g., an applicable Credit Support Annex, Master Agreement or similar document) and is not specified in the related Transaction Record. Users may indicate that the Independent Amount applicable to the Eligible Transaction to which the Transaction Record relates is linked to another transaction confirmed through the system (the “Linked Transaction”) by specifying “Linked to [trade id of Linked Transaction]” in Item 27. In the event such Linked Transaction is terminated, novated or otherwise amended, the Independent Amount may be reassessed in the sole discretion of the counterparty to the party with respect to which the Independent Amount applies (the “Independent Amount Determining Party”). Such reassessment shall be effective immediately upon the date of termination, novation or amendment of the Linked Transaction, unless otherwise delayed beyond such date by the Independent Amount Determining Party. The foregoing may be amended in accordance with, and is subject to, any relevant contract between the parties. • Item 22, Single/Initial Payment (Old): Sometimes referred to as “single payment”, indicates the amount of an agreed payment owed by one party to the other party on the date specified. If the Buyer is payer, the parties do not need to identify the payer or payee as the System will automatically identify the Buyer as payer and the other party as payee. If the Seller is payer, the Transaction Record must identify the payer by use of the Company assigned ID. The currency shall be identical to the currency of the Floating Rate Payer Calculation Amount (Old). An initial payment shall be in lieu of or in addition to the payments determined by items 18 and 39. • Item 25, Additional Matrix Provisions (Old): For a fixed recovery swap, “ISDA2010Fixed Recovery” must be specified. • Item 26, First Payment Period Accrual Start Date (Old): If a date is specified, the first Fixed Rate Payer Calculation Period will commence on, and include, such date. If specified, the First Payment Period Accrual Start Date should be a date before the Effective Date. • Item 28, Submitting User Old Trade Reference Number: Although the Submitting User Old Trade Reference Numbers that are submitted by the separate parties to an assignment need not, and will not, match, the status of Confirmed for an assignment of a transaction originally confirmed through the System will require that each such Submitting User Old Trade Reference Number match exactly the equivalent data element in the Transaction

Record submitted by that User for the original transaction as Confirmed. Where the assigned trade was not originally confirmed through the System, this number will be used solely as the transaction reference number for the assignment itself. In that case, this data element will not be used to identify the transaction to be assigned (rather the data elements pertaining to the Old Transaction will be so used) and the assignment will not be ineffective due to the failure of this number to conform to the actual User trade reference number for the Old Transaction. • Item 31, Notional Amount, Currency (Old): This refers to the Floating Rate Payer Calculation Amount (Old) just before the assignment. • Item 35, Master Document Date (Old): This refers to the date of publication of the applicable ISDA Matrix. If this item is left blank, the Users will be deemed to have incorporated the ISDA Matrix most recently published as of the Trade Date of the Old Transaction. Notwithstanding the foregoing, (i) in the case of a Single Entity Matrix Transaction that results from the occurrence of a restructuring credit event with respect to a component reference entity in an index credit default swap transaction relating to an iTraxx Europe index or an iTraxx Japan index, if this item is left blank and the Trade Date is prior to the publication date of the first ISDA Matrix that includes the relevant Transaction Type for such Single Entity Matrix Transaction, the Master Document Date will be the publication date of the first ISDA Matrix that includes such Transaction Type, (ii) in the case of Master Document Transaction Type "Latin American Corporate B", if this item is left blank, the Users will be deemed to have incorporated the ISDA Matrix most recently published as of the Trade Date of the Transaction, provided, however, that if the Transaction is subject to a version which precedes February 1, 2007, the terms affiliated with the Latin America Corporate Transaction Type shall apply and (iii) in the case of Master Document Transaction Types, "Sukuk Corporate", "Sukuk Sovereign", "Standard Sukuk Corporate" and "Standard Sukuk Sovereign", Users will be deemed to have incorporated the later of (a) the ISDA Matrix most recently published as of the Trade Date of the Transaction and (b) the ISDA Matrix dated November 8, 2010 that first included these Master Document Transaction Types. • Item 36, Master Document Transaction Type (Old): This refers to a “Transaction Type” that would otherwise be specified in a written Confirmation. The related ISDA Matrix provides that certain terms apply to the subject Eligible Transaction depending on the designated Transaction Type. The Company may, by Important Notice, amend the available categories of Master Document Transaction Types that may be specified in a Transaction Record, including to reflect amendments to the ISDA Matrix. • Item 38, Effective Date (Old): Any identification of Effective Date (Old) shall mean the exact date identified regardless of any business day convention adopted in any Master Document. • Items 41 through 43, Payer, Payment Date, and Payment Amount: Remaining Party does not see these items on its Transaction Record.

• Item 44, Recovery Price: The specified Recovery Price will be the “Final Price” for purposes of the Additional Provisions for Fixed Recovery CDS Transactions. • Item 454, Comment: This data element is visible only to the Transferor and will only appear in the Transferor’s Transaction Record.

The following are the data elements to be included in the Remaining Party’s Transaction Record:

Required/Optional/Conditional Matching # Data Element Name Means of Specifying Information Validation (R/O/C) (Y/N)* 1Transferor* R Y Company number assigned to User Company will maintain table of User IDs

2Transferee* R Y Company number assigned to User Company will maintain table of User IDs

3Remaining Party* R Y Company number assigned to User Company will maintain table of User IDs

3ARemaining Party 2* O Y Company number assigned to User Company will maintain table of User Ids

4Super ID O N Identifier that may be used to group or link related 40 character limit transactions

5Desk ID O N Identifier that may be used to identify the relevant Valid identifier desk that executed the transaction

6Designated Party ID O N Identifier that may be used by prime brokers to 20 character limit identify the prime broker’s relevant customer with respect to the transaction 7E-trading TRN O N Transaction identifier assigned to the transaction 40 character limit by an applicable execution platform (e.g., TradeWeb or Market Axess) 8Broker Name O N Identifier that may be used to identify any 40 character limit applicable broker with respect to the transaction

9Novation Date* R Y Any date Valid date format

Required/Optional/Conditional Matching # Data Element Name Means of Specifying Information Validation (R/O/C) (Y/N)* 9ANovation Trade Date R Y Any date Valid date format

10Novated Amount, Currency* R Y Positive integer and currency Positive integer and ISO currency code

11Transaction Type R Y Assignments Company will maintain a table of valid Transaction Type identifiers.

12Product Type R Y Specify “CreditDefaultSwapShort” “CreditDefaultSwapShort”

13Documentation Type (New) R Y/N Specify “CreditDerivativesPhysicalSettlementMatrix” “CreditDerivativesPhysicalSettlementMatrix” 14Fixed Rate Payer ("Buyer")* R Y Company number assigned to User Company will maintain table of User IDs

15Floating Rate Payer R Y Company number assigned to User Company will maintain table of User IDs ("Seller")* 16Reference Entity (Old)* R N/Y Identified by unique identifier maintained in Company will validate against unique Company’s Reference Entity database and by Reference Entity database identifiers. 250 text legal name. character limit for text legal name. Only one Reference Entity permitted. 16Reference Entity (New)* R Y/N Identified by unique identifier maintained in Company will validate against unique A Company’s Reference Entity database and by Reference Entity database identifiers. 250 text legal name. character limit for text legal name. Only one Reference Entity permitted. 17Reference Obligation (Old)* R N/Y Identified by ISIN. Credit Default Swaps with Correct number and type of characters for Reference Obligations that cannot be identified ISIN. Only one Reference Obligation by ISIN cannot be processed through use of this permitted. System will not validate against Transaction Record Company’s own internal list of ISIN numbers. 17Reference Obligation R Y/N Identified by ISIN. Credit Default Swaps with Correct number and type of characters for A(New)* Reference Obligations that cannot be identified ISIN. Only one Reference Obligation by ISIN cannot be processed through use of this permitted. System will not validate against Transaction Record Company’s own internal list of ISIN numbers. 18Payment Frequency* R Y The frequency will specify the number of months An integer from 0 through 12 between payments (e.g., 6 for semi-annual, 3 for quarterly, etc.).

Required/Optional/Conditional Matching # Data Element Name Means of Specifying Information Validation (R/O/C) (Y/N)* 19Fixed Rate * O Y Expressed as a percentage (numerical - 5.550 Any decimal number with up to 3 digits to would match 5.55) the left of the decimal point and up to 8 to the right 20Scheduled Termination R Y Any date Valid date format Date * 21Restructuring Credit Event R* Y/N "Applicable" or "Not Applicable" "Applicable" or "Not Applicable" (New)* 22Independent Amount O Y/N Expressed as a Percentage (numerical - 5.550 Any decimal number with up to 3 digits to (New)* would match 5.55); in addition, credit support the left of the decimal point and up to 5 to provider (payer) and credit support receiver the right; Company will maintain table of (receiver) would be indicated by Company User IDs to be used for payer and receiver number assigned to the relevant User 23Additional Matrix O Y/N Specify “ISDA2003CreditMonolineInsurers2005”, “ISDA2003CreditMonolineInsurers2005”, Provisions (New)* “ISDA2003DeliveryRestrictions”, or “ISDA2003DeliveryRestrictions”, or “ISDA2003SecuredDeliverableObligationCharact “ISDA2003SecuredDeliverableObligationCh eristic” or “ISDA2010FixedRecovery” (or other aracteristic” or “ISDA2010FixedRecovery” applicable valid value), if applicable (or other applicable valid value) 24Additional Terms (New)* O Y/N Text 255 character limit

25Submitting User New Trade O* N Unique identifier input by User 40 character limit Reference Number* 26Submitting User New O N Users may include an additional processing 70 character limit Message ID* number for internal purposes (e.g., tracking) 27Master Agreement Type R Y/N Specify “AFB”, “German”, “ISDA”, “Swiss”, “AFB”, “German”, “ISDA”, “Swiss”, (New) “ICETrustUS”, “ICEClearEurope” or “Other” “ICETrustUS”, “ICEClearEurope” or “Other” 28Master Agreement Date O Y/N Identified by date of Master Agreement Valid date format (New) 29Master Document Date R Y/N Identified by date of applicable ISDA Matrix Valid date format (New)* 30Master Document R Y/N Specify the applicable Master Document The applicable valid values in the list Transaction Type (New)* Transaction Type as set forth in the list maintained by the Company from time to maintained by the Company from time to time. time. 31Calculation Agent (New)* R Y/N Specify company number assigned to relevant Company number assigned to relevant party or “As specified in Master Agreement” party or “As specified in Master Agreement” 32Calculation Agent City O Y/N Identified by ISDA identifier Validated against ISDA list of business (New)* centers 33Full First Calculation O Y Specify “Y” or “N” “Y” or “N” Period*

Required/Optional/Conditional Matching # Data Element Name Means of Specifying Information Validation (R/O/C) (Y/N)* 34Submitting User Old Trade R N Unique identifier input by User 40 character limit Reference Number* 35Trade Reference Number R N Unique identifier input by User 40 character limit Supplement* 36Submitting User Old O N Users may include an additional processing 70 character limit Message ID* number for internal purposes (e.g., tracking) 37Notional Amount, Currency R N/Y Positive integer and currency Positive integer and ISO currency code (Old)* 38Documentation Type (Old) R N/Y Specify “CreditDerivativesPhysicalSettlementMatrix” “CreditDerivativesPhysicalSettlementMatrix” 39Master Document Date R N/Y Identified by date of applicable ISDA Matrix Valid date format (Old) 40Master Document R N/Y Specify the applicable Master Document The applicable valid values in the list Transaction Type (Old) Transaction Type as set forth in the list maintained by the Company from time to maintained by the Company from time to time. time.

41Restructuring Credit Event R N/Y Specify "Applicable" or "Not Applicable" "Applicable" or "Not Applicable" (Old) * 42Master Agreement Type R N/Y Specify “AFB”, “German”, “ISDA”, “Swiss”, “AFB”, “German”, “ISDA”, “Swiss”, (Old) “ICETrustUS”, “ICEClearEurope” or “Other” “ICETrustUS”, “ICEClearEurope” or “Other” 43Master Agreement Date R N/Y Identified by date of Master Agreement Valid date format (Old) 44Additional Terms (Old) O N/Y Text 255 character limit 45Trade Date (Old) R N/Y Any date Valid date format 46Effective Date (Old)* R N/Y Any date Valid date format 47Single/Initial Payment (Old)* O N/Y Positive integer, date and, if necessary, Positive integer, valid date format and, if identification of payer by Company assigned ID* necessary, Company assigned ID of payer* 48Calculation Agent (Old) R N/Y Specify company number assigned to relevant Company number assigned to relevant party or “As specified in Master Agreement” party or “As specified in Master Agreement”

Required/Optional/Conditional Matching # Data Element Name Means of Specifying Information Validation (R/O/C) (Y/N)* 49Calculation Agent City (Old) O N/Y Identified by ISDA identifier Validated against ISDA list of business centers 50First Fixed Rate Payer O N/Y The first payment date Valid date format Payment Date (Old) 51First Payment Period O N/Y Any date Valid date format Accrual Start Date (Old)* 52Additional Matrix O N/Y Specify “ISDA2003CreditMonolineInsurers2005”, “ISDA2003CreditMonolineInsurers2005”, Provisions (Old) “ISDA2003DeliveryRestrictions”, or “ISDA2003DeliveryRestrictions”, or “ISDA2003SecuredDeliverableObligationCharact “ISDA2003SecuredDeliverableObligationCh eristic” or “ISDA2010FixedRecovery” (or other aracteristic” or “ISDA2010FixedRecovery” applicable valid value), if applicable (or other applicable valid value) 53Recovery Price C-required if Expressed as a percentage Any decimal number with up to 3 digits to “ISDA2010FixedRecovery” is the left of the decimal point and up to 8 specified in Item 23; otherwise, digits to the right not allowed. 54Comment* O N Text 250 character limit 3

Transaction Record, in order to match the Remaining Party’s Transaction Record, Transferee must name (i) itself in the same position (i.e., Buyer or Seller) as Remaining Party had named Transferor, and (ii) its Remaining Party in the same position (i.e., either Buyer or Seller) as Remaining Party had named itself. On the Transferor’s Transaction Record, in order to match the Remaining Party’s Transaction Record, Transferor must name (i) itself in the same position (i.e., Buyer or Seller) as Remaining Party had named Transferor, and (ii) Remaining Party in the same position (i.e., Buyer or Seller) as Remaining Party had named itself. • Item 3 and 3A, Remaining Party and Remaining Party 2: For a four party assignment, the Remaining Party identifies the party to the Old Transaction as the Remaining Party and the entity that is party to the New Transaction as Remaining Party 2. Remaining Party is matched against the Transferor’s Remaining Party, and Remaining Party 2 is matched against the Transferee’s Remaining Party. Remaining Party and Remaining Party 2 must be in the same Family. • Item 10, Novated Amount, Currency: This is the same amount as the Notional Amount for the New Transaction. In addition to being matched against the Novated Amount, Currency items for the Transferor and Transferee, Remaining Party’s Item 10 is also matched against Item 25 in the Transferee’s Transaction Record, Floating Rate Payer Calculation Amount (New). If the Master Document Transaction Type is Standard North American Corporate, Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Japan Corporate, Standard Japan Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, the currency must be one of the applicable currencies specified in the ISDA Matrix for that transaction type. • Items 16 and 16A, Reference Entity (Old) and Reference Entity (New): The Reference Entity identifiers referred to in the above table will be provided by a vendor designated by the MarkitSERV Board (including any successor oversight body). Initially such vendor shall be Markit Group, who will provide 6 digit identifiers for each Reference Entity maintained in their database. The System will accept either the 6 digit identifiers or else 9 digit identifiers (also provided by Markit Group, with the first 6 digits identifying the Reference Entity and the last 3 linking the Reference Entity to a Reference Obligation). All Users with access to the identifiers provided by the designated vendor shall be obliged to submit them in their Transaction Records. The System will match identifiers and names as follows: (i) if names and identifiers are submitted, both must match; if one party submits only a name (permissible only if that party does not have access to the identifiers), then only the names must match; (ii) the

system will match 6 digit and 9 digit identifiers exactly; if one party submits a 6 digit identifier and the other a 9 digit identifier, then the System will match the 6 digit identifier against the first 6 digits of the 9 digit identifier; (iii) the system will convert text names to all capital letters and will match the names, including punctuation and spacing exactly. As an operational matter, the Company will, with respect to transactions between Users who have access to the identifiers and Users who do not, periodically check identifiers submitted by Users with access against the names associated with them in its database (as supplied by the designated vendor) and will inform such Users of any apparent discrepancies between the text names submitted by such Users and the names in the Company’s database. Where there will be a change in Reference Entity between the Old Transaction and the New Transaction, the Reference Entity (Old) field should reflect the Reference Entity under the Old Transaction and the Reference Entity (New) field should reflect the Reference Entity under the New Transaction. Even if there will be no such change, both fields must be completed. • Item 17 and 17A, Reference Obligation (Old) and Reference Obligation (New): A Transaction Record may indicate that the Eligible Transaction has no Reference Obligation by using the following “dummy” ISIN in place of a Reference Obligation identifier: XSNOREFOBL00. Where there will be a change in Reference Entity between the Old Transaction and the New Transaction, the Reference Obligation (Old) field should reflect the Reference Obligation under the Old Transaction and the Reference Entity (New) field should reflect the Reference Obligation under the New Transaction. Even if there will be no such change, both fields must be completed. • Item 18, Payment Frequency: This field will be ignored if the Fixed Rate is zero. If the Master Document Transaction Type is Standard North American Corporate, Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Japan Corporate, Standard Japan Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, this field will be overwritten such that the payment frequency will be three months. • Item 19, Fixed Rate: If the Master Document Transaction Type is Standard North American Corporate, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Sukuk Corporate or Standard Sukuk

Sovereign, the Fixed Rate must be either 1.00% or 5.00%. If the Master Document Transaction Type is Standard European Corporate, Standard Subordinated European Insurance Corporate or Standard Western European Sovereign, the Fixed Rate must be 0.25%, 1.00%, 3.00%, 5.00%, 7.50% or 10.00%. If the Master Document Transaction Type is Standard Japan Corporate or Standard Japan Sovereign, the Fixed Rate must be either 0.25%, 1.00% or 5.00%. • Item 20, Scheduled Termination Date: If the Master Document Transaction Type is Standard North American Corporate, Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Japan Corporate, Standard Japan Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, this date must be a Quarterly Roll Date. • Item 21, Restructuring Credit Event (New): If the Master Document Transaction Type (New) is not North American Corporate or Standard North American Corporate, Restructuring must be applicable. • Item 22, Independent Amount (New): A Transaction Record relating to an Eligible Transaction may indicate the Independent Amount (New) (Independent Amount, as defined in the governing Credit Support Annex, or similar document not so named, relating to the Master Agreement). The Independent Amount (New) must be expressed as a percentage and should be understood as a percentage of the Floating Rate Payer Calculation Amount (New). If an Independent Amount (New) is indicated, the parties must also identify the credit support provider (payer) by Company assigned ID, similar to how Buyer and Seller are designated. One or another of the Buyer or Seller must also be the credit support provider. If an Independent Amount (New) is not indicated, it does not mean that there is no Independent Amount (New), rather that any Independent Amount (New) applicable to the transaction or a portfolio containing the transaction is specified in a different document (e.g., an applicable Credit Support Annex, Master Agreement or similar document) and is not specified in the related Transaction Record. Users may indicate that the Independent Amount applicable to the Eligible Transaction to which the Transaction Record relates is linked to another transaction confirmed through the system (the “Linked Transaction”) by specifying “Linked to [trade id of Linked Transaction]” in Item 24. In the event such Linked Transaction is terminated, novated or otherwise amended, the Independent Amount may be reassessed in the sole discretion of the counterparty to the party with respect to which the Independent Amount applies (the “Independent Amount Determining Party”). Such reassessment shall be effective immediately upon the date of termination, novation or amendment of the

Linked Transaction, unless otherwise delayed beyond such date by the Independent Amount Determining Party. The foregoing may be amended in accordance with, and is subject to, any relevant contract between the parties. • Item 23, Additional Matrix Provisions (New): For a fixed recovery swap, “ISDA2010FixedRecovery” must be specified. Notwithstanding anything to the contrary in the Operating Procedures, if the Reference Entity specified in a Transaction Record is a monoline insurer (determined solely based on its RED code’s matching one of the RED codes on a list maintained for this purpose by the Company from time to time), “ISDA2003CreditMonolineInsurers2005” must be specified in Additional Matrix Provisions (New). • Item 24, Additional Terms (New): Users may insert up to 255 characters of free text specifying, among other things, additional terms applicable to the transaction (e.g., credit linkage terms). A submission of “N” or “n” as the sole character in this data element will be treated for matching purposes as if the data element had been left blank. • Item 25, Submitting User New Trade Reference Number: Required if the assignment is a partial assignment. • Item 29, Master Document Date (New): This refers to the date of publication of the applicable ISDA Matrix. If this item is left blank, the Users will be deemed to have incorporated the ISDA Matrix most recently published as of the Novation Date. • Item 30, Master Document Transaction Type (New): This refers to a “Transaction Type” that would otherwise be specified in a written Confirmation. The related ISDA Matrix provides that certain terms apply to the subject Eligible Transaction depending on the designated Transaction Type. The Company may, by Important Notice, amend the available categories of Master Document Transaction Types that may be specified in a Transaction Record, including to reflect amendments to the ISDA Matrix. The Master Document Transaction Type for the New Transaction may not be Standard North American Corporate, Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Japan Corporate, Standard Japan Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, unless the Master Document Transaction Type for the Old Transaction is Standard North American Corporate, Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign,

Standard Singapore Corporate, Standard Singapore Sovereign, Standard Japan Corporate, Standard Japan Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, respectively. • Item 31, Calculation Agent (New): If “As specified in Master Agreement” is specified in Item 31, the Calculation Agent will be the party identified as such pursuant to the New Master Agreement. In other cases, the party identified as the Calculation Agent must be a party to the New Transaction. • Item 32, Calculation Agent City (New): The Calculation Agent City may be identified by codes used for FpML purposes and published by ISDA. The Company may, after Important Notice issued in accordance with these Operating Procedures, choose to validate submissions against these codes. If this field is left blank, the System will automatically specify the Calculation Agent City (New) based on the applicable default set forth in the ISDA Matrix. If the Master Document Transaction Type is Standard North American Corporate, this field will be overwritten with the applicable business center set forth in the ISDA Matrix for such transaction type. If the Master Document Transaction Type is Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, this field will be overwritten with London. If the Master Document Transaction Type is Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan or Standard Latin America Sovereign, this field will be overwritten to be New York. If the Master Document Transaction Type is Standard Japan Corporate or Standard Japan Sovereign, this field will be overwritten to be Tokyo. • Item 34, Submitting User Old Trade Reference Number: Although the Submitting User Old Trade Reference Numbers that are submitted by the separate parties to an assignment need not, and will not, match, the status of Confirmed for an assignment of a transaction originally confirmed through the System will require that each such Submitting User Old Trade Reference Number match exactly the equivalent data element in the Transaction Record submitted by that User for the original transaction as Confirmed. Where the assigned trade was not originally confirmed through the System, this number will be used solely as the transaction reference number for the assignment itself. In that case, this data element will not be used to identify the transaction to be assigned (rather the data elements pertaining to the Old Transaction will be so used) and the assignment will not be ineffective due to the failure of this number to conform to the actual User trade reference number for the Old Transaction. • Item 37, Notional Amount, Currency (Old): This refers to the Floating Rate Payer Calculation Amount (Old) just before the assignment.

• Item 46, Effective Date (Old): Any identification of Effective Date (Old) shall mean the exact date identified regardless of any business day convention adopted in any Master Document. • Item 47, Single/Initial Payment (Old): Sometimes referred to as “single payment”, indicates the amount of an agreed payment owed by one party to the other party on the date specified. If the Buyer is payer, the parties do not need to identify the payer or payee as the System will automatically identify the Buyer as payer and the other party as payee. If the Seller is payer, the Transaction Record must identify the payer by use of the Company assigned ID. The currency shall be identical to the currency of the Floating Rate Payer Calculation Amount (Old). An initial payment shall be in lieu of or in addition to the payments determined by items 19 and 50. • Item 51, First Payment Period Accrual Start Date: If a date is specified, the first Fixed Rate Payer Calculation Period will commence on, and include, such date. If specified, the First Payment Period Accrual Start Date should be a date before the Effective Date. • Item 53, Recovery Price: The specified Recovery Price will be the “Final Price” for purposes of the Additional Provisions for Fixed Recovery CDS Transactions. • Item 543, Comment: This data element is visible only to the Remaining Party and will only appear in the Remaining Party’s Transaction Record.

Transaction Record Description for Increases

Replaced Document and Data Elements:

The Replaced Document in respect of increases shall in all cases be an increase agreement that would have been fully executed between the parties to a Single Entity Matrix Transaction that is being increased (where the Single Entity Matrix Transaction was confirmed through the System). The purpose of the increase agreement would be to evidence: the identity of the transaction being increased, the effective date of the termination in part, the increase in the notional amount, the outstanding notional amount after the increase, and the payment, if any, to be made between the parties in connection with the increase. Notwithstanding any provision in any document evidencing and/or governing any Single Entity Matrix Transaction intended to be increased, each User agrees that the submission of Transaction Records by it and any other User through the System for increase of such transaction shall constitute an acceptable method under such document(s) for evidencing and confirming the increase of such transaction. Each User further agrees that Confirmed Transaction Records designating the product and transaction type governed by this Transaction Record Description and relating to the increase of a Single Entity Matrix Transaction shall constitute such User’s agreement to increase such transaction as of the Increase Effective Date identified in such Confirmed Transaction Records and to receive or pay the Payment Amount identified in such Confirmed Transaction Records on the Payment Settlement Date identified in such Confirmed Transaction Records.

The transaction that is being increased is increased to the extent of the increase in notional amount indicated in item 17 of the Transaction Record Data Elements, with the outstanding Floating Rate Payer Calculation Amount effective after the effective date of the increase being the amount specified in item 18 of the Transaction Record Data Elements.

Required/Optional/ Matching # Data Element Name Means of Specifying Information Validation Conditional (R/O/C) (Y/N) For All Increases 1Transaction Type R Y Increase Company will maintain a table of valid Transaction Type identifiers.

2Product Type R Y Specify “CreditDefaultSwapShort” “CreditDefaultSwapShort”

3Submitting User Reference R* N* Unique identifier input by User. To increase a 40 character limit Number for Original Transaction* transaction confirmed through System, must match data element 3 in original Transaction Record.

4Submitting User Reference R N Unique identifier input by User to distinguish between 40 character limit Number Supplement multiple unconfirmed transactions.

5Submitting User Message ID O N Users may include in an additional processing 70 character limit number for internal purposes (e.g., tracking)

6Super ID O N Identifier that may be used to group or link related 40 character limit transactions

7Desk ID O N Identifier that may be used to identify the relevant Valid identifier desk that executed the transaction

11Payer* R Y Company number assigned to User Company will maintain a table of User IDs*

12Payment Amount R Y Amount of increase payment; matching tolerance of Positive Integer one currency unit 13Payment Currency R Y Currency of increase payment ISO currency code 14Payment Settlement Date* R Y Date of increase payment Valid date format 15Increase Trade Date R Y Trade Date of the increase transaction Valid date format 16Increase Effective Date* R Y Effective date of increase Valid date format 17Increase in Notional* R Y Notional amount being increased and currency Positive Integer and ISO currency code 18Outstanding Notional* R Y Notional amount remaining following increase and Positive Integer and ISO currency code currency 19Comment* O N Text 250 character limit

*The following Notes apply to the above table:

• General: No data element subject to matching will have a matching tolerance other than item 12, which has a matching tolerance of one currency unit (e.g., 1 Euro if the currency is Euro). All other data elements subject to matching must match exactly. • Valid date format: Valid date formats will be set forth in the Applicable Publications. • Item 3, Submitting User Reference Number for Original Transaction: Although the Submitting User Reference Numbers for Original Transaction that are submitted by the separate parties to an increase need not, and will not, match, the status of Confirmed will require that each such Submitting User Reference Numbers for Original Transaction match exactly data element 3 in the Transaction Record submitted by that User for the original transaction as Confirmed. • Item 11, Payer: This is the designation of the User that is the Payer of the Payment Amount under the transaction. • Item 17, Increase in Notional, and Item 18, Outstanding Notional: The transaction that is being increased is increased to the extent of the increase in notional amount indicated in item 17, with the outstanding Floating Rate Payer Calculation Amount effective after the effective date of the increase being the amount specified in item 18. • Item 19, Comment: This data element is visible only to each User (and not its counterparty) and will only appear in each such User’s Transaction Record.

Transaction Record Description for Amendments

Replaced Document:

The Replaced Document for amendments of Single Entity Matrix Transactions shall in all cases be a “Confirmation” (or any similar document not so named) that has been executed by two Users for the purpose of evidencing such amendment between them (each, a “Confirmation”). The provisions of this Appendix K shall only apply to Single Entity Matrix Transactions for which “CreditDerivativesPhysicalSettlementMatrix” (or any other term for this purpose specified by the Company) is specified in the applicable “Documentation Type” field of the Transaction Record. Related Master Documents shall be:

The Users shall be deemed to have incorporated into the Replaced Document the definitions and provisions contained in the 2003 ISDA Credit Derivatives Definitions, as supplemented by the May 2003 Supplement and the 2005 Matrix Supplement (the “Matrix Supplement”) to the 2003 ISDA Credit Derivatives Definitions (as so supplemented, the “Definitions”), each as published by ISDA and available at www.isda.org; provided that notwithstanding Section 11.2 of the Matrix Supplement, the Credit Derivatives Physical Settlement Matrix shall be the ISDA Matrix published as of the date specified in “Master Document Date” (or, if no date is specified therein, the most recent ISDA Matrix published as of the Trade Date). In the event of any inconsistency between the Definitions and the Replaced Document, the Replaced Document shall govern. The Users agree that the Replaced Document shall supplement, form a part of, and be subject to the applicable Master Documents. All provisions contained in, or incorporated by reference in, the Master Documents shall govern the Replaced Document except as expressly modified herein or therein.

Solely with respect to Transaction Records for Amendments in Single Entity Matrix Transactions (other than Excluded Transactions) with a Trade Date on or after July 27, 2009 but for which the specified ISDA Matrix was published prior to July 27, 2009, notwithstanding anything to the contrary herein, in the specified ISDA Matrix or in a Transaction Record, but without derogation of any other relevant term of the Matrix Supplement or ISDA Matrix, the Users shall be deemed to have (i) incorporated into the Replaced Document the July 2009 Auction Supplement (and, unless the context otherwise requires, references therein to the 2003 ISDA Credit Derivatives Definitions shall be deemed to refer to such definitions as supplemented by the July 2009 Auction Supplement) and (ii) specified Auction Settlement as the Settlement Method and Physical Settlement as the Fallback Settlement Method.

The governing law of the Master Documents shall also govern the obligations created by any Transaction Record.

Amendments Processing:

Transaction Record Data Elements:

will be required to provide. Actual Transaction Records submitted by Users may be different in terms of appearance and in the manner in which information is to be provided (e.g., data elements may be specified in FpML). Users should consult the Applicable Publications for further information on the inputting of data.

Required/Optional/Conditional Matching # Data Element Name Means of Specifying Information Validation (R/O/C) (Y/N)* 1 Transaction Type R Y Amendments Company will maintain a table of valid Transaction Type identifiers 2 Product Type R Y Specify “CreditDefaultSwapShort” “CreditDefaultSwapShort” 3 Submitting User Trade R N Unique identifier input by User 40 character limit Reference Number 4 Submitting User Message ID O N Users may include an additional processing 70 character limit number for internal purposes (e.g., tracking) 5 Super ID O N Identifier that may be used to group or link 40 character limit related transactions 6 Desk ID O N Identifier that may be used to identify the Valid identifier relevant desk that executed the transaction 7 Designated Party ID O N Identifier that may be used by prime brokers 20 character limit to identify the prime broker’s relevant customer with respect to the transaction 8 E-trading TRN O N Transaction identifier assigned to the 40 character limit transaction by an applicable execution platform (e.g., TradeWeb or Market Axess) 9 Broker Name O N Identifier that may be used to identify any 40 character limit applicable broker with respect to the transaction 10 Master Document R Y Specify the applicable Master Document The applicable valid values in the list Transaction Type* Transaction Type as set forth in the list maintained by the Company from time to maintained by the Company from time to time. time. 11 Master Agreement Type R Y Specify “AFB, “German”, “ISDA”, “Swiss”, “AFB, “German”, “ISDA”, “Swiss”, “ICETrustUS”, “ICEClearEurope” or “Other” “ICETrustUS”, “ICEClearEurope” or “Other” 12 Master Agreement Date R Y Identified by date of Master Agreement Valid date format 13 Documentation Type R Y Specify “CreditDerivativesPhysicalSettlementMatrix” “CreditDerivativesPhysicalSettlementMatrix” 14 Master Document Date* O Y Identified by date of publication of the Valid date format relevant ISDA Matrix

15 Calculation Agent* R Y Specify company number assigned to Company number assigned to relevant relevant party or “As specified in Master party or “As specified in Master Agreement” Agreement” 16 Trade Date R Y Any date Valid date format 17 Effective Date* R Y Any date Valid date format 18 Scheduled Termination Date R Y Any date Valid date format * 19 Floating Rate Payer R Y Company number assigned to User Company will maintain table of User IDs ("Seller")*

Required/Optional/Conditional Matching # Data Element Name Means of Specifying Information Validation (R/O/C) (Y/N)* 20 Fixed Rate Payer ("Buyer")* R Y Company number assigned to User Company will maintain table of User IDs* 21 Reference Entity* R Y Identified by unique identifier maintained in Company will validate against unique Company’s Reference Entity database and Reference Entity database identifiers. 250 by text legal name. character limit for text legal name. Only one Reference Entity permitted. 22 Reference Obligation* R Y Identified by ISIN. Credit Default Swaps with Correct number and type of characters for Reference Obligations that cannot be ISIN. Only one Reference Obligation identified by ISIN cannot be processed permitted. System will not validate against through use of this Transaction Record. Company’s own internal list of ISIN numbers. 23 First Payment Date; Payment C- optional if Item 28 is Y One date and a frequency -- the First Valid date format and an integer from 0 Frequency (Fixed Rate Payer submitted; otherwise required Payment Date specified will be the first Fixed through 12 Payment Date(s))* Rate Payer Payment Date; the frequency will specify the number of months between payments (e.g., 6 for semi-annual, 3 for quarterly, etc.), with the last scheduled payment date being the Scheduled Termination Date. Each Fixed Rate Payer Payment Date after the first shall be determined by starting with the Scheduled Termination Date and working backwards to the first Fixed Rate Payer Payment Date. 24 Fixed Rate * C- optional if Item 28 is Y Expressed as a percentage (numerical - Any decimal number with up to 3 digits to submitted; otherwise required 5.550 would match 5.55) the left of the decimal point and up to 8 to the right 25 Floating Rate Payer R Y Positive integer and currency Positive integer and ISO currency code Calculation Amount * 26 Restructuring Credit Event* R Y "Applicable" or "Not Applicable" "Applicable" or "Not Applicable" 27 Independent Amount* O Y Expressed as a Percentage (numerical - Any decimal number with up to 3 digits to 5.550 would match 5.55); in addition, credit the left of the decimal point and up to 5 to support provider (payer) and credit support the right; Company will maintain table of receiver (receiver) would be indicated by User IDs to be used for payer and receiver Company number assigned to the relevant User 28 Single/Initial Payment* O Y Positive integer, date and, if necessary, Positive integer, valid date format and, if identification of payer by Company assigned necessary, Company assigned ID of payer ID 29 Calculation Agent City* O Y Identified by ISDA identifier Validated against ISDA list of business centers 30 First Payment Period Accrual O Y Any date Valid date format Start Date* 31 Additional Matrix Provisions* O Y Specify “ISDA2003CreditMonolineInsurers2005”,

Required/Optional/Conditional Matching # Data Element Name Means of Specifying Information Validation (R/O/C) (Y/N)* “ISDA2003CreditMonolineInsurers2005”, “ISDA2003DeliveryRestrictions”, or “ISDA2003DeliveryRestrictions”, or “ISDA2003SecuredDeliverableObligationCh “ISDA2003SecuredDeliverableObligationCha aracteristic” or “ISDA2010FixedRecovery” racteristic” or “ISDA2010FixedRecovery” (or (or other applicable valid value) other applicable valid value), if applicable 32 Additional Terms* O Y Text 255 character limit 33 Recovery Price C-required if Y Expressed as a percentage Any decimal number with up to 3 digits to “ISDA2010FixedRecovery” is the left of the decimal point and up to 8 specified in Item 31; otherwise, digits to the right not allowed. 34Comment* O N Text 250 character limit 3 35Amendment Trade Date R Y Any date Valid date format 4 36Amendment Effective Date R Y Any date Valid date format 5 37Payer* O Y Company number assigned to User Company will maintain table of User Ids 6 38Payment Date O Y Any date Valid date format 7 39Payment Amount O Y Positive integer and currency Positive integer and ISO currency code 8

• General: No data element subject to matching will have a matching tolerance. All such data elements must match exactly. • Valid date format: Valid date formats will be set forth in the Applicable Publications. • Item 10, Master Document Transaction Type: This refers to a “Transaction Type” that would otherwise be specified in a written Confirmation. The related ISDA Matrix provides that certain terms apply to the subject Eligible Transaction depending on the designated Transaction Type. The Company may, by Important Notice, amend the available categories of Master Document Transaction Types that may be specified in a Transaction Record, including to reflect amendments to the ISDA Matrix. • Item 14, Master Document Date: This refers to the date of publication of the applicable ISDA Matrix. If this item is left blank, the Users will be deemed to have incorporated the ISDA Matrix most recently published as of the Trade Date. Notwithstanding the foregoing, (i) in the case of a Single Entity Matrix Transaction that results from the occurrence of a restructuring credit event with respect to a component reference entity in an index credit default swap transaction relating to an iTraxx Europe index or an iTraxx Japan index, if this item is left blank and the Trade Date is prior to the publication date of the first ISDA Matrix that includes the relevant Transaction Type for

such Single Entity Matrix Transaction, the Master Document Date will be the publication date of the first ISDA Matrix that includes such Transaction Type, (ii) in the case of Master Document Transaction Type "Latin American Corporate B", if this item is left blank, the Users will be deemed to have incorporated the ISDA Matrix most recently published as of the Trade Date of the Transaction, provided, however, that if the Transaction is subject to a version which precedes February 1, 2007, the terms affiliated with the Latin America Corporate Transaction Type shall apply and (iii) in the case of Master Document Transaction Types, "Sukuk Corporate", "Sukuk Sovereign", "Standard Sukuk Corporate" and "Standard Sukuk Sovereign", Users will be deemed to have incorporated the later of (a) the ISDA Matrix most recently published as of the Trade Date of the Transaction and (b) the ISDA Matrix dated November 8, 2010 that first included these Master Document Transaction Types. • Item 15, Calculation Agent: If “As specified in Master Agreement” is specified in Item 15, the Calculation Agent will be the party identified as such pursuant to the Master Agreement. In other cases, the party identified as the Calculation Agent must be a party to the transaction. • Item 17, Effective Date: Any identification of Effective Date shall mean the exact date identified regardless of any business day convention adopted in any Master Document. Where the Master Document Transaction Type is Standard North American Corporate, Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Japan Corporate, Standard Japan Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, the data in this field will be overwritten to be the calendar day following the Trade Date. • Item 18, Scheduled Termination Date: If the Master Document Transaction Type is Standard North American Corporate, Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Japan Corporate, Standard Japan Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, this date must be a Quarterly Roll Date.

• Items 19 and 20, Floating Rate Payer (“Seller”) and Fixed Rate Payer (“Buyer”): These are the designations of the Users that are parties to the transaction. The submitted transmission must be identified as originating from the Family of either the Seller or the Buyer, or it will not be accepted. • Item 21, Reference Entity: The Reference Entity identifiers referred to in the above table will be provided by a vendor designated by the MarkitSERV Board (including any successor oversight body). Initially such vendor shall be Markit Group, who will provide 6 digit identifiers for each Reference Entity maintained in their database. The System will accept either the 6 digit identifiers or else 9 digit identifiers (also provided by Markit Group, with the first 6 digits identifying the Reference Entity and the last 3 linking the Reference Entity to a Reference Obligation). All Users with access to the identifiers provided by the designated vendor shall be obliged to submit them in their Transaction Records. The System will match identifiers and names as follows: (i) if names and identifiers are submitted, both must match; if one party submits only a name (permissible only if that party does not have access to the identifiers), then only the names must match; (ii) the system will match 6 digit and 9 digit identifiers exactly; if one party submits a 6 digit identifier and the other a 9 digit identifier, then the System will match the 6 digit identifier against the first 6 digits of the 9 digit identifier; (iii) the system will convert text names to all capital letters and will match the names, including punctuation and spacing exactly. As an operational matter, the Company will, with respect to transactions between Users who have access to the identifiers and Users who do not, periodically check identifiers submitted by Users with access against the names associated with them in its database (as supplied by the designated vendor) and will inform such Users of any apparent discrepancies between the text names submitted by such Users and the names in the Company’s database. • Item 22, Reference Obligation: A Transaction Record may indicate that the Eligible Transaction has no Reference Obligation by using the following “dummy” ISIN in place of a Reference Obligation identifier: XSNOREFOBL00. • Item 23, First Payment Date; Payment Frequency (Fixed Rate Payer Payment Date(s)): These fields are used to determine the Fixed Rate Payer Payment Dates as set forth above, and will be ignored if the Fixed Rate is zero. If the Master Document Transaction Type is Standard North American Corporate, Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Japan Corporate, Standard Japan Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, these fields will be overwritten such that the specified First Payment Date will be the first Quarterly Roll Date following the calendar day after the Trade Date and the Payment Frequency will be three months.

• Item 24, Fixed Rate: If the Master Document Transaction Type is Standard North American Corporate, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, the Fixed Rate must be either 1.00% or 5.00%. If the Master Document Transaction Type is Standard European Corporate, Standard Subordinated European Insurance Corporate or Standard Western European Sovereign, the Fixed Rate must be 0.25%, 1.00%, 3.00%, 5.00%, 7.50% or 10.00%. If the Master Document Transaction Type is Standard Japan Corporate or Standard Japan Sovereign, the Fixed Rate must be either 0.25%, 1.00% or 5.00%. • Item 25, Floating Rate Payer Calculation Amount: If the Master Document Transaction Type is Standard North American Corporate, Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Japan Corporate, Standard Japan Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, the currency must be one of the applicable currencies specified in the ISDA Matrix for that transaction type. • Item 26, Restructuring Credit Event: If the Master Document Transaction Type is not North American Corporate or Standard North American Corporate, Restructuring must be applicable. • Item 27, Independent Amount: A Transaction Record relating to an Eligible Transaction may indicate the Independent Amount (as defined in the governing Credit Support Annex, or similar document not so named, relating to the Master Agreement). The Independent Amount must be expressed as a percentage and should be understood as a percentage of the Floating Rate Payer Calculation Amount. If an Independent Amount is indicated, the parties must also identify the credit support provider (payer) and credit support receiver (receiver) by Company assigned ID, similar to how Buyer and Seller are designated. One or another of the Buyer or Seller must also be the credit support provider or receiver. If an Independent Amount is not indicated, it does not mean that there is no Independent Amount, rather that any Independent Amount applicable to the transaction or a portfolio containing the transaction is specified in a different document (e.g., an applicable Credit Support Annex, Master Agreement or similar document) and is not specified in the related Transaction Record. Users may indicate

that the Independent Amount applicable to the Eligible Transaction to which the Transaction Record relates is linked to another transaction confirmed through the system (the “Linked Transaction”) by specifying “Linked to [trade id of Linked Transaction]” in Item 32. In the event such Linked Transaction is terminated, novated or otherwise amended, the Independent Amount may be reassessed in the sole discretion of the counterparty to the party with respect to which the Independent Amount applies (the “Independent Amount Determining Party”). Such reassessment shall be effective immediately upon the date of termination, novation or amendment of the Linked Transaction, unless otherwise delayed beyond such date by the Independent Amount Determining Party. The foregoing may be amended in accordance with, and is subject to, any relevant contract between the parties. • Item 28, Single/Initial Payment: Indicates the amount of an agreed payment owed by one party to the other party on the date specified. If the Buyer is payer, the parties do not need to identify the payer or payee as the System will automatically identify the Buyer as payer and the other party as payee. If the Seller is payer, the Transaction Record must identify the payer by use of the Company assigned ID. The currency shall be identical to the currency of the Floating Rate Payer Calculation Amount, which, if the Master Document Transaction Type is Standard North American Corporate, Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Japan Corporate, Standard Japan Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, must be one of the applicable currencies specified in the ISDA Matrix for that transaction type. An initial payment shall be in lieu of or in addition to the payments determined by items 23 and 24. If the Master Document Transaction Type is Standard North American Corporate, Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Japan Corporate, Standard Japan Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, the payment date will be overwritten to be the third Business Day following the Trade Date. • Item 29, Calculation Agent City: The Calculation Agent City may be identified by codes used for FpML purposes and published by ISDA. The Company may, after Important Notice issued in accordance with these Operating

Procedures, choose to validate submissions against these codes. If this field is left blank, the System will automatically specify the Calculation Agent City based on the applicable default set forth in the ISDA Matrix. If the Master Document Transaction Type is Standard North American Corporate, this field will be overwritten with the applicable business center set forth in the ISDA Matrix for such transaction type. If the Master Document Transaction Type is Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, this field will be overwritten with London. If the Master Document Transaction Type is Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan or Standard Latin America Sovereign, this field will be overwritten to be New York. If the Master Document Transaction Type is Standard Japan Corporate or Standard Japan Sovereign, this field will be overwritten to be Tokyo. • Item 30, First Payment Period Accrual Start Date: If a date is specified, the first Fixed Rate Payer Calculation Period will commence on, and include, such date. If specified, the First Payment Period Accrual Start Date should be a date before the Effective Date. If the Master Document Transaction Type is Standard North American Corporate, Standard European Corporate, Standard Subordinated European Insurance Corporate, Standard Western European Sovereign, Standard Emerging European Corporate LPN, Standard Emerging European Corporate, Standard Latin America Corporate Bond, Standard Latin America Corporate Bond or Loan, Standard Latin America Sovereign, Standard Emerging European and Middle Eastern Sovereign, Standard Australia Corporate, Standard Australia Sovereign, Standard New Zealand Corporate, Standard New Zealand Sovereign, Standard Asia Corporate, Standard Asia Sovereign, Standard Singapore Corporate, Standard Singapore Sovereign, Standard Japan Corporate, Standard Japan Sovereign, Standard Sukuk Corporate or Standard Sukuk Sovereign, this field will be overwritten to be the Fixed Rate Payer Payment Date falling on or immediately prior to the calendar day immediately following the Trade Date (and for this purpose, Section 2.10 of the 2003 ISDA Credit Derivatives Definitions will be deemed amended by deleting the words “during the term of the Transaction”). Formatted: Font: Italic • Item 31, Additional Matrix Provisions: For a fixed recovery swap, “ISDA2010FixedRecovery” must be specified. • Item 32, Additional Terms: Users may insert up to 255 characters of free text specifying, among other things, additional terms applicable to the transaction (e.g., credit linkage terms). A submission of “N” or “n” as the sole character in this data element will be treated for matching purposes as if the data element had been left blank. • Item 33, Recovery Price: The specified Recovery Price will be the “Final Price” for purposes of the Additional Provisions for Fixed Recovery CDS Transactions.

• Item 343, Comment: This data element is visible only to each User (and not its counterparty) and will only appear in each such User’s Transaction Record. • Item 354, Payer: This is the designation of the User that is the Payer of the Payment Amount under the transaction.

76 Rev. 2011-21 (Release Date: January February 28, 2011)

Trade Warehouse Appendix to The Warehouse Trust Company LLC Operating Procedures

THE WAREHOUSE TRUST COMPANY LLC TRADE INFORMATION WAREHOUSE

I. INTRODUCTION

The Warehouse Trust Company LLC Trade Information Warehouse (the “Warehouse”) is implemented and maintained by the Company for the benefit of Users and is intended as a central trade information warehouse for records of eligible transactions (“Warehouse Eligible Transactions”). All Warehouse Eligible Transactions (and related records) included or to be included in the Warehouse from time to time shall be subject to the provisions set forth in this Appendix and the Company’s Applicable Publications, each as may be amended from time to time. The Warehouse will be deemed a Service for purposes of the Operating Procedures; provided that in the event of any conflict between this Appendix and any other provision of the Operating Procedures (or the appendices thereto) in connection with a Warehouse Eligible Transaction (and related records) included or to be included in the Warehouse, this Appendix shall govern.

II. WAREHOUSE ELIGIBLE TRANSACTIONS

The initial Warehouse Eligible Transactions will be credit default swap transactions that are eligible to be confirmed under Appendices B, C, K and L of the MarkitSERV Operating Procedures (i.e., single name credit default swaps (using master confirmation agreements, default master confirmation agreements or the ISDA physical settlement matrix) and index credit default swaps (using master confirmation agreements, default master confirmation agreements or published standard terms). The elements of the record to be maintained in the Warehouse for any Warehouse Eligible Transaction shall be as set forth in the applicable Appendix of the MarkitSERV Operating Procedures for transactions of that type, the operating procedures for Other Confirmation Services (as defined below), in this Appendix or in any other template adopted by the Company for that purpose from time to time, in each case with such modifications as the Company shall determine.

The Company may from time to time designate additional categories of transactions as Warehouse Eligible Transactions by amendment to the Operating Procedures or by Important Notice or through Applicable Publications.

III. INITIAL SUBMISSION OF WAREHOUSE TRANSACTIONS

On or after the date specified by the Company through an Important Notice for each category of Warehouse Eligible Transaction (the “Warehouse Inception Date”), records of Warehouse Eligible Transactions of that category may be included in the Warehouse in any of the following manners:

• Records of New Trades in Warehouse Eligible Transactions that have been submitted on or after the Warehouse Inception Date to the MarkitSERV Confirmation Service for confirmation will automatically be included in the Warehouse. For purposes hereof, a “New Trade” will be either a new Warehouse Eligible Transaction entered into between Users or a Warehouse Eligible Transaction between Users resulting from an assignment or novation of a Warehouse Eligible Transaction.

• The Company may from time to time enter into arrangements with other confirmation matching services or facilities (“Other Confirmation Services”) pursuant to which records of New Trades in Warehouse Eligible Transactions confirmed through those systems on or following the Warehouse Inception Date may be included in the Warehouse. The Company will designate any such Other Confirmation Services, and any applicable procedures for the inclusion in the Warehouse of records of Warehouse Eligible Transactions from those Other Confirmation Services in the Warehouse, by amendment to these Operating Procedures or by Important Notice or through Applicable Publications.

• Records of other Warehouse Eligible Transactions may be included in the Warehouse through the backloading procedures set forth in Section VI below.

New records of Warehouse Eligible Transactions may not be included in the Warehouse in any other manner. The record for each Warehouse Eligible Transaction that has been included in the Warehouse will be referred to as a “Warehouse Record” and the related transaction will be referred to as a “Warehouse Transaction” hereunder. The Warehouse Record will consist of the applicable Transaction Records (as defined in the operating procedures for the MarkitSERV Confirmation Service (the “MarkitSERV Operating Procedures”)) or other applicable Record for the relevant type of transaction as specified by the Operating Procedures, and may be modified from time to time by Modifications (as defined in Section IV below). Following the occurrence of a Modification, the Warehouse Record for purposes hereof will be the Warehouse Record as so modified. All Warehouse Records will, upon inclusion in the Warehouse, be assigned a Trade Reference Identifier (“TRI”) that will enable Users to track such Warehouse Records in the Warehouse. Without prejudice to any provisions hereof, Warehouse Records (as so defined) may for various purposes also be commonly be referred to as “gold” records. The Company may also maintain in the Warehouse records of transactions that do not constitute “gold” Warehouse Records (which may include records commonly referred to as “bronze” records or “copper” records), in each case on the terms set forth herein or in Applicable Publications.

The Warehouse will maintain the current status of each Warehouse Record as “Certain,” “Uncertain” or in certain cases, “Unconfirmed/Alleged”, as described in more detail herein. With respect to Warehouse Records for New Trades included in the Warehouse through submission to the MarkitSERV Confirmation Service, such Warehouse Records will have a status of “Certain” upon achieving a status of “Confirmed” in the MarkitSERV Confirmation Service and satisfaction of any applicable business validation rules specified by the Company in the Applicable Publications (the “Validation Rules”). Prior to achieving a status of “Certain” in the Warehouse, such Warehouse Records will have a status of “Unconfirmed/Alleged” in the Warehouse. If a Warehouse Record for a New Trade submitted to the MarkitSERV Confirmation Service that has a

status of “Unconfirmed/Alleged” is cancelled in accordance with Section 3 of the MarkitSERV Operating Procedures, such Warehouse Record will be removed from the Warehouse.

Warehouse Records included in the Warehouse through backloading will initially have a status of “Certain” as provided in Section VI below. Warehouse Records for New Trades included in the Warehouse from Other Confirmation Services will have a status of “Certain” as specified in any procedures adopted by the Company with respect to such Other Confirmation Services.

IV. MODIFICATION OF WAREHOUSE RECORDS

The terms and status of a Warehouse Record in the Warehouse may be modified from time to time to reflect certain confirmable and non-confirmable post-trade events and, if applicable, credit events with respect to the related Warehouse Transaction (each, a “Modification”).

A. Confirmable Modifications

Confirmable post-trade events (“Confirmable Modifications”) will include the following actions by the parties to a Warehouse Transaction:

• Amendment

• Assignment/novation

• Increase

• Partial Termination

• Full Termination

• Any other post-trade events as may be specified by the Company in the Applicable Publications.

The Warehouse will reflect Confirmable Modifications that have been submitted to the MarkitSERV Confirmation Service as follows: If a Confirmable Modification is submitted to the MarkitSERV Confirmation Service but has not yet been confirmed through the MarkitSERV Confirmation Service (i.e., it has the status of “Unconfirmed” or “Alleged” in the MarkitSERV Confirmation Service), the status of the Warehouse Record will become “Uncertain”. Upon confirmation of the Confirmable Modification through the MarkitSERV Confirmation Service and satisfaction of any applicable Validation Rules, the Warehouse Record will be updated and will again have a status of “Certain.”

The Warehouse may also reflect Confirmable Modifications that have been confirmed through Other Confirmation Services, as may be specified by the Company. Following submission of such confirmed Confirmable Modification and satisfaction of any applicable Validation Rules, the Warehouse Record will be updated and will have a status of “Certain”.

In addition, the status of a Warehouse Record may become “Uncertain” if, as a result of Confirmable Modifications confirmed out of order or mistakenly confirmed, the relevant notional

amount (or similar term thereto) set forth in a Warehouse Record becomes negative.

B. Non-Confirmable Modifications

The Company may from time to time adopt procedures for the modification of Warehouse Records (without action by Users) to reflect certain post-trade events on the basis of information provided by certain third party sources (“Non-Confirmable Modifications”), including, without limitation, (i) factor adjustments for relevant indexes provided by index sponsors or parties designated by index sponsors and (ii) rate resets based on index values or levels published by designated sources. The Company will implement any such procedures through an amendment to the Operating Procedures.

Prior to the adoption of any such applicable procedures, the parties to a Warehouse Transaction will be responsible for either amending the related Warehouse Record to reflect any relevant Non-Confirmable Modifications or submitting “exit” records with respect to such Warehouse Record following such Non-Confirmable Modification.

C. Credit Event Modifications

The Company has adopted pursuant to Section VIII and Section VIIIA of this Appendix and may adopt additional procedures for the modification of certain Warehouse Records that are credit default swap transactions to reflect the occurrence of certain credit events (“Credit Event Modifications”). The Company will notify Users of additional such procedures through an amendment to the Operating Procedures or by Important Notice or through Applicable Publications.

Pending the adoption of additional procedures, if a credit event notice or similar notice is delivered and a Protocol Settlement Designation pursuant to Section VIII of this Appendix is not made (i) with respect to a Warehouse Transaction that is a “single name” credit default swap, the parties to such transaction must submit “exit” records with respect to the related Warehouse Record, as provided in Section V below; and (ii) with respect to a Warehouse Transaction that is an “index” credit default swap, the related Warehouse Record may be maintained in the Warehouse but will not reflect any such delivery or any settlement with respect to the related credit event under such Warehouse Transaction (unless the parties amend the Warehouse Record accordingly or the relevant information is provided to the Company through other means as may be designated by the Company in an amendment to the Operating Procedures).

D. Successor Event Modifications

The Company has adopted pursuant to Section X of this Appendix and may adopt additional procedures for the modification of certain Warehouse Records that are credit default swap transactions to reflect the occurrence of certain successor events with respect to the relevant reference entity (“Successor Event Modifications”). The Company will notify Users of any such additional procedures through an amendment to the Operating Procedures or by Important Notice or through Applicable Publications.

To the extent any successor or similar event occurs with respect to a Warehouse Transaction and such event is not addressed by the procedures set forth in Section X of this 4

Appendix or otherwise adopted by the Company as described above, the parties to such transaction will be responsible for making any necessary amendment to the related Warehouse Record to reflect such event and/or submitting “exit” records with respect to such Warehouse Record following such event.

V. LEGAL STATUS OF WAREHOUSE TRANSACTIONS AND WAREHOUSE RECORDS

Each User that is party to a Warehouse Transaction shall be deemed to agree that, notwithstanding any provisions in any applicable Master Document or other documentation relating to such transaction:

(i) as of any date, the related Warehouse Record, if it has a current status of “Certain,” represents the definitive record of the applicable Replaced Document for such Warehouse Transaction as of such date and shall supersede any other documentation or understanding, whether written, oral or electronic, between the parties with respect to such Replaced Document (except as otherwise provided below with respect to “index” credit default swaps and in Section VI below with respect to backloaded Warehouse Records);

(ii) such Warehouse Record shall constitute an acceptable method under the related Master Documents for evidencing the terms to be specified in the applicable Replaced Document;

(iii) upon the occurrence of any Modification of a Warehouse Record and establishment of a current status of “Certain” with respect thereto, the Warehouse Record shall be deemed to have been amended and restated to reflect such Modification;

(iv) a Warehouse Record with a current status of “Certain” shall have the same legal effect as a fully executed Replaced Document or amended and restated Replaced Document, as the case may be, entered into pursuant to and subject to the terms of the related Master Documents and shall evidence a transaction between the two Users whose terms and provisions will be set forth in, governed by, construed in accordance with and subject to such record itself, such Master Documents and the Operating Procedures (including the applicable appendices thereto); and

(v) without limiting the foregoing, the determination of any payments (including Informational Payment Calculations described in Section VII) or settlements by the Company with respect to a Warehouse Transaction shall be made solely on the basis of the related Warehouse Record, the Operating Procedures and certain assumptions as may be adopted from time to time by the Company and set forth by Important Notice or through Applicable Publications. For this purpose, the Company shall not be deemed to have notice of the terms of any other agreement or understanding between Users, including without limitation, Master Documents.

A Warehouse Record that has a current status of “Uncertain” or “Unconfirmed/Alleged” will not be subject to the provisions set forth above applicable to Warehouse Records with a status of “Certain”. The fact that a Warehouse Record has a current status of “Uncertain” or “Unconfirmed/Alleged” does not, however, necessarily indicate that the related Warehouse Transaction is not a binding agreement or that all of the terms of such Warehouse Record, or any particular terms, are uncertain or disputed. The legal status of a Warehouse Record with a current 5

status of “Uncertain” or “Unconfirmed/Alleged” or of the related Warehouse Transaction (and the terms thereof) will depend, among other things, on the provisions of the applicable Master Documents or other documentation relating to the relevant Warehouse Transaction, including the procedures for contract formation agreed to by the parties, the relevant Warehouse Record, the relationship between the parties, communications, negotiations and actions by the parties with respect to the Warehouse Transaction and any Applicable Law. For the avoidance of doubt, the fact that a Warehouse Record has a status of “Uncertain” at any time shall not be deemed to retroactively affect the status of such record as “Certain” at any prior time.

The parties to a Warehouse Transaction may, through procedures described in Applicable Publications, submit an “exit” record indicating their intent to remove (or “exit”) the related Warehouse Record from the Warehouse. If one User submits such an “exit” record to the Company with respect to a Warehouse Record, the current status of such Warehouse Record will become “Uncertain,” with the consequences described in the preceding paragraph. Upon confirmation of an “exit” record by both parties to a Warehouse Transaction, as described in Applicable Publications, the related Warehouse Record shall cease to be a Warehouse Record. In addition, an election by the parties to the Warehouse Transaction as described in “Exit of Confirmed Transactions” in Section 3 of the MarkitSERV Operating Procedures shall automatically cause the related Warehouse Record to cease to be a Warehouse Record. Without limiting the foregoing, upon confirmation of an “exit” record by both parties to a Warehouse Transaction where such “exit” record contains an additional code or identifier defined in an Important Notice or Applicable Publications as providing for the termination of such Warehouse Transaction, then such Users shall be deemed to have agreed that the related Warehouse Transaction upon such exit shall be terminated in full, without further obligation of either party to the other, and in such case such “exit” record shall be deemed a confirmation of such termination for all purposes.

Upon the termination of a User’s participation in the System in accordance with the Operating Procedures, the provisions of this Section V shall only apply to its Warehouse Records through the date of termination, and such records shall cease to be Warehouse Records thereafter and shall not be subject to any amendments or modifications to the Operating Procedures following such date of termination. In addition, any Warehouse Records of such User that have the status of “Unconfirmed/Alleged” in the Warehouse will be deemed cancelled.

Upon a record ceasing to be a Warehouse Record, such record as maintained in the Warehouse as of the date of exit shall become fixed and will not be modified by the Company for any subsequent events affecting the related Warehouse Transaction. Accordingly, such Warehouse Record will only reflect the terms of the related Warehouse Transaction as of the date of exit, and the parties will need to separately document and confirm any subsequent modifications.

Except for Warehouse Transactions that are subject to processing pursuant to Section VIII of this Appendix, in the case of delivery of a credit event notice or similar notice (i) with respect to a Warehouse Transaction that is a “single-name” credit default swap, Users must submit “exit” records; and (ii) with respect to a Warehouse Transaction that is an “index” credit default swap, the related Warehouse Record will not reflect such delivery of credit event notices or similar notices or any settlement with respect to the related credit event under such Warehouse Transaction (unless

the parties amend the Warehouse Record accordingly or the relevant information is provided to the Company through other means as may be designated by the Company in an amendment to the Operating Procedures), and as a result the Warehouse Record will not constitute the definitive record with respect to any such matters (unless reflected in an amendment to the Warehouse Record or information provided to the Company through such other means) but will otherwise remain the definitive record of the applicable Replaced Document as set forth in this Section V.

In addition, Users submitting Warehouse Transactions to a “tear-up” or similar service (such as TriOptima) must ensure that the Warehouse Record remains accurate through the submission of appropriate Records as specified in the Operating Procedures or by Important Notice or through Applicable Publications. With respect to Warehouse Transactions that are terminated early pursuant to the related Master Documents (including, without limitation, as a result of an event of default), Users must also ensure that the Warehouse Record remains accurate through the submission of appropriate Records as specified in the Operating Procedures or by Important Notice or through Applicable Publications.

In the event that the parties to a Warehouse Transaction agree that the Warehouse Record is erroneous or has an incorrect status (e.g., through a mutual mistake of fact), such parties may, upon submission to the Company of written confirmation of the error to the satisfaction of the Company, request that the Company make such adjustments to the Warehouse Record as may be necessary to correct such error. Notwithstanding the foregoing, if the underlying Transaction Records for a Warehouse Transaction submitted to the MarkitSERV Confirmation Service cease to have a status of “Confirmed” in the MarkitSERV Confirmation Service pursuant to “Transaction Records Confirmed in Error” in Section 3 of the MarkitSERV Operating Procedures, the related Warehouse Record will cease to be a Warehouse Record.

The Company shall not be responsible for a User’s failure to properly identify, in records submitted to the Warehouse in accordance with this Appendix and the Operating Procedures, the terms of any Warehouse Transaction or any Modification thereto or to submit an “exit” record with respect to a Warehouse Transaction.

VI. BACKLOADING

The Company will allow Users to submit to the Warehouse, or “backload,” records of Warehouse Eligible Transactions confirmed outside of the MarkitSERV Confirmation Service, in accordance with the following procedures:

Records of Warehouse Eligible Transactions to be backloaded must be submitted by Users to the Warehouse electronically in the form of templates adopted for this purpose by the Company, which will generally be in the same form as the templates applicable to the submission of Transaction Records in the MarkitSERV Confirmation Service, with such modifications as the Company determines to be appropriate. Notwithstanding the foregoing, backloaded records (or the validation or matching rules applicable thereto) may have certain differences from records submitted through the MarkitSERV Confirmation Service. For example, certain fields may be optional and serve informational purposes only and/or matching may not be required with respect to certain required fields. Optional information-only fields will not form part of the definitive legal record of the relevant Replaced Document or otherwise affect the legal status of the relevant

Warehouse Record for purposes of Section V above. With respect to required fields that are not required to match, if the information therein matches, it will form part of the definitive legal record of the relevant Replaced Document to the same extent as the matching fields. If the information in such fields does not match, such information will not form part of the definitive legal record of the relevant Replaced Document. The fact that information in such fields does not match shall not in itself indicate that the related Warehouse Transaction is not a binding agreement and shall not in itself affect the status of the relevant Warehouse Record as a whole or any matched terms thereof for purposes of Article V (which, for the avoidance of doubt, the parties intend as the definitive record of such matched terms). The status of any such non-matched terms of a Warehouse Transaction will depend, among other things, on the provisions of the prior documentation relating to such Warehouse Transaction, any procedures for contract formation agreed to by the parties, the relationship between the parties, communications, negotiations and actions by the parties with respect to such Warehouse Transaction and Applicable Law. Notwithstanding anything to the contrary in the Operating Procedures, if a backloaded Warehouse Transaction with any such non-matched terms is to be assigned pursuant to the MarkitSERV Confirmation Service, then (i) with respect to any non-matched information as to the first payment date under the Warehouse Transaction, the Company will use the information contained in the payor’s backloaded record for purposes of populating the relevant field in the Transaction Record for the relevant Replaced Document as assigned (and such field will form part of the definitive legal record of the relevant Replaced Document of the assigned Warehouse Transaction) and (ii) the Company may permit or require the transferor and remaining party to resolve and confirm one or more of any other such non-matched terms for purposes of the Replaced Document as assigned (whereupon such resolved and confirmed terms will form part of the definitive legal record of the assigned Warehouse Transaction, and any non-matched terms not so resolved and confirmed will remain subject to the preceding provisions of this paragraph).

With respect to records submitted for backloading after February 19, 2009, in the case of a transaction that has been novated prior to the Backload Effective Date, it is expected that the date specified in the “Trade Date” field will be the Novation Trade Date, rather than the Original Trade Date. In such case, notwithstanding anything to the contrary in the Operating Procedures or the backloaded record, (i) the Original Trade Date for the backloaded Warehouse Transaction (including following any subsequent novation thereof) shall be as set forth in the Original Confirmation; (ii) in the event of any inconsistency between the backloaded Transaction Record and the Original Confirmation as to the Original Trade Date, the Original Confirmation shall govern; and (iii) the specification of the Novation Trade Date in the backloaded record shall not affect the validity of the original transaction confirmed by the Original Confirmation. With respect to any other backloaded Warehouse Transaction (including following any subsequent novation thereof), nothing in these Operating Procedures will preclude the parties from claiming that the Original Trade Date and/or Novation Trade Date, if applicable, should be determined on the basis of the Original Confirmation, notwithstanding that the backloaded records have a status of “Certain.” Without limiting the foregoing, one or both parties to a backloaded Warehouse Transaction may, for reference purposes only, specify the Original Trade Date of the transaction in a non-matching free text or comment field in the backloaded record.

As used in the preceding paragraph:

The “Original Confirmation” shall mean, with respect to a backloaded Warehouse

Transaction, the original confirmation thereof between the parties thereto, as amended or supplemented from time to time (or other applicable documentation, agreements or understandings as to the terms and conditions of such transaction), including, for purposes of the determination of the Novation Trade Date, any novation confirmation or agreement with respect thereto, in any case as in effect for such Warehouse Transaction immediately prior to the Backload Effective Date.

The “Original Trade Date” shall mean, with respect to a backloaded Warehouse Transaction, the original Trade Date for the backloaded Warehouse Transaction regardless of any novation thereof.

Each backloaded record will contain a field named “Backload Effective Date”. Users submitting records of Warehouse Eligible Transactions for backloading should specify the terms of the related Warehouse Transactions that are current as of the specified Backload Effective Date, reflecting all post-trade events that occurred on or prior to the Backload Effective Date.

With respect to backloaded records for Single Entity Matrix Transactions (as defined in Appendix K of the MarkitSERV Operating Procedures), notwithstanding anything to the contrary in these Operating Procedures, if the “Master Document Date” field is blank, Users will be deemed to have incorporated the ISDA Matrix (as defined in Appendix K of the MarkitSERV Operating Procedures) most recently published as of the Backload Effective Date. Users wishing to have a different version of the ISDA Matrix apply to the backloaded transaction must specify the applicable publication date thereof in the “Master Document Date” field.

If two Users submit backloaded records for Warehouse Eligible Transactions that match (in accordance with the matching requirements for backloaded records or the Validation Rules), or a User affirms a backloaded record submitted by the other User, and in either case the record satisfies the applicable Validation Rules, such record will be compared to the records of existing transactions in the MarkitSERV Confirmation Service. If the backloaded record is not in the existing MarkitSERV Confirmation Service database, the record will be automatically loaded into the Warehouse as a Warehouse Record with a status of “Certain.”

If a record for the transaction exists in the MarkitSERV Confirmation Service database, the backloaded record will be compared to the “imputed trade state” for that transaction in the MarkitSERV Confirmation Service. If the backloaded record matches the “imputed trade state” (as more fully specified in the Applicable Publications), it will be automatically loaded into the Warehouse as a Warehouse Record with a status of “Certain.” If the backloaded record does not match the “imputed trade state,” the relevant Users will be notified. In such case, if both Users elect, the record as submitted for backloading will be manually loaded to the Warehouse as a Warehouse Record with a status of “Certain” (notwithstanding any discrepancies from its “imputed trade state” in the MarkitSERV Confirmation Service).

With respect to any Warehouse Transaction that is a credit default swap transaction, the Reference Entity as specified in the backloaded record is intended to be the correct name of the Reference Entity as at the Backload Effective Date as determined in accordance with the terms of the relevant Warehouse Transaction (including any prior documentation relating thereto) and taking into account any relevant Material Event (as defined below) that occurred prior to the

Backload Effective Date.

Subject to the following paragraph, the Reference Entity specified in the backloaded record will become the Reference Entity for the purposes of the Warehouse Transaction, provided that (subject to the following paragraph) all references to the Reference Entity in any documentation relating to the Warehouse Transaction will be interpreted on the basis that the Reference Entity name was correct as at the Backload Effective Date.

In the event that a Material Event occurred with respect to a Reference Entity prior to the Backload Effective Date and the parties failed to correctly take into account such Material Event in the backloaded records for the relevant Warehouse Transaction (such that the Reference Entity and/or the Floating Rate Payer Calculation Amount specified in the Warehouse Record were not correct as of the Backload Effective Date), nothing in these Operating Procedures will preclude the parties from claiming that the Reference Entity and/or Floating Rate Payer Calculation Amount for such Warehouse Transaction should be determined on the basis of any confirmation relating to such Warehouse Transaction existing prior to the Backload Effective Date, and any associated documentation, agreements or understandings relating to the consequences of such Material Event, notwithstanding that the backloaded records have a status of “Certain.” For the avoidance of doubt, in such circumstances, Users may submit an Amendment in accordance with these Operating Procedures to correct the backloaded Warehouse Record as of the Backload Effective Date.

For the purposes of this Section VI, a “Material Event” means an event that has occurred in respect of a Reference Entity prior to a relevant Backload Effective Date, including but not limited to any name changes and/or determination of one or more Successors pursuant to the Credit Derivatives Definitions.

Each User agrees that a backloaded record of a Warehouse Eligible Transaction that has attained the status of “Certain” in the Warehouse shall constitute the amendment and restatement of the relevant Replaced Document for the related transaction as of the Backload Effective Date and in the form uploaded to the Warehouse (except as set forth above with respect to non-matching terms). Thereafter, such record shall constitute a Warehouse Record for all purposes under this Appendix (including, without limitation, in connection with Modifications that occur after the Backload Effective Date).

For the avoidance of doubt, until it is loaded into the Warehouse with a status of “Certain”, a record submitted for backloading will not constitute a Warehouse Record for purposes of this Appendix and will not be subject to the provisions of Section V above. The submission of a record of a Warehouse Eligible Transaction shall not affect the status of any payments or settlements thereunder made prior to the Backload Effective Date.

VII. INFORMATIONAL PAYMENT CALCULATIONS

NOTE: The following provisions shall be in effect for payments calculated by the Company other than pursuant to the Central Settlement Appendix to the Operating Procedures. The Company may provide calculations (“Informational Payment Calculations”) with respect to certain payments due under Warehouse Transactions, as set forth by the Company from

time to time by Important Notice or through Applicable Publications. Any Informational Payment Calculations may be made by the Company solely on the basis of the related Warehouse Record, the Operating Procedures and certain assumptions as may be adopted from time to time by the Company by an Important Notice or through Applicable Publications. For this purpose, the Company shall not be deemed to have notice of the terms of any other agreement or understanding between Users that may affect relevant Informational Payment Calculations, including, without limitation, Master Documents.

The Informational Payment Calculations are intended merely for the convenience of Users and for informational purposes only. In providing Informational Payment Calculations, the Company will not be acting as agent or in a similar capacity for any User and will not be acting as calculation agent or in a similar capacity under the terms of any Warehouse Transaction. Without limiting any other provisions of the Operating Procedures (including, without limitation, the Important Legal Information section), the Company will have no responsibility or liability for the accuracy of any Informational Payment Calculations. Informational Payment Calculations will not create, alter or foreclose any legal obligation related to a Warehouse Transaction (including, but not limited to, any applicable payment obligation) that may exist between or among Users. Although records of Informational Payment Calculations will be maintained in the Warehouse, they will not form part of any Warehouse Record.

VIII. PROCESSING AFTER CREDIT EVENTS VIA PROTOCOL OR AUTOMATIC ADHERENCE

On or after the date determined by the Company and subject to the provisions herein and in any Applicable Publications, the Company will provide a facility for Users to submit protocol adherence notices or messages (each, a “Protocol Adherence Message”) with respect to credit events related to specified categories of Warehouse Transactions that are credit derivative transactions, with the effect set forth herein.

Unless otherwise determined by the Company, the Protocol Adherence Message function will not be available for Warehouse Transactions relating to a particular reference entity unless the Company has specifically activated the function for that entity. The Company will activate the Protocol Adherence Message function for a reference entity (a “Protocol Activation Event”) upon (i) in the case of Auction Supplement Transactions (other than where the relevant credit event is a restructuring) (“Non-Restructuring Auction Supplement Transactions”), upon receipt by the Company of a statement or notice from ISDA or the relevant Credit Derivatives Determinations Committee (as defined in the Auction Supplement) that a settlement auction will be held with respect to such reference entity; or (ii) in the case of other transactions (other than where the relevant credit event is a restructuring), (a) receipt of a written request to do so by one or more members of the Company’s senior operations working group (or any successor to such group), which request must be in accordance with procedures for that purpose established by the Company and must state that a credit event has occurred and specify in reasonable detail the facts relevant to the determination of such credit event or (b) receipt of a published statement from a widely recognized industry group or index publisher or service provider for the relevant product indicating that a credit event has occurred and specifying in reasonable detail the facts relevant to the determination of such credit event (including, by way of example and without limitation, an announcement that an auction settlement protocol will be conducted with respect to a reference

entity). The Company, through Important Notice, will inform all Users that a Protocol Activation Event has occurred. Prior to the occurrence of a Protocol Activation Event, the System will not accept any Protocol Adherence Messages for a reference entity. As used herein, an Auction Supplement Transaction is a Warehouse Transaction (i) that is subject to the 2009 ISDA Credit Derivatives Determinations Committees and Auction Settlement Supplement to the 2003 ISDA Credit Derivatives Definitions, as published by ISDA on March 12, 2009 (the “March 2009 Auction Supplement”) or the 2009 ISDA Credit Derivatives Determinations Committees, Auction Supplement and Restructuring Supplement to the 2003 ISDA Credit Derivatives Definitions, as published by ISDA on July 14, 2009 (the “July 2009 Auction Supplement, and together with the March 2009 Auction Supplement, an “Auction Supplement”), by the terms of these Operating Procedures, (ii) that had a Trade Date or Novation Date, as applicable, prior to April 8, 2009 but is a Protocol Covered Transaction (other than a Covered Non-Auction Transaction)) as defined in the 2009 ISDA Credit Derivatives Determinations Committees and Auction Settlement CDS Protocol (the “March 2009 Auction Settlement Protocol”) or would be such transaction but for the failure of a party to adhere to the March 2009 Auction Settlement Protocol or (iii) that had a Trade Date or Novation Date, as applicable, prior to July 24, 2009 but is a Protocol Covered Transaction (other than a Covered Non-Auction Transaction)) as defined in the 2009 ISDA Credit Derivatives Determinations Committees, Auction Settlement and Restructuring CDS Protocol (the “July 2009 Auction Settlement Protocol”, and together with the March 2009 Auction Settlement Protocol, an Auction Settlement Protocol) or would be such transaction but for the failure of a party to adhere to the July 2009 Auction Settlement Protocol. For the avoidance of doubt, the Company shall treat Warehouse Transactions described in clause (ii) and (iii) above as Auction Supplement Transactions, regardless of whether the parties to such transactions adhered to the Auction Settlement Protocol, and the Company will have no obligation to inquire or determine whether the parties to a Warehouse Transaction adhered to such protocol.

The occurrence of a Protocol Activation Event for a reference entity shall not be deemed to be a determination or representation by the Company that any alleged credit event has or has not occurred with respect to that reference entity under any applicable Master Document or the Credit Derivatives Definitions and shall not be deemed to affect the determination by the parties or others under the terms of any Warehouse Transaction as to whether a credit event has or has not occurred. The Company will have no responsibility or liability for the accuracy of any information set forth in any notice delivered by members of the Company’s senior operations working group (or any successor to such group) or received from an industry group, index publisher, service provider or determination committee related to such Protocol Activation Event. Without limiting the foregoing, the Company will have no responsibility for determining whether any relevant credit event occurred prior to any Credit Event Backstop Date for a Warehouse Transaction.

The Company, through Important Notice or through Applicable Publications, will specify the information that Users will be required to provide in order to submit a valid Protocol Adherence Message and the manner in which such messages are to be submitted (including whether such messages may be in electronic or other written form). Users may submit a global Protocol Adherence Message with respect to all Warehouse Transactions related to the applicable reference entity and/or may submit Protocol Adherence Messages with respect to individual Warehouse Transactions. In the case of a global Protocol Adherence Message, the Company will deem the Protocol Adherence Message to apply to each Warehouse Transaction related to the applicable reference entity as determined in accordance with the specified RED code (or similar

code) for that entity. A User that has submitted a global Protocol Adherence Message may revoke such global message such that it will not apply to any relevant Warehouse Transactions added to the Warehouse after such revocation. In addition, a User that has submitted a Protocol Adherence Message with respect to a particular Warehouse Transaction (either by a global message or individually) may revoke such message with respect to that Warehouse Transaction at any time prior to the Processing Cut-Off Time (as defined below). Notwithstanding anything to the contrary herein, unless otherwise determined by the Company, each User party to a Warehouse Transaction that is (i) a Non-Restructuring Auction Supplement Transaction or (ii) a tranched index credit default swap transaction or loan index credit default swap transaction (whether untranched or tranched) that is not a Non-Restructuring Auction Supplement Transaction, in either case related to the applicable reference entity will automatically be deemed by the Company to have submitted a Protocol Adherence Message with respect to such transaction (and references herein to “submission” of a Protocol Adherence Message shall include any such deemed submission); provided that such User may revoke such Protocol Adherence Message for such transaction at any time prior to the Processing Cut-Off Time; provided, further, that clause (i) will only apply where the Protocol Activation Event occurred on or following June 20, 2009. The Company may operate the Protocol Adherence Message function separately in connection with Auction Side Letters (as defined below) for applicable reference entity.

Submission of a valid Protocol Adherence Message by both Users party to a Warehouse Transaction, where such message has not been revoked by either User for such Warehouse Transaction as of a certain cut-off date and time established by the Company for the relevant Protocol Activation Event (the “Processing Cut-Off Time”), will serve as an instruction by such Users to the Company to calculate and process settlement payments for such transaction in accordance with any applicable Transaction Auction Settlement Terms, subject to the terms and conditions set forth herein (a “Protocol Settlement Designation”).

For these purposes, “Transaction Auction Settlement Terms” will include any applicable ISDA cash settlement protocol or Transaction Auction Settlement Terms (or other similar process by which the “final price” (or similar term) with respect to qualifying credit derivative transactions is determined), including without limitation the Transaction Auction Settlement Terms under the Auction Supplement. For the avoidance of doubt, the Processing Cut-Off Time may be later than any deadline for adherence under Transaction Auction Settlement Terms, if applicable.

Notwithstanding the foregoing, the Company will only calculate and process settlement payments for a Warehouse Transaction based on the applicable Transaction Auction Settlement Terms if the following conditions are met: (i) the Warehouse Transaction shall have a status of “Certain” in the Warehouse as of the Processing Cut-Off Time, (ii) the Company is at such time calculating and processing payments for the relevant type of transaction and the Users party to the transaction have satisfied any applicable conditions to the use of those payment calculation and processing services, (iii) relevant auction settlement terms covering the credit event related to the applicable Protocol Activation Event apply to the transactions of the same type as the Warehouse Transaction, (iv) solely to the extent adherence to Transaction Auction Settlement Terms is required under the terms thereof, both Users party to the Warehouse Transaction have adhered to such Transaction Auction Settlement Terms as of the deadline for such adherence (and satisfied any conditions with respect thereto) and neither party has revoked its adherence prior to such time, based on information made publicly available by ISDA or the other party sponsoring the auction

(the “Auction Sponsor”) or both Users party to the Warehouse Transaction shall have notified or confirmed to the Company, in a manner to be specified by the Company and by a deadline to be specified by the Company, that they have entered into a side letter or other arrangement (a “Auction Side Letter”) specifying that the Warehouse Transaction (by itself or together with other transactions between them) shall be settled on the basis of the final price determined pursuant to the Transaction Auction Settlement Terms, (v) both Users party to the Warehouse Transaction have submitted a valid Protocol Adherence Message applicable to such Warehouse Transaction and neither party has revoked such message with respect to such Warehouse Transaction as of the Processing Cut-Off Time and (vi) the applicable auction or other settlement or price determination mechanism under the terms of the Transaction Auction Settlement Terms occurs and a “final price” or similar settlement price is determined and published by the Auction Sponsor. In addition, in calculating settlement payments for a Warehouse Transaction that is an index credit default swap, the Company will assume that all settlement payments due (or that would be due following delivery of any required notices) with respect to credit events occurring prior to the Protocol Activation Event have been made.

If such conditions are satisfied with respect to a Warehouse Transaction, each User shall be deemed to agree, by submission of a Protocol Adherence Message, that, notwithstanding anything to the contrary in any applicable Master Document or other documentation for such transaction, (i) the settlement of the relevant Warehouse Transaction (including the settlement method and determination of any relevant final price) shall be subject to and governed by the applicable Transaction Auction Settlement Terms and (ii) any calculations and settlement processing performed by the Company with respect to such Warehouse Transaction shall be performed on the basis of the final price determined in accordance with the applicable Transaction Auction Settlement Terms. Following the completion of any such settlement processing for a Warehouse Transaction that is a “single-name” credit default swap, the related Warehouse Record will automatically be deemed to “exit” the Warehouse, with the effect set forth in Section V of this Appendix. Following the completion of any such settlement processing for a Warehouse Transaction that is an “index” credit default swap (whether “tranched” or “untranched”), if (i) the index publisher has published a new version of the relevant index taking into account the occurrence of the relevant credit event (the “New Index Version”), (ii) the related Warehouse Record has a status of “Certain” as of the applicable cash settlement date for the Transaction Auction Settlement Terms and (iii) the Company is then providing index versioning services for such index, then the Company will automatically amend the “Index Name”, “Annex Date” (or equivalent fields) and any other relevant field in such Warehouse Record to reflect the New Index Version, effective as of such cash settlement date, and will thereafter use the latest version of the relevant settled entity matrix applicable to the New Index Version as of such cash settlement date for purposes of ongoing calculations.

Failure by Users to make a Protocol Settlement Designation in the System for a Warehouse Transaction or of the other conditions above to be satisfied shall not be deemed to affect the Users’ legal obligations with respect to that transaction or to indicate that it is not subject to any applicable Transaction Auction Settlement Terms or Auction Side Letter. Rather, the result of such failure will be that the Company will not calculate and process settlement payments for such transaction based on the applicable Transaction Auction Settlement Terms. The Company is not responsible for the consequences of any such failure. In addition, failure to make a Protocol Settlement Designation shall not affect the validity of any credit event notice or similar notice

14 delivered by a party or determination made by a determinations committee, where applicable.

For purposes of processing the settlement of Warehouse Transactions for which the above conditions are satisfied, the Company will use any applicable final or settlement prices published by the Auction Sponsor. The Company will have no responsibility or liability for the accuracy of such published prices or for the reasonableness or sufficiency of the process by which such prices were determined. The Company shall not, by virtue of providing the services described herein, be deemed to participate in or be involved with the administration or implementation of any auction or any other process whereby final prices are determined pursuant to Transaction Auction Settlement Terms or otherwise to have any connection with such protocol or any Auction Side Letter. The Company shall not be responsible for reviewing the terms or otherwise determining the sufficiency or scope of any Auction Side Letter.

In the case of (i) a Warehouse Transaction that is an untranched index credit default swap transaction for which one, but not both, parties submitted (and did not revoke) a Protocol Adherence Message for a credit event, (ii) a Warehouse Transaction that is an untranched index credit default swap transaction for which both parties submitted (and did not revoke) a Protocol Adherence Message for a credit event but for which credit event processing did not occur pursuant to this section VIII because the related Warehouse Record had a status of “Uncertain” at the relevant time, or (iii) a Warehouse Transaction that is an untranched index credit default swap transaction for which one or both parties submitted (and did not revoke) a Protocol Adherence Message for a credit event but for which a “no-calc” election had been made under the Central Settlement Appendix, the Company will nonetheless update the applicable calculation factor associated with the Warehouse Record to take into account such credit event for purposes of any future fixed amount (coupon) payment calculations for that transaction. Any such factor update shall not be deemed to create, alter or foreclose any legal obligation, right or defense related to a Warehouse Transaction (including with respect to such payment) that may exist between or among the parties thereto. For the avoidance of doubt, in such cases the Company will not calculate any cash settlement amount for such transaction in respect of such credit event.

A Warehouse Transaction that is a fixed recovery credit default swap shall be subject to processing pursuant to this Section VIII and Section VIIIA as otherwise provided herein and therein for credit default swaps relating to a single reference entity; provided that for purposes of the processing of the settlement of any such Warehouse Transaction, the Company will use the applicable final price set forth in the related Warehouse Record.

A Warehouse Transaction that is a credit default swaption related to a single reference entity shall be subject to processing pursuant to this Section VIII and Section VIIIA as otherwise provided herein and therein for credit default swaps relating to a single reference entity; provided that notwithstanding anything to the contrary herein, a Protocol Settlement Designation with respect to any such Warehouse Transaction shall serve as a direction by both Users to the Company to process the “exit” of such transaction from the Warehouse (and for the avoidance of doubt the Company shall not calculate or process any settlement in connection therewith).

VIIIA. PROCESSING FOR RESTRUCTURING CREDIT EVENTS

As used in this Section VIIIA, references to the “Credit Derivatives Definitions” shall be to the 2003 ISDA Credit Derivatives Definitions (as published by ISDA), as supplemented by the July 2009 Auction Supplement. Capitalized terms used in this Section VIIIA but not otherwise defined in this Appendix shall have the meanings set forth in the Credit Derivatives Definitions.

A. Scope of Application

Subject to subsections F and G below, the provisions set forth in Section VIIIA(B)-(D) below shall apply to any Restructuring Supplement Transaction (as defined below) relating to a single Reference Entity, and, to the extent provided in subsection E below, to any Restructuring Supplement Transaction relating to an index of Reference Entities.

B. Credit Event Notice Facility

On or after a date determined by the Company and subject to the provisions herein and in any Applicable Publications, the Company will provide a facility (the “Restructuring Credit Event Notice Facility”) for the delivery through the System of credit event notices in connection with Restructuring Supplement Transactions following a public announcement by ISDA that a Restructuring Credit Event has occurred with respect to a particular Reference Entity (such entity, a “Restructured Entity”). The Company, through Important Notice, will inform all Users that the Restructuring Credit Event Notice Facility has been activated for a particular Restructured Entity at the same time at which the facility is so activated. As used herein, a “Restructuring Supplement Transaction” is a Warehouse Transaction (i) that is subject to the July 2009 Auction Supplement by its terms (including without limitation through the terms of the applicable appendix of the MarkitSERV Operating Procedures or the operating procedures of another applicable confirmation service for the relevant product type of such Warehouse Transaction ) or (ii) that had a Trade Date or Novation Date, as applicable, prior to July 24, 2009 but is a Protocol Covered Transaction (other than a Covered Non-Auction Transaction)) as defined in the July 2009 Auction Settlement Protocol or would be such transaction but for the failure of a party to adhere to the July 2009 Auction Settlement Protocol. For the avoidance of doubt, the Company shall treat Warehouse Transactions described in clause (ii) above as Restructuring Supplement Transactions, regardless of whether the parties to such transactions adhered to the July 2009 Auction Settlement Protocol, and the Company will have no obligation to inquire or determine whether the parties to a Warehouse Transaction adhered to such protocol.

Pursuant to the Restructuring Credit Event Notice Facility, a User that is party to a Restructuring Supplement Transaction may submit a credit event notice message (the “Restructuring Credit Event Notice”). Such submission may serve as a “Credit Event Notice” by such User to the counterparty User with respect to the relevant Restructuring Credit Event for purposes of the relevant Restructuring Supplement Transaction, but without prejudice to any requirements applicable to Credit Event Notices under the Credit Derivatives Definitions other than the requirement that a Notifying Party deliver a Credit Event Notice directly to the other party to the relevant transaction.. Each User shall be deemed to agree that, notwithstanding anything to the contrary in any Master Documents or the Credit Derivatives Definitions, submission by a User of a Restructuring Credit Event Notice shall be a permissible and legally effective means of delivering a Credit Event Notice under the terms of such Restructuring Supplement Transaction without prejudice to any other means of delivery of a credit event notice permitted by the terms of

such Restructuring Supplement Transaction. For the avoidance of doubt, where both parties to a Restructuring Supplement Transaction submit Restructuring Credit Event Notice (or where one party or both parties to such Restructuring Supplement Transaction deliver Credit Event Notice(s) outside of the System) in respect of such Restructuring Supplement Transaction (or applicable portion thereof), the provisions in the Credit Derivatives Definitions as regards priority of Credit Event Notices given by protection buyer or protection seller shall apply; provided that the Company will not recognize for purposes of processing under this Section VIIIA any Credit Event Notice delivered outside of the System unless an Outside Credit Event Record (as defined below) is submitted with respect thereto and accepted by the counterparty. The Company shall not be responsible for determining whether a User party to a Restructuring Supplement Transaction is a Notifying Party or is otherwise entitled to deliver a Credit Event Notice under the terms thereof, and will conduct Credit Event processing on the basis that a User submitting a Restructuring Credit Event Notice is so entitled, but without prejudice to the rights and obligations of the parties to such Restructuring Supplement Transaction in respect of any impermissible delivery.

The Company will make the Restructuring Credit Event Notice available to the counterparty User through the System, and the System has been designed to make such notice available to the counterparty User as soon as practicable following the time of submission. For the avoidance of doubt the recipient of any such notice need not acknowledge or accept such notice in order for it to be effective for purposes hereof. The Company, through Important Notice or through Applicable Publications, will specify the information that Users will be required to provide in order to submit a valid Restructuring Credit Event Notice and the manner in which such messages are to be submitted. A Restructuring Credit Event Notice will be irrevocable. A User may submit a Restructuring Credit Event Notice with respect to a Restructuring Supplement Transaction whether or not such transaction has a status of “Certain” in the Warehouse. However, for the avoidance of doubt, the Company will calculate and process settlement payments for a Restructuring Supplement Transaction only if such transaction has a status of “Certain”.

The Restructuring Credit Event Notice will be deemed effective as of the Processing Time (as defined below), regardless of when such notice is submitted to the System by the submitting User or actually received or reviewed by the counterparty. The Company will only apply Restructuring Credit Event Notices for further processing with respect to a particular Restructuring Credit Event if the Processing Time is prior to the applicable exercise deadline for such event (the “Exercise Cut-Off Time”) under the Credit Derivatives Definitions. The Company will make available at the Processing Time through the System to both the submitting User and its counterparty the Processing Time for any Restructuring Credit Event Notice. A Restructuring Credit Event Notice with a Processing Time after the Exercise Cut-Off Time will be accepted and recorded by the System, but the Company will not treat it as being effectively delivered and will provide no further Credit Event processing with respect thereto, and such notice will not be effective for either party to the relevant Restructuring Supplement Transaction. As used herein, the “Processing Time” for a Restructuring Credit Event Notice or Movement Option Notice (as defined below) that has been submitted to the Company will be the time, as recorded by the Company, as of which the Company has completed those steps necessary in the System to make such notice available for viewing in the various DTCC access systems.

If a User party to a Restructuring Supplement Transaction is unable to access Restructuring Credit Event Notices sent to it through the System due to a failure of that User’s computer systems, 17

electronic messaging systems, or other similar occurrence, the Company will make available to the User, upon request, one or more periodic reports of such notices (as so requested) in a form determined by the Company. The Company will use best efforts to provide such report promptly upon request and with such frequency as is reasonably requested by the relevant User. Except to the extent provided in the “Important Legal Information” section of these Operating Procedures, the Company shall not be responsible for any delay in providing a Restructuring Credit Event Notice to the receiving party, and in no event shall the Company be responsible for any failure of such party to monitor the System for such notices or for any inability of such party to provide credit event notices with respect to other transactions as a result of its delayed or missed receipt of a Restructuring Credit Event Notice.

For purposes of Section 3.9 of the Credit Derivatives Definitions, a User may submit through the System a Restructuring Credit Event Notice specifying an Exercise Amount that is less than the outstanding Floating Rate Payer Calculation Amount or notional amount with respect to the relevant Restructuring Supplement Transaction (a “Partial Credit Event Notification”). A Restructuring Credit Event Notice that specifies an Exercise Amount that exceeds the outstanding Floating Rate Payer Calculation Amount or notional amount will be deemed to specify such outstanding Floating Rate Payer Calculation Amount or notional amount of the applicable Restructuring Supplement Transaction. The System will track, and make available to the relevant parties, information concerning the extent of any Partial Credit Event Notification of a Restructuring Supplement Transaction by the protection buyer and/or protection seller. In furtherance of the provisions of Section 3.9 of the Credit Derivatives Definitions, and without prejudice to the rights and obligations of the parties to a Restructuring Supplement Transaction thereunder, if an effective Partial Credit Event Notification has been submitted with respect to a Restructuring Supplement Transaction, upon the Exercise Cut-Off Time the Company will, without further action of the parties thereto, reduce the Floating Rate Payer Calculation Amount or notional amount of such Restructuring Supplement Transaction (the “Remaining Reduced Transaction”) to the extent of the relevant Exercise Amount and simultaneously establish a new Restructuring Supplement Transaction with identical terms to those of the original Restructuring Supplement Transaction but with a Floating Rate Payer Calculation Amount or notional amount equal to such Exercise Amount (a “Partial Trigger Resulting Transaction”). A Restructuring Credit Event Notice will be deemed to have been submitted with respect to a Partial Trigger Resulting Transaction without the need for further action by the parties, but no Restructuring Credit Event Notice will be deemed to have been submitted with respect to the Remaining Reduced Transaction (unless a subsequent Restructuring Credit Event Notice is effectively delivered with respect thereto). Where Partial Credit Event Notifications are submitted with respect to a Restructuring Supplement Transaction by both parties thereto, the relevant Exercise Amount will be determined in accordance with the relevant provisions of the Credit Derivatives Definitions as regards priority of notices delivered by protection buyer and protection seller. When a Partial Trigger Resulting Transaction is created, the Company will notify both of the parties thereto through the System in the manner generally applicable for notices by the Company of new Warehouse Transactions.

The Company will also provide a facility pursuant to which a record of the delivery of a Credit Event Notice with respect to a Restructuring Credit Event outside of the System may be submitted to the System in respect of a Restructuring Supplement Transaction (an “Outside Credit

Event Record”). The Company, through Important Notice or through Applicable Publications, will specify the information that Users will be required to provide in order to submit such a record and the manner in which such a record is to be submitted. Submission of an Outside Credit Event Record by one party will not itself constitute a Credit Event Notice under a Restructuring Supplement Transaction or otherwise have any legal effect. However, if an Outside Credit Event Record is accepted by the recipient in the manner specified by the Company by Important Notice or Applicable Publications, the System will treat such message as if it were a Restructuring Credit Event Notice; provided that, notwithstanding any provision of the relevant Master Document(s), the Credit Derivatives Definitions or this Section VIIIA to the contrary, an Outside Credit Event Record, regardless of when submitted, that is accepted by the recipient as provided above after the relevant Exercise Cut-Off Time will be treated as if it had been received and was effective immediately prior to the Exercise Cut-Off Time, and the Users party to the relevant Restructuring Supplement Transaction will be deemed to have agreed that such Outside Credit Event Record may constitute an effective Restructuring Credit Event Notice notwithstanding the actual time of submission or acceptance of such Outside Credit Event Record.

The activation of the Restructuring Credit Event Notice Facility for a Reference Entity shall not be deemed to be a determination or representation by the Company that any alleged Credit Event has or has not occurred with respect to that Reference Entity under any applicable Master Document or the Credit Derivatives Definitions and shall not be deemed to affect the determination by the parties or others under the terms of any Restructuring Supplement Transaction as to whether a Credit Event has or has not occurred or the rights or obligations of the parties with respect thereto, except as expressly set forth herein. The Company will have no responsibility or liability for the accuracy of any information set forth in any notice received from, or public announcement made by, ISDA or a DC related to such Credit Event. Without limiting the foregoing, the Company will have no responsibility for determining whether any relevant Credit Event occurred prior to any Credit Event Backstop Date for a Restructuring Supplement Transaction; provided however that any processing of the Restructuring Credit Event Notice or Outside Credit Event Record, as applicable, will be without prejudice to the rights of the parties in the event that the credit event did occur prior to the Credit Event Backstop Date for such Restructuring Supplement Transaction. For the avoidance of doubt, the Company will conduct Credit Event processing under this Section VIIIA solely on the basis of Restructuring Credit Event Notices (and Outside Credit Event Records) effectively submitted (and, in the case of Outside Credit Event Records, accepted) in accordance with the terms hereof (provided, for the further avoidance of doubt, that the Company will calculate and process settlement payments for a Restructuring Supplement Transaction only if such transaction has a status of “Certain”), but without prejudice to the rights and obligations of the parties to a Restructuring Supplement Transaction in respect of any Credit Event Notice delivered outside of the System.

For the avoidance of doubt, except as expressly provided herein, no provision of this subsection B shall have the effect of amending the legal terms of the relevant Restructuring Supplement Transaction.

C. Maturity Classification and Movement Option

The Company shall classify each Restructuring Supplement Transaction for which a Restructuring Credit Event Notice has been effectively submitted (each, a “Triggered Restructured

Transaction”) into the applicable maturity category for the relevant Restructuring Credit Event (each, a “Maturity Bucket”) based on the Scheduled Termination Date of such Triggered Restructured Transaction, the applicable User that submitted the relevant Restructuring Credit Event Notice and the applicable terms of the Triggered Restructured Transaction (including without limitation under the Credit Derivatives Definitions and Transaction Auction Settlement Terms (including any applicable rounding convention under the Credit Derivatives Definitions)).

If a Movement Option is applicable to a Maturity Bucket for Triggered Restructured Transactions under the Credit Derivatives Definitions, the Company will provide a facility pursuant to which Users party to such transactions may submit a movement option adherence message (a “Movement Option Notice”). A User will not be entitled to submit through the System a Movement Option Notice other than for the outstanding Floating Rate Payer Calculation Amount or notional amount of the Triggered Restructured Transaction (provided that for the avoidance of doubt each Partial Trigger Resulting Transaction will be deemed a separate Triggered Restructured Transaction for this purpose). A Movement Option Notice that is effective as described below may serve as a “Notice to Exercise Movement Option” by such User for purposes of the relevant Triggered Restructured Transaction, but without prejudice to any requirements applicable to Notices to Exercise Movement Option under the Credit Derivatives Definitions other than the requirement that a Notifying Party deliver such notice directly to the other party to the relevant transaction. Each User shall be deemed to agree that , notwithstanding anything to the contrary in any Master Document(s) or the Credit Derivatives Definitions, submission by a User of a Movement Option Notice shall be a permissible and legally effective means of delivering a “Notice to Exercise Movement Option” under the terms of a Triggered Restructured Transaction without prejudice to any other means of delivery of a “Notice to Exercise Movement Option” permitted by the terms of such Restructuring Supplement Transaction. For the avoidance of doubt, where both parties to a Triggered Restructured Transaction submit Movement Option Notices, or Notices to Exercise Movement Options in respect of such Triggered Restructured Transaction, the provisions in the Credit Derivatives Definitions as regards priority of Notices to Exercise Movement Option delivered by protection buyer or protection seller shall apply. The Company shall not be responsible for determining whether a User party to a Restructuring Supplement Transaction is a Notifying Party or is otherwise entitled to deliver a Notice to Exercise Movement Option under the terms thereof, and will conduct Credit Event processing on the basis that a User submitting a Movement Option Notice is so entitled, but without prejudice to the rights and obligations of the parties to such Restructuring Supplement Transaction.

The Company will make the Movement Option Notice available to the counterparty User through the System. The System has been designed to make such notice available to the counterparty User as soon as practicable following the time of submission. The Company, through Important Notice or through Applicable Publications, will specify the information that Users will be required to provide in order to submit a valid Movement Option Notice and the manner in which such messages are to be submitted. The recipient of any such notice need not acknowledge or accept such notice in order for it to be effective for purposes hereof. For the avoidance of doubt, a Movement Option Notice will be irrevocable. A User may submit a Movement Option Notice with respect to a Restructuring Supplement Transaction whether or not such transaction has a status of “Certain” in the Warehouse. However, for the avoidance of doubt, the Company will calculate and process settlement payments for a Restructuring Supplement Transaction only if such transaction has a status of “Certain”.

Movement Option Notices will be deemed effective as of the Processing Time for such notices. The Company will make available at the Processing Time through the System to both the submitting User and its counterparty the Processing Time for any Movement Option Notice. The Company will only apply Movement Option Notices for a particular Credit Event and Triggered Restructured Transaction if the Processing Time is prior to the deadline for such a notice on the Movement Option Cut-Off Date under the Credit Derivatives Definitions (the “Movement Option Cut-Off Time”). Movement Option Notices with a Processing Time after the Movement Option Cut-Off Time will be accepted and recorded by the System, but the Company will not treat such notices as being effectively delivered and will provide no further processing with respect thereto.

Following submission of one or more effective Movement Option Notices by a User with respect to a Triggered Restructured Transaction, the Company will reclassify such Triggered Restructured Transaction into the appropriate Maturity Bucket based on the terms of such Triggered Restructured Transaction. For the avoidance of doubt, the Company will classify and process Triggered Restructured Transactions solely on the basis of Restructuring Credit Event Notices and Movement Option Notices effectively submitted in accordance with the terms hereof, (provided, for the further avoidance of doubt, that the Company will calculate and process settlement payments for a Triggered Restructured Transaction only if such transaction has a status of “Certain”) but without prejudice to the rights and obligations of the parties to a Triggered Restructured Transaction in respect of any Credit Event Notice or Notice to Exercise Movement Option delivered outside of the System.

For the avoidance of doubt, except as expressly provided herein, no provision of this subsection C shall have the effect of amending the legal terms of the relevant Restructuring Supplement Transaction.

D. Adherence and Auction Processing

The Company will establish a Protocol Activation Event for each applicable Maturity Bucket for which ISDA or the DC has published Transaction Auction Settlement Terms. The provisions of Section VIII of this Appendix shall apply to each such Protocol Activation Event, except as provided herein.

Unless otherwise determined by the Company, each User party to a Triggered Restructured Transaction classified in the applicable Maturity Bucket (including through the Movement Option) will automatically be deemed by the Company to have submitted a Protocol Adherence Message with respect to such transaction and Maturity Bucket (and references herein to “submission” of a Protocol Adherence Message shall include any such deemed submission); provided that such User may revoke such Protocol Adherence Message for such transaction at any time prior to the Processing Cut-Off Time, and in the case of such revocation without prejudice, however, to any rights or obligations of the parties as set forth under the terms of the relevant Triggered Restructured Transaction. For Triggered Restructured Transactions for which the conditions set forth in Section VIII above are satisfied, the Company shall conduct settlement processing pursuant to Section VIII separately for each relevant Maturity Bucket.

For the avoidance of doubt, Triggered Restructured Transactions for which there is no Protocol Activation Event for the relevant Maturity Bucket (i.e., for which no auction is to be held)

will not be subject to further processing by the Company, and the Users party thereto are responsible for arranging for the “exit” of the transaction from the Warehouse and settlement of the transaction in accordance with its terms outside of the System.

For the avoidance of doubt, except as expressly provided herein, no provision of this subsection D shall have the effect of amending the legal terms of the relevant Restructuring Supplement Transaction.

E. Certain Matters for Index Transactions

In the case of an “untranched” index credit default swap transaction with respect to which a Restructuring Credit Event occurs for a component Reference Entity, the Users party thereto shall be responsible for submitting and confirming through the System one or more separate component transactions with respect to such component Reference Entity (the “Credit Event Component Transactions”) for purposes of the application of the Restructuring Credit Event triggering provisions and related settlement provisions of this Section VIIIA, and for the avoidance of doubt Credit Event Component Transactions will then be subject to Credit Event processing as set forth in this Section VIIIA. With respect to the remaining index transaction, if (i) the index publisher has published a new version of the relevant index taking into account the occurrence of the relevant Credit Event (the “New Index Version”), (ii) the related Warehouse Record has a status of “Certain” as of the relevant processing date and (iii) the Company is then providing index versioning services for such index, then the Company will automatically amend the “Index Name”, “Annex Date” (or equivalent fields) and any other relevant field in such Warehouse Record to reflect the New Index Version, effective as of the date determined by the Company.

With respect to “tranched” index credit default swaps, the System will permit the delivery of a Restructuring Credit Event Notice and/or Movement Option Notice as described in Section VIIIA(B)-(C) above. As described in subsection B above, a User may submit through the System a Restructuring Credit Event Notice that is a Partial Credit Event Notification. For purposes of any submission of a Restructuring Credit Event Notice for a tranched transaction, the specified (or deemed) Exercise Amount will be applied with respect to the Reference Entity Notional Amount rather than the full notional amount for the tranched transaction; provided that any Partial Trigger Resulting Transaction created as a result of such notice will reflect the corresponding portion of the Reference Entity Notional Amount.

For the avoidance of doubt, except as expressly provided herein, no provision of this subsection E shall have the effect of amending the legal terms of the relevant Restructuring Supplement Transaction.

F. Old R Transactions

With respect to Restructuring Supplement Transactions for which neither (i) Restructuring Maturity Limitation and Fully Transferable Obligation Applicable nor (ii) Modified Restructuring Maturity Limitation and Conditionally Transferable Obligation Applicable is specified (“Old R Transactions”), the System will permit the delivery of a Restructuring Credit Event Notice as described in Section VIIIA(B) above; provided that for the avoidance of doubt, no Partial Credit Event Notification may be submitted for an Old R Transaction. With respect to such transaction

for which a Restructuring Credit Event Notice is effectively submitted, the Company will establish a Protocol Activation Event and perform Credit Event processing as set forth in Section VIII above. For the avoidance of doubt, Movement Option Notices may not be submitted in respect of an Old R Transaction and the maturity classification provisions of Section VIIIA(C) above will not apply to such transactions. The provisions of Section VIIIA(E) will apply to Old R Transactions.

For the avoidance of doubt, except as expressly provided herein, no provision of this subsection F shall have the effect of amending the legal terms of the relevant Restructuring Supplement Transaction.

G. Certain Provisions for Cleared Transactions

The provisions of this Section VIIIA, including VIIIA(A) through (F) above, shall apply to Restructuring Supplement Transactions that have been cleared with a clearing organization, with the modifications set forth herein. In processing Restructuring Credit Events for cleared Restructuring Supplement Transactions, the Company will rely on information provided by the relevant clearing organization that matches each cleared Restructuring Supplement Transaction with one or more offsetting cleared Restructuring Supplement Transactions (including an order of priority of matching, as appropriate) for purposes of Restructuring Credit Events (the “Matching Information”). Upon receipt of a Restructuring Credit Event Notice or Movement Option Notice from a User with respect to a cleared Restructuring Supplement Transaction (each, a “User Cleared Transaction Notice”), the Warehouse, using the Matching Information, will generate and send such Restructuring Credit Event Notice or Movement Option Notice, as the case may be, on behalf of the clearing organization to such clearing organization and the relevant User(s) under the matching cleared Restructuring Supplement Transaction(s) (each, an “Offsetting Cleared Transaction Notice”). Notwithstanding anything to the contrary herein, the Processing Time for both a User Cleared Transaction Notice and the corresponding Offsetting Cleared Transaction Notice shall be the time, as recorded by the Company, as of which the Company has completed those steps necessary in the System to make the User Cleared Transaction Notice available for viewing in the various DTCC access systems (and, for the avoidance of doubt, both the User Cleared Transaction Notice and corresponding Offsetting Cleared Transaction Notice will therefore have the same Processing Time). In the event of a System failure as a result of which the Offsetting Cleared Transaction Notice is not available for viewing in the various DTCC access systems at the Processing Time thereof, the Company will promptly notify the clearing organization and recipient User of such Offsetting Cleared Transaction Notice and its Processing Time. If a User Cleared Transaction Notice is submitted on a cleared Restructuring Supplement Transaction for which the Matching Information provided by the clearing organization is insufficient to enable the Company to match the cleared Restructuring Supplement Transactions, the submission will be rejected. The Company will notify in the manner determined by the Company both the User who submitted the Restructuring Credit Event Notice and the relevant clearing organization in case of such rejection. Outside Credit Event Records will not be accepted for cleared Restructuring Supplement Transactions. The Company will have no responsibility or liability for the Matching Information (or lack thereof) provided by a clearing organization or the consequences to a User of any Offsetting Cleared Transaction Notices generated or not generated as a result thereof, provided that this provision shall not prejudice the rights and obligations of Users and clearing organizations as against each other. Without limiting the foregoing, the Company will have no liability to any person in respect of any failure to generate or provide an

Offsetting Cleared Transaction Notice, except as provided in the “Important Legal Information” section of these Operating Procedures.

For the avoidance of doubt, except as expressly provided herein, no provision of this subsection G shall have the effect of amending the legal terms of the relevant Restructuring Supplement Transaction.

IX. PROCESSING FOR LOAN EARLY TERMINATION EVENTS

The following provisions shall apply to each Warehouse Transaction that is an index credit default swap (tranched or untranched) relating to a series of the LCDX index, iTraxx LevX index or other loan credit default swap index as determined to be eligible from time to time by the Company (a “Loan Index Warehouse Transaction”). On or after the date determined by the Company and subject to the provisions herein and in any Applicable Publications, the Company will make appropriate adjustments to the Warehouse Records for Loan Index Warehouse Transactions that have a status of “Certain” in the Warehouse to reflect the occurrence of a Loan Early Termination Event and calculate any related payments on the basis of such adjustments, in each case in accordance with the terms of the applicable published standard terms supplements for such transactions (the “Standard Terms Supplements”) and these Operating Procedures. In making any such adjustments and calculations, the Company will rely on information published by the Applicable Publisher as to the occurrence of a Loan Early Termination Event. The Company takes no responsibility for information published by the Applicable Publisher and will not make any independent determination or evaluation with respect thereto. Such adjustments will constitute Non-Confirmable Modifications for purposes of this Appendix. Accordingly, each User will be deemed to agree that the Company will make such adjustments and calculations with respect to its Loan Index Warehouse Transactions without any action or confirmation by such User. As used herein, (i) a “Loan Early Termination Event” means with respect to a transaction relating to a series of (a) an LCDX index, a Secured List Early Termination Event, (b) an iTraxx LevX index, the occurrence of the Scheduled Termination Date for a Component Transaction in accordance with the applicable Standard Terms Supplement as a result of a Cancellation, or (c) another loan credit default swap index, the occurrence of a similar event as designated by the Company; and (ii) “Applicable Publisher” means with respect to a transaction relating to a series of (a) an LCDX index, the Secured List Publisher, (b) an iTraxx LevX index, the Index Publisher or (c) another loan index credit default swap, the applicable publisher as determined by the Company. Capitalized terms used in this section IX but not defined in these Operating Procedures shall have the meanings set forth in the applicable Standard Terms Supplement.

X. SUCCESSOR EVENT PROCESSING

On or after the date determined by the Company and subject to the provisions herein and in any Applicable Publications, the Company will provide a facility for Users to submit adherence notices or messages (each, a “Successor Adherence Message”) with respect to Successor Events related to specified categories of Warehouse Transactions that are credit derivative transactions, with the effect set forth herein.

Unless otherwise determined by the Company, the Successor Adherence Message function will not be available with respect to a successor event for a particular reference entity unless the

Company has specifically activated the function for that event. The Company will activate the Successor Adherence Message function for a successor event (a “Succession Activation Event”) (i) in the case of Auction Supplement Transactions, upon receipt by the Company of a statement or notice from ISDA or the relevant Credit Derivatives Determinations Committee (as defined in the Auction Supplement) of the determination that a successor event has occurred; or (ii) in the case of other transactions, (a) upon receipt of a written request to do so by one or more members of the Company’s senior operations working group (or any successor to such group), which request must be in accordance with procedures for that purpose established by the Company, (b) upon receipt of a published statement from a widely recognized industry group or index publisher or service provider for the relevant product indicating that a successor event has occurred or (c) as otherwise determined by the Company. Such request or statement must provide, among other requirements established by the Company, (i) that a successor event has occurred with respect to a reference entity (the “Old Reference Entity”), (ii) the nature of the successor event (i.e., whether the event constitutes the renaming of the reference entity or a reorganization or similar event with respect to the reference entity), (iii) the effective date of such successor event (or, in the case of a future event, the expected effective date), (iv) the name(s) and, where applicable, RED code(s) of the reference entity or entities resulting from such event (the “New Reference Entities”), which may include the Old Reference Entity and, where applicable, the ISIN codes for the reference obligation(s) for each New Reference Entity and (v) the applicable percentage of existing credit default swap transactions to be represented by each New Reference Entity (the “New Reference Entity Percentage”), with the sum of the New Reference Entity Percentages for all New Reference Entities equaling 100% (collectively, the “Successor Event Information”). The Company, through an Important Notice, will inform all Users that a Succession Activation Event has occurred and of the details of the Successor Event Information. Prior to such action, the System will not accept Successor Adherence Messages for a particular successor event. The Company may determine that a Succession Activation Event will apply to only certain categories of Warehouse Transactions (e.g., only single-name credit default swaps as opposed to index credit default swaps). The Company may, by subsequent Important Notice prior to the Processing Cut-Off Time (as defined below), make any necessary corrections or updates to the Successor Event Information.

The occurrence of a Succession Activation Event for a successor event for a reference entity shall not be deemed to be a determination or representation by the Company that any successor event (however named) has or has not occurred with respect to that reference entity under any applicable Master Document or the Credit Derivatives Definitions or as to the consequences thereunder of any such event and shall not be deemed to affect the determination by the parties or others under the terms of any Warehouse Transaction as to whether such an event has or has not occurred or as to the consequences of any such event. The Company will have no responsibility or liability for the accuracy of any information set forth in any notice delivered by members of the Company’s senior operations working group (or any successor to such group) related to such Succession Activation Event (including, without limitation, as to the Successor Event Information) or in any published statement from an industry group, index publisher, service provider or determinations committee. Without limiting the foregoing, the Company will have no responsibility for determining whether any relevant successor event occurred prior to any Successor Event Backstop Date for a Warehouse Transaction.

The Company, through Important Notice or through Applicable Publications, will specify

the information that Users will be required to provide in order to submit a valid Successor Adherence Message and the manner in which such messages are to be submitted (including whether such messages may be in electronic or other written form). Users may submit a global Successor Adherence Messages with respect to all Warehouse Transactions of the relevant type related to the applicable reference entity and/or may submit Successor Adherence Messages with respect to individual Warehouse Transactions. In the case of a global Successor Adherence Message, the Company will deem the Successor Adherence Message to apply to each Warehouse Transaction of the relevant type related to the applicable reference entity as determined in accordance with the specified RED code (or similar code) for that entity. A User that has submitted a global Successor Adherence Message may revoke such global message such that it will not apply to any relevant Warehouse Transactions added to the Warehouse after such revocation. In addition, a User that has submitted a Successor Adherence Message with respect to a particular Warehouse Transaction (either by a global message or individually) may revoke such message with respect to that Warehouse Transaction at any time prior to the Processing Cut-Off Time. Notwithstanding anything to the contrary herein, unless otherwise determined by the Company, in the case of a Succession Activation Event occurring on or following June 20, 2009, each User party to an Auction Supplement Transaction related to the applicable reference entity will automatically be deemed by the Company to have submitted a Successor Adherence Message with respect to such transaction (and references herein to “submission” of a Successor Adherence Message shall include any such deemed submission); provided that such User may revoke such Successor Adherence Message for such transaction at any time prior to the Processing Cut-Off Time.

Submission of a valid Successor Adherence Message by both Users party to a Warehouse Transaction, where such message has not been revoked by either User for such Warehouse Transaction as of a certain cut-off date and time established by the Company for the relevant Succession Activation Event (the “Processing Cut-Off Time”), will serve as an instruction by such Users to the Company simultaneously to (i) “exit” such Warehouse Transaction (the “Old Warehouse Transaction”) from the Warehouse and (ii) create in the Warehouse a number of new Warehouse Transactions (“New Warehouse Transactions”) equal to the number of New Reference Entities, as follows. Each of the New Reference Entities shall be the reference entity under one of the New Warehouse Transactions, and each New Warehouse Transaction shall have a notional amount equal to the notional amount of the Old Warehouse Transaction multiplied by the New Reference Entity Percentage for the relevant New Reference Entity. In all other respects, each New Warehouse Transaction shall have terms identical to the Old Warehouse Transaction (with (i) appropriate adjustments to the first calculation period and first payment date to maintain consistency with the calculation periods under the Old Warehouse Transaction and (ii) the changes to the ISIN code for the reference obligation set forth in the Successor Event Information). The Company shall perform such actions (collectively, the “Successor Event Processing”) at the time specified by the Company following the Processing Cut-off Time. Notwithstanding the foregoing, the Company will only perform Successor Event Processing for a Warehouse Transaction if the Warehouse Transaction has a status of “Certain” in the Warehouse as of the Processing Cut-Off Time and has a positive notional amount. The Company will perform the Successor Event Processing solely on the basis of the Successor Event Information, notwithstanding anything to the contrary in any applicable Master Document or other documentation for a Warehouse Transaction.

Failure by Users to instruct that Successor Event Processing apply to a Warehouse

Transaction or of the other conditions above to be satisfied shall not be deemed to affect the Users’ legal obligations with respect to that transaction or to indicate that a successor event (however defined) thereunder has or has not occurred. Rather, the result of such failure will be that the Company will not conduct Successor Event Processing for that Warehouse Transaction. The Company is not responsible for the consequences of any such failure, and the Users party to such Warehouse Transaction are responsible for “exiting” the Warehouse Transaction following any such successor event and/or making any necessary amendments to reflect such event. In addition, failure to instruct that Successor Event Processing apply shall not affect the validity of any determination by a calculation agent, determinations committee, party to such transaction or other relevant person with respect to any such event.

XI. TRADING VOLUME DATA GUIDELINES

Each User hereby agrees and consents to the Company’s performing the responsibilities and functions assigned to it under the Credit Derivatives Determinations Committees Rules set out in Annex A to the Auction Supplement (the “DC Rules”) and the Trading Volume Data Guidelines as published from time to time by ISDA (the “Guidelines”). Without limiting the foregoing, each User identified on a list of eligible institutions provided by ISDA to the Company pursuant to the DC Rules and the Guidelines agrees and consents to the Company’s determining the Global Notional Amount or Regional Notional Amount for that User and/or its affiliates and notifying ISDA of its identity, if applicable, based on its position in the Global Dealer Trading Volume List or Regional Dealer Trading Volume List and the number of institutions specified by ISDA to be selected.

In addition, with respect to Restructuring Supplement Transactions in respect of which a restructuring credit event has occurred, each User hereby agrees and consents to the Company’s providing certain additional information to ISDA or the applicable DC, including (i) an initial indication of the potential notional volume of Warehouse Transactions in each applicable Maturity Bucket that could be triggered as a result of such event and (ii) on a daily basis up to the applicable exercise deadline, the notional volume for each Maturity Bucket of Restructuring Supplement Transactions for which a Restructuring Credit Event Notice or Outside Credit Event Notice was submitted to the System on such date and the number of dealers whose trades are included in such daily notional volume.

XII. SUBMISSION OF “COPPER” TRANSACTION RECORDS

The Company will provide a facility in the Warehouse pursuant to which Users may submit records (“Copper Records”) from time to time with respect to one or more categories or types of transactions as may be specified by the Company. The Company shall specify by Important Notice or Applicable Publications the information required or permitted to be included in Copper Records for transactions of a particular type and the manner in which Copper Records may be submitted. Copper Records will be maintained by the Company in the Warehouse, but Copper Records will not constitute Warehouse Records (that is, “gold” records), and transactions described therein will not constitute Warehouse Transactions, for any purposes under this Appendix or the Operating Procedures; provided that if a Copper Record is submitted with respect to a transaction for which there is a Warehouse Record, such Copper Record shall have no effect on such Warehouse Record or the related Warehouse Transaction. Without limiting the foregoing

sentence, Copper Records are not intended to constitute confirmations or other legal documentation and accordingly will not affect the legal status (if any) in any respect of a transaction described (or purported to be described) therein. The Company will not perform matching, post-trade processing or any calculations or determinations with respect to Copper Records. In addition, the Company will not provide any notification to a party identified as the counterparty in a submitted Copper Record.

The Company will permit submission of Copper Records only in batches. Each time a User submits a batch of Copper Records, all prior Copper Records of that User will be deleted and replaced with the new batch. A User should not submit a Copper Record with respect to a transaction for which a Warehouse Record exists; provided that if such a Copper Record is submitted it will have no effect on such Warehouse Record.

The Company will prepare on a periodic basis consolidated reports with respect to all current Copper Records submitted to the Company (“Copper Record Reports”). Copper Record Reports may be prepared on an aggregate basis for all Users and/or on a submitting User basis and may have subcategories for product type, counterparty and other relevant categories.

Without limiting any other provisions of the Operating Procedures (including, without limitation, the Representation and Warranties Important Legal Information section):

(i) To the extent that a User is located within the United States, or is otherwise subject to the jurisdiction of the United States, User certifies the following in connection with Copper Records submitted by it:

User is a U.S. person as defined by applicable regulations administered and enforced by OFAC. User agrees that it is thereby subject to, and has implemented a program reasonably designed to comply with, such regulations. As part of its OFAC compliance program, User also certifies that it has screened and will continue to periodically screen against the most recent version of OFAC’s List of Blocked Persons, Specially Designated Nationals, Specially Designated Terrorists, Specially Designated Global Terrorists, Foreign Terrorist Organizations and Specially Designated Narcotics Traffickers (collectively referred to as the “SDN List”) the name and address of any counterparty to a transaction for which it submits a Copper Record;

(ii) To the extent that a User is not located in the United States, or is not otherwise subject to the jurisdiction of the United States, User certifies that it will not submit any Copper Record for a transaction that User knows, either due to its screening or through other means, to be in violation of the regulations administered and enforced by OFAC.

XIII. NOVATION CONSENT AND CONFIRMATION PROCEDURES

Notwithstanding anything to the contrary herein, the Company will accept as set forth in this Section XIII Confirmable Modifications that are novations of confirmed Warehouse Transactions that were originated by one or more novation consent services or platforms as may be authorized by the Company from time to time by Important Notice or Applicable Publications (“Novation Consent Platforms”).

The Company will, upon request of a Novation Consent Platform in a form acceptable to the Company, provide the Novation Consent Platform access to the information contained in the Warehouse Record (including its current status) for a Warehouse Transaction. A Novation Consent Platform may submit to the Company a request, in a form acceptable to the Company, that the Company reserve all or a portion of the outstanding unreserved notional amount of a Warehouse Transaction (a “Notional Amount Reservation”) pending submission of a Novation Confirmation (as defined below) with respect to such transaction.

The Company will reject a Notional Amount Reservation if there is insufficient notional available, if the Warehouse Record has a status of Uncertain because the transaction is not confirmed or is the subject of an unconfirmed amendment or exit, or for such other reason as may be specified in an Important Notice or Applicable Publications. Following receipt by the Company of a Notional Amount Reservation with respect to a specified notional amount of a Warehouse Transaction where such reservation is not rejected, (i) the Company will confirm such Notional Amount Reservation to the submitting Novation Consent Platform with a unique identifier for such reservation, (ii) while such Notional Amount Reservation is in effect the Company will not accept a further Notional Amount Reservation with respect to such specified notional amount or a Novation Confirmation with respect to such specified notional amount that does not contain the Notional Amount Reservation identifier; and (iii) while such Notional Amount Reservation is in effect, the relevant Warehouse Record will have a status of Uncertain in the Warehouse. The Company will notify the Novation Consent Platform of any rejection of a Notional Amount Reservation, in a manner to be specified by the Company.

A submitting Novation Consent Platform may cancel a Notional Amount Reservation in the manner designated by the Company. A Notional Amount Reservation will automatically expire, if not previously cancelled or followed by a Novation Confirmation submission using its identifier, as of the applicable cutoff time adopted by the Company. In submitting or canceling a Notional Amount Reservation, a Novation Consent Platform will be deemed to be acting on behalf of the User that is the transferor of the relevant novation consent request for purposes of the Operating Procedures.

Notwithstanding anything to the contrary herein, upon the confirmation by the MarkitSERV Confirmation Service of an agreed novation of a confirmed Warehouse Transaction that was affirmed and/or consented to by all relevant parties through a Novation Consent Platform (a “Novation Confirmation”) and acceptance of such Novation Confirmation by the Warehouse as described herein, the Company shall treat such novation for all purposes as having been confirmed by all parties to such novation, update the applicable Warehouse Records to reflect such novation, without the need for further confirmation or action by any party to such novation and release the related Notional Amount Reservation.

Each User that uses a Novation Consent Platform for purposes of the novation of a Warehouse Transaction will notify the Company, in the manner to be specified by the Company, of the identity of each Novation Consent Platform it uses. Each User hereby authorizes the Company to accept a Notional Amount Reservation with respect to its Warehouse Transactions from each Novation Consent Platform so identified, until the Company is notified to the contrary by such User in a manner to be specified by the Company.