Product Representation for Standardized Derivatives

White Paper

April 14, 2011
Page | 2

Product Representation for Standardized Derivatives

White Paper 

Contents

1. Executive Summary...............................................................................................................................4

2. The Value Proposition...........................................................................................................................6

3. The Derivatives Product Registry..........................................................................................................7

A. The working principles......................................................................................................................7

a. Central administration..................................................................................................................7

b. Full set of economics.....................................................................................................................7

c. FpML compliant representation ...................................................................................................8

d. Marketplace access to the registry...............................................................................................8

e. Common product taxonomy with the OTC representation..........................................................8

f. Non-intelligent product identifier.................................................................................................9

B. The two-tiered data model...............................................................................................................9

C. The marketplace workflow .............................................................................................................11

D. Open issues.....................................................................................................................................12

4. The FpML Representation of the Product & Tradable Instrument.....................................................14

Use Case #1 – Fixed-Float Interest Rate Swap........................................................................................14

a) The Product Representation.......................................................................................................15

b) The Tradable Instrument Representation ..................................................................................18

Use Case #2 – Basis Swap .......................................................................................................................20

Use Case #3 – Cross-Currency swap .......................................................................................................20

a) The Product Representation.......................................................................................................20

b) The Tradable Instrument Representation ..................................................................................21

Use Case #4 - Single Name Credit Default Swap.....................................................................................21

a) The Product Representation for case 1 – Reference to the matrix ............................................22

b) The Tradable Instrument Representation for case 1 – Reference to the matrix........................23

c) The Product Representation for case 2 – Inclusion of the matrix terms as part of the Product 

definition.............................................................................................................................................24

d) The Tradable Instrument Representation for case 2 – Inclusion of the matrix terms as part of 

the Product definition.........................................................................................................................27
Page | 3

Use Case #5 – Index Credit Default Swap ...............................................................................................27

a) The Product Representation.......................................................................................................27

b) The Tradable Instrument Representation ..................................................................................28

Use Case #6 –Strategies..........................................................................................................................29

5. Next Steps and Migration Considerations..........................................................................................30

© 2011 International Swaps and Derivatives Association, Inc.

ISDA is a registered trademark of the International Swaps and Derivatives Association, Inc.

FpML is a registered trademark of the International Swaps and Derivatives Association, Inc.
Page | 4

1. Executive Summary

For standardized OTC derivatives i.e. broadly speaking those derivatives that will be centrally cleared or 

electronically executed, a marketplace infrastructure similar in certain respects to the one in place for 

securities markets and futures and listed options markets could be developed if all processes forming

part of the lifecycle workflow (buy/sell trades; post-execution clearing and settlement activities; reports 

to marketplace regulators) can use product identifiers that link to the full set of product economics 

abstracted as reference data. Such an approach is much simpler than the contractual workflow currently 

in place for OTC derivatives, where each of the lifecycle events needs to carry a full representation of 

the contract economics.

In this white paper we examine how this can be achieved for the standardized portion of the OTC 

derivatives markets. The first part of the paper contains a proposed approach, details the main 

fundamentals for the approach and describes the benefits of this change in market infrastructure. In the 

second part of the paper we examine a set of use cases and describe the next steps. 

The central infrastructure change that is proposed consists of establishing a Derivatives Product Registry 

facility that will:

 Maintain a reference data representation for standardized derivatives;

 Issue product identifiers that will be associated with each of those derivatives;

 Disseminate this reference information to all market participants.

The implementation of such a central Derivatives Product Registry is built around two main concepts:

 Leverage the FpML data representation protocol for OTC derivatives in order to provide an 

electronic reference (a.k.a. canonical) representation in the form of XML documents for each of 

the distinct derivatives products that are eligible for clearing or electronic execution through 

marketplace facilities.

 Associate unique identifiers to each of those canonical representations. This will allow for the 

transactional data to carry those identifiers, which in turn point to referential databases that will 

contain the economic details of those derivative products.

As a result, the following benefits will be achieved:

 Simplification of the trade processing and reporting architecture across the marketplace for the 

standardized products, as market participants will be able to abstract the trade economics 

through reference data instead of having to specify them as part of each transaction.

 Better support for the regulatory reform initiatives:

- Price transparency reporting: unambiguous relationship between the price and the full 

trade economics, via the Product Identifier.
Page | 5

- Electronic trading platforms' relationships with participants: the "reference data" 

approach will facilitate usage of and interoperability with other industry protocols.

Participants reporting to the Data Repositories: eased through the reporting of Product 

Identifiers instead of full trade economics.

- Regulatory transparency: better aggregation & analysis of positions with the same 

Product Identifier.

This proposal partly relates to the Unique Product Identifier (UPI) concept specified by the CFTC through 

its proposed regulation in application of the Dodd-Frank Act. It goes beyond some of the objectives 

assigned by the Commission.

The proposed CFTC regulation 17 CFR Part 43 indicates that “Unique product identifier means a unique 

identification of a particular level of the taxonomy of the asset class or sub-asset class in question.” 

Although the Product representation solution that is developed in this white paper is not aimed at 

providing a taxonomy solution, this paper identifies the need for a taxonomy that will be used to 

navigate the products available in the Derivatives Product Registry. Furthermore, this paper stresses the 

benefits associated with leveraging a common data representation protocol (FpML) across the 

standardized and bespoke derivatives for the purpose of having a unique aggregation taxonomy across 

those. To this effect, ISDA has proposed to work with regulators in order to review the taxonomy 

developed through FpML over the past 10 years and enhance where needed.

CFTC proposed regulation 17 CFR Part 43 also indicates that “The Commission envisions that the 

