# FpML® Financial product Markup Language Recommendation 28 May 2013 (Transparency View)

## Version: 5.5

#### This version: http://www.fpml.org/spec/fpml-5-5-7-rec-1

#### Latest version: http://www.fpml.org/spec/fpml-5-5-7-rec-1

#### Previous version: http://www.fpml.org/spec/fpml-5-5-6-tr-2/

#### Errata for this version: http://www.fpml.org/spec/fpml-5-5-7-rec-1/html/transparency/fpml-5-5-errata.html

Build Number: 7; Document built: Thu 05/16/2013 15:09:29.92

Copyright (c) 1999 - 2013 by International Swaps and Derivatives Association, Inc.

Financial Products Markup Language is subject to the FpML® Public License.

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

A copy of this license is available at http://www.fpml.org/license/license.html

The FpML specifications provided are without warranty of any kind, either expressed or implied, including, without limitation, warranties that FpML, or the FpML specifications are free of defects, merchantable, fit for a particular purpose or non-infringing. The entire risk as to the quality and performance of the specifications is with you. Should any of the FpML specifications prove defective in any respect, you assume the cost of any necessary servicing or repair. Under no circumstances and under no legal theory, whether tort (including negligence), contract, or otherwise, shall ISDA, any of its members, or any distributor of documents or software containing any of the FpML specifications, or any supplier of any of such parties, be liable to you or any other person for any indirect, special, incidental, or consequential damages of any character including, without limitation, damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses, even if such party shall have been informed of the possibility of such damages.

## Table Of Contents

## 1 INTRODUCTION AND OVERVIEW

### 1.1 STATUS OF THIS DOCUMENT

This is the FpML 5.5 Recommendation for review by the public and by FpML members and working groups.

The FpML Working Groups encourage reviewing organizations to provide feedback as early as possible. Comments on this document should be sent by filling in the form at the following link: http://www.fpml.org/issues. An archive of the comments is available at http://www.fpml.org/issues/

There are also asset class-specific mailing lists; you can join them at the following link:

Join a Working Group at FpML

A list of current FpML Recommendations and other technical documents can be found at

http://www.fpml.org/spec

This document has been produced as part of the FpML 5.5 activity and is part of the Standards Approval Process.

### 1.2 ORGANIZATION OF THE DOCUMENTATION

The FpML documentation is organized into a number of subsections.

This section provides an overview of the specification.

####

1.2.1 Schema Reference

These are automatically generated reference documents detailing the contents of the various sections in the FpML schema.

- Core Definitions:
  - Main Components
  - Doc Components
  - Shared Components
  - Shared Enumeration definitions
  - Asset Components
- Products:
  - IRD
    - Interest Rate Components
  - FX
    - FX Components
  - CD
    - Credit Derivative Components
  - EQD
    - Equity Shared Components
    - Equity Derivative Options Components
    - Return Swaps Components
    - Variance Derivatives Swaps and Options Components
    - Correlation Derivatives Components
    - Dividend Derivatives Components
  - Bond Options
    - Bond Options Components
  - Options shared
    - Options Shared Components
  - Commodity
    - Commodity Derivative Components
  - Cross-Asset Class Products
    - Standard Product Components. (standardProduct-Standard products - for use in Transparency reporting to define a product that represents a standardized OTC derivative transaction whose economics do not need to be fully described using an FpML schema because they are implied by the product ID. In other views, standard products are present for convenience to support internal messaging and workflows that are cross-product. Standard products are not full trade representations as such they are not intended to be used for confirming trades.
      )
    - Generic Product Components (genericProduct-Generic products - for use in Transparency reporting to define a product that represents an OTC derivative transaction whose economics are not fully described using an FpML schema. In other views, generic products are present for convenience to support internal messaging and workflows that are cross-product. Generic products are not full trade representations as such they are not intended to be used for confirming trades.
      )
- Business Processes
  - Messaging Components
  - Business Event Notification Components
  - Transparency Processes (Public reporting)
- Reference:
  - Index and cross-reference of definitions
  - Schema and Example files - Provides zip file with FpML schemas and examples.

####

1.2.2 Other Documents in the Specification

- Examples - Provides sample FpML for each section.
- Scheme Definitions - Describes standard FpML schemes, and the values that they can take.
- FpML Products Framework (PDF) - Gives an overview of the financial products covered in FpML and their interrelationships.
- FpML Messaging Framework (PDF) - Gives an overview of the FpML Messaging Framework.

####

1.2.3 Diagram Notation

Most diagrams in this specification come from TIBCO's XML Turbo application which is used to batch generate the pictures in the documentation. The notation follows the pattern:

