ClearLink C1.3 revision 4 Product Specification Specification - Product_v1.… · manufacturing...

ClearLink C1.3 revision 4

Product Specification

Service: CDSClear

Document Type: Product Specification

Document Number: CLC-OPM16-ISP-001

Version Number: C1.3 revision 4

Issue Date: January 2013

COPYRIGHT

The copyright in this work is vested in LCH.Clearnet Ltd and is issued in confidence for the purpose for which it is supplied. It must not be reproduced in whole or in part or used for tendering or

manufacturing purposes except under an agreement or with the consent in writing of LCH.Clearnet Ltd and then only on the condition that this notice is included in any such reproduction. No

information as to the contents or the subject matter of this document or any part thereof arising directly or indirectly there from shall be given orally or in writing or communicated in any manner

whatsoever to any third party being an individual firm or employee thereof without the prior consent in writing of LCH.Clearnet Ltd.

© 2013 LCH.Clearnet Limited, 33 Aldgate High Street, London, EC3N 1EA

TRADEMARKS

All trademarks are duly acknowledged.

FpML is a registered trademark of FpML Org

WebSphere is a registered trademark of IBM Corporation

CDSClear is a trademark of LCH.Clearnet Group

ClearLink is a trademark of LCH.Clearnet Limited

Table of Contents Table of Contents __________________________________________________________ i Figures _________________________________________________________________ iii Tables __________________________________________________________________ iv 1. Introduction ________________________________________________________ 5

1.1 Purpose of this document ------------------------------------------------------------------------ 5 1.2 Intended audience --------------------------------------------------------------------------------- 5 1.3 Scope -------------------------------------------------------------------------------------------------- 5 1.4 What is ClearLink? --------------------------------------------------------------------------------- 5 1.5 Out of Scope ----------------------------------------------------------------------------------------- 6 1.6 Change Tracking ----------------------------------------------------------------------------------- 6 1.7 Language --------------------------------------------------------------------------------------------- 6 1.8 XML Colour coding --------------------------------------------------------------------------------- 6 1.9 XML Schema Descriptions ----------------------------------------------------------------------- 7

2. ClearLink Specifications _____________________________________________ 8 2.1 Coding Schemes ----------------------------------------------------------------------------------- 9

3. Trade and Party Specification ________________________________________ 10 3.1 trade structure ----------------------------------------------------------------------------------- 11

3.1.1 USI and TradeId ............................................................................................ 12 3.1.2 This form is used as an additional reference to the tradetradeHeader element 12 3.1.3 tradeHeader element ................................................................................. 14 3.1.4 partyTradeIdentifier element ............................................................. 15 3.1.5 partyTradeInformation element ........................................................... 16 3.1.6 Product Structure .......................................................................................... 18 3.1.7 Calculation Agent .......................................................................................... 18 3.1.8 documentation structure ........................................................................... 19

3.2 party Structure ---------------------------------------------------------------------------------- 21

4. CDS Product Specification __________________________________________ 22 • Main, HiVol, CrossOver indices -------------------------------------------------------------------- 22 • Single names ------------------------------------------------------------------------------------------- 22 4.1 CDSClear ------------------------------------------------------------------------------------------- 22 • Contact CDS Clear for details ---------------------------------------------------------------------- 22 • Has an underlying iTraxx product ----------------------------------------------------------------- 22 4.2 creditDefaultSwap Product Structure ------------------------------------------------- 23

4.2.1 generalTerms Structure ............................................................................. 24 4.2.2 feeLeg Structure .......................................................................................... 29 4.2.3 protectionTerms Structure ...................................................................... 33

Appendix A. FpML Schemas _____________________________________________ 34 Appendix B. References _________________________________________________ 35 B.1 Related documents ________________________________________________ 35

LCH.Clearnet Only i

Appendix C. Code Lists _________________________________________________ 36 C.1 partyRoleScheme __________________________________________________ 36 Appendix D. List of Abbreviations ________________________________________ 37

LCH.Clearnet Only ii