reporting of the data fields in appendix A to proposed part 43 may eventually be reported in the form of 

a consolidated ticker, particularly for the more standardized swaps that are traded on swap markets. 

Additionally, the Commission believes that when unique product identifiers emerge they will be publicly 

disseminated, increase uniformity and transparency across real-time disseminators and ultimately lead 

to greater transparency and price discovery.” Example of such price tickers are developed as part of this 

text: 16:20:47 IRS 10 TXIIIL 2.53 @0 G21 for a fixed-float interest rate swap, and 16:20:47 IRS 1 0 TXIIIL S/1W 

2.53 @0.07 G21 EMBED1 EU 2.53PF@–.04 LOG12 for an interest rate swaption. (See here for more details 

about this ticker approach.) 

For the standardized derivatives that will be executed on an electronic platform or centrally cleared, the 

solution proposed in this white paper supports such price transparency reporting more effectively than 

the proposed price ticker, because of the Product Identifier which points to the complete set of 

derivatives economics, i.e. an unambiguous specification of the product. We however recognize that, by 

focusing on the products that are executed and/or cleared on electronic markets, this leaves open the 

question as to how prices would be published for more bespoke derivatives that are transacted OTC and 

are not cleared.
Page | 6

2. The Value Proposition

The proposal is to develop a normalized product representation, with associated product identifiers, for 

swaps and other derivatives instruments which are listed or cleared through marketplace facilities. Such 

a normalized representation and product identifiers are expected to yield the following benefits:

1. Facilitation of the transparency reporting that is mandated as part of the financial reform: a 

standardized trade can be reported as a combination of certain transaction characteristics (such 

as notional), the identifier (which refers to the product economics) and a price.

2. Simplification of the trade processing flows, both at the marketplace level (where the 

respective participants will exchange transactional data which references those product 

identifiers) and as part of the internal processing for each of the participants (where the trade 

economics will be positioned as reference data, accessible through the unique product ID).

3. Greater flexibility among participants, who will be able to exchange information and move 

positions on instruments more easily among themselves, either vertically throughout the flow 

lifecycle (from execution facilities, all the way through to the trade repositories); or horizontally 

between respective participants (e.g. by allowing an easier transfer of positions between 

clearing agents).

4. Greater usability of and interoperability with other industry protocols1

, such as FIX in the trade 

execution space for financial products, which are more geared toward supporting simpler 

products with an associated product identifier or with few normalized data elements (like FX).

This initiative focuses on the standardized derivatives instruments that are electronically executed 

and/or centrally cleared. This market segment is expected to grow rapidly as a result of regulatory 

reforms currently under way. The reason for such scope limitation is twofold: (i) the proposed workflow 

requires that the product be centrally available before clearing or electronic execution, and (ii) the focus 

on standardized derivatives corresponds with the scope of electronic trading platforms and CCPs. 2

As part of the development of this white paper, it has been suggested that OTC participants should be 

allowed to make use of registered products if there are cases for them to be traded OTC or processed 

outside of central clearing. Similarly not all electronic execution will necessarily require the use of 

Product IDs. The exact scope will require further detailed discussions and might change over time.

 

1 ISDA/FpML promotes the use of existing open industry standards leveraging the different strengths of existing 

standards where appropriate. ISDA/FpML is actively involved in ISO 20022 and working towards FpML and ISO 

20022 convergence on the level of the business model. FpML currently supports several ISO standards such as BIC 

and currency codes and will support emerging standards such as LEI.

2 The scope is limited to traditional OTC products that become subject to central clearing or become listed or 

traded on electronic platforms. This initiative is not aimed at futures or listed options products which traditionally 

have been and still are transacted through exchanges and clearing facilities. Such products are generally simpler in 

representation and already benefit from a well developed central market infrastructure. 
Page | 7

3. The Derivatives Product Registry

A. The working principles

a. Central administration

In order to guarantee that (i) no redundant products are created, and (ii) the information dissemination 

to the marketplace takes place efficiently, the Derivatives Product Registry should be centrally 

administered

 The need for a centralized model to ensure the uniqueness of derivatives products stems from 

the following two considerations. First, the registration of derivatives products that are cleared 

or electronically executed on a central platform is not driven by the issuer agent. Whereas in 

the securities space the issuer’s agent knows when a product is ‘new’ and needs to be 

registered, in the derivatives space the registration is triggered by a decentralized set of actors 

who may not have complete knowledge as to whether a product with a given set of economics 

has already been created. Hence the benefit of having a centralized model to act as a central 

coordination agent to avoid such product duplication. Second, there is a concern that 

decentralization of the derivatives product creation at the venue level might lead to a situation 

where distinct products with same economics would coexist and as a result may be perceived 

as not equivalent (i.e. would the same product, created by two distinct execution venues, be 

deemed fungible if cleared by the same facility?). Having a centralized registry process 

eliminates this concern by focusing exclusively on the economics of those products.

 While we expect the creation of new products to be initiated by the execution and clearing 

venues, they will have to be propagated to all participants in order to be usable. As a result, the 

possible benefits associated with a faster turnaround in the creation process would be mitigated 

by the increased latency (everything being equal) in the dissemination process.

However, a decentralized approach for parts of the process will be further considered as part of the 

implementation considerations.

b. Full set of economics

The Derivatives Product Registry will maintain the full set of economics for each of the products. As 

mentioned above, this will not include a qualification of the execution and clearing venues where such 

products are eligible. We expect those venues to link such information to the trades as part of the 

execution and clearing stages, respectively.
Page | 8

The Derivatives Product Registry will be responsible for ensuring that no duplicate product economics 

