CFTC Technology Advisory Committee Subcommittee on Data Standardization 

Group 2 – Machine-Readable Legal Documents

1 | P a g e

Generic Product Representation

Data Representation for Complex and Bespoke OTC Derivatives

Interim Recommendations to the CFTC Technical Advisory Committee - December, 2011

Table of Contents

Executive Summary.......................................................................................................................................2

Scope and Approach .....................................................................................................................................4

The Data Representation ..............................................................................................................................6

The Product Representation Lifecycle ........................................................................................................10

Cost-Benefit Analysis ..................................................................................................................................12

Appendix 1 - The FpML Generic Representation........................................................................................17

Appendix 2 - The DTCC Copper Representation .........................................................................................21
CFTC Technology Advisory Committee Subcommittee on Data Standardization 

Group 2 – Machine-Readable Legal Documents

2 | P a g e

Executive Summary

As the marketplace landscape takes shape to address the financial reform commitments, we see 

some clear trends as it relates to electronic data representation of OTC derivatives. A dominant 

role of FIX in the execution space, where this lightweight protocol has been used for a number 

of years; a collective commitment to FpML for SDR reporting, as a result of its completeness for

representing OTC derivatives terms; a dual role played by FIXML and FpML for clearing, often a 

function of whether the facility had roots in the listed derivatives or the OTC derivatives space.

In such context, leveraging FpML to represent complex and bespoke products carries the 

immense advantage of providing a common data representation across all OTC derivatives. Not 

only does a unique protocol translates into lower costs of interface and easier ability to 

aggregate data across products and asset classes, but it also provides a flexible framework for 

adjusting the level of data representation across the product innovation lifecycle.

FpML adopted the Generic Product representation to address the needs to capture the

complete spectrum of OTC derivatives, for purposes such as portfolio reporting and internal 

data representation. The approach consists in having a simplified product representation, which 

focuses on describing some fundamental economic fields. As very similar concept has been 

embraced by the industry for representing non-electronically confirmed credit derivatives in the 

DTCC Trade Information Warehouse, one difference being that a spreadsheet is used to 

communicate the data in that latter case.

Current usage shows that when this Generic Product representation is used, it applies to less 

than 5% of the OTC derivatives population.

As it relates to prudential regulators, the main limitation of such data representation is that it 

cannot be used as an input for computing valuation and risk analysis, as the transaction 

economics are not fully represented. It is however understood that this will not constitute an 

issue in the foreseeable future, as reporting participants will be required to periodically send 

their own valuation, while regulators do not intend to independently perform such computation 

for some period of time.

It is expected that this machine-readable Generic Product representation will be supplemented 

with the legally binding confirmation of the trade, in a format that is to be determined. While it 

is understood that this requirement to have the legal trade confirmation sent to the SDR applies 

to all trade types, it would have further value in the case of generic and complex products, 

considering that the machine-readable algorithmic representation will only have partial 

information about the transaction economics. This confirmation document would equip 

prudential regulators with the ability to investigate the full terms of such complex OTC 

derivative trades on a case-by-case basis.
CFTC Technology Advisory Committee Subcommittee on Data Standardization 

Group 2 – Machine-Readable Legal Documents

3 | P a g e

The cost-benefit analysis shows this Generic Product representation approach would preserve 

market participants’ ability to effectively participate in the product innovation cycle, and 

translate into significantly lower reporting costs for those products, a number of which will 

anyway not reach a level of maturity that would lead to significant volumes of activity.

Adopting the FpML Generic Product representation for complex and bespoke products 

constitutes then a good stepping stone for SDR reporting of complex and bespoke products, inline with a market practice that has proven to be quite effective at striking a good balance 

between product innovation and data reporting imperatives.
CFTC Technology Advisory Committee Subcommittee on Data Standardization 

Group 2 – Machine-Readable Legal Documents

4 | P a g e

Scope and Approach

This paper aims at evaluating the suitability of the Generic Product representation for the 

reporting of complex and bespoke OTC derivatives to the Swap Data Repositories (SDR). 

1

The concept behind such approach is to report basic transaction economics until the product 

has reached a sufficient level in the innovation cycle to allow for the standardization of such 

terms, while provide appropriate level of details for the other parts of the derivatives 

representation.