- No bubble indicates a mandatory element or attribute
- A '?' indicates an optional element or attribute
- A '*' indicates an occurrence of zero or many
- A '+' indicates an occurrence of one or many
- A '..' bubble with numbers above and below indicates specific range
- A '1' in a bubble indicates the presence of a nested sequence or choice group
- Diagonal lines indicate a choice group (< shape)
- Non-diagonal lines indicate a sequence ([ shape)
- A 'D' in a bubble indicates an attribute with a default value

### 1.3 WORKING GROUP MEMBERS AND ACKNOWLEDGEMENTS

This document was produced by the following working groups:

####

1.3.1 Architecture Working Group

- Andrew Jacobs (HandCoded Software), chair
- Anthony B. Coates (Miley Watts)
- Igor Dayen (Object Centric Solutions)
- Daniel Dui (University College London)
- Marc Gratacos (ISDA)
- Simon Heinrich (IONA Technologies)
- Lyteck Lynhiavu (ISDA)
- Andrew Parry (JP Morgan Chase Bank)
- Raj Patel (HSBC)
- Henri Pegeron (MarkitSERV)
- Matthew Rawlings (JP Morgan Chase Bank)
- John Weir (Goldman Sachs)
- Irina Yermakova (ISDA)

####

1.3.2 Business Process Working Group

- Brian Lynn (Global Electronic Markets), chair
- Aleix Revilla (TradeHeader)
- Andrew Jacobs (HSBC)
- Andy Maynard (State Street)
- Clare Gehrhardt (DTCC)
- Devansh Rastogi (DTCC)
- Dibyendu Majumdar (LCH)
- Harry McAllister (BNPP)
- Henri Pegeron (Sapient)
- Joseph Hlava (DTCC)
- John Booth (MarkitSERV)
- Liz Scott (DTCC)
- Mike Anthony (Bank New York Mellon)
- Niranjana Sharma (CME)
- Shawn Kelly (ARK EDI Solutions)
- Simone Milani-Foglia (LCH)
- Sivagami Gomathinayagam (DTCC)
- Sreedhar Segu (Credit Suisse)
- Sudipto Haldar (Morgan Stanley)
- Venkat Krishnasamy (Tullett Prebon)
- Irina Yermakova (ISDA)
- Lyteck Lynhiavu (ISDA)
- Maithili Koli (ISDA)
- Marc Gratacos (ISDA)

####

1.3.3 Regulatory Reporting Working Group

- Brian Lynn (Global Electronic Markets), chair
- Harry McAllister (BNP Paribas)
- Sreedhar Segu (Credit Suisse)
- Justin Roy (Deutsche Bank)
- Clare Gehrhardt (DTCC)
- Liz Scott (DTCC)
- Joe Hlava (DTCC)
- Devansh Rastogi (DTCC)
- John Booth (MarkitSERV)
- Niranjana Sharma (CME)
- Simone Milani Foglia (LCH Clearnet)
- George Heming (GS)
- Pierre Lamy (GS)
- John Booth (MarkitSERV)
- Jonathan Elliot (MarkitSERV)
- Henri Peregon (Sapient)
- Bryan McRoberts (Bank of America Merrill Lynch)
- Chris Funck (Chatham Financials)
- Steve Turner (J.P. Morgan)
- Ian Salter (J.P. Morgan)
- James Beattie (Message Automation)
- Venkat Krishnan (J.P. Morgan)
- David Kempster (Morgan Stanley)
- Shawn Kelly (ARK EDI Solutions)
- Karel Engelen (ISDA)
- Lyteck Lynhiavu (ISDA)
- Marc Gratacos (ISDA)
- Irina Yermakova (ISDA)
- Maithili Koli(ISDA)

####

1.3.4 Validation Working Group

- Andrew Jacobs (HSBC, HandCoded Software), co-chair
- Daniel Dui (Barclays Capital and UCL), co-chair
- Tony Coates (UBS)
- Andrew Dingwall-Smith (Message Automation)
- Marc Gratacos (ISDA)
- Lyteck Lynhiavu (ISDA)
- Irina Yermakova (ISDA)
- Maithili Koli(ISDA)

####

1.3.5 IRD Products Working Group

- Harry McAllister (BNP Paribas), chair
- John Aldridge (JP Morgan Chase Bank)
- Marc Gratacos (ISDA)
- Robert Green (DTCC)
- Guy Gurden (Swapswire)
- Pierre Lamy (Goldman Sachs)
- Philippe Negri (Sungard)
- Jamie Orme (Goldman Sachs)
- Andrew Parry (JP Morgan Chase Bank)
- Marty Ross-Trevor (Bank of Tokyo-Mitsubishi)
- Marc Teichman (T-Zero)
- Jeff Valentino (Bank of America)
- Irina Yermakova (ISDA)

####

1.3.6 Credit Derivatives Working Group

- Ben Lis (ICE), chair
- Kathy Andrews (Bank of America)
- Milla Bouklieva (Goldman Sachs)
- Karel Engelen (ISDA)
- Piers Evans (SwapsWire)
- Marc Gratacos (ISDA)
- Robert Green (DTCC)
- Guy Gurden (SwapsWire)
- Tony Kao (Goldman Sachs)
- Lyteck Lynhiavu (ISDA)
- Pierre Lamy (Goldman Sachs)
- Anna Lukasiak (Goldman Sachs)
- Andrew Parry (JPMorgan Chase Bank)
- Henri Pegeron (MarkitSERV)
- Mark Perry (Goldman Sachs)
- Marc Teichman (T-Zero)
- Irina Yermakova (ISDA)
- Shel Xu (Goldman Sachs)

####

1.3.7 FX Working Group

- Simone Milani-Foglia (LCH), co-chair
- Marc Gratacos (ISDA)
- Andrew Gregory (HSBC)
- Richard Haslock (Logicscope)
- Andrew Jacobs (HSBC)
- Brian Lynn (GEM)
- Lyteck Lynhiavu (ISDA)
- Harry McAllister (BNP Paribas)
- Michael McKay (DTCC)
- Rick Schumacher (Wall Street Systems)
- Digby Strong (JP Morgan Chase)
- Stephen Turner (JP Morgan Chase)
- Irina Yermakova (ISDA)
- Christina Yeung (Goldman Sachs)
- Vijay Addanky (State Street)

####

1.3.8 Equity Derivatives Working Group

Voting Members

- Andrew Parry (JP Morgan Chase Bank), Chair
- Jasone Brasil (State Street)
- James Clark (MarkItSERV)
- Piers Evans (MarkIt)
- Robert Green (DTCC)
- Guy Gurden (MarkIt)
- Shabbir Irfani (Goldman Sachs)
- Rajan Khorana (Citadel Group)
- Robert Masri (DTCC)
- Coner Mongey
- Bin Shen (Goldman Sachs)
- Marc Teichman (T-Zero)

Non-Voting Members

- Takeo Asakura (MarkItSERV)
- Oluwasegun Bewaji (University of Essex)
- Jim Bonner (ML)
- Tom Brown (Omgeo)
- Jim Brous (Metro Solutions)
- Prashant Choudhary (Cognizant)
- Karel Engelen (ISDA)
- Philip Franz (Bank of America)
- Steve Goswell (Barclays Global)
- Marc Gratacos (ISDA)
- Vinod Jain (Headstrong)
- Lucio Iida (Barclays Global)
- Selma Laidoudi (MarkIt)
- Philip Leach (DTCC)
- Jianan Li (Citadel Group)
- Gaurav Makhija (Citadel Group)
- Mark Parris (UBS)
- Dharmender Rai
- Matthew Rawlings
- Sreedhar Segu (DTCC)
- Alicia Szybillo (DTCC)
- Sam Twum (Blue Tawny)
- Chise Yamamoto (DTCC)
- Irina Yermakova (ISDA)

####

1.3.9 Commodity Derivatives Working Group

- Andrew Jacobs (HSBC), co-chair
- Peter Stockman (DTCC), co-chair
- Andrew Solomon (Morgan Stanley)
- Brian Lynn (GEM)
- Chris Emmett (HSBC)
- Divya Dhakar (Goldman Sachs)
- Fred Litjens (Murex)
- Helen Mahon (Credit Suisse)
- Irina Yermakova (ISDA)
- Jyoti Sahrawat (CME Group)
- Kent Tung(Goldman Sachs)
- Lyteck Lynhiavu (ISDA)
- Marc Gratacos (ISDA)
- Nandini Ravi(Goldman Sachs)
- Nathaniel Jones (DB)
- Ronan Hughes (HSBC)
- Sabrina Ovadya (Goldman Sachs)
- Simon Toop (BNP Paribas)
- Timothy Capuano (Goldman Sachs)
- Timothy Kimber (Barclays Capital)

####

1.3.10 Pricing and Risk Working Group

- Brian Lynn (Global Electronic Markets), chair
- Michael Di Stefano (Integrasoft)
- Amod Dixit (Standard Chartered Bank)
- Marc Gratacos (ISDA)
- Mahmood Hanif (Bank of America)
- Pierre Lamy (Goldman Sachs)
- Philippe Negri (Sungard)
- Henrik Nilsson (TriOptima)
- Robert Stowsky (Progress)
- Vlad Efroimson (Bank of America)
- Irina Yermakova (ISDA)

####

1.3.11 Collateral Working Group

- Richard Barton (Algorithmics), Chair
- Caroline Foran (HSBC)
- Anil Panchal (GlobeOp)
- Kaizad Bhathena (GlobeOp)
- Sammy Lee (GlobeOp)
- Harry McAllister (BNP Paribas)
- Jesse Nolan (UBS)
- Vivian Wu (Goldman Sachs)
- Simone Milani-Foglia (LCH Clearnet)
- Nicole Jolliffe (SWIFT)
- Evelyne Piron (SWIFT)
- Chip Miller (JPMorgan)
- John Straley (DTCC)
- Joe Novellino (DB)
- Lucio Iida (Blackrock)
- Tom Brown (Omgeo)
- Benjamin Riley (Deloitte and Touche)
- Marc Gratacos (ISDA)
- Irina Yermakova (ISDA)
- Lyteck Lynhiavu (ISDA)

### 1.4 FpML INTRODUCTION

The Financial Products Markup Language (FpML) is the industry standard enabling e-business activities in the field of financial derivatives and structured products. The development of the standard, controlled by ISDA (the International Swaps and Derivatives Association), will ultimately allow the electronic integration of a range of services, from electronic trading and confirmations to portfolio specification for risk analysis. All types of over-the-counter (OTC) derivatives will, over time, be incorporated into the standard.

FpML is an application of XML, an internet standard language for describing data shared between computer applications.

### 1.5 REQUESTED FEEDBACK

####

1.5.1 New Regulatory Reporting Views

The FpML Reporting Working Group has defined two new views, "Transparency" and "Recordkeeping", to support parties and execution facilities reporting trading activity into Swaps Data Repositories (SDRs), as required by the Commodities Futures Trading Commission's 17 CFR 43 and 45, and similar requirements from the Securities and Exchange Commission in 17 CFR 240. The FpML Standards Committee invites comments on the proposed materials including schemas, examples, and documentation.

In WD#2, a number of new products have been added to Transparency view. The changes versus Confirmation view have been modeled on other products in WD#1, but the product representations have not yet been reviewed in detail in the working group. The FpML Reporting Working Group invites feedback on the detailed contents in Transparency view of any product.

####

1.5.2 Message Framework/Correlation ID

The FpML Business Process Working Group has adjusted the multiplicity of the correlation IDs and is seeking feedback on this change. In particular, is there a need for multiple correlation IDs if the correlation ID on original requests is made optional?

####

1.5.3 Providing Feedback

Comments on this document should be sent by filling in the form at the following link: http://www.fpml.org/issues.

### 1.6 CHANGES IN THIS VERSION

####

1.6.1 Changes compared to FpML 5.5 Trial Recommendation 2 - build#6

- Business Process:
- The following issues have been resolved:
  - http://www.fpml.org/issues/view.php?id=1080

View PDF for details on schema changes

View PDF for details on validation rules changes

View SCHEME DEFINITIONS for details on coding schemes changes

####

1.6.2 Incompatible changes compared to FpML 5.4 - build#5
- - Generic Product:
    - In Confirmation, Reporting, Recordkeeping and Transparency Views - > fpml-generic.xsd-> "GenericProduct": Removed "dayCountFraction" element. Rationale: The "dayCountFraction" element was moved to the "underlyer" component (placed within "TradeUnderlyer2").Part 43 requires reporting on both the fixed as well as floating leg for the dayCountFraction element. Part 43 requires reporting on both the fixed as well as floating leg for the dayCountFraction element. The Standards committee approved the removal with the assumption that it would not break any critical implementation.
  - CorrelationId:
    - In Confirmation, Reporting, Recordkeeping and Transparency Views - > fpml-msg.xsd - > within "CorrelationId": replaced the base class "xsd:normalizedString" with “Scheme” which restricts the "xsd:normalizedString" to maxLength value="255".
  - Commodity Derivatives:
    - Recordkeeping View –> fpml-com-xsd -> within "SettlementPeriods" complex type: the "startDate" element's status changed from "optional" to "mandatory". Rational:Fix - to prevent the submission of the "endDate" without the "startDate". The change was agreed by the Commodity WG and approved by the Standards Committee (March-11-2013)

####

1.6.3 Changes compared to FpML 5.4 Recommendation

- All Views (except: Pretrade View):
  - Regulatory Reporting:
    - Added several new fields, coding schemes, and examples to support ESMA regulatory reporting, including:
      - party/region field
      - partyTradeInformation/collateralPortfolio identifier field
      - partyTradeInformation/reportingRegime/exceedsClearingThreshold boolean field
      - European regulatory region coding scheme
      - enhanced the ReportingRole coding scheme
      - ESMA organization classification scheme
    - Refactored the Generic Product
      - It includes one incompatible change:
        - In fpml-generic.xsd-> "GenericProduct": Removed "dayCountFraction" element. Rationale: The "dayCountFraction" element was moved to the "underlyer" component (placed within "TradeUnderlyer2").Part 43 requires reporting on both the fixed as well as floating leg for the dayCountFraction element. Part 43 requires reporting on both the fixed as well as floating leg for the dayCountFraction element. The Standards committee approved the removal with the assumption that it would not break any critical implementation.
      - Added support for EMIR in generic product for Commodities, Equities, FX.
  - Clean-up work: Removed orphan types. External URIs corrected.

- FX:
  - Added support for a new fxFlexibleForward product
  - Refactored Fx Option Barrier and Fx Digital Option:
    - Within "FxBarrierFeature" and "FxTouch", added support the MT306 and the ISDA confirmation templates which require the specification of the "observationStartTime" and "observationEndTime for a barrier in terms of the business center and time, in addition to the observationStartDate" and "observationEndDate".
    - Within "FxBarrierFeature" and "FxTouch", added a choice between the above structure and a new element "observationPoint" of a new type "FxBusinessCenterDateTime", a collection of observationPoint elements, with individual observation times.
    - Within "FxOption" -> "FxOptionFeatures" -> "FxBarrierFeature", added a new field "direction" of a new type "FxBarrierDirectionEnum". This specifies whether the barrier direction is "Up" or "Down"; that is, that a barrier event occurs if the spot rate is at or above the trigger rate, or at or below the trigger rate during the period of observation of an american barrier, or at the times of observation of a discrete or european barrier. This change is to comply with Dodd-Frank reporting requirements.
    - Within "FxDigitalOption" -> "FxTouch", added a new field "direction" of type "TriggerConditionEnum". This specifies whether the trigger direction is "AtOrAbove" or "AtOrBelow; that is, that a barrier event occurs if the spot rate is at or above the trigger rate, or at or below the trigger rate during the period of observation of an american trigger, or at the times of observation of a discrete trigger. Note: within "TriggerConditionEnum", values "Above" and "Below" are deprecated. This change is to comply with Dodd-Frank reporting requirements.
    - Within exiting "TriggerConditionEnum" structure (used with FxDigitalOption-> "FxTrigger" and FxTouch), added new values "AtOrAbove" and "AtOrBelow", deprecated existing values "Above" and "Below".
    - Within existing "FxBarrierTypeEnum" structure (used with FxOption-> "FxBarrierFeature"), deprecated values "ReverseKnockin" and "ReverseKnockout".
    - Within "Trade" added support for "barrierDeterminationAgent" - the party referenced is specified in the related Confirmation as Barrier Determination Agent
- Equity Derivatives:
  - Additions based on the trading firms' requirements:
    - Added support for value "Both" (Both parties with joined rights to be a calculation agent) to "CalculationAgentPartyEnum".
    - Refactored "CalculationFromObservation" complex type, to support Initial Level Source in Variance and Correlation Swaps.
    - Updated several coding schemes: localJurisdictionScheme, determinationMethodScheme, instrumentIdScheme
  - Some of the previously agreed on the Standards Committee none-backward compatible changes to FpML 5-3 in Equity Transparency and Recordkeeping view have been reverted by the Standards Committee on April 08, 2013.
- Commodity Derivatives:
  - Added Support for Gold Interest Rate Swap (Official Name: Gold Forward Offered Rate) representation in FpML
  - Added support for ESMA regulatory reporting
    - Border (Gas and Electricity "deliveryConditions/interconnectionPoint").
    - Block Hours (Electricity loadType = BlackHours).
  - Clean-up work: Removed orphan types. Corrected external URIs.
- Interest Rate Derivatives:
  - In Transparency View - > foml-ird.xsd -> "SettlementProvision": added element "settlementCurrency" ofType "Currency" as a mandatory field. Rationale: Requires for regulatory reporting of Non Deliverable Currencies. The Standards committee approved the addition of the "settlementCurrency" on March 11, 2013.
  - Within "Fra": "fixedRate" element's type changed from "xsd:decimal" to "IdentifiedRate". Rationale: Fix.
  - Added support for FRA's fees and additional payments.
- Listed Derivatives Reporting:
  - Added several new components and examples to support ESMA regulatory reporting, including:
    - Added "holding" structure to position/constituent for securities position reporting.
    - Added examples of reporting securities activity and position
    - Added examples of reporting securities market data
  - Added several new components and examples to support regulatory reporting for commodities, including:
    - Added a new Exchange Traded Option asset underlyer and added an example.
    - Updated the Future underlyer and added an example.
- Business Process:
  - Added support for Equity Corporate Action and Basket Change events. Refactored Events.model
  - In Confirmation, Reporting, Recordkeeping, Transparency Views (Incompatible changes) - > fpml-msg.xsd - > within "CorrelationId": replaced the base class "xsd:normalizedString" with “Scheme” which restricts the "xsd:normalizedString" to maxLength value="255".
  - Increase and Termination events: Refactored TradeNotionalChange to correct two modeling issues. The refactoring provides a backward compatible path; a choice between the old structures (TradeNotionalChange.model) and enhanced structures (sizeChange). The sizeChange wrapper relates pairs of elements (e.g., notionalAmount/outstandingNotionalAmount). Using the new model:
    - The reporting of both change of units and change of notional amount is now possible (as required for dividend swaps, for example)
    - Linking notionals with product legs is now possible. An additional optional empty element (e.g., notionalReference) within the sizeChange wrapper links the pair of elements to a specific underlying leg reference using an @href attribute.
    - Within TradeNotionalChange, deprecated change in/outstanding notional, number of options, number of units in favor of a more flexible structure (sizeChange) that allows linking notionals with product legs as well the reporting of both change of units or change of notional amount as required for dividend swaps, for example.
  - LSOC Reporting: Enhanced the requestCollateralAllocation message with a requestedAction element which allows FCMs to specify how the allocations are to be processed (e.g., Update, Reset).
  - Added support for ESMA entity type classification (e.g. Financial, NonFinanacial)in the reportingRegime structure

### 1.7 SCOPE

The scope of FpML 5.5 includes broadened BusinessProcess/Messaging coverage and additional product support, specifically:

####

1.7.1 Architecture Framework

The various Working Groups have developed FpML 5.5 within the FpML Architecture 3.0 Specification defined by the Architecture Working Group. This document defines that standards and principles on which the FpML grammatical definitions are based.

The FpML Architecture 3.0 builds upon the earlier FpML Architecture specifications and the conventions of FpML 1.02b before that. The refinement of the FpML architecture is an evolutionary process bought about by changes in the XML technology upon which it is based and the requirements of the standard as its scope expands.

####

1.7.2 Business Process Scope

The FpML Messaging Task Force group was formed to define a new messaging framework in 5.x that insures consistent processes across trades and post-trade events, observable completion, consistent message correlation, consistent error reporting, consistent correction and retraction.

Most of the FpML 5 business processes are “generic” processes that can apply to new trades and/or any post-trade events. This means that the message name indicates the business process (e.g. confirmation, execution notification, etc.) but not the type of event (e.g. trade, amendment, etc.). The payload of the message indicates the type of the event.

The business processes currently supported in this view include:

##### 1.7.2.1 Generic processes:

##### 1.7.2.1.1 Transparency

- Public execution reporting

##### 1.7.2.2 Generic (Multi-Event) Flows

All the processes described in this section are applied to the following events:

- trade
- novation
- increase
- termination
- amendment
- option exercise / option expiry
- deClear
- basketChange
- corporateAction
- indexChange

To support these business processes, a number of messages have been defined. Please see the "Business Process Architecture" section for more information.

####

1.7.3 IRD Scope

In FpML 5.5 Recommendation the following Interest Rate Derivative products are covered:

- Single and Cross-Currency Interest Rate Swap
- Forward Rate Agreement
- Interest Rate Cap
- Interest Rate Floor
- Interest Rate Swaption (European, Bermuda and American Styles; Cash and Physical Settlement)
- Extendible and Cancelable Interest Rate Swap Provisions

####

1.7.4 Credit Derivatives Scope

In FpML 5.5 Recommendation the following Credit Derivative products are covered:

- Credit Default Swap
- Standard Coupon Credit Default Swap
- Credit Default Swap Index
- Tranche on Credit Default Swap Index
- Credit Default Swap on a Mortgage
- Credit Default Swap on a Loan

####

1.7.5 FX Scope

The Scope of FpML 5.5 Recommendation includes redesigned FX product model developed by the Modeling Task Force (MTF) and FX Working Group to make it more consistent with other FpML product representations and to facilitate its further development. As a result of this work many of an original 4.x model’s issues were addressed:

- A number of sets of reusable components that facilitates product development were defined, so that the existing and future FX products will leverage these building blocks to ensure the FX model is coherent and easy to maintain, as per FpML best practices
- Extended the existing coverage to include Dual Currency Deposits and FX Flexible Forward.
- Rationalized the models' constraints:
  - Made use of grammar to bring related data together.
  - Made better use of XML schema to simplify the validation rules.

In FpML 5.5 Recommendation the following FX products are covered:

- Basic FX Products
  - FX Spot, FX Forward (including non-deliverable settlements, or NDFs) and FX Flexible Forward.
  - FX Swap
- Simple FX Option Products (including, features, cash and physical settlement)
  - FX options
    - European and American

####

1.7.6 Return Swaps Scope

FpML provides generic Return Swaps support including "long form" Equity Swap representations, as well as Total Return Swaps. A separate product element called equitySwapTransactionSupplement supports "short form" Equity Swap Transaction Supplement.

Return-type Swaps have 1-to-many Legs, all of which must be derived from the ReturnSwapLeg type. Instances of Legs are returnLeg, interestLeg. Other Leg types may be derived from ReturnSwapLeg at will, to allow for private extensions to support whatever type of Generic Return Swap is desired.

The scope of this FpML representation for return swaps is to capture the following types of swaps that have equity-related underlyers:

- Single stock swaps as well as basket swaps (i.e. swaps with multiple underlyers);
- Swaps that have a different types of underlying assets (equity, index, mutual funds, exchange-traded funds, convertible bond, futures), or a combination of these;
- 2-legged swaps with a combination of an equity leg and a funding leg, as well as swaps that either have only one leg (e.g. fully funded or zero-strike swap) or multiple equity legs (e.g. outperformance swaps);
- Total Return Swaps, a type of swap in which one party (total return payer) transfers the total economic performance of a reference obligation to the other party (total return receiver).

####

1.7.7 Variance Derivatives Scope

The Equity Derivative Working Group extended FpML to cover:

- Variance Swaps, a type of volatility swap where the payout is linear to variance rather than volatility, therefore the payout will rise at a higher rate than volatility;
- Short Form Variance Options represented also as Transaction Supplements under ISDA Master Confirmation Agreements.

####

1.7.8 Commodity Derivative Product Scope

The Commodities Working Group will extend the FpML standard to include trade types and products for the OTC commodities markets, following the structure and coverage of the 2005 ISDA Commodity Definitions. The following are included in version 5-5:

- Support for financially settled swaps, options and spreads
- Support for physically-settled swaps/forwards, options
- Natural Gas, Oil, Electricity, Coal, Metal, Environmental as the underlying Commodity product
- Gold Interest Rate Swap (Official Name: Gold Forward Offered Rate)

Business Process is including Confirmations, Valuations, Reporting

### 1.8 CHARACTER ENCODING AND CHARACTER REPERTOIRE

####

1.8.1 Character Encoding

Producers of FpML documents intended for interchange with other parties must encode such documents using either UTF-8 or UTF-16. Consumers of FpML documents must be able to process documents encoded using UTF-8, as well as documents encoded using UTF-16. For more information, see

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

####

1.8.2 Character Repertoire

Unrestricted FpML elements may use any valid XML characters. For more information, see

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

Certain elements and attributes (such as scheme URIs) are defined with more restrictive types, such as xsd:normalizedString, xsd:token, or xsd:anyURI. For these types, please see the relevant data type definition in the XML Schema datatypes specification:

http://www.w3.org/TR/xmlschema-2/

### 1.9 TOOLS AND VALIDATION

####

1.9.1 Schema and Example Validation

The schema files and examples in this document have been validated with XercesJ (v.2.2.1 and v.2.6.2) and HandCoded's Toolkit for FpML Processing (version Java 1.1 Alpha 2).

## 2 FpML OVERVIEW

### 2.1 FpML

FpML is designed based on a number of key principles and conventions. Some of these include:

- Use XML's structuring ability to create reusable building blocks.
- Follow naming and structuring conventions to create a more consistent XML appearance.
- Where possible, share definitions across products and asset classes.
- Minimize evolution in instance documents from version to version.

Although these basic principles have consistently been observed, over the life of the specification there has been some evolution in the details, and as a result there have been some changes in the appearance of FpML. A number of these changes have been introduced to take advantage of the power created by XML schema. The original version of the FpML Architecture is located at FpML Architecture 1.0. The latest version of the FpML architecture principles is described in detail in the FpML Architecture 3.0. That document discusses how to create and extend FpML definitions.

The remainder of this section is intended to describe how the architecture principles were applied in developing FpML, and how to use the resulting spec. Please see the end of this section for a fuller explanation of the motivation for the FpML design approach.

### 2.2 Overview of FpML views

With FpML 5-5 , FpML has been divided into several very closely related schemas to better support different types of business processes. Each of these schemas, called a "view", has a distinct namespace and element and type definitions. However, each view is built from the same source schema, and so shares a number of features, such as element names.

The following features are the SAME across all views:

- Element names
- Type names
- Product names
- Available product features, and the representation of those features
- The FpML version

The following features are DIFFERENT in different views:

- The intended usage of the standard, i.e. the types of business processes that it will be used for
- The list of available business processes and messages
- The "cardinality" of elements within a product or message (i.e. whether they are mandatory or optional)
- The exact list of supported products (may differ from view to view)
- The namespace
- The list of non-product features that are supported

In FpML 5-5, the list of supported views includes:

- Pre-trade: Currently, this view coveres pre-trade CDS and IRS product descriptions and Credit Limit Check messages to support Clearing Certainty work flows.
- Reporting: This view is intended to be used for reporting trading and business activities and positions (including as part of STP flows), as well as processes such as reconciliation. This view has a moderately loose product representation; it requires key economic information such as the notional, key dates, and parties, but leaves other information optional.
- Confirmation: This view is intended to be used for confirming the precise details of contracts and post-trade business events. This view is intended to have similar charactistics to the FpML versions 1-4 product representation, i.e. a very detailed product representation capturing the details needed for a transaction confirmation.
- Recordkeeping: This view is intended to be used for reporting the Primary Economic Terms of derivative transactions to Swaps Data Repositories from entities including market participants, execution platforms, and clearing or confirmation services. This view is intended to have similar charactistics to the FpML "confirmation view" product representation, i.e. a very detailed product representation capturing the details needed for a transaction valuation; it may not include all docmentaiton and legal terms.
- Transparency: This view is intended to be used for reporting price forming information about executed transactions to the public by reporting parties and execution platforms. This view is intended to provide only the key product econommics that are appropriate for standardized transctions, and not customizations and detailed information not required for price discovery, for example details of date adjustment rules and the like. Many elements are suppressed from Transparency view. These are suppressed for a number of reasons, which are documented using a "rationale" in the master scheme. Rationales include:
  - DateAdjustments - Date adjustments and other similar date calculations re out of scope of transparency view because they are typically fairly standardized and have minimal effect on the price of the product.
  - Standardized - Generally standard (default) values for this field apply for a standard product - products with other values are "nonstandard" and these out of scope of transparency view.
  - NonStandardFeature - This element represents a specialized feature of a non-standard product and should not occur in a non-customized product.
  - Unsupported - This product is unsupported in Transparency view.
  - Technical - Skipped for technical reasons (e.g. as part of a choice block). (Normally these elements are available by using a different element of the choice; they are omitted because if they are present the cause parsing non-determinism errors.)
  - Documentation - This is a documentation detail, not strongly price affecting, and so is omitted from Transparency view.
  - PartySpecific - This is party-specific or proprietary information, and so is omitted from Transparency view.

The following diagram shows the relationship of some of these views for Dodd-Frank reporting:

The rationale for the concept of "views" is to provide a consistent representation of key information across many types of business process, while allowing the set of mandatory and optional data to vary between processes. For example, when a firm reporting on an interest rate swap it may not provide information such as: payment date and reset date definitions on the floating side, or the business day adjustments that were used, etc. However, all of these pieces of information are crucial for confirming that swap once it is traded. So for confirmation view we want these pieces of information to be mandatory, while they are optional for pre-trade view.

A present, the concept of views is implemented as follows:

- A single "master" schema is maintained for all views
- This master schema includes a number of annotations using a simple syntax for overriding specific items (typically cardinalities) for a specific view.
- The published schema for each view is generated using an XSLT processing script from the master schema.
- ISDA publishes a separate schema and set of examples for each view.

In the reporting view, a firm reporting on an interest rate swap may provide the following elements:

- Streams for both the fixed and floating sides.
- Streams for both the fixed and floating sides.
- The absolute effective and termination dates.
- The payer and receiver party references for both sides.
- Calculation frequencies for both sides.
- The notional that was traded.
- The day count fraction on each stream.

Thus, the FpML for reporting on a 5-year USD-LIBOR-3M swap may look something as follows:

    		<swap>
    			<productType>InterestRateSwap</productType>
    				<assetClass>InterestRates</assetClass>
    					<swapStream>
    						<payerPartyReference href="hedge_global"/>
    						<calculationPeriodDates id="floatingCalcPeriodDates">
    							<effectiveDate>
    								<adjustedDate>2009-08-04Z</adjustedDate>
    							</effectiveDate>
    							<terminationDate>
    								<adjustedDate>2021-03-01Z</adjustedDate>
    							</terminationDate>
    						</calculationPeriodDates>
    						<calculationPeriodAmount>
    							<calculation>
    								<notionalSchedule>
    									<notionalStepSchedule>
    										<initialValue>623161.01</initialValue>
    										<step>
    											<stepDate>2009-09-01</stepDate>
    											<stepValue>617840.01</stepValue>
    										</step>
    										<!-- .... intermediate values removed -->
    										<step>
    											<stepDate>2021-01-01</stepDate>
    											<stepValue>9792.01</stepValue>
    										</step>
    										<step>
    											<stepDate>2021-02-01</stepDate>
    											<stepValue>5486.01</stepValue>
    										</step>
    										<currency>USD</currency>
    									</notionalStepSchedule>
    								</notionalSchedule>
    								<floatingRateCalculation>
    									<floatingRateIndex>USD-LIBOR-BBA</floatingRateIndex>
    									<indexTenor>
    										<periodMultiplier>1</periodMultiplier>
    										<period>M</period>
    									</indexTenor>
    									<spreadSchedule>
    										<initialValue>3.40</initialValue>
    									</spreadSchedule>
    								</floatingRateCalculation>
    								<dayCountFraction>ACT/360</dayCountFraction>
    							</calculation>
    						</calculationPeriodAmount>
    					</swapStream>
    					<swapStream>
    						<receiverPartyReference href="hedge_global"/>
    						<calculationPeriodAmount>
    						<calculation>
    						<notionalSchedule>
    							<notionalStepSchedule>
    								<initialValue>623161.01</initialValue>
    								<step>
    									<stepDate>2009-09-01</stepDate>
    									<stepValue>617840.01</stepValue>
    								</step>
    								<!-- .... intermediate values removed -->
    								<step>
    									<stepDate>2021-01-01</stepDate>
    									<stepValue>9792.01</stepValue>
    								</step>
    								<step>
    									<stepDate>2021-02-01</stepDate>
    									<stepValue>5486.01</stepValue>
    								</step>
    								<currency>USD</currency>
    							</notionalStepSchedule>
    						</notionalSchedule>
    						<fixedRateSchedule>
    							<initialValue>0.0711</initialValue>
    						</fixedRateSchedule>
    						<dayCountFraction>ACT/360</dayCountFraction>
    					</calculation>
    				</calculationPeriodAmount>
    			</swapStream>
    		</swap>

In confirmation view, a firm confirming a swap would include, in addition to the above, the following elements:

- Date adjustments.
- Payment date definitions.
- Reset date definitions on the floating side.

### 2.3 Overview of the organization of the master schema

FpML is divided into several sub-schema files, which organize the definitions into smaller and more maintainable building blocks. These building blocks include:

- Core Definitions:
  - All Views
    - fpml-main-5-5.xsd - Root definitions.
    - fpml-doc-5-5.xsd - Trade definitions and definitions relating to validation.
    - fpml-shared-5-5.xsd - Shared definitions used widely throughout the specification. These include items such as base types, shared financial structures, etc.
    - fpml-enum-5-5.xsd - Shared enumeration definitions. These definitions list the values that enumerated types may take.
    - fpml-asset-5-5.xsd - Underlyer definitions plus some types used by them (e.g. ones relating to commissions or dividend payouts).
- Products:
  - All Views
    - IRD
      - fpml-ird-5-5.xsd - Interest rate derivative product definitions.
    - CD
      - fpml-cd-5-5.xsd - Credit derivative product definitions.
  - Confirmation, Reporting, Record-keeping, Transparency Views
    - FX
      - fpml-fx-5-5.xsd - Foreign exchange product definitions.
    - EQD
      - fpml-eq-shared-5-5.xsd - Definitions shared by types with Equity Underlyers.
      - fpml-eqd-5-5.xsd - Equity Option and Equity Forward Product Definitions.
      - fpml-return-swaps-5-5.xsd - Return Swaps Product Definitions.
      - fpml-variance-swaps-5-5.xsd - Variance Swap and Variance Option Product Definitions.
      - fpml-correlation-swap-5-5.xsd - Correlation Swap Product Definitions.
      - fpml-dividend-swap-5-5.xsd - Dividend Swap Product Definitions.
    - Bond Options
      - fpml-bond-option-5-5.xsd - Bond and Convertible Bond Options Product Definitions.
    - Options shared
      - fpml-option-shared-5-5.xsd - Shared option definitions used for defining the common features of options.
    - Commodity
      - fpml-com-5-5.xsd - Commodity Swap and Commodity Option Derivative Poduct Definitions.
    - Cross-Asset Class Products
      - fpml-doc-5-5.xsd - strategy - combination of existing products.
      - fpml-doc-5-5.xsd - instrumentTradeDetails-No Annotation Available
      - fpml-standard-5-5.xsd - Standard Product elements and types Definitions. standardProduct-Standard products - for use in Transparency reporting to define a product that represents a standardized OTC derivative transaction whose economics do not need to be fully described using an FpML schema because they are implied by the product ID. In other views, standard products are present for convenience to support internal messaging and workflows that are cross-product. Standard products are not full trade representations as such they are not intended to be used for confirming trades.
      - fpml-generic-5-5.xsd - Generic Product elements and types Definitions. genericProduct-Generic products - for use in Transparency reporting to define a product that represents an OTC derivative transaction whose economics are not fully described using an FpML schema. In other views, generic products are present for convenience to support internal messaging and workflows that are cross-product. Generic products are not full trade representations as such they are not intended to be used for confirming trades.
- Business Processes:
  - All Views
    - fpml-msg-5-5.xsd - Definitions related to messaging and workflow.
    - fpml-business-events-5-5.xsd - Business event notification components, such as creation of a trade, amendment, increase, termination and novation.
  - Pre-Trade View
    - fpml-msg-5-5.xsd - Definitions related to messaging and workflow.
    - fpml-pretrade-processes-5-5.xsd - Definitions of pre-trade Credit Limit Check messaging components to support Clearing Certainty work flows.
    - fpml-business-events-5-5.xsd - Business event notification components, such as creation of a trade, amendment, increase, termination and novation.
  - Confirmation View
    - fpml-confirmation-processes-5-5.xsd - Definitions of trade and post-trade messaging components such as execution, execution advice, trade change, consent negotiation, confirmation, clearing and allocation.
    - fpml-credit-event-notification-5-5.xsd - Credit event notification components
  - Record-keeping View
    - fpml-recordkeeping-processes-5-5.xsd - Definitions for non-public execution reporting, used to report transaction records to SDRs.
  - Transparency View
    - fpml-transparency-processes-5-5.xsd - Definitions for public price discovery reporting, for reporting from market participants and execution platforms to the public via SDRs or third party message distribution services.
  - Reporting View
    - fpml-reconciliation-5-5.xsd - Cash flow matching and portfolio reconciliation messaging components
    - fpml-reporting-5-5.xsd - Definitions of reporting messaging components such as position activity report , event activity report and reset report.
    - fpml-credit-event-notification-5-5.xsd - Credit event notification components
    - Pricing and Risk:
      - fpml-valuation-5-5.xsd – Valuation result sets and related definitions.
      - fpml-mktenv-5-5.xsd – Definitions of market environment data structures such as yield curves, volatility matrices, and the like.
      - fpml-riskdef-5-5.xsd – Definitions of valuation and sensitivity results. They include detailed definitions of sensitivity calculations and are intended to be used by sophisticated users.
    - fpml-collateral-processes-5-5.xsd - Collateral messaging components

### 2.4 Overview of Document Types

An FpML document can be either of two categories:

- A DataDocument is a document that contains only data, such as trades, parties, and portfolios. This structure is very similar to an FpML version 3 and 4 document. The DataDocument type is provided for those who do not wish to use FpML messaging features.
- A Message is a document that contains a message header and data elements specific to that message. In fact, an FpML message will always be of a more specific type derived from Message, such as "RequestTradeStatus". To learn more about FpML messaging, please see the Business Process section of this specification.

The following documents give a general overview of what is covered in FpML Data Documents and FpML Messages:

- FpML Products Framework (PDF) - Gives an overview of all the financial products covered in FpML and their interrelationships.
- FpML Messaging Framework (PDF) - Gives an overview of the FpML Messaging Framework.

### 2.5 Using FpML

Before beginning to use FpML, an architect must answer several questions:

- How will the FpML be used? Is it primarily a messaging application, or primarily a data storage and retrieval application?
- If it is a messaging application, is there an existing workflow format that is used to coordinate interactions between the entities exchanging messages, or is a new one required?
- Will the FpML be used within a single institution, or across a number of institutions?
- What asset classes of products will be required?
- Will there need to be local data or product extensions?
- Are there any other XML schemas or DTDs the FpML needs to interact with?

If the application requires a new messaging layer, particularly if it will be used between institutions, the FpML messaging layer is recommended. If the application is primarily a data storage and retrieval application, the DataDocument type is available. For example, to store trades in an XML trade archive, and then retrieve them for a display or to generate, say, a confirmation, the DataDocument format will likely be sufficient. To implement a trade matching service between institutions, you should use the messaging layer.

### 2.6 The FpML root element

In FpML 5.0, there is a different root element for each different message or document type. For example, a message to request that a novation be confirmed begins "<requestNovationConfirmation> ...", while a Data Document begins "<dataDocument> ...". Each different root element defines a structure that corresponds to the business requirements of that message or document.

The following short example illustrates this, using a "Request Confirmation" message from the confirmation view:

    <requestConfirmation
    	fpmlVersion="5-5"
    	xmlns="http://www.fpml.org/FpML-5/confirmation"
    	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    	xsi:schemaLocation="http://www.fpml.org/FpML-5/confirmation ../../fpml-main-5-5.xsd">
      <header>
        <messageId messageIdScheme="http://www.fpml.org/msg-id">123</messageId>
        <sentBy>PARTYABICXXX</sentBy>
        <sendTo>PARTYBBICXXX</sendTo>
        <creationTimestamp>2013-07-02T16:38:00Z</creationTimestamp>
      </header>
      <trade>
      <!-- trade details omitted -->
    	  <creditDefaultSwap>
    	    <!-- product details omitted -->
    	  </creditDefaultSwap>
      </trade>
    </requestConfirmation>

The simplest FpML document is a "DataDocument" (root='dataDocument'). This is similar to an FpML 3.0 document, and is described in the next section.

The FpML root element contains attributes that specify the FpML version (fpmlVersion='5-5' for FpML 5.5), the schema name and location, the namespace, and related properties. The "version" attribute from previous FpML versions has been renamed to "fpmlVersion" to provide an unambiguous indicator of the beginning of the FpML document that is not reliant on namespaces. Each different view has a different namespace. See the Architecture 3.0 specification for more details on this.

### 2.7 Annotations

Since version 4.3, the FpML Schema has included a set of eCore annotations. These annotations improve the existing model by providing additional information that W3C Schema is not able to represent.

####

2.7.1 eCore

eCore is part of the Eclipse Modelling Framework. This is the modelling technology Eclipse based on a subset of UML.

eCore annotations add back the model information missing from XML Schema, specifically:

- The type of IDREFs
- Canonical namespace prefix
- Package names
- Root documents

In terms of implementation, the FpML Schema root element includes these additional attributes:

- the eCore namespace: xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
- the canonical namespace prefix: ecore:nsPrefix="fpml"
- the package name: ecore:package="org.fpml"
- the root element: ecore:documentRoot="FpML"

In addition, the ecore annotations specify the specific target of an href attribute:

    <xsd:complexType name="AccountReference">
    	<xsd:annotation>
    		<xsd:documentation xml:lang="en">Reference to an account.</xsd:documentation>
    	</xsd:annotation>
    	<xsd:attribute name="href" type="xsd:IDREF" use="required" ecore:reference="Account"/>
    </xsd:complexType>

Benefits of eCore annotations include:

- FpML controls the object oriented models built from FpML
- The same OO model is shared, which is good for interoperability
- Modelling use now work with FpML
- Developers who can't unerstand XML Schema, can understand UML
- The FpML Schema is still valid and XML Schema tools are unaffected

More details about eCore annotations are available at: http://www.eclipse.org/modeling/emf/docs/overviews/XMLSchemaToEcoreMapping.pdf

### 2.8 Main Components

There are a set of elements in FpML that are used across the different message types. These include elements such as trades, portfolios, events and parties.

####

2.8.1 The DataDocument type

As mentioned above, the structure of the FpML document depends on the "type" attribute. The simplest FpML document is a "DataDocument", which is similar to an FpML 3.0 document. The DataDocument is used to represent static data. A DataDocument looks like this:

It contains:

- Optional validation rules identification
- A trade or trades
- A portfolio or portfolios. Portfolios contain only trade references, if the trades themselves need to be included in the document then the trades can be included within the root element.
- An event or events
- A party or parties

Since the introduction of event in FpML 4.1, the content of "DataDocument" was constraint using "xsd:choice" to reduce the number of permutations between the different elements.

####

2.8.2 The Trade Component

The trade is typically a top-level component within an FpML root element. A trade is an agreement between two parties to enter into a financial contract and the trade component in FpML contains the information necessary to execute and confirm that trade. The trade includes a trade header, economic details (enhanced from version 5.2 to allow non-OTC products to be represented), and other legal, operational, and documentation terms.

##### 2.8.2.1 tradeHeader

The information within tradeHeader is common across all types of trade regardless of product. In FpML 5.5 this element contains the trade date and party trade identifiers, as well as party-specific trade information.

##### 2.8.2.1.1 Primary Trade Identifier

In FpML, there is no notion of primary trade or contract identifier. Trade identification is meaningful within the context of a party. That’s why the partyTradeIdentifier structure contains a partyReference element referencing a party. Within the structure, multiple tradeId or versionedTradeId elements can be specified. This is useful for allowing organizations with multiple systems, each one of them generating one or multiple trade identifiers, to be able to record that in the FpML message. Each system is identified by a unique value in the tradeIdScheme attribute.

    <partyTradeIdentifier>
    	<partyReference href="INVM1"/>
      	<versionedTradeId>
    		<tradetId contractIdScheme="http://www.investmentmgm.com/coding-scheme/trade-id">CDI290204</tradetId>
            		<version>1</version>
        	</versionedTradetId>
        	<versionedTradeId>
            		<tradeId tradeIdScheme=”valuation-system/trade-id”>VS3456332</tradeId>
            		<version>1</version>
    	</versionedTradeId>
    </partyTradeIdentifier>

In order to be able to process trade identification information, in absense of a central system, participants should decide on how to store the identification information of the trade:

- Recipients may choose to process all trade identifers and sources sent in a message and their relationship so in subsequent messages, the sender may send only one of the previous identifiers and the recipient may still be able to identify the trade.
- Recipients may choose to process a single trade identifier. In that case, participants must agree which system source is relevant, and ignore the others. Participants must exchange the tradeIdScheme values that are going to be relevant for processing. In the example above, the recipient may keep the trade id of ‘http://www.investmentmgm.com/coding-scheme/trade-id’ and ignore the other trade id.

##### 2.8.2.1.2 Trade Information

FpML allows a number of pieces of additional information to be recorded about how the trade was executed and for what purposes. This is contained in tradeInformation. The specifics of this type may alter depending on the view.

##### 2.8.2.2 product

Product is an abstract concept in FpML and an actual product element is not used. Instead, one of the FpML products will appear directly under trade. From version 5.2, instead of an OTC product it is possible to represent the basic details of a trade of a multiply-traded instrument such as a security; this is provided to allow reporting on non-OTC trades that result from OTC trading activity, for example physical settlements of OTC options on securities.

All FpML products inherit two optional elements from the Product type: productType and productId.

##### 2.8.2.2.1 Product Identification

In order to identify the type of product contained within an FpML message, the Standards Committee encourages the use of structural analysis. Structural analysis is based on checking the presence of some specific elements within the message instead of relying on the value of a specific element such as productType.

The presence of some specific elements helps to define the product category of the transaction that is being sent. For example, the presence of the creditDefaultSwap and referenceInformation elements in a message is critical to categorize the product as single name credit default swap.

Product categorization using only the productType element value should be avoided. It should only be used by internal messaging implementations or by service providers. In both cases the code list is well-controlled and commonly understood by all participants.

####

2.8.3 The Party Component

The party component holds information about a party in involved any of the trades or portfolios included in the document. Parties can perform multiple roles in a trade lifecycle. For example, the principal parties obligated to make payments from time to time during the term of the trade, but may include other parties involved in, or incidental to, the trade, such as parties acting in the role of novation transferor/transferee, broker, calculation agent, etc. In FpML roles are defined in multiple places within a document.

It should be noted that an FpML document is not 'written' from the perspective of one particular party, i.e. it is symmetrical with respect to the principal parties. The particular role that a party plays in the trade, e.g. buyer, seller, stream payer/receiver, fee payer/receiver, is modeled via the use of references from the component where the role is identified (relatedParty structure) to the party component.

This is a description of the elements:

- partyId: A party identifier, e.g. a S.W.I.F.T. bank identifier code (BIC).
- partyName: The name of the party. A free format string. FpML does not define usage rules for this element.

Example:

                        ...
    	<party id="SKY">
    		<partyId partyIdScheme="http://www.sky.org/coding-schem/code-id">SkyLTD</partyId>
    		<partyName>Sky Limited</partyName>
    	</party>
                        ...

####

2.8.4 The Product Component

The product component specifies the financial instrument being traded. This component captures the economic details of the trade. It is modeled as a substitution group; each asset class may create one or more product definitions. Some examples of products that different working groups have defined include:

- Interest rate swaps
- FRAs
- caps/floors
- swaptions
- FX spot/forwards
- FX swaps
- FX options
- Equity options
- Equity swaps
- Equity forwards
- Commodity swaps
- Commodity options
- Correlation swap
- Credit default swaps
- Dividend swap
- Variance swap
- Variance option

### 2.9 More Background on FpML's Design

This section provides some additional background on the design of FpML.

####

2.9.1 Rationale for Structured Approach

FpML incorporates a significant level of structure, rather than being a 'flat' representation of data. This structuring is achieved through the grouping of related elements describing particular features of a trade into components. Components can both contain, and be contained by, other components.

An alternative approach would have been to collect all the required elements in a single large component representing a product or trade. A flat structure of this kind would capture all the relevant information concisely but would also constrain the model in two important respects, namely, ease of implementation and extensibility.

Grouping related elements into components makes it easier to validate that the model is correct, that it is complete and that it doesn't contain redundancy. This is true, both from the perspective of readability to the human eye, and also from the perspective of processing services. Processing services that do not need all the information in a trade definition can isolate components and be sure that the complete set of elements required, and only the elements required, is available for the particular process in hand.

Components additionally serve as the building blocks for a flexible and extensible model. Generally speaking, the complexity of financial products is a result of combining a few simple ideas in a variety of different ways. The component structure supports a trade content definition that is flexible enough to represent the wide variation of features found in traded financial instruments.

It should be noted that the application of the guiding principles of extensibility and ease of use has resulted in a different approach with regard to the forward rate agreement. Because this product is straightforward, commoditized and unlikely to develop further, the advantage to be gained from the extensive use of components is outweighed by the concision of a single component.

####

2.9.2 Component Framework

The optimum level of granularity is important to FpML. FpML separates the elements which collectively describe a feature of a product or trade into a separate component with each component serving a particular semantic purpose. Every grouping of elements in FpML is regarded as a component and each component is regarded as a container for the elements that describe that component. In the majority of cases each component will contain a mixture of other components and primitive elements, e.g. a date or string, that collectively describe the features of the component. Components are typically represented in the FpML schema as Complex Types.

Generally speaking, the lower level a component is, the more re-usable it will be. FpML makes use of a number of primitive entity components that describe the basic building blocks of financial products, for example, FpML_Money, FpML_AdjustableDate, FpML_BusinessCenters, FpML_Interval, FpML_BusinessDayAdjustments etc. These primitive components are re-used in different business contexts.

Primitive components are contained in higher level components that describe the features of particular products. For this reason these higher level components will tend not to be re-usable to the same extent. Examples within the definition of swapStream are the components required to construct schedules of dates such as calculationPeriodDates, resetDates and paymentDates. However, it should not be inferred from this that any fundamental distinction is drawn between components in usage or structure.

####

2.9.3 Coding Schemes

A necessary feature of a portable data standard is both an agreed set of elements and an agreed set of permissible values (the value domain) for those elements. An FpML document exchanged between two parties would not be mutually understandable if either or both of the parties used internal or proprietary coding schemes to populate elements. For FpML 4.0 the handling of coding schemes was changed from previous versions of FpML, with the introduction of the use of enumerations and the elimination of scheme default attributes from the FpML root element. The following description refers to the updated approach.

One possible means of identifying value domains is to include the domain of permitted values within the schema, using an XML Schema enumeration structure. This mechanism was adopted in FpML 4.0 for element values that satisfy the following criteria:

- The list of allowable values is relatively short.
- The list of allowable values is not expected to change during the lifetime of the specification
- It's not possible to change the list of allowable values without affecting the meaning of the specification.

This leave a number of lists of values not meeting the above criteria that are represented by "schemes". "Schemes" are lists of values that can be changed dynamically without affecting the schema. They include items such as currency codes, party identifiers, business calendar locations, floating rate indexes, etc. For these data elements, the "scheme" is a URI, as identified in an FpML attribute, that designates the universe of acceptable values the element may take. This scheme definition list is typically encoded as an XML document, but does not in general need to be. In cases where the ISDA wishes to designate a default scheme, this is recorded as a default attribute value in the schema. In other cases, the scheme attribute is required.

For further details on the architectural framework behind Schemes, refer to the FpML Architecture Version 1.0 and Version 2.0 documents.

## 3 BUSINESS PROCESS ARCHITECTURE

### 3.1 Introduction

The FpML 4.0 Schema was the first release of the specification to place a messaging framework around the product descriptions to describe the context and use to which the information is expected to be put. This section describes a small set of complex types and elements that comprise a simple message framework that is used as the basis for defining business messages and processes suitable for use in a communications process.

These definitions introduce a new set of ideas that previously could not be used in FpML because of its reliance on DTDs as the formal specification of the grammar. The following sections describe the reasoning behind the features used in the framework as well as a description of several business processes.

####

3.1.1 Why Business Messaging?

Increased efficiency in financial markets can only be achieved through greater automation of transaction processing and use of electronic messaging (e.g. the exchange of information directly between computer systems with as little human interaction as possible). In order to achieve this all the parties involved in such communications must agree on four things, namely:

- Representation

  There must be a common representation of a transaction, product or other reference data item that is accepted by all the parties.

  The core FpML grammar defines a standard vocabulary for derivative based transactions and products that can form the basis of a messaging standard. As new messaging applications are considered the scope of the core grammar will need to expand to encompass the additional types of data referenced in these messages.

- Semantics

  All the parties must have the same interpretation of the information expressed by the representation.

  The work of the validation working group provides a set of rules to ensure that a product definition conforms to the market definition for that product. The FpML rule set will expand and evolve over time as new financial products and message types are added to the grammar.

- Business Process

  All the parties must follow the same business processes and respond appropriately to any communication they receive.

  To support the consistency across different business processes and views, the Messaging Task Force defined a new messaging framework that extended the core grammar. This section describes some business processes and shows how they could be implemented as message exchanges. This section describes some business processes and shows how they could be implemented as message exchanges.

- Transport

  The parties must agree on the communications transport used to interconnect their businesses.

  FpML does not endorse any particular messaging transport for communication. The choice of transport is left to the implementer although in practice we expect only a few to be found suitable.

Disagreement over the first three of these features will mean that FpML users will potentially have to implement, maintain and support different software systems for each FpML aware service or application that they use. Supporting multiple communications transports is typically not that difficult although it does incur additional operations costs.

### 3.2 The Messaging Framework

####

3.2.1 Introduction

FpML 5 introduces a new messaging framework to address limitations in the version 4 framework.

This new framework does the following:

- it consistently implements a set of general principles to make it easier to use the messages to implement real business processes

- it adjusts the representation of parties, accounts, and roles to clarify the purpose of messages and the roles of the parties within a message.

The following section describes the new messaging framework.

####

3.2.2 Issues in FpML 4 Messaging Framework

Following are some of the issues in the FpML messaging framework that the version 5 framework seeks to correct:

- Incomplete message set – in many cases not all messages required to implement a business process are defined in the FpML 4 message set. In particular, many requests lack acknowledgements, exception responses, correction capabilities, and in some cases normal responses. Many generic business processes (such as confirmation) have different levels of completeness depending on the specific event that is being covered.

- Inconsistent message correlation – different implementations use different features of the FpML 4 framework to link successive messages together, making them incompatible.

- Unclear processes – it is not always clear how the version 4 messages are to be combined together to fully implement a business process. For example, which message should be used to acknowledge or respond to a request isn’t always defined. While this could in theory be addressed through documentation, because the message set is incomplete, this is difficult to do.

####

3.2.3 Design Assumptions

In order to create the messages and business processes described in this document some design assumptions had to be made, principally:

##### 3.2.3.1 Highly Assured Transport

- Throughout this document we have assumed that message exchanges will be carried by a passing of messages over a highly assured transport, such is provided by a messaging queuing system. This form of transport is commonly used today in the finance industry (e.g. AMQP, Apache QPid, FIX engines, MQSeries, MSMQ, RabbitMQ, SwiftNet Interact 'Store and Forward', etc.).

  One important consequence of this decision is that error cases related to non-delivery do not have to be considered (e.g. once accepted a guaranteed messaging queuing system WILL ALWAYS deliver a message) although the 'freshness' of the message may need to be considered (e.g. has the message been stuck in a queue waiting to be delivered for a long period of time). Similarly message queuing system can normally eliminate duplicate messages so these are not considered either.

##### 3.2.3.2 No Preservation of Message Sequence

- There is no requirement for message sequence to be preserved over the message transport. Message sequence must not be expected to be repeatable nor predictable.

  In practise enterprise message buses cannot be expected to halt the enterprise to preserve sequence. Hence this is not a requirement of FpML.

##### 3.2.3.3 Long-Running Processes

- Some of the business processes are 'long-running' in that once initiated they may remain active for a considerable time before completing (e.g. a request to confirm a trade may take many hours as it is dependent on the time of arrival of the matching trade). During this time the process may generate periodic notifications to the originator of the request and/or other parties. Such notifications will appear in the message stream set to a participant intermixed between other response messages.

  An implication of such 'long-running' transactions is that the 'service provider' will contain a complex 'state'. The service should make suitable provisions to persistently record its state so that in the event of a software or hardware failure it can recover transparently without its clients having to resend any information.

##### 3.2.3.4 Observable Completion

- Principle: All requests should result in an "observable completion", that is a clear (observable by the requester) response.

- Implementation: For each request or notification message there should be at least one defined acknowledgement message. In the case where the response to the request might be delayed pending additional information, the recipient of the request should acknowledge the request. [Should we set a guideline here? E.g. acknowledge if resulting action is likely not to occur within 10 seconds?]

##### 3.2.3.5 Consistent Message Correlation

- Principle: There should be a single, well-defined way to link successive messages (such as corrections or retractions of requests or notifications). This should not rely on message or transport level information, but rather use business-level information.

- Implementation: Add an explicit correlation identifier, defined as business object identifier, and a sequence number to link successive messages.

##### 3.2.3.6 Consistent Error Reporting

- Principle: There should be a standard way of reporting error or exception status for each type of request.

- Implementation: Ensure that there is an exception message for each message workflow.

##### 3.2.3.7 Consistent correction and retraction mechanism

- Principle: There should be a consistent way to correct messages containing an error, and to retract (withdraw, cancel) messages when the information is no longer valid or the action is no longer required.

- Implementation: Correctable messages will contain an "isCorrection" indicator to indicate whether the message corrects a previous message. Retractable messages should have a corresponding message ending with "Retracted".

##### 3.2.3.8 Consistent Processes Across Trades and Post-trade Events

- Principle: Business processes should work consistently across trading events and post-trade events where possible, so the same messages should be available for each type of event.

- Implementation: Most messages will be designed to be able to handle multiple types of events, such as new trades and post-trade events. This allows consistent coverage of a number of post-trade events with a number of business processes.

Implementers attempting to construct software based on these protocols using a non queuing transport (e.g. WebServices, DCOM, CORBA) will need to implement a reliable message layer to encapsulate the current message sequences (e.g. a get/put message interface using sequence numbers to detect lost or duplicated messages and positive/negative acknowledgments). The W3C site contains links to proposals for such extensions for use with WebServices.

##### 3.2.3.9 Transport Characteristics

##### 3.2.3.9.1 Purpose

The definition of the FpML business processes assumes the use of reliable messaging, meaning high predictability. Generally, increasing reliability increases latency. The assumption of reliable messaging is provided to make it easier to design standard business processes and messages. If the transport characteristics were not defined, the business process definition would be ambiguous.

##### 3.2.3.9.2 Layers

The protocol that is used for exchanging FpML messages is defined in being in three main layers:

- The Business Layer is the higher layer and deals with FpML documents. The exchange of FpML documents is fully described in the message choreography and the structure of the FpML documents is fully described by the schemata and the related validation rules. The Business Layer is equivalent to adding a Layer 9 to the OSI model.
- The Message Transport Layer is the lower layer and deals with transport messages. The implementation of this layer is outside the scope of FpML since it varies. The Transport Characteristics apply to the Message Transport Layer. This layer is equivalent to adding a Layer 8 to the OSI model.
- The layer immediately beneath the FpML Protocol is the Messaging Application Layer. FpML allows any Messaging Application that supports the requirements of the Transport Characteristics defined below. The Messaging Application Layer is Layer 7 of the OSI model.

##### 3.2.3.9.3 Reliable Mode

Specifically, the transport characteristics that FpML assumes in order to implement most of its business process definition are defined by:

- The delivery of a message is highly assured so the receiving messaging endpoint receives the message at least once.
- A sending messaging endpoint must not block the sending or receipt of other messages while waiting for a response to the sent message.
- The same applies to the receiving messaging endpoint. It must not block the receipt or processing of other messages while processing the current message.
- Messages may arrive in any order at the receiving messaging endpoints. However the message must be delivered before the maximum duration of time permitted.
- For each FpML document sent, sixty seconds is the maximum duration of time in within which all its preceding FpML documents must be sent.
- Messages are addressed to nought to many receiving messaging endpoints.
- The maximum duration of time within which a message must be delivered is sixty seconds.
- Only valid FpML documents are delivered; invalid FpML documents are rejected to the sending messaging endpoint.
- The messaging transport system must ensure that the FpML document is well-formed, W3C Schema valid, validated against the constraints defined in the validation rules, and validated against the message choreography. It is important to note that the messaging transport system is a role that can be played by either endpoint in a peer to peer setup, or by one or more third party systems. In addition, multiple messaging transport systems can be chained together into a single messaging transport system.
- The messaging transport system must ensure that the message is kept available until it is received by the messaging endpoint or until it is expired because it was delivered later than the maximum duration of delivery time. So, it can be queued on the messaging transport system within the maximum delivery time duration, but it can be queued at the destination indefinitely.
- The maximum size of a message is 100,000kb (100Mb). Any message exceeding this size must be treated as an invalid message.
- Clocks must maintain a maximum (inclusive) variance from UTC less than the Maximum Clock Variation for the supported Message Transport Mode. The maximum clock variation for this mode is ten seconds.

##### 3.2.3.9.4 Bulk Transfer Mode

In some processes such as Portfolio Reconciliation or Position Report, FpML assumes the following transport characteristics:

- The delivery of a message is highly assured so the receiving messaging endpoint receives the message at least once.
- A sending messaging endpoint must not block the sending or receipt of other messages while waiting for a response to the sent message.
- The same applies to the receiving messaging endpoint. It must not block the receipt or processing of other messages while processing the current message.
- Messages may arrive in any order at the receiving messaging endpoints. However the message must be delivered before the maximum duration of time permitted.
- Messages are addressed to nought to many receiving messaging endpoints.
- The maximum duration of time within which a message must be delivered is ten minutes (600 seconds).
- Only valid FpML documents are delivered; invalid FpML documents are rejected to the sending messaging endpoint.
- The messaging transport system must ensure that the FpML document is well-formed, W3C Schema valid, validated against the constraints defined in the validation rules, and validated against the message choreography. It is important to note that the messaging transport system is a role that can be played by either endpoint in a peer to peer setup, or by one or more third party systems. In addition, multiple messaging transport systems can be chained together into a single messaging transport system.
- The messaging transport system must ensure that the message is kept available until it is received by the messaging endpoint or until it is expired because it was delivered later than the maximum duration of delivery time. So, it can be queued on the messaging transport system within the maximum delivery time duration, but it can be queued at the destination indefinitely.
- The maximum size of a message is 100,000kb (100Mb). Any message exceeding this size must be treated as an invalid message
- Clocks must maintain a maximum (inclusive) variance from UTC less than the Maximum Clock Variation for the supported Message Transport Mode. The maximum clock variation for this mode is five minutes.

####

3.2.4 Transport Independence

In general, four layers of specification are contained in a XML Standard. A multi-layer approach allows implementers to choose the most appropriate technology for a given situation. It allows development and modifications within one layer without affecting or requiring changes to the others..

From the top down, the four layers are:

##### 3.2.4.1 Business Process

This layer specifies the way in which any business process is defined, such that is understood and executable by people and applications. A business process can be defined as a set of interrelated tasks linked to an activity that spans functional boundaries. Business processes have starting points and ending points, and they are repeatable. Examples of business processes in the derivatives domain are the affirmation process, the confirmation process, and the matching process.

The FpML Specification models business processes in UML sequence diagrams.

##### 3.2.4.2 Document

This layer corresponds to the FpML document definitions. It provides a set of abstractions specific to financial derivatives but also a set of elements which are not context specific (such as “Party” and “Price”).

##### 3.2.4.3 Messaging

The Messaging layer addresses the need to record session and communication settings for message transport in order to enable coordination between parties in a business transaction.

The FpML Schema explicitly models ‘delivery’ related information as part of the message itself. Some transports (i.e. SOAP, ebXML, etc.) allow such information to be placed in the ‘envelope’ that surrounds the message during delivery.

Including a standard header within FpML messages increases consistency by providing a single format for delivering information regardless of the physical transport, ensures that it will be persisted if the message is archived, and allows more flexible use of features such as digital signatures.

##### 3.2.4.4 Transport

The Transport Layer provides a point to point connection so that one server can send messages to another server and they will arrive uncorrupted and in the correct order.

The FpML Message Architecture defines a message structure that is independent of the underlying transport protocol, such as SMTP, File Transfer Protocol (FTP), Standardized Messaging Middleware, HTTP, etc.

####

3.2.5 Identification of Purpose

The receiver of a message needs to be able to determine the function that the message is invoking. In XML there are three different techniques that can be used for indicating the purpose of a message.

The FpML 5.0 message framework is based on element naming (option 2 - By Element Name). Below is a short explanation of the three techniques:

##### 3.2.5.1 By Namespace (not used by FpML)

The receiver can look at the namespace from which the element definitions have been drawn and determine from it the function requested.

    <?xml version="1.0"?>

    <FpML version="4-0"
     xmlns="http://www.fpml.org/2002/FpML-4-0-TradeConfirmationRequest">
      <header>
        ... Message header
      </header>
      ... Business data
    </FpML>

Using namespaces it would be possible to create a highly extensible framework for FpML but it could lead to documents having to have every FpML element prefixed with a suitable namespace abbreviation although it may be possible to mitigate this by having the 'core' sub-schemas use no namespaces in their definition and take on the namespace of the one they are including into.

There may be further issues with related XML standards such as XPath as the namespace of the same included elements may not be consistent between documents.

##### 3.2.5.2 By Element Name (used by FpML 5.x)

The receiver can look at the name associated with an element within the message (the root and one of the first level children) to determine the function requested.

    <?xml version="1.0"?>
    <requestConfirmation fpmlVersion="5-0" xmlns="http://www.fpml.org/FpML-5/confirmation">
      <header>
        ... Message header
      </header>
      <trade>
        ... Business data
      </trade>
      ...
    </requestConfirmation>

In this model the root element is a global element of a type derived from the base FpML Document type, typically a message type.

##### 3.2.5.3 By Element Type (used by FpML 4.x)

The receiver can look at the type associated with an element within the message (e.g. the root or a child).

    <?xml version="1.0"?>
    <FpML version="4-0" xmlns="http://www.fpml.org/2002/FpML-4-0" xsi:type="TradeConfirmationRequest">
      <header>
        ... Message header
      </header>
      ... Business data
    </FpML>

An XML schema based instance may use type substitution to replace the content model of any element with another providing that the replacement is derived from the original. Given a framework that provides the appropriate extension points any number of new types can be derived within the name or different namespaces as necessary.

In addition through inheritance the message types can be associated with an appropriate message header content model.

####

3.2.6 General Pattern of Messages

Messages are divided into a series of business processes. For example, consent negotiation (getting permission to do something) is a business process. For each business process, in general the following messages will be available:

- process request or notification message – to initiate the process. (In some cases the process may be initiated by a notification message rather than a request message).

- process acknowledgment message – to acknowledge that the request or notification was received.

- process exception message – to report that a request or notification cannot be processed.

- process request/notification retracted message – to withdraw the original request or notification.

- possibly, process-specific response messages

In some cases, some of these messages may be intentionally omitted, but in these cases the rationale for omitting the messages will be provided. For example, acknowledgement messages may be omitted where it is expected that all responses will be immediate, and retraction messages may be omitted if there is no need to allow requests to be withdrawn, because the original request would be fulfilled before the retraction could be sent.

For the consent negotiation process, for example, the messages include:

- requestConsent – initiating request

- consentAcknowledgement - acknowledgement

- consentException - exception

- requestConsentRetracted – retraction of the request

- consentGranted - response

- consentRefused – response

####

3.2.7 Naming Conventions

Messages follow this naming convention:

- requestXxx

- xxxAcknowledgement

- xxxException

- requestXxxRetracted

- xxx[Status] or xxx[Response]

####

3.2.8 Acknowledgements

Providing each request with a more immediate and guaranteed response allows a more synchronous style of design, such as this:

Here the requester waits for the response before terminating its execution. This would allows easier specification of timeouts related to request processing although as we shall see later has implications for gathering the results of long running processes, such as matching.

####

3.2.9 Message correlation

The initiator of a business process should allocate a unique correlation identifier for each process instance it begins and any subsequent message related to the same process should contain the same identifier. A qualified scheme based value ensures that participants cannot accidentally re-use an identifier previous generated by another firm.

For example, when used within a trade execution advice it might appear as follows:

                                                    ...
    <tradeExecutionAdvice>
      <messageHeader>

      </messageHeader>
      <isCorrection>false</isCorrection>
      <correlationId correlationIdScheme="http…">BQ/1234 </correlationnId>
      <sequenceNumber>657</sequenceNumber>
      <onBehalfOf>
        <partReference href="PARTYA"/>
      </onBehalfOf>
      <execution>
        <trade>
          … Lots more here
        </trade>
      </execution>
      <party id="PARTYA">…</party>
      <party id="PARTYB">…</party>
    </tradeExecutionAdvice>

                                                    ...

Any response or follow up to this message should contain the same 'correlationId' definition. This regime allows us to make some other messaging clarifications, namely:

- Every message will have a unique message identifier.

- The ‘inReplyTo’ element of a response message (or exception) correlates with the ‘messageId’ of the associated request.

- The conversationId has been removed.

- Retransmission of a message for technical reasons (e.g. the last transmission of the request was not acknowledged or rejected) does not change the message identifier.

- Replication of a message for business reasons (e.g. sending data that has been previously acknowledged) generates a new message identifier.

- The response to a retransmitted request message should be identical to the original request. (1)

- At the start of a long running process the initiating participant must create a unique one-time identifier for each process instance and distribute it to the other messaging party.

- Every subsequent message sent by the requester must contain the process identifier.

- Messages may contain reference to other business process instances providing their role is clear and unambiguous (e.g. an order MAY reference a previous quotation).

(1) This allows the transport to respond to retransmissions by sending a copy of the earlier cached response, no business process is necessary. This is a standard technique in ONC RPC and WebServices.

####

3.2.10 Message sequencing

In a long running operation it is important to process all of the messages in the correct order. Each message’s ‘messageId’ is element is guaranteed to contain a unique value but the order of messages cannot be inferred by comparing two such identifiers.

The characteristics required by FpML’s transport characteristics states that two messages sent simultaneously, or within a short time of each other, may arrive in any order. Since message order cannot be determined from the message identifiers some other information needs to be added to them message to provide this.

In the SWIFT CUG implementation of the contract notification messages the trade version is used to derive the ordering. Whilst this is a workable solution for the CUG it does not solve the problem generally and some messages must artificially increase the contract version number to maintain order even though no change has actually occurred to the underlying contract.

The simplest solution is to define a type for sequence numbers and use it within messages to provide an orderable value.

It is important to note that although sequence numbers should be consistently increasing in value they do not have to form a gapless sequence. (2)

When combined with the unordered delivery transport characteristics a message processing application can be presented with a series of messages in a jumbled order.

- An optimistic message processor should attempt to process the messages in the order they are delivered and unwind actions (or raise exceptions) when conflict is detected.

- A pessimistic message processor should record the messages but delay their processing for a short period. This provides a time window during which any earlier messages received out of order can be re-sequenced before processing begins.

It is also important to note that sequence numbers must be qualified with respect to the message sender and the responding part may need to produce messages containing them. For example in the matching processes the messages containing the result should reference the same ‘correlationId’ used in the original request but should use a ‘sequenceNumber’ provided by the matcher rather than the requester.

For example the series of messages for a trade confirmation (including a correction) followed by the resulting match might be identified as follows:

(2) There may be messages within the same business process sent to other participants or internal changes to the business object that affect the sequence number.

####

3.2.11 Correlation ID optionality

Starting from FpML 5.2, the correlation ID is optional in requests. This is intended to more flexibly support a variety of processing models. The original request may omit the correlation ID if the recipient will quickly respond to requests with its own correlation ID. Subsequently requester will need to use the recipient's correlation IDs if it needs to correct or retract a request. The FpML messaging architecture recommends that services support the correlation ID in the original requests, because otherwise requesters cannot correct or retract requests until they receive a reply from the service.

####

3.2.12 Other topics

##### 3.2.12.1 onBehalfOf

The FpML neutral view principle when combined with some of the notifications for post-trade processes and a common third party such as a custodian results in situations where the third party can not easily tell which side of the trade he is supposed to be processing.

For example, parties A and B negotiate a trade and then send a contract execution notification to their common custodian C. The custodian may be able to figure out which side of the trade to process by means of the message sender’s identity but as a single sender identity might be used by several legally separate trading divisions within the same company group determining the correct party might require extensive organisational reference data. This approach would also fail for internal book-to-book deals where both sides would originate from the same sender.

What is needed is an explicit indication of the party for whom the trade should be processed included in every message. In the case of book-to-book trades this information should use account references to further qualify the party. For example:

    				<someRequest>
    				  <header>
    				    … Basic message details
    				  </header>
    				  …
    				  <onBehalfOf>
    				    <partyReference href="JPM"/>
    				    <accountReference href="PORTFOLIO1"/>
    				  </onBehalfOf>
    				  … Request specification here
    				</someRequest>

##### 3.2.12.2 party roles

The 4.x tradeSide structure has been replaced by a simpler implementation adding a new relatedParty element. The role element within the relatedParty defines the list of roles as code list. This allows to customize the roles easier than using the tradeSide structure.

    <someRequest>
    ...
    	<partyTradeInformation>
                <partyReference href="party3"/>
                <relatedParty>
                   <partyReference href="party4"/>
                   <role>orderer</role>
                </relatedParty>
                <relatedParty>
                   <partyReference href="party4"/>
                   <role>introducer</role>
                </relatedParty>
                <relatedParty>
                   <partyReference href="party3"/>
                   <role>executor</role>
                </relatedParty>
                <relatedParty>
                   <partyReference href="party4"/>
                   <role>confirmer</role>
                </relatedParty>
                <relatedParty>
                   <partyReference href="party6"/>
                   <role>creditor</role>
                </relatedParty>
                <relatedParty>
                   <partyReference href="party5"/>
                   <role>settler</role>
                </relatedParty>
                <relatedParty>
                   <partyReference href="party6"/>
                   <role>accountant</role>
                </relatedParty>
    	</partyTradeInformation>
    ...
    </someRequest>

##### 3.2.12.3 separation of party and account

Currently accounts are specified within a party definition and the relationship between the two objects depends on the elements present. To simplify the structure and make the relationships clearer the account structure should be moved outside of Party and given a mandatory reference to its beneficiary and an optional reference to its servicer (this is the reverse of the 4.x accounts model).

### 3.3 Regulatory Reporting Processes

FpML 5.2 and above introduce new features to better support regulatory reporting requirements. The following table shows which FpML business processes support which types of regulatory reporting requirements.

|  | FpML Views
Message Type |  | Confirmation | Reporting | Transparency | Record Keeping
Real Time |  |  |  | X |
PET |  |  |  |  | X
Confirmation |  | X |  |  |
Life Cycle | Price Formation | X |  | X | X
Intrinsic | Non Price Formation | X |  |  | X
Daily State |  |  | X |  |
Valuation |  |  | X |  | TBD

The different message types have no dependencies except for valuation messages to SDRs that require prior reports to be submitted.

### 3.4 Business Processes

####

3.4.1 FpML 5 Business Processes

Before looking at the current message processes and their associated messages it is worth looking at the overall sequence of business processes for trades.

The first thing to note is that there are two sets of processes; the first set manages the transaction itself during its ‘cradle to grave’ life cycle while the second are repeatable management tasks that may occur several times over the life time of the transaction.

####

3.4.2 Transaction life cycle

Looking at the states in the life cycle part of the process model there the first thing to note is that there are multiple routes to the creation of trade.

The original model for FpML (and not actually supported in the specification) is the traditional model of direct inter-dealer negotiation (e.g. by phone, over SwapsWire, etc.) followed by an affirmation of the resulting transaction.

Alternatively trades could be created using a more market based approach in which quotes and orders are communicated through an exchange in which more than one market maker may be offering prices for the same quote or order. The terminology of quote, indications of interest, orders and execution is more closely coupled with this market approach.

In the direct negotiation approach the identities of the participants of fully disclosed and this allows pre-agreed exploitation of other party’s credit rating to obtain better prices (within agreed limits). In the market approach pre-order interactions may be anonymous to guarantee best prices are obtained for all market participants.

Messages related to trade negotiation and affirmation need to be capable of recording that these additional parties are being used but in later trade processing stages such ‘give-up’ trades are decomposed in a set of related back-to-back trades.

####

3.4.3 Overall Messaging Flows

With the advent of new business processes created based on regulatory reform in the OTC derivative trading space, the FpML Business Process Working Group (BPWG) created a set of diagrams to describe how FpML can be used to support the new business lifecycles around OTC derivative trading. Following is an initial version of those diagrams.

####

3.4.4 Generic (Multi-Event) Flows

All the processes described in this section are applied to the following events:

- trade
- novation
- increase
- termination
- amendment
- optionExercise / optionExpiry
- deClear
- withdrawal

Additional events have been added since version 5.5.

- basketChange
- corporateAction
- indexChange

All events use the same messages to support the processes. The additionalEvent element is an extension point to customize FpML and add additional events.

##### 3.4.4.1 Public Execution Report Flow

##### 3.4.4.1.1 Dodd-Frank Reporting

FpML has developed messages to support reporting by reporting parties and execution facilities into swaps data repositories, to support the regulatory reporting requirements mandated by the Dodd-Frank Act. The following diagram shows how the different entities in the reporting process may use the FpML public reporting messages (in red) to report on trade execution to the public via SDRs or third party messaging services.

##### 3.4.4.1.2 Public Execution Report

The public execution report message is provided for reporting parties and agents (such as execution platforms) to report on the execution of trades to the public, via Swaps Data Repositories or third party messaging services. The public execution report contains a simplified version of the product model covering only the commonly used terms that affect pricing.

##### 3.4.4.1.3 Public Execution Report Correction

The public execution report may contain mistakes. The PublicExecutionReport type allows corrections (provided it is still possible to do so), by sending a corrected execution report correlated to a prior report with "isCorrection" element set to "true".

##### 3.4.4.1.4 Public Execution Retraction

The execution report can be retracted (provided it is still possible to do so) by correlating execution retracted message to the execution report.

####

3.4.5 Service Notification

There are service notification messages that allow a service to report information on status and other alerts to users. Supported variations include:

- status - allows the service to indicate whether it is available or not as a whole (or other overall statuses).
- processingStatus - allows the service to report information about the status of processing activities, for example end of day processing, netting processes, etc. There are fields that allow the processing cycle to be identified as well as the specific processing event.
- advisory - allows the service to provide advance notice of changes to the service, for example related to availability, rules, product coverage, etc. Advisories may be qualified with a time range when they is applicable, and may be categorized (for example into advailability, rules, products, etc.) to assist recipients to know how to process them.

## 4 VALIDATION ARCHITECTURE

### 4.1 Validation Rules

This section defines the business validation rules architecture that was established by the Validation Working Group. It contains introductory and background information about the purpose of validation, a guide to how to make use of the documents published by the Validation Working Group, and serves as a reference point for implementers.

The main documents produced by the Validation Working Group is the set of validation rules, expressed in English:

Please Note: The Reference and Shared Validation rule are being included in the Reporting, Recordkeeping and Transparency view since FpML version 5.5WD1. The examples and rules associated with these views are currently avaialable only for Confirmation view. The rules are currently in the process of being reviewed and will be added with in the next 5.5 publication.

The validation rules follow the principles and guidelines defined in the Validation Rule Specifications section.

### 4.2 Reference Implementations

The Validation Working Group's charter includes a mandate to formalize the validation rules from their plain English representation to a suitable implementation language. The purpose of this decision was to disambiguate the English language representation, to serve as a point of reference for implementers looking for clarification, and to validate the test cases produced by the working group. Reference implementations play an important part in providing quality guarantees to the working group and it is hope that their publication will be useful to implementers.

####

4.2.1 Java and C#

Provider |
Implementation Language | Java and C#
Implemented Rules | All published FpML rules (plus adjustments for FpML 1.0, 2.0 and 3.0); Additional rules for datatypes (in DTD documents FpML 1.0, 2.0 and 3.0); Additonal rules for schemes (all FpML releases)
Browse | N/A
Further Information | http://www.handcoded.com

####

4.2.2 Java/XPath

Provider |
Implementation Language | Xpath/Java
Implemented Rules | All versions, All rules
Browse | FpML Reference Implementation
Further Information | http://www.iona.com/products/artix/standards_libraries.htm

####

4.2.3 CLiX

Provider |
Implementation Language | CLiX / Java
Implemented Rules | http://www.fpml.org/2003/FpML-4-0/validation/2004-04-02:All rules
Browse | FpML Reference Implementation
Further Information | http://www.messageautomation.com

The reference implementations are non-normative and should not be considered publications of the Validation Working Group. Instead, they are contributions provided by members of the working group or other implementers.

Although the working group does not have the means to provide official certification, it expects implementers to demonstrate that they produce the correct results - valid or invalid - for the normative test cases of each implemented rule. There is no requirement to implement all rules, but reference implementations will state clearly which rules are implemented by publishing a list of rule identifiers.

### 4.3 Test Cases

The Validation Working Group also publishes a set of test cases with each rule set release (available above). For each rule, a number of valid examples and a number of invalid counter-examples are given. The test cases for a release will have been validated both manually and against at least one reference implementation to check that they are correct. The test cases have the following properties:

- All test cases are valid against the schema
- Every valid test case is valid against all rules (business valid), but is guaranteed to carry the information that the particular rule it is designed to test against makes use of.
- Every invalid test case for a rule is guaranteed to violate the rule, but may in addition violate other rules.
- Each invalid test case must state which instance of the context is invalid. For example an invalid document with more than one matching context must state which contexts are invalid, and the other contexts must be valid.
- There is no guarantee of completeness. The test cases are designed for disambiguation and test the most common violations, they are not an exhaustive set of boundary cases.

### 4.4 Target Audience

This document should be useful to:

- Architects that need to consider the impact of semantic validation on the overall workflow or processing pipeline. Relevant section: Validation Architecture Concepts
- Implementers of FpML that need to understand how to make use of the validation rules in implementations. Relevant section: Validation Rules and Reference Implementations
- Analysts or other interested parties who wish to use the validation rules to further their understanding of FpML. Relevant section: Background

### 4.5 Background

FpML has been designed as a very rich language, with a large amount of optionality in its element and attribute definitions. This richness, which arises from the complexity of the information that FpML is designed to carry, has made it easier for implementers to fit FpML into existing architectures, and has facilitated the reuse of common element types across different asset classes.

Partly due to this flexibility, and partly due to the rich structure of FpML, it is unrealistic to assume that a schema-validated FpML document is necessarily correct in a business sense. The Validation Working Group was established early in 2003 to consider the implications of this problem and breaks down the correctness of an FpML document into three parts:

- Well-formed XML: The document meets the basic XML well-formedness constraints defined by W3C.
- Schema Compliance: The document is valid against the Schema that the document references.
- Business Rules Compliance: The document is valid against the validation rules published by the Validation Working Group.

It is useful to consider some simple example to illustrate the different levels of validity. The following is a fragment of a well-formed FpML document, but violates the schema due to an invalid start date:

    <calculationPeriodDates>

      <effectiveDate>

        <unadjustedDate>xxxx-xx-xx</unadjustedDate>

        ..

      </effectiveDate>

      <terminationDate>

        <unadjustedDate>2004-02-29</unadjustedDate>

        ..

      </terminationDate>

      ..

    </calculationPeriodDates>

The following version of the fragment is syntactically valid, because the contents of the effective date now match the schema definition of a valid date.

    <calculationPeriodDates>

      <effectiveDate>

        <unadjustedDate>2004-08-29</unadjustedDate>

        ..

      </effectiveDate>

      <terminationDate>

        <unadjustedDate>2004-02-29</unadjustedDate>

        ..

      </terminationDate>

      ..

    </calculationPeriodDates>

The fragment of FpML inserted above is however not semantically valid, because the effective date of the trade precedes the termination date. As a consequence, the trade is not meaningful and in fact violates one of the validation rules for IRD interest rate streams. Many other types of constraints will not be validated by the schema, which is designed to designate structure, not semantics:

- Constraints between the contents of multiple elements, like as in example given above
- Relationships between elements in distant parts of the document
- Complex data type operations that require processing, for example checking cash flows against the parametric representation
- Reference data validity, or other checks against external documents or databases

The validation working group has considered these problems and their implications, and has attempted to address a number of questions. How do we extract the knowledge about what constitutes a correct trade from business experts? What, if any, guarantees will we give that our work is complete? What is the normative status of the validation rules? How can parties override or tailor the rule set? What infrastructure support is necessary in the FpML architecture to enable rule-based checking? What support is necessary in the new messaging framework? The answers to these questions are addressed in the remainder of this section.

### 4.6 Rule Specifications

This section defines the guiding principles and requirements for how rules should be defined and written. The Validation Working Group’s desire is to define a set of guidelines, which when followed produce a set of rules which conforms to an agreed standard of layout and content, with the intention that the rules are coherent, complete and well-defined; and therefore usable by practitioners.

####

4.6.1 General Principles and Guidelines

Validation rules should be written in a stylized plain English which is both precise and complete, but not necessarily formal:

- The target audience is business analysts and programmers familiar with OTC derivatives
- The rule definitions must be precise
- Rules must be written in the terms of an infoset. At present the only suitable infoset is XDM *
- For each context of a rule, the rule must evaluate to a single XML schema Boolean value +
- The definition of each English term should correspond to an XPath 2 expression. NB all other terms or tests must be defined using terms already defined or existing XPath 2 expressions (cf. http://www.w3.org/TR/xpath20). Any reference to XPath is to XPath 2.

* XML infoset does not contain schema information; PVSI contains gaps and impossible scenarios when used for rules, and therefore is unsuitable; this is why the W3C created the XDM infoset. NB model groups do not appear in XDM and therefore cannot be defined in the rule (they are also context free)

+ other cases would result in ambiguity, e.g. an optional Boolean value or more than one Boolean value (multiplicity)

####

4.6.2 Mathematical Notation

There is a list of approved mathematical symbols which must be used, in the formal description, instead of their natural language equivalents. This list contains the commonly understood mathematical symbols. Only the symbols on the approved list may be used in the formal description. Their advantage is their terseness and readability compared to natural language.

To avoid confusion with XPath definitions, each symbol must be separated for other words with a space. Otherwise for example the division symbol and the XPath symbol would be confusable.

The approved mathematical symbols are:

eq | equality (XPath value comparison operator)
ne | inequality (XPath value comparison operator)
lt and gt | is less/greater than (XPath value comparison operator)
le and ge | is less/greater than or equal (XPath value comparison operator)
+ | addition (plus)
- | substraction (minus)
* | multiplication
/ | division
() | precedence grouping

XPath value comparison operators (eq, ne, lt, le, gt, ge) are defined in the XPath specification.

####

4.6.3 Rule Definition and Layout

To ensure consistency and improve readability rules should be defined using the following syntax (the notation is expressed using EBNF):

Rule | ::= | RuleIdExpr Contexts RuleDef Tests
RuleIdExpr | ::= | RuleId “(” “Mandatory” | “Warning” | “Implementation-specific” “)”
RuleId | ::= | ProductType “-” Digits
ProductType | ::= | One of the product type or shared
Digits | ::= | [0-9]+
Contexts | ::= | Context (“,” Context)*
Context | ::= | “Context:” TypeName (ContextConds)
ContextConds | ::= | ContextCond (ContextCond)*
ContextCond | ::= | “[”ConditionExpr | ValCondition “]”
ConditionExpr | ::= | Precise definition of the rule expressed in English using defined terms
ValCondition | ::= | Reference to a global validation condition (ref) expressed in English
TypeName | ::= | XML Schema Type Name (complex type)
RuleDefEnglish | ::= | English definition of the rule expressed in natural language. This description may include business reasons or examples.
RuleDefFormal | ::= | Formal definition of the rule expressed in XPath and defined terms
Tests | ::= | “Test Cases:” Valid (Valid)* Invalid (Invalid)*
Valid | ::= | “[“ DocLink “]”
Invalid | ::= | “[“ DocLink “]”
DocLink | ::= | Link to a test case document

- rule identifier must be unique and as appropriate the product type they apply to should prefix any numbering scheme (e.g. eqd-5 for rule 5 of Equity Derivatives)
- a Context evaluates from the document node to a resulting set of element nodes, the rule should then be applied separately to each member of the set
- a Context is qualified by an appropriate namespace unless it is in the default namespace (NB a section should define all applicable namespaces)
- context conditions qualify a context and therefore should appear after the context (this is important in the case of multiple contexts where different context conditions may apply)
- the current context is not carried through into a function. The function has no context other than its parameters
- a suitable set of valid and invalid test cases, which exercise the rule, will also need to be developed. NB each invalid test case must invalidate a single rule (and not any other rule)
- when a new rule is defined it should not invalidate any existing test cases
- there should be no redundant rules, e.g. A>B, B>C would make a rule of the form A>C redundant
- any term that is defined in XPath then that meaning is used for the term in the RuleDef. Any other term must be defined as a function
- literal values must be given a datatype. For example, the string "ISDA1999" refers to a value of xs:string

Rule layout:

An example rule:

The above definition describes rule 3 for credit derivatives. The context is type Trade, which is a complex type. The precondition ISDA1999 must evaluate to true, the condition that node-element documentation/contractualSupplement (as expressed using XPath 2) should exist. The rule body specifies that the node-element type must not begin with string “ISDA2003Credit” (finally links to applicable valid and invalid test case documents.)

####

4.6.4 Defining New Terms as Functions

In the previous sections, the notion of expressing rules using stylized English was introduced; and the concomitant concept that a term should have the same meaning as the equivalent XPath expression. This section introduces functions as a mechanism to define repeatable tests that are applied independent of a context. Functions take node-element types as parameters and return a typed result.

Consider a test requiring that all currencies must be the same and that this applies for several different contexts. With reference to the schema it’s possible to identify that currency is applicable to all Money types and therefore define a function which accepts as a parameter a set of Money nodes:

Function Name | same-currency
Description | the set of money elements must all contain the same currency
Parameter 1 | $money (fpml:Money) (min=2, max=*)
Result Type | xs:boolean
Test | Every $money/currency must be the same and every $money/currency/@currencyScheme must be the same

This creates a new term same-currency which can be used as part of the definition of any validation rule.

NB The function does not inherit the context of where it is called from.

Each parameter name is prefixed with "$" to distinguish it from an XPath. Otherwise "money" might be either the parameter "$money" or the XPath "./money".

Each parameter has a minimum and maximum cardinality. This is given in the style of XML Schema. The cardinality must always be present. If the cardinality is not indicated, by default, the parameter must be provided once.

Each function must have a single result type.

There can be any number of parameters to a function.

##### 4.6.4.1 How to use functions?

Once a new term (e.g., same-currency) is defined, it can be used as part of the definition of any validation rule (including conditions).

A reference to a new term must also include required parameters (within parenthesis and comma-delimited) as specified in the function definition. For example,

- same-currency((equityPremium/paymentAmount , notional))
- [exists(physicalSettlementTerms)] (example of Xpath function exists() used within a condition)

####

4.6.5 Formatting

Components of the validation rules may be differenciated by formatting as shown in the following table.

Component | Formatting | Example
values | Courier New, 12pt, bold, black font | 100, ISDA2003Credit
xpath expressions and elements | Courier New, small 9pt, blue font | creditDefaultSwap/generalTerms/effectiveDate
functions | Times, 10pt, black font | exists(argument)

Formatting is defined in stylesheet rules.css.

### 4.7 Technical Guidelines

####

4.7.1 Implementations

For the purposes of precision, extensibility, and robustness to change the structure of the Validation Rules is profiled. The rules of the profile are:

- The context for a validation rule must always be a type. However, an element can be used for a context if there is no suitable type, because the context is a model group. If the context isn't a model group, then an element cannot be used."
- The paths from the context should be node names rather than types wherever posssible. For example "equityAmericanExercise" is preferred to "element(*, EquityAmericanExercise)".
- The context of the rule must be defined such that incorporates everything referred to in a rule. The rule must not use the ancestor or parent axis, or use them in cojunction with any other axis. For example "../../tradeHeader" is precluded.

####

4.7.2 Evaluation of Dates

The evaluation of dates in the validation rules is not trivial. The optionality of including time offsets in date datatypes makes comparisons between dates more difficult since sometimes the result is indeterminate as any ISO8601 date is +/- 18 hours of timezone, and +/- 24 hours of day.

The Validation Working Group recommends the use of the XPath 2.0 date/time comparison rules which defines a definitive true / false value even for indeterminate calculations.

The Validation Working Group recommends that time offsets appear on all date/time values used in FpML documents.

####

4.7.3 Contains

Many validation rules defined in FpML use the term 'contains'. FpML uses the definition of XPath 2's 'contains' (fn:contains) http://www.w3.org/TR/xpath-functions/#func-contains. This is significant for alphabets with accents, diaresis, etc.

### 4.8 Revision and Publication Process

Since the Validation Working Group was established after most product working groups, it still has a lot of work to complete before the rules span the whole product range, and indeed are reasonably complete for any particular product type. The latest set of validation rules is thus likely to change more frequently than the specification, and the process of rule publication has been decoupled from the specification.

The validation working group undergoes the following process in preparing its releases:

- Comments from previous publications are reviewed and logged as issues.
- The working group collaborates with selected experts from product working group to establish an initial set of rules, expressed in plain English.
- The rules are reviewed and extended, by performing a structured walk-through of the schema for the product type.
- The chairman of the Validation Working Group calls a freeze on the rule sets when a substantial set of new rules is available, or critical issues need to be urgently resolved.
- Test cases are written for each rule and ambiguities in the language addressed. This process usually leads to the elimination of some rules, and discovery of additional ones.
- The test cases must be validated by at least one reference implementation, and further ambiguities eliminated.

At the end of this process, a new URI is allocated for the revised rule set, and the rule set is announced and published as the new normative rule set on the FpML web site. We expect to publish the process to take on average three months for the foreseeable future.

### 4.9 Normativity and its Implications

The rule sets and test cases are the normative content published by the Validation Working Group. The reference implementations, see below, are informative and not part of the normative process. This normative characteristic has the implication that applications that construct FpML documents have to be designed so that their output meets the full set of validation constraints.

Applications that receive FpML for processing may want to check the validation rules to ensure that the data they are receiving represent a valid FpML document. Processing applications are not obliged to reject invalid messages. Instead, the implications of rule normativity are that the receiver gains the right to reject invalid messages. In other words, the sender has to either be prepared for rejection, or the rule set has to be tailored.

The validation working group is concerned that there may be legal implications due to this definition in situations where trades are executed between counter-parties. While we believe that the definition given above, providing a right for the receiver to reject trades and placing the burden on the sender, is the least controversial, we would like to obtain additional feedback on this issue before the publication of the final recommendation.

## 5 CROSS-ASSET PRODUCT ARCHITECTURE

### 5.1 Overall Architecture

There are several special, cross-asset products in FpML.

- genericProduct
- standardProduct

### 5.2 The Strategy Component

This component defines a special kind of product that allows the structuring of trade by combining any number of products within a strategy. A trade can be of a strategy rather than of a base product; this strategy can then in turn contain other products, such as multiple options. For example, you could define a strategy consisting of an FX call and an FX put to create a straddle or strangle, and then create a trade of that strategy.

This component also defines the simple strategies of strike spread and calendar spread for Equity Options

The Strategy component makes use of a composition pattern since strategy itself is a product. This means that strategies can themselves contain strategies.

In a strategy, in addition to sub-products, there may be a "premiumProductReference" reference element. Thisreferences a product (for example a bullet payment) within the strategy that can be considered a premium for the whole strategy.

### 5.3 genericProduct

The Generic product provides a placeholder representation with a few key identifying details to allow reporting of products that aren't otherwise able to be represented in FpML.

The approach is to keep a very lightweight generic product to represent the key economics of the complex and bespoke products, which would also include imbedded searchable/electronically readable term sheet in PDF format including any remaining terms. The generic product representation has been enhanced in FpML 5.5 to include all of the fields specifically listed in the CFTC part 43 and 45 regulations.

- genericProduct-Generic products - for use in Transparency reporting to define a product that represents an OTC derivative transaction whose economics are not fully described using an FpML schema. In other views, generic products are present for convenience to support internal messaging and workflows that are cross-product. Generic products are not full trade representations as such they are not intended to be used for confirming trades.

| genericProductspecifies the structure of the generic product. productType - A classification of the type of product. FpML defines a simple product categorization using a coding scheme. productId - A product reference identifier allocated by a party. FpML does not define the domain values associated with this element. Note that the domain values for this element are not strictly an enumerated list. assetClass - asset class to which the product belongs, e.g. Credit. BuyerSeller.model - holds references to the buyer and seller of the product. effectiveDate - when the product starts accruing, or in the case of an option, its first exercise date. expirationDate - for an option, the final valid exercise date. terminationDate - the final accrual date of the product or of the underlying of a product. underlyer - one or more underlying assets upon which the product is based. notional - the size/quantity of the product. settlementPeriods - Specifies the delivery time periods loadtype - LoadType is a summary of the full description of the settlement periods with respect to the region. Used for describing Electricity delivery schedules. optionType - for options, whether it is a call or put. paymentFrequency - The frequency at which payments from one party to another occur. resetFrequency - The frequency at which reset dates occur. settlementCurrency - the currency in which the buyer settles.

### 5.4 standardProduct

- standardProduct-Standard products - for use in Transparency reporting to define a product that represents a standardized OTC derivative transaction whose economics do not need to be fully described using an FpML schema because they are implied by the product ID. In other views, standard products are present for convenience to support internal messaging and workflows that are cross-product. Standard products are not full trade representations as such they are not intended to be used for confirming trades.

The Standard product provides a way to report on products that are fully represented by a standardized set of reference data, and therefore do not need a complete representation for activity or position reporting. For trades on standard products, typically only the size and price needs to be represented in addition to the product identifier.

standardProduct - specifies the structure of a standard product.

- productType - A classification of the type of product. FpML defines a simple product categorization using a coding scheme.
- productId - A product reference identifier typically allocated by a trading facility or reference data repository. For the Standard product, this will link to a precise product definition supported by FpML reference data.
- assetClass - asset class to which the product belongs, e.g. Credit.
- notional - quantity of the product that was traded.
- priceNotation - price at which the product was transacted.

## 6 INTEREST RATE DERIVATIVE PRODUCT ARCHITECTURE

### 6.1 Interest Rate Swap

In Transparency view, a swap component contains two instances of the swapStream component. A swapStream contains the elements required to define an individual swap leg.

Within an FpML swap there is no concept of a swap header. Details of payment flows are defined within swapStreams which each contain their own independent parameters.

FpML Transparency view supports a parametric representation of a swap.

The following elements and their sub-elements within the calculationPeriodAmount element:

- floatingRateIndex
- indexTenor
- dayCountFraction

The following elements and their sub-elements within the stubCalculationPeriodAmount element:

- floatingRateIndex
- indexTenor.

In general, an interest rate swap will be a swap with a fixed leg and a floating leg, two floating legs, or two fixed legs.

The structure of a swapStream is shown diagrammatically below:

The components within a swapStream cannot be randomly combined and cannot be thought of as existing in their own right; they only make sense in the given context and in relationship to other components within the swapStream container.

The paymentDates and resetDates components contain the payment and reset frequency.

FpML uses the ISDA Floating Rate Option to specify the floating rate being observed. This scheme was used rather than attempting to parameterize into elements because although most floating rate indices are defined fully by a standard set of parameters (namely index, currency and fixing source) there are sometimes other details including fixing offsets and formulas. This approach allows for more flexibility in adding new floating rate indices without having to introduce new elements, although this comes at the expense of a self contained definition within the standard.

The information relating to amounts and rates is collected in the calculationPeriodAmount.

Certain swapStream components are designated as being optional (although it would be more accurate to say that they are conditional). Thus a fixed rate stream never includes a resetDates component, but this is required for a floating rate stream. The principalExchanges component is required in the case of cross currency swaps or other types of swap involving exchanges of principal amounts.

The detailed structures within the swapStream are shown diagrammatically below:

### 6.2 Forward Rate Agreement

As noted above, the definition of a forward rate agreement trade is contained within a single component. A forward rate agreement is a simple and commoditized product. This means there is no variation in the product traded and it is not expected to become more complex in the future.

The structure of the fra component is shown diagrammatically below:

### 6.3 Option Components

FpML also supports interest rate options. The supported components are:

- Early Termination Provision (Optional or Mandatory) for a swap
- Cancelable Provision for a swap
- Extendible Provision for a swap
- Swaption
- Cap / Floor

The ISDA 2000 Definitions have been followed closely in defining the various option dates and element names. Thus components for European, Bermuda and American exercise have been defined which are re-used in each of the first four components above. These components share an element called relevantUnderlyingDate whose meaning is dependent on the option component it is contained in:

- OptionalEarlyTermination - It represents the new terminationDate of the underlying swapStreams if the trade is terminated early.
- CancelableProvision - It represents the new terminationDate of the underlying swapStreams if the trade is cancelled.
- ExtendibleProvision - It represents the new terminationDate of the underlying swapStreams if the trade is extended.
- Swaption - It represents the effectiveDate of the underlying swapStreams if the swaption is exercised.

####

6.3.1 European Exercise

This is a style of option to which the right or rights granted are exercisable on a single date referred to as the expiration date. This date can be specified either as an adjustableDate or as a relativeDate though the latter is only expected to be used in the case of cash settled cancellations where the expiration date may be defined as an offset to the cash settlement payment date.

The relevantUnderlyingDate is optional, in its absence the effectiveDate of the underlying is the effectiveDate defined in the swapStreams. This can only be excluded for european swaptions.

####

6.3.2 American Exercise

This is a style of option to which the right or rights granted are exercisable during the exercise period which consists of a period of days. The underlying should specify its effective date based on the earliest possible exercise. When exercise implies a stub period this will be taken to be a short stub at the start, i.e. the underlying swap defines a series of flows, exercise merely brings the flows into existence from the relevantUnderlyingDate.

####

6.3.3 Bermuda Exercise

This is a style of option to which the right or rights granted are exercisable during an exercise period which consists of a number of specified dates. These dates can be defined as a list together with adjustments or by reference to an existing schedule elsewhere in the trade (e.g. resetDates). In the latter case bounds can be placed on the referenced schedule to define a subset of the whole schedule.

####

6.3.4 Cancelable Provision

With a cancelableProvision the seller grants the buyer the right to terminate all swapStreams, typically in exchange for an upfront premium. Unlike optionalEarlyTermination, the cancellation of the swap does not require the parties to exchange a cash settlement amount on exercise representing the fair value of the remaining life of the swap although an exercise fee can be specified in the exerciseFeeSchedule.

####

6.3.5 Extendible Provision

With an extendibleProvision the seller grants the buyer the right to extend all swapStreams, typically in exchange for an upfront premium. This provision is very similar to a cancelableProvision and in fact the two share the same market risk profile. FpML makes a clear distinction between the two since the operational risk associated with misrecording the type of applicable provision can be high. For example, a 10 year swap with the right to cancel after 5 years has exactly the same risk profile as a 5 year swap with the right to extend for 5 years after 5 years. However, failing to give notice of exercise after 5 years will in one case (extendibleProvision) result in the swap terminating after 5 years and in the other case (cancelableProvision) result in the swap terminating after 10 years, i.e. action after 5 years is required in one case to lengthen the term of the swap in the other to shorten it.

####

6.3.6 Swaption

The option to enter into a swap is defined as its own product and contains the underlying swap as a swap element. A swaption straddle is defined by setting the swaptionStraddle element to true: this implies that the swaption buyer has the right, on exercise, to decide whether to pay or receive fixed on the underlying swap. If the underlying does not contain a single fixed stream and a single floating stream then the straddle is invalid and thus this flag should be set to false..

####

6.3.7 Cap / Floor

Caps and Floors are defined as one or more capFloorStreams and zero or more additionalPayments. The capFloorStream re-uses the InterestRateStream entity and thus its content is identical to a swapStream.

Though a capFloorStream allows the definition of fixed streams or known amount streams these are not the intended use of this component and there use would be considered an invalid FpML trade.

The floatingRateCalculation component has been amended to allow the specification of cap/floor structures within a single stream (e.g. straddles, corridors). The changes are:

- The occurrence rules for the components capRateSchedule and floorRateSchedule have been changed from 'zero or one' to 'zero or more'.
- An optional buyer and seller reference have been added to these schedules

These additions allow for multiple cap and floor rates to be added to the stream and to define precisely which party bought and sold them. To maintain backward compatibility with FpML1.0 the buyer and seller are optional. When absent the following rules apply:

- CapRateSchedule: BUYER = Stream payer SELLER = Stream receiver
- floorRateSchedule: BUYER = Stream receiver SELLER = Stream payer

## 7 CREDIT DERIVATIVE PRODUCT ARCHITECTURE

### 7.1 Introduction

This section provides an in-depth review of the product architecture of FpML 5.5 Credit Derivatives. The products covered by FpML 5.5 Credit Derivatives are the single name credit default swap, the credit default swap index, the credit default swap basket, the credit default swap on a mortgage, and the credit default swap on a loan.

####

7.1.1 credit default swap

In order to define the scope of the credit default swap work FpML adopted the definition used in the ISDA Year End 2001 Flash Survey:

"In a credit default swap one counterparty (the protection seller) agrees to compensate another counterparty (the protection buyer) if a specified company or Sovereign (the reference entity) experiences a credit event, indicating it is or may be unable to service its debts. The protection seller is paid a fee and/or premium, expressed as an annualized percent of the notional in basis points, regularly over the life of the transaction."

The FpML 5.5 Credit Derivatives Product Architecture draws heavily on the 2003 ISDA Credit Derivatives Definitions (hereafter referred to as the "2003 Definitions"). Wherever feasible the terminology and practice of the ISDA definitions has been adopted to ensure consistency between traditional and FpML contract representations. Appendix A lists the elements in FpML 5.5 Credit Derivatives that differ in name from their corresponding terms in the 2003 Definitions. In FpML 5.5 it is possible to represent credit default swap trades done under either the 1999 or the 2003 definitions.

The FpML 5.5 Credit Derivatives Subschema supports both a full confirmation and a transaction supplement (i.e. economics of the trade) representation of the credit default swap. The transaction supplement representation is a subset of the elements contained in the full confirmation representation. This flexible approach makes FpML 5.5 Credit Derivatives usable in all stages of the credit default swap trade lifecycle.

####

7.1.2 credit default swap index

Product support for the credit default swap index was added to FpML in version 4.1. The FpML representation for this product is closely based on the credit default swap work that first appeared in FpML 4.0. In fact, the index trade itself is described using the creditDefaultSwap element. Only a transaction supplement representation of a credit default swap index is supported.

Support for tranches on credit default swap indices was added in version 4.2.

####

7.1.3 mortgage credit default swap

Product support for the credit default swap on a mortgage was added to FpML in version 4.3. The support includes the representation of a mortgage underlyer and the addition of additional structures within the creditDefaultSwap product representation.

##### 7.1.3.1 Main differences between Mortgage and Corporate CDS

Underlying product | Mortgage | Corporate
Traded on | Reference obligation | Reference entity
Credit Events | Failure to pay principal; Write down – occurs when the reference obligation is written down (realized losses usually); Distressed ratings downgrade; Maturity extension; Failure to Pay Interest | Bankruptcy; Failure to pay; Restructuring; Sovereign failure to pay, in case of emerging market underlyers
Interest Shortfall | Interest does not have to be fully paid, and can be reimbursed at a later time | Not applicable
Factors | Bonds factor down, as mortgages are paid down | No factor issues
Payment frequency | Monthly | Quarterly
Maturity | Generally 30 year bonds. The CDS trade terminates with the maturity of the underlyer | Five or ten years are most common. CDS trades terminate with the maturity of the underlyer or a credit event

##### 7.1.3.2 The Pay-As-You-Go model

While single name corporate CDS are terminated once a credit event occurs, mortgage CDS persist.

A failure to pay principal or interest by some underlying mortgagors results in a shortfall, which is then compensated by the protection seller, in accordance to the contract terms. If those mortgagors reimburse those defaults at a later point, this will result into a corresponding ‘additional fixed payment amount’ that will be returned by the production buyer.

Those ‘floating rate payment events’ and ‘additional fixed payments’ can exist without occurrence of a credit event. A typical case would be when a failure to pay interests is not eligible as a credit event (but specified as an eligible floating rate payment event).

####

7.1.4 loan credit default swap

Product support for the credit default swap on a loan was added to FpML in version 4.3. The support includes the representation of a loan underlyer and the addition of additional structures within the creditDefaultSwap product representation.

The Loan CDS approach is tackled through two extensions to the reference information:

- the securedList element as an optional last child of Reference Information, which means that the reference obligation is not required if Secured List is present and true; this follows the normal naming convention in FpML for elements relating to ISDA Applicable or Non Applicable Legal Terms.
- the loan underlyer to the list of available products as part of the Reference Obligation.

####

7.1.5 credit default swap option

Product support for credit default swap option was added to FpML in version 4.3. The support is based on the creation of a new creditDefaultSwapOption product. As part of this work, some option structures have been generalized to be reused across multiple types of options.

The credit default swap underlyer is supported by referencing the existing creditDefaultSwap product element within the new creditDefaultSwapOption product.

### 7.2 creditDefaultSwap

Like all other derivative products supported by FpML, the type used to represent the credit default swap, the credit default swap index, and the credit default swap basket, CreditDefaultSwap, is defined as an extension of the Product type and the corresponding creditDefaultSwap element belongs to the product substitution group. The creditDefaultSwap element appears in Figure 1.

Figure 1: creditDefaultSwap element

2003 Confirmation | FpML creditDefaultSwap Element
General Terms | generalTerms
Fixed Rate Payments | feeLeg
Floating Payment | protectionTerms
Settlement Terms | Not included in Transparency view
Notice and Account Details | N/A
Offices | N/A

Figure 2: Sections of the 2003 Confirmation and their corresponding FpML creditDefaultSwap elements.

Additional points to note:

- The id attribute and the productType and productId elements are inherited from the product type. They are not credit derivatives specific. Each product supported by FpML contains these elements.
- Although Settlement Terms are specified on a full confirmation, they are not required for Transparency view. Therefore, the equivalent element (physicalSettlementTerms or cashSettlementTerms) are not supported in Transparency view of FpML 5.5.
- The Notice and Account Details and Offices sections of the confirmation do not have a direct analog in the FpML 5.5 definition of the credit default swap. In FpML, the party elements that appear under the FpML root element serve the purpose these sections do in the traditional confirm.

The remainder of this document reviews each child element of the creditDefaultSwap.

### 7.3 generalTerms

The generalTerms element, which appears in Figure 3, represents the information specified in the General Terms section of the 2003 Confirmation.

Figure 3: generalTerms Element

The effectiveDate element represents the Effective Date term. In order to optionally allow the explicit specification of a particular business day convention per the 2003 Definitions this element is of type AdjustableDate2. The effectiveDate is optional for the transaction supplement representation of some credit default swap indices.

The scheduledTerminationDate element represents the Scheduled Termination Date term. This element can be specified as either an adjustable date or a relative date. For confirmation and transparency purposes a specific date will always be specified. Again, the AdjustableDate2 type allows the parties to explicitly specify a particular business day convention per the 2003 Definitions. The Interval type (e.g. 5 Y for a five year deal) is included because this way of expressing a scheduled termination date is quite commonly used in historical price databases. The scheduled termination date is optional for the transaction supplement representation of some credit default swap indices. The effectiveDate and scheduledTerminationDate should always be included for a credit default swap.

The referenceInformation element is used in the representation of a credit default swap. The indexReferenceInformation element is used in the representation of a credit default swap index. The basketReferenceInformation element is used in the representation of a credit default swap basket.

The full expansion of the referenceInformation element appears in figure 4. Two of its child elements, referenceEntity and referenceObligation, are used to represent the Reference Entity and Reference Obligation(s) terms respectively.

The referenceEntity element is of type LegalEntity and is required. The LegalEntity type requires an entityName and/or an entityId to be provided. Both the entityName and the entityId are represented using schemes, which allow the source (e.g. reference database) of the information to be recorded.

####

7.3.3 referenceObligation

A referenceObligation element has either a bond, a convertibleBond, a mortgage, or loan as one of its child elements. The bond, convertibleBond, mortgage, and loan elements are shared FpML elements. In other words, they were not created specifically to support credit derivatives and are also used in other asset classes.

##### 7.3.3.1 bond and convertibleBond

For a credit default swap, bond or convertibleBond is used to specify a Reference Obligation's CUSIP/ISIN, Maturity and Coupon values. The instrumentId element is used to specify CUSIP/ISIN. The mandatory instrumentIdScheme is used to specify whether the id provided is a CUSIP or an ISIN. Since multiple occurrences of instrumentId are allowed, the schema supports the specification of both the obligation's CUSIP and ISIN, if they both exist. The couponRate and maturity elements are used to represent the Coupon and Maturity terms respectively.

##### 7.3.3.2 mortgage

A mortgage underlyer was added to the underlying classes that are part of the ReferenceObligation structure in order to support cds on mortgage. This Mortgage type uses most of the structures present at other underlying assets.

The extensions specific to the mortgage structure are the following:

- The originalPrincipalAmount element, which schema definition is 'The initial issued amount of the mortgage obligation'.
- The pool, which specifies the underlying mortgage pool through an initialFactor and a currentFactor elements. An optional versionHistory group provides the ability to indicate the version of the pool. In the ISDA long form definition, this initialFactor is used as an input for specifying the 'Applicable Percentage' that is used throughout the life the trade for representing the effect of the mortgage factor updates.
- The sector, defined in the schema as 'The sector classification of mortgage obligations'. This element is specified as a normalized string that optionally refers to the mortgageSectorScheme. This scheme contains the mortgage typology currently in use by the marketplace: ABS, CDO, CMBS and RMBS.
- The tranche specifies the mortgage obligation tranche that is subject to the derivative transaction. There can only be one tranche. No scheme is associated with the tranche, as there is no current classification or normalization of those mortgage tranches.

##### 7.3.3.3 loan

A loan underlyer was added to the list of available product classes as part of the Reference Obligation. This Loan type extends Underlying Asset structure.

The extensions specific to the loan structure are the following:

- The borrowerName or borrowerPartyReference on Loan CDS is meant to be used in the event that there is no Bloomberg Id or the Secured List isn't applicable, and has been modeled in the same way as the insurerName or insurerPartyReference on Mortgage CDS.
- The lien specifies the seniority level of the lien..
- The facilityType describes the type of the loan facility and is specified through the facility-type-1-0.xml scheme file. Defined values are “BridgeLoan”, “LetterOfCredit”, “RevolvingLoan”, “SwinglineFunding”, “TermLoan” and “TradeClaim”.
- The maturity is the maturity date of the loan.
- The creditAgreementDate is the closing date (the date where the agreement has been signed) for the loans in the credit agreement. Funding of the facilities occurs on (or sometimes a little after) the Credit Agreement date. This underlyer attribute is used to help identify which of the company's outstanding loans are being referenced by knowing to which credit agreement it belongs. ISDA Standards Terms Supplement term: Date of Original Credit Agreement.
- While the tranche element is present for both the mortgage and loan extensions, its usage is different across those 2 underlyers:

- In the mortgage case, the instrument Id is used to indicate the Bloomberg reference number of the mortgage, while the tranche element is used to qualify the specific tranche that is subject to the derivative transaction.
- With the loan, the Bloomberg number qualifies both the loan and the tranche. As a result, the instrument Id is used to specify the loan’s Cusip, while the tranche is used to specify the Bloomberg number. Consequently, a transcheIdScheme is being associated to the tranche element.

To represent the Primary Obligor term a referenceObligation element may optionally have either a primaryObligor or a primaryObligationReference element. If the Primary Obligor is the Reference Entity, then primaryObligorReference should be used. Its href attribute will contain the id attribute of the referenceEntity. Otherwise, the primaryObligor element, which is of type LegalEntity, should be used.

Similarly, to represent the Guarantor term a referenceObligation element may optionally have either a guarantor or a primaryObligationReference element. If the Guarantor is the Reference Entity, then guarantorReference should be used. Its href attribute will contain the id attribute of the referenceEntity. Otherwise, the guarantor element, which is of type LegalEntity, should be used.

The optional allGuarantees and referencePrice are used to represent the terms All Guarantees and Reference Price respectively.

####

7.3.4 referenceInformation

Figure 4: referenceInformation element

Although the structure of referenceInformation appears to be somewhat complex, the specification of Reference Entity and Reference Obligation information in FpML documents is quite simple, straightforward and flexible. An example bears this out:

- Reference Entity: Bundesrepublic Deutschland
- Primary Obligor: Reference Entity
- Guarantor: None
- Coupon Rate: 5%
- Date Maturity: 2012-7-4
- ISIN/Cusip: DE0001135200
- Reference Price: 100%

In order to support the full credit default swap trade lifecycle, the schema allows this information to be expressed in various degrees of detail:

Example 1 - Reference Entity only:

    <referenceInformation>
      <referenceEntity>
        <entityName>Bundesrepublic Deutschland</entityName>
      </referenceEntity>
      <noReferenceObligation/>
    </referenceInformation>

Example 2 - Reference Entity and ISIN of the Reference Obligation with optional scheme attributes:

    <referenceInformation>
      <referenceEntity>
        <entityName>Bundesrepublic Deutschland</entityName>
        </referenceEntity>
      <referenceObligation>
        <bond>
          <instrumentId instrumentIdScheme =
    "http://www.fpml.org/spec/2002/instrument-id-ISIN-1-0">DE0001135200</instrumentId>
        </bond>
      </referenceObligation>
    </referenceInformation>

Example 3 - Full Representation of Reference Entity and Reference Obligation terms:

    <referenceInformation>
       <referenceEntity id ="DBR">
    	<entityName>Bundesrepublic Deutschland</entityName>
      </referenceEntity>
      <referenceObligation>
        <bond>
          <instrumentId
            instrumentIdScheme =
    "http://www.fpml.org/spec/2002/instrument-id-ISIN-1-0">DE0001135200</instrumentId>
          <couponRate>.05</couponRate>
          <maturity>2012-07-04</maturity>
        </bond>
        <primaryObligorReference href =
    "DBR"/>
      </referenceObligation>
      <referencePrice>1</referencePrice>
    </referenceInformation>

The referencePolicy element is applicable to the transactions on mortgage-backed security, which can make use of a reference policy. Presence of the element indicates that the reference policy is applicable; absence implies that it is not.

####

7.3.5 indexReferenceInformation

The indexReferenceInformation element appears in the Figure 5. This element is used to identify the index referenced by a credit default swap index trade.

The indexReferenceInformation element is structurally very similar to the referenceEntity element. The indexReferenceInformation element identifies a collection of (Reference Entity, Reference Obligation) pairs issued by an index sponsor (e.g. iBoxx, TRAC-X). The referenceEntity element, on the other hand, identifies a specific Reference Entity.

Figure 5: indexReferenceInformation element

The identification is accomplished by a combination of the indexId and the indexName elements. There are optional elements to explicitly define the index series number, the version number of the index series annex, the annex publication date and the source of the relevant annex (the elements indexSeries, indexAnnexVersion, indexAnnexDate and indexAnnexSource respectively) (for a given series, multiple versions of the “annex” may be published over time). The indexSeries and indexAnnexVersion elements are of integer type, the indexAnnexDate element is of date type and the indexAnnexSource element is of complex type IndexAnnexSource (which is of base type string).

The indexAnnexSource element corresponds to the field ‘Source of Relevant Annex’ that appears in the Dow Jones CDX form of Transaction Supplement and it is proposed an FpML-defined Scheme is defined with initial possible values of “Publisher” and “Master Confirmation”. These values have the meanings ascribed to them in the Dow Jones CDX General Terms Confirmation (A value of “Publisher” implies the relevant annex for a transaction is the list for the relevant index with the relevant annex date published by Mark-it Partners).

See the Mark-it Partners website (http://www.mark-it.com) for examples of published annexes for the CDX and iTraxx index families.

An additional optional repeating element excludedReferenceEntity is also proposed to support the iTraxx and CDX forms of Transaction Supplement which allow for specific reference entities in the index to be excluded by making reference to them in the Transaction Supplement. This element uses the existing LegalEntity type.

Identifying a credit default swap index with indexReferenceInformation is quite straightforward. Like referenceInformation, it allows for this information to be expressed in various degrees of detail.

Some illustrative example FpML snippets including the optional elements follow:

    <generalTerms>
      ...
      <indexReferenceInformation>
        <indexName>Dow Jones CDX.NA.IG.3 Version 1</indexName>
        <indexId indexIdScheme="http://www.fpml.org/spec/2003/instrument-id-RED-pair-1-0">123456789</indexId>
        <indexSeries>3</indexSeries>
        <indexAnnexVersion>1</indexAnnexVersion>
        <indexAnnexDate>2004-09-20</indexAnnexDate>
        <indexAnnexSource>Publisher</indexAnnexSource>
      </indexReferenceInformation>
      ...
    </generalTerms>

    <generalTerms>
      ...
      <indexReferenceInformation>
        <indexName>Dow Jones iTraxx Europe Series 2 Version 1</indexName>
        <indexId indexIdScheme="http://www.fpml.org/spec/2003/instrument-id-RED-pair-1-0">123456789</indexId>
        <indexSeries>2</indexSeries>
        <indexAnnexVersion>1</indexAnnexVersion>
        <indexAnnexDate>2004-09-17</indexAnnexDate>
        <excludedReferenceEntity>
          <entityName>Acme Inc.</entityName>
          <entityId entityIdScheme="http://www.fpml.org/spec/2003/entity-id-RED-1-0">123456</entityId>
        </excludedReferenceEntity>
      </indexReferenceInformation>
      ...
    </generalTerms>

##### 7.3.5.1 Index Tranche

The optional tranche element allows the specification of index tranches. The structure requires an attachment point and an exhaustion point and optionally the applicability of the legal term Incurred Recovery.

##### 7.3.5.2 Settled Entity Matrix

The Dow Jones CDX Tranche Transactions Standard Terms Supplement requires the "Source of Relevant Settled Entity Matrix" field on a Confirmation. The optional settledEntityMatrix element supports it. It contains a required matrixSource element and an optional publicationDate element.

    <generalTerms>
      ...
      <indexReferenceInformation>
    	<indexName>Dow Jones iTraxx Europe Consumers Series 2 Version 1</indexName>
    	<indexSeries>2</indexSeries>
    	<indexAnnexVersion>1</indexAnnexVersion>
    	<tranche>
    		<attachmentPoint>0.03</attachmentPoint>
    		<exhaustionPoint>0.07</exhaustionPoint>
    	</tranche>
    	<settledEntityMatrix>
    		<matrixSource>NotApplicable</matrixSource>
    	</settledEntityMatrix>
      </indexReferenceInformation>
      ...
    </generalTerms>

Several terms that appear in the General Terms section of the 2003 Confirmation do not appear in the generalTerms element because elements to represent these terms already existed in the FpML trade element. The terms that belong to this category appear in Figure 6 along with their corresponding FpML element.

ISDA Confirmation Term | FpML Element
Trade Date | trade.tradeHeader.tradeDate
Calculation Agent | trade.calculationAgent.calculationAgentPartyReference
Calculation Agent City | trade.calculationAgentBusinessCenter

Figure 6 General Terms that do not appear in creditDefaultSwap.generalTerms element.

### 7.4 feeLeg

####

7.4.1 Credit default swap

The feeLeg element represents the information specified in the Fixed Payments section of the 2003 Confirmation. In other words, this is where the payment stream from Fixed Rate Payer to the Floating Rate Payer is specified. This element reuses types and elements from FpML 5.5 Interest Rate Derivatives.

The feeLeg allows representation of the following types of payment schedules for a credit default swap using a combination of the singlePayment and periodicPayment elements:

- Fixed Rate, Regular Schedule
- Upfront Fee and Fixed Rate, Regular Schedule

In addition, it's important to note that the use of initialPayment allows the representation of the situation when the seller of protection pays a fee to the buyer as an upfront payment. An example of this scenario is the payment in exchange for an agreed modification of the first period start date.

Figure 7: feeLeg element

In transparency view, the fixed leg is limited to representing the fixed rate for a periodic payment, and optionally an upfront fee.

The addition of the adjustedPaymentDate element within singlePayment and adjustedPaymentDates component in periodicPayment allows the optional inclusion of a 'cashflows' like structure consistent with what was done in FpML 5.5 Interest Rate Derivatives. Note these structures are intended more for internal application integration use rather than external communication, i.e. Wouldn't be applicable for confirmations.

Here are some example fee schedules:

Example 1 - Fixed Rate - Regular Schedule:

- Effective Date: 1 November, 2002
- Scheduled Termination Date: 1 November, 2007
- Notional Amount: USD 5,000,000
- Fixed Rate: .85%
- Payment Frequency: Quarterly
- Day Count Fraction: ACT/360

    <feeLeg>
      <periodicPayment>
        <paymentFrequency>
          <periodMultiplier>3</periodMultiplier>
          <period>M</period>
        </paymentFrequency>
        <rollConvention>1</rollConvention>
        <fixedAmountCalculation>
    	    <calculationAmount>
    		    <currency>USD</currency>
    		    <amount>5000000</amount>
    	    </calculationAmount>
          <fixedRate>0.0085</fixedRate>
          <dayCountFraction dayCountFractionScheme="http://www.fpml.org/spec/2004/
    day-count-fraction-1-0">ACT/360</dayCountFraction>
        </fixedAmountCalculation>
      </periodicPayment>
    </feeLeg>

or in a Transaction Supplement

    <feeLeg>
      <periodicPayment>
        <paymentFrequency>
          <periodMultiplier>3</periodMultiplier>
          <period>M</period>
        </paymentFrequency>
        <rollConvention>1</rollConvention>
        <fixedAmountCalculation>
          <fixedRate>0.0085</fixedRate>
        </fixedAmountCalculation>
      </periodicPayment>
    </feeLeg>

Example 2 - Fixed Amount - Regular Schedule:

- Effective Date: 1 November, 2002
- Scheduled Termination Date: 1 November, 2007
- Notional Amount: USD 5,000,000
- Fixed Amount: USD 10,625
- Payment Frequency: Quarterly
- Day Count Fraction: ACT/360

    <feeLeg>
      <periodicPayment>
        <paymentFrequency>
          <periodMultiplier>3</periodMultiplier>
          <period>M</period>
        </paymentFrequency>
        <rollConvention>1</rollConvention>
        <fixedAmount>
          <currency>USD</currency>
          <amount>10625.00</amount>
        </fixedAmount>
      </periodicPayment>
    </feeLeg>

Example 3 - Fixed Rate - Month-End Rolls:

- Effective Date: 30 September, 2002
- Scheduled Termination Date: 30 September, 2007
- Notional Amount: USD 5,000,000
- Fixed Rate: .85%
- Payment Frequency: Quarterly on each December 31, March 31, June 30 and September 30
- Day Count Fraction: ACT/360

    <feeLeg>
      <periodicPayment>
        <paymentFrequency>
          <periodMultiplier>3</periodMultiplier>
          <period>M</period>
        </paymentFrequency>
        <rollConvention>EOM</rollConvention>
        <fixedAmountCalculation>
          <calculationAmount>
            <currency>USD</currency>
            <amount>5000000</amount>
          </calculationAmount>
          <fixedRate>0.0085</fixedRate>
          <dayCountFraction dayCountFractionScheme="http://www.fpml.org/spec/2004/
    day-count-fraction-1-0">ACT/360</dayCountFraction>
        </fixedAmountCalculation>
      </periodicPayment>
    </feeLeg>

or in a Transaction Supplement

    <feeLeg>
      <periodicPayment>
        <paymentFrequency>
          <periodMultiplier>3</periodMultiplier>
          <period>M</period>
        </paymentFrequency>
        <rollConvention>EOM</rollConvention>
        <fixedAmountCalculation>
          <fixedRate>0.0085</fixedRate>
        </fixedAmountCalculation>
      </periodicPayment>
    </feeLeg>

Example 4 - Fixed Rate - Initial (Short) Stub:

- Effective Date: 30 September, 2002
- Scheduled Termination Date: 1 November, 2007
- Notional Amount: USD 5,000,000
- Fixed Rate: .85%
- Payment Frequency: 1 November 2002 and each February 1, May 1, August 1 and November 1
- Day Count Fraction: ACT/360

    <feeLeg>
      <periodicPayment>
        <paymentFrequency>
          <periodMultiplier>3</periodMultiplier>
          <period>M</period>
        </paymentFrequency>
        <firstPaymentDate>2002-11-01</firstPaymentDate>
        <rollConvention>1</rollConvention>
        <fixedAmountCalculation>
          <fixedRate>0.0085</fixedRate>
        </fixedAmountCalculation>
      </periodicPayment>
    </feeLeg>

Example 5 - Fixed Rate - Initial (Long) Stub:

- Effective Date: 30 September, 2002
- Scheduled Termination Date: 1 November, 2007
- Notional Amount: USD 5,000,000
- Fixed Rate: .85%
- Payment Frequency: 1 February 2003 and each May 1, August 1, November 1 and February 1
- Day Count Fraction: ACT/360

    <feeLeg>
     <periodicPayment>
        <paymentFrequency>
          <periodMultiplier>3</periodMultiplier>
          <period>M</period>
        </paymentFrequency>
        <firstPaymentDate>2003-02-01</firstPaymentDate>
        <rollConvention>1</rollConvention>
        <fixedAmountCalculation>
          <fixedRate>0.0085</fixedRate>
        </fixedAmountCalculation>
      </periodicPayment>
    </feeLeg>

Example 6 - Fixed Amount - Single Payment:

- Effective Date: 1 November, 2002
- Scheduled Termination Date: 1 November, 2007
- Notional Amount: USD 5,000,000
- Fixed Amount: USD 100,000
- Payment Date: 2 November 2002

    <feeLeg>
      <singlePayment>
        <adjustablePaymentDate>2002-11-02</adjustablePaymentDate>
        <fixedAmount>
          <currency>USD</currency>
          <amount>100000.00</amount>
        </fixedAmount>
      </singlePayment>
    </feeLeg>

Example 7 - Upfront Fee combined with Fixed Rate Regular Schedule

- Effective Date: 1 November, 2002
- Scheduled Termination Date: 1 November, 2007
- Notional Amount: USD 5,000,000
- Upfront Payment Amount: USD 100,000
- Upfront Payment Date: 2 November 2002
- Fixed Rate: .85%
- Payment Frequency: Quarterly
- Day Count Fraction: ACT/360

    <feeLeg>
      <singlePayment>
        <adjustablePaymentDate>2002-11-02</adjustablePaymentDate>
        <fixedAmount>
          <currency>USD</currency>
          <amount>100000.00</amount>
        </fixedAmount>
      </singlePayment>
      <periodicPayment>
        <paymentFrequency>
          <periodMultiplier>3</periodMultiplier>
          <period>M</period>
        </paymentFrequency>
        <rollConvention>1</rollConvention>
        <fixedAmountCalculation>
          <fixedRate>0.0085</fixedRate>
        </fixedAmountCalculation>
      </periodicPayment>
    </feeLeg>

Example 8 - Irregular Payment Schedule

- Effective Date: 1 November, 2002
- Scheduled Termination Date: 1 November, 2007
- Notional Amount: USD 5,000,000
- Fixed Amount of USD 100,000 on 2 November 2002 and USD 50,000 on 2 December 2002 .

    <feeLeg>
      <singlePayment>
        <adjustablePaymentDate>2002-11-02</adjustablePaymentDate>
        <fixedAmount>
          <currency>USD</currency>
          <amount>100000.00</amount>
        </fixedAmount>
      </singlePayment>
      <singlePayment>
        <adjustablePaymentDate>2002-12-02</adjustablePaymentDate>
        <fixedAmount>
          <currency>USD</currency>
          <amount>50000.00</amount>
        </fixedAmount>
      </singlePayment>
    </feeLeg>

Example 9 - Fixed Rate - Final (Short) Stub:

- Effective Date: 18 February, 2003
- Scheduled Termination Date: 20 March, 2008
- Notional Amount: USD 5,000,000
- Fixed Rate: .9%
- Payment Frequency: 20 March 2003 and each June 20, September 20 and March 20.
- Day Count Fraction: ACT/360

    <feeLeg>
      <periodicPayment>
        <paymentFrequency>
          <periodMultiplier>3</periodMultiplier>
          <period>M</period>
        </paymentFrequency>
        <lastRegularPaymentDate>2003-03-20</lastRegularPaymentDate>
        <rollConvention>20</rollConvention>
        <fixedAmountCalculation>
          <fixedRate>0.009</fixedRate>
        </fixedAmountCalculation>
      </periodicPayment>
    </feeLeg>

Example 10 - Fixed Rate - Regular Schedule (Including Optional Cashflows):

- Effective Date: 1 November, 2002
- Scheduled Termination Date: 1 November, 2003
- Notional Amount: USD 5,000,000
- Fixed Rate: .85%
- Payment Frequency: Quarterly
- Day Count Fraction: ACT/360

Note that the adjustedPaymentDate element values have not been adjusted for any applicable business days.

    <feeLeg>
      <periodicPayment>
        <paymentFrequency>
          <periodMultiplier>3</periodMultiplier>
          <period>M</period>
        </paymentFrequency>
        <rollConvention>1</rollConvention>
        <fixedAmountCalculation>
          <calculationAmount>
            <currency>USD</currency>
            <amount>5000000</amount>
          </calculationAmount>
          <fixedRate>0.0085</fixedRate>
          <dayCountFraction dayCountFractionScheme="http://www.fpml.org/spec/2004/
    day-count-fraction-1-0">ACT/360</dayCountFraction>
        </fixedAmountCalculation>
        <adjustedPaymentDates>
          <adjustedPaymentDate>2003-02-01</adjustedPaymentDate>
          <fixedAmount>
            <currency>USD</currency>
            <amount>10625.00</amount>
          </fixedAmount>
        </adjustedPaymentDates>
        <adjustedPaymentDates>
          <adjustedPaymentDate>2003-05-01</adjustedPaymentDate>
          <fixedAmount>
            <currency>USD</currency>
            <amount>10625.00</amount>
          </fixedAmount>
        </adjustedPaymentDates>
        <adjustedPaymentDates>
          <adjustedPaymentDate>2003-08-01</adjustedPaymentDate>
          <fixedAmount>
            <currency>USD</currency>
            <amount>10625.00</amount>
          </fixedAmount>
        </adjustedPaymentDates>
        <adjustedPaymentDates>
          <adjustedPaymentDate>2003-11-01</adjustedPaymentDate>
          <fixedAmount>
            <currency>USD</currency>
            <amount>10625.00</amount>
          </fixedAmount>
        </adjustedPaymentDates>
      </periodicPayment>
    </feeLeg>

Example 11 - firstPeriodStartDate - Novations Support

Suppose the following Old Transaction is Novated with the following information:

- Effective Date: 9 June, 2004
- Scheduled Termination Date: 20 June, 2009
- First Fixed Rate Payer Payment Date: 20 September, 2004
- Novation Trade Date: 21 September, 2004
- Novation Date: 22 September, 2004

Old Transaction FpML (abbreviated) representation:

    <creditDefaultSwap>
      <generalTerms>
        <effectiveDate>
          <unadjustedDate>2004-06-09</unadjustedDate>
          <dateAdjustments>
            <businessDayConvention>NONE</businessDayConvention>
          </dateAdjustments>
        </effectiveDate>
        <scheduledTerminationDate>
          <adjustableDate>
            <unadjustedDate>2009-06-20</unadjustedDate>
            <dateAdjustments>
              <businessDayConvention>NONE</businessDayConvention>
            </dateAdjustments>
          </adjustableDate>
        </scheduledTerminationDate>
        ...
      </generalTerms>
      <feeLeg>
        <periodicPayment>
          <paymentFrequency>
            <periodMultiplier>3</periodMultiplier>
            <period>M</period>
          </paymentFrequency>
          <firstPaymentDate>2004-09-20</firstPaymentDate>
          <rollConvention>20</rollConvention>
          <fixedAmountCalculation>
            <calculationAmount>
              <currency>EUR</currency>
              <amount>5000000.0</amount>
            </calculationAmount>
            <fixedRate>0.0125</fixedRate>
            <dayCountFraction dayCountFractionScheme="http://www.fpml.org/spec/2004/
    day-count-fraction-1-0">ACT/360</dayCountFraction>
          </fixedAmountCalculation>
        </periodicPayment>
      </feeLeg>
      ...
    </creditDefaultSwap>

For the New Transaction the FpML representation would show:

- Effective Date: 22 September, 2004 (the Novation Date)
- Scheduled Termination Date: 20 June, 2009
- First Fixed Rate Payer Payment Date: 20 December, 2004
- Initial Calculation Period Start Date (element firstPeriodStartDate): 20 September, 2004

New Transaction FpML (abbreviated) representation:

    <creditDefaultSwap>
      <generalTerms>
        <effectiveDate>
          <unadjustedDate>2004-09-22</unadjustedDate>
          <dateAdjustments>
            <businessDayConvention>NONE</businessDayConvention>
          </dateAdjustments>
        </effectiveDate>
        <scheduledTerminationDate>
          <adjustableDate>
            <unadjustedDate>2009-06-20</unadjustedDate>
            <dateAdjustments>
              <businessDayConvention>NONE</businessDayConvention>
            </dateAdjustments>
          </adjustableDate>
        </scheduledTerminationDate>
        ...
      </generalTerms>
      <feeLeg>
        <periodicPayment>
          <paymentFrequency>
            <periodMultiplier>3</periodMultiplier>
            <period>M</period>
          </paymentFrequency>
          <firstPeriodStartDate>2004-09-20</firstPeriodStartDate>
          <firstPaymentDate>2004-12-20</firstPaymentDate>
          <rollConvention>20</rollConvention>
          <fixedAmountCalculation>
            <calculationAmount>
              <currency>EUR</currency>
              <amount>5000000.0</amount>
            </calculationAmount>
            <fixedRate>0.0125</fixedRate>
            <dayCountFraction dayCountFractionScheme="http://www.fpml.org/spec/2004/
    day-count-fraction-1-0">ACT/360</dayCountFraction>
          </fixedAmountCalculation>
        </periodicPayment>
      </feeLeg>
      ...
    </creditDefaultSwap>

Example 12 - Periodic payments - stepping notional

A credit default swap pays 100bp every 3 months. The notional starts at 5M but steps down twice throughout the life of the deal (only the relevant portions of FpML are shown):

    <feeLeg>
      <periodicPayment>
        <paymentFrequency>
          <periodMultiplier>3</periodMultiplier>
          <period>M</period>
        </paymentFrequency>
        <rollConvention>1</rollConvention>
        <fixedAmountCalculation>
          <calculationAmount>
            <currency>USD</currency>
            <amount>5000000</amount>
            <step>
              <stepDate>2002-03-01</stepDate>
              <stepValue>4000000</stepValue>
            </step>
            <step>
              <stepDate>2002-09-01</stepDate>
              <stepValue>3000000</stepValue>
            </step>
          </calculationAmount>
          <fixedRate>0.010</fixedRate>
          <dayCountFraction>ACT/360</dayCountFraction>
        </fixedAmountCalculation>
      </periodicPayment>
    </feeLeg>
    <protectionTerms>
      <calculationAmount>
        <currency>USD</currency>
        <amount>5000000</amount>
        <step>
          <stepDate>2002-03-01</stepDate>
          <stepValue>4000000</stepValue>
        </step>
        <step>
          <stepDate>2002-09-01</stepDate>
          <stepValue>3000000</stepValue>
        </step>
      </calculationAmount>
      <creditEvents>
        <defaultRequirement>
          <currency>USD</currency>
          <amount>10000000</amount>
        </defaultRequirement>
    	...

Example 13 - Irregular Payments, stepping notional

In this example, payments are made at irregular intervals (note that there is no June payment). Also the amount of each payment is determined based on notional that change over time:

    <feeLeg>
      <singlePayment>
        <adjustablePaymentDate>2001-12-01</adjustablePaymentDate>
        <fixedAmount>
          <currency>USD</currency>
          <amount>230.50</amount>
        </fixedAmount>
      </singlePayment>
      <singlePayment>
        <adjustablePaymentDate>2002-03-01</adjustablePaymentDate>
        <fixedAmount>
          <currency>USD</currency>
          <amount>219.20</amount>
        </fixedAmount>
      </singlePayment>
      <singlePayment>
        <adjustablePaymentDate>2002-9-01</adjustablePaymentDate>
        <fixedAmount>
          <currency>USD</currency>
          <amount>500.00</amount>
        </fixedAmount>
    </singlePayment>
      <periodicPayment>
         <fixedAmountCalculation>
          <calculationAmount>
            <currency>USD</currency>
            <amount>5000000</amount>
            <step>
              <stepDate>2002-03-01</stepDate>
              <stepValue>4000000</stepValue>
            </step>
            <step>
              <stepDate>2002-09-01</stepDate>
              <stepValue>3000000</stepValue>
            </step>
          </calculationAmount>
          <fixedRate>0.010</fixedRate>
          <dayCountFraction>ACT/360</dayCountFraction>
        </fixedAmountCalculation>
      </periodicPayment>
    </feeLeg>
    <protectionTerms>
      <calculationAmount>
        <currency>USD</currency>
        <amount>5000000</amount>
        <step>
          <stepDate>2002-03-01</stepDate>
          <stepValue>4000000</stepValue>
        </step>
        <step>
          <stepDate>2002-09-01</stepDate>
          <stepValue>3000000</stepValue>
        </step>
      </calculationAmount>
    	...

####

7.4.2 Credit default swap index

The payment information that appears in the transaction supplement representation of a credit default swap index trade is expressed in FpML by using the initialPayment and periodicPayment/fixedAmountCalculation elements.

Trades on credit default swap indices generally have an upfront payment associated with them. Unlike upfront payments on credit default swap trades, the initial payment can be from either protection buyer to protection seller or from protection seller to protection buyer. To address this requirement, an additional optional element called initialPayment has been added to feeLeg in FpML 4.1. This element is intended to be used solely in the representation of a credit default swap index trade.

The structure of initialPayment can be seen in figure 6. The major difference between initialPayment and singlePayment is that initialPayment allows the specification of which party is making the payment (payerPartyReference) and which is receiving it (receiverPartyReference).

Unlike a credit default swap trade, a credit index trade has two fixed rates associated with it:

- Fixed Rate: Credit spread (“premium”) set at the time the index series is issued. Payments from the protection buyer to the protection seller are based on this value. It’s roughly analogous to the coupon on a fixed rate bond.
- Market Fixed Rate: Credit spread (“fair value”) of the index at a particular time. Varies over the life of the index depending on market conditions. This is the price quoted by the trading desks. It’s roughly analogous to the yield on a fixed rate bond.

The present value of the difference between these two fixed rates is one of the two inputs to the calculation of the initial (e.g. upfront) payment. The other component is accrued interest.

Here is an example of the payment information associated with a trade and how that information appears in FpML:

- Initial Payment: EUR 10,000
- Initial Payment Payer: XYZ Bank
- Fixed Rate: .70%
- Market Fixed Rate: .40%

    <feeLeg>
            <initialPayment>
                    <payerPartyReference href="partyA"/>
                    <receiverPartyReference href="partyB"/>
                    <paymentAmount>
                            <currency>EUR</currency>
                            <amount>10000</amount>
                    </paymentAmount>
            </initialPayment>
            <periodicPayment>
                    <fixedAmountCalculation>
                            <fixedRate>0.0070</fixedRate>
                    </fixedAmountCalculation>
            </periodicPayment>
            <marketFixedRate>0.0040</marketFixedRate>
    </feeLeg>

####

7.4.3 Mortgage derivatives

The paymentDelay has been added as a boolean element as part of the feeLeg construct to support the ISDA definition associated with the fixed amount:

Fixed Amount: | [Fixed Amount definition for underlying with no payment delay]/[Fixed Amount definition for underlying with payment delay]

Parties should make a selection that is appropriate in view of the interest basis of the Reference Obligation as set out in the Underlying Instruments. The former version may be preferred if the Reference Obligation does not have a payment delay, and the latter if it is a security with a payment delay.

The schema definition states: “Applicable to CDS on MBS to specify whether payment delays are applicable to the fixed Amount. RMBS typically have a payment delay of 5 days between the coupon date of the reference obligation and the payment date of the synthetic swap. CMBS do not, on the other hand, with both payment dates being on the 25th of each month.”

### 7.5 protectionTerms

In Transparency view the protectionTerms element contains only the protection amount (trade notional); in futures versions of the schema it may contain indicators for some commonly negotiated credit events such as "restructuring".

### 7.6 Appendix A: Naming differences between FpML 5.5 Credit Derivatives Subschema and 2003 ISDA Credit Derivatives Definitions

There are several places in the FpML 5.5 Credit Derivatives Subschema where the element names diverge from the names used for terms in the 2003 Definitions. These names are listed in the table that appear in Figure 11.

FpML Element Name | 2003 Definitions | Existing FpML Element | Clarity
sellerPartyReference | Floating Rate Payer | X | X
buyerPartyReference | Fixed Rate Payer | X | X
dateAdjustments | Business Day, Business Day Convention | X |
obligationId | CUSIP/ISIN |  | X
feeLeg | Fixed Payments |  | X
protectionTerms | Floating Payment |  | X
calculationAmount | Fixed Rate Payer Calculation Amount, Floating Rate Payer Calculation Amount |  | X
valuationDate | Valuation Date | X |
valuationTime | Valuation Time | X |
accruedInterest | Quotations | X |
excluded | Excluded Obligations | X |
excluded | Excluded Deliverable Obligations | X |
category | Obligation Category | X |
category | Deliverable Obligation Category | X |
calculationAgentPartyReference | Calculation Agent | X |

Figure 11: Naming differences between FpML 5.5 and the 2003 definitions (incomplete).

The table also indicates the reason why the FpML name diverges from the name used in the 2003 definitions. There are only two reasons for diverging:

- An appropriate FpML element already existed, but this element did not have the same name as the corresponding term in the 2003 Definitions.
- WG members thought a different name would provide greater clarity to FpML users.

## 8 FX PRODUCT ARCHITECTURE

### 8.1 FX Scope

The Scope of FpML 5.5 Recommendation includes redesigned FX product model developed by the Modeling Task Force (MTF) and FX Working Group to make it more consistent with other FpML product representations and to facilitate its further development. As a result of this work many of an original 4.x model’s issues were addressed:

- A number of sets of reusable components that facilitates product development were defined, so that the existing and future FX products will leverage these building blocks to ensure the FX model is coherent and easy to maintain, as per FpML best practices
- Extended the existing coverage to include Dual Currency Deposits and FX Flexible Forward.
- Rationalized the models' constraints:
  - Made use of grammar to bring related data together.
  - Made better use of XML schema to simplify the validation rules.

In FpML 5.5 Recommendation the following FX products are covered:

- Basic FX Products
  - FX Spot, FX Forward (including non-deliverable settlements, or NDFs) and FX Flexible Forward.
  - FX Swap
- Simple FX Option Products (including, features, cash and physical settlement)
  - FX options
    - European and American

NOTE: Some additional fields for Foreign Exchange Flexible Forward product are being considered for the next draft.

### 8.2 Foreign Exchange Spot and Forward

Foreign exchange single-legged instruments include spot and forwards. fxSingleLeg contains a reusable entity (FxCoreDetails.Model) that describes common components to FX spot, forward and swap legs: two instances of the exchangedCurrency component (the first currency and the second currency), an optional dealtCurrency that indicates which currency was dealt, either a single value date component for the trade or an optional value date per exchanged currency, an optional tenorPeriod that denotes the tenor on which both currencies traded will settle, a single instance of the exchangeRate component, and an optional nonDeliverableSettlement component.

Note: An optional confirmationSenderPartyReference (to the party that is sending the current document as a confirmation of the trade is accommodated) has been moved out from the product economics. It will be placed at the trade level.

####

8.2.1 Exchanged Currency

The simple FX transaction contains two currencies which are exchanged between parties. The characteristics of each currency exchange: the currency, the amount, and optionally settlement instructions are described in the exchangedCurrency structure. An optional payment date is allowed per currency if there is a requirement to provide for date adjustments for each currency based upon business day conventions to accommodate unscheduled holidays.

####

8.2.2 Exchange Rate

The rate of exchange is required for a foreign exchange trade. The rate of exchange includes a reusable entity (QuotedCurrencyPair) that describes the underlying composition of the rate: the currencies and the method in which the rate is quoted. The actual trade rate is required, but other rate information such as spot rate, forward points and point value are also accommodated. For non-base currency trades, cross rates (or rates to base) to accommodate the currency exchange rates to cross between the traded currencies are provided for.

Note: the refactored rate of exchange model has stricter grammar than FpML 4.x, which eliminates a few rules (e.g. fx-1, fx-2, fx-3, fx-28, fx-29 ).

### 8.3 Foreign Exchange Flexible Forward

FxFlexibleForward-Product model for a flexible-term fx forward (also known as callable forward, window forward). This is a term forward transaction over a specific period, allowing the client full flexibility on the timing of the transactional flow(s). The product allows for (full or partial) execution at a predetermined forward rate, at any time between the start date and the expiry date. Although, the product is an outright, it has some option-like characteristics, leading to the use of option components in the model: (i) the BuyerSeller model expresses the roles of the parties in the overall transaction - the client "buys" the product (ii) the PutCallCurrency model expresses the buyer's perspective on the exchanged currencies i.e. the client may buy (call) or sell (put) the notional currency for the alternative currency.

| BuyerSeller.model-No Annotation Available PutCallCurrency.model-No Annotation Available notionalAmount-The aggregate notional amount which will be exchanged, possibly as multiple partial executions, during the course of the execution period. Any residual notional which remains unexchanged at the expiry date will automatically be executed at the applicable exchange rate (strike). minimumExecutionAmount-The minimum notional amount which must be executed in any single transaction. executionPeriodDates-The period during which the client has the right to execute a transaction, on any business day defined by reference to the specified business centers, subject to the constraints of the minimum execution amount and aggregate total notional amount. * Period dates are inclusive i.e. the expiry date is the final date on which execution may occur.The period during which the client has the right to execute a transaction, on any business day defined by reference to the specified business centers, subject to the constraints of the minimum execution amount and aggregate total notional amount. * Period dates are inclusive i.e. the expiry date is the final date on which execution may occur. earliestExecutionTime-The earliest time of day at the specified business center, at which the client may execute a transaction. latestExecutionTime-The latest time of day at the specified business center, at which the client may execute a transaction. settlementDateOffset-The date on which delivery of the transacted currency amounts will occur, expressed as an offset from the execution date. * This property is optional in the schema, allowing it to be omitted by systems which do not support it; however this information would be expected in contractual documentation (e.g. termsheet, confirmation).The date on which delivery of the transacted currency amounts will occur, expressed as an offset from the execution date. * This property is optional in the schema, allowing it to be omitted by systems which do not support it; however this information would be expected in contractual documentation (e.g. termsheet, confirmation). finalSettlementDate-The final date for settlement. This is the date on which any residual exchange amount will be delivered. * This is an adjusted date i.e. a good business day for delivery in the location(s) specified in executionPeriodDates /businessCentersThe final date for settlement. This is the date on which any residual exchange amount will be delivered. * This is an adjusted date i.e. a good business day for delivery in the location(s) specified in executionPeriodDates /businessCenters forwardRate-Definition of the forward exchange rate for transactions executed during the execution period.Definition of the forward exchange rate for transactions executed during the execution period. forwardRate-Definition of the forward exchange rate for transactions executed during the execution period.Definition of the forward exchange rate for transactions executed during the execution period.

####

8.3.1 FxFlexibleForward->executionPeriodDates

executionPeriodDates-The period during which the client has the right to execute a transaction, on any business day defined by reference to the specified business centers, subject to the constraints of the minimum execution amount and aggregate total notional amount. * Period dates are inclusive i.e. the expiry date is the final date on which execution may occur.The period during which the client has the right to execute a transaction, on any business day defined by reference to the specified business centers, subject to the constraints of the minimum execution amount and aggregate total notional amount. * Period dates are inclusive i.e. the expiry date is the final date on which execution may occur.

| startDate-Start date of the execution period/window. expiryDate-Expiry (maturity) date of the execution period. businessCenters-Business centers for determination of execution period business days.

####

8.3.2 FxFlexibleForward->forwardRate

forwardRate-Definition of the forward exchange rate for transactions executed during the execution period.Definition of the forward exchange rate for transactions executed during the execution period.

| rate-Constant rate value, applicable for the duration of the execution period.Constant rate value, applicable for the duration of the execution period. spotRate-The spot exchange rate for the specified currency pair as per the specified quote basis, as at the trade date.The spot exchange rate for the specified currency pair as per the specified quote basis, as at the trade date.

### 8.4 Foreign Exchange Swap

A foreign exchange swap is a single product that combines two trades, either spot/forward or forward/forward. (The FpML 4.x model allowed any number of exchanges but the new restricts it to just two. In the old model FX Swap was a container for other products – like a strategy. In the new model it's a single product). A standard FX swap contains only two legs, nearLeg and farLeg to indicate the value date order. There are a variety of different types of FX swaps in the marketplace: standard (round-amount) swaps, overnight swaps, unequal-sided swaps, forward-forward swaps. All of the features that are available within FxCoreDetails.Model, common components to standard FX spot and forward trades (described previously) can be utilized in describing an FX swap as well.

####

8.4.1 FX Swap Leg

Near and far legs are based on a new FxSwapLeg type and derived from a super type Leg from which all swap legs are extended (and is not derived from Product as in 4.x).

### 8.5 Foreign Exchange Option

Foreign exchange options model is completely redesigned compared to 4.x model that was very loose with too many independent optional elements. It did not enforce relationships between elements. The basic data types used for values like rates had no constraints (e.g. could be negative). The 5.x model is designed to bring related data together and many elements were renamed in line with FpML naming convention and MTF recommendations.

Foreign exchange options are now more consistent with other option products. FxOption type extends new Option base type - a type that defining the common features of options - buyer and seller model and derived from a Product type (the Option type could be used to re-factor other option types). It also includes separate exercise structures for standard European and American options.

A vanilla fxOption identifies an exercise style, the put currency and amount, and call currency and amount, strike price and premium information. The premium is structured similar to an exchanged currency for a conventional FX trade, where optional settlement information for the premium can be attached. In addition, there are optional procedures associated with the exercise, a soldAs reference to allow buyer/seller perspective to be easier to derive – did I buy a put or sell a call, spotRate that this represents the current market rate for a particular currency pair. Note: quotedAs component has been removed as it was a legacy element carried through the versions and the group felt it was confusing.

####

8.5.2 FX Option Exercise

The fxOption element allows the description of a basic FX Vanilla option with European or American exercise.

It provides a (mandatory) choice between describing European or American exercise:

##### 8.5.2.1 American Exercise

##### 8.5.2.2 European Exercise

European exercise is at a date, time, cut and identifies the value date.

####

8.5.3 Premium

### 8.6 Foreign Exchange Binary and Digital Options

The terms binary and digital are not clearly defined in the FX markets and can occasionally be synonymous. This is used to define an option that has a discontinuous payout profile. It typically pays out a fixed amount if the underlying satisfies a predetermined trigger condition or else pays nothing. Unlike the standard option, the amounts quoted are the payout amounts as opposed to a notional underlying amount. Below are the structures for FX OTC binary and digital options.

### 8.7 Trade Strategies

One or more financial instruments, of any sort that are supported by the FpML specification, can be combined to form what is called a strategy. This can include various packages of the same or different asset classes in a single trade. Typical examples of this would include option packages (e.g., straddles, strangles) or a delta hedge (FX OTC option with spot risk hedged by FX spot deal). Additionally, other asset classes can be combined in a strategy (e.g., interest rate swap with FX, etc.)

## 9 EQUITY DERIVATIVE OPTIONS PRODUCT ARCHITECTURE

### 9.1 Overall Architecture

FpML Transparency view supports standardized OTC equity options without customizations. More precise high-level documentation will be available in a future draft. The following descriptions may include features not included in Transparency view. Please consult the schema reference for more precise documentation.

### 9.2 Component Descriptions

####

9.2.1 Underlyer

| The underlyer component specifies the asset(s) on which the option is granted, which can be either on either a singleUnderlyer or basket, and consist of equity, index, or convertible bond components, or some combination of these The instrumentIdcontains a short-form, unique identifier (e.g. ISIN, CUSIP) for the asset. At least one instrumentId must be present. The exchangeId element contains a short form unique identifier for an exchange. If omitted then the exchange shall be the primary exchange on which the underlying is listed. The relatedExchangeId element contains a short form unique identifier for a related exchange. If omitted then the exchange shall be the primary exchange on which listed futures and options on the underlying are listed. The clearanceSystem element contains the identity of the clearance system to be used. If omitted, the principal clearance system customarily used for settling trades in the relevant underlying shall be assumed.

####

9.2.2 Equity Exercise

| The EquityValuation component specifies the date and time on which the option is valued. The element valuationDateis assumed to have the meaning as defined in the ISDA 2002 Equity Derivatives Definitions. It enables the valuationDate to be expressed in relation to some other date defined in the document (the anchor date), where there is the opportunity to specify a combination of offset rules. This component will typically be used for defining the valuation date in relation to the payment date, as both the currency and the exchange holiday calendars need to be considered. Alternatively, valuationDate is a date that shall be subject to adjustment if it would otherwise fall on a day that is not a business day in the specified business calendar locations, together with the convention for adjusting the date. The element valuationDate specifies the interim equity valuation dates of the swap. The valuationDate can be specified as a series of dates that shall be subject to adjustment if they would otherwise fall on a day that is not a business day in the specified business calendar locations, together with the convention for adjusting the date, otherwise, the valuationDate is a series of dates specified as some offset to other dates (the anchor dates). The element valuationTimeType is the time of day at which the calculation agent values the underlying, for example the official closing time of the exchange. The element valuationTime specifies the time of day at which the calculation agent values the underlying. The EquityExerciseValuationSettlement component specifies equity option contractural settlement information. The settlement date specifies when the option is to be settled relative to the valuation date. If the settlement date is not specified explicitly then settlement will take place on the valuation date. The settlementType component is used to specify whether the option is settled in cash or physically. The settlementType element shows how the transaction is to be settled when it is exercised. The values comes from list: Cash, Election, Physical.

##### 9.2.2.1 European Exercise

| The sub-components of the EquityEuropeanExercise component specify the date and time when the option will expire. The element expirationDate enables the expiration date to be expressed as adjustable or relative date to some other event, such as the close of business for the exchange. The element equityExpirationTimeType is the time of day at which the equity option expires, for example the official closing time of the exchange.

##### 9.2.2.2 American Exercise

| The commencementDate and expirationDate are used to specify the period during which the option may be exercised (more than once if permitted by the The element latestExerciseTimeType-The latest time of day at which the equity option can be exercised, for example the official closing time of the exchange.The latest time of day at which the equity option can be exercised, for example the official closing time of the exchange. The element equityExpirationTimeType-The time of day at which the equity option expires, for example the official closing time of the exchange.

##### 9.2.2.3 Bermuda Exercise

| The commencementDate and expirationDate are used to specify the period during which the option may be exercised (more than once if permitted by the equityMultipleExercise component). The option may be exercised on any of the days in the list bermudaExerciseDates up to the latestExerciseTime specified for exercise. The element latestExerciseTimeType-The latest time of day at which the equity option can be exercised, for example the official closing time of the exchange.The latest time of day at which the equity option can be exercised, for example the official closing time of the exchange. The element equityExpirationTimeType-The time of day at which the equity option expires, for example the official closing time of the exchange.

####

9.2.3 Equity Premium

| The EquityPremium component specifies the amount and timing of the premium payment that is made for the equity option. payerPartyReference and Party components that specify the payer and receiver of the premium respectively. In FpML the premium amount can be expressed in a number of ways: as a monetary amount ( paymentAmount), as a price per option ( pricePerOption) or as a percentage of notional ( percentageOfNotional) - if more than one method is used then they must be mutually consistent. There are circumstances in which no premium would be specified, for example if the trade formed part of a put/call combo structure. The swapPremium element holds a boolean value that, if "true" specifies that the premium is to be paid in the style of payments under an interest rate swap contract.

####

9.2.4 Adjustment of dates in Equity Options

When a date specified in an equity option contract falls on a non-business day then it may be necessary to adjust it to be a business day. At the time the contract is agreed it is not always possible to determine whether or not a particular date in the future will be a business day.

The meaning of "business day" varies according to the context in which it is used. When the context is the payments of monetary amounts then the rules for adjustment according to currency business days apply, and the equity option product architecture uses the same AdjustableOrRelativeDate component ( or derivations ) as the interest rate and foreign exchange products.

However, when the context is the valuation or settlement of equities or equity indices then the term "business day" means "exchange business day". In this case the equity option product architecture specifies the use of unadjusted dates with the adjustment rules being implicitly inherited from the ISDA definitions.

## 10 RETURN SWAPS PRODUCT ARCHITECTURE

### 10.1 Return Swaps Scope

FpML provides generic Return Swaps support including "long form" Equity Swap representations, as well as Total Return Swaps. A separate product element called equitySwapTransactionSupplement supports "short form" Equity Swap Transaction Supplement.

Return-type Swaps have 1-to-many Legs, all of which must be derived from the ReturnSwapLeg type. Instances of Legs are returnLeg, interestLeg. Other Leg types may be derived from ReturnSwapLeg at will, to allow for private extensions to support whatever type of Generic Return Swap is desired.

The scope of this FpML representation for return swaps is to capture the following types of swaps that have equity-related underlyers:

- Single stock swaps as well as basket swaps (i.e. swaps with multiple underlyers);
- Swaps that have a different types of underlying assets (equity, index, mutual funds, exchange-traded funds, convertible bond, futures), or a combination of these;
- 2-legged swaps with a combination of an equity leg and a funding leg, as well as swaps that either have only one leg (e.g. fully funded or zero-strike swap) or multiple equity legs (e.g. outperformance swaps);
- Total Return Swaps, a type of swap in which one party (total return payer) transfers the total economic performance of a reference obligation to the other party (total return receiver).

NOTE: Some refactoring work for SettlementPeriods are being considered for the next draft.

### 10.2 Introduction

FpML Return Swaps Product Architecture amends the previous Equity Swaps Product Architecture since it describes a more generic representation of return type swaps, not only equities. The generic representation includes the product coverage introduced in previous versions of FpML to support full conformance with ISDA 2002 Equity Derivative Definitions, intial and final stubs, and Equity Swap Transaction Supplement. In addition, it supports the representation of Total Return Swaps.

This document provides an in-depth review of the technical architecture of the FpML Return Swap subschema. The scope as well as the current limitations of this schema, which will be addressed through a next release, are described in the first section of this document.

####

10.2.1 The structure of the generic Return Swap

The FpML representation of the returnSwap relies on the structures that are presented in the figure below:

| Swaps may have 1-to-many Legs, the principal components of the return swap schema are as follows: In Transparency view, Return-type Swaps have 2 Legs, all of which must be derived from the ReturnSwapLeg type. Normally one will be a returnLeg and the other an interestLeg. The returnLeg (old equityLeg) component specifies the return leg of the swap. There can be one or several return legs; The interestLeg component defines the interest leg of the swap. Note: The equityLeg was deprecated in FpML 4.2 Second Working Draft and it has been removed in version 5.0. The principalExchangeFeatures is an optional component that describes the case where principal cashflows are exchanged between the parties to the trade; Similarly to the interest rate swap (but with a different structure, that serves the specific features of the return swaps), the additionalPayment component supports the other types of payments involving the parties to the trade, such as fees; Finally, the earlyTermination component specifies, for one or for both the parties to the trade, the date from which it can be early terminated.

####

10.2.2 Equity Swap Transaction Supplement

| equitySwapTransactionSupplement implements Equity Swap Transaction Supplements by providing a short form representation for use in trades governed by a Master Confirmation Agreement. Due to the wide scope of the Equity Swap Transaction Supplement, it has not been possible to make the equitySwapTransactionSupplement component as compact as equityOptionTransactionSupplement The various sections below detail each of these five structures of the equity leg of the swap.

### 10.3 Component Descriptions

####

10.3.1 The return leg

The figure 2 presents the structure of the return leg of the swap, which has 10 categories of components:

| Figure 2: The structure of the return leg. These categories of components are described through the next few pages. They are the following: The determination of the effective date and the termination date; The determination of the strike date for forward starting swaps; The description of the underlying asset(s); The Rate of Return terms; The specification of the notional; The determination of the payoff amount; The description of the return terms; The notional adjustments conditions; The currency exchange terms that can be associated with the equity leg of the swap.

##### 10.3.1.1 The effective date and the termination date

The effective date and the termination date are similarly defined for both the interest and equity leg of the trade. Each of these dates can be specified either in reference to a date defined somewhere else in the document (using the relativeDate subcomponent), or as a specific date (using the adjustableDate subcomponent).

The figure 3 presents the effective date as an example of how these two components are structured:

| Figure 3: The effectiveDate.

The example 1 below presents how these schema structures are used for defining the effective date of the equity swap as a function of the trade date (the elapse time between these being the settlement cycle of the underlying security assets) and the termination date as a function of the last payment of the swap. This corresponds indeed to the most frequent practice for confirming equity swaps.

Example 1 - Effective date as a function of the trade date and effective date as a function of the last payment date:

- Effective date: 3 business days after the trade date (defined in another part of the document and referred to through the TradeDate reference);
- Termination date: on the last payment date (also defined somewhere else in the document and referred to through the FinalEquityPaymentDate reference).

    	<effectiveDate id="EffectiveDate">
    	  <relativeDate>
    	    <periodMultiplier>3</periodMultiplier>
    		<period>D</period>
    		<dayType>ExchangeBusiness</dayType>
    		<businessDayConvention>NotApplicable</businessDayConvention>
    		<dateRelativeTo href="TradeDate"/>
    	  </relativeDate>
    	</effectiveDate>
    	<terminationDate id="TerminationDate">
    	  <relativeDate>
    	    <periodMultiplier>0</periodMultiplier>
    	    <period>D</period>
    	    <businessDayConvention>NotApplicable</businessDayConvention>
    	    <dateRelativeTo href="FinalEquityPaymentDate"/>
    	  </relativeDate>
        </terminationDate>

##### 10.3.1.2 The underlyer

The underlyer component provides a detailed description of the characteristic of the underlying asset(s). Seven types of asset classes have been included as part of this release, of which six are actually used by the equity swap. These six underlying types are the convertible bond, the equity, the exchange-traded fund, the future contract, the index and the mutual fund. The seventh one is the bond, that is used by the schema for credit derivatives and will be later used by the schema for trigger swaps once it will be released. Each of these asset types has been defined by extending a component named underlyingAsset that contains some key attributes that are common across most of the underlyers: the identifier, the descriptive name, the currency of denomination, the stock exchange on which the underlyer is listed and the clearance system. With the exception of the identifier element, all these attributes are optional.

Thereafter is the description of these six types of underlyers that are used by the schema for equity swaps. These diagrams also present the respective schemes that have been associated with these components. Not surprisingly, the exchangeId is used quite often.

##### 10.3.1.2.1 The equity:

| Figure 4: The equity underlyer extends the underlyingAsset component by adding two (optional) elements: the related exchange and the options exchange.

##### 10.3.1.2.2 The index:

| Figure 5: The index underlyer extends the underlyingAsset component by adding two (optional) elements: the related exchange and the identifier of the reference future contract that may have been referenced as part of the swap contract.

##### 10.3.1.2.3 The mutual fund:

| Figure 6: The mutual fund underlyer extends the underlyingAsset component by adding two (optional) elements: the indicator of whether the fund is open or closed and the name of the fund manager.

##### 10.3.1.2.4 The exchange-traded fund:

| Figure 7: The exchange-traded fund underlyer extends the underlyingAsset component by adding three (optional) elements: the related exchange, the options exchange and the name of the fund manager.

##### 10.3.1.2.5 The future contract:

| Figure 8: The future contract underlyer extends the underlyingAsset component by adding four (optional) elements: the related exchange, the options exchange, the contract multiplier and the specific reference of the future contract that is used as part of the swap.

##### 10.3.1.2.6 The convertible bond:

| Figure 9: The convertible bond underlyer extends the underlyingAsset component through six elements that characterize the instrument (the related exchange, the issuer name, the coupon rate, the maturity date, the par value and the face amount); in addition, the underlyingEquity component describes the equity underlyer in which the convertible bond can be turned into.

##### 10.3.1.2.7 The commodity:

| Figure 10: The commodity underlyer extends the IdentifiedAsset component and may be used in the same way as all other FpML underlyers.

These various types of underlyers can be combined through two different structures, depending upon whether the swap has only one underlyer or has multiple underlying assets: the singleUnderlyer structure or the basket structure. The figure 11 below provides a high-level view of these two alternative structures, which are detailed in the following paragraphs.

| Figure 11: Overview of the two alternative types of underlying structured: the singleUnderlyer and the basket.

In the case of a single underlyer, the singleUnderlyer component specifies the number of open units, the description of the underlyer (through the underlyingAsset substitution group) and the dividendPayout ratio (which is defined through the underlyer component rather than the return component for reasons that are related to the basket, and that are explained below). It should be noted that the eleven members of the underlyingAsset substitution group (The bond, convertibleBond, cash, commodity, equity, exchangeTradedFund, future, index, loan, mortgage, mutualFund) do not appear in this diagram: only the basis elements are represented.

Basket underlyers are currently not supported in Transparency view.

     <underlyer>
      <basket>
        <openUnits>1</openUnits>
        <basketConstituent>
          <equity>
            <instrumentId instrumentIdScheme="RIC">TIM.MI</instrumentId>
            <description>Telecom Italia Mobile spa</description>
            <currency>EUR</currency>
            <exchangeId exchangeIdScheme="http://www.fpml.org/schemes/4.0/exchangeId">Milan Stock Exchange</exchangeId>
          </equity>
          <constituentWeight>
            <openUnits>783000</openUnits>
          </constituentWeight>
          <dividendPayout>
            <dividendPayoutRatio>85</dividendPayoutRatio>
          </dividendPayout>
          <underlyerPrice>
            <grossPrice>
              <currency>EUR</currency>
              <amount>4.14</amount>
              <priceExpression>AbsoluteTerms</priceExpression>
            </grossPrice>
    		<netPrice>
    		  <currency>USD</currency>
    		  <amount>4.182</amount>
    		  <priceExpression>AbsoluteTerms</priceExpression>
    		</netPrice>
    	  </underlyerPrice>
    	  <underlyerNotional>
    	    <currency>USD</currency>
    	    <amount>3274506</amount>
    	  </underlyerNotional>
    	</basketConstituent>
    	<basketConstituent>
    	  <equity>
    	    <instrumentId instrumentIdScheme="RIC">VOD.L</instrumentId>
    	    <description>Vodafone Group</description>
    	    <currency>GBP</currency>
    	    <exchangeId exchangeIdScheme="http://www.fpml.org/schemes/4.0/exchangeId">London Stock Exchange</exchangeId>
    	  </equity>
    	  <constituentWeight>
    	    <openUnits>24860</openUnits>
    	  </constituentWeight>
    	  <dividendPayout>
    	    <dividendPayoutRatio>85</dividendPayoutRatio>
    	  </dividendPayout>
    	  <underlyerPrice>
    	    <grossPrice>
    	      <currency>GBP</currency>
    	      <amount>110.00</amount>
    	      <priceExpression>AbsoluteTerms</priceExpression>
    	    </grossPrice>
    	    <netPrice>
    	      <currency>USD</currency>
    	      <amount>165.00</amount>
    	      <priceExpression>AbsoluteTerms</priceExpression>
    	     </netPrice>
    	   </underlyerPrice>
    	   <underlyerNotional>
    	     <currency>USD</currency>
    	     <amount>4101900</amount>
    	    </underlyerNotional>
    	  </basketConstituent>
    	</basket>
    </underlyer>

##### 10.3.1.3 The valuation

Equity Options and Return Swaps both now use a common EquityValuation type.

| Figure 14: The EquityValuation type, that specifies the valuation terms of the return leg of the swap.

The following developments present in more details the four main structures that are part of ReturnLegValuation type: the initialPrice, the valuationPriceInterim, the valuationPriceFinal and the paymentDates (old equityPaymentDates). Even if these components can appear quite complex at first glance, the objective here is to outline how they have been based upon a limited set of 'building blocks' that are systematically reused.

The purpose of the initialPrice component is to specify the initial price for the underlyer of the trade (equity, bond, index). In most of the cases, this price will be known. There can however be certain cases, such as a forward trade, where the actual price is not known on trade date and where the trade confirmation will rather specify the terms according to which this initial price will be determined at a later point.

Three possible ways for defining the price of the underlyer are available: as an actual price and currency ( EquityPrice.model), in reference to an amount defined somewhere else in the document using the amountRelativeTo element, or by specifying a specific determination method using the determinationMethod component. Commissions can be associated with each of these three alternative definitions. For addressing the requirements related to composite FX swaps, the possibility is also provided, through the fxConversion component, to explicitly define the FX rate that has been used to convert the price from its listing currency to the reference currency of the swap.

Considering that in the vast majority of the cases the initial price is defined as an actual price and currency, the examples below will focus on detailing the various options available for specifying such actual price. The other possibilities offered through the Price type will be further detailed through the interim and final price components.

Example 3 - Specification of an initial price as an actual price that does not include commissions and FX terms:

- Price amount: 37.44;
- Price currency: USD;
- Price expression: in absolute terms (as opposed to as a percentage of the notional);
- There are no commissions nor FX terms associated with the price.

    			<initialPrice>
    			  <netPrice>
    			    <currency>USD</currency>
    			    <amount>37.44</amount>
    			    <priceExpression>AbsoluteTerms</priceExpression>
    			  </netPrice>
    			</initialPrice>

    	<initialPrice>
    	  <commission>
    	    <commissionDenomination>BPS</commissionDenomination>
    	    <commissionAmount>5</commissionAmount>
    	  </commission>
    	  <grossPrice>
    	    <currency>CAD</currency>
    	    <amount>113228777</amount>
    	    <priceExpression>AbsoluteTerms</priceExpression>
    	  </grossPrice>
    	  <netPrice>
    	    <currency>USD</currency>
    	    <amount>84089141</amount>
    	    <priceExpression>AbsoluteTerms</priceExpression>
    	  </netPrice>
    	  <fxConversion>
    	    <fxRate>
    	      <quotedCurrencyPair>
    	        <currency1>CAD</currency1>
    	        <currency2>USD</currency2>
    	        <quoteBasis>Currency1PerCurrency2</quoteBasis>
    	      </quotedCurrencyPair>
    	      <rate>1.34665</rate>
    		</fxRate>
    	  </fxConversion>
    	</initialPrice>

Example 4 - Specification of an initial price as a percentage of the notional, without commissions nor FX terms:

- Price: 94.80278% of the notional amount.

    			<initialPrice>
    			  <netPrice>
    			    <amount>94.80278</amount>
    			    <priceExpression>PercentageOfNotional</priceExpression>
    			  </netPrice>
    			</initialPrice>

This structure that specifies the date and time of the valuation will typically not be used as part of the definition of the initial price. This is because in most cases the initialPrice component specifies the price of the underlyer that is used as the initial reference point for the swap, and there is no need to refer to any specific date or time. Considering that this 'building block is defined and used in a quite similar same way for the interim and final price, it will be detailed through these latter.

The purpose of the valuationPriceInterim component is to specify the interim price(s) for the equity underlyer of the trade. This is an optional component, as it does not apply in the case of a bullet swap, where there is no reset date. Its other specificity vis-a-vis the initial and final valuation components it that this components can hold an array of valuation dates, as opposed to only one valuation date.

Similarly to the initialPrice component, the diagrams 16 and 17 below present the two sets of structures that are part of the valuationPriceInterim component: one structure that specifies the price and one structure that specifies the valuation dates. Both structures are mandatory.

The example 6 below is very illustrative of the typical use of the valuationPriceInterim structure for representing the interim valuation prices of an equity swap:

- As part of the Price structure, the determinationMethod node of the choice sequence will be used for specifying how the future prices of the underlyer will be determined;
- The definition of the time of the valuation essentially relies upon the valuationTimeType element, that specifies the time of day at which the Calculation Agent values the underlyer: the valuationTime component, which purpose is to specify an actual valuation time, is expected to be used only in some rare cases;
- Most often, a schedule of valuation dates will be specified, to which the payment schedule will refer.

Example 6 - Typical example of how the valuationPriceInterim component is used to specify the the interim valuation:

- A schedule of 11 interim valuation dates is defined, that extends from October 12, 2001 to August 12, 2002;
- This schedule of dates already takes into consideration the expected exchange holidays. Hence, no business day convention is applicable;
- On each of these valuation dates, the equity underlyer will be valued at the market close.

    	<valuationPriceInterim>
    	  <determinationMethod>ValuationTime</determinationMethod>
    	  <valuationRules>
    	    <valuationDates id="InterimValuationDate">
    	      <adjustableDates>
    	        <unadjustedDate>2001-10-12</unadjustedDate>
    			<unadjustedDate>2001-11-13</unadjustedDate>
    			<unadjustedDate>2001-12-12</unadjustedDate>
    			<unadjustedDate>2002-01-14</unadjustedDate>
    			<unadjustedDate>2002-02-12</unadjustedDate>
    			<unadjustedDate>2002-03-12</unadjustedDate>
    			<unadjustedDate>2002-04-12</unadjustedDate>
    			<unadjustedDate>2002-05-13</unadjustedDate>
    			<unadjustedDate>2002-06-12</unadjustedDate>
    			<unadjustedDate>2002-07-12</unadjustedDate>
    			<unadjustedDate>2002-08-12</unadjustedDate>
    		    <dateAdjustments>
    			  <businessDayConvention>NotApplicable</businessDayConvention>
    			</dateAdjustments>
    		  </adjustableDates>
    		</valuationDates>
    		<valuationTimeType>Close</valuationTimeType>
    	  </valuationRules>
        </valuationPriceInterim>

The schema also provides the ability to address some more unusual situations. One of these relates to the case where the valuation dates are defined as a function of the equity payment dates. In such case, a specific consideration needs to be given to the various types of holidays, i.e. banking holidays versus exchange holidays. The relativeDateSequence component does provide such ability to define a date as a function of another date by applying a defined sequence of offsets, as opposed to only one offset as in the case of the relativeDate component. This case is illustrated in the example 7 below.

Example 7 - The interim valuation dates are defined in relation to the payment dates:

- The settlement cycle of the underlying equity is 3 business days;
- The valuation date is defined as a function of the payment date. Considering that the payment date happens after the valuation date, a negative value is then specified as the periodMultiplier element;
- In order to give consideration to the situations where the stock exchange is opened on certain banking holidays (e.g. Veteran Day in the United States) and vice-versa, a sequence of offsets is being applied. Considering a settlement cycle of 3 days, a first sequence of 2 currency business days is first applied, and then a sequence of 1 exchange business day. This avoids a situation where an offset of 3 currency business days could lead to specifying a valuation date that corresponds to an exchange business day.
- Considering that the first offset sequence of 2 business days applies to currency business days, the ISDA business day convention is applicable; it is not applicable for the second offset sequence, which refers to exchange business days.

        <valuationPriceInterim>
    	  <valuationRules>
    	    <valuationDates id="InterimValuationDates">
    	      <relativeDateSequence>
    	        <dateRelativeTo href="InterimEquityPaymentDate"/>
    			  <!--The first offset is 2 exchange business days prior to the payment date.-->
    			  <dateOffset>
    			    <periodMultiplier>-2</periodMultiplier>
    			    <period>D</period>
    			    <dayType>CurrencyBusiness</dayType>
    			    <businessDayConvention>FOLLOWING</businessDayConvention>
    			    <sequence>1</sequence>
    			  </dateOffset>
    			  <!--The second offset is 1 banking business day prior to the payment date.-->
    			  <dateOffset>
    			    <periodMultiplier>-1</periodMultiplier>
    			    <period>D</period>
    			    <dayType>ExchangeBusiness</dayType>
    			    <businessDayConvention>NotApplicable</businessDayConvention>
    			    <sequence>2</sequence>
    			  </dateOffset>
    			  <businessCenters id="PrimaryBusinessCenter">
    			    <businessCenter>USNY</businessCenter>
    			  </businessCenters>
    		    </relativeDateSequence>
    		  </valuationDates>
    	  </valuationRules>
    	 </valuationPriceInterim>

The example 8 below provides another example of an unusual definition of the interim valuation date. Here, the valuation dates are defined through a rule-based schedule, which corresponds to the market practice typically in use for fixed income swaps. This practice is however used only rarely in the case of equity derivatives.

Example 8 - The interim valuation dates are defined through a rule-based schedule:

- The underlyer is valued at the market close on each of the interim valuation dates;
- The final valuation is based on the price obtained by the payer of the equity return when unwinding his hedge position;
- The first valuation date is April 10, 2002;
- Each of the following valuations is scheduled on the 10th of each month, until the last valuation date which is scheduled on March 12, 2003;
- The business day convention is not applicable, because the terms 'Modified Following', 'Following', 'Preceding', etc. are not recognized ISDA terms in the context of exchange business days. On the other hand, the ISDA Definition for Equity Derivatives is, by default, to roll forward if a scheduled valuation date is not a exchange business day.

    	<valuationPriceInterim>
    	  <determinationMethod>ValuationTime</determinationMethod>
    	  <valuationRules>
    	  	 <valuationDates id="InterimValuationDates">
    	      <periodicDates>
    	        <calculationStartDate>
    	          <adjustableDate>
    	            <unadjustedDate>2002-04-10</unadjustedDate>
    	            <dateAdjustments>
    	              <businessDayConvention>NotApplicable</businessDayConvention>
    	            </dateAdjustments>
    	          </adjustableDate>
    	        </calculationStartDate>
    	        <calculationPeriodFrequency>
    	          <periodMultiplier>1</periodMultiplier>
    	          <period>M</period>
    	          <rollConvention>10</rollConvention>
    	        </calculationPeriodFrequency>
    	        <calculationPeriodDatesAdjustments>
    	          <businessDayConvention>NotApplicable</businessDayConvention>
    	        </calculationPeriodDatesAdjustments>
    	      </periodicDates>
    	    </valuationDates>
    	    <valuationTimeType>Close</valuationTimeType>
    	  </valuationRules>
    	</valuationPriceInterim>
    	<valuationPriceFinal>
    		<determinationMethod>HedgeExecution</determinationMethod>
    		<valuationRules>
    			<valuationDate id="FinalValuationDate">
    				<adjustableDate>
    					<unadjustedDate>2003-03-12</unadjustedDate>
    					<dateAdjustments>
    						<businessDayConvention>NotApplicable</businessDayConvention>
    					</dateAdjustments>
    				</adjustableDate>
    			</valuationDate>
    		</valuationRules>
    	</valuationPriceFinal>

The purpose of the valuationPriceFinal component is to specify the final price for the equity underlyer of the trade.

In a similar way than what has been previously detailed for the components that specify the initial and the intermediate valuations, the diagrams 18 and 19 below respectively detail the structure that specifies the final price and the structure that specifies the date on which this valuation will take place. Both structures are mandatory.

It can be noted at this point that the only difference between this valuationPriceFinal component and the valuationPriceInterim component is that only one final valuationDate can be specified, while the possibility is provided to define several interim valuationDates. The equity valuationDates component used for specifying the interim valuation dates has then been substituted with the equity valuationDate component, which allows only one date.

The example 8 below presents the most common use of this structure, a specific final valuation date being defined while the final price is specified through the use of the determinationMethod element. Of course, if the interim valuation dates would be defined in reference to the payment dates (as illustrated in the example 7) or through a rule-based schedule (example 8), such method would also be applied for defining the final valuation date.

Example 9 - The most common definition of the final valuation:

- The final price of the equity underlyer will correspond to the price at which the payer of the equity leg will unwind his hedge position;
- A commission of 60 basis points will be applied to this price;
- The final valuation date is February 3, 2004;
- In accordance to the market practice, this date has been determined by the Calculation Agent as corresponding to an exchange business day. As previously indicated, the terms 'Modified Following', 'Following', 'Preceding', etc. are not recognized ISDA terms in the context of exchange business days.

    	<valuationPriceFinal>
    	  <commission>
    	    <commissionDenomination>BPS</commissionDenomination>
    	      <commissionAmount>60</commissionAmount>
    	    </commission>
    		<determinationMethod>HedgeExecution</determinationMethod>
    		<valuationRules>
    		  <valuationDate id="FinalValuationDate">
    		  <adjustableDate>
    		    <unadjustedDate>2004-02-03</unadjustedDate>
    			<dateAdjustments>
    			  <businessDayConvention>NotApplicable</businessDayConvention>
    			</dateAdjustments>
    		  </adjustableDate>
    		</valuationDate>
          </valuationRules>
    	</valuationPriceFinal>

The last structure that participates in the definition of the equity swap valuation is the schedule of equity payment dates. These dates are specified through the equity paymentDates component. The structure of this component is threefold:

- An Identifier is associated to the equityPaymentDates root component, in order to allow to specify a generic reference to these payment dates. This unique reference to the payment dates is used through the dividend component, when it is specified that the dividend will be paid on the next equity payment date (see below the section related to the return component of the equity leg);
- The equity paymentDatesInterim component specifies the interim payment dates of the swap. It is optional to address the case of bullet swaps that do not have interim equity resets;
- The equity paymentDateFinal component specifies the final payment date.

The structure of the paymentDatesInterim (old equityPaymentDatesInterim) and the paymentDateFinal (equityPaymentDateFinal) is very similar. The only difference is that several dates can be specified in the first case, and only one date in the latter.

As a result, both the interim and the final payment dates can be defined either as a schedule of dates or in reference to a date defined somewhere else in the document. This latter approach is used most often, with the payment dates being specified as one settlement cycle after the valuation date to which they relate. This is illustrated through this final example relating to the valuation component, which provides a complete view of how the valuation dates are defined as an actual schedule of dates to which the payment dates refer.

Example 10 - Equity swap which payment dates are defined in relation to the schedule of valuation dates:

- The initial price of the swap is USD 37.44;
- A schedule of 12 valuation dates is defined: 11 interim valuation dates (from October 12, 2001 to August 12, 2001) and 1 final valuation date (September 24, 2002);
- The equity underlyer is to be valued at the market close on each of the interim valuation dates. Its final valuation will correspond to the price at which the payer of the equity return unwinds his hedge;
- The payment dates are scheduled 3 currency business days after each of the valuation dates. Considering that these are currency business days, as opposed to exchange business days, the 'Following' business day convention is specified, New York being the reference business calendar location.

    	<rateOfReturn>
    	  <initialPrice>
    	    <netPrice>
    	      <currency>USD</currency>
    	      <amount>37.44</amount>
    	      <priceExpression>AbsoluteTerms</priceExpression>
    	    </netPrice>
    	  </initialPrice>
    	  <notionalReset>true</equityNotionalReset>
    	  <valuationPriceInterim>
    	    <determinationMethod>ValuationTime</determinationMethod>
    	    <valuationRules>
    	      <valuationDates id="InterimValuationDate">
    	        <adjustableDates>
      	          <unadjustedDate>2001-10-12</unadjustedDate>
      	          <unadjustedDate>2001-11-13</unadjustedDate>
      	          <unadjustedDate>2001-12-12</unadjustedDate>
    	          <unadjustedDate>2002-01-14</unadjustedDate>
    	          <unadjustedDate>2002-02-12</unadjustedDate>
    	          <unadjustedDate>2002-03-12</unadjustedDate>
    	          <unadjustedDate>2002-04-12</unadjustedDate>
    	          <unadjustedDate>2002-05-13</unadjustedDate>
    	          <unadjustedDate>2002-06-12</unadjustedDate>
    	          <unadjustedDate>2002-07-12</unadjustedDate>
    	          <unadjustedDate>2002-08-12</unadjustedDate>
    	          <dateAdjustments>
    	            <businessDayConvention>NotApplicable</businessDayConvention>
    	          </dateAdjustments>
    	        </adjustableDates>
    	      </valuationDates>
    	      <valuationTimeType>Close</valuationTimeType>
    	    </valuationRules>
    	  </valuationPriceInterim>
    	  <valuationPriceFinal>
    	    <determinationMethod>HedgeExecution</determinationMethod>
    	    <valuationRules>
    	      <valuationDate id="FinalValuationDate">
    	        <adjustableDate>
    	          <unadjustedDate>2002-09-24</unadjustedDate>
    	          <dateAdjustments>
    	            <businessDayConvention>NotApplicable</businessDayConvention>
    	          </dateAdjustments>
    	        </adjustableDate>
    	      </valuationDate>
    	   	</valuationRules>
    	  </valuationPriceFinal>
    	  <paymentDates id="EquityPaymentDate">
    	    <paymentDatesInterim id="InterimEquityPaymentDate">
    	      <relativeDates>
    	        <periodMultiplier>3</periodMultiplier>
    	        <period>D</period>
    	        <dayType>CurrencyBusiness</dayType>
    	        <businessDayConvention>FOLLOWING</businessDayConvention>
    	        <businessCenters id="PrimaryBusinessCenter">
    	          <businessCenter>USNY</businessCenter>
    	        </businessCenters>
    	        <dateRelativeTo href="InterimValuationDate"/>
    	      </relativeDates>
    	    </paymentDatesInterim>
    	    <paymentDateFinal id="FinalEquityPaymentDate">
    	      <relativeDate>
    	        <periodMultiplier>3</periodMultiplier>
    	        <period>D</period>
    	        <dayType>CurrencyBusiness</dayType>
    	        <businessDayConvention>FOLLOWING</businessDayConvention>
    	        <businessCentersReference href="PrimaryBusinessCenter"/>
    	        <dateRelativeTo href="FinalValuationDate"/>
    	      </relativeDate>
    	    </paymentDateFinal>
    	  </paymentDates>
    	</rateOfReturn>

##### 10.3.1.4 The notional amount

The notional component specifies the notional of each of the legs of the swap (it is indeed also present in the interest leg of the trade). Similarly to the price of the underlyer, four possible ways of defining this notional are available:

- By using notionalAmount component to specify an actual amount and currency. This is used most often for the equity leg of the swap;
- By using relativeNotionalAmount component to reference an amount specified somewhere else in the document. This is typically the case of the interest leg of the swap, which notional refers to notional specified through equity leg;
- By using determinationMethod component to specify a determination method. This is typically useful for forward swaps, which notional is not known on trade date.
- By using relativeDeterminationMethod component to reference a determination method specified somewhere else in the document. This is typically the case of the interest leg of the swap, which determination method refers to a determination method specified through equity leg;

The four examples below illustrate each of these cases mentioned before:

Example 11 - The explicit notional amount:

- This approach is typically used for specifying the notional of the equity leg of the swap;
- The identifier attribute associated with the notional amount element is used so that the notional amount of the interest leg can refer to it (example 12 below).

    	<notional>
    	  <notionalAmount id="EquityNotionalAmount">
    	    <currency>USD</currency>
    	    <amount>28469376</amount>
    	  </notionalAmount>
    	</notional>

Example 12 - The reference to a notional amount defined somewhere else in the document:

- This approach is typically used for specifying the notional amount of the interest leg of the swap;
- The relationship with the notional amount specified in the equity leg is established via the href, which refers to the value specified through the identifier associated with the explicit notional amount.

    	<notional>
    	  <relativeNotionalAmount href="EquityNotionalAmount"/>
    	</notional>

Example 13 - The use of the determinationMethod for specifying the notional amount:

- The initial price of the equity underlyer is not known on trade inception: it will be determined at a later point;
- As a consequence, only the method through which the notional is calculated is specified as part of the swap.

    	<notional>
    	  <determinationMethod id="EquityNotionalAmount">Number of Shares * Initial Price</determinationMethod>
    	</notional>

Example 13b - The reference to a determination method defined somewhere else in the document:

- This approach is typically used for specifying the notional determination method of the interest leg of the swap;
- The relationship with the notional determination method specified in the equity leg is established via the href, which refers to the value specified through the identifier associated with the explicit notional determination method.

    	<notional>
    	  <relativeDeterminationMethod href="EquityNotionalAmount"/>
    	</notional>

##### 10.3.1.5 The amount

The main purpose of the amount (old equityAmount) component is to specify the method that determines the amount to be paid/received on each of the payment dates. Its role however goes quite beyond this, as it also specifies:

- Whether the swap will cash settle of physically settle;
- The settlement currency of the return leg of the swap.

| Figure: The amount component.

This amount component is based on the LegAmount type that is also used for defining the interestAmount. It extends this type by adding a boolean cashSettlement element that specifies whether the swap will cash or physically settle.

The payment currency is the first component of this structure. It specifies the payment currency of the equity leg of the swap through three possible methods:

- As an actual ISO currency code;
- As a determinationMethod description, applicable in the case of some exotic swap where the payment currency of the trade will be a function of certain parameters;
- Through the currencyReference to a currency defined somewhere else in the document, as in the case of a quanto swap or a composite FX swap which reference currency is specified through the fxTerms component.

The core of the component is its second component, which specifies the payoff of the return leg. This can done in three possible ways:

- The referenceAmount element is aimed at holding the reference to the standard ISDA definition of the equity amount. (It can however be used beyond this sole purpose, as it is defined as a string element, without any specific enumerations;
- The formula component is aimed at the exotic equity swaps, which equity payoff needs to be described through a mathematical formula. To meet this purpose, the formula component provides a flexible structure for describing the return payoff, using the combination of the formulaDescription component that provides a literary description of the payoff, the math container that uses the xsd:any XML structure to hold any type of formula description, and the formulaComponent element that describes the various components of the formula.
- As an alternative to the XML representation of each of the details of the return payoff, the encodedDescription element provides the ability to encode an image that describes the payout formula, using a base64Binary structure.

The optional calculationDates component is also aimed at these more complex equity swaps. It provides the possibility to define calculation dates (such as observation points in the case of an equity payoff that is a function of some specific market levels). These calculation dates can be specified similarly to the valuation dates:

- As an actual schedule of dates, using the adjustableDates component;
- In relation to some dates defined elsewhere in the document, using the relativeDateSequence component;
- Through a rule-based schedule, using the periodicDates component.

Example 14 - The use of the amount component for a vanilla equity swap:

- The payment currency of the return leg is USD;
- The payoff amount of the return leg is specified as the ISDA standard definition, i.e. equal to the product of the underlyer notional amount and the rate of return;
- The settlements will be made in cash.

    	<amount>
    	  <paymentCurrency id="EquityPaymentCurrency">
    	    <currency>USD</currency>
    	  </paymentCurrency>
    	  <referenceAmount>ISDA Standard</referenceAmount>
    	  <cashSettlement>true</cashSettlement>
    	</amount>

##### 10.3.1.6 The return

The return component encapsulates the information that defines the dividend to be paid to the receiver of the equity amounts, with the exception of the dividend payout ratio, that is specified through the underlyer component. (As explained earlier, this is because a specific payout ratio can be associated with each underlyer component in the case of basket swaps; such situation can typically be related to different tax regimes across countries when those various underlyers originate from different market places.)

In Transparency view the return component has only a the returnType element, that specifies (through an enumeration) whether the contract is a total return swap, a price return swap or a dividend return swap.

##### 10.3.1.7 The notional adjustment

The notionalAdjustments component specifies whether the adjustment to the equity notional of the swap will obey to certain specific terms. These terms can be, according to the current industry practice, threefold: standard, execution and portfolio rebalancing. An execution-style swap is a trade where the quantity of underlyers is expected to vary quite often; in order to facilitate these later 'executions', the parties agree in advance on contractual terms that will facilitate these expected adjustments to the contract. A portfolio-rebalancing swap is a trade where the basket components will be often adjusted not only in terms of quantities but also in terms of types of underlyers; similarly to the previous case, some specific language will typically accommodate such adjustments.

These legal terms are however not specified through the schema representation of the equity swap. There are two reasons for this. The first one is that they are not part of the ISDA Definitions for Equity Derivatives. The second reason is that this current version of the equity swap schema is focused on representing the economic description of the trade. These legal terms are then not part of it.

####

10.3.2 The interest leg

The interest leg of the equity swap leverages for the most part the schema developed for the interest rate swaps.

However, instead of simply reusing the entire swapStream, the interest rate leg of the equity swap schema reuses certain of the components that are part of this swapStream.

This design approach is motivated by the differences in market practices that exist between the equity and fixed income products. The industry practice for the equity swaps consists in defining a schedule of actual dates for the equity valuation, while most of the other swap dates are defined in reference to this schedule. The practice in place in the interest rate area consists, on the other hand, in defining a rule-based schedule. As a result, the swapStream features are largely focused on defining such periodicity rules along with the appropriate calendar exceptions, and do not provide the possibility for defining a complete schedule of actual dates (if we except through the firstPeriodStartDate, the firstRegularPeriodStartDate and the lastRegularPeriodEndDate) and references to these.

Instead of leveraging the whole swapStream component, the interest leg of the equity swap leverages then components at a more granular level, such as the resetFrequency component, the interestCalculation component and the calculationPeriodDatesReference element.

As a result, the interest leg of the equity swap has several categories of components, which are presented in the figure 28 below and respectively specify the following features of the interest leg:

- The calculation dates (represented by interestLegCalculationPeriodDates component);
- The notional amount (represented by notional component);
- The interest amount (represented by interestAmount component);
- The interest calculation (represented by interestCalculation component);

| Figure: The interestLeg of the returnSwap.

##### 10.3.2.1 The calculation dates

The interestLegCalculationPeriodDates component defines the various dates associated with the interest leg of the swap:

- The effective date, through the effectiveDate component, also used for the equity leg of the swap;
- The termination date, through the terminationDate component that is also similar to the equity leg;
- The reset dates, via the interestLegResetDates component;
- The payment dates, through the interestLegPaymentDates component.

The diagram below presents the key features of these different date structures. Three of these components are structured in the same way: the effectiveDate, the terminationDate and the interestLegPaymentDates. These components indeed all provide the possibility to define a date (or several dates, in the case of the interestLegPaymentDates component) as either an actual date or in reference to a date specified somewhere else in the document.

The interestLegResetDates component has been developed as a simplified version of the ResetDates type that is part of the interest rates derivatives schema. Three of the seven components that are part of this ResetDates type have indeed been reused:

- The calculationPeriodDatesReference is an empty element that holds an href into the identifier attribute that is associated with the interestLegCalculationPeriodDates;
- The resetRelativeTo specifies whether the reset dates are determined with respect to each adjusted calculation period start date or adjusted calculation period end date;
- The resetFrequency component provides the possibility to define a specific reset frequency, instead of defining the reset in relation to the various interest calculation dates: the effective date, the respective interest payment dates and the termination date.

The example below presents a typical example of how this schema is applied to the standard interest leg of an equity swap:

Example 17 - The calculation period dates of the interest leg of an equity swap:

- The effectiveDate is defined similarly than for the equity leg, as one settlement cycle following the trade date;
- The terminationDate is also defined in the same way than the equity leg, as corresponding to the last equity payment date;
- The interestLegResetDates for the floating rate are defined as corresponding to the first day of each of the calculation periods by referencing the identifier that is associated with the interestLegCalculationPeriodDates node;
- The interestLegPaymentDates are specified in reference to the equity payment dates: this is called a combined reset, as a net amount corresponding to the difference between the interest and the equity amount will be exchanged on each payment date.

    	<interestLegCalculationPeriodDates id="InterestLegPeriodDates">
    	  <effectiveDate>
    	    <relativeDate>
    	      <periodMultiplier>3</periodMultiplier>
    	      <period>D</period>
    	      <dayType>ExchangeBusiness</dayType>
    	      <businessDayConvention>NotApplicable</businessDayConvention>
    	      <dateRelativeTo href="TradeDate"/>
    	    </relativeDate>
    	  </effectiveDate>
    	  <terminationDate>
    	    <relativeDate>
    	      <periodMultiplier>0</periodMultiplier>
    	      <period>D</period>
    	      <businessDayConvention>NotApplicable</businessDayConvention>
    	      <dateRelativeTo href="FinalEquityPaymentDate"/>
    	    </relativeDate>
    	  </terminationDate>
    	  <interestLegResetDates>
    	    <calculationPeriodDatesReference href="InterestLegPeriodDates"/>
    	    <resetRelativeTo>CalculationPeriodStartDate</resetRelativeTo>
    	  </interestLegResetDates>
    	  <interestLegPaymentDates>
    	    <relativeDates>
    	      <periodMultiplier>0</periodMultiplier>
    	      <period>D</period>
    	      <businessDayConvention>NotApplicable</businessDayConvention>
    	      <dateRelativeTo href="EquityPaymentDate"/>
    	    </relativeDates>
    	  </interestLegPaymentDates>
    	</interestLegCalculationPeriodDates>

##### 10.3.2.2 The notional amount

The notional amount is defined through the same structure than for the equity leg of the swap: the notional component. As mentioned earlier, and illustrated through the example 12, this component is most often used for referencing the notional amount that is defined as part of the equity leg.

##### 10.3.2.3 The interest amount

The interest amount is defined in the same way than the equity amount: using the LegAmount complex type. Used through the interest leg, it specifies the following elements:

- The settlement currency of the interest leg of the swap;
- The interest amount of the swap, either by referencing the standard ISDA Definition or by describing a very specific formula.

Example 18 - The interest amount of an equity swap:

- This example illustrates a swap that has FX terms which are referenced through the fxTerms component that is part of the equity leg. An identifier is associated with the reference currency that is defined as part of that component, and the href that is part of the paymentCurrency element refers to this identifier;
- The interest amount is specified by reference to the ISDA Equity Derivatives Definitions.

    	<interestAmount>
    	  <paymentCurrency href="ReferenceCurrency"/>
    	  <referenceAmount>Standard ISDA</referenceAmount>
    	</interestAmount>

##### 10.3.2.4 The interest calculation

The interestCalculation component specifies the interest rate reference of the swap (by referring either to a fixed interest rate or to a floating reference rate) and the day count fraction to be applied. As indicated in the introduction to the interest leg section, this structure has been developed by leveraging the components defined for the interest rate swap schema.

The component supports also compounding for on the interest leg (see optional compounding element within InterestCalculation. The compounding rate on the Interest leg can be different than that used for funding calculation. In addition, the structure supports the representation of multiple types of spreads, i.e. one for a long amount and one for a short amount.

| Figure: The interestCalculation component.

The example below presents a typical example of how this interestCalculation component can be applied for specifying the floating rate of an equity swap:

Example 19 - Specifying the floating rate of an equity swap:

- The reference rate is 3 month USD-LIBOR-BBA;
- The spread is plus 50 basis points;
- The day count fraction is actual number of days / 360 days.

    	<interestCalculation>
    	  <floatingRateCalculation>
    	    <floatingRateIndex>USD-LIBOR-BBA</floatingRateIndex>
    	    <indexTenor>
    	      <periodMultiplier>3</periodMultiplier>
    	      <period>M</period>
    	    </indexTenor>
    	    <spreadSchedule>
    	      <initialValue>0.0050</initialValue>
    	    </spreadSchedule>
    	  </floatingRateCalculation>
    	  <dayCountFraction>ACT/360</dayCountFraction>
    	</interestCalculation>

####

10.3.3 The additional payments when involving the principal parties to the trade

Similarly to the principal exchange, the EquitySwapAdditionalPayment complex type extends the design developed for the interest rate swaps by providing the ability to define dates in relation to other dates, as well as to specify the calculation logic that supports certain types of fees.

This additionalPayment structure leverages some of the features that are also used through other components:

- The additionalPaymentAmount component provides the flexibility to define an actual amount (through the paymentAmount component) and/or to describe the methodology for determining such amount, leveraging the formula component developed for the LegAmount complex type;
- Similarly to the PrincipalExchangeFeatures component, the date of each of the additional payments can be defined either as actual dates or in relation to dates defined somewhere else in the document, through respectively the adjustableDate and the relativeDate components;
- The optional paymentType string element provides the opportunity to characterize the additional payment.

Example 21 - Upfront fee:

- An upfront fee is paid by Party A to Party B, on the effective date of the swap;
- This upfront fee is equal to: 18388000 * Reference Price * [6.5% (the upfront Fee) + 0.63% (taxes)].

    	<additionalPayment>
    	  <payerPartyReference href="PartyA"/>
    	  <receiverPartyReference href="PartyB"/>
    	  <additionalPaymentAmount>
    	    <formula>
    	      <formulaDescription>18388000 * Reference Price * [6.5% (the upfront Fee) + 0.63% (taxes)]</formulaDescription>
    	      <math>
    	        <mn>18388000 </mn>
    	        <mo>*</mo>
    	        <mi>ReferencePrice</mi>
    	        <mo>*</mo>
    	        <mo>(</mo>
    	        <mn>6.5</mn>
    	        <mo>%</mo>
    	        <mo>+</mo>
    	        <mn>0.63</mn>
    	        <mo>%</mo>
    	        <mo>)</mo>
    	      </math>
    	      <formulaComponent name="ReferencePrice">
    	        <componentDescription>Volume-weighted average price per share of underlying security on Trade Date</componentDescription>
    	      </formulaComponent>
    	    </formula>
    	  </additionalPaymentAmount>
    	  <additionalPaymentDate>
    	    <relativeDate>
    	      <periodMultiplier>0</periodMultiplier>
    	      <period>D</period>
    	      <businessDayConvention>NotApplicable</businessDayConvention>
    	      <dateRelativeTo href="EffectiveDate"/>
    	    </relativeDate>
    	  </additionalPaymentDate>
    	  <paymentType>Upfront fee</paymentType>
    	</additionalPayment>

####

10.3.4 The optional early termination

The purpose of the ReturnSwapEarlyTermination component is to specify the date from which each of the parties to the trade may have the right to terminate it early. The figure 33 below presents the structure of this component:

Figure: The earlyTermination component.

Similarly to the other date-related components that are part of the return swap, the date can be specified using either the adjustableDate component or the relativeDate component. Considering that the standard market practice is to provide the ability for both the parties to the trade to early terminate it starting on Trade Date, the relativeDate element should be used most often. This is illustrated in the example below.

    	<earlyTermination>
    	  <partyReference href="PartyA"/>
    	  <startingDate>
    	    <dateRelativeTo href="TradeDate"/>
    	  </startingDate>
    	</earlyTermination>
    	<earlyTermination>
    	  <partyReference href="PartyB"/>
    	  <startingDate>
    	    <dateRelativeTo href="TradeDate"/>
    	  </startingDate>
    	</earlyTermination>

## 11 VARIANCE PRODUCT ARCHITECTURE

### 11.1 Variance Derivatives Scope

The Equity Derivative Working Group extended FpML to cover:

- Variance Swaps, a type of volatility swap where the payout is linear to variance rather than volatility, therefore the payout will rise at a higher rate than volatility;
- Short Form Variance Options represented also as Transaction Supplements under ISDA Master Confirmation Agreements.

### 11.2 Overall Architecture

Variance Swaps and Options are modelled using the following product element in FpML:

- varianceSwapTransactionSupplement
- varianceOptionTransactionSupplement

Please note that the following documentation describes the full, confirmation-view representation of variance swaps. In Transparency view, some of the fields mentioned below are not available. Please consult the schema reference for more precise documentation.

these components provide support for:

####

11.2.1 varianceSwapTransactionSupplement

varianceSwapTransactionSupplement specifies the structure of a variance swap transaction supplement. This modelled using the same variance legs as Variance Swap, but does not allow for long form content such as extraordinary events.

####

11.2.2 VarianceLeg

varianceLeg - A type describing return which is driven by a Variance calculation.

| legIdentifier - Version aware identification of this leg. (e.g. Variance Dispersion typically involves many legs, with 1 IVS and 50 EVS legs being typical. Leg Identifier has been introduced as an optional child element to support identification of each of these legs.)

####

11.2.3 varianceOptionTransactionSupplement

varianceOptionTransactionSupplement specifies the structure of a variance option transaction supplement. VarianceOptionTransactionSupplement implements Variance Option Transaction Supplement by providing a short form representation for use in trades governed by a Master Confirmation Agreement.

## 12 DIVIDEND PRODUCT ARCHITECTURE

### 12.1 Overall Architecture

Dividend Swaps (Transaction Supplement form) are modelled using the following product element in FpML: dividendSwapTransactionSupplement.

- dividendSwapTransactionSupplement

####

12.1.1 dividendSwapTransactionSupplement

dividendSwapTransactionSupplement specifies the structure of the dividend swap transaction supplement.

| productType - A classification of the type of product. FpML defines a simple product categorization using a coding scheme. productId - A product reference identifier allocated by a party. FpML does not define the domain values associated with this element. Note that the domain values for this element are not strictly an enumerated list. additionalPayment - Specifies additional payment(s) between the principal parties to the netted swap. dividendLeg - Dividend leg. fixedLeg - Fixed payment leg.

####

12.1.2 dividendLeg

dividendLeg - Floating Payment Leg of a Dividend Swap.

####

12.1.3 fixedLeg

fixedLeg - Fixed Payment Leg of a Dividend Swap.

## 13 CORRELATION PRODUCT ARCHITECTURE

### 13.1 Overall Architecture

Correlation Swaps are modelled using the following product element in FpML:

- correlationSwap

####

13.1.1 correlationSwap

The correlationSwap product is modelled as a single netted leg.

| productType - A classification of the type of product. FpML defines a simple product categorization using a coding scheme. productId - A product reference identifier allocated by a party. FpML does not define the domain values associated with this element. Note that the domain values for this element are not strictly an enumerated list. additionalPayment - Specifies additional payment(s) between the principal parties to the netted swap. extraordinaryEvents - Where the underlying is shares, defines market events affecting the issuer of those shares that may require the terms of the transaction to be adjusted. correlationLeg - A type describing return which is driven by a Correlation calculation.

####

13.1.2 correlationLeg

The correlationLeg - A type describing return which is driven by a Correlation calculation.

## 14 BOND OPTIONS PRODUCT ARCHITECTURE

### 14.1 Introduction

This section provides an in-depth review of the product architecture of FpML 5.5 regarding Bond and Convertible Bond Options. It also covers the set of shared option constructs that are used by other types of options, not only Bond or CB options.

####

14.1.1 bondOption

The bondOption product element provides support for Bond and Convertible Bond options. Like all other derivative products supported by FpML, the BondOption type is an extension of Product and the bondOption element belongs to the FpML product substitution group.

### 14.2 Shared Option Components

####

14.2.1 OptionBase

The OptionBase type defines the schema structure associated with optionType: The type of option transaction. From a usage standpoint, put/call is the default option type, while payer/receiver indicator is used for options index credit default swaps as well as the swaptions. Straddle is used for the case of straddle strategy, which combines a call and a put with the same strike. The optionType is to be used if the underlyer does not carry any mention of the resulting trade direction as well as in the case of a straddle.

####

14.2.2 OptionBaseExtended

Incorporates features that are not underlyer-specific and cannot be integrated as part of the OptionBase because of backward compatibility reasons with the eqd schema.

##### 14.2.2.1 Premium

The premium construct has a similar approach than the swaption (i.e. premium based upon a premium construct), but introduces a simplified payment that does not incorporate the settlement features. In order to make this construct forward applicable to the equity options, this new SimplePayment is then extended to incorporate some premium-specific concepts that currently exist as part of the eqd schema.

##### 14.2.2.2 Exercise

The overall approach is to leverage the swaption constructs, both for the Exercise and the ExerciseProcedure, with a couple of backward compatible extensions to tackle some specific features.

The proposed extension is for the multiple exercise, where the existing Multiple Exercise only support notional amounts, while the template for convertible bonds refers to number of options:

Multiple Exercise: | Applicable
Minimum Number of Options: | The lesser of (i) [ ] and (ii) the unexercised number of Options
Maximum Number of Options: | The unexercised number of Options
Integral Multiple: | 1

As a result, the new schema introduces choice nodes to provide the ability to express the minimum/maximum levels either in terms of notional amounts (swaptions) or number of options (bond and CB options).

In addition, the notionalReference node is made optional, as this reference is not used in the case of options on securities.

##### 14.2.2.3 The Notional construct

This provides the ability to support the notional for CDS option as expressed in the ISDA template, i.e. as a reference to the notional of the underlyer swap or as an explicit amount.

##### 14.2.2.4 The Denomination construct

This requirement was identified in the case of bond and CB option. Not CDS options. The structure positions an explicit construct as part of the base type, so that it can be applied over time to the equity options. The currency has been added, as it is present as part of the bond and CB option confirmations.

### 14.3 The Option on Bond and Convertible Bond

####

14.3.1 The strike

The market practice consists in pricing convertible bond options based upon a swap curve, while also to include 'standard penalty' (called Make Whole Amount) in the case where the option is exercised early one. Conversely, the bond options are priced using a price reference.

As a result, the BondOptionStrike provides a choice between a swap curve reference and a price.

####

14.3.2 The convertible bond underlyer

Two changes have been added to the convertible bond underlyer in order to support options on convertible bonds:

- Added the redemption date (defined as "Earlier date between put dates and maturity date."), as it is specified as part of the CB option template;
- Made the underlyingEquity optional, for consistently with the guideline for underlying assets (internal systems just reference the instrumentId).

## 15 COMMODITY DERIVATIVE PRODUCT ARCHITECTURE

NOTE: Some refactoring work for SettlementPeriods are being considered for the next draft.

### 15.1 Introduction

This section provides a detailed description of the product architecture for commodity derivatives. FpML transparency view currently provides support for cash-settled commodity swaps (fix/float), cash settled commodity options, bullion forwards, and physically settled natural gas, oil, electricity, and coal swaps.

### 15.2 Commodity Underlyer

The 'commodity' underlyer identifies the market price on which the OTC contract is written. The structure of the 'commodity' underyer follows the ISDA Commodity Reference Price Framework. FpML defines a number of global elements in the FpML schema for various types of assets The 'commodity' underlyer follows the same model.

The 'instrumentId' and the 'description' elements are derived from the IdentifiedAsset type, which is used by multiple underlyers. The 'instrumentId' contains the unique identifier for the asset, and is intended to hold a Commodity Reference Price in the format set out by ISDA in the 1993 or 2005 Commodity Definitions. However, a CUSIP, ISIN, or any other identifier could also be used. The 'description' contains the name of the asset.

The following sequence of elements is optional and they are specified only in the event that no ISDA Commodity Reference Price or other standard identifier for a commodity 'index' exists.

| commodityBase-A coding scheme value to identify the base type of the commodity being traded. Where possible, this should follow the naming convention used in the 2005 ISDA Commodity Definitions. For example, 'Oil'.

specifiedPrice-The 'specified Price' describes the nature of the underlying price that is observed. It must be be stated in the underlyer definition as it is not defined in the Commodity Reference Price. Example values of 'specifiedPrice' are 'Settlement' (for a futures contract) and 'WeightedAverage' (for some published prices and indices).

deliveryDates-The 'deliveryDates' element is applicable for a Commodity Reference Price that references a listed future contract (e.g. The Delivery Date is a NearbyMonth).

### 15.3 commoditySwap

CommoditySwap-The commodity swap product model is designed to support fixed-float swaps, float-float swaps, fixed vs. physical swaps, float vs. physical swaps as well as, weather specific swaps. Its design is fully compatible with other FpML products and the product reuses standard common types.

As with all products in FpML, commodity swaps are accessed through a global element, 'commoditySwap', which substitutes for the 'product' element used in trade structures. The following diagram outlines the product structure.

The 'commoditySwap' structure defines parameters for product-related information (e.g. dates, rates, underlying commodity, price source, etc.). Other trade-related information (e.g. trade date, identifiers, legal documentation, etc.) is held in the containing 'trade' structure.

The 'commoditySwapLeg' element is placeholder within commoditySwap structure for the actual commoditySwap swap legs (e.g. 'fixedLeg' and 'floatingLeg'). The 'weatherLeg' is modeled as a choice to 'commoditySwapLeg' because weather index transactions are strictly financially-settled transaction and always structured with two legs, each of which is a 'weatherLeg'.

The 'fixedLeg', 'floatingLeg', 'weatherLeg' elements contain the details of any scheduled cash payments or exchanges during the life of the instrument and are described later. A transparency view commodity swap contains two legs, one fixed and one floating, or two weather legs. More complex instruments are considered customized and are not fully covered in transparency view; for these, the "nonStandardTerms" indicator should be set to "true".

Physical settlement of swaps is represented using 'coalPhysicalLeg', 'electricityPhysicalLeg', 'gasPhysicalLeg', 'oilPhysicalLeg', 'environmentalPhysicalLeg' paired with 'fixedLeg' or 'floatingLeg' - see details in the Physical Leg section.

####

15.3.2 fixedLeg

FixedPriceLeg-Fixed Price Leg of a Commodity Swap. It defines schedule of fixed payments associated with a commodity swap.

| CommodityCalculationPeriods.model-The different options for specifying the Calculation Periods. CommodityFixedPrice.model-The different options for specifying the Fixed Price. CommodityNotionalQuantity.model-The different options for specifying the Notional Quantity. A flat notional for the term of the contract may be specified, or else the Notional Quantity per Calculation Period. In the latter case, there must be a notional quantity step specified for each Calculation Period, regardless of whether the Notional Quantity changes or remains the same between periods. CommodityFreightFlatRate.model-The Flat Rate, applicable to Wet Voyager Charter Freight Swaps.

- The 'fixedPrice' structure defines the price for a given unit of the underlying commodity where that price is fixed for the life of the trade.
- The 'totalPrice' structure specifies the total amount of all fixed payments due during the term of the trade.
- The total notional quantity and quanity units also must be supplied.

####

15.3.3 floatingLeg

FloatingPriceLeg-Floating Price Leg of a Commodity Swap. Each 'floatingLeg' defines a series of financial payments for a commodity the value of which is derived from a floating price such as an exchange or an index publication.

| CommodityCalculationPeriods.model-The different options for specifying the Calculation Periods. commodity-Specifies the underlying instrument. Only underlyers of type Commodity are supported.Specifies the underlying instrument. Only underlyers of type Commodity are supported. CommodityNotionalQuantity.model-The different options for specifying the Notional Quantity. A flat notional for the term of the contract may be specified, or else the Notional Quantity per Calculation Period. In the latter case, there must be a notional quantity step specified for each Calculation Period, regardless of whether the Notional Quantity changes or remains the same between periods. calculation-Defines details relevant to the calculation of the floating price.Defines details relevant to the calculation of the floating price.

Two structures distinguish the 'floatingLeg' from the 'fixedLeg': the existence of the 'commodity' underlyer (see description above at the Commodity Underlyer section) and the 'calculation' structure within the floating leg.

##### 15.3.3.2 calculation

The 'calculation' structure captures details relevant to the calculation of the floating price.

FloatingLegCalculation-A type to capture details relevant to the calculation of the floating price.

The structure is defined by the following elements:

| pricingDates- represent the dates on which prices are observed for the underlyer. averagingMethod-The parties may specify a Method of Averaging where more than one pricing Dates is being specified as being applicable. In some trades, there may be a spread-The spread over or under the Commodity Reference Price for this leg of the trade. spreadPercentage-The spread percentage over or under the Commodity Reference Price for this leg of the trade.

##### 15.3.3.2.1 pricingDates

CommodityPricingDates-The dates on which prices are observed for the underlyer.

| PricingDays.model-The different options for specifying which days are pricing days within a pricing period. Unless a lag element is present, the pricing period will be contained within the calculation period. calendarSource-No Annotation Available

####

15.3.4 weatherLeg

WeatherLeg-A weather leg of a Commodity Swap defines Weather Index Swap transactions. Weather Index Swap transactions are OTC derivative transactions which settle financially based on an index calculated from observations of temperature, precipitation and other weather-related measurements at weather stations throughout the world. Sub-Annex C of the 2005 ISDA Commodity Definitions provides definitions and terms for a number of types of weather indices. These indices include: HDD (heating degree days), CDD (cooling degree days), CPD (critical precipitation days). Weather Index Swap transactions result in a cash flow to one of the two counterparties each Calculation Period depending on the relationship between the Settlement Level and the Weather Index Level. A Weather Index swap transaction always consists of a commodity swap element as a parent to two weatherLeg elements.
Weather Index transaction = weatherLeg/weatherLeg.

| weatherIndexLevel-Defining the Weather Index Level or Weather Index Strike Level.Defining the Weather Index Level or Weather Index Strike Level. WeatherCalculationPeriod.model-Descriptions of a calculation period. weatherNotionalAmount-Defines the price per weather index unit.Defines the price per weather index unit. calculation-Defines details relevant to the calculation of the aggregate weather index amount.Defines details relevant to the calculation of the aggregate weather index amount. weatherIndexData-Specifies where the data (e.g. CPD) have been collected, an actual physical reference point (weather station) and various fall back arrangements.Specifies where the data (e.g. CPD) have been collected, an actual physical reference point (weather station) and various fall back arrangements.

##### 15.3.4.1 weatherLeg - WeatherIndex

WeatherIndex-A type defining the Weather Index Level or Weather Index Strike Level.

| quantity-This is the Reference Level. The CDD, HDD or HDD Reference Level is specified as the number of (amount of) Weather Index Units specified by the parties in the related Confirmation. unit-Weather Index Unit derived from one of the following variable methods of determination: Cooling Degree Day (CDD), Heating Degree Day (HDD), Critical Precipitation Day (CPD) as defined in Section 11.15 of the 2005 ISDA Commodity Definitions and User Guide.

##### 15.3.4.2 weatherLeg - WeatherCalculationPeriod

| WeatherCalculationPeriods-The schedule of Calculation Period First Days and Lasts Days. If there is only one First Day - Last Day pair then the First is equal to the Effective Date and the Last Day is equal to the Termination Date. or

##### 15.3.4.3 weatherLeg - weatherNotionalAmount

weatherNotionalAmount-Defines the price per weather index unit.Defines the price per weather index unit.

##### 15.3.4.4 weatherLeg - calculation

WeatherLegCalculation-A type to capture details of the calculation of the Payment Amount on a Weather Index Transaction.

| settlementLevel-The Settlement Level means either the cumulative number of Weather Index Units for each day in the Calculation Period (Cumulative) or the cumulative number of Weather Index Units for each day in the Calculation Period divided by the number of days in the Calculation Period (Average) or the maximum number of Weather Index Units for any day in the Calculation Period (Maximum) or the minimum number of Weather Index Units for any day in the Calculation Period. referenceLevelEqualsZero-If Reference Level Equals Zero is specified to be applicable then CPD means, for any day during the Calculation Period, (A) 1 if the Daily Precipitation for that day is greater than or equal to the CPD Reference Level or (B) zero if the the Daily Precipitation for that day is less than the CPD Reference Level. If Reference Level Equals Zero is specified not to be applicable then CPD means, for any day during the Calculation Period, (A) 1 if the Daily Precipitation for that day is greater than the CPD Reference Level or 0 if the Daily Precipitation for that day is less than or equal to the CPD Reference Level. calculationDate-The number of days following the final day of the Calculation Period specified in the Confirmation on which is is practicable to provide the notice that the Calculation Agent is required to give for that Settlement Date or Payment Date. maximumPaymentAmount-The maximum total payment amount that will be paid in any particular transaction. maximumTransactionPaymentAmount-The maximum payment amount that will be paid in any particular Calculation Period.

##### 15.3.4.5 weatherLeg - weatherIndexData

WeatherIndexData-No Annotation Available

| referenceLevel-Reference level is the number of degree-days (in the case of HDD and CDD) or inches/millimeters (in the case of CPD) on which the differential is calculated. In the case of HDD it is the number of degree-days below this reference level. In the case of CDD it is the number of degree days above this reference level. In the case of CPD it is number of inches/millimeters above this reference level.

####

15.3.5 Physical Leg

##### 15.3.5.1 Coverage

The support for physically-settled commodity swap trades includes,

- Natural Gas
- Oil
- Electricity
- Coal
- Environmental

##### 15.3.5.2 Product Representation

The product representation of physically-settled commodity swap or commodity forward contracts not written on a metal underlying is done within the commoditySwap product element by adding a family of physical legs.

- Fixed price transaction = xxxPhysicalLeg + fixedLeg
- Floating price transaction = xxxPhysicalLeg + floatingLeg

Note: xxx gets replaced by 'oil', 'gas', 'electricity', 'coal' or 'environmental'.

The following structures vary between all these commodities,

- Delivery periods
- Product
- Delivery
- Quantities

##### 15.3.5.2.1 Gas Physical Leg

gasPhysicalLeg

| gas-The specification of the gas to be delivered.The specification of the gas to be delivered. deliveryConditions-The physical delivery conditions for the transaction.The physical delivery conditions for the transaction. deliveryQuantity-The different options for specifying the quantity. For Fixed trades where the quantity is known at the time of confirmation, a single quantity or a quantity per Delivery Period may be specified. For Variable trades minimum and maximum trades may be specified.The different options for specifying the quantity. For Fixed trades where the quantity is known at the time of confirmation, a single quantity or a quantity per Delivery Period may be specified. For Variable trades minimum and maximum trades may be specified.

##### 15.3.5.2.1.1 gasPhysicalLeg - product

| type-The type of gas to be delivered. calorificValue-No Annotation Available quality-No Annotation Available

##### 15.3.5.2.1.2 gasPhysicalLeg - deliveryConditions

| CommodityDeliveryPoints.model-A Delivery Point, applicable to physically settled commodity transactions. deliveryType-Indicates whether the buyer and seller are contractually obliged to consume and supply the specified quantities of the commodity. interconnectionPoint-Identification of the border(s) or border point(s) of a transportation contract. buyerHub-The hub code of the gas buyer. sellerHub-The hub code of the has seller.

##### 15.3.5.2.1.3 gasPhysicalLeg - deliveryQuantity

| CommodityFixedPhysicalQuantity.model-The different options for specifying a fixed physical quantity of commodity to be delivered. minPhysicalQuantity-No Annotation Available maxPhysicalQuantity-No Annotation Available electingParty-No Annotation Available

##### 15.3.5.2.2 Oil Physical Leg

Physically settled oil or refined products leg.

##### 15.3.5.2.2.1 oilPhysicalLeg - product

##### 15.3.5.2.2.2 oilPhysicalLeg - deliveryConditions

##### 15.3.5.2.2.3 oilPhysicalLeg - deliveryQuantity

##### 15.3.5.2.3 Electricity Physical Leg

Physically settled electricity leg.

##### 15.3.5.2.3.1 electricityPhysicalLeg - product

##### 15.3.5.2.3.2 electricityPhysicalLeg - deliveryConditions

##### 15.3.5.2.3.3 electricityPhysicalLeg - deliveryQuantity

##### 15.3.5.2.4 Coal Physical Leg

Physically settled coal leg.

##### 15.3.5.2.4.1 coalPhysicalLeg - product

##### 15.3.5.2.4.2 coalPhysicalLeg - deliveryConditions

##### 15.3.5.2.4.3 coalPhysicalLeg - deliveryQuantity

##### 15.3.5.2.5 Environmental Physical Leg

EnvironmentalPhysicalLeg-No Annotation Available

| numberOfAllowances-The number of allowances, certificates or credit to be transaction in the transaction.The number of allowances, certificates or credit to be transaction in the transaction. environmental-The specification of the type of allowance or credit.The specification of the type of allowance or credit. abandonmentOfScheme-Applies to U.S. Emissions Allowance Transactions. Specifies terms which apply in the event of an Abandonment of Scheme event.Applies to U.S. Emissions Allowance Transactions. Specifies terms which apply in the event of an Abandonment of Scheme event.

##### 15.3.5.2.5.1 environmentalPhysicalLeg - numberOfAllowances

UnitQuantity-A quantity and associated unit.

| quantityUnit-Quantity Unit is the unit of measure applicable for the quantity on the Transaction. quantity-Amount of commodity per quantity frequency.

##### 15.3.5.2.5.2 environmentalPhysicalLeg - product

EnvironmentalProduct-A type defining the characteristics of the environmental allowance or credit being traded. Settlement of environmental transactions is classified as physical because settlement is accomplished through the exchange of one or more certificates (despite the fact that this exchange is almost always executed through electronic book entry transfer between the parties allowance accounts).

| productType-Specifies the type of environmental allowance or credit. Examples include allowances or credit issued by the European Union (E.U.) or by the State of California in the Unites States. vintage-Applies to U.S. Emissions Allowance Transactions. The year(s) of the applicable Emissions Product(s) as specified in an Emissions Transaction. applicableLaw-Applies to U.S. Emissions Allowance Transactions. Used to specify the Applicable Emissions Law when this is not defined in Emissions Product Definitions Exhibit. trackingSystem-Applies to U.S. Emissions Allowance Transactions. Used to specify the Tracking System when this is not defined in Emissions Product Definitions Exhibit.

##### 15.3.5.2.5.3 environmentalPhysicalLeg - abandonmentOfScheme

abandonmentOfScheme-Applies to U.S. Emissions Allowance Transactions. Specifies terms which apply in the event of an Abandonment of Scheme event.Applies to U.S. Emissions Allowance Transactions. Specifies terms which apply in the event of an Abandonment of Scheme event.

### 15.4 commodityOption

commodityOption-Defines a commodity option product. The product support for financially-settled exercises or exercise into physical forward contracts written on precious and non-precious metals. options in FpML is based on the creation of a 'commodityOption' product. The product references the 'commodity' underlyer in order to support the underlying asset of the option.
The product support for financially-settled or physically-settled forward (for preciouse and non-preciouse metal) options in FpML is based on the creation of a 'commodityOption' product. The product references the 'commodity' underlyer in order to support the underlying asset of the option.

All FpML products inherit two optional elements from the Product type: 'productType' and 'productId'. The 'productType' defines a classification of the type of product. FpML defines a simple product categorization using a coding scheme. The 'productId' contains a product reference identifier allocated by a party. In this case, FpML does not define the domain values associated with this element.

| CommodityOption-Defines a commodity option product type. The product support for financially-settled exercises or exercise into physical forward contracts written on precious and non-precious metals. options in FpML is based on the creation of a 'commodityOption' product. The product references the 'commodity' underlyer in order to support the underlying asset of the option. CommodityFinancialOption.model-Items specific to financially-settled commodity options. CommodityPhysicalOption.model-Items specific to financially-settled commodity options. For specifying physically-settled forward (preciouse and non-preciouse metal forward) options. NOTE: support for other physically-settled options within commodityOption was DEPRICATED. The commoditySwaption product, should be used instead. CommodityWeatherOption.model-Described Weather Index Option component. Weather Index Option transactions are OTC derivative transactions which settle financially based on an index calculated from observations of temperature and precipitation at weather stations throughout the world. Sub-Annex C of the 2005 ISDA Commodity Definitions provides definitions and terms for a number of types of weather indices. These indices include: HDD (heating degree days), CDD (cooling degree days), CPD (critical precipitation days). Weather Index Option Transactions results in a cash flow to the buyer depending on the relationship between the Settlement Level to the Weather Index Strike Level. premium-The option premium payable by the buyer to the seller.The option premium payable by the buyer to the seller.

The choice between 'CommodityFinancialOption.model', 'CommodityPhysicalOption.model' and 'CommodityWeatherOption.model' models allows to select the financially-settled commodity options, or physically-settled forward (precious and non-precious metal) options, or weather specific option and described below.

####

15.4.1 commodityOption - CommodityFinancialOption

CommodityFinancialOption.model-Items specific to financially-settled commodity options.

| commodity-Specifies the underlying instrument. Usual content is an ISDA Commodity Reference Price Name. The 'commodity' underlyer component is specified using a reference to the 'commodity' asset (see description above at the Commodity Underlyer section). The 'commodity' underlyer component is specified using a reference to the 'commodity' asset (see description above at the Commodity Underlyer section). CommodityOptionFeatures.model-Describes additional features within the option. exercise-The parameters for defining how the commodity option can be exercised and how it is settled. CommodityStrikePrice.model-The different options for specifying the Strike price per unit. Note that the intention is that a strike price per unit step should be specified for each Calculation Period in the trade, regardless of whether there is a change in value between two periods. This is so as to match the strike price schedule to the calculation periods as clearly as possible. The strike price per unit of the strike price per unit steps must be in chronological order (i.e the first step corresponds to the first Calculation Period, the last step to the last Calculation Period). CommodityFloatingStrikePrice.model-The different options for specifying the average strike price per unit. These options are to specify a single average strike price per unit or to specify a schedule of average strike prices.

##### 15.4.1.1 commodityOption - CommodityFinancialOption - CommodityOptionFeatures

CommodityOptionFeatures.model-Describes additional features within the option.

| effectiveDate-The effective date of the Commodity Option Transaction. Note that the Termination/Expiration Date should be specified in expirationDate within the CommodityAmericanExercise type or the CommodityEuropeanExercise type, as applicable. terminationDate-Specifies the termination date of the Commodity Option Transaction. In some confirmations this will be indicated as the second date in "Option Term" or "Term". Note: If provided, terminationDate should not be before specified expirationDate within the CommodityAmericanExercise type or the CommodityEuropeanExercise type. CommodityAsian.model-Model group containing features specific to asian/averaging commodity options.

##### 15.4.1.1.1 commodityOption - CommodityFinancialOption - CommodityOptionFeatures - CommodityAsian

CommodityAsian.model-Model group containing features specific to asian/averaging commodity options.

The following elements are specific to asian/averaging commodity options only:

| The Calculation Periods are represented explicitly with the 'calculationPeriods' element or as a parametric representation with the 'calculationPeriodsSchedule' structure. The 'pricingDates' element defines the dates on which the option will price. The 'averagingMethod' is present if there is more than one 'pricingDates' element.

##### 15.4.1.2 commodityOption - CommodityFinancialOption - CommodityNotionalQuantity

As with the 'commoditySwap', the notional amount of the 'commodityOption' is specified stating either the 'notionalQuantity' or if the notional changes over the life of the transaction, then the 'notionalQuantitySchedule' is specified. In addition, the 'totalNotionalQuantity' must be specified. Note that the intention is that a notional step should be specified for each Calculation Period in the trade, regardless of whether there is a change in value between two periods. This is so as to match the notional quantity schedule to the calculation periods as clearly as possible. The notional steps must be in chronological order (i.e the first step corresponds to the first Calculation Period, the last step to the last Calculation Period).

| CommodityNotionalQuantity.model-The different options for specifying the Notional Quantity. A flat notional for the term of the contract may be specified, or else the Notional Quantity per Calculation Period. In the latter case, there must be a notional quantity step specified for each Calculation Period, regardless of whether the Notional Quantity changes or remains the same between periods.

##### 15.4.1.3 commodityOption - CommodityFinancialOption - CommodityExercise

CommodityExercise-The parameters for defining how the commodity option can be exercised, how it is priced and how it is settled.

| americanExercise-The parameters for defining the expiration date for an American option. europeanExercise-The parameters for defining the expiration date and time for a European or Asian style option. For an Asian style option the expiration date is equivalent to the termination date. settlementCurrency-The currency into which the Commodity Option Transaction will settle. If this is not the same as the currency in which the Commodity Reference Price is quoted, then an FX determination method should also be specified.

##### 15.4.1.3.1 CommodityAmericanExercise

CommodityAmericanExercise-A type for defining exercise procedures associated with an American style exercise of a commodity option.

| exercisePeriod-Describes the American exercise periods. exerciseFrequency-The exercise frequency for the strip.

##### 15.4.1.3.2 CommodityEuropeanExercise

CommodityEuropeanExercise-A type for defining exercise procedures associated with a European style exercise of a commodity option.

| expirationDate-The last day within an exercise period for an American style option. For a European style option it is the only day within the exercise period. For an averaging option this is equivalent to the Termination Date. exerciseFrequency-The exercise frequency for the strip.

####

15.4.2 commodityOption - CommodityWeatherOption

CommodityWeatherOption.model-Described Weather Index Option component. Weather Index Option transactions are OTC derivative transactions which settle financially based on an index calculated from observations of temperature and precipitation at weather stations throughout the world. Sub-Annex C of the 2005 ISDA Commodity Definitions provides definitions and terms for a number of types of weather indices. These indices include: HDD (heating degree days), CDD (cooling degree days), CPD (critical precipitation days). Weather Index Option Transactions results in a cash flow to the buyer depending on the relationship between the Settlement Level to the Weather Index Strike Level.

| effectiveDate-Effective date of an option. WeatherCalculationPeriod.model-Descriptions of a calculation period. weatherNotionalAmount-No Annotation Available exercise-No Annotation Available weatherIndexStrikeLevel-Weather Index strike price level is specified in terms of weather index units (e.g. 1 Days, 3 Inches, etc.) calculation-Contains parameters which figure in the calculation of payments on a Weather Index Option. weatherIndexData-Specifies where the data (e.g. CPD) have been collected, an actual physical reference point (weather station) and various fall back arrangements.

effectiveDate is an effectiveDate of a Weather Index Option.

##### 15.4.2.1 commodityOption - CommodityWeatherOption - WeatherCalculationPeriod

WeatherCalculationPeriod.model-Descriptions of a calculation period.

Weather Index Swap and Weather Index Option transactions are OTC derivative transactions which settle financially based on a index calculated from observations of temperature and precipitation at weather stations throughout the world. Sub-Annex C of the 2005 ISDA Commodity Definitions provides definitions and terms for a number of types of weather indices. These indices include: HDD (heating degree days), CDD (cooling degree days), CPD (critical precipitation days). Weather Index Swap transactions result in a cash flow to one of the two counterparties each Calculation Period depending on the relationship between the Settlement Level and the Weather Index Level. Weather Index Option Transactions results in a cash flow to to the buyer if depending on the relationship between the Settlement Level to the Weather Index Strike Level.

| weatherCalculationPeriods-No Annotation Available

##### 15.4.2.1.1 WeatherCalculationPeriods

WeatherCalculationPeriods-The schedule of Calculation Period First Days and Lasts Days. If there is only one First Day - Last Day pair then the First is equal to the Effective Date and the Last Day is equal to the Termination Date.

| calculationPeriodFirstDay-No Annotation Available calculationPeriodEndDay-No Annotation Available

##### 15.4.2.2 commodityOption - CommodityWeatherOption - weatherNotionalAmount

weatherNotionalAmount-No Annotation Available

##### 15.4.2.3 commodityOption - CommodityWeatherOption - exercise

exercise-No Annotation Available

| Note: americanExercise-The parameters for defining the expiration date for an American option. - is not to be used with Weather Options europeanExercise-The parameters for defining the expiration date and time for a European or Asian style option. For an Asian style option the expiration date is equivalent to the termination date. settlementCurrency-The currency into which the Commodity Option Transaction will settle. If this is not the same as the currency in which the Commodity Reference Price is quoted, then an FX determination method should also be specified.

##### 15.4.2.3.1 paymentDates

paymentDates-Dates on which payments will be made.

##### 15.4.2.4 commodityOption - CommodityWeatherOption - weatherIndexStrikeLevel

weatherIndexStrikeLevel-Weather Index strike price level is specified in terms of weather index units (e.g. 1 Days, 3 Inches, etc.)

| quantity-This is the Reference Level. The CDD, HDD or HDD Reference Level is specified as the number of (amount of) Weather Index Units specified by the parties in the related Confirmation. unit-Weather Index Unit derived from one of the following variable methods of determination: Cooling Degree Day (CDD), Heating Degree Day (HDD), Critical Precipitation Day (CPD) as defined in Section 11.15 of the 2005 ISDA Commodity Definitions and User Guide.

##### 15.4.2.5 commodityOption - CommodityWeatherOption - calculation

calculation-Contains parameters which figure in the calculation of payments on a Weather Index Option.

| settlementLevel-The Settlement Level means either the cumulative number of Weather Index Units for each day in the Calculation Period (Cumulative) or the cumulative number of Weather Index Units for each day in the Calculation Period divided by the number of days in the Calculation Period (Average) or the maximum number of Weather Index Units for any day in the Calculation Period (Maximum) or the minimum number of Weather Index Units for any day in the Calculation Period. referenceLevelEqualsZero-If Reference Level Equals Zero is specified to be applicable then CPD means, for any day during the Calculation Period, (A) 1 if the Daily Precipitation for that day is greater than or equal to the CPD Reference Level or (B) zero if the the Daily Precipitation for that day is less than the CPD Reference Level. If Reference Level Equals Zero is specified not to be applicable then CPD means, for any day during the Calculation Period, (A) 1 if the Daily Precipitation for that day is greater than the CPD Reference Level or 0 if the Daily Precipitation for that day is less than or equal to the CPD Reference Level. calculationDate-The number of days following the final day of the Calculation Period specified in the Confirmation on which is is practicable to provide the notice that the Calculation Agent is required to give for that Settlement Date or Payment Date. maximumPaymentAmount-The maximum total payment amount that will be paid in any particular transaction. maximumTransactionPaymentAmount-The maximum payment amount that will be paid in any particular Calculation Period.

##### 15.4.2.6 commodityOption - CommodityWeatherOption - weatherIndexData

weatherIndexData-Specifies where the data (e.g. CPD) have been collected, an actual physical reference point (weather station) and various fall back arrangements.

| referenceLevel-Reference level is the number of degree-days (in the case of HDD and CDD) or inches/millimeters (in the case of CPD) on which the differential is calculated. In the case of HDD it is the number of degree-days below this reference level. In the case of CDD it is the number of degree days above this reference level. In the case of CPD it is number of inches/millimeters above this reference level.

####

15.4.3 commodityOption - CommodityPhysicalOption

CommodityPhysicalOption.model-Items specific to financially-settled commodity options.

The approach is similar to that used for interest rate swaptions by embedding a physically-settled precious and non-precious metal forward transaction within the option transaction. So that the exercise of an option results in a new physically-settled forward transaction.

| commodityForward-Defines a commodity forward product. physicalExercise-The parameters for defining how the commodity option can be exercised into a physical transaction.

The 'commodityForward' component is described in the 'Commodity Forward' section below.

The 'physicalExercise' component is the same as for physically-settled commodity options described in the 'commoditySwaption' section below.

NOTE: support for other physically-settled options within 'commodityOption' is DEPRICATED. The 'commoditySwaption' product should be used instead.

### 15.5 commoditySwaption

The commoditySwaption is specific to physically-settled commodity options:

All FpML products inherit two optional elements from the Product type: 'productType' and 'productId'. The 'productType' defines a classification of the type of product. FpML defines a simple product categorization using a coding scheme. The 'productId' contains a product reference identifier allocated by a party. In this case, FpML does not define the domain values associated with this element.

| CommoditySwaption-Commodity Swaption. optionType-The type of option transaction.The type of option transaction. e.g. a call option or a put option. commoditySwap-The underlying commodity swap definiton.The underlying commodity swap definiton. physicalExercise-The parameters for defining how the commodity option can be exercised into a physical transaction.The parameters for defining how the commodity option can be exercised into a physical transaction. premium-The option premium payable by the buyer to the seller.The option premium payable by the buyer to the seller.

####

15.5.1 commoditySwaption - CommoditySwapDetails

The approach is similar to that used for interest rate swaptions by embedding a physically-settled swap transaction within the option transaction. So that the exercise of an option results in a new physically-settled swap transaction.

| effectiveDate-Specifies the effective date of this leg of the swap. When defined in relation to a date specified somewhere else in the document (through the relativeDate component), this element will typically point to the effective date of the other leg of the swap. terminationDate-Specifies the termination date of this leg of the swap. When defined in relation to a date specified somewhere else in the document (through the relativeDate component), this element will typically point to the termination date of the other leg of the swap. commoditySwapLeg-Defines the substitutable commodity swap leg weatherLeg-A weather leg element of a Commodity Swap defines Weather Index Swap transactions. Weather Index Swap transactions are OTC derivative transactions which settle financially based on an index calculated from observations of temperature, precipitation and other weather-related measurements at weather stations throughout the world. Sub-Annex C of the 2005 ISDA Commodity Definitions provides definitions and terms for a number of types of weather indices. These indices include: HDD (heating degree days), CDD (cooling degree days), CPD (critical precipitation days). Weather Index Swap transactions result in a cash flow to one of the two counterparties each Calculation Period depending on the relationship between the Settlement Level and the Weather Index Level. A Weather Index swap transaction always consists of a commodity swap element as a parent to two weatherLeg elements.

####

15.5.2 commoditySwaption - physicalExercise

physicalExercise-The parameters for defining how the commodity option can be exercised into a physical transaction.The parameters for defining how the commodity option can be exercised into a physical transaction.

| CommodityPhysicalExercise-The parameters for defining how the physically-settled commodity option can be exercised and how it is settled. americanExercise-The parameters for defining the expiration date(s) and time(s) for an American style option. europeanExercise-The parameters for defining the expiration date(s) and time(s) for a European style option.

####

15.5.3 commoditySwaption - premium

premium-The option premium payable by the buyer to the seller.The option premium payable by the buyer to the seller.
Should the premium differ over the course of an Asian options life (e.g. because delivery is per calendar day which is reflected in the premium), a premium schedule should be specified. Note that the intention is that a premium step should be specified for each Calculation Period in the trade, regardless of whether there is a change in value between two periods. This is so as to match the premium schedule to the calculation periods as clearly as possible. The premium steps must be in chronological order (i.e the first step corresponds to the first Calculation Period, the last step to the last Calculation Period).

| CommodityPremium-The commodity option premium payable by the buyer to the seller. paymentAmount-Non negative payment amount.Non negative payment amount. premiumPerUnit - Not used in Swaptions

### 15.6 commodityForward

The commodityForward product element supports the representation of Precious and Non-Precious metal Forwards. Whilst some commodity forwards are booked as single period swaps, precious forwards are extremely basic trades and are confirmed under a different ISDA confirmation template

Even though the initial scope is limited to Precious and Non-Precious Forward, the intention of the working group is to allow support for other commodity classes should this be required.

| valueDate-Specifies the value date of the Commodity Forward Transaction. This is the day on which both the cash and the physical commodity settle.Specifies the value date of the Commodity Forward Transaction. This is the day on which both the cash and the physical commodity settle. fixedLeg-The fixed leg of a Commodity Forward Transaction. averagePriceLeg-Specifies the calculated floating price leg of a Commodity Forward Transaction. commodityForwardLeg-Defines the substitutable commodity forward leg.

####

15.6.1 commodityForward - fixedLeg

The fixed payment of the Commodity Forward product is represented using the fixedLeg element of type NonPeriodicFixedPriceLeg.

| fixedPrice-Fixed price on which fixed payments are based.Fixed price on which fixed payments are based. totalPrice-The total amount of the fixed payment for all units of the underlying commodity.The total amount of the fixed payment for all units of the underlying commodity.

####

15.6.2 commodityForward - averagePriceLeg

averagePriceLeg-Specifies the calculated floating price leg of a Commodity Forward Transaction.

| AveragePriceLeg-The average price leg of an average price commodity bullion or non-precious metal forward transaction. commodity-Identifies the underlying asset when it is a listed commodity. pricingStartDate-Defines the Start of the Pricing period. PricingStartDate is optional when discrete pricingDates are supplied and is not recommended to be included. Should they coexist, pricingStartDate is expected to be the same as the earliest pricing date or earlier for a Term deal as the discrete dates will take precedence.Defines the Start of the Pricing period. PricingStartDate is optional when discrete pricingDates are supplied and is not recommended to be included. Should they coexist, pricingStartDate is expected to be the same as the earliest pricing date or earlier for a Term deal as the discrete dates will take precedence. calculation-Captures details relevant to the calculation of the floating price.Captures details relevant to the calculation of the floating price.

The 'commodityForwardLeg' element is placeholder within commodityForward structure for the actual Precious and Non-Precious metal legs (e.g. bullionPhysicalLeg and metalPhysicalLeg).

####

15.6.3 commodityForward - bullionPhysicalLeg

The intention of the new leg is to re-use as many existing commodity components as possible to achieve a flexible implementation of a forward that will be adaptable for use with further commodity classes.

Consequently, the BullionPhysicalLeg component will be a member of a choice group such that further commodity types can be added over time.

BullionPhysicalLeg-Physically settled leg of a physically settled Bullion Transaction. |

####

15.6.4 commodityForward - metalPhysicalLeg

metalPhysicalLeg-Physically settled metal products leg.

| MetalPhysicalLeg-Physically settled leg of a physically settled Metal transaction. metal-The specification of the Metal Product to be delivered.The specification of the Metal Product to be delivered. deliveryConditions-The physical delivery arrangements and requirements for a physically settled non-precious metal transaction.The physical delivery arrangements and requirements for a physically settled non-precious metal transaction. CommodityFixedPhysicalQuantity.model-The different options for specifying a fixed physical quantity of commodity to be delivered.

##### 15.6.4.1 commodityForward - metalPhysicalLeg - metal

metal-The specification of the Metal Product to be delivered.The specification of the Metal Product to be delivered.

| material-The types of metal product for a physically settled metal trade. grade-The grade(s) of material which can be delivered in seller's option.

##### 15.6.4.2 commodityForward - metalPhysicalLeg - deliveryConditions

deliveryConditions-The physical delivery arrangements and requirements for a physically settled non-precious metal transaction.The physical delivery arrangements and requirements for a physically settled non-precious metal transaction.

| MetalDelivery-The physical delivery conditions for the transaction. deliveryLocation-The Delivery Point for a physically settled non-precious metal transaction. risk-"Risk of loss" may also be used, equivalently, on confirmation documents.

##### 15.6.4.3 commodityForward - metalPhysicalLeg - CommodityFixedPhysicalQuantity.model

CommodityFixedPhysicalQuantity.model-The different options for specifying a fixed physical quantity of commodity to be delivered.

| totalPhysicalQuantity-The Total Quantity of the commodity to be delivered.

## 16 CHANGES IN THIS VERSION

### 16.1 Changes compared to FpML 5.5 Trial Recommendation 2 - build#6

- Business Process:
- The following issues have been resolved:
  - http://www.fpml.org/issues/view.php?id=1080

View PDF for details on schema changes

View PDF for details on validation rules changes

View SCHEME DEFINITIONS for details on coding schemes changes

### 16.2 Incompatible changes compared to FpML 5.4 - build#5

- - Generic Product:
    - In Confirmation, Reporting, Recordkeeping and Transparency Views - > fpml-generic.xsd-> "GenericProduct": Removed "dayCountFraction" element. Rationale: The "dayCountFraction" element was moved to the "underlyer" component (placed within "TradeUnderlyer2").Part 43 requires reporting on both the fixed as well as floating leg for the dayCountFraction element. Part 43 requires reporting on both the fixed as well as floating leg for the dayCountFraction element. The Standards committee approved the removal with the assumption that it would not break any critical implementation.
  - CorrelationId:
    - In Confirmation, Reporting, Recordkeeping and Transparency Views - > fpml-msg.xsd - > within "CorrelationId": replaced the base class "xsd:normalizedString" with “Scheme” which restricts the "xsd:normalizedString" to maxLength value="255".
  - Commodity Derivatives:
    - Recordkeeping View –> fpml-com-xsd -> within "SettlementPeriods" complex type: the "startDate" element's status changed from "optional" to "mandatory". Rational:Fix - to prevent the submission of the "endDate" without the "startDate". The change was agreed by the Commodity WG and approved by the Standards Committee (March-11-2013)

### 16.3 Changes compared to FpML 5.4 Recommendation

- All Views (except: Pretrade View):
  - Regulatory Reporting:
    - Added several new fields, coding schemes, and examples to support ESMA regulatory reporting, including:
      - party/region field
      - partyTradeInformation/collateralPortfolio identifier field
      - partyTradeInformation/reportingRegime/exceedsClearingThreshold boolean field
      - European regulatory region coding scheme
      - enhanced the ReportingRole coding scheme
      - ESMA organization classification scheme
    - Refactored the Generic Product
      - It includes one incompatible change:
        - In fpml-generic.xsd-> "GenericProduct": Removed "dayCountFraction" element. Rationale: The "dayCountFraction" element was moved to the "underlyer" component (placed within "TradeUnderlyer2").Part 43 requires reporting on both the fixed as well as floating leg for the dayCountFraction element. Part 43 requires reporting on both the fixed as well as floating leg for the dayCountFraction element. The Standards committee approved the removal with the assumption that it would not break any critical implementation.
      - Added support for EMIR in generic product for Commodities, Equities, FX.
  - Clean-up work: Removed orphan types. External URIs corrected.

- FX:
  - Added support for a new fxFlexibleForward product
  - Refactored Fx Option Barrier and Fx Digital Option:
    - Within "FxBarrierFeature" and "FxTouch", added support the MT306 and the ISDA confirmation templates which require the specification of the "observationStartTime" and "observationEndTime for a barrier in terms of the business center and time, in addition to the observationStartDate" and "observationEndDate".
    - Within "FxBarrierFeature" and "FxTouch", added a choice between the above structure and a new element "observationPoint" of a new type "FxBusinessCenterDateTime", a collection of observationPoint elements, with individual observation times.
    - Within "FxOption" -> "FxOptionFeatures" -> "FxBarrierFeature", added a new field "direction" of a new type "FxBarrierDirectionEnum". This specifies whether the barrier direction is "Up" or "Down"; that is, that a barrier event occurs if the spot rate is at or above the trigger rate, or at or below the trigger rate during the period of observation of an american barrier, or at the times of observation of a discrete or european barrier. This change is to comply with Dodd-Frank reporting requirements.
    - Within "FxDigitalOption" -> "FxTouch", added a new field "direction" of type "TriggerConditionEnum". This specifies whether the trigger direction is "AtOrAbove" or "AtOrBelow; that is, that a barrier event occurs if the spot rate is at or above the trigger rate, or at or below the trigger rate during the period of observation of an american trigger, or at the times of observation of a discrete trigger. Note: within "TriggerConditionEnum", values "Above" and "Below" are deprecated. This change is to comply with Dodd-Frank reporting requirements.
    - Within exiting "TriggerConditionEnum" structure (used with FxDigitalOption-> "FxTrigger" and FxTouch), added new values "AtOrAbove" and "AtOrBelow", deprecated existing values "Above" and "Below".
    - Within existing "FxBarrierTypeEnum" structure (used with FxOption-> "FxBarrierFeature"), deprecated values "ReverseKnockin" and "ReverseKnockout".
    - Within "Trade" added support for "barrierDeterminationAgent" - the party referenced is specified in the related Confirmation as Barrier Determination Agent
- Equity Derivatives:
  - Additions based on the trading firms' requirements:
    - Added support for value "Both" (Both parties with joined rights to be a calculation agent) to "CalculationAgentPartyEnum".
    - Refactored "CalculationFromObservation" complex type, to support Initial Level Source in Variance and Correlation Swaps.
    - Updated several coding schemes: localJurisdictionScheme, determinationMethodScheme, instrumentIdScheme
  - Some of the previously agreed on the Standards Committee none-backward compatible changes to FpML 5-3 in Equity Transparency and Recordkeeping view have been reverted by the Standards Committee on April 08, 2013.
- Commodity Derivatives:
  - Added Support for Gold Interest Rate Swap (Official Name: Gold Forward Offered Rate) representation in FpML
  - Added support for ESMA regulatory reporting
    - Border (Gas and Electricity "deliveryConditions/interconnectionPoint").
    - Block Hours (Electricity loadType = BlackHours).
  - Clean-up work: Removed orphan types. Corrected external URIs.
- Interest Rate Derivatives:
  - In Transparency View - > foml-ird.xsd -> "SettlementProvision": added element "settlementCurrency" ofType "Currency" as a mandatory field. Rationale: Requires for regulatory reporting of Non Deliverable Currencies. The Standards committee approved the addition of the "settlementCurrency" on March 11, 2013.
  - Within "Fra": "fixedRate" element's type changed from "xsd:decimal" to "IdentifiedRate". Rationale: Fix.
  - Added support for FRA's fees and additional payments.
- Listed Derivatives Reporting:
  - Added several new components and examples to support ESMA regulatory reporting, including:
    - Added "holding" structure to position/constituent for securities position reporting.
    - Added examples of reporting securities activity and position
    - Added examples of reporting securities market data
  - Added several new components and examples to support regulatory reporting for commodities, including:
    - Added a new Exchange Traded Option asset underlyer and added an example.
    - Updated the Future underlyer and added an example.
- Business Process:
  - Added support for Equity Corporate Action and Basket Change events. Refactored Events.model
  - In Confirmation, Reporting, Recordkeeping, Transparency Views (Incompatible changes) - > fpml-msg.xsd - > within "CorrelationId": replaced the base class "xsd:normalizedString" with “Scheme” which restricts the "xsd:normalizedString" to maxLength value="255".
  - Increase and Termination events: Refactored TradeNotionalChange to correct two modeling issues. The refactoring provides a backward compatible path; a choice between the old structures (TradeNotionalChange.model) and enhanced structures (sizeChange). The sizeChange wrapper relates pairs of elements (e.g., notionalAmount/outstandingNotionalAmount). Using the new model:
    - The reporting of both change of units and change of notional amount is now possible (as required for dividend swaps, for example)
    - Linking notionals with product legs is now possible. An additional optional empty element (e.g., notionalReference) within the sizeChange wrapper links the pair of elements to a specific underlying leg reference using an @href attribute.
    - Within TradeNotionalChange, deprecated change in/outstanding notional, number of options, number of units in favor of a more flexible structure (sizeChange) that allows linking notionals with product legs as well the reporting of both change of units or change of notional amount as required for dividend swaps, for example.
  - LSOC Reporting: Enhanced the requestCollateralAllocation message with a requestedAction element which allows FCMs to specify how the allocations are to be processed (e.g., Update, Reset).
  - Added support for ESMA entity type classification (e.g. Financial, NonFinanacial)in the reportingRegime structure

## 17 SCHEMA REFERENCE

These are automatically generated reference documents detailing the contents of the various sections in the FpML schema.

- Core Definitions:
  - Main Components
  - Doc Components
  - Shared Components
  - Shared Enumeration definitions
  - Asset Components
- Products:
  - IRD
    - Interest Rate Components
  - FX
    - FX Components
  - CD
    - Credit Derivative Components
  - EQD
    - Equity Shared Components
    - Equity Derivative Options Components
    - Return Swaps Components
    - Variance Swaps Components
    - Dividend Swaps Components
    - Correlation Swaps Components
  - Bond Options
    - Bond Options Components
  - Options
    - Options Shared Components
  - Commodities
    - Commodity Derivative Components
  - Cross-Asset Products
    - Standard Product Components (standardProduct-Standard products - for use in Transparency reporting to define a product that represents a standardized OTC derivative transaction whose economics do not need to be fully described using an FpML schema because they are implied by the product ID. In other views, standard products are present for convenience to support internal messaging and workflows that are cross-product. Standard products are not full trade representations as such they are not intended to be used for confirming trades.
      )
    - Generic Product Components (genericProduct-Generic products - for use in Transparency reporting to define a product that represents an OTC derivative transaction whose economics are not fully described using an FpML schema. In other views, generic products are present for convenience to support internal messaging and workflows that are cross-product. Generic products are not full trade representations as such they are not intended to be used for confirming trades.
      )
- Messaging Framework:
  - Messaging Components
  - Trade and Post-Trade Messaging Components
  - Business Event Notification Components
- Reference:
  - Index and cross-reference of definitions
  - Schema and Example files - Provides zip file with FpML schemas and examples.

## 18 SCHEMA AND EXAMPLES

- Description of Examples - Provides list and description of available FpML examples. All examples can be downloaded clicking the link below.

- Schema and Example files - Provides zip file with FpML Schema and all examples.

## 19 SCHEME DEFINITIONS

- Scheme Definitions - Describes standard FpML schemes, and the values that they can take.
- Coding Schemes (.zip file) - Package of internal FpML defined internal schemes defined as xml files.