exist in the registry.

c. FpML compliant representation

The Derivatives Products will be represented through FpML Product Schemas that will form part of the 

FpML standard. ISDA/FpML will develop a formal process for issuing appropriate schema 

representations for such products. 

As part of the registration process, the Derivatives Products Registry will ensure that those products will 

conform to the FpML schema.

d. Marketplace access to the registry

The Derivatives Product Registry will make the registry available to the marketplace in a non-restricted 

fashion. In order to do so, a navigation tool should be provided that allows open access to:

- The FpML schema library; which we expect to be actively used by the execution and clearing 

venues to determine if a schema is available to support a new product or tradable instrument

(see section B below for the proposed distinction between those two concepts as part of the 

proposed data modeling). If a schema is not available, ISDA/FpML will be responsible for its 

creation.

- The product registry; which we expect to be accessed by all marketplace participants. This 

access will need to combine user-query tools to navigate the registry, as well as electronic APIs

for the purpose of data dissemination.

e. Common product taxonomy with the OTC representation

One of the benefits associated with the usage of FpML to support the Derivatives Product 

representation is the ability to make use of a common protocol across the derivatives that are traded 

OTC and those that are traded through central execution and clearing venues and benefit from the 

product reference data representation.

This translates into a need for a common taxonomy, for the purpose of aggregating risks and positions 

across those two sets of representation.
Page | 9

f. Non-intelligent product identifier

We favor a ‘non-intelligent’ Product Identifier, because experience demonstrates that ‘intelligent’ 

identifiers make inherent assumptions relating to the structure of underlying products, and to the set of 

attributes required for unique identification. These assumptions can be rendered invalid over time as 

the complexity of product offerings increases. This would be of particular concern in the derivatives 

space, which is characterized by a dynamic product innovation. 

For ease of identification and readability of Product Identifiers, aliases can be associated with the 

product identifiers. Price transparency reporting is an example where, given the preference for nonintelligent identifiers, the use of aliases could provide value.

Note: A decentralized approach, as referred to under 3.A.a., would require the use of some form of 

intelligent identifier.

B. The two-tiered data model

For scalability purposes, it is proposed to have a two-tiered data model to present derivatives products:

 The ‘product’ level, which captures the attributes which are relatively static in nature. 

 The ‘tradable instrument’ level, which incorporates the economic attributes that are more 

dynamic in nature. The tradable instrument represents the executable instance of the product.

The figure below illustrates those relationships. The Product and Tradable Instrument entities will both 

be used as part of the Derivatives Product Registry to represent the product reference data. A Trade 

consists of transactional data that accesses product and tradable instrument data through an identifier.
Page | 10
Page | 11

C. The marketplace workflow

The below diagram illustrates the high-level workflow that is envisioned for the marketplace.

Observations:

 We expect the requests for new derivatives products to be initiated by the marketplace facilities 

(whether execution or clearing venues) that will list /clear those derivatives. As discussed in the 

scope section, the reason for excluding the OTC market is twofold: (i) there will be some level of 

latency as part of the product creation process, and (ii) the intent is to focus on standardized 

products. However, this would not prevent marketplace participants from making use of those 

derivatives products as part of their OTC activity.

Derivatives Product

All Market Participants Execution & Clearing 

Facilities

Derivatives Product 

Registry

Schema 

development

ISDA/FpML

Request for a 

new Product or 

Tradable 

Instrument 

If no schema support = 

Request product schema 

Register new 

Product & assign 

Product ID

Product & Tradable 

Schemas Library

Tradable 

Instrument 

Component

Step 1 – Query the 

library for confirming 

schema support

Register

Step 4 –

Subscription

Derivatives 

Reference Data

Subscribe for 

registry into their 

respective Product 

Master databases

Step 2 (default) - Product schema 

already exists  XML request

Product 

Component

Step 2 –

Registration
Page | 12

 ISDA/FpML will be a critical participant in the workflow, responsible for (i) making the product 

schemas available to the Derivatives Product Registry, and (ii) evolving the taxonomy across the 

whole FpML spectrum jointly with market participants, marketplace facilities (such as SDR) and 

regulators. Formal Service Level Agreements (SLA) will need to be defined in relation to the 

production/availability of Product and Tradable Instrument schemas.

 We expect the registration process to be completely automated, as long as the supporting 

schema exists. As a result, we expect new product requests to be processed intra-day, using a 

messaging infrastructure among participants.

 As mentioned in other parts of this document, the navigation tool into the Derivatives Products 

Registry will be a critical component of the infrastructure.

D. Open issues

A few open issues have been identified, for which resolution goes beyond the scope of this white paper.

a. Flex instruments

Flex instruments are products (such as equity index, commodity and FX futures and options) which are 

listed and centrally cleared, while having certain attributes which are created ‘on the fly’ at the time of 

trading. Examples of such attributes include the option strike level, the product termination/expiry date, 

or even the underlying asset.

There is currently no standard way to process such instruments. While the vertically integrated 

exchanges may process them efficiently through their own infrastructure, issues tend to arise once 

there is a need to interface with market participants or third party clearing facilities.

With respect to this white paper, no conclusive assessment can be made at this point regarding those 

instruments. There is a need to develop a case-by-case analysis (which is beyond the scope of this 

document), as the modeling approach will depend on whether the attributes in question belong to the 

Tradable Instrument or the Trade level.

b. Corporate actions

How should the Derivatives Product Registry handle corporate actions? One approach would be to have 

a versioning process, whereby a new version of product or tradable instrument is created each time 

there is a corporate action. Another approach would be to create a new product (or tradable 

instrument) altogether.
Page | 13