Figures Figure 1 – ClearLink Overview --------------------------------------------------------------------------------- 5 Figure 2 - XML Schema Definition ---------------------------------------------------------------------------- 7 Figure 4 USI Trade identifier --------------------------------------------------------------------------------- 12 Figure 5 - tradeHeader structure ---------------------------------------------------------------------------- 12 Figure 6 - tradeHeader Structure ------------------------------------------------------------------------- 14 Figure 7 - partyTradeIdentifier Element ---------------------------------------------------------- 15 Figure 8 - partyTradeInformation Element -------------------------------------------------------- 16 Figure 9 - Example of the documentation element for a single named product ------------- 20 Figure 10 - creditDefaultSwap product structure -------------------------------------------------- 23 Figure 11 - generalTerms structure ---------------------------------------------------------------------- 24 Figure 12 - referenceInformation Element Structure --------------------------------------------------- 25 Figure 13 - indexReferenceInformation Element Structure ------------------------------------------- 26 Figure 14 - feeLeg structure ---------------------------------------------------------------------------------- 29 Figure 15 - initialPayment structure ------------------------------------------------------------------ 30 Figure 16 - periodicPayment structure ---------------------------------------------------------------- 32

LCH.Clearnet Only iii

LCH.Clearnet Only iv

Tables

Table 1 – ClearLink C1.3 Product Specification Scope ------------------------------------------------- 6 Table 2 - Change Tracking -------------------------------------------------------------------------------------- 6 Table 3 - XSD Diagram Symbols ------------------------------------------------------------------------------ 7 Table 4 - ClearLink coding schemes ------------------------------------------------------------------------- 9 Table 5 - Trade Identification elements of partyTradeIdentifier ---------------------------- 12 Table 6 - tradeHeader elements -------------------------------------------------------------------------- 13 Table 7 - tradeHeader elements ------------------------------------------------------------------------- 17 Table 8 - trade elements ------------------------------------------------------------------------------------ 18 Table 9 – documentation elements -------------------------------------------------------------------- 20 Table 11 – party elements ---------------------------------------------------------------------------------- 21 Table 12 - swap product types ------------------------------------------------------------------------------- 22 Table 13 - initialPayment structure -------------------------------------------------------------------------- 31

1. Introduction 1.1 Purpose of this document

The purpose of this document is to fully describe the products supported by ClearLink, the messaging interface used by LCH Clearnet’s CDS Clear services.

1.2 Intended audience • Participants interacting with LCH.Clearnet’s CDS Clear Service via

ClearLink. • LCH Clearnet In-house staff wishing to understand the interface between

the CDS Clear Services and its Participants.

1.3 Scope This document covers the specification of Credit Default Swap (CDS) products supported by LCH Clearnet’s CDS Clear Services via ClearLink.

1.4 What is ClearLink? ClearLink provides an interface mechanism for market participants to interact with LCH Clearnet’s CDS Clear Services. It consists of following:

• A messaging standard that describes the format and the content of messages that are supported by the ClearLink.

• A specification of the messaging interactions supported by the ClearLink.

• A specification of products supported by ClearLink.

The figure below provides a high level view of ClearLink.

Figure 1 – ClearLink Overview

The messaging specifications and message interactions are described in the ClearLink V1.3 messaging specification.

The products supported by ClearLink are listed below.

Version C1.3 revision 4 LCH.Clearnet Only 5

OTC Service Supported Products

CDSClear Main, HiVol, CrossOver index CDSs Single name CDSs

Table 1 – ClearLink C1.3 Product Specification Scope

ClearLink is based on FpML (Financial products Markup Language), which is an industry-standard protocol for complex financial products. FpML is based on XML (eXtensible Markup Language), a standard meta-language for describing data shared between applications.

The ClearLink specification defines additional rules and restrictions that must be followed when creating the FpML messages. Not all FpML elements are supported; failure to adhere to the rules specified in this interface may lead to messages being rejected.

1.5 Out of Scope This specification does not cover:

• Message specification (see document reference 7).

• Connectivity details (see document reference 8).

1.6 Change Tracking Change Date & Version Source

• Initial draft V 1.1 draft 0.1

Feb 2012

• CDS Updates to finalise Requirements V1.2 Draft

30 April 2012

• Final Updates for Initial publication V1.3

1st June 2012

• Updates following FpML 5.3 publication and for minor clarifications and corrections

C1.3 revision 1

20th August 2012

• Updates following reviews by internal project teams

C1.3 revision 2

24th September 2012

• Updates following further reviews by internal project teams

C1.3 revision 4

08th October 2012

Table 2 - Change Tracking