Such approach allows for the usage of a consistent data representation protocol across the 

whole spectrum of OTC derivatives. This is deemed as preferable to an alternative avenue that 

would consist in having a distinct algorithmic protocol for such population of OTC derivatives, 

because of the implied costs and complexities associated with the development and 

maintenance of dual reporting protocols. 2

This paper makes reference to two implementations of this concept: the FpML Generic Product 

representation, and the DTCC Copper Record representation.

The FpML protocol provides a normalized electronic data representation for OTC derivatives 

that is very closely aligned with the confirmation terms of those products. 

The implication is that a product needs to have reached a certain level of marketplace 

standardization as part of its confirmation language in order to be fully expressible through 

FpML.

This was identified some years ago as an issue in the cases where FpML is meant to represent a 

complete spectrum of OTC derivatives, such as portfolio reporting or internal data 

representation.

The response to this issue has consisted in developing a simplified product representation, 

which focuses on describing some fundamental economic fields. It is called the Generic Product 

representation.

 

1

And, more generally, to the respective derivatives Trade Repositories that have been mandated as part of the 

G20 commitment

2

 The usage of one consistent protocol allows to proceed by extension once a product becomes standardized. 

Making use of a distinct protocol for the early stages of a product lifecycle would, on the other hand, necessitate 

to re-do this initial implementation via an alternative protocol (say, FpML) once the product becomes mature. 

Furthermore, this would necessitate the maintenance of two standards across the industry for a similar purpose.
CFTC Technology Advisory Committee Subcommittee on Data Standardization 

Group 2 – Machine-Readable Legal Documents

5 | P a g e

When asked in 2009 by prudential regulators to centrally record non-electronically confirmed 

Credit derivatives transactions, DTCC has developed a similar approach, in the form of the 

Copper Record representation.

The DTCC Gold Record representation was implemented as part of the initial inception of the 

DTCC Trade Information Warehouse for credit default swaps, in November 2006. It corresponds 

to a bilaterally agreed electronic representation of the full set of contract terms. The Copper 

Records, on the other hand, aims at capturing information for the credit derivative transactions

which are not electronically confirmed. It was rolled out in July 2009, and corresponds to a 

single sided non-legal representation of some of the terms of the contracts. It has been 

enhanced in a number of respects since this initial implementation, to increase transparency 

and accommodate records submitted by clearing venues.

The purpose of this paper is to articulate how those concepts can be used for the purpose of 

reporting complex and bespoke OTC derivatives to the Swap Data Repositories.

The developments are organized in three sections and two appendices. The first section 

describes the data representation of the Generic Product implementation, using the analytical 

framework recently proposed by the CPSS/IOSCO Report on OTC Derivatives Data Reporting and 

Aggregation Requirements. The second section proposes a scope framework for this Generic 

Product representation in the context of the Dodd-Frank Wall Street Reform and Consumer 

Protection Act. The third section articulates a cost/benefit analysis in relation to this proposed 

approach.

The two appendices present more specific information and supportive examples for each of the 

two implementation approaches that are referenced as part of this document: respectively, the 

FpML Generic Product and the DTCC Copper Record representations.

As the FpML Generic representation and the DTCC Copper Record are very similar, the term 

‘Generic Product’ will be used when referring to both of those as an implementation concept. 

The terms ‘FpML Generic Product’ and ‘DTCC Copper Record’ will be used when specifically 

referring to one of those respective implementations.
CFTC Technology Advisory Committee Subcommittee on Data Standardization 

Group 2 – Machine-Readable Legal Documents

6 | P a g e

The Data Representation

The CPSS/IOSCO Report on OTC Derivatives Data Reporting and Aggregation Requirements 3

identifies the following functional categories of data elements that are of relevant value for the 

Trade Repositories:

1. Operational data, i.e. data used by a Trade Repository for internal management 

purposes and such as transaction number, trading and clearing venue, etc.

2. Product information, i.e. information that allows for the classification and/or 

identification of the instrument.

3. Transaction economics, i.e. the material terms of a transaction, including effective 

and termination dates, notional amounts, coupon amounts, payment schedules, etc.

4. Valuation data.

5. Counterparty information.

6. Underlyer information, i.e. unique code for identifying underlyers and various 

attributes of the underlyers.