Those different approaches need to be evaluated in the context of the respective use cases. As an 

example, how would CDS Index tradable instrument operate when there is a credit event on one of the 

index constituents? Today, a new Markit RED 9-code is generated for the index and its version 

increments, e.g. 1 to 2, and the ‘annex date’ changes. What is the timing of when the new Markit RED 9-

code is generated? What do the CCPs do in these circumstances? (e.g. do they clear two distinct 

instruments?)
Page | 14

4. The FpML Representation of the Product & Tradable Instrument

Use Case #1 – Fixed-Float Interest Rate Swap

The modeling approach for the fixed-float interest rate swap consists of positioning the essential set of 

data elements in a cohesive fashion at the Product level. 

The data elements that are considered as not belonging to the Product level representation are the 

following:

 The start/end dates of the swaps, for which new dates will typically be created every day. The 

approach for tackling those is to rather associate a tenor concept at the Tradable Instrument 

level, which we expect to be expressed in years (e.g. two years, five years, ...). The start/end 

dates will then be deduced from the trade date (Trade level attribute), tenor (Tradable 

Instrument attribute) and spot date convention associated with the Floating Rate Index (Product 

attribute).

 The lag (if any) between the trade start date (which will be at the trade level) and the calculation 

start date (which would be the effective date of the trade in a contractual representation.

The following table recaps the proposed approach for the positioning of the respective data 

constituents:

Business Key Sample Value Modeling Approach

Fixed Start Date 2010-06-29 Trade (Implied)

Fixed Start Date

Adjustment

NONE Product

Fixed End Date 2012-06-29 Trade (implied)

Fixed End Date Adjustment MODFOLLOWING Product

Fixed End Date Business 

Days

GBLO

USNY

Product

Tenor 2 Years Tradable Instrument

Type Spot Tradable Instrument

Fixed Calculation Period 

End Dates Adjustment

MODFOLLOWING Product

Fixed Calculation Period 

and Payment Business Days

GBLO

USNY

Product

Fixed Calculation and 

Payment Frequency

Semi-Annually Product

Fixed Payment Dates

Adjustment

MODFOLLOWING Product

Fixed Currency USD Product

Fixed Day Count 

Convention

30/360 Product
Page | 15

Business Key Sample Value Modeling Approach

Float Start Date 2010-06-29 Trade (Implied)

Float Start Date Adjustment NONE Product

Float End Date 2012-06-29 Trade (Implied)

Float End Date Adjustment MODFOLLOWING Product

Float End Date Business 

Days

GBLO

USNY

Product

Float Calculation Period

End Dates Adjustment

MODFOLLOWING Product

Float Calculation Period and 

Payment Business Days

GBLO

USNY

Product

Float Calculation and 

Payment Frequency

Quarterly Product

Float Payment Date 

Adjustment

MODFOLLOWING Product

Float Currency USD Product

Reset Frequency Quarterly Product

Fixing Date Determination 2 London Business Days prior to each Reset Date Product

Floating Rate Index 3-Month USD-LIBOR-BBA Product

Float Day Count Convention ACT/360 Product

a) The Product Representation

As previously mentioned, the Product schema representation contains a cohesive description of the 

trade economics. Aside from the insertion of the productType and productId elements, the schema 

representation is consistent with the confirmation view.

<swap>

<productType>InterestRateSwap</productType>

<productId productIdScheme="http://newutility.com/code/product_id">789012</productId>

<swapStream>

<calculationPeriodDates id="fixedCalcPeriodDates">

<effectiveDate>

<dateAdjustments>

<businessDayConvention>NONE</businessDayConvention>

</dateAdjustments>

</effectiveDate>

<terminationDate>

<dateAdjustments>

<businessDayConvention>MODFOLLOWING</businessDayConvention>
Page | 16

<businessCenters>

<businessCenter>GBLO</businessCenter>

<businessCenter>USNY</businessCenter>

</businessCenters>

</dateAdjustments>

</terminationDate>

<calculationPeriodDatesAdjustments>

<businessDayConvention>MODFOLLOWING</businessDayConvention>

<businessCenters>

<businessCenter>GBLO</businessCenter>

<businessCenter>USNY</businessCenter>

</businessCenters>

</calculationPeriodDatesAdjustments>

<calculationPeriodFrequency>

<periodMultiplier>6</periodMultiplier>

<period>M</period>

</calculationPeriodFrequency>

</calculationPeriodDates>

<paymentDates>

<calculationPeriodDatesReference href="fixedCalcPeriodDates"/>

<paymentFrequency>

<periodMultiplier>6</periodMultiplier>

<period>M</period>

</paymentFrequency>

<payRelativeTo>CalculationPeriodEndDate</payRelativeTo>

<paymentDatesAdjustments>

<businessDayConvention>MODFOLLOWING</businessDayConvention>

<businessCenters>

<businessCenter>GBLO</businessCenter>

<businessCenter>USNY</businessCenter>

</businessCenters>

</paymentDatesAdjustments>

</paymentDates>

<calculationPeriodAmount>

<calculation>

<notionalSchedule>

<notionalStepSchedule>

<currency

currencyScheme="http://www.fpml.org/ext/iso4217">USD</currency>

</notionalStepSchedule>

</notionalSchedule>

<dayCountFraction>30/360</dayCountFraction>

</calculation>

</calculationPeriodAmount>

</swapStream>

<swapStream>

<calculationPeriodDates id="floatingCalcPeriodDates">

<effectiveDate>

<dateAdjustments>

<businessDayConvention>NONE</businessDayConvention>

</dateAdjustments>

</effectiveDate>