1.7 Language The key words "must", "must not", "required", "shall", "shall not", "should", "should not", "recommended", "may", and "optional" in this document are to be interpreted as described in IETF RFC 2119 (document reference 4).

Words in courier font such as this denote code or XML structural component names.

1.8 XML Colour coding XML formatted text used throughout this document is colour coded to aid understanding of the fields.


Comments - Green 

XML Instructions - Purple <?xml version="1.0" encoding="UTF-8

Element Names - Blue <sentBy>

Attributes - Orange xmlns=

Universal Resource Indicator (URI) - Red http://www.fpml.org/2008/FpML-4-5

Content value - Black <tradeStatusValue>Registered</tradeStatusValue>

1.9 XML Schema Descriptions XML Schema elements are depicted as shown below:

Figure 2 - XML Schema Definition

Symbol Description

Sequence of elements

Choice between elements

The elements crossed out by a red line are not supported by ClearLink and must not be present in the message.

Required elements are connected using a bold line

Optional elements are connected using a thin line

Specifies the minimum and maximum occurrence of an element. If unspecified, the minimum and maximum occurrence is 1 for required elements. For optional elements, minimum occurrence is 0 and maximum occurrence is 1. Note that the occurrence specified is the base FpML standard, however, ClearLink may place further restrictions as noted in the document below..

Table 3 - XSD Diagram Symbols

2. ClearLink Specifications Each ClearLink supported product is must conform to the FpML 5.3 specification (document reference 2) as well as the ClearLink Product Specification constraints and extensions laid out in this document.

Document Specifications This section describes the standards relevant to all XML documents used in the ClearLink Product specification.

Root element Each document shall have a root element specific to the type of message structure used. The root element identifies the type of document and the content allowed for that document type. For example:

<?xml version="1.0" encoding="UTF-8"?> <requestClearing>

FpML Version

The version of FpML used must be 5.3 to conform to C1.3 of the ClearLink specification. This is declared as a version attribute on the root element as follows:

fpmlVersion="5-3"

Namespace declarations The namespaces should be specified at the root element level. Schema location is an optional environment specific indicator of where the physical schema files can be found.

The namespace requirements are identified in Appendix A.

Document Representation All documents in the specification are to be represented on the message transport as text messages. Character Encoding All XML documents intended for interchange with ClearLink must be encoded using UTF-8. Consumers of FpML documents must be able to process documents encoded using UTF-8.

Timestamps

Date and times must be represented as Coordinated Universal Time (UTC) as specified in the W3C standard (document reference 6). The usage of time zone adjustment values is supported for any quantity coded using the XML Schema DateTime format. These adjustments will be applied by the Gateway. I.e. A time zone adjusted value being received by the gateway will be adjusted to a UTC time by applying the adjustment.


2.1 Coding Schemes The table below describes the coding scheme extensions used or defined for the ClearLink specification that are commonly referenced throughout the message types in this document.

Note that some of these are FpML coding schemes which are provided by default within the FpML specification but overridden by the ClearLink specification. All such custom code schemes use the ClearLink namespace convention of http://www.lchclearnet.com/clearlink/coding-scheme; followed by the name of the field, such as ‘message-id’.

Where the code scheme used in the CDS Clear specification is the same as the FpML default code scheme the inclusion of the code scheme in the message is optional.. The omission of a code scheme attribute in a message will result in the default code scheme being applied for that element.

Coding Scheme Description Rules for data

accountIdScheme Client fund account Alpha numeric up to 30 characters. Client

account value agreed with LCH.Clearnet.

http://www.lchclearnet.com/clearlink/coding-scheme/account-id

partyIdScheme Valid party identifiers as defined by LCH Clearnet’s CDS Clear Service.

The party identifiers must be agreed between the various participants.

http://www.lchclearnet.com/clearlink/coding-scheme/party-id

tradeIdScheme

Trade Identifier assigned to the trade by a party

Each party must assign its own identifiers to the trade.

There are no defined domain values for the trade identifier

USI transaction identifiers shall be identified by the coding scheme: http://www.fpml.org/coding-scheme/external/unique-transaction-identifier

Non USI trade identifiers shall use the following URI: http://www.lchclearnet.com/clearlink/coding-scheme/trade-id

Netting IDs shall use the following URI: http://www.lchclearnet.com/clearlink/coding-scheme/netting-id

A maximum of one Netting ID may be present for each trade side.