7. Event data, i.e. information that records the occurrence of an event and includes a 

time stamp (which indicates precisely when a particular event occurred).

The below table presents the Generic Product representation coverage across each of those 

functional categories of data elements:

Functional Category Generic Product Representation

Operational data Same as standardized trades negotiated and confirmed non-electronically.

Product information Taxonomy classification will be provided, but not the UPI.

Transaction economics Basic information.

Valuation data Same as standardized trades.

Counterparty information Same as standardized trades.

Underlyer information The data structure exists. Its usage may differ across products.

Event data While the FpML structure exists, its usage may be limited in practice.

This table highlights the fact that the Generic Product fundamentally differs from the 

standardized instruments in relation to just one or two of those functional categories of data 

elements: the transaction economics and, to some extent, the lifecycle event.

The data representation consistency for the other functional categories relates to the fact that 

the firms that transact those complex and bespoke products need to integrate them as part of 

 

3

http://www.iosco.org/library/pubdocs/pdf/IOSCOPD356.pdf
CFTC Technology Advisory Committee Subcommittee on Data Standardization 

Group 2 – Machine-Readable Legal Documents

7 | P a g e

their operational, risk management and control frameworks. As a result, they need to have such 

a similar data representation across standardized and complex products.

On the other hand, the straight-through-processing infrastructure in place for the standardized 

products typically does not apply to low-volume complex instruments, which in turn translates 

to an absence of data normalization for the representation of the transaction economics and the 

lifecycle event data.

Let’s review more in detail each of those functional categories of data elements as they pertain 

to complex and bespoke products:

1. Operational data

The key distinguishing factor among OTC derivatives as it relates to operational data 

attributes is whether a product is transacted electronically or through voice. A trade 

executed electronically will indeed carry information that is typically not available for voice 

trade, such as the order time and the execution time.

As a result, it is expected that Generic Products should carry the same level of operational 

data than standardized products that are executed through voice channels.

2. Product information

The product taxonomies that are in the process of being finalized by ISDA include an ‘Exotic’ 

product identification for each of the 5 asset classes, which will allow reporting participants 

to appropriately classify the complex and bespoke products.

Generic Products will however not have a distinct Unique Product Identifier (UPI), the 

reason for this being that the normalized product identification that is necessary to generate 

such UPI code will not be available. This has been discussed and acknowledged by the ISDA 

UPI Working Group.

3. Transaction economics

The core set of transaction economics available as part of the Generic Product 

representation relates to dates and notional.

The dates allow to determine the start and end period of the trade. The FpML Generic 

Product representation includes the effective date, besides the start date.
CFTC Technology Advisory Committee Subcommittee on Data Standardization 

Group 2 – Machine-Readable Legal Documents

8 | P a g e

The notional allows to ‘size’ the trade, and is often required for financial reporting and 

other purposes. The FpML Generic Product provides the flexibility to express the notional 

either in currency or units, to accommodate the commodity and equity products.

The DTCC Copper Record representation being focused on the Credit products, it provides 

support to some other data elements that are specific to that asset class, when applicable: 

fixed rate, tranche attachment, tranche exhaustion, seniority, restructuring type. Those 

fields are however applicable to certain specific products types 4, and such an approach 

would be extremely difficult to extend to a broader cross-assets context where the set of 

complex and bespoke products in not well defined. As a result, the recommendation is to 

make use of the current FpML Generic Product representation as a starting point, and to 

potentially augment it down the road if need be.

4. Valuation data

It is understood that regulators will look for marketplace participants to provide on-going 

exposure information, and that they do not plan to compute exposure calculation 

independently in the foreseeable future.

In that respect, valuation information can be reported in exactly the same manner across 

the standardized and non-standardized (i.e. Generic) products.

5. Counterparty information

Similarly, the Generic Product representation should not affect the level of counterparty 

information to be reported to the SDR.

6. Underlyer information

Both the FpML Generic Product and DTCC Copper Record representations provide the 

ability to report the underlyer information, when applicable. (In the DTCC Copper Record 

representation, though, this representation is limited to the first underlyer in the case of 

basket trades.) 

Such support can seem counter-intuitive considering that it is deemed extremely difficult 

to normalize complex and bespoke products. It should however be noted that the Generic 