<terminationDate>

<dateAdjustments>
Page | 17

<businessDayConvention>MODFOLLOWING</businessDayConvention>

<businessCenters>

<businessCenter>GBLO</businessCenter>

<businessCenter>USNY</businessCenter>

</businessCenters>

</dateAdjustments>

</terminationDate>

<calculationPeriodDatesAdjustments>

<businessDayConvention>MODFOLLOWING</businessDayConvention>

<businessCenters>

<businessCenter>GBLO</businessCenter>

<businessCenter>USNY</businessCenter>

</businessCenters>

</calculationPeriodDatesAdjustments>

<calculationPeriodFrequency>

<periodMultiplier>3</periodMultiplier>

<period>M</period>

</calculationPeriodFrequency>

</calculationPeriodDates>

<paymentDates>

<calculationPeriodDatesReference href="floatingCalcPeriodDates"/>

<paymentFrequency>

<periodMultiplier>3</periodMultiplier>

<period>M</period>

</paymentFrequency>

<payRelativeTo>CalculationPeriodEndDate</payRelativeTo>

<paymentDatesAdjustments>

<businessDayConvention>MODFOLLOWING</businessDayConvention>

<businessCenters>

<businessCenter>GBLO</businessCenter>

<businessCenter>USNY</businessCenter>

</businessCenters>

</paymentDatesAdjustments>

</paymentDates>

<resetDates id="resetDates">

<calculationPeriodDatesReference href="floatingCalcPeriodDates"/>

<resetRelativeTo>CalculationPeriodStartDate</resetRelativeTo>

<fixingDates>

<periodMultiplier>-2</periodMultiplier>

<period>D</period>

<dayType>Business</dayType>

<businessDayConvention>NONE</businessDayConvention>

<businessCenters>

<businessCenter>GBLO</businessCenter>

</businessCenters>

<dateRelativeTo href="resetDates"/>

</fixingDates>

<resetFrequency>

<periodMultiplier>3</periodMultiplier>

<period>M</period>

</resetFrequency>

<resetDatesAdjustments>

<businessDayConvention>MODFOLLOWING</businessDayConvention>

<businessCenters>
Page | 18

<businessCenter>GBLO</businessCenter>

<businessCenter>USNY</businessCenter>

</businessCenters>

</resetDatesAdjustments>

</resetDates>

<calculationPeriodAmount>

<calculation>

<notionalSchedule>

<notionalStepSchedule>

<currency

currencyScheme="http://www.fpml.org/ext/iso4217">USD</currency>

</notionalStepSchedule>

</notionalSchedule>

<floatingRateCalculation>

<floatingRateIndex>USD-LIBOR-BBA</floatingRateIndex>

<indexTenor>

<periodMultiplier>3</periodMultiplier>

<period>M</period>

</indexTenor>

</floatingRateCalculation>

<dayCountFraction>ACT/360</dayCountFraction>

</calculation>

</calculationPeriodAmount>

</swapStream>

</swap>

b) The Tradable Instrument Representation

The Tradable Instrument representation will contain the two sets of data attributes, which will be 

supported through a new schema construct:

 The forward terms of the swap, i.e. the lag between the trade date (which is represented at the 

trade level) and the start date for the calculation period. This is supported through the <type> 

node and, if a forward term is specified the <start> node. Note that further analysis is required 

to determine the most appropriate way of ensuring that the marketplace has a common way of 

calculating the start date when the <type> node contains a value of ‘Spot’. For example, should 

the rules be parameterized and embedded as part of the product representation itself?

 The tenor of the swap, which is expressed through the <term> node.

Three examples are developed below, which present different use cases that have been identified: spot 

trade, forward starting trade, and forward starting IMM trade.

For the purpose of the forward starting IMM trade example we added a year field, the idea being to 

explicitly suggest fungibility by tenor across trades done on a given day. Another suggested approach 

consists in positioning the <year> as part of the trade data, which would result in a smaller number of 

tradable instruments.
Page | 19

Spot IRS

<tradableInstrument>

<interestRateSwapInstrument>

<tradableInstrumentType>USD-LIBOR-BBAIRSSpot</tradableInstrumentType>

<tradableInstrumentId tradableInstrumentIdScheme="http:// http://newutility.com

/code/tradableInstrument_id">EFGHIJ</tradableInstrumentId>

<productId productIdScheme="http://newutility.com/code/product_id">789012</productId>

<calculationPeriodDatesMethod>

<type>Spot</type>

<term>

<periodMultiplier>2</periodMultiplier>

<period>Y</period>

</term>

</calculationPeriodDatesMethod>

</interestRateSwapInstrument>

</tradableInstrument>

Forward Starting IRS

<tradableInstrument>

<interestRateSwapInstrument>

<tradableInstrumentType>USD-LIBOR-BBAIRSForwardStarting </tradableInstrumentType>

<tradableInstrumentId tradableInstrumentIdScheme="http:// http://newutility.com

/code/tradableInstrument_id">KLHEKJ</tradableInstrumentId>

<productId productIdScheme="http://newutility.com/code/product_id">789012</productId>

<calculationPeriodDatesMethod>

<type>ForwardStarting</type>

< start >

< offset >

<periodMultiplier>1</periodMultiplier>

<period>Y</period>

</ offset >

</ start >

<term>

<periodMultiplier>2</periodMultiplier>

<period>Y</period>

</term>

</calculationPeriodDatesMethod>

</interestRateSwapInstrument>

</tradableInstrument>

Forward Starting IMM IRS:

<tradableInstrument>

<interestRateSwapInstrument>