businessCenterScheme

Financial Centres Permissible values:

GBLO

http://www.fpml.org/coding-scheme/business-center

currencyScheme

Currency codes. Currency code as defined by the ISO standard 4217.

3 character ISO 4217 code.

http://www.fpml.org/ext/iso4217

partyRoleScheme must use the URI :

http://www.lchclearnet.com/clearlink/coding-scheme/party-role

Table 4 - ClearLink coding schemes


http://www.fpml.org/coding-scheme/external/unique-transaction-identifier



http://www.fpml.org/ext/iso4217

3. Trade and Party Specification A trade is an agreement between two parties to enter into a financial contract and the trade component in FpML contains the information necessary to execute and confirm that trade.

The trade details are contained in an enclosing message type, such as requestClearing (see document reference 7) which is part of an overall exchange of messages to form a process.

This document describes the product specific trade description.

After the base message header elements the following FpML structures appear in order:

• trade

• party


3.1 trade structure ClearLink expects the trade element to consist of one tradeHeader structure, one product structure and one documentation structure. The product is abstract and requires a specific concrete product type implementation. These specific product types vary in structure and are each dealt with separately in section 4 of this specification.

Figure 3 - trade structure


3.1.1 USI and TradeId Since FpML 5.3 LCWD the usage of USI is supported in FpML 5.3. This specification takes the form of an issuer namespace code and a regular trade identifier. This form is only supported in the tradeHeader.

Figure 4 USI Trade identifier

3.1.2 This form is used as an additional reference to the tradetradeHeader element

Figure 5 - tradeHeader structure

The tradeHeader component may contain one or more partyTradeIdentifier and partyTradeInformation elements. The following table outlines the elements used in the tradeHeader structure.

Element Description trade/tradeHeader/partyTradeIdentifier

trade/tradeHeader/partyTradeInformation

trade/tradeHeader

tradeDate The date that the trade was made.

Table 5 - Trade Identification elements of partyTradeIdentifier

partyTradeIdentifier element may be present for each of the parties in the message. At least two occurrences of the partyTradeIdentifier element, one for each counterparty, are required.


The following table outlines the elements used in the partyTradeIdentifier structure.


partyReference[@href] Href to the party definition in the XML message – this element shall not be present if issuer is present.

issuer The USI namespace. For CFTC regulated trades, this shall be the 10 character alpha-numeric identifier allocated by CFTC to the USI originator. For trades regulated by CFTC, the coding scheme shall be set to the following value: http://www.fpml.org/coding-scheme/external/issuer-identifier/cftc

tradeId USI transaction identifiers shall be identified by the coding scheme: http://www.fpml.org/coding-scheme/external/unique-transaction-identifier

Non USI trade identifiers shall use the following URI: http://www.lchclearnet.com/clearlink/coding-scheme/trade-id

Netting IDs shall use the following URI: http://www.lchclearnet.com/clearlink/coding-scheme/netting-id

A maximum of one Netting ID may be present for each trade side.

Table 6 - tradeHeader elements

3.1.2.1 Trade Identifiers

In FpML, there is no notion of primary trade or contract identifier. Trade identification is meaningful within the context of a party. That’s why the partyTradeIdentifier structure contains a partyReference element referencing a party. ClearLink supports one trade identifier per party per tradeIdScheme.

Trade identifiers should always use a tradeIdScheme:which will vary based on the nature of the ID being specified. ( See table above )


http://www.fpml.org/coding-scheme/external/issuer-identifier/cftc






3.1.3 tradeHeader element

Figure 6 - tradeHeader Structure

A partyTradeIdentifier element may be present for each of the parties in the message (section 1). At least two occurrences of the partyTradeIdentifier element, one for each counterparty, are required. A partyTradeInformation element must also be present, one for each counterparty in the message, (see party structure in section 1).

If the trade has client counterparties then additional partyTradeIdentifier and partyTradeInformation elements are required to specify the clearing broker and potential executor relationships with the client.

Following the partyTradeIdentifier and partyTradeInformation elements, a tradeDate element must be present.


3.1.4 partyTradeIdentifier element

Figure 7 - partyTradeIdentifier Element


3.1.5 partyTradeInformation element

Figure 8 - partyTradeInformation Element


The following table outlines the elements used in the tradeHeader structure.


partyReference[@href] Href to the party definition in the XML message