Product only provides a list of underlyer constituents. It does not provide information as to 

 

4

The DTCC specification makes a distinction between seven product types: single name, index, index tranche, CDS 

on loans, CDS on ABS, swaption and structured transaction.
CFTC Technology Advisory Committee Subcommittee on Data Standardization 

Group 2 – Machine-Readable Legal Documents

9 | P a g e

how those underlyer elements should be combined for the purpose of determining a 

payoff.

Furthermore, it should be expected that the level of underlyer information will vary among 

products and, possibly, reporting participants. It is recommended that the SDR reporting 

requirements should be kept flexible in that respect, at least in an initial period of time.

7. Event data

FpML models lifecycle events outside of the product/trade construct. As a result, from a 

strict data modeling standpoint the fact that a product is either fully or generically 

represented does not impact the lifecycle event representation.

That being said, the level of sophistication of a lifecycle event model is directly correlated to

the level of straight-through processing that firms want to achieve. As a result, whenever 

possible firms tend to opt for a ‘snapshot’ approach as it relates to complex and bespoke 

products. The DTCC Copper Record is an example of such an implementation.

It is expected that this machine-readable Generic Product representation will be supplemented with the 

legally binding confirmation of the trade, in a format that is to be determined. While it is understood 

that this requirement to have the legal trade confirmation sent to the SDR applies to all trade types, it 

would have further value in the case of generic and complex products, considering that the machinereadable algorithmic representation will only have partial information about the transaction economics. 

This confirmation document would equip prudential regulators with the ability to investigate the full 

terms of such complex OTC derivative trades on a case-by-case basis.
CFTC Technology Advisory Committee Subcommittee on Data Standardization 

Group 2 – Machine-Readable Legal Documents

10 | P a g e

The Product Representation Lifecycle

Adopting a Generic Product implementation for complex and bespoke products also requires 

the definition of an evolution path, to determine when a complete data representation should 

be adopted for a given product.

The following developments describe the approach currently in place at DTCC and at the market 

participants which make use of the Generic Product representation, and propose a possible 

avenue for SDR reporting.

The product representation cycle at DTCC

The ISDA Credit Implementation Group (CIG) is the governance structure for the DTCC Trade 

Information Warehouse as it relates to Credit derivatives. As such, it decides when it is 

appropriate for a Copper Record representation to be promoted to Gold Record. The decision 

combines volume, business prospects and product complexity considerations. 

According to the DTCC monthly metrics for July 2011, 96.72% of total credit derivatives trade 

volumes were represented through Gold Records. The remainder 3.28% of the population were 

represented as Copper Records. 5

The product representation cycle at the firms that make use of the Generic Product concept

Earlier version of this paper have been discussed with 20+market participants, either via group 

sessions hosted by ISDA or via one-on-one specific meetings.

These discussions appear to confirm the fact that this approach of having a more limited data 

representation downstream of the risk and pricing systems is quite widely used across the 

industry for representing non-standardized products. It is indeed not a coincidence if such 

approach was adopted by the large dealers to represent the complex credit derivatives for 

reporting purposes to the DTCC Trade Information Warehouse, in 2009.

The typical paradigm seems for those market participants to engage into a full representation of 

those products once there is a need to put in place straight-through-processing.

Those discussions with market participants also appear to confirm that those implementations 

of the Generic Product concept represent typically less than 5% of the number of outstanding 

 

5

It should be noted that those statistics indicate the number of trade records in the Trade Information Warehouse 

database. The Copper Records are then double-counted when compared to the Gold Records, because they are 

counted as submitted trades, while the Gold Records are counted as matched trades. 
CFTC Technology Advisory Committee Subcommittee on Data Standardization 

Group 2 – Machine-Readable Legal Documents

11 | P a g e

OTC derivatives – even if such percentages can be greater in certain asset classes, like equity and 

commodity.

The product representation cycle for SDR reporting - A proposed approach

The Dodd-Frank Wall Street Reform and Consumer Protection Act requires that standardized 

swaps be centrally cleared. As a result, it is proposed that this clearing requirement be used as 

the baseline for defining the set of products that should, at minimum, be fully represented as 

part of the reporting to the SDRs.

In practice, it can be expected that some products can reach an appropriate level of 