<tradableInstrumentType>USD-LIBOR-BBA IRSForwardIMM </tradableInstrumentType>

<tradableInstrumentId tradableInstrumentIdScheme="http:// http://newutility.com
Page | 20

/code/tradableInstrument_id">KLDHIJ</tradableInstrumentId>

<productId productIdScheme="http://newutility.com/code/product_id">789012</productId>

<calculationPeriodDatesMethod>

<type>ForwardStarting</type>

< start >

< monthYear >

<month>06</month>

<year>2011</year>

</monthYear>

<rollConvention>IMM</rollConvention>

</ start >

<term>

<periodMultiplier>2</periodMultiplier>

<period>Y</period>

</term>

</calculationPeriodDatesMethod>

</interestRateSwapInstrument>

</tradableInstrument>

Use Case #2 – Basis Swap

Following analysis, it appears that the basis swap product representation follows very much the 

structure of the fixed-float interest rate swap representation, the only difference being that there are 

two float legs instead of one fixed and one float leg.

Use Case #3 – Cross-Currency swap

a) The Product Representation

Following analysis, it appears that the Product representation of the cross-currency swap with constant 

notional3

<swap>

<productType>InterestRateSwap</productType>

<productId productIdScheme="http://newutility.com/code/product_id">456789</productId>

<swapStream id="floatingLeg">

<!—Same structure as the interest rate swap-->

has just one structural difference with respect to the interest rate swap: the addition of the 

principal exchange nodes:

 

3 The case of mark-to-market currency swaps where the principal exchange of one of the legs varies has not been 

evaluated as part of this white paper.
Page | 21

<principalExchanges>

<initialExchange>true</initialExchange>

<finalExchange>true</finalExchange>

<intermediateExchange>true</intermediateExchange>

</principalExchanges>

</swapStream>

<swapStream id="floatingLeg2">

<!—Same structure as the interest rate swap-->

<principalExchanges>

<initialExchange>true</initialExchange>

<finalExchange>true</finalExchange>

<intermediateExchange>true</intermediateExchange>

</principalExchanges>

</swapStream>

</swap>

b) The Tradable Instrument Representation

The Tradable Instrument Representation will be similar to the interest rate swap: the principal exchange 

amounts will be part of the trade representation, as it results from the actual notional of the trade.

Use Case #4 - Single Name Credit Default Swap

The proposed approach is to respectively position the Product and Tradable Instrument representation 

along the lines of the physical settlement Matrix Transaction Types. With some exceptions, the Product 

level contains the specifications as can be found in the physical settlement matrix, while the Tradable 

Instrument contains the additional elements that would lead to fungible trades. (For more information 

on the Credit Physical Settlement Matrix: http://www.isda.org/c_and_a/oper_commitusefuldocs.html#cd )

Credit-Derivatives-P

hysical-Settlement-Ma

Given the central role of the settlement matrix, the credit example has been worked out in two different 

ways. The first is with an explicit reference to the physical settlement matrix without replicating any of 

the elements defined in the settlement matrix. For the second approach, the settlement matrix 

elections have been replicated in the product representation without explicit reference to the matrix. 
Page | 22

a) The Product Representation for case 1 – Reference to the matrix

This corresponds to the approach where the schema includes an explicit reference to the physical 

settlement matrix, while not including any of the elements that are part of it. To this effect, a 

<matrixTerm> element is introduced as part of the product definition to host this reference.

The following table shows the approach of an explicit reference to the physical settlement matrix:

Business Key Sample Value Modeling Approach

Effective Date 2010-06-20 Not present. Implied by 

the trade date

Effective Date Business Day 

Convention

NONE Product 

Scheduled Termination 

Date

2012-06-20 Tradable Instrument

Scheduled Termination 

Date Business Day 

Convention

NONE Product

Business Day Convention FOLLOWING Product

Fixed Rate 1.00% Tradable Instrument

Fixed Rate Payer Payment 

Dates Frequency and 

Payment Day

Quarterly on the 20th of the month Product

Floating Rate Payer 

Calculation Amount 

Currency Denomination

USD Product

Reference Entity Identifier Markit RED Entity ID 3H98A Tradable Instrument

Reference Entity Name Ford Motor Company Tradable Instrument

Reference Obligation ISIN US345370BX76 (also RED could be used) Tradable Instrument

Matrix Type CreditDerivativesPhysicalSettlementMatrix Product

Matrix Term StandardNorthAmericanCorporate Product

<creditDefaultSwap>

<productType>SingleNameCreditDefaultSwap</productType>

<productId productIdScheme="http://newutility.com/code/product_id">123456</productId>

<generalTerms>

<effectiveDate>

<dateAdjustments>

<businessDayConvention>NONE</businessDayConvention>

</dateAdjustments>

</effectiveDate>

<scheduledTerminationDate>

<dateAdjustments>

<businessDayConvention>NONE</businessDayConvention>

</dateAdjustments>

</scheduledTerminationDate>

<dateAdjustments>

<businessDayConvention>FOLLOWING</businessDayConvention>

</dateAdjustments>
Page | 23

</generalTerms>

<feeLeg>

<periodicPayment>

<paymentFrequency>

<periodMultiplier>3</periodMultiplier>

<period>M</period>

</paymentFrequency>

<rollConvention>20</rollConvention>

</periodicPayment>

</feeLeg>

<protectionTerms>

<calculationAmount>

<currency>USD</currency>

</calculationAmount>

</protectionTerms>

<contractualMatrix>

<matrixType>CreditDerivativesPhysicalSettlementMatrix</matrixType>

<matrixTerm>StandardNorthAmericanCorporate</matrixTerm>

</contractualMatrix>