tradeId At least one occurrence of the party reference to the original trade identifier is required.

A maximum of one tradeId per tradeIdScheme is permitted per party. Additional restrictions apply as described below.

Trade identifiers shall use the following URI: http://www.lchclearnet.com/clearlink/coding-scheme/trade-id

trade/tradeHeader/partyTradeInformation


trade/tradeHeader/partyTradeInformation/relatedParty


role The role of the related party to the party referred to in the partyTradeInformation element.

Coding Scheme: http://www.lchclearnet.com/clearlink/coding-scheme/party-role

trade/tradeHeader

tradeDate The date that the trade was made.

Table 7 - tradeHeader elements

At least the two Clearing Brokers and the Trade Source must be identified with a relatedParty/role to explicitly indicate their role in the trade across suitable partyTradeInformation elements. .

3.1.5.1 Trade Identifiers

In FpML, there is no notion of primary trade or contract identifier. Trade identification is meaningful within the context of a party. That’s why the partyTradeIdentifier structure contains a partyReference element referencing a party. ClearLink supports one trade identifier per party.

Trade identifiers should always use the following tradeIdScheme: http://www.lchclearnet.com/clearlink/coding-scheme/trade-id

For a client counterparty the accountReference is required, as in the example below:

<partyTradeIdentifier> <partyReference href="counterpartyB"/> <tradeId tradeIdScheme="http://www.lchclearnet.com/clearlink/coding-scheme/trade-id"> TID123</tradeId> </partyTradeIdentifier>


3.1.5.2 Party Relationships

The partyTradeInformation element specifies the relationship between the counterparty and the clearing broker as in the example shown below:

<partyTradeInformation> <partyReference href="counterpartyB"/> <relatedParty> <partyReference href="clearingBrokerB"/> <role partyRoleScheme="http://www.lchclearnet.com/clearlink/coding-scheme/party-role"> ClearingBroker</role> </relatedParty> </partyTradeInformation>

3.1.6 Product Structure The product structure describes the credit default swap product characteristics and is described in detail in section 4.

3.1.7 Calculation Agent This identifier defines the ISDA calculation agent responsible for performing duties as defined in the applicable product definitions. The elements are as follows:

Element Description trade

calculationAgent/calculationAgentPartyReference [@href]

Href to the party definition in the XML message

calculationAgentBusinessCenter

The city in which the office through which ISDA Calculation Agent is acting for purposes of the transaction.

Coding Scheme: http://www.fpml.org/coding-scheme/business-center

The permissible values are: GBLO

Table 8 - trade elements


3.1.8 documentation structure A single documentation structure must follow the product in the trade structure.

The following table outlines the elements used in the documentation structure that must be present in the message.

Element Description documentation/masterAgreement

masterAgreementType The agreement executed between the parties and intended to govern product-specific derivatives transactions between those parties. Coding Scheme: http://www.fpml.org/coding-scheme/master-agreement-type

The permissible values are: ISDA

masterAgreementDate The date on which the master agreement was signed. Documentation/contractualMatrix

matrixType

Identifies the form of applicable matrix. Coding Scheme: http://www.fpml.org/coding-scheme/matrix-type

The permissible values are: CreditDerivativesPhysicalSettlementMatrix



Element Description matrixTerm

Defines any applicable key into the relevant matrix Coding Scheme: http://www.fpml.org/coding-scheme/credit-matrix-transaction-type

The permissible values are: EuropeanCorporate

Documentation/contractualTermsSupplement type Identifies the form of applicable contractual supplement.

Coding Scheme: http://www.fpml.org/coding-scheme/contractual-supplement

The permissible values are: iTraxxEurope

publicationDate Specifies the publication date of the applicable version of the contractual supplement.

Table 9 – documentation elements

3.1.8.1 Business Rules

1. For Indices products a contractualTermsSupplement structure must be present.

2. For single named products a contractualMatrix structure must be present

3.1.8.2 Examples:

<documentation> <masterAgreement> <masterAgreementType masterAgreementTypeScheme="http://dtcc.com/coding-scheme/master-agreement-type">ISDA</masterAgreementType> <masterAgreementDate>2003-10-01</masterAgreementDate> </masterAgreement> <contractualMatrix> <matrixType matrixTypeScheme="http://www.fpml.org/coding-scheme/matrix-type">CreditDerivativesPhysicalSettlementMatrix</matrixType> <matrixTerm matrixTermScheme="http://www.fpml.org/coding-scheme/credit-matrix-transaction-type">EuropeanCorporate</matrixTerm> </contractualMatrix> </documentation>