standardization, while liquidity and/or risk considerations might still be an impediment for 

mandating that they be centrally cleared.

As a result, it is suggested that the level of electronic confirmations be also used as a criterion 

for determining whether a product should be fully represented as part of the reporting to the 

SDRs.
CFTC Technology Advisory Committee Subcommittee on Data Standardization 

Group 2 – Machine-Readable Legal Documents

12 | P a g e

Cost-Benefit Analysis

Methodology 

This analysis compares the Generic Product implementation with the full representation of the 

transaction economics in terms of delivery timeline, implementation cost, and usage benefits 

for prudential regulators.

In order to accommodate for the widely accepted fact that the FpML standardized product 

representation would be inapplicable to the tail-end of the OTC derivatives lifecycle spectrum

(i.e. those extremely tailored and exotic products, which in some cases are transacted only 

once), the analysis is focused on the ‘emerging products’, i.e. those which are marketed and 

traded in a repeated but still limited fashion and which terms are not yet completely 

standardized.

The analysis is based upon the extensive experience developed by industry participants in 

making use of FpML to represent OTC derivatives products, whether for internal data 

representation purposes or as part of marketplace initiatives (such as the DTCC Trade 

Information Warehouse). The time-to-market estimate has been developed leveraging the 

experience of the FpML working groups assigned to creating the respective product 

representations. The cost estimate has been evaluated leveraging participant experience in 

implementing such representation. This analysis has been discussed with 20+ market 

participants that included sell-side and buy-side firms, as well as industry service providers and 

marketplace utilities.

This analysis shows that the Generic Product representation for the purpose of reporting 

complex and bespoke OTC derivatives to the Swap Data Repository would result in two sets of 

benefits for the marketplace:

 It would preserve market participants’ ability to effectively participate in the product 

innovation cycle;

 It would translate into significantly lower reporting costs for those products, a number 

of which will never reach a level of maturity that would lead to significant volumes of 

activity.

From a usage standpoint, it is estimated that such approach would meet prudential regulators’ 

requirements until they decide to independently price and value such complex and bespoke 

transactions. At that point, experience demonstrates that reported transaction economics can 

be effectively enriched for the products that require it.
CFTC Technology Advisory Committee Subcommittee on Data Standardization 

Group 2 – Machine-Readable Legal Documents

13 | P a g e

The Generic Product representation as a way to preserve market participants’ ability to participate in 

the product innovation lifecycle

Developing a normalized representation for OTC derivatives is a two-step process:

 The development of an industry standard representation. This requires the definition of 

the appropriate legal language at the marketplace level, followed by the development 

of an algorithmic representation of those terms. The experience at ISDA shows that it 

typically takes between 3 to 6 months, depending of whether it’s an extension of an 

existing product, or a completely new product.

 Once this industry standard is in place, the respective participants then need to 

integrate this new data representation into their respective systems. Here also, the 

experience shows that it typically takes 3 to 6 months to do so.

As a result, implementing a full normalized representation of the trade economics for bespoke 

and complex OTC derivatives would add a 6 months to 1 year time-to-market lead time for each 

product as part of the product innovation cycle. 6

As mentioned as part of the introduction to this cost-benefit analysis, it is certainly not 

suggested here that we should look to develop a standardized data representation for each and 

every OTC derivative that is traded on the marketplace. Some of those are traded only once, 

among two parties, and it would then not be feasible to agree on and implement a standard 

representation at the industry level for those.

The Generic Product representation as a way to control the reporting infrastructure cost

Evaluating the incremental cost associated with a complete product representation versus a 

Generic Product representation requires 3 data estimates:

 The incremental cost per OTC derivative product;

 The number of products currently represented as Generic Products across the industry;

 The number of reporting participants and SDR that would have to undertake the work.

 

6

These estimates will vary according to whether it is a variation of an existing product, or a new product 

altogether. They are based upon the experience that was developed for representing new products through FpML 

over the past 10 years or so. While the industry had the experience of implementing very simple variations of 

existing products more quickly than mentioned here, some products also took significantly longer (mortgage

derivatives would be an example that comes to mind). The goal here is to focus on the typical cases, as opposed to 

the tail-end of the distribution.
CFTC Technology Advisory Committee Subcommittee on Data Standardization 