</creditDefaultSwap>

b) The Tradable Instrument Representation for case 1 – Reference to the matrix

We expect a Tradable Instrument to be created for each combination of:

 Reference entity

 Reference obligation

 Termination date (i.e. each quarter, for each of the standard 20th roll dates)

 Fixed Rate

<tradableInstrument>

<creditDefaultSwapInstrument>

<tradableInstrumentId instrumentIdScheme="http:// http://newutility.com

/code/tradableInstrument_id">ABCDF</tradableInstrumentId>

<productId productIdScheme="http://newutility.com/code/product_id">123456</productId>

<generalTerms>

<scheduledTerminationDate>

<unadjustedDate>2012-06-20</unadjustedDate>

</scheduledTerminationDate>

<referenceInformation>

<referenceEntity>

<entityName>Ford Motor Company</entityName>

<entityId entityIdScheme="http://www.ext.org/entity-id-RED-1-

0">3H98A</entityId>

</referenceEntity>

<referenceObligation>

<bond>

<instrumentId instrumentIdScheme="http://www.ext.org/instrument-
Page | 24

id-ISIN-1-0">US345370BX76</instrumentId>

</bond>

</referenceObligation>

</referenceInformation>

</generalTerms>

<feeLeg>

<periodicPayment>

<fixedAmountCalculation>

<fixedRate>0.01</fixedRate>

</fixedAmountCalculation>

</periodicPayment>

</feeLeg>

</creditDefaultSwapInstrument>

</tradableInstrument>

 

c) The Product Representation for case 2 – Inclusion of the matrix terms as part of the 

Product definition

The following table shows the approach of incorporating the matrix terms as part of the Product 

definition (second case):

Business Key Sample Value Modeling Approach Specified in 

Matrix

Effective Date 2010-06-20 Not present. Implied by the 

trade date

N

Effective Date Business Day Convention NONE Product N

Scheduled Termination Date 2012-06-20 Tradable Instrument N

Scheduled Termination Date Business Day 

Convention

NONE Product N

Business Day Convention FOLLOWING Product N

Business Days London and New York Product Y

Fixed Rate 1.00% Tradable Instrument N

Fixed Rate Payer Payment Dates Frequency 

and Payment Day

Quarterly on the 20th of the 

month

Product N

Floating Rate Payer Calculation Amount 

Currency Denomination

USD Product N

Reference Entity Identifier Markit RED Entity ID 3H98A Tradable Instrument N

Reference Entity Name Ford Motor Company Tradable Instrument N

Reference Obligation ISIN US345370BX76 Tradable Instrument N

All Guarantees False Product Y

Publicly Available Information Applicable Product Y

Bankruptcy True Product Y

Failure To Pay – Applicable True Product Y

Restructuring – Applicable True Product Y

Restructuring – Type ModR Product Y

Obligations – Category BorrowedMoney Product Y
Page | 25

Business Key Sample Value Modeling Approach Specified in 

Matrix

Physical Settlement Period – Maximum 

Business Days

30 Product Y

Deliverable Obligation Category BondOrLoan Product Y

Deliverable Obligations – Not Subordinated True Product Y

Specified Currency – Applicable True Product Y

Not Contingent True Product Y

Assignable Loan – Applicable True Product Y

Consent Required Loan – Applicable True Product Y

Transferable True Product Y

Maximum Maturity 30 Y Product Y

Not Bearer True Product Y

Escrow True Product Y

60 Business Day Cap on Settlement False Product Y

Calculation Agent Business Center New York Product Y

<creditDefaultSwap >

 <productType>SingleNameCreditDefaultSwap</productType>

<productId productIdScheme="http://newutility.com/code/product_id">123456</productId>

<generalTerms>

<effectiveDate>

<dateAdjustments>

<businessDayConvention>NONE</businessDayConvention>

</dateAdjustments>

</effectiveDate>

<scheduledTerminationDate>

<dateAdjustments>

<businessDayConvention>NONE</businessDayConvention>

</dateAdjustments>

</scheduledTerminationDate>

<dateAdjustments>

<businessDayConvention>FOLLOWING</businessDayConvention>

<businessCenters>

<businessCenter>GBLO</businessCenter>

<businessCenter>USNY</businessCenter>

</businessCenters>

</dateAdjustments>

<referenceInformation>

<allGuarantees>false</allGuarantees>

</referenceInformation>

</generalTerms>

<feeLeg>

<periodicPayment>

<paymentFrequency>

<periodMultiplier>3</periodMultiplier>

<period>M</period>

</paymentFrequency>

<rollConvention>20</rollConvention>

</periodicPayment>
Page | 26

</feeLeg>

<protectionTerms>

<calculationAmount>

<currency>USD</currency>

</calculationAmount>

<creditEvents>

<bankruptcy>true</bankruptcy>

<failureToPay>

<applicable>true</applicable>

</failureToPay>

<restructuring>

<applicable>true</applicable>

<restructuringType>ModR</restructuringType>

</restructuring>

<creditEventNotice>

<publiclyAvailableInformation>

<standardPublicSources>true</standardPublicSources>

</publiclyAvailableInformation>

</creditEventNotice>

</creditEvents>

<obligations>

<category>BorrowedMoney</category>

</obligations>

</protectionTerms>

<physicalSettlementTerms>

<physicalSettlementPeriod>

<maximumBusinessDays>30</maximumBusinessDays>

</physicalSettlementPeriod>

<deliverableObligations>

<accruedInterest>false</accruedInterest>

<category>BondOrLoan</category>

<notSubordinated>true</notSubordinated>

<specifiedCurrency>

<applicable>true</applicable>