Figure 9 - Example of the documentation element for a single named product

<documentation> <masterAgreement> <masterAgreementType masterAgreementTypeScheme="http://dtcc.com/coding-scheme/master-agreement-type">ISDA</masterAgreementType> <masterAgreementDate>2003-10-01</masterAgreementDate> </masterAgreement> <contractualTermsSupplement> <type contractualSupplementScheme="http://www.fpml.org/coding-scheme/contractual-supplement">iTraxxEurope</type> <publicationDate>2010-09-19</publicationDate> </contractualTermsSupplement> </documentation>

http://dtcc.com/coding-scheme/master-agreement-type

http://www.fpml.org/coding-scheme/matrix-type

http://www.fpml.org/coding-scheme/matrix-type

http://www.fpml.org/coding-scheme/credit-matrix-transaction-type

http://dtcc.com/coding-scheme/master-agreement-type

http://www.fpml.org/coding-scheme/contractual-supplement

3.2 party Structure A product in FpML must reference parties defined elsewhere within the enclosing FpML document using the party element.

The following table identifies all the party roles in a trade that are supported by ClearLink:

id Description counterpartyA The first counterparty.

counterpartyB The second counterparty.

clearingBrokerA The Clearing Broker for counterparty A.

clearingBrokerB The Clearing Broker for counterparty B.

tradeSource The Trade Source.

clearer The Clearing House

executor The execution facility (SEF) if different from the trade source.

Table 10 - accepted party structures

The following table outlines the elements used in the party structure.

Element Description party[@id] will point to individual party elements corresponding to the roles of :

counterpartyA, counterpartyB, clearingBrokerA, clearingBrokerB, tradeSource, clearer, executor

partyId The LCH.Clearnet CDS Clear accepted party identifier.

Coding scheme: http://www.lchclearnet.com/clearlink/coding-scheme/party-id

partyName This is an optional descriptive name for the legal entity

Table 11 – party elements

Additional information on how the parties are mapped inside the trade element is provided in section 3.1.2.

Usage Notes:

The values of the party[@id] attribute shown above are for illustration purposes only. In general, the role of a party in the transaction context must be determined by examining the partyTradeInformation structure and the trade structure, as described in section 3.1.2. ClearLink also assumes that participants have access to reference data that enables them to identify the absolute role of each party.


4. CDS Product Specification This section specifies the representation of interest rate swaps using FpML. The supported CDS types are listed below.

Swap Product Types OTC Service

Remarks

• Main, HiVol, CrossOver indices

• Single names

CDSClear • Contact CDS Clear for details

• Has an underlying iTraxx product

Table 12 - swap product types


4.2 creditDefaultSwap Product Structure The FpML creditDefaultSwap Product type is used to represent the product types supported by CDSClear.

The main elements of a creditDefaultSwap Product structure are shown below.

Figure 10 - creditDefaultSwap product structure

There are three main parts to the creditDefaultSwap product type:

• generalTerms • feeLeg • protectedTerms

Each element is dealt with separately below.


4.2.1 generalTerms Structure The generalTerms element is mandatory and is the first element in the creditDefaultSwap product structure. This element contains all the data that appears in the section entitled "1. General Terms" in the 2003 ISDA Credit Derivatives Confirmation.

The structure of the generalTerms type is shown below:

Figure 11 - generalTerms structure


4.2.1.1 referenceInformation element

Figure 12 - referenceInformation Element Structure


4.2.1.2 indexReferenceInformation element

Figure 13 - indexReferenceInformation Element Structure


Element Description creditDefaultSwap/generalTerms

effectiveDate The first day of the term of the trade.

scheduledTerminationDate The scheduled date on which the credit protection will lapse.

buyerPartyReference[@href] A reference to the counterparty that is buying the contract. See section 1.

sellerPartyReference[@href] A reference to the counterparty that is selling the contract. See section 1.

If the CDS is a single name product:

creditDefaultSwap/generalTerms/referenceInformation

referenceEntity/entityName Optional - The name of the entity.attribute : entityNameScheme must be: http://www.fpml.org/spec/2003/entity-name-RED