Group 2 – Machine-Readable Legal Documents

14 | P a g e

Estimating the implementation cost differential associated with a Generic Product 

representation versus a full product representation

For the purpose of simplicity, we assume that the implementation cost is limited to two set of 

actors: the reporting participants and the trade repositories. 

7

 Market participant development costs: the additional incremental cost of a full 

implementation versus of Generic Product implementation is estimated at 4 manmonths when limited to the transaction economics, and 1 man-year if lifecycle events

also need to be modeled. 

8

 Assuming that two of the five asset classes will have a 

lifecycle event model, while the other three will have a snapshot update model 9, this 

leads to an averaged 7 man-months work estimate per product.

 Trade repository cost: internal analysis by DTCC concluded that the above cost can also 

be applied as the estimate of the incremental effort required for implementing a Gold 

Record representation by the trade repository. As noted the previous page, while

experience shows that this effort can vary significantly depending on how unusual the 

product is, this estimate is a fair reflection of such incremental effort.

Estimating the number of products currently represented as Generic Products across the 

industry

This is certainly the most difficult part of the exercise. As stated above, the proposed approach 

is to limit the scope of this cost-benefit analysis to the products that are already traded in some 

‘reasonable’ volumes. 

Information collected from market participants leads to think that we have in the order of 10 to 

15 products per asset class which have more than 100 open trades associated with each of 

them, but which transaction economics are not yet full normalized and standardized in order to 

allow (among other things) for operational straight-through processing.

 

7

In particular, we are proposing to ignore the cost associated with the definition of the standardized 

representation itself at the marketplace level. While such effort translates into a significant elapse time (the 3 to 6 

months already mentioned), the actual work involved is indeed quite difficult to estimate. It is also estimated to 

be much less significant than the overall implementation cost across participants.

8

This cost includes the combined set of Technology and Operations resources typically associated with such 

implementation.

9

See CFTC proposed rule 17 CFR Part 45 Swap Data Recordkeeping and Reporting Requirements.
CFTC Technology Advisory Committee Subcommittee on Data Standardization 

Group 2 – Machine-Readable Legal Documents

15 | P a g e

Estimating the number of reporting participants and SDR that would have to undertake the work

The CFTC proposed rule 17 CFR Part 45 Swap Data Recordkeeping and Reporting Requirements, 

estimates the number of entities impacted by the reporting obligations as follows: 15 SDRs, 50 

MSPs, 250 SDs, 12 DCOs, and 40 SEFs.

Considering that the DCOs and SEFs will only get involved in standardized products, they should 

not be part of the scope analysis as it relates to the Generic Product representation.

As a result, the number of entities to be considered as part of the cost-benefit analysis should be 

300 reporting entities and 15 SDRs.

For the purpose of this cost-benefit analysis, this assumption however needs to be further 

refined in order to account for the fact that some participants will play a role in relation to only 

certain of the asset classes, while a number of them will also outsource the work to marketplace 

service providers (either software development firms or middleware service providers). As a 

result, we have adopted the following further assumptions:

 10 first tier reporting participants will undertake the work internally, across the 5 asset 

classes.

 30 second tier reporting participants will undertake the work internally, across 3 asset 

classes.

 260 reporting entities will rely on service providers to do the work. For the purpose of 

this exercise, we assume that there will be 20 such service providers, each of them 

covering 2 asset classes.

 While we will have one global SDR covering the 5 asset classes, we assume that the 14 

other SDRs will be asset-class specific.

The table below presents the outcome of this incremental cost analysis. Assuming that 10 products per 

asset class would have the potential to be eligible for a full representation of their transaction 

economics, such representation would translate into an additional reporting cost of 1,161 man-years 

across the industry. This incremental cost would be 1,741 man-years if we assume 15 products per 

asset class.

Number of asset 

classes per 

entity

Effort per entity if 10 

products per asset class

(man-years)

Effort per entity if 15 

products per asset class

(man-years)

Number of 

Entities

Marketplace effort if 10 

products per asset class

(man-years)

Marketplace effort if 15 

products per asset class

(man-years)

1

st tier reporting participants 5 29 44 10 292 438

2

nd tier reporting participants 3 18 26 30 525 788

Service providers 2 12 18 20 233 350

Global SDR 5 29 44 1 29 44