</specifiedCurrency>

<notContingent>true</notContingent>

<assignableLoan>

<applicable>true</applicable>

</assignableLoan>

<consentRequiredLoan>

<applicable>true</applicable>

</consentRequiredLoan>

<transferable>true</transferable>

<maximumMaturity>

<periodMultiplier>30</periodMultiplier>

<period>Y</period>

</maximumMaturity>

<notBearer>true</notBearer>

</deliverableObligations>

<escrow>true</escrow>

<sixtyBusinessDaySettlementCap>false</sixtyBusinessDaySettlementCap>

</physicalSettlementTerms>

<calculationAgentBusinessCenter>USNY</calculationAgentBusinessCenter>

</creditDefaultSwap>
Page | 27

d) The Tradable Instrument Representation for case 2 – Inclusion of the matrix terms as 

part of the Product definition

The Tradable Instrument Representation for case 2 is identical to case 1.

Use Case #5 – Index Credit Default Swap

The index credit default swap representation follows the same principles as the single name credit 

default swap. The resulting Product representation is however more limited, as a result of the fact that 

the index specifies a number of the terms that are part of the single name Product definition.

Another difference relates to the Tradable Instrument definition, which incorporates the Start Date, the 

reason being that for a given index series the Start and Termination dates are fixed, irrespective as to 

when it is traded.

Business Key Sample Value Modeling Approach

Start Date 2010-09-20 Tradable Instrument 

Scheduled Termination 

Date

2015-12-20 Tradable Instrument

Fixed Rate 1.00% Tradable Instrument

Floating Rate Payer 

Calculation Amount 

Currency Denomination

USD Product

Index Family CDX.NA Product

Index Name CDX.NA.IG.15 Tradable Instrument

Index Identifier Markit RED ID Pair ID 2I65BYCL7 Tradable Instrument

a) The Product Representation

<creditDefaultSwap>

<productType>IndexCreditDefaultSwap</productType>

< indexFamily > CDX.NA </indexFamily>

<productId productIdScheme="http://newutility.com/code/product_id">789101</productId><protectionTerms>

<calculationAmount>

<currency>USD</currency>

</calculationAmount>

</protectionTerms>

</creditDefaultSwap>
Page | 28

b) The Tradable Instrument Representation

<tradableInstrument>

<creditDefaultSwapInstrument>

<tradableInstrumentType>IndexCreditDefaultSwap</tradableInstrumentType>

<tradableInstrumentId tradableInstrumentIdScheme="http:// http://newutility.com

/code/tradableInstrument_id">EFGHIJ</tradableInstrumentId>

<productId productIdScheme="http://newutility.com/code/product_id">789101</productId>

<generalTerms>

<effectiveDate>

<unadjustedDate>2010-09-20</unadjustedDate>

</effectiveDate>

<scheduledTerminationDate>

<unadjustedDate>2015-12-20</unadjustedDate>

</scheduledTerminationDate>

<indexReferenceInformation>

<indexName>CDX.NA.IG.15</indexName>

<indexId indexIdScheme="http://www.ext.org/entity-id-RED-pair-1-

0">2I65BYCL7</indexId>

<indexSeries>15</indexSeries>

<indexAnnexVersion>1</indexAnnexVersion>

<indexAnnexDate>2010-09-20</indexAnnexDate>

</indexReferenceInformation>

</generalTerms>

<feeLeg>

<periodicPayment>

<fixedAmountCalculation>

<fixedRate>0.01</fixedRate>

</fixedAmountCalculation>

</periodicPayment>

</feeLeg>

</creditDefaultSwapInstrument>

</tradableInstrument>
Page | 29

Use Case #6 –Strategies

Two approaches can be considered for representing ‘strategy products’, i.e. products that result from 

the combination of several individual trades (e.g. collar and curve products, which combine two 

individual trades; butterfly products, which combine three individual trades):

1. Specify a Product that combines those multiple legs, leveraging the Strategy concept in 

FpML. One of the important benefits associated with this approach relates to the price 

transparency reporting, as the executed price can then be effectively associated with the 

resulting identifier.

2. Combine several product identifiers, with one resulting identifier associated with each of 

the product components. The downside associated with such an approach relates to the 

issues for exposing the pricing information.

There is a strong bias in favor of the first of these two approaches. Further analysis during 

implementation will need to confirm that this is indeed a viable approach.
Page | 30

5. Next Steps and Migration Considerations

As a follow up on this paper, we will work on an implementation plan that will focus in more detail on 

the practical aspects of putting the proposed infrastructure in place. Besides the establishment of the 

Derivative Product Registry, careful consideration will need to be given to migration questions, such as 

the population of the initial set of products and the impact the existence of the Registry will have on 

existing message flows and how to adapt those. 

For the migration of the existing set of products to the new model, one possible approach would be to 

apply the workflow that is being proposed as part of this white paper during an initial conversion period

in order to populate the product registry. For this approach to be successful, the following high level 

steps need to be taken:

 The respective execution and clearing facilities will work with ISDA/FpML and the new 

Derivatives Product Registration Facility to create the appropriate set of schemas to support the 

new Products and Tradable Instruments.

 Once those are in place, those execution and clearing facilities will send queries to the 

Derivatives Product Registration Facility to register their existing products.

 The market participants will load those trade economics in their respective systems and confirm 

applicability as part of marketplace test phase.

It is clear that the rollout of such infrastructure will have profound impacts on the marketplace. 

Changing existing system and operational workflow for standardized products that use contractual 

representations to a much simplified representation that relies on the use of unique identifiers will have 

multiple impacts and as such will need to be carefully considered.