referenceEntity/entityId Mandatory - The identity code of the entity attribute : entityIdScheme must be: http://www.fpml.org/spec/2003/entity-id-RED

referenceObligation/bond/ instrumentId

Mandatory - The ISIN code of the underlying Bond.attribute : instrumentIdScheme must be: http://www.fpml.org/spec/2002/instrument-id-ISIN

If the CDS is an index product:

creditDefaultSwap/generalTerms/indexReferenceInformation

indexName The name of the index. The indexNameScheme code scheme defines the source of the index name.

indexNameScheme must be: http://www.fpml.org/spec/2003/entity-name-RED

indexId A CDS index identifier. The indexIdScheme code scheme defines the source of the Id.

indexIdScheme must be: http://www.fpml.org/spec/2003/instrument-id-RED-pair

indexSeries The CDS index series identifier

indexAnnexDate The CDS index series annex date.

4.2.1.3 Business rules:

1. Contract must be between the two principal counterparties, identified by the buyerPartyReference and sellerPartyReference elements in the creditDefaultSwap structure

2. The effectiveDate element must be present and contain a valid business date. The date must be specified as an unadjustable date.

3. The scheduledTerminationDate element must be present and contain a valid business date. The date must be specified as an adjustable date.

4. If the product is a single name then the referenceInformation structure must be included, else, if the product is an index product then the indexReferenceInformation structure must be included.


http://www.fpml.org/spec/2003/entity-name-RED

4.2.1.4 Examples:

Example of the generalTerms structure for an Indexed CDS:

<generalTerms> <effectiveDate> <unadjustedDate>2012-05-04</unadjustedDate> </effectiveDate> <scheduledTerminationDate> <unadjustedDate>2012-06-04</unadjustedDate> </scheduledTerminationDate> <buyerPartyReference href="counterpartyA"/ <sellerPartyReference href="counterpartyB"/> <indexReferenceInformation> <indexName>iTraxx Europe Crossover Series 10 Version 3</indexName> <indexId indexIdScheme="http://www.fpml.org/spec/2003/instrument-id-RED-pair-1-0">2I667KAV0</indexId> <indexAnnexDate>2009-08-12</indexAnnexDate> </indexReferenceInformation> ...Etc... </generalTerms>

Example of the generalTerms structure for a Single Name CDS:

<generalTerms> <effectiveDate> <unadjustedDate>2012-05-04</unadjustedDate> </effectiveDate> <scheduledTerminationDate> <unadjustedDate>2012-06-04</unadjustedDate> </scheduledTerminationDate> <buyerPartyReference href="counterpartyA"/ <sellerPartyReference href="counterpartyB"/> <referenceInformation> <referenceEntity> <entityName entityNameScheme="http://www.fpml.org/spec/2003/entity-name-RED">REDCDS001</entityName> <entityId entityIdScheme="http://www.fpml.org/spec/2003/entity-id-RED">123456789</entityId> </referenceEntity> <referenceObligation> <bond> <instrumentId instrumentIdScheme="http://www.fpml.org/spec/2002/instrument-id-ISIN">JP378860000</instrumentId> </bond> </referenceObligation> </referenceInformation> ...Etc... </generalTerms>


http://www.fpml.org/spec/2003/entity-name-RED

http://www.fpml.org/spec/2003/entity-id-RED

http://www.fpml.org/spec/2002/instrument-id-ISIN

http://www.fpml.org/spec/2002/instrument-id-ISIN

4.2.2 feeLeg Structure The feeLeg element contains all the terms relevant to defining the fixed amounts/payments pertaining to the applicable ISDA definitions. The high level structure of the feeLeg element is shown below.

Figure 14 - feeLeg structure

The main elements of a feeLeg structure are:

• initialPayment

• periodicPayment

Each of these elements is further described below.


4.2.2.1 initialPayment Structure

Figure 15 - initialPayment structure


The initialPayment structure defines a single fixed payment that is payable by the payer to the receiver on the initial payment date. The base elements in the initialPayment structure are as follows:

Element Description initialPayment

payerPartyReference[@href] A reference to the party responsible for making the payments defined by this structure.

receiverPartyReference[@href] A reference to the party that receives the payments corresponding to this structure.

adjustablePaymentDate A fixed payment date that shall be subject to adjustment in accordance with the applicable business day convention if it would otherwise fall on a day that is not a business day.