Asset-class specific SDRs 1 6 9 14 82 123

Total 1,161 1,741
CFTC Technology Advisory Committee Subcommittee on Data Standardization 

Group 2 – Machine-Readable Legal Documents

16 | P a g e

The Generic Product representation as satisfying prudential regulators needs in the foreseeable future

As indicated in the second part of this document, the key limitation associated with the Generic 

Product representation is that it cannot be used as an input to independently compute valuation 

and risk analysis.

Prudential regulators involved in discussions with the Working Group confirmed that this would 

not constitute an issue in the foreseeable future, as reporting participants will be required to 

provide valuation information.

If prudential regulators want to independently compute valuation and risk analysis at a later 

point, experience shows that such Generic Product representation constitutes a flexible 

paradigm, which can be extended for the products that justify it.
CFTC Technology Advisory Committee Subcommittee on Data Standardization 

Group 2 – Machine-Readable Legal Documents

17 | P a g e

Appendix 1 - The FpML Generic Representation

The diagram below presents the main components of the FpML schema for the Generic Product 

representation.
CFTC Technology Advisory Committee Subcommittee on Data Standardization 

Group 2 – Machine-Readable Legal Documents

18 | P a g e

The following comments can be made in relation to this schema representation:

- This schema representation doesn’t incorporate the operational data elements that are part 

of the tradeHeader information, which corresponds to the root element that is common 

across all the FpML trade representations. This tradeHeader construct includes the trade 

date, the relevant timestamps, the clearing status, the execution and clearing information, 

etc.)

- Most of the data elements are optional, to accommodate the fact that the ability to provide 

the relevant information may vary among asset classes and products. (In the above 

diagram, optional components are represented with dotted lines.)

- This diagram only highlights the main components of this Generic Product representation. 

The complete set of information can be accessed from the ISDA FpML web site, at 

http://www.fpml.org/ . (It is part of the recordkeeping and reporting views.)

FpML Generic Product examples

The three examples below present the set of data points that would typically be available 

through an FpML Generic Product representation. For simplicity purposes, the data is presented

through a table format, instead of a sample XML file.

Example 1 – Exotic interest rate swap

Functional Category FpML Data Element Example Value

Operational data Event type New trade

Operational data Trade identifier 12345

Operational data Execution type Voice

Operational data Execution venue Not Applicable

Operational data Clearing indicator N

Product information Asset class Interest rate

Product information Base product Exotic

Product information Sub-Product Not populated

Product information Transaction Type Not populated

Counterparty information Party A identifier LEI A

Counterparty information Party B identifier LEI B

Transaction economics Buyer party Party A

Transaction economics Seller party Party B

Transaction economics Trade date 2010-08-10

Transaction economics Effective date 2010-08-10

Transaction economics Termination date 2015-08-10

Transaction economics Notional amount 123,200,000

Transaction economics Notional currency USD

Transaction economics Settlement currency USD

Underlyer information Fixed rate Not populated

Underlyer information Floating rate Not populated
CFTC Technology Advisory Committee Subcommittee on Data Standardization 

Group 2 – Machine-Readable Legal Documents

19 | P a g e

Example 2 – Exotic credit derivative

Functional Category FpML Data Element Example Value

Operational data Event type New trade

Operational data Trade identifier 23456

Operational data Execution type Voice

Operational data Execution venue Not Applicable

Operational data Clearing indicator N

Product information Asset class Credit

Product information Base product Exotic

Product information Sub-Product Corporate

Product information Transaction Type Not populated

Counterparty information Party A identifier LEI A

Counterparty information Party B identifier LEI B

Transaction economics Buyer party Party A

Transaction economics Seller party Party B

Transaction economics Trade date 2009-05-10

Transaction economics Effective date 2009-05-21

Transaction economics Termination date 2012-06-20

Transaction economics Notional amount 50,000,000

Transaction economics Notional currency USD

Transaction economics Settlement currency USD

Underlyer information Reference entity - Entity name Alcoa Inc.

Underlyer information Reference entity - RED ID 0A4848

Underlyer information Reference obligation – ISIN US00440EAC12
CFTC Technology Advisory Committee Subcommittee on Data Standardization 

Group 2 – Machine-Readable Legal Documents

20 | P a g e

Example 3 – Exotic equity derivative

Functional Category FpML Data Element Example Value

Operational data Event type New trade

Operational data Trade identifier 23456

Operational data Execution type Voice

Operational data Execution venue Not Applicable

Operational data Clearing indicator N

Product information Asset class Equity

Product information Base product Exotic

Product information Sub-Product Not populated

Product information Transaction Type Not populated

Counterparty information Party A identifier LEI A

Counterparty information Party B identifier LEI B

Transaction economics Buyer party Party A

Transaction economics Seller party Party B

Transaction economics Trade date 2009-05-10

Transaction economics Effective date 2011-10-14

Transaction economics Termination date 2012-01-04

Transaction economics Notional amount 108,000,000

Transaction economics Notional currency USD

Transaction economics Settlement currency USD

Underlyer information Instrument ID – RIC Code GOOG.O

Underlyer information Instrument ID – ISIN Code US38259P5089

Underlyer information Market ID NASD
CFTC Technology Advisory Committee Subcommittee on Data Standardization 

Group 2 – Machine-Readable Legal Documents

21 | P a g e

Appendix 2 - The DTCC Copper Representation

Following are two Copper Records examples which highlight the main features of the Copper 

Record data representation that has been in use at DTCC since 2009. 

Example 1 – Structured transaction

Functional Category DTCC Data Element Example Value

Operational data Activity New

Operational data Transaction Type Trade

Operational data Participant Account ID 00006440

Operational data Participant Trade Reference Number 123

Operational data Counterparty Trade Reference 456

Operational data Counterparty Account ID 00006441

Operational data Clearing Product Code Not populated

Operational data Cleared Trade No

Operational data Record Type Trade

Operational data Counterparty Exchange ID (DCM) RPX

Operational data Customer Account ID 9A4C6G45

Operational data Customer Account Origin CUST

Operational data Participant ID of the Customer 00006441

Product information Asset Class Credit

Product information Product Type Structured Transaction

Counterparty information Counterparty Account Name Party A

Counterparty information Customer Account Name ABC TRADING COMPANY

Transaction economics Buyer/Seller Indicator Buyer

Transaction economics Effective Notional Amount 70,000,000

Transaction economics Effective Notional Currency USD

Transaction economics Multi-Leg N

Transaction economics Trade Date 2010-01-01

Transaction economics Maturity Date 2011-01-01

Transaction economics Fixed Rate Not populated

Transaction economics Tranche Attachment 1.75

Transaction economics Tranche Exhaustion 1.75

Transaction economics Seniority Not populated

Transaction economics Restructuring Type Not populated

Underlyer information Reference Entity ID 123456

Underlyer information Reference Entity Name ABC Company
CFTC Technology Advisory Committee Subcommittee on Data Standardization 

Group 2 – Machine-Readable Legal Documents

22 | P a g e

Example 2 – Loan CDS

Functional Category DTCC Data Element Example Value

Operational data Activity New

Operational data Transaction Type Trade

Operational data Participant Account ID 00006440

Operational data Participant Trade Reference Number 123

Operational data Counterparty Trade Reference 456

Operational data Counterparty Account ID 00006441

Operational data Clearing Product Code Not populated

Operational data Cleared Trade No

Operational data Record Type Trade

Operational data Counterparty Exchange ID (DCM) SPX

Operational data Customer Account ID 9A4C6G43

Operational data Customer Account Origin HOUS

Operational data Participant ID of the Customer 00006441

Product information Asset Class Credit

Product information Product Type Loan CDS

Counterparty information Counterparty Account Name Party A

Counterparty information Customer Account Name ABC TRADING COMPANY

Transaction economics Buyer/Seller Indicator Buyer

Transaction economics Effective Notional Amount 40,000,000

Transaction economics Effective Notional Currency USD

Transaction economics Multi-Leg N

Transaction economics Trade Date 2010-01-01

Transaction economics Maturity Date 2011-01-01

Transaction economics Fixed Rate 1.50000

Transaction economics Tranche Attachment Not populated

Transaction economics Tranche Exhaustion Not populated

Transaction economics Seniority Not populated

Transaction economics Restructuring Type Not populated

Underlyer information Reference Entity ID 123456

Underlyer information Reference Entity Name ABC Company