paymentAmount Structure containing the details of the fixed payment amount.

initialPayment/paymentAmount

currency The currency in which an amount is denominated.

amount The monetary quantity in currency units.

Table 13 - initialPayment structure

See section 3 for further details on how parties are represented in the overall trade structure.


4.2.2.2 periodicPayment Structure

The periodicPayment structure defines a periodic schedule of fixed amounts that are payable by the buyer to the seller on the fixed rate payer payment dates. The base elements in the periodicPayment structure are as follows:

Figure 16 - periodicPayment structure

Element Description periodicPayment/fixedAmountCalculation

fixedRate The calculation period fixed rate. A per annum rate, expressed as a decimal. A fixed rate of 5% would be represented as 0.05.


4.2.3 protectionTerms Structure protectionTerms structure contains all the terms relevant to defining the applicable floating rate payer calculation amount, credit events and associated conditions to settlement, and reference obligations. The high level structure of the protectionTerms element is shown below.

Figure 17 - protectionTerms structure

The main elements of a protectionTerms structure are:

• calculationAmount

CDSClear does not require this information but it must be left in the trade. The will protectedTerms elements will be structurally validated but not subject to business validation or eligibility checks.

• creditEvents

creditEvents will only be specified for single name products and only when there has been a restructuring event. The ClearLink gateway will be unable to distinguish a restructuring event but should validate that the product is a single name product. if creditEvents is specified for a non single name product the message should be rejected.


Appendix A. FpML Schemas ClearLink uses the confirmation and reporting views supported by FpML 5.3..

The following schema headers must be present in the messages that are based on the confirmation view:

xmlns="http://www.fpml.org/FpML-5/confirmation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" fpmlVersion="5-3"

The following schema headers must be present in the messages that are based on the reporting view:

xmlns="http://www.fpml.org/FpML-5/reporting" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" fpmlVersion="5-3"


Appendix B. References B.1 Related documents

Ref No.

Reference Title VersionNo.

Document/ Link Notes

1. FpML Org http://www.fpml.org/index.html FpML Org Web page

2. FpML 5-3 Specification (Contact LCH for specification links)

Free registration required to access

3. W3C XML Specification 1.0 (Fifth edition)

http://www.w3.org/TR/REC-xml/

4. IETF RFC 2119 Standard http://www.ietf.org/rfc/rfc2119.txt

5. CDSClear Service Definition

(Contact LCH for specification links)

6. W3C UTC Specification http://www.w3.org/TR/NOTE-datetime

7. CDS ClearLink Messaging Specification

C1.3 (Contact LCH for specification links)


http://www.fpml.org/index.html

http://www.w3.org/TR/REC-xml/

http://www.ietf.org/rfc/rfc2119.txt

http://www.w3.org/TR/NOTE-datetime

http://www.w3.org/TR/NOTE-datetime

Appendix C. Code Lists C.1 partyRoleScheme

Following values are supported by ClearLink. Code Description Source

ClearingBroker Identifies the FCM or SCM party FpML

Executor The trade execution venue FpML

Client The price taking party ClearLink

Clearer The Clearing House ClearLink

Matcher The trade matching/affirmation venue ClearLink

Counterparty The counterparty in the trade ClearLink

TradeSource The trade source ClearLink



Appendix D. List of Abbreviations Abbreviation Explanation

AP Affirmation Platform

BIC Bank Identifier Code

CB Clearing Broker

CCP Central Counterparty

CLS Continuous Linked Settlement

EB Executing Broker

EID Swap Instrument Identifier

EOD End of Day

FCM Futures Commission Merchant

FpML Financial products Markup Language

FSA Financial Services Authority

FX Foreign Exchange

GCM General Clearing Member

ISO International Organization for Standardization

LCH London Clearing House Clearnet Ltd (LCH.Clearnet)

SCM SwapClear Clearing Member

SEF Swap Execution Facility

USI Universal Swap Identifier

UTC Coordinated Universal Time

UTF Unicode Transformation Format

UTI Universal Trade Identifier

W3C World Wide Web Consortium

XML eXtensible Markup Language

t

ClearLink C1.3 revision 4 Product Specification Specification - Product_v1.… · manufacturing...

Documents

Transcript of ClearLink C1.3 revision 4 Product Specification Specification - Product_v1.… · manufacturing...