FpML® Financial product Markup Language Last Call Working Draft 2 May 2014 (Reporting View)

Version: 5.7

This version: http://www.fpml.org/spec/fpml-5-7-3-lcwd-1

Latest version: http://www.fpml.org/spec/fpml-5-7-3-lcwd-1

Previous version: http://www.fpml.org/spec/fpml-5-7-2-wd-2/

Errata for this version: http://www.fpml.org/spec/fpml-5-7-3-lcwd-1/html/reporting/fpml-5-7-errata.html

Build Number: 3; Document built: Wed 04/23/2014 0:55:13.71

Copyright (c) 1999 - 2014 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
        1.2 ORGANIZATION OF THE DOCUMENTATION
             1.2.1 Schema Reference
             1.2.2 Other Documents in the Specification
             1.2.3 Diagram Notation
        1.3 WORKING GROUP MEMBERS AND ACKNOWLEDGEMENTS
             1.3.1 Architecture Working Group
             1.3.2 Business Process Working Group
             1.3.3 Regulatory Reporting Working Group
             1.3.4 Validation Working Group
             1.3.5 IRD Products Working Group
             1.3.6 Credit Derivatives Working Group
             1.3.7 FX Working Group
             1.3.8 Equity Derivatives Working Group
             1.3.9 Commodity Derivatives Working Group
             1.3.10 Pricing and Risk Working Group
             1.3.11 Collateral Working Group
        1.4 FpML INTRODUCTION
        1.5 REQUESTED FEEDBACK
             1.5.1 Providing Feedback
        1.6 CHANGES IN THIS VERSION
             1.6.1 Changes compared to FpML 5.7 Second Working Draft (build#2)
             1.6.2 Changes compared to FpML 5.6 Recommendation (build#5)
             1.6.3 Incompatible changes compared to FpML 5.6 (build#5)
        1.7 SCOPE
             1.7.1 Architecture Framework
             1.7.2 Business Process Scope
                 1.7.2.1 Generic processes:
                 1.7.2.1.1 Reporting
             1.7.3 Validation Scope
             1.7.4 IRD Scope
             1.7.5 Credit Derivatives Scope
             1.7.6 FX Scope
             1.7.7 Equity Derivative Options and Forwards Scope
             1.7.8 Return Swaps Scope
             1.7.9 Correlation Derivatives Scope
             1.7.10 Variance Derivatives Scope
             1.7.11 Dividend Derivatives Scope
             1.7.12 Commodity Derivative Product Scope
             1.7.13 Pricing and Risk Scope
        1.8 CHARACTER ENCODING AND CHARACTER REPERTOIRE
             1.8.1 Character Encoding
             1.8.2 Character Repertoire
        1.9 TOOLS AND VALIDATION
             1.9.1 Schema and Example Validation
    2 FpML OVERVIEW
        2.1 FpML
        2.2 Overview of FpML views
        2.3 Overview of the organization of the master schema
        2.4 Overview of Document Types
        2.5 Using FpML
        2.6 The FpML root element
        2.7 Annotations
             2.7.1 eCore
        2.8 Main Components
             2.8.1 The DataDocument type
             2.8.2 The Trade Component
                 2.8.2.1 tradeHeader
                 2.8.2.1.1 Primary Trade Identifier
                 2.8.2.1.2 Party Trade Information
                 2.8.2.2 product
                 2.8.2.2.1 Product Identification
                 2.8.2.3 otherPartyPayment
                 2.8.2.4 brokerPartyReference
                 2.8.2.5 calculationAgent
                 2.8.2.6 documentation
                 2.8.2.6.1 contractualMatrix
                 2.8.2.6.1.1 Examples of using the contractualMatrix structure
                 2.8.2.6.2 Attachment
                 2.8.2.7 collateral
                 2.8.2.7.1 independentAmount
                 2.8.2.8 governingLaw
             2.8.3 The Portfolio Component
             2.8.4 The Party Component
             2.8.5 The Account Component
             2.8.6 The Product Component
             2.8.7 The Strategy Component
        2.9 More Background on FpML's Design
             2.9.1 Rationale for Structured Approach
             2.9.2 Component Framework
             2.9.3 Coding Schemes
    3 BUSINESS PROCESS ARCHITECTURE
        3.1 Introduction
             3.1.1 Why Business Messaging?
        3.2 The Messaging Framework
             3.2.1 Introduction
             3.2.2 Issues in FpML 4 Messaging Framework
             3.2.3 Design Assumptions
                 3.2.3.1 Highly Assured Transport
                 3.2.3.2 No Preservation of Message Sequence
                 3.2.3.3 Long-Running Processes
                 3.2.3.4 Observable Completion
                 3.2.3.5 Consistent Message Correlation
                 3.2.3.6 Consistent Error Reporting
                 3.2.3.7 Consistent correction and retraction mechanism
                 3.2.3.8 Consistent Processes Across Trades and Post-trade Events
                 3.2.3.9 Transport Characteristics
                 3.2.3.9.1 Purpose
                 3.2.3.9.2 Layers
                 3.2.3.9.3 Reliable Mode
                 3.2.3.9.4 Bulk Transfer Mode
             3.2.4 Transport Independence
                 3.2.4.1 Business Process
                 3.2.4.2 Document
                 3.2.4.3 Messaging
                 3.2.4.4 Transport
             3.2.5 Identification of Purpose
                 3.2.5.1 By Namespace (not used by FpML)
                 3.2.5.2 By Element Name (used by FpML 5.x)
                 3.2.5.3 By Element Type (used by FpML 4.x)
             3.2.6 General Pattern of Messages
             3.2.7 Naming Conventions
             3.2.8 Acknowledgements
             3.2.9 Message correlation
             3.2.10 Message sequencing
             3.2.11 Correlation ID optionality
             3.2.12 Other topics
                 3.2.12.1 onBehalfOf
                 3.2.12.2 party roles
                 3.2.12.3 separation of party and account
        3.3 Regulatory Reporting Processes
        3.4 Business Processes
             3.4.1 FpML 5 Business Processes
             3.4.2 Transaction life cycle
             3.4.3 Overall Messaging Flows
             3.4.4 Generic (Multi-Event) Flows
             3.4.5 Trade Approval (Credit Approval Token)
             3.4.6 Reporting Business Processes
                 3.4.6.1 Overview
                 3.4.6.1.1 Purpose
                 3.4.6.1.2 Reporting View
                 3.4.6.1.3 Field Lists
                 3.4.6.1.4 Generic Product
                 3.4.6.2 Description of the Processes
                 3.4.6.2.1 Position and Activity Reporting
                 3.4.6.2.1.1 Position Report
                 3.4.6.2.1.2 Position Activity Report
                 3.4.6.2.1.3 Event Activity Report
                 3.4.6.2.2 Securities Reporting
                 3.4.6.2.3 Reset Reporting
                 3.4.6.2.4 Exposure Reporting
                 3.4.6.2.5 Cashflow Matching
                 3.4.6.2.5.1 Model Overview
                 3.4.6.2.5.2 Design Principles
                 3.4.6.2.5.3 Cashflows within a trade
                 3.4.6.2.5.3.1 tradeCashflowsAsserted
                 3.4.6.2.5.3.2 tradeCashflowsMatchResult
                 3.4.6.2.5.3.3 cancelTradeCashflows
                 3.4.6.2.5.4 Cashflows across multiple trades
                 3.4.6.2.5.5 Reference Data
                 3.4.6.2.5.6 Usage Guidelines
                 3.4.6.2.5.6.1 Trade Identification
                 3.4.6.2.5.6.2 Payment
                 3.4.6.2.5.6.3 Calculation Details
                 3.4.6.2.6 Portfolio Reconciliation
                 3.4.6.2.6.1 Introduction
                 3.4.6.2.6.2 Model Overview
                 3.4.6.2.6.2.1 Bilateral vs. Trilateral
                 3.4.6.2.6.2.2 Batch (a.k.a Snapshot) vs. Incremental
                 3.4.6.2.6.2.3 Fixed time vs. Real-time
                 3.4.6.2.6.2.4 Level of detail
                 3.4.6.2.6.2.5 Product Scope
                 3.4.6.2.6.3 Design Principles
                 3.4.6.2.6.3.1 Product Representation
                 3.4.6.2.6.3.2 Design approach
                 3.4.6.2.6.4 Messaging and Schema Structure
                 3.4.6.2.6.4.1 PositionsAsserted
                 3.4.6.2.6.4.2 PositionsAcknowledged
                 3.4.6.2.6.4.3 PositionsMatchResults
                 3.4.6.2.6.5 Usage Guidelines
                 3.4.6.2.6.5.1 Trilateral vs. Bilateral
                 3.4.6.2.6.5.2 Incremental vs. Snapshot
                 3.4.6.2.6.5.3 Reference Data
                 3.4.6.2.6.5.4 Position Differences
                 3.4.6.2.6.6 Examples
                 3.4.6.2.7 Valuation Reporting
             3.4.7 Service Notification
    4 VALIDATION ARCHITECTURE
        4.1 Validation Rules
        4.2 Reference Implementations
             4.2.1 Java and C#
             4.2.2 Java/XPath
             4.2.3 CLiX
        4.3 Test Cases
        4.4 Target Audience
        4.5 Background
        4.6 Rule Specifications
             4.6.1 General Principles and Guidelines
             4.6.2 Mathematical Notation
             4.6.3 Rule Definition and Layout
             4.6.4 Defining New Terms as Functions
                 4.6.4.1 How to use functions?
             4.6.5 Formatting
        4.7 Technical Guidelines
             4.7.1 Implementations
             4.7.2 Evaluation of Dates
             4.7.3 Contains
        4.8 Revision and Publication Process
        4.9 Normativity and its Implications
    6 CROSS-ASSET PRODUCT ARCHITECTURE
        6.1 Cross-Asset Products Scope
        6.2 Overall Architecture
        6.3 The Strategy Component
        6.4 The InstrumentTrade Details Component
        6.5 genericProduct
        6.6 standardProduct
    7 INTEREST RATE DERIVATIVE PRODUCT ARCHITECTURE
        7.1 Interest Rate Swap
             7.1.1 Relative Swap
             7.1.2 Non-Deliverable Settlement Provision
        7.2 Asset Swap
             7.2.1 Implementation
             7.2.2 Design Rationale
        7.3 Inflation Swap
             7.3.1 Design Approach
             7.3.2 Implementation
                 7.3.2.1 Inflation Terms
        7.4 Forward Rate Agreement
        7.5 Option Components
             7.5.1 European Exercise
             7.5.2 American Exercise
             7.5.3 Bermuda Exercise
             7.5.4 Early Termination Provision
             7.5.5 Cancelable Provision
             7.5.6 Extendible Provision
             7.5.7 Swaption
             7.5.8 Cap / Floor
        7.6 Cash Settlement
    8 CREDIT DERIVATIVE PRODUCT ARCHITECTURE
        8.1 Introduction
             8.1.1 credit default swap
             8.1.2 credit default swap index
             8.1.3 credit default swap basket
             8.1.4 mortgage credit default swap
                 8.1.4.1 Main differences between Mortgage and Corporate CDS
                 8.1.4.2 The Pay-As-You-Go model
             8.1.5 loan credit default swap
             8.1.6 credit default swap option
        8.2 creditDefaultSwap
        8.3 generalTerms
             8.3.1 referenceObligation
                 8.3.1.1 bond and convertibleBond
                 8.3.1.2 mortgage
                 8.3.1.3 loan
             8.3.2 referenceInformation
             8.3.3 indexReferenceInformation
                 8.3.3.1 Index Tranche
                 8.3.3.2 Settled Entity Matrix
             8.3.4 basketReferenceInformation
                 8.3.4.1 Basket Tranche and Nth to Default
        8.4 feeLeg
             8.4.1 Credit default swap
             8.4.2 Credit default swap index
             8.4.3 Mortgage derivatives
        8.5 protectionTerms
             8.5.1 Mortgage derivatives
        8.6 physicalSettlementTerms and cashSettlementTerms
        8.7 creditDefaultSwapOption
             8.7.1 Option Components
                 8.7.1.1 OptionBase
                 8.7.1.2 OptionBaseExtended
                 8.7.1.2.1 Premium
        8.8 Credit Event Notice
             8.8.1 Background
             8.8.2 Implementation
                 8.8.2.1 Description of some of the elements
                 8.8.2.2 Examples
        8.9 Appendix A: Naming differences between FpML 5.7 Credit Derivatives Subschema and 2003 ISDA Credit Derivatives Definitions
    10 FX PRODUCT ARCHITECTURE
        10.1 FX Scope
        10.2 Foreign Exchange Spot and Forward
             10.2.1 Exchanged Currency
                 10.2.1.1 Settlement Information
                 10.2.1.1.1 Settlement Instruction
                 10.2.1.1.1.1 Correspondent Information
                 10.2.1.1.1.2 Intermediary Information
                 10.2.1.1.1.3 Beneficiary Information
                 10.2.1.1.1.4 Beneficiary Bank
                 10.2.1.1.1.5 Split Settlement
             10.2.2 Exchange Rate
             10.2.3 Non Deliverable Settlement
             10.2.4 Disruption Events
        10.3 Foreign Exchange Flexible Forward
             10.3.1 FxFlexibleForward->executionPeriodDates
             10.3.2 FxFlexibleForward->forwardRate
        10.4 Foreign Exchange Swap
             10.4.1 FX Swap Leg
        10.5 Foreign Exchange Option
             10.5.1 FX Option Exercise
                 10.5.1.1 American Exercise
                 10.5.1.2 European Exercise
             10.5.2 FX Features
                 10.5.2.1 Fx Barrier Feature
                 10.5.2.2 Fx Asian Feature
             10.5.3 Premium
             10.5.4 Cash Settlement
        10.6 Foreign Exchange Binary and Digital Options
             10.6.1 Option Style
                 10.6.1.1 American Exercise and American Barrier/ Discrete Barrier
                 10.6.1.1.1 American Exercise
                 10.6.1.1.2 American Barrier/ Discrete Barrier
                 10.6.1.2 European Exercise and European Barrier
                 10.6.1.2.1 European Exercise
                 10.6.1.2.2 European Barrier
             10.6.2 Fx Option Payout
                 10.6.2.1 Fx Option Payout Style
        10.7 Term Deposit
             10.7.1 Term Deposit Features
        10.8 Trade Strategies
    12 EQUITY DERIVATIVE OPTIONS PRODUCT ARCHITECTURE
        12.1 Equity Derivative Options and Forwards Scope
        12.2 Overall Architecture
             12.2.1 brokerEquityOption
             12.2.2 equityForward
             12.2.3 equityOption
             12.2.4 equityOptionTransactionSupplement
        12.3 Component Descriptions
             12.3.1 Underlyer
             12.3.2 Equity Exercise
                 12.3.2.1 European Exercise
                 12.3.2.2 American Exercise
                 12.3.2.3 Bermuda Exercise
             12.3.3 Features
                 12.3.3.1 Equity Option Feature
                 12.3.3.1.1 asian
                 12.3.3.1.2 Barrier and Knock
                 12.3.3.1.3 Pass Through
                 12.3.3.1.3.1 Alternate Approaches
                 12.3.3.1.4 Dividend Adjustment
                 12.3.3.2 Fx Feature
                 12.3.3.3 Strategy Feature
             12.3.4 Equity Premium
             12.3.5 Adjustment of dates in Equity Options
    14 RETURN SWAPS PRODUCT ARCHITECTURE
        14.1 Return Swaps Scope
        14.2 Introduction
             14.2.1 The structure of the generic Return Swap
             14.2.2 Equity Swap Transaction Supplement
        14.3 Component Descriptions
             14.3.1 The return leg
                 14.3.1.1 The payer and receiver party
                 14.3.1.2 The effective date and the termination date
                 14.3.1.3 The underlyer
                 14.3.1.3.1 The equity:
                 14.3.1.3.2 The index:
                 14.3.1.3.3 The mutual fund:
                 14.3.1.3.4 The exchange-traded fund:
                 14.3.1.3.5 The future contract:
                 14.3.1.3.6 The convertible bond:
                 14.3.1.3.7 The commodity:
                 14.3.1.4 The valuation
                 14.3.1.5 The notional amount
                 14.3.1.6 The amount
                 14.3.1.7 The return
                 14.3.1.8 The notional adjustment
                 14.3.1.9 The FX Feature (old FX terms)
             14.3.2 The interest leg
                 14.3.2.1 The payer and receiver party
                 14.3.2.2 The calculation dates
                 14.3.2.3 The notional amount
                 14.3.2.4 The interest amount
                 14.3.2.5 The interest calculation
             14.3.3 The initial and final stub
             14.3.4 The principal exchange
             14.3.5 The additional payments when involving the principal parties to the trade
             14.3.6 The optional early termination
    16 VARIANCE PRODUCT ARCHITECTURE
        16.1 Variance Derivatives Scope
        16.2 Overall Architecture
             16.2.1 varianceSwap
             16.2.2 varianceSwapTransactionSupplement
             16.2.3 VarianceLeg
             16.2.4 varianceOptionTransactionSupplement
    18 DIVIDEND PRODUCT ARCHITECTURE
        18.1 Dividend Derivatives Scope
        18.2 Overall Architecture
             18.2.1 dividendSwapTransactionSupplement
             18.2.2 dividendLeg
             18.2.3 fixedLeg
    20 CORRELATION PRODUCT ARCHITECTURE
        20.1 Correlation Derivatives Scope
        20.2 Overall Architecture
             20.2.1 correlationSwap
             20.2.2 correlationLeg
    22 BOND OPTIONS PRODUCT ARCHITECTURE
        22.1 Introduction
             22.1.1 bondOption
        22.2 Shared Option Components
             22.2.1 OptionBase
             22.2.2 OptionBaseExtended
                 22.2.2.1 Premium
                 22.2.2.2 Exercise
                 22.2.2.3 The ExerciseProcedure construct
                 22.2.2.4 The Notional construct
                 22.2.2.5 The Denomination construct
        22.3 The Option on Bond and Convertible Bond
             22.3.1 The strike
             22.3.2 The convertible bond underlyer
    25 COMMODITY DERIVATIVE PRODUCT ARCHITECTURE
        25.1 Introduction
        25.2 Commodity Underlyer
             25.2.1 Commodity Underlyer -> Commodity Single Underlyer
             25.2.2 Commodity Underlyer -> Commodity Basket Underlyer
                 25.2.2.1 Commodity Underlyer -> Commodity Basket Underlyer - BasketIdentifier.model
                 25.2.2.2 Commodity Underlyer -> Commodity Basket Underlyer - CommodityBasket.model
        25.3 commoditySwap
             25.3.1 commoditySwap - CommodityContent
             25.3.2 fixedLeg
             25.3.3 floatingLeg
                 25.3.3.1 calculation
                 25.3.3.1.1 pricingDates
                 25.3.3.1.2 fx
             25.3.4 weatherLeg
                 25.3.4.1 weatherLeg - WeatherIndex
                 25.3.4.2 weatherLeg - WeatherCalculationPeriod
                 25.3.4.3 weatherLeg - weatherNotionalAmount
                 25.3.4.4 weatherLeg - calculation
                 25.3.4.5 weatherLeg - paymentDates
                 25.3.4.6 weatherLeg - weatherIndexData
             25.3.5 Physical Leg
                 25.3.5.1 Coverage
                 25.3.5.2 Product Representation
                 25.3.5.2.1 Gas Physical Leg
                 25.3.5.2.1.1 gasPhysicalLeg - deliveryPeriods
                 25.3.5.2.1.2 gasPhysicalLeg - product
                 25.3.5.2.1.3 gasPhysicalLeg - deliveryConditions
                 25.3.5.2.1.4 gasPhysicalLeg - deliveryQuantity
                 25.3.5.2.2 Oil Physical Leg
                 25.3.5.2.2.1 oilPhysicalLeg - deliveryPeriods
                 25.3.5.2.2.2 oilPhysicalLeg - product
                 25.3.5.2.2.3 oilPhysicalLeg - deliveryConditions
                 25.3.5.2.2.4 oilPhysicalLeg - deliveryQuantity
                 25.3.5.2.3 Electricity Physical Leg
                 25.3.5.2.3.1 electricityPhysicalLeg - deliveryPeriods
                 25.3.5.2.3.2 electricityPhysicalLeg - product
                 25.3.5.2.3.3 electricityPhysicalLeg - deliveryConditions
                 25.3.5.2.3.4 electricityPhysicalLeg - deliveryQuantity
                 25.3.5.2.4 Coal Physical Leg
                 25.3.5.2.4.1 coalPhysicalLeg - deliveryPeriods
                 25.3.5.2.4.2 coalPhysicalLeg - product
                 25.3.5.2.4.3 coalPhysicalLeg - deliveryConditions
                 25.3.5.2.4.4 coalPhysicalLeg - deliveryQuantity
                 25.3.5.2.5 Environmental Physical Leg
                 25.3.5.2.5.1 environmentalPhysicalLeg - numberOfAllowances
                 25.3.5.2.5.2 environmentalPhysicalLeg - product
                 25.3.5.2.5.3 environmentalPhysicalLeg - abandonmentOfScheme
                 25.3.5.2.5.4 environmentalPhysicalLeg - deliveryDate
                 25.3.5.2.5.5 environmentalPhysicalLeg - paymentDate and businessCenters
                 25.3.5.2.5.6 environmentalPhysicalLeg - failureToDeliverApplicable
                 25.3.5.2.5.7 environmentalPhysicalLeg - EEPParameters
        25.4 commodityForward
             25.4.1 commodityForward - fixedLeg
             25.4.2 commodityForward - averagePriceLeg
             25.4.3 commodityForward - bullionPhysicalLeg
             25.4.4 commodityForward - metalPhysicalLeg
                 25.4.4.1 commodityForward - metalPhysicalLeg - metal
                 25.4.4.2 commodityForward - metalPhysicalLeg - deliveryPeriods
                 25.4.4.3 commodityForward - metalPhysicalLeg - deliveryConditions
                 25.4.4.4 commodityForward - metalPhysicalLeg - CommodityFixedPhysicalQuantity.model
        25.5 commodityOption
             25.5.1 commodityOption - CommodityFinancialOption
                 25.5.1.1 commodityOption - CommodityFinancialOption - CommodityOptionFeatures
                 25.5.1.1.1 commodityOption - CommodityFinancialOption - CommodityOptionFeatures - CommodityAsian
                 25.5.1.1.2 commodityOption - CommodityFinancialOption - CommodityOptionFeatures - CommodityBarrier
                 25.5.1.1.2.1 commodityOption - CommodityFinancialOption - CommodityOptionFeatures - CommodityBarrier - trigger
                 25.5.1.1.2.2 commodityOption - - CommodityFinancialOption - CommodityOptionFeatures - CommodityBarrier - Feature Payment Amount
                 25.5.1.2 commodityOption - CommodityFinancialOption - CommodityNotionalQuantity
                 25.5.1.3 commodityOption - CommodityFinancialOption - CommodityExercise
                 25.5.1.3.1 CommodityAmericanExercise
                 25.5.1.3.2 CommodityEuropeanExercise
             25.5.2 commodityOption - CommodityWeatherOption
                 25.5.2.1 commodityOption - CommodityWeatherOption - WeatherCalculationPeriod
                 25.5.2.1.1 WeatherCalculationPeriods
                 25.5.2.2 commodityOption - CommodityWeatherOption - weatherNotionalAmount
                 25.5.2.3 commodityOption - CommodityWeatherOption - exercise
                 25.5.2.3.1 paymentDates
                 25.5.2.4 commodityOption - CommodityWeatherOption - weatherIndexStrikeLevel
                 25.5.2.5 commodityOption - CommodityWeatherOption - calculation
                 25.5.2.6 commodityOption - CommodityWeatherOption - weatherIndexData
                 25.5.2.6.1 WeatherStation
             25.5.3 commodityOption - CommodityPhysicalOption
        25.6 commoditySwaption
             25.6.1 commoditySwaption - CommoditySwapDetails
             25.6.2 commoditySwaption - physicalExercise
             25.6.3 commoditySwaption - premium
             25.6.4 commoditySwaption - CommodityContent
        25.7 commodityBasketOption
             25.7.1 commodityBasketOption - CommodityBasketOptionFeatures.model
             25.7.2 commodityBasketOption - notionalQuantityBasket
             25.7.3 commodityBasketOption - notionalAmountBasket
             25.7.4 commodityBasketOption - CommodityStrikePrice.model
             25.7.5 commodityBasketOption - CommodityFloatingStrikePrice.model
             25.7.6 commodityBasketOption - Exercise
             25.7.7 commodityBasketOption - Premium
             25.7.8 commodityBasketOption - CommodityContent.model
        25.8 commodityDigitalOption
             25.8.1 commodityDigitalOption - CommodityDigitalOptionFeatures.model
                 25.8.1.1 commodityDigitalOption - CommodityDigitalOptionFeatures.model - digital
                 25.8.1.1.1 commodityDigitalOption - CommodityDigitalOptionFeatures.model - Digital - Commodity Trigger
                 25.8.1.1.2 commodityDigitalOption - CommodityDigitalOptionFeatures.model - Digital - Feature Payment Amount
             25.8.2 commodityDigitalOption - Exercise
             25.8.3 commodityDigitalOption - Premium
             25.8.4 commodityDigitalOption - CommodityContent.model
        25.9 commodityPerformanceSwap
             25.9.1 commodityPerformanceSwap - commodityReturnLeg
                 25.9.1.1 commodityPerformanceSwap - commodityReturnLeg - CommodityCalculationPeriods.model
                 25.9.1.2 commodityPerformanceSwap - commodityReturnLeg - CommodityPaymentDates.model
                 25.9.1.3 commodityPerformanceSwap - commodityReturnLeg - CommodityUnderlyerChoice.model
                 25.9.1.4 commodityPerformanceSwap - commodityReturnLeg - notionalAmount
                 25.9.1.5 commodityPerformanceSwap - commodityReturnLeg - returnCalculation
             25.9.2 commodityPerformanceSwap - commodityInterestLeg
                 25.9.2.1 commodityPerformanceSwap - commodityInterestLeg - interestCalculation
             25.9.3 commodityPerformanceSwap - commodityVarianceLeg
                 25.9.3.1 commodityPerformanceSwap - commodityVarianceLeg - varianceCalculation
    26 PRICING AND RISK ARCHITECTURE
        26.1 Introduction
        26.2 Derivatives Pricing and Risk
             26.2.1 Pricing
             26.2.2 Valuation and Risk Reporting
        26.3 Pricing and Risk Scope
        26.4 Requirements
             26.4.1 Introduction
             26.4.2 Usage Scenarios
             26.4.3 Product Coverage
             26.4.4 Valuation and Risk Measures
             26.4.5 Market and Pricing Data
             26.4.6 Valuation Scenarios
             26.4.7 Portfolios
        26.5 Overview of design
             26.5.1 Overview
             26.5.2 Shared Types
                 26.5.2.1 Introduction
                 26.5.2.2 Quotation Characteristics
                 26.5.2.3 Measure Types
                 26.5.2.4 BasicQuotations
                 26.5.2.5 Valuation
                 26.5.2.6 Basic Asset Valuation
             26.5.3 Valuation Sets and related definitions
                 26.5.3.1 Quotation
                 26.5.3.2 Asset Valuation
                 26.5.3.3 Sensitivity Set
                 26.5.3.4 Sensitivity
                 26.5.3.5 Valuation Set
                 26.5.3.6 Valuation Scenario
                 26.5.3.7 Summary
             26.5.4 Pricing Inputs
                 26.5.4.1 Overview
                 26.5.4.2 Abstract Structures
                 26.5.4.3 Term Points and Curves
                 26.5.4.4 Underlying Assets
                 26.5.4.5 Quoted Asset Sets
                 26.5.4.6 Yield Curves
                 26.5.4.6.1 Yield Curve
                 26.5.4.6.2 Yield Curve Valuation
                 26.5.4.6.3 Zero Rate Curve
                 26.5.4.6.4 Forward Rate Curve
                 26.5.4.7 FX Forward Curves
                 26.5.4.8 Credit Curves
                 26.5.4.9 Multi-dimensional Pricing Data
                 26.5.4.10 Markets
             26.5.5 Risk Definition
                 26.5.5.1 Overview
                 26.5.5.2 Sensitivity Set Definitions
                 26.5.5.3 Sensitivity Definitions
                 26.5.5.3.1 Pricing Parameter Derivative
                 26.5.5.3.2 Derivative Formula
                 26.5.5.4 Valuation Scenario
                 26.5.5.4.1 Pricing Parameter Shift
             26.5.6 Query Portfolio
             26.5.7 Valuation Messaging
                 26.5.7.1 Introduction
                 26.5.7.2 Messaging Guidelines for 'Valuation Report' and 'Position Report'
                 26.5.7.3 TradeValuationItem
                 26.5.7.4 PortfolioValuationItem
                 26.5.7.5 RequestValuationReport
                 26.5.7.6 ValuationReport
                 26.5.7.7 PositionReport
                 26.5.7.7.1 Position
        26.6 Use Cases/Examples
        26.7 Glossary
             26.7.1 Valuation
             26.7.2 Risk
             26.7.3 Valuation Measure
             26.7.4 Risk Measure
             26.7.5 Market Environment
             26.7.6 Market Data
             26.7.7 Market Data Value
             26.7.8 Pricing Data
             26.7.9 Portfolio
             26.7.10 Scenario
             26.7.11 Sensitivity
             26.7.12 Shock
        26.8 Validation Rules
             26.8.1 Introduction
             26.8.2 Reference Integrity
             26.8.3 Date uniqueness
             26.8.4 Optionality
             26.8.5 Names/Definitions
             26.8.6 Consistency of definitions/references
        26.9 Appendix: Design Decisions
             26.9.1 Abstract vs. Actual Products
                 26.9.1.1 Issue 1: Defining an abstract product
                 26.9.1.2 Issue 2: Use of tenors instead of absolute dates
                 26.9.1.3 Issue 3: Stub definitions
             26.9.2 Product and Trade Identification and Description
                 26.9.2.1 Issue 1: Trade Summaries
                 26.9.2.2 Options:
                 26.9.2.3 Solution:
                 26.9.2.4 Rationale:
                 26.9.2.5 Issue 2: Trade Identification
                 26.9.2.6 Options:
                 26.9.2.7 Solution:
                 26.9.2.8 Rationale:
             26.9.3 Pricing Inputs
                 26.9.3.1 Issue 1: Term Representation
                 26.9.3.2 Options
                 26.9.3.3 Solution:
                 26.9.3.4 Rationale:
                 26.9.3.5 Issue 2: Ability to handle different dimensionality for pricing inputs
                 26.9.3.6 Options:
                 26.9.3.7 Solution:
                 26.9.3.8 Rationale:
                 26.9.3.9 Issue 3: Dates used within pricing structures
                 26.9.3.10 Solution:
                 26.9.3.11 Rationale:
                 26.9.3.12 Issue 4: Compactness of term structure indexes
                 26.9.3.13 Options:
                 26.9.3.14 Solution:
                 26.9.3.15 Rationale:
                 26.9.3.16 Issue 6: Handling of currency conversion
                 26.9.3.17 Solution:
                 26.9.3.18 Rationale:
                 26.9.3.19 Issue 7: Handling of credit default swap basis conventions
                 26.9.3.20 Option 1: partial description
                 26.9.3.21 Option 2: full description:
                 26.9.3.22 Option 3: fpml CD 4.x specification:
                 26.9.3.23 Solution:
                 26.9.3.24 Rationale:
             26.9.4 Valuation Reporting
                 26.9.4.1 Issue 1: How much detail is needed for the NPVs?
                 26.9.4.2 Options:
                 26.9.4.3 Solution:
                 26.9.4.4 Rationale:
                 26.9.4.5 Issue 2: Reporting Currency
             26.9.5 Risk Types and Measures
                 26.9.5.1 Issue 1: Risk types and measures
                 26.9.5.2 Solution
                 26.9.5.3 Solution
                 26.9.5.4 Issue2: Shift size
                 26.9.5.5 Solution
                 26.9.5.6 Issue 3 Shift method
                 26.9.5.7 Solution
                 26.9.5.8 Issue 4 Risk currency
                 26.9.5.9 Solution
    27 COLLATERAL MANAGEMENT ARCHITECTURE
        27.1 Collateral Management Scope
        27.2 Availaible in Reporting View
        27.3 Introduction
        27.4 Collateral Concepts
             27.4.1 Use Messaging as an Enabling Technology
             27.4.2 Support Real World Customer and Collateral System Needs
             27.4.3 Unambiguous Messages
             27.4.4 Variation Margin and Segregated Independent Amount
             27.4.5 Margin Call Status
             27.4.6 Support Full Disclosure for Effective Risk Mitigation
             27.4.7 Separation of Collateral Proposal from Margin Call Response
             27.4.8 Counter Proposal
             27.4.9 Expected Collateral
             27.4.10 Dispute Messages
             27.4.11 Retraction, Acknowledgement and Exception Messages
        27.5 Margin Call Process
             27.5.1 Mapping Table of ISDA Collateral Committee Messages to FpML Collateral Working Group Messages
             27.5.2 Proposed FpML Workflow
             27.5.3 FpML Margin Call Messages
                 27.5.3.1 Margin Call Request (MC1) - requestMargin
                 27.5.3.2 Rescind Margin Call (MC2) - requestMarginRetracted
                 27.5.3.2.1 Message Correlation
                 27.5.3.3 Margin Call Response (MC3b/MC5/MC6) - marginCallStatus
                 27.5.3.4 Rescind Margin Call Response (MC4) - MarginCallStatusRetracted
                 27.5.3.5 Collateral Proposal (MC3c) - requestCollateralAcceptance
                 27.5.3.5.1 Assets
                 27.5.3.6 Collateral Proposal Response (MC7/MC8) - collateralProposalStatus
                 27.5.3.7 Acknowledge Dispute (MC11) - disputeNotification
        27.6 Collateral Substitution Process
             27.6.1 Mapping Table of ISDA Collateral Committee Messages to FpML Collateral Working Group Messages
             27.6.2 Proposed FpML Workflow
             27.6.3 FpML Collateral Substitution Messages
                 27.6.3.1 Request Substitution (CS1) - requestSubstitution
                 27.6.3.2 Collateral Substitution Response: Agree (CS2) / Reject (CS5) - substitutionStatus
                 27.6.3.3 Confirm Substitution (CS3) - substituteConfirmationStatus
                 27.6.3.4 Confirm Collateral Return (CS4) - returnConfirmationStatus
        27.7 Interest Payment Process
             27.7.1 Mapping Table of ISDA Collateral Committee Messages to FpML Collateral Working Group Messages
             27.7.2 Proposed FpML Workflow
             27.7.3 FpML Interest Messages
                 27.7.3.1 Send Interest Notification (IN1) - requestInterest
                 27.7.3.1.1 Single Direction (singleDirection)
                 27.7.3.1.2 Both Directions (bothDirections)
                 27.7.3.1.3 Interest Calculation Details (interestCalculationDetails)
                 27.7.3.2 Response to Interest Notification / Accept (IN2) - Reject Value Date (IN3) - Dispute Interest (IN5) - interestStatus
                 27.7.3.3 Amend Value Date Convention (IN4) - requestInterest
                 27.7.3.4 Interest Statement - interestStatement
    29 CHANGES IN THIS VERSION
        29.1 Changes compared to FpML 5.7 Second Working Draft (build#2)
        29.2 Changes compared to FpML 5.6 Recommendation (build#5)
        29.3 Incompatible changes compared to FpML 5.6 (build#5)
    30 SCHEMA REFERENCE
    31 SCHEMA AND EXAMPLES
    32 SCHEME DEFINITIONS

1 INTRODUCTION AND OVERVIEW

1.1 STATUS OF THIS DOCUMENT

This is the FpML 5.7 Last Call Working Draft 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.7 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
    • Strategy Product (strategy-A strategy product.
      )
    • InstrumentTradeDetails Product (instrumentTradeDetails-A type to hold trades of multiply-traded instruments. Typically this will be used to represent the trade resulting from a physically-settled OTC product where the underlying is a security, for example the exercise of a physically-settled option.
      )
    • 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
  • Credit Event Notification Components
  • Business Event Notification Components
  • Cash Flow Matching and Portfolio Reconciliation Components
  • Collateral Messaging Components
  • Reporting Messaging Components
  • Pricing and Risk:
    • Valuation Result Sets and Related Components
    • Market Environment Data Components
    • Valuation and Sensitivity Results
• 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
• Andrew Jacobs (HSBC)
• Claire Lobo (MarkitSERV)
• Darcy Baber (LCH)
• David Kempster (Morgan Stanley)
• Devansh Rastogi (DTCC)
• Dibyendu Majumdar (LCH)
• Harry McAllister (BNPP)
• Henri Pegeron (Sapient)
• Jaskiran Dhillon (MarkitSERV)
• John Booth (MarkitSERV)
• Katrina Bell (TrueEX)
• Leon Shor (DTCC)
• Liz Scott (DTCC)
• Mia Colasuonno (DTCC)
• Mike Anthony (Bank New York Mellon)
• Niranjana Sharma (CME)
• Shawn Kelly (ARK EDI Solutions)
• Simone Milani-Foglia (LCH)
• Sivagami Gomathinayagam (DTCC)
• Sreedhar Segu (Deutsche Bank)
• Sudipto Haldar (Morgan Stanley)
• Ted Brooks (MarkitSERV)
• Vijay Addanki (State Street)
• Yuval Kost (Traiana)
• Irina Yermakova (ISDA)
• Lyteck Lynhiavu (ISDA)
• Marc Gratacos (ISDA)

1.3.3 Regulatory Reporting Working Group

• Brian Lynn (Global Electronic Markets), chair
• Ahfan Chan (JPMorgan)
• Andrew Jacobs (HSBC)
• Avneesh Dutta (Citi)
• David Kempster (Morgan Stanley)
• Devansh Rastogi (DTCC)
• Harry McAllister (BNP Paribas)
• Henri Peregon (Sapient)
• John Booth (MarkitSERV)
• Jonathan Elliot (MarkitSERV)
• Justin Roy (Deutsche Bank)
• Leon Shor (DTCC)
• Liz Scott (DTCC)
• Lynn Callahan (Treasury)
• Martin Sexton (London Market Systems)
• Mia Colasuonno (DTCC)
• Naima Zerrouki (Societe Generale)
• Niranjana Sharma (CME)
• Peter Schulze (Citi)
• Peter Stockman (Deep River Group)
• Shawn Kelly (ARK EDI Solutions)
• Stephen White (Fidelity)
• Steve Goswell (Incept5)
• Sreedhar Segu (Deutsche Bank)
• Tony Coates (Deutsche Bank)
• Venkat Krishnasamy (JPMorgan)
• Karel Engelen (ISDA)
• Lyteck Lynhiavu (ISDA)
• Marc Gratacos (ISDA)
• Irina Yermakova (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)

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 (MarkItSERV)
• 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 (ICE)
• Jeff Valentino (Bank of America)
• Irina Yermakova (ISDA)

1.3.6 Credit Derivatives Working Group

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

1.3.7 FX Working Group

• Richard Haslock (Marit Serv), chair
• Andrew Gregory (HSBC)
• Andrew Jacobs (HSBC)
• Brian Lynn (GEM)
• Christina Yeung (Goldman Sachs)
• Harry McAllister (BNP Paribas)
• Irina Yermakova (ISDA)
• Lyteck Lynhiavu (ISDA)
• Marc Gratacos (ISDA)
• Stephen Turner (JP Morgan Chase)
• 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 (MarkItSERV)
• Robert Green (DTCC)
• Guy Gurden (MarkItSERV)
• Shabbir Irfani (Goldman Sachs)
• Rajan Khorana (Citadel Group)
• Robert Masri (DTCC)
• Coner Mongey
• Bin Shen (Goldman Sachs)
• Marc Teichman (ICE)

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 (MarkItSERV)
• 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)
• Fred Litjens (Murex)
• Irina Yermakova (ISDA)
• Jyoti Sahrawat (CME Group)
• Kent Tung(Goldman Sachs)
• Lyteck Lynhiavu (ISDA)
• Marc Gratacos (ISDA)
• Ronan Hughes (HSBC)
• Susan Helfter (Credit Suisse)
• Timothy Capuano (Goldman Sachs)

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 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.7 Second Working Draft (build#2)

• Credit Derivatives:
  • Added additional support for 2014 ISDA Credit Derivatives Definitions: an optional Boolean indicator standardReferenceObligation within the existing ReferenceObligation component. It indicates if the reference obligation is a Standard Reference Obligation. ISDA 2014 Term: Standard Reference Obligation.
• Business Process:
  • Enhanced Package Transactions representation:
    • Updated examples and schemes.
    • Within the packageHeader, added package type, size and originatingEvent
    • Within the tradeHeader, added originatingPackage including package id, size and sequence number: these will provide more information about the originating package and how this trade relates to it once the trade is separated from the package.
    • Pretrade view: Within tradePackage/allocations, added the “allocatingPartyReference” and changed the multiplicity of the allocations element to allow up to 2 instances of it
  • Partial termination of a TRS – Added an id attribute to the equity derivative “ActualPrice” type to allow price references to be made to it (See example #100 in confirmation/business-processes/execution-advice of a partial termination of a TRS)
  • Reporting:
    • Entity Classification: Within the reportingRegime, added partyEntityClassification as an improved way to relate an entity classification to a party (e.g., Financial/NonFinancial, Dealer/NonDealer, LocalParty/NonLocalParty)
    • Within the reportingRegime, added tradePartyRelationshipType to specify intragroup (ESMA), inter-affiliate (CSA). (See recordkeeping examples ex140, ex141, ex142)
    • Removed the now redundant intragroup flag introduced in WD1. Renamed isCompressedTrade to compressedTrade.
  • Confirmation view: Correction: Made ReportingRegime/supervisorRegistration optional when reportingRegime/Name is supplied. It had been made mandatory in Confirmation view in error since version 5.3. The original intention under recordkeeping was to mandate the existence of at-least-one-of (name, supervisorRegistration).
  • Predetermined Clearing: renamed specifiedClearingOrganizationPartyReference to predeterminedClearingOrganizationPartyReference to match last agreed working group documents/emails.
• The following issues have been resolved:
  • http://www.fpml.org/issues/view.php?id=1178
  • http://www.fpml.org/issues/view.php?id=1076

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 Changes compared to FpML 5.6 Recommendation (build#5)

• Commodity Derivatives:
  • Added support for Commodity Performance Swap, a swap in which the payout(s) are based on the price performance of an index rather than the price level of the index. Current support price performance metrics include price return and price variance.
  • Enhanced the CommoditySwaption and commodityOption/commodityForward models to include a field indicating the pre-determined clearing organization for the resulting swap created due from swaption exercise. This change has been approved by the CommWG – see the minutes from Sep-18-2013's meeting.
• Credit Derivatives:
  • Added support for 2014 ISDA Credit Derivatives Definitions:
    • Within 'CreditEvents', added 'governmentalIntervention' credit event.
    • Added an optional Boolean indicator standardReferenceObligation within the existing ReferenceObligation component. It indicates if the reference obligation is a Standard Reference Obligation. ISDA 2014 Term: Standard Reference Obligation.
  • Added support for Credit index swaps quoted using price: Added 'marketPrice' to 'feeLeg' in fpml-cd.xsd and 'price' to 'quotationStyleEnum' enumeration
  • Enhanced the CreditDefaultSwapOption model to include a field indicating the pre-determined clearing organization for the resulting swap created due from swaption exercise. This change has been approved by the CDWG – see the minutes from Mar-26-2014's meeting.
• Interest Rate Derivatives:
  • Fixed incorrect 'PaymentCalculationPeriod' type's derivation introduced in FpML-4-6 as part of the rationalization of the 'Payment' type hierarchy. The 'PaymentCalculationPeriod' is not a type of Payment so derivation from 'PaymentBase' is inappropriate. Within 'PaymentCalculationPeriod' complex type, removed derivation from 'PaymentBase'.
  • Enhanced the Swaption model to include a field indicating the pre-determined clearing organization for the resulting swap created due from swaption exercise.
• Equity Derivatives:
  • Enhanced the DividendSwapOptionTransactionSupplement and VarianceOptionTransactionSupplement models to include a field indicating the pre-determined clearing organization for the resulting swap created due from swaption exercise.
• Business Process:
  • Package Transactions - Refined the "tradePackage" representation (a bundle or package of trades executed and cleared as part of a single transaction). Note: Package Transactions are available in Confirmation, Pretrade, and Reporting views. Regulatory reporting would be at the granular level, not at the package level. For pre-trade view, the list of supported products include CDS, IRS and FX NDF.
    • Within the packageHeader, added package type, size and originatingEvent
    • Within the tradeHeader, added originatingPackage including package id, size and sequence number: these will provide more information about the originating package and how this trade relates to it once the trade is separated from the package.
  • For post trade events (increases, terminations, novations) added support for a size change of a notional schedule, not just a single value
  • For post trade events (increases, terminations, novations) added support for a price change to support resetting during the event.
  • Added support for partial exercises on trades with multiple notionals (of various types)
  • Enhanced the consent business process to allow more information about approvals to be captured. (see confirmation examples consent/msg-ex400 and msg-ex401)
  • Added support for "clearing instructions" to the physicaly settled options (CreditDefaultSwapOption, CommoditySwaption, DividendSwapOptionTransactionSupplement, VarianceOptionTransactionSupplement) that specifies any instructions on how the physical settlement is to be effected when the option is exercised.
  • Partial termination of a TRS – Added an id attribute to the equity derivative “ActualPrice” type to allow price references to be made to it (See example #100 in confirmation/business-processes/execution-advice of a partial termination of a TRS)
• Reporting:
  • Joint and Several Liable Parties: Refined support for multiple legal entities with joint and several liability
    • Within party, added a groupType flag (JointAndSeveralLiability) followed by several party references.
    • Within party, removed jointAndSeveralLiability added in the first working draft.
  • Added a Facility Execution flag to indicate whether the particular product must be executed on a SEF or DCM.
    • Within reporting regime, added a mandatoryFacilityExectution flag and additional elements to specify whether the party invoked exception to not execute the trade on facility such as SEF and DCM even though the particular product is mandated to execute on a SEF.
  • Added to reduce the overuse of the category element:
    • Within partyTradeInformation, compressedTrade - Specifies whether this trade is a result of compression activity.
  • Entity Classification: Within the reportingRegime, added partyEntityClassification as an improved way to relate an entity classification to a party (e.g., Financial/NonFinancial, Dealer/NonDealer, LocalParty/NonLocalParty)
  • Within the reportingRegime, added tradePartyRelationshipType to specify intragroup (ESMA), inter-affiliate (CSA). (See recordkeeping examples ex140, ex141, ex142)
  • Confirmation view: Correction: Made ReportingRegime/supervisorRegistration optional when reportingRegime/Name is supplied. It had been made mandatory in Confirmation view in error since version 5.3. The original intention under recordkeeping was to mandate the existence of at-least-one-of (name, supervisorRegistration).
  • Predetermined Clearing: renamed specifiedClearingOrganizationPartyReference to predeterminedClearingOrganizationPartyReference to match last agreed working group documents/emails.
• Shared:
  • Schema clean-up as per standards' recomendation
    • Removed orphan types

1.6.3 Incompatible changes compared to FpML 5.6 (build#5)

None.

1.7 SCOPE

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

1.7.1 Architecture Framework

The various Working Groups have developed FpML 5.7 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 Reporting

• Portfolio reconciliation
• Cash flow matching
• Valuation
• Position and activity reporting
• Reset reporting
• Credit event notice
• Collateral margin call, collateral substitution, interest (new for version 5)

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 Validation Scope

The Validation Working Group provides semantic, or business-level validation rules for FpML 5.7. These validation rules, which are aimed at normalizing the use of elements within FpML, are issued as part of the FpML Specification in the validation section of this document.

The validation working group publishes with its releases:

• A set of rules described in English
• Positive and negative test case documents for each rule
• Non-normative reference implementations

The current specification includes a set of rules for Interest Rate Derivatives, Equity Derivatives, Credit Derivatives, Loans, FX, and for shared components. The rules for the different asset classes will be further enhanced in future versions.

1.7.4 IRD Scope

In FpML 5.7 Last Call Working Draft 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
• Mandatory and Optional Early Termination Provisions for Interest Rate Swaps
• FX Resetable Cross-Currency Swap

1.7.5 Credit Derivatives Scope

In FpML 5.7 Last Call Working Draft 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 Basket
• Credit Default Swap on a Mortgage
• Credit Default Swap on a Loan
• Option on Credit Default Swap
• Credit Event Notice

1.7.6 FX Scope

The Scope of FpML 5.7 Last Call Working Draft 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.7 Last Call Working Draft 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
    • Averaging
    • Barriers
  • Digital Options
• Option Strategies (multiple simple options)

In addition, support for the following money market instrument is also provided:

• Term Deposits (including features)
  • Money Market Deposits
  • Dual Currency

1.7.7 Equity Derivative Options and Forwards Scope

The EQD Products Working Group has extended the FpML standard to cover the following Equity Derivative products

• Broker Equity Options;
• Long Form Equity Forwards;
• Long Form Equity Options;
• Short Form Equity Options represented as Transaction Supplements under ISDA Master Confirmation Agreements.

1.7.8 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).
• Swaps that have specific adjustment conditions, such as execution swaps or portfolio rebalancing swaps;
• Swaps that involve the exchange of principal cashflows;
• Swaps that have inital and final stubs;
• Swaps which can be represented as Transaction Supplements under ISDA Master Agreements;

Extraordinary Events terms have been incorporated, to take into consideration the release of the 2002 ISDA Definitions for Equity Derivatives.

Trigger swaps, in which equity risk morphs into a fixed income risk once a certain market level is reached, may be supported in a subsequent release.

1.7.9 Correlation Derivatives Scope

The Equity Derivative Working Group extended FpML to cover:

• Correlation Swaps

1.7.10 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.11 Dividend Derivatives Scope

The Equity Derivative Working Group extended FpML to cover:

• Dividend Swap Transaction Supplement

1.7.12 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-7:

• 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.7.13 Pricing and Risk Scope

The Pricing and Risk scope for FpML 5.7 Last Call Working Draft is:

Valuation and basic risk on the following products:

• Vanilla IR Swaps (single and dual currency fix/float swaps, non-CMS/CMT)
  • Valuation reporting (trades only)
  • Market Data (Yield Curves, FX spot rates)
  • Market risk reporting (Delta Risk vs. Curve Inputs, FX exposures) for trades
• Credit Default Swaps
  • Valuation reporting for trades
  • Market Data (ir curves, credit spread, recovery rate, probability of default)
  • Market risk reporting (risk with respect to. the above variables) for trades
• IR Caps/Floors/ EuropeanSwaptions, and corresponding risk types
  • Valuation reporting for trades
  • Market data (volatility surfaces)
  • Market risk reporting
    • Volatility/Vega Risk
    • Convexity/Gamma Risk (applies to all products)
    • Time Decay/Theta (applies to all products)
• Portfolio level valuation and risk
  • Valuation
  • Risk reporting

The Pricing and Risk Working Group has also provided some definitions that might be useful for other types of valuation and risk 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-7 , 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-7, 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-7.xsd - Root definitions.
    • fpml-doc-5-7.xsd - Trade definitions and definitions relating to validation.
    • fpml-shared-5-7.xsd - Shared definitions used widely throughout the specification. These include items such as base types, shared financial structures, etc.
    • fpml-enum-5-7.xsd - Shared enumeration definitions. These definitions list the values that enumerated types may take.
    • fpml-asset-5-7.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-7.xsd - Interest rate derivative product definitions.
    • CD
      • fpml-cd-5-7.xsd - Credit derivative product definitions.
  • Confirmation, Reporting, Record-keeping, Transparency Views
    • FX
      • fpml-fx-5-7.xsd - Foreign exchange product definitions.
    • EQD
      • fpml-eq-shared-5-7.xsd - Definitions shared by types with Equity Underlyers.
      • fpml-eqd-5-7.xsd - Equity Option and Equity Forward Product Definitions.
      • fpml-return-swaps-5-7.xsd - Return Swaps Product Definitions.
      • fpml-variance-swaps-5-7.xsd - Variance Swap and Variance Option Product Definitions.
      • fpml-correlation-swap-5-7.xsd - Correlation Swap Product Definitions.
      • fpml-dividend-swap-5-7.xsd - Dividend Swap Product Definitions.
    • Bond Options
      • fpml-bond-option-5-7.xsd - Bond and Convertible Bond Options Product Definitions.
    • Options shared
      • fpml-option-shared-5-7.xsd - Shared option definitions used for defining the common features of options.
    • Commodity
      • fpml-com-5-7.xsd - Commodity Swap and Commodity Option Derivative Poduct Definitions.
    • Cross-Asset Class Products
      • fpml-doc-5-7.xsd - strategy - combination of existing products.
      • fpml-doc-5-7.xsd - instrumentTradeDetails-A type to hold trades of multiply-traded instruments. Typically this will be used to represent the trade resulting from a physically-settled OTC product where the underlying is a security, for example the exercise of a physically-settled option.
        
      • fpml-standard-5-7.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-7.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-7.xsd - Definitions related to messaging and workflow.
    • fpml-business-events-5-7.xsd - Business event notification components, such as creation of a trade, amendment, increase, termination and novation.
  • Pre-Trade View
    • fpml-msg-5-7.xsd - Definitions related to messaging and workflow.
    • fpml-pretrade-processes-5-7.xsd - Definitions of pre-trade Credit Limit Check messaging components to support Clearing Certainty work flows.
    • fpml-business-events-5-7.xsd - Business event notification components, such as creation of a trade, amendment, increase, termination and novation.
  • Confirmation View
    • fpml-confirmation-processes-5-7.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-7.xsd - Credit event notification components
  • Record-keeping View
    • fpml-recordkeeping-processes-5-7.xsd - Definitions for non-public execution reporting, used to report transaction records to SDRs.
  • Transparency View
    • fpml-transparency-processes-5-7.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-7.xsd - Cash flow matching and portfolio reconciliation messaging components
    • fpml-reporting-5-7.xsd - Definitions of reporting messaging components such as position activity report , event activity report and reset report.
    • fpml-credit-event-notification-5-7.xsd - Credit event notification components
    • Pricing and Risk:
      • fpml-valuation-5-7.xsd – Valuation result sets and related definitions.
      • fpml-mktenv-5-7.xsd – Definitions of market environment data structures such as yield curves, volatility matrices, and the like.
      • fpml-riskdef-5-7.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-7.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-6"
	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-6.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-6' for FpML 5.6), 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.7 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 Party 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 partyTradeInformation. 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.2.3 otherPartyPayment

This component contains additional payments such as brokerage paid to third parties which are not part of the economics of a trade itself.

2.8.2.4 brokerPartyReference

The brokerPartyReference identifies the party or parties that arranged the trade.

2.8.2.5 calculationAgent

The calculation agent identifies the party or parties responsible for performing calculation duties, such as cash settlement calculations.

2.8.2.6 documentation

The documentation element defines where the legal definitions used for the trade are documented.

2.8.2.6.1 contractualMatrix

The contractualMatrix element is a generic mechanism for making references to ISDA-published matrices within an FpML trade definition.

Specifically it is designed to:

• Reference zero, one or more applicable matrices in a single trade definition.
• Identify the form of applicable matrix, e.g. the “2000 ISDA Definitions Settlement Matrix for Early Terminations and Swaptions” or “Credit Derivatives Physical Settlement Matrix” etc.
• Optionally identify the relevant version of the matrix through reference to its publication date (this is currently the mechanism recommended by ISDA). The publication date is optional since typically the incorporation language defines which version would be applicable based on the Trade Date of the relevant Transaction.
• Allow an additional term to be specified that acts as a “key” into the matrix for identifying the applicable sub-set of relevant data in the matrix. For example, in the case of the Credit Derivatives Physical Settlement Matrix the Transaction Type term identifies the applicable column of defaults in the matrix that is applicable to the Transaction. For the 2000 ISDA Definitions Settlement Matrix no additional terms need to be specified since the “key” into the matrix is the Settlement Currency which is already captured as part of the standard trade terms.

2.8.2.6.1.1 Examples of using the contractualMatrix structure

For Interest Rate Derivatives:

To specify that the July 1, 2004 version of the ISDA Definitions Settlement Matrix for Early Terminations and Swaptions is incorporated into the Confirmation:

<documentation>
  ...
          <contractualDefinitions>ISDA2000</contractualDefinitions>
          <contractualMatrix>
                    <matrixType>SettlementMatrix</matrixType>
                    <publicationDate>2004-07-01</publicationDate>
          </contractualMatrix>
</documentation>
                                        

For Credit Derivatives:

To specify that the March 7, 2005 version of the Credit Derivatives Physical Settlement Matrix is incorporated into the Confirmation and that the applicable Transaction Type is North American Corporate:

<documentation>
  ...
          <contractualDefinitions>ISDA2003Credit</contractualDefinitions>
          <contractualSupplement>ISDA2003CreditMay2003</contractualSupplement>
          <contractualSupplement>ISDA2003Credit2005MatrixSupplement</contractualSupplement>
          <contractualMatrix>
                    <matrixType>CreditDerivativesPhysicalSettlementMatrix</matrixType>
                    <publicationDate>2005-03-07</publicationDate>
                    <matrixTerm matrixTermScheme="http://www.fpml.org/coding-scheme/
credit-matrix-transaction-type-1-0">NorthAmericanCorporate</matrixTerm>
          </contractualMatrix>
</documentation>
                                        

2.8.2.6.2 Attachment

Now in reporting view, FpML allows attached documents to be included as part of the documentation section. These attached documents may be included as text or as a variety of encoded binary formats. Each attached document must include a resourceId and should include a resoure type indicating what the document is used for (e.g. it is a Confirmation), a mimeType indicating the format of the document, and may include other fields describing the attachment.

If the document is embedded as an encoded binary document (for example as a Base64 encoded binary document), it is the responsibility of the developers generating and processing the FpML to convert between the binary formatted file and the encoded representation. For Base64 there are a variety of open source and commercial tools and libaries which may be used for this purpose. The generator of the FpML document will convert the document (for example a PDF) into a Base64 encoded representation (which is an ASCII translation of the binary bytes in the input document) and put that ASCII string directly into the "base64Binary" field in the FpML resource. (It may be better to enclose this data in a CDATA block to avoid the risk that a base64 encoded sequence may result in a sequence that is confusing to the XML parser; alternatively XML characters such as '<' or '>' can be escaped individually.). It is the responsibility of the recipient of the message to extract the character value of the base64Binary field and apply the reverse transformation to revert the string back to the original binary format. Now that binary data may be saved to a file system or database, and/or displayed using the tool implied by the resource's mimeType. (Note that with some tools it may be easier to save and retrieve the base64 encoded representation rather than the binary representation.)

2.8.2.7 collateral

The collateral element defines the collateral obligations of a party. The collateral element is an optional child of Trade and Independent Amount is a mandatory child of the Collateral element.

2.8.2.7.1 independentAmount

Independent Amount was present at a Product Specific level, being both defined and used within Credit Derivatives. However, the concept of Independent Amount applies across products; it is the method of calculation which varies according to the type of Product. For this reason Independent Amount was moved to the trade level in version 4.1 Last Call Working Draft.

PaymentRule is an abstract type defined for extension purposes. PercentageRule is a derived type from PaymentRule. It contains the payment percentage and a reference to the notional amount. Type substitution mechanism will be used in this case, which makes it extensible in case there is a need to add other calculation methods in the future.

The notionalAmountReference defines a reference to the notional amount. This reference is particularly useful in products like interest rate swaps, in which the leg of the notional needs to be specified. In order to accomplish that, an optional id attribute (IDREF type) has been added to the notional amount elements of the different products.

After some discussion, the Credit Derivatives Working Group decided that people will not use FpML without a CSA being signed, so a collateral party element is not necessary. The Collateral element itself should is a useful container for future work. The independentAmount element may not be required in the presence of CSA, but its optional inclusion should be supported for the avoidance of doubt, and expression of any variation from the CSA

2.8.2.8 governingLaw

The governingLaw element identifies which legal system will be used to enforce the contract.

2.8.3 The Portfolio Component

The portfolio component specifies a set of trades as a list of tradeIds and a list of sub portfolios. Portfolios can be composed of other portfolios using a composition pattern. By using the tradeId to identify the trade the standard allows for portfolios to be sent around without the full trade record.

2.8.4 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.
• relatedParty: Identifies a related party performing a role within the transaction.

Example:

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

2.8.5 The Account Component

The Account component holds information about an account that represents any party's account at another party. Parties may be identified by the account at another party.

This is a description of the elements:

• accountId: An account identifier. For example an Account number.
• accountName: The name by which the account is known.
• accountBeneficiary: The beneficiary of the account.
• servicingParty: A reference to the party that services/supports the account..

Example:

                    ...
	<account id="GEN478">
		<accountId>47896325</accountId>
		<accountName>Sky General Account</accountName>
		<accountBeneficiary href="SKY"/>
	</account>
                    ...
                                        

2.8.6 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.8.7 The Strategy Component

This product is discussed in "Cross-Asset Products".

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 in version 5.6.

• basketChange
• corporateAction
• indexChange

A new tradePackage event has been added in 5.7 to support Package Transations. tradePackage represents a bundle or package of trades executed and cleared as part of a single transaction). The tradePackage representation and examples have been refined in WD2. Note: Package Transactions are available in Confirmation, Pretrade, and Reporting views. Regulatory reporting would be at the granular level, not at the package level. For pre-trade view, the list of supported products include CDS, IRS and FX NDF.

• tradePackage

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.5 Trade Approval (Credit Approval Token)

The trade model has been enhanced with an approval structure (approvals) to support electronic execution in which the trades are pre-authorized (“pre-screened”) to be cleared by the credit granting firm.

There have been industry discussions between several FCMs and clearing firms on how FCM acceptance of pre-trade screened orders could be automated. Screened orders would be given a credit approval token.

Background - CFTC Rule 1.73 requires FCM to establish risk-based limits in each Client account, and screen orders for compliance with these limits. In the current trade clearing workflow CCPs present trades to FCM for acceptance. This, in essence, is yet another screening operation. Since the orders were screened before the resulting trades were sent for clearing there is no reason to reject the trades. FCMs seek to prevent rejecting a trade which was the outcome of an approved order. In other words, FCMs would like the ability to have auto-acceptance of trades that result from properly screened orders, while being able to possibly reject trades that weren’t screened.”

In FpML, the credit approval token is modeled using a generic approval structure that could be used for (but not limited to) credit limit checking. Other uses include compliance approvals or for market risk limit approvals, (most likely internal to a firm).

The trade has been enhanced with an apprvoal structure (approvals) which is a container for approval states in the workflow.

The approval element represents a specific approval state in the workflow. and contains the following elements:

• type - The type of approval (e.g. "Credit").
• status - The current state of approval (.e.g preapproved, pending approval, etc.)
• approver - The full name or identifiying ID of the relevant approver.
• approvingPartyReference - A pointer style reference to a party defined elsewhere in the document. The party referenced has approved the specified item (e.g. trade or allocation).
• approvalId - An identifer for a specific appoval, to allow the approval to be identified and tracked.

The following examples illustrate the use of the approval structure.

• confirmation/business-processes/clearing/msg-ex07.xml (requestClearing) - This example shows a request for clearing from a SEF to a clearing house
• confirmation/business-processes/clearing/msg-ex10.xml (clearingConfirmed) - This example shows a clearing confirmation to a SEF showing the original trade and information about the cleared trades that were created.

Additional related enhancements are deferred to a later version. This may include, for instance, the ability to update approvals independent of trade information, or allocation-specific approval processes.

3.4.6 Reporting Business Processes

3.4.6.1 Overview

3.4.6.1.1 Purpose

The FpML reporting capability is designed to allow institutions to report details about derivative portfolios with a variety of levels of granularity, in a format consistent with the normal messaging and confirmation specification.

The reporting capability is intended to support a number of use cases, including but not limited to:

• Regulatory reporting

• Reporting between counterparties for reconciliation purposes

• Reporting from service providers to clients on portfolios maintained by the service.

3.4.6.1.2 Reporting View

The FpML reporting messages are provided in the FpML reporting view, which is indicated with the namespace "http://www.fpml.org/FpML-5/reporting".

The reporting view contains essentially the same element definitions as the FpML confirmation view. However, in almost all cases the elements are optional (minOccurs = "0") in reporting view. This allows the creator of the report to decide which elements to include. There are some other slight differences in the product schema between reporting view and confirmation view; these are mostly to prevent ambiguity in the reporting view cause by too many optional elements within choices.

3.4.6.1.3 Field Lists

For a specific report layout, implementations are encouraged to list the required/expected fields using a field list that is validated by the recipient using a validation processor. The field list should be expressed in the form of a table that lists the expected fields and the XPath within the FpML document that contains the expected value. The validation processor can iterate through these XPaths and verify that they are present, and report errors if they are not.

In future drafts of this specification we anticipate publishing field lists for select business reporting requirements.

3.4.6.1.4 Generic Product

To support reporting on derivative products for which no full FpML representation is available, there is a special product called the "genericProduct" (this was formerly known as the "nonSchemaProduct"; that product is still available as a deprecated product name.). This product allows a small number of identifying characteristics to be represented. These identifying characteristics cover key risk attributes of the product, such as:

• key dates (like effective, termination, and expirations dates)

• underlying assets

• strikes or fixed rates

• notionals

Characteristics that do not have significant impact on the overall market or credit risk of a product are not included and will not be added in the future. These characteristics include:

• date adjustment rules, conventions, business calendar locations, and lags or offsets

• fields related to detailed calculation procedures, such as precision, negative rate treatment, etc...

• fields related to option exercise procedures, such as business calendar location time.

• fields related to handing of unusual situations, such as extraordinary events.

• in general, any fields that do not contribute to describing the risk characteristics of the trade

Following are guidelines for use of the non-schema product:

• nonSchemaProduct should be used only when the product is not adequately covered by the existing FpML product structures.

• If a non-schema product is used, the asset class and product type should be filled in with descriptions of the product, either using FpML-supplied or implementation-specific codes.

• When a full FpML product description becomes available for a non-schema product, new implementations should use that in preference to the non-schema product, and existing implementations should attempt to phase out uses of the non-schema product over time as they are maintained.

3.4.6.2 Description of the Processes

3.4.6.2.1 Position and Activity Reporting

The position report was introduced in FpML 4.x in the Pricing and Risk area. It allows a firm to report on the open positions contained in a portfolio. For version 5.x the position report has been expanded, and two new activity reports have been added. In addition, the position report (positionReport) was enhanced to report payments at the position level in order to support the clearing and settlement of OTC derivatives.

3.4.6.2.1.1 Position Report

The position report is intended to allow a firm to report the current status of a portfolio of positions.

The position report includes:

• header information to describe the contents of the report (asOfDate, dataSetName, reportContents, quotationCharacteristics, submissionsComplete)

• a series of position elements. Each position element includes:

  - identifying information

  - optional status information, allowing the reporting firm to explain how the position was created and modified

  - details of the trade underlying the position

  - servicing events, both planned and historical, together with related values

  - valuation elements reporting calculated or observed values such as NPVs, rates, or spreads. (More information about the valuation elements can be found in "Pricing and Risk Architecture" section.)

  - optional payments (repeatable payment element), allow cash flows to be reported for the majority of asset types as well as allow payments to be reported at the position level in the same way that valuations are reported.

The FpML standard for cashflow matching offers the ability to provide optional calculation details (calculationDetails) within the payment structure that explain how the payment has been computed. A typical approach would be to reconcile the payment(s) and grossCashflow(s) elements.

Additional observation and calculation details can be provided to enable a fast research path to the cause of the break. calculationElements and/or observationElements structures can be used to capture partial calculations and observation details.

(More information about the calculation details can be found in section 3.4.2.3 "Calculation Details". Additionally, the “Design principles” subsection provides insights on supported cashflows in FpML)

Example of new payment structure at the position level, including adjustedPaymentDate and calculationDetails:

 
 <position>
               ...
                <payment>
                             <identifier>123</identifier>
                             <payerPartyReference href="party1"/>
                             <receiverPartyReference href="party2"/>
                             <paymentAmount>
                                         <currency>EUR</currency>
                                          <amount>123</amount>
                              </paymentAmount>
                              <adjustedPaymentDate>2004-06-04</adjustedPaymentDate>
                              <calculationDetails>
                                               <grossCashflow>
                                                              <cashflowId cashflowIdScheme="http://www.abc.com/cashflowId">_2005US2</cashflowId>
                                                               <payerPartyReference href="party2"/>
                                                               <receiverPartyReference href="party1"/>
                                                                <cashflowAmount>
                                                                                 <currency>USD</currency>
                                                                                  <amount>20444.44</amount>
                                                                 </cashflowAmount>
                                                                <cashflowType>Coupon</cashflowType>
                                               </grossCashflow>
                                                <calculationElements>
                                                                <calculationPeriod>
                                                                                  <adjustedStartDate>2004-03-20Z</adjustedStartDate>
                                                                                   <adjustedEndDate>2004-06-20Z</adjustedEndDate>
                                                                                    <numberOfDays>92</numberOfDays>
                                                                                    <dayCountFraction>ACT/360</dayCountFraction>
                                                                                    <dayCountYearFraction>0.2555</dayCountYearFraction>
                                                                 </calculationPeriod>
                                               </calculationElements>
                              </calculationDetails>
              </payment>
             ...    
      

The position element is based on ReportedPosition type which adds the optional payment(s).

The payment structure in FpML was modified to accommodate for an optional adjusted payment date and calculation details used in the position report. The payment within the position report is based on a new type PositionPayment which uses a new model group PaymentDetails.model that covers payment details.

The existing PaymentMatching type was restructured to use the new PaymentDetails model group.

3.4.6.2.1.2 Position Activity Report

The position activity report is a variation of the Position Report that is specifically targeted to reporting changes in position, for example changes between two points in time.

Instead of directly containing positions, the PositionActivityReport includes a series of Position Updates. These elements include information about the type of update (new position, modified position, removed position), the reason for the update, and details of the resulting or removed position.

3.4.6.2.1.3 Event Activity Report

The Event Activity Report allows a firm to report on a series of related or unrelated business events, such as trades, amendments, novations, or terminations. These events will typically be applicable for a specific context (e.g. a single account or product) over a specific time period (e.g. a day or month). It does not allow valuation information or servicing events to be reported.

3.4.6.2.2 Securities Reporting

From version 5.5 some additional examples of securities reporting in FpML have been created. There are now examples of event activity reports that show securities trades using the "instrumentTradeDetails" structure. There are also examples of position reports that show a new structure, a "holding", which records a position held in a multiply-traded security like a stock or a future.

3.4.6.2.3 Reset Reporting

The reset report, added in FpML 5.0, allows a firm to report on the fixing of a floating rate index, and to indicate the positions that are affected by the fixing.

It contains:

• header information describing the applicability of the report

• information about the index being set

• information about the rate observation

• a list of positions affect by the fixing.

3.4.6.2.4 Exposure Reporting

FpML can now support reporting of aggregate exposures in a variety of ways. The ExposureReport allows a substantial number of idenfying characteristics to be used to categorize exposure. These characteristics include both party-related categories (such as the region, country, risk grade, or industry sector) to be used for grouping exposure records, or product-related fields such as product type, currency, underlying assets, etc. Exposures can be reported in a flat summary form, or nested within other exposures to provide a multi-level report. The values that are reported can be any FpML measureType, such as aggregate NPV or notional, or various risk measures.

The FpML exposure report is used to implement the CFTC Part 20 position report. Several examples are provided of these exposure reports. Subsequent versions of the specification will include more detail on these examples, which are based on the Part 20 regulation and the CFTC guidebook to Part 20 reporting.

3.4.6.2.5 Cashflow Matching

The FpML standard for cashflow matching is aimed at providing a messaging standard to support the ISDA guideline developed by the ISDA Operations Committee.

3.4.6.2.5.1 Model Overview

Its purpose is to provide a general framework that the industry service providers as well as the various financial actors in the marketplace should use to support their cashflow reconciliations on OTC derivatives. Because of the wide range of expected usage scenarios as well as products involved, this standard has been developed as a flexible paradigm: the schema is largely made of optional nodes and elements, while this guideline document opens the possibility of using only part of the framework.

The scope of this standard is to support the following spectrum of use cases:

• The complete range of OTC products that are supported by the FpML standard;
• The matching of cashflows by industry service providers that provide a multilateral relationship with an implied level of sophistication in terms of underlying state transition structure, as well as, on the other end of the spectrum, simple bilateral reconciliation of cashflows among specific actors;
• Intra-day matching, where sets of cash flows are sent incrementally and resulting messages with the matching statuses are received immediately, as well as end-of-day (or, more generally, and-of-period) matching processes.

The standard for cashflow matching supports both cashflow netting for a single and across multiple trades.

This section is organized as follows:

• Design principles
• Messaging and schema structure
• Usage guidelines

3.4.6.2.5.2 Design Principles

The standard for cashflow matching within a single trade was specified by the FpML Business Process Group in the course of 2005 and early 2006, as a follow-up from the earlier high-level guidelines developed by the ISDA Operations Working Group. In 2010, support for cashlow matching across multiple trades was added by the FpML Business Process Working Group.

The following design principles have guided this standard:

• Synergies with the other components of the FpML standard:

  The cashflow matching standard is positioned as an additional component of the FpML standard. As such, it leverages the building blocks that are part of this standard and is compatible with those other components. As a result, it is expected that the actors of the marketplace will leverage their existing FpML product implementations to support their cashflow matching reconciliation.

• Product support:

  The FpML representation of cash flow matching is designed to support all OTC derivatives products. The representation is flexible and generic in order to accommodate the different product features. Also, the aim being to reconcile cashflows as opposed to trade characteristics, the trade features that are part of this standard have been strictly limited to (i) those that are deemed appropriate for identifying the supporting trade, and (ii) the calculation details that support the exposed cashflows.

• Supported cashflows:

  The current version of the standard is focused on reconciling known cashflows (as opposed to partial calculation and/or observation elements that will get refined over time until the cashflow is finally known) within the context of a trade or across trades. It is expected that if two parties would have a netting agreement across contracts for the purpose of decreasing their settlement exposure, they would use this standard for reconciling their individual cashflow components while agreeing through a different framework regarding the actual settlement amount.

• Matching window:

  For cashflows within a single trade, the high-level guideline developed by the ISDA Operations Working Group recommends that “The window for inclusion into the matching process is to be based upon the next known cashflow date, subject to certain rules”. The recommended FpML standard is that, in addition to systematically reconciling the next known cashflow within a given trade (whether it is 1 week or 1 year out),the parties should also reconcile any known cashflow within a window of 20 business days. Such calendar month is indeed considered as the operational window where the parties should systematically match any known cashflow, including those that come is rapid upcoming succession.

• Cashflow granularity:

  The high-level guideline developed by the ISDA Operations Working Group recommends that “Each cashflow leg forming part of a trade should be matched independently.” The FpML Business Process Working Group expressed the concern that this might cause issues in the case of less vanilla OTC derivatives, as it would imply that the various parties have a similar modeling approach for the trade. As a result, the FpML standard recommends the matching, within each trade, of the cashflow that the counterparty intends to settle, with the gross cashflow component(s) being provided as an underlying calculation detail. Considering the industry practice of reducing settlement risk by netting cashflows whenever practically possible, this means that in most of the cases netted cashflows per payment date and currency should be reconciled (netted float vs. fix in the case of interest rate swaps, netted price, interest and dividend components in the case the reset or unwind of a total return swap, etc.). In the fewer cases where two counterparties would, for example, intend to settle separately their fixed and float legs, they would expose these two cashflows independently.

• Identification of trades:

  For addressing the case of trades that have not been negotiated through electronic platforms and for which the counterparty's trade ID has not been captured, the FpML standard provides the ability to identify this trade through a meaningful set of standard economic details: dates, notional and underlying asset. This set of attributes has been limited in order to avoid the bias of focusing the reconciliation on trade attributes instead of cashflows elements.

3.4.6.2.5.3 Cashflows within a trade

• Sequence of messages:

  The standard suggests that the following workflow sequence will be applied for reconciling cashflows related to OTC derivatives contracts in the case where a central matching service will be involved:

  • Either Matching Requester sends a TradeCashflowsAsserted including the set of net payments (each one uniquely identified) that need to be reconciled to the Matching Service as of a specific date. Initially, non-previously submitted sets of payments are at the Pending state. The message can be rejected if it doesn’t correlate, which would imply sending a MessageRejected and the submitted set would go to a rejected state.

  • Once the matching process is performed the matching service sends a CashflowsMatchResults message. This message includes a list of all matched, mismatched (with proposed matches), and unmatched set of payments. Alleged and unmatched net payments are the same state but from different sides. So the status of the cashflow changes from Pending to Unmatched, Mismatched, or Matched depending on the matching results.

  

  • The set of payments can be cancelled (removed) from the process using a cancelTradeCashflows message.
  • A broken matched is a transition from matched but it’s not a state in the workflow. The broken matched status has been suggested as part of the ISDA high-level standard for Cash flow Matching, Netting, and Settlement. However, from a modeling perspective, this is considered a transition between two different states.
  • If a payment is unmatched or mismatched while it reaches the stated payment date, it moves to Expired state.

3.4.6.2.5.3.1 tradeCashflowsAsserted

As stated above, the payment is exposed to the matching process using the tradeCashflowsAsserted message:

The tradeCashflowsAsserted message contains the following structures:

• asOfDate: The date and time at which the set of net cashflows was defined.
• tradeCashflowsId: Unique identifier assigned by either party or matching service, as agreed, to a set of net cashflows.
• tradeIdentifyingItems: Structure that holds reference to the trade through the tradeId and optionally some trade-specific elements for identifying the trade in the case of trades that have not been negotiated through electronic platforms and for which the counterparty's trade ID has not been captured. The underlyingAsset element is a head of a substitution group. This means that this element is replaced by one of the possible underlying components defined in the fpml-asset subschema. These components include: equity, index, bond, convertible bond, fx rate, and other underlyers.

• adjustedPaymentDate: The adjusted date in which the net payments are being paid/received.
• payment: Defines a net payment in a given currency and optionally contains the gross cash flow information and its related calculation details that sustains this payment.

• matchId: A unique identifier assigned by either party, or matching service, as agreed, to each set of matched cashflows.

3.4.6.2.5.3.2 tradeCashflowsMatchResult

The result of the reconciliation process is reported using the tradeCashflowsMatchResult message:

The message includes a status element. The values are defined using a coding scheme. The values include:

• Matched: both sides have the same cash flow (or set of cash flows) information within matching policies.
• Mismatched: both sides have the same cash flow (or set of cash flows), but there are differences greater than the acceptable tolerance in the matching policies.
• Unmatched: no corresponding cash flow (or set of cash flows) was found in "the other party’s" submitted sets.
• Alleged: no corresponding cash flow (or set of cash flows) was found in "your" submitted sets.

3.4.6.2.5.3.3 cancelTradeCashflows

The set of net payments can be cancelled using CancelTradeCashflows message:

3.4.6.2.5.4 Cashflows across multiple trades

• Sequence of messages:

  The standard suggests that the following workflow sequence will be applied for reconciling cashflows related to multiple OTC derivatives contracts:

  • The Matching Requester sends a nettedTradeCashflowsAsserted including the set of net payments (each one uniquely identified) that need to be reconciled to the Matching Service as of a specific date. Initially, non-previously submitted sets of payments are at the Pending state. The message can be rejected if it doesn’t correlate, which would imply sending a nettedTradeCashflowsException message and the submitted set would go to an exception state.
  • Once the matching process is performed the matching service sends a nettedTradeCashflowsMatchResults message. This message includes a list of all matched, mismatched (with proposed matches), and unmatched set of payments. Alleged and unmatched net payments are the same state but from different sides. So the status of the cashflow changes from Pending to Unmatched, Mismatched, or Matched depending on the matching results.
  • The set of payments can be cancelled (removed) from the process using a nettedTradeCashflowsRetracted message.

• Referencing the trade within the gross cashflow:

  The ability to establish the relationship between the cashflow and the trade is implemented referencing the partyTradeIdentifier through the partyTradeIdentifierReference within the GrossCashflow component:

  	 
  <nettedTradeCashflowsAsserted>
  ...
  	<tradeIdentifyingItems>
        		<partyTradeIdentifier id="trade2">
  			...
  	</tradeIdentifyingItems>
  	...
  	<grossCashflow>
              ...
              <partyTradeIdentifierReference href="trade2"/> 
              ...
      </grossCashflow>
  ...
  </nettedTradeCashflowsAsserted>
  
  
    

3.4.6.2.5.5 Reference Data

In order to standardize the values of some of the elements defined by the cash flow matching subschema, a set of schemes is provided. The schemes provided include:

• Product type scheme
• Cash flow type scheme
• Updated asset measure scheme
• Cash flow status scheme

The scheme mechanism provides implementers the ability to define their own schemes in a more generic or more aggregated level.

3.4.6.2.5.6 Usage Guidelines

The FpML schema that supports the cashflow matching standard has a quite loose grammar control: a large number of elements are made optional, while there a significant reliance on values that are specified through schemes that are external to the scheme (as opposed to stricter enumerations).

As stated in the introduction to this document, this is because this standard is aimed at supported a wide range of use cases.

As a result, a set of usage guidelines are being provided thereafter, which adoption is left to the discretion of the respective implementers. Also, a set of examples in the form of xml files have been developed, which illustrate those usage guidelines.

3.4.6.2.5.6.1 Trade Identification

The FpML guideline recommendation for cashflow matching is to identify the trade using either the common trade identifier (in the case where it has been negotiated through an electronic platform), or the trade identifiers assigned by each of the respective parties (in the case where a post-trade matching process exists, either bilaterally or through an industry service provider).

Recognizing that a common trade identification is, most often, not available (at least in the early stages of the contract’s lifecycle), the FpML standard supports the identification of the trades through a set of trade attributes:

• Trade date, effective date and termination date. The recommended usage is to specify those two latter dates as unadjusted, without date adjustment. The objective is indeed to use those attributes as a trade identification mechanism, not to reconcile the date adjustment convention for the given contract. In the case where a trade would have several effective dates and/or termination dates, the recommended usage guideline is to identify it with the earliest effective date and the latest termination date.
• ProductType. A simple typology of OTC products has been developed to support the cashflow matching process, which is contained in the product-type-simple-1-0.xml scheme. This typology can be used by the implementers as a reference for product categorization. As a coding scheme it can be customized easily to meet the needs of the application.
• Underlyer. The substitution group that is part of the schema provides the ability to represent the whole array of underlying assets currently specified through FpML. The examples that have been developed illustrate the suggested usage. In the case of assets that have multiple industry references, such as listed securities (with ISIN, CUSIP, RIC, etc.) or reference entities (with the formal name or the RED identifier), the expectation is that while FpML provides an appropriate framework, each implementer will specify an appropriate convention.
• Notional. The FpML usage guideline is to specify the notional (or notionals, in the case of a cross-currency swap) in effect on the last day of the last calculation period.

Below is a snippet of one of a credit default swap example that highlights this approach for identifying the trade when no common identifier is available and the party do not have (yet) the trade identifier of its counterpart:

 
...
<tradeIdentifyingItems>
	<partyTradeIdentifier>
		<partyReference href="abc"/>
		<tradeId tradeIdScheme="http://www.abc.com/tradeId">SDB0494701620</tradeId>
	</partyTradeIdentifier>
	<tradeDetails>
		<tradeDate>2005-02-28</tradeDate>
		<effectiveDate>
			<unadjustedDate>2005-03-01</unadjustedDate>
		</effectiveDate>
		<terminationDate>
			<unadjustedDate>2009-12-20</unadjustedDate>
		</terminationDate>
		<productType productTypeSimpleScheme=
"http://www.fpml.org/coding-scheme/product-type-simple-1-0">CreditDefaultSwap</productType>
		<underlyer id="_018A99">
			<referenceEntity>
				<entityId entityIdScheme=
"http://www.fpml.org/spec/2003/entity-id-RED-1-0">018A99</entityId>
		</referenceEntity>
		</underlyer>
		<underlyer id="FIXED">
			<fixedRate>
				<initialValue>0.04</initialValue>
			</fixedRate>
		</underlyer>
		<notional>
			<currency>USD</currency>
			<amount>2000000.00</amount>
		</notional>
	</tradeDetails>
</tradeIdentifyingItems>

...      
                                                

In this other snippet, the respective trade identifiers are know, and the party that asserts the cashflow does not then see the need to express the trade details (this latter point being however not necessarily an optimal approach, considering that the statement of the economic identifiers of the trade could be a good way to ensure that the trade identification has not been mi-stated):

 
...
 <tradeIdentifyingItems>
	<partyTradeIdentifier>
		<partyReference href="abc"/>
		<tradeId tradeIdScheme="http://www.abc.com/tradeId">trade1abcxxx</tradeId>
	</partyTradeIdentifier>
	<partyTradeIdentifier>
		<partyReference href="def"/>
		<tradeId tradeIdScheme="http://www.def.com/tradeId">123cds</tradeId>
	</partyTradeIdentifier>
</tradeIdentifyingItems>

...
                                           
                                                

3.4.6.2.5.6.2 Payment

As presented in the Design Principles section of this document, the recommended usage of this messaging protocol is, within the perimeter of a trade, to match the cashflow that the counterparties intend to settle.

Practically speaking, this means that when several cashflows will have the same payment date and currency, those will be presented as netted to the matching process.

This snippet below presents the simple way of expressing a payment as part of the schema:

...
<payment>
	<identifier paymentIdScheme="http://www.abc.com/paymentId">8410363</identifier>
	<payerPartyReference href="def"/>
	<receiverPartyReference href="abc"/>
	<paymentAmount>
		<currency>USD</currency>
		<amount>20444.44</amount>
	</paymentAmount>
</payment>
...
                                                
                                                

3.4.6.2.5.6.3 Calculation Details

The FpML standard for cashflow matching offers the ability to provide underneath calculation details that explain how the payment has been computed. Those details are optional, in order to provide the ability for the implementers to have matching processes with a scope limited to the sole payment, with no underlying information.

Considering the underlying recommendation that cashflows should be matched as they will settle and, as a result, that most of those would be netted, the calculationDetails container is based upon the specification of each of the gross cashflow components that make up this exposed payment. In the case where no netting would have occurred (e.g. a credit default swap coupon), the amount stated in the paymentAmount node would be equal to the one stated in the grossCashflow node.

The various examples that have been developed propose a usage guideline in the case where the party would provide a complete set of underlying information to explain how the payment has been computed. From an implementation perspective, such approach would however not necessarily imply that each of those data elements should be reconciled: a conceivable approach could be to just reconcile the payment and gross cashflow(s) elements, with the observation and calculation details being provided to enable a fast research path to the cause of the break.

3.4.6.2.6 Portfolio Reconciliation

3.4.6.2.6.1 Introduction

This section describes the specification to support trade reconciliation as described in the recent ISDA Operations Committee paper Recommended Practices for Portfolio Reconciliation. It details the reconciliation scenarios that it has been designed to support and required assumptions and goes on to define the ‘protocol’ that allows their execution through the exchange of electronic messages between participating parties.

The main drivers for these enhancements are the best practices stated by the ISDA Operations Committee and the work developed by the Data Standards Working Group (DSWG), a group of US hedge funds that developed a position reporting format based on FpML. The FpML portfolio reconciliation integrates this position representation into its framework.

3.4.6.2.6.2 Model Overview

The objective of portfolio reconciliation is to ensure that two organisations have consistent record for a given portfolio by comparing descriptions of the portfolio content provided by each participant.

The result of the reconciliation process is a report describing where the two content descriptions are in agreement and just as importantly where they disagree (e.g. additional/missing transactions, different values, etc.).

The reconciliation process itself can be performed in several different ways. The following sections describe the key areas of variation.

3.4.6.2.6.2.1 Bilateral vs. Trilateral

Reconciliation can be performed directly with the other participant or via an intermediary who performs the service on behalf of both parties. If it is performed bilaterally then either one or both the parties may take in responsibility for performing the necessary comparisons.

3.4.6.2.6.2.2 Batch (a.k.a Snapshot) vs. Incremental

Reconciliation MAY be performed when complete portfolio descriptions have been received from both parties or as an on going process whenever either party changes their portfolio description.

A portfolio description could be sent as a single message to the service (e.g. containing a complete snapshot of a small portfolio), or as a series of messages describing incremental changes to the position components (e.g. as additions, modifications, cancellations to a large portfolio).

It may also be useful to be able to construct portfolios by referencing components of previous submitted portfolios rather than having to re-upload them (especially if there are a large number of components which have not changed). The reference could be made specific through the use of version identifiers.

3.4.6.2.6.2.3 Fixed time vs. Real-time

Reconciliation may be performed as soon as information is provided or at a fixed time, for example relative to a specific geographic ‘end of day’ or ‘market close’ time.

Portfolio information is never provided simultaneously by both parties so any change to a portfolio in a real-time based service will generate an initial unmatched state with respect to one party and alleged with respect to the other until the matching component is received from the other party (when it can be resolved to matched or mismatched).

3.4.6.2.6.2.4 Level of detail

Reconciliation MUST compare the parametric descriptions of each portfolio constituent but MAY also compare additional information such as any provided valuations.

3.4.6.2.6.2.5 Product Scope

Trades describing positions created by negotiated OTC transactions. The unique nature of these contracts means that they cannot be aggregated. The products supported include complete range of OTC products that are supported by FpML. Currently the coverage is limited to OTC products. It doesn’t include multiply traded contracts.

The potential extended coverage could include:

• Positions in multiply traded contracts such as equity, bonds, futures, exchange traded options and warrants. Such positions are normally expressed and an opening and closing amount of some contract and MAY be supported by a list of the transactions that affected the position. A proposal for representing trades of securitised products is available on the FpML website on the proposals section www.fpml.org/proposals (Non derivative products) and this framework can be extended to support these products.
• Cash positions resulting from foreign exchange transactions, coupons and dividends. As with securitised positions theses should be expressed as an opening and closing amount for each currency and MAY be supported by a list of affecting transactions. Whilst currencies have been modelled in FpML since version 1.0 they are not treated the same ways as OTC and non-derivative products so they require separate handling.

3.4.6.2.6.3 Design Principles

Although reconciliation occurs between pairs of parties, for the purposes of defining the communications protocol we need only consider the data exchanges that occur between a single requesting party and the provider of the reconciliation service.

In terms of design inputs, the position representation for portfolio reconciliation is based on the model developed by the Data Standards Working Group (DSWG), which defined a position report message to support daily reporting. The Business Process Working Group decided that it was important to integrate the DSWG representation (already part of FpML in the PositionReport message) into the Portfolio Reconciliation framework.

3.4.6.2.6.3.1 Product Representation

The FpML portfolio reconciliation messages use the existing FpML OTC product representations. The rationale for this is that existing complex data models used for confirmations purposes should cover the data requirements for portfolio reconciliation. However, the FpML Business Process Working Group recognizes that there are some data elements that are required for confirmation and other post-trade processes that shouldn’t be required for reconciliation activities. Future schemas may have a more flexible product representation to be used exclusively for reconciliation purposes.

3.4.6.2.6.3.2 Design approach

When a group of parties are reconciling with each other through the same service they should all have the same view, although they may define a different number of portfolios to the service. For example if we had four parties A, B, C and D using the same service where A had traded with B, C and D, C had traded with A and D whilst B had only traded with A, then A would need to submit three portfolios (A-B, A-C, A-D), B would submit one (B-A), C would submit two (C-A, C-D) and D would submit two (D-A, D-C).

To initiate reconciliation the requester should send one (“snapshot approach”) or more (“incremental approach”) ‘PositionsAsserted’ messages to the reconciliation service provider to construct the portfolio contents.

Each definition request WILL contain details of:

• The identity of the requesting party
• The identity of the matching party (optional).
• A portfolio identifier (possibly defined by the service provider). Having an identifier allows more that one portfolio to exist for each party pairing. For example you could define portfolios to maintain DAILY, WEEK-TO-DATE and MONTH-TO-DATE positions with a particular counterparty simultaneously.
• A portfolio as-of date (the date for which the portfolio definition applies).
• A flag indicating whether it is a new portfolio or an update to an existing one.
• A number of portfolio component definitions with optional version information.

In the “incremental approach” the reconciliation service WILL use the two identities, portfolio identifier and as-of date to group together components that arrive in multiple definition messages to create a complete portfolio definition. Request message contents SHOULD be processed sequentially and individually. It is possible for some component definitions to be rejected while others are accepted and applied to the portfolio.

Optionally, the service provider can send a response message called ‘PositionsAcknowledged” with immediate feedback how each of the provided component definitions was processed (e.g. accepted/rejected). It does not contain any reconciliation comparison results.

At some time following the submission of the portfolio of positions, the reconciliation server will process its set of the portfolio collections and produce a notification report of matches and differences. This notification report is called ‘PositionsMatchResults’.

In a real-time environment this notification may be generated every time one of underlying portfolio sets is modified and requesters MUST be capable of processing multiple notification messages relating to the same portfolio. They MUST also be capable of processing a reconciliation notification (containing alleged position components) for a portfolio they have not yet defined. This implies that the portfolio identifier can be determined in advance and is not a user definable data item.

3.4.6.2.6.4 Messaging and Schema Structure

This section describes the new types need within the FpML schema to support the outlined design.

3.4.6.2.6.4.1 PositionsAsserted

The ‘PositionsAsserted’ message type is used to either start the construction of a new portfolio or modify the contents of an existing one.

The message includes:

• A portfolio identification section, identifying the portfolio name, the defining and matching parties, the as-of date, and the new portfolio definition flag as described above.
• An indicator called ‘submissionsComplete’ that specifies whether this message completes the updating of the portfolio for the as-of date.
• A set of instructions for specifying the positions contained in the portfolio. There is a choice between completely restating the portfolio’s positions (by specifying “replaceAllPositions” and listing the up-to-date positions), and incrementally updating the portfolio by updating or removing positions.
• The parties referenced by the above.

To specify a position, whether it is a new or updated position, the ‘definePosition’ element is used. It has the structure shown in the following diagram and it is based on the Position representation developed by the FpML Pricing and Risk Working Group. This guarantees a consistent position model, which is used for both: position reporting as well as portfolio reconciliation. This structure allows for positions in unique OTC derivative contracts, and through extensions could potentially allow for listed securities (identified by an instrument code value and qualifying URL) and cash as well. It can be appear multiple times within a request.

This structure is an extension of the Pricing and Risk Position type and includes:

• Identification information (a position ID and version), which allows the position to be referenced across messages. The positionId may be based on one of the trade IDs in an included trade, or it may be something different. The version is a positive, increasing number. Higher version numbers imply “newer” positions, i.e. ones that replace previously supplied information. There is no requirement that the version number be small or that version numbers be sequential, so a timestamp-based integer could potentially be used as a version identifier. The positionId and version are assumed to have been created by the sender of the message (i.e. the definingParty), rather than by any of the parties to the trade.
• Complete trade details, or an element identifying the version of the position that included the full trade definition, or trade reference (mainly used for reporting purposes).
• An optional reference to a base party, from whose point of view valuations are computed. This allows the reconciliation service to determine the sign with which valuations should be compared.
• A “force match” element, which is an optional reference to a position specified by the matchingParty that is known to correspond to this position.

If a position is no longer needed (e.g. a change to a trade’s details means that it falls outside the scope of the reconciliation) it may be removed by sending a ‘removePosition’ element, which simply contains a “PositionReference” type. This is a reference to a previously identified position. Its structure is as follows:

The PositionReference contains a position ID, which is version-independent, and an optional version. If the version is specified, the reference is to a particular version of the position; if not, the reference is to any version (which typically means the latest version).

In the case of a “removePosition” element, the “version” is not needed to specify the position, and if supplied should be treated as informational.

Positions that net to a zero closing amount within the scope of the reconciliation SHOULD be expressed using ‘definePosition’ and NOT removed. Example: If I opened with 50 shares in IBM stock that were sold during the period being reconciled then I should have a position with zero closing units to represent this. If I do no further trading in IBM stock then there does not need to be a position for IBM stock in future reconciliation portfolios until some is reacquired.

If a reconciliation provider cannot process a PositionsAsserted, for example because the message cannot be parsed, is schema-invalid, or contains illegal header information (defining or matching parties, as-of date, or portfolio name), it should return an FpML “MessageRejected” message, specifying the reason the message was rejected.

3.4.6.2.6.4.2 PositionsAcknowledged

When a reconciliation provider has processed a ‘PositionsAsserted’ it MAY return a ‘PositionsAcknowledged’ to the requester. The decision on whether use this message will depend on the implementation. As the request may have contained many position adjustments the response must be capable of providing status information of each adjustment.

For each ‘definePosition’ element in the request the response SHOULD contain either a ‘definedPosition’ or ‘unprocessedPosition’ element. Similarly a ‘removePosition’ element in the request SHOULD have either a corresponding ‘removedPosition’ or ‘unprocessedPosition’ element.

The ‘definedPosition’ element describes a position adjustment that succeeded. It contains a PositionReference to the position that was created. Similarly, a “removedPosition” element contains a PositionReference to the position that was removed.

If an entire position change cannot be processed then in addition to the position identification information, the reason that the position change could not be processed should be provided.

3.4.6.2.6.4.3 PositionsMatchResults

The result of a reconciliation operation is one (“snapshot approach”) or more (“incremental approach”) ‘PositionsMatchResults’ messages sent by the provider. A single notification message may contain the results of comparing multiple positions and hence must support the match, mismatched, unmatched and alleged position results. However, the data reported for each one of these status is quite similar, i.e. an implementation may choose to report differences between positions even thought they are matched objects.

The message includes a status element. The values are defined using a coding scheme. The values include:

• Matched: both sides have the same position information within matching policies.
• Mismatched: both sides have the same position, but there are differences greater than the acceptable tolerance in the matching policies.
• Unmatched: no corresponding position was found in "the other party’s" submitted set.
• Alleged: no corresponding position was found in "your" submitted set.

3.4.6.2.6.5 Usage Guidelines

The FpML support for portfolio reconciliation aims to support a wide range of scenarios. As a result, a set of usage guidelines are being provided thereafter, which adoption is left to the discretion of the respective implementers. Also, a set of examples in the form of xml files have been developed, which illustrate those usage guidelines.

3.4.6.2.6.5.1 Trilateral vs. Bilateral

In the implementation of this set of messages using a central matching service (trilateral), there are a set of guidelines to consider:

• The matchingParty element contained inside portfolioDefinition should be omitted since it would provide irrelevant information.
• A matchId value should be provided by the central matching service once two positions are matched.

In the bilateral case:

• The matchingParty element should be provided.
• The parties should agree upfront whether to use the matchId element and who will provide the value.

3.4.6.2.6.5.2 Incremental vs. Snapshot

There are a set of guidelines to consider depending on the scenario that is going to be implemented:

• If the position submissions are sent incrementally, the matching results should be sent incrementally as well.
• If the position submissions are sent as snapshot (using a single message for the whole portfolio), the results should be sent as snapshot as well.

3.4.6.2.6.5.3 Reference Data

In order to standardize the values of some of the elements defined by the portfolio reconciliation subschema, a set of schemes is provided. The schemes provided include:

• Position match status scheme (position-match-status.xml)

3.4.6.2.6.5.4 Position Differences

In order to provide the ability to report position differences, the portfolio reconciliation PositionMatchResults message reuses the existing TradeDifference structure. Example:

<difference>
	<differenceType>Value</differenceType> 
	<differenceSeverity>Error</differenceSeverity> 
	<element>adjustedTerminationDate</element> 
	<basePath>constituent/trade/fra/ajustedTerminationDate</basePath> 
	<baseValue>1992-01-17</baseValue>
	<otherPath>constituent/trade/fra/ajustedTerminationDate</otherPath> 
	<otherValue>1993-01-17</otherValue> 
	<message>Value [1993-01-17] in HEDGUS33 is [1992-01-17] in ABCDUS33.</message> 
</difference>
						

There is flexibility for implementers to provide the basePath/otherPath information. FpML recommends having different “entry points” for reporting the XPath expression depending on where the difference is located. These entry points would begin with the following elements:

• constituent (as shown in the snippet above)
• valuation
• scheduledDate

3.4.6.2.6.6 Examples

A set of scenarios and examples have been developed. These scenarios and examples are available at the examples section (SCHEMAS and EXAMPLES) - Business Process Examples - Portfolio Reconciliation.

3.4.6.2.7 Valuation Reporting

More information about valuation can be found in the "Pricing and Risk Architecture" section.

3.4.7 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.

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 main documents produced by the Validation Working Group is the set of validation rules, expressed in English:

• Collateral Rules: Business constraints for Collateral messages.
• ID / IDREF Rules: Business constraints for ID / IDREF relationships.

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 Cross-Asset Products Scope

FpML has several special products that cover multiple asset classes. This includes combinations of other products and trades of non-OTC securities. In addition, the Reporting Working Group defined several products for reporting views:

• strategy - combination of existing products.
• instrumentTradeDetails-A type to hold trades of multiply-traded instruments. Typically this will be used to represent the trade resulting from a physically-settled OTC product where the underlying is a security, for example the exercise of a physically-settled option.
  
• 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.
  
• 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.
  

5.2 Overall Architecture

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

• strategy
• instrumentTradeDetails
• genericProduct
• standardProduct

5.3 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.4 The InstrumentTrade Details Component

FpML is a standard that supports OTC derivative products. However, sometimes as a result of settling an OTC derivative, a trade in a non-derivative security must be performed. For example, in an OTC equity option that is physically settled, exercising the option results in a trade in the underlying equity security. For this reason, FpML has added limited coverage for representing trades in non-OTC assets. This coverage includes based information about the security that was traded, the amount that was traded, and the price at which it was traded. It does not provide full details of settlement calculations, such as fees, commissions, or taxes.

The instrumentTradeDetails component may be included in an FpML trade object in place of an OTC product. It may include several types of information.

• Information about the buyer and seller of the instrument (and optionally their accounts).
• The security that was traded.
• The amount that was traded.
• The price at which the instrument was traded, net and/or gross of fees and commissions
• The equivalent principal amount, net and/or gross of fees and commissions

The quantity of the trade indicates the number of securities that were traded, or the nominal (face value) amount.

The pricing of trade represents the gross price (price before fees and commissions) and/or the net price (pricing including fees and commissions).

The principal of trade represents the net and/or gross value that was traded, that is to say the quantity times the net and/or gross price.

5.5 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.

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.6 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.

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

A swap component contains one or more instances of the swapStream component, zero or more instances of the additionalPayment component together with an optional cancelableProvision component,an optional extendibleProvision component and an optional earlyTerminationProvision 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. There can also be additionalPayment elements that contain fees. The additionalPayment component is identical to the otherPartyPayment component shown above.

FpML also supports option related features. These include cancelable, extendible swaps and early termination provisions. Combining these together with swaptions into a single component was considered but rejected in favor of identifying the different option types with their own components. This provided more clarity and allowed for easier combination of the different options into a single trade. As such a swap can contain a cancelableProvision, extendibleProvision and an earlyTerminationProvision. All these components are very similar (and similar to the swaption component), re-use is achieved by using shared entities within each of the components.

FpML supports two representations of a swap stream; a parametric representation, and a cashflows representation. The parametric representation is designed to capture all the economic information required regarding dates, amounts and rates to allow trade execution and confirmation. The parametric representation is mandatory. The cashflows representation specifies an optional additional description of the same stream. The main purpose of this is to allow the inclusion of adjusted dates within an FpML representation of a trade. It can also be used to represent adhoc trades not achievable by easy manipulation of the parameters of a stream (i.e. by changing the adjusted dates). This would lead to the cashflows not matching those generated by the parameters (see more discussion later) and would also render the representation of the trade unsuitable for a confirmation. The spirit of FpML is that such manipulation of cashflows would be achieved by splitting a single stream into a number of streams though it is recognized that this may be impractical in some systems.

The cashflows representation is not self contained as it relies on certain information contained within the stream's parametric definition. The elements required from the parametric definition to complete the cashflows representation are:

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

• floatingRateIndex
• indexTenor
• rateTreatment
• finalRateRounding
• averagingMethod
• negativeInterestRateTreatment
• dayCountFraction
• discounting
• compoundingMethod.

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

• floatingRateIndex
• indexTenor.

The inclusion of the cashflows representation is intended to support Application integration. For example, a financial institution may have one application that captures trade parameters and constructs the trade schedules and then publishes the result for use by other applications. In this case it may be either undesirable, or impossible, for each of the subscribing applications to store and calculate schedules.

The flexibility of the cashflows representation also allows payment and calculation schedules which can not be fully represented by the parametric description. If this situation arises, the mandatory parametric data should still be included in the document and the flag cashflowsMatchParameters should contain the value false to indicate that it is not possible to generate the cashflows from this parametric data. The setting of this flag to true means that the cashflows can be regenerated at any time without loss of information.

Parties wishing to take advantage of the facility for specifying cashflows which are inconsistent with the parametric representation will need to specify additional rules for how the parametric representation should be processed. This applies to both the creation of the parametric data as well as its interpretation.

The cashflows representation specifies adjusted dates, that is, dates that have already been adjusted for the relevant business day convention using the relevant set of business day calendars (lists of valid business days for each business calendar location). The FpML standard does not specify the source of these business day calendars. This may lead applications to generate differing cashflow representations from the same parametric representation if they use different business day calendars. The use of adjusted dates also produces schedules that are only valid at a particular instance of time. Additional holidays for a business calendar location may subsequently be introduced that would result in changes to the adjusted dates, which would not be reflected in the cashflows representation.

Analogous to cashflows being used to represent adjusted dates, with the addition of options it was important to be able to represented the adjusted dates associated with an option. Thus, where appropriate, a component includes an optional element to represent a schedule of adjusted dates for the option. Such a schedule would include details of adjusted dates such as adjusted exercise dates and cash settlement dates.

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. However, certain types of trades may contain more than two legs. FpML does not restrict the number of legs that may be defined. From a modeling perspective, FpML does not distinguish between a swap leg referencing a fixed rate and a swap leg referencing a floating rate, the difference being indicated by the existence, for example, of the resetDates component in a floating rate leg.

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.

In FpML, the schedule of dates within a swapStream is based around the calculationPeriodDates component. The definition of a calculation period in FpML differs in some respects from the International Swaps and Derivatives Association (ISDA) definition of Calculation Period. In the case of a trade involving compounding, ISDA introduces the concept of a Compounding Period, with several Compounding Periods contributing to a single Calculation Period. The FpML calculation period is equivalent to the ISDA definition of Compounding Period when compounding is applicable, i.e. the calculation period frequency will correspond to the compounding frequency. An FpML calculation period is directly comparable to the ISDA defined Calculation Period when only one calculation period contributes to a payment.

The other date components within swapStream are related to the calculationPeriodDates component. The paymentDates and resetDates components contain the information necessary to construct a schedule of payment and reset dates relative to the calculation period dates.

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 and stubCalculationPeriodAmount components. fxLinkedNotionalSchedule is an alternative to notionalSchedule for defining notionals. This allows for the definition of FX Resetable trades by allowing for the notional of a stream to be linked to notionals from another stream by way of the spot fx rate.

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. Similarly, the stubCalculationPeriodAmount component will be required if the swap leg has either an initial or final stub, or indeed both, but should otherwise not be specified. The principalExchanges component is required in the case of cross currency swaps or other types of swap involving exchanges of principal amounts.

The payerPartyReference and receiverPartyReference elements indicate which party is paying and which receiving the stream payments. This is done by referencing the appropriate party within the party component.

The detailed structures within the swapStream are shown diagrammatically below:

6.1.1 Relative Swap

The pricing and valuation working group required product definitions in order to support:

• Pricing requests
• Curve definitions

To support the above the Pricing and Risk Working Group required a Relative Swap – ie a swap where the dates are specified as periods relative to some other date. Eg – effective date is spot and the termination date is 5y after the effective date.

The working group considered including a separate product and extending the existing product. The group decided that many of the features of a relative swap could be very useful within the normal swap definition. Also, providing a separate product would add ambiguity in the standard allowing two ways to represent some products. As such is was decided to extend the existing InterestRateStream to include relative swap features.

To fully define any swap using relative dates then all places where a date is specified in the standard would need to be replaced by a relative date type. The group considered this but agreed that the initial proposal should limit the work to extending the calculation period dates to cover relative dates. This would cover the requirements of the Pricing and Valuation WG since it allows the definition of relatively simple swaps as relative. If a requirement arises to define more complex swaps (eg compounding with payment stubs) then the standard can be extended at that point.

An optional stubPeriodType element was added to allow the definition of how any irregular period should be handled. This element can be present along with the explicit dates but if this is the case there is a rule that the dates generated using the stubPeriodType should be consistent with the dates present within calculationPeriodDates.

6.1.2 Non-Deliverable Settlement Provision

The Interest Rate Stream component captures the necessary information to represent the non-deliverable terms of an interest rate swap.

These non-deliverable terms specify the conditions under which the cashflows will be made in a different currency (the “settlement currency”) than the currency in which a given leg is denominated (the “reference currency”).

The InterestRateStream type contains an optional settlementProvision component.

This structure supports both "Euro trades" (where settlement currency needs to be specified) and the non-deliverable settlement provision.

Five elements are required to characterize the non-deliverable settlement terms:

• The settlement currency;
• The reference currency;
• An indication/pointer to the reference currency of the swap as well as to the payments that need to be made in that specific currency;
• The determination of the date on which this FX rate will be specified (typically, in reference to the payment date);
• The specification of how this FX rate will be determined.

Here is how each of these requirements is addressed through this structure:

• The settlement currency is specified through the settlementCurrency element;
• The reference currency is specified through the referenceCurrency element (this approach has been considered as more straightforward than specifying it through an href into the calculatedAmount node);
• The indication of the payments that will be made in that settlement currency is done through the datesRelativeToPaymentDates element, which provides the ability to point to multiple payment nodes in the document through the unbounded paymentDatesReference. The example below illustrates how it works in the case of a swap leg that has resets as well as a principal exchange:

The regular payments of the swap get assigned an Id:

<paymentDates id="PaymentDatesID">
	<calculationPeriodDatesReference href="E2000098N10184"/>
	<paymentFrequency>
		<periodMultiplier>6</periodMultiplier>
		<period>M</period>
	</paymentFrequency>
	<firstPaymentDate>2005-06-16</firstPaymentDate>
	<payRelativeTo>CalculationPeriodEndDate</payRelativeTo>
	<paymentDatesAdjustments>
		<businessDayConvention>MODFOLLOWING</businessDayConvention>
		<businessCenters>
			<businessCenter businessCenterScheme=
"http://www.fpml.org/coding-scheme/business-center-2-0">USNY</businessCenter>
			<businessCenter businessCenterScheme=
"http://www.fpml.org/coding-scheme/business-center-2-0">GBLO</businessCenter>
		</businessCenters>
	</paymentDatesAdjustments>
</paymentDates>
        			

The principalExchanges node of the swap also gets assigned an Id:

<principalExchanges id="PrincipalExchanges">
	<initialExchange>false</initialExchange>
	<finalExchange>true</finalExchange>
	<intermediateExchange>false</intermediateExchange>
</principalExchanges>
        			

The dateRelativeToPaymentDates refers to each of those payments that need to be settled in the settlement currency of the swap:

<dateRelativeToPaymentDates>
	<paymentDatesReference href="PaymentDatesID"/>
	<paymentDatesReference href="PrincipalExchanges"/>
</dateRelativeToPaymentDates>
        			

• The determination of the date on which the FX rate will be specified is done through the FxFixingDate component, which uses the same structure than the RelativeDatOffset component, the only difference being that the relativeDateTo pointer is replaced by the dateRelativeToPaymentDates element, which has been described above.
• The specification of how the FX rate is determined is done through the Settlement Rate Option scheme. This scheme is specified as part of the ISDA 1998 FX and currency options definitions, and is effectively used in both the FX and Interest Rate markets to specify how a currency rate will be determined.

The priceSourceDisruption element defines the parameters used to get a price quote to replace the settlement rate option that is disrupted.

6.2 Asset Swap

Asset Swaps can be represented in FpML since version 4.2 Second Working Draft. An Asset Swap is a swap agreement where one leg mimics the return of the underlying asset. No transfer of asset takes place. Sometimes the sale of the bond is included in the asset swap construct.

6.2.1 Implementation

The representation of Asset Swaps reuses the Swap type adding an optional reference to a Bond underlyer.

6.2.2 Design Rationale

• All information required for supporting asset swaps existed in the Swap structure. Since within asset swaps there isn’t always a bond reference, a separate AssetSwap type would copy the existing Swap model without adding any value.
• Instead of referencing the generic underlying asset component, the group felt that narrowing the scope to bond (and maybe convertible bond in the future) would provide a more accurate definition. The existing underlying asset is too broad for this purpose, allowing coverage of cash and ETF that do not seem appropriate for this structure.
• The group agreed to make bondReference element optional within additionalTerms for extensibility purpose. Group envisioned that internal xml vocabularies would extend the additionaTerms element. Making bondReference required would be a problem for extensions.
• The group agreed that asset swap and Condition Precedent Bond are two different things. Condition Precedent Bond ties to the legal condition regarding the placement of the bond. The agreement was to support both within the existing Swap structure.
• The group agreed that the Condition Precedent Bond flag shouldn’t be placed in the Bond type since this element would be used in a very specific case. Placing the element within the Bond would overload the type.

6.3 Inflation Swap

The support of Inflation Swaps is based on the extension of the IRD product schema through the use of a Substitution Group.

The representation focuses on the Floating Rate Calculation, which is the key component that differentiates an Inflation based product from other Interest Rate Products.

6.3.1 Design Approach

A Floating Rate such as USD-LIBOR is observed daily as a percentage interest rate value and does not require any further calculation. In contrast, an Inflation Rate for a calculation period is usually determined as follows:

• Inflation Rate = (Index Final/Index Initial – 1) * 100%; where
• Index Initial is the published index level at the beginning of the period.
• Index Final is the published index level at the end of the period.
• Note: The index levels are usually taken for a Reference Month which is N months before the fixing date. This is known as the Inflation Lag. [ See below on Reference Month calculation ]

Apart from the above difference other features of inflation swaps are very much in line with the interest rate swaps. They have a concept of two cash flow streams, generally a fixed stream and an inflation stream. Both streams generate cash flows based on a function of the interest rate, notional and day count fraction for each calculation period. For this reason, the design approach focused on merging the functionality with the IRD schema instead of developing a new product.

Two options were considered in order to merge the Inflation Swaps into the IRD Schema. The first option was to extend the Floating Rate Leg to include Inflation specific elements. The second approach was to introduce a substitution group at the Floating Rate Leg level. Here are some of the advantages of using the substitution group instead of extending the schema.

• It does not weaken and add complexity to the existing floating rate definition through the addition of a number of optional elements.
• It allows the choice of the content of an FpML document to be determined at the time when the document is created.
• It is future proof by allowing the addition of new features to the Inflation or Floating rate elements without impacting each other (note: it also allows common features to be enhanced).
• It is entirely backward compatible. The Floating Rate Leg remains exactly the same as it is in the current version of the FpML.
• It adds no overhead to the existing schema.

6.3.2 Implementation

The InflationRateCalculation type is created by extension of the existing FloatingRateCalculation type, then addition of Inflation specific elements such as the Inflation Lag.

In order to implement the Substitution Group an abstract element rateCalcuation has been added to the schema. The rateCalcuation element can be substituted by the floatingRateCalculation element for standard Floating Rate legs, or the inflationRateCalculation element.

Any product that uses an InterestRateStream can elect to use this type by making use of the substitution group.

6.3.2.1 Inflation Terms

There are two main types of Inflation Products that are commonly traded, the Zero Coupon Inflation Swaps and the Year On Year Inflation Swaps. The following elements extended the FloatingRateCalculation in order to support the correct representation of these products.

• inflationLag
• indexSource
• mainPublication
• interpolationMethod
• initialIndexLevel
• relatedBond
• formula
• fallbackBondApplicable

Here is how the above structure addresses each of the following requirements:

• Inflation Index Name – element floatingRateIndex will be used to store the name of the Inflation Index itself.
• Index Source - indexSource element stores the main source of the inflation index such as Reuters or Bloomberg screens.
• Main Publication - mainPublication element represents the current main publication source of the inflation such as relevant web site or an official government or non-governmental organisation.
• Inflation Tenor, Day Count Fraction and Payment Frequency - elements of the InterestRateStream are reused to represent the inflation specific tenor, day count fraction (usually 1/1) and payment frequency.
• Inflation Lag - inflationLag element supports the period is used to determine the Reference Month(s) for fixing each Index Level.
• Fallback Bond Applicable - The applicability of a fallback bond as defined in the 2006 ISDA Inflation Derivatives Definitions, sections 1.3 and 1.8. Omission of this element imples a value of true.

• Reference Month for Initial/Final Index of each calculation period.
  • The Reference Month is usually calculated by offsetting the Index Level Fixing Date with the Inflation Lag. Example: Assuming Inflation Lag = 3M and Reset Date = 20-Apr-05, Reference Month = Apr-3M = January; Therefore, the index level used for the Fixing date of 20-Apr-05 will be the Inflation Index Level of January 2005.
• Initial Index Level – Unlike other interest rate products, the initial index of the first calculation period (even for non forward starting inflation swaps) is generally known at the time of entering the trade. This optional field will be used to store the initial value if it is known.
• Interpolation – there are several fields required to describe Inflation Interpolations.
  • Interpolation Method - The most common (and so far the only option) is Linear interpolation. The presence of this element indicates that the Inflation Index Level should be calculated from two different Index Levels and the resulting Inflation Index Level will be based on the weighting of each level.
  • Reference Month - for each point to be used for Interpolation is usually calculated as follows: Reference Month (point 2) = Month( Fixing Date ) – Inflation Lag; Reference Month (point 1) = Reference Month (point 1) – 1M
  • Weighting to be associated with each interpolation point’s Index Level. It determined by the Roll Day for each Fixing Date. For example, the Linear Interpolation between the inflation for the Reference Month of March (a) and April (b) as follows. Interpolated Index Level = (1-N/D).a + (N/D).b; where N = day part of the Fixing Date (i.e. 29) and D = number of days in the payment month (Juen)
• Formula to be used for Zero Coupon Inflation Leg. The same ComplexType used for Equity Swaps has been re-used for this.

• RelatedBond – If the Inflation Index can not be determined or has not been published continuously, an equivalent index level is obtained from an agreed related Bond. In order to support this the additionalTerms element is used to reference the bond.

6.4 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.5 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.5.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.5.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.5.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.5.4 Early Termination Provision

The right for one or both parties to terminate the trade and settle the remaining term of the swap for fair value. In the case of a mandatory early termination the termination is mandatory.

The Broker Working Group defined the requirement to be able to define early termination dates in a parametric form: “ At X years and every Y years thereafter “. The current FpML Specification quotes the actual unadjusted dates.

For example, FpML early termination dates: 10-Nov-2008, 10-Nov-2009, 10-Nov-2010, 10-Nov-2011. Assuming trade date was 10-Nov-2004 we would want “At 4 years and every year thereafter”.

The mandatoryEarlyTerminationDateTenor and optionalEarlyTerminationParameters elements allow specification of the mandatory early termination date in terms of a tenor, e.g. 5 years, or for optional early termination (mutual puts) the specification of the earliest termination date in terms of a tenor and a subsequent exercise frequency (in the case of Bermudan or American style early termination). American style exercise would be indicated by stating an exercise frequency of 1 day. European style exercise would omit the exercise frequency altogether.

6.5.5 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.5.6 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.5.7 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.5.8 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

6.6 Cash Settlement

The cash settlement component is used by mandatoryEarlyTermination, optionEarlyTermination and swaption. The language used within the component corresponds to the ISDA language for the various cash settlement methods. Of the five methods included, three share one underlying component and the other two share another component. Thus there is re-use whilst maintaining ease of identification of the type. Also, this approach allows for easy integration of other methods should they arise.

7 CREDIT DERIVATIVE PRODUCT ARCHITECTURE

7.1 Introduction

This section provides an in-depth review of the product architecture of FpML 5.7 Credit Derivatives. The products covered by FpML 5.7 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.7 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.7 Credit Derivatives that differ in name from their corresponding terms in the 2003 Definitions. In FpML 5.7 it is possible to represent credit default swap trades done under either the 1999 or the 2003 definitions.

The FpML 5.7 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.7 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 credit default swap basket

Product support for the credit default swap basket was added to FpML in version 4.2. The FpML representation for this product is based on the existing creditDefaultSwap product element and it includes the support for tranches.

7.1.4 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.4.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.4.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.5 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.6 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

The structure of the creditDefaultSwap element corresponds to the structure of the Confirmation that appears in Exhibit A of the 2003 Definitions (hereafter referred to as the "2003 Confirmation"). The six sections that comprise the 2003 Confirmation and their corresponding FpML elements appear in Figure 2.

In Transparency view, the structure of the creditDefaultSwap element corresponds to a subset of the structure of the Confirmation that appears in Exhibit A of the 2003 Definitions (hereafter referred to as the "2003 Confirmation"). The sections that comprise the 2003 Confirmation and their corresponding Transparency View FpML elements appear in Figure 2.

2003 Confirmation	FpML creditDefaultSwap Element
General Terms	generalTerms
Fixed Rate Payments	feeLeg
Floating Payment	protectionTerms
Settlement Terms	physicalSettlementTerms or cashSettlementTerms
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 necessarily required for a transaction supplement or other activities in the trade lifecycle. Therefore, the equivalent element (physicalSettlementTerms or cashSettlementTerms) is optional in FpML 5.7.
• The Notice and Account Details and Offices sections of the confirmation do not have a direct analog in the FpML 5.7 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 sellerPartyReference element represents the protection seller. This party is referred to as the Floating Rate Payer in the 2003 Definitions. Similarly, the buyerPartyReference element represents the protection buyer and is referred to as the Fixed Rate Payer in the 2003 Definitions. These elements reference the party elements underneath the FpML root element.

The optional elements dateAdjustments.businessCenters and dateAdjustments.businessDayConvention are used to represent the terms Business Day and Business Day Convention respectively.

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.1 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.1.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.1.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.1.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.2 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.3 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.3.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.3.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>			
			

7.3.4 basketReferenceInformation

The basketReferenceInformation element appears in the figure below. This element is used to define the composition of the basket by a credit default swap basket.

The identification of the basket using basketId and/or basketName is optional since each component of the basket must be specified using the referencePoolItem element.

The constituentWeight (weight of each component of the basket) is optional since if the element is not present, it means that flat weight is assumed.

7.3.4.1 Basket Tranche and Nth to Default

The ability to specify either Nth and Mth to default or tranche details on baskets has been included within basketReferenceInformation.

The tranche element is available to specify an attachment and exhaustion point as well as the legal applicability of Incurred Recovery. The Nth and Mth to Default sequence is available to express trades in which there is a triggered reference obligation to payout. The tranche and nthToDefault are features are both optional structures.

Some illustrative example FpML snippets follow:

<generalTerms>
  ...
  <basketReferenceInformation>
   <referencePool>
     <referencePoolItem>
	<referencePair>
		<referenceEntity id="agriumEntity">
			<entityName>Agrium Inc.</entityName>
			<entityId entityIdScheme="http://www.fpml.org/spec/2003/entity-id-RED-1-0">
008HA7</entityId>
		</referenceEntity>
		<referenceObligation>
			<bond>
				<instrumentId instrumentIdScheme="http://www.fpml.org/spec/2002/
instrument-id-CUSIP-1-0">008916AB4</instrumentId>
				<couponRate>0.077</couponRate>
				<maturity>2017-02-01</maturity>
			</bond>
			<primaryObligorReference href="agriumEntity"/>
		</referenceObligation>
		<entityType>NorthAmericanInvestmentGrade</entityType>
	</referencePair>
   </referencePoolItem>
   <referencePoolItem>
	<referencePair>
		<referenceEntity id="tenetEntity">
			<entityName>Tenet Healthcare Corporation</entityName>
			<entityId entityIdScheme="http://www.fpml.org/spec/2003/entity-id-RED-1-0">
8G836J</entityId>
		</referenceEntity>
		<referenceObligation>
			<bond>
				<instrumentId instrumentIdScheme="http://www.fpml.org/spec/2002/
instrument-id-CUSIP-1-0">88033GAT7</instrumentId>
				<couponRate>0.06</couponRate>
				<maturity>2011-12-01</maturity>
			</bond>
			<primaryObligorReference href="tenetEntity"/>
		</referenceObligation>
		<entityType>NorthAmericanInvestmentGrade</entityType>
	</referencePair>
     </referencePoolItem>
   </referencePool>
   <nthToDefault>1</nthToDefault>
  </basketReferenceInformation>
  ...
</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.7 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 Amount, Regular Schedule
• Fixed Rate, Regular Schedule
• Fixed Rate, Month-End Rolls
• Fixed Rate, Initial (Short) Stub
• Fixed Rate, Initial (Long) Stub
• Fixed Rate, Final (Short) Stub
• Fixed Rate, Final (Long) Stub
• Fixed Amount, Single Payment
• Upfront Fee and Fixed Rate, Regular Schedule
• Irregular Payment 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.

An optional cashflow representation is also permitted. The feeLeg element appears in Figure 7.

Figure 7: feeLeg element

This structure allows specification of a single payment (zero or more) or a periodic series of payments. Therefore, it allows representation of a single upfront payment, a single upfront payment combined with a schedule of regular payments or a schedule of totally irregular payment dates and amounts. Note that payments specified in the singlePayment and periodicPayment elements are always assumed to be payments made by the Fixed Rate Payer (protection buyer) to the Floating Rate Payer (protection seller).

When a ‘New Transaction’ arises following a Novation it is market practice for a CDS that the initial Calculation Period with respect to the New Transaction shall commence on and include the (a) the Fixed Rate Payer Period End Date of the ‘Old Transaction’ that immediately precedes the Novation Date; or (b) in the event the Novation Date occurs during the initial Calculation Period of the Old Transaction, the Effective Date (see 2004 ISDA Novation Definitions at http://www.isda.org/publications/pdf/2004-Novation-Definitions.pdf for further background, specifically Section 1.20).

firstPeriodStartDate supports a CDS FpML representation for a New Transaction arising from a Novation to be useful as a standalone document (without needing reference to the Old Transaction). It allows specification of the initial Calculation Period Start Date where it is not equal to the trade’s Effective Date.

The periodicPayment.rollConvention element is used to address the ambiguities that can otherwise occur with regard to the actual payment dates, particularly when considering month-end rolls and any initial stub. The rollConvention element typically takes a value of 1-30 or EOM. It represents the actual unadjusted day in the month on which payments would occur.

As in FpML 5.7 Interest Rate Derivatives, the periodicPayment.firstPaymentDate element is only needed when the first period is irregular, i.e. there is a short or long initial stub. For a regular set of payment periods knowing the Effective Date, Scheduled Termination Date, payment frequency and roll convention is sufficient to define the schedule.

In keeping with the 2003 Definitions either a Fixed Rate Calculation or known Fixed Amount may be specified. The optional periodicPayment.fixedAmountCalculation.dayCountFraction element should be omitted in the case of a Transaction Supplement. Similarly, the optional periodicPayment.fixedAmountCalculation.calculationAmount element provides support for the full confirmation but should be omitted in the case of a Transaction Supplement.

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.7 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

The protectionTerms element, which appears in Figure 8, represents the information specified in the FloatingPayment section of the 2003 Confirmation. This is where the credit events and obligations that are applicable to the credit default swap trade are specified.

Figure 8: protectionTerms element

The only required child element of protectionTerms is calculationAmount. It represents the term Floating Rate Payer Calculation Amount in the 2003 Definitions.

In order to indicate that a particular Credit Event is applicable in an FpML credit default swap trade, an element whose name is the Credit Event it represents appears as a child of the creditEvents element. If a particular Credit Event has no attributes of its own (e.g. Bankruptcy), it appears as an element with its value set to true. On the other hand, if it does have attributes (e.g. Failure to Pay - Grace Period, Payment Requirement) then those attributes appear as child elements of the Credit Event with the "applicable" element's value set to true. If in an element doesn't appear it means that it's not applicable or its applicability is defined within the master confirmation. In general, the value set to false will be specified only in case the default in the master confirmation needs to be overridden.

In the following example, these credit events are applicable:

• Bankruptcy
• Failure to Pay with Grace Period Extension not applicable and Payment Requirement of USD 1,000,000.
• Restructuring (R)
• Default Requirement of USD 10,000,000.

And these conditions to credit event notice settlement apply:

• Both the Buyer and Seller are notifying parties.
• Notice of Publicly Available Information is a Condition to Payment - defaults apply for Public Source(s) and Specified Number.

<creditEvents>
  <bankruptcy>true</bankruptcy>
  <failureToPay>
    <paymentRequirement>
      <currency>USD</currency>
      <amount>1000000</amount>
    </paymentRequirement>
  </failureToPay>
  <restructuring>
     <applicable>true</applicable>
    <restructuringType restructuringScheme =
      "http://www.fpml.org/spec/2003/restructuring-1-0">R</restructuringType>
  </restructuring>
  <creditEventNotice>
    <notifyingParty>
      <buyerPartyReference href = "abc"/>
      <sellerPartyReference href = "def"/>
    </notifyingParty>
    <publiclyAvailableInformation>
      <standardPublicSources> true</standardPublicSources>
      <specifiedNumber>2</specifiedNumber>
    </publiclyAvailableInformation>
  </creditEventNotice>
</creditEvents>
                

Please note the following regarding the representation of the Restructuring credit event:

• If the Restructuring credit event is not applicable, no restructuring element should appear in the creditEvents element.
• If Restructuring as defined in the 2003 Definitions is applicable and a full confirmation is being represented, then the restructuring element should appear and the restructuringType element contains one of the three restructuring codes (see below).
• If Restructuring as defined in the 2003 Definitions is applicable and a transaction supplement is being represented, then only the restructuring element should appear (the actual restructuring type will be defined in the relevant master confirmation associated with the transaction supplement).
• If the 1999 Definitions are used and a transaction supplement is being represented, the actual restructuring type needs to be explicitly specified in the XML instance using the restructuringType element (same as one would do for a long form) since the 1999 master agreements are silent on the actual restructuring type.

The legal restructuring codes are:

• ModR: If Restructuring Maturity Limitation and Fully Transferable Obligation (Section 2.32 of the 2003 Definitions) applies.
• ModModR: If Modified Restructuring Maturity Limitation and Conditionally Transferable Obligation (Section 2.33 of the 2003 Definitions) applies.
• R: If neither Restructuring Maturity Limitation and Fully Transferable Obligation or Modified Restructuring Maturity Limitation and Conditionally Transferable Obligation are applicable.

7.5.1 Mortgage derivatives

Five credit event elements have been added as part of the CreditEvents container in order to support cds on derivatives: failureToPayPrincipal, failureToPayInterest, distressedRatingsDowngrade, maturityExtension and writedown.

• failureToPayInterest and failureToPayPrincipal have been positioned as eligible credit events besides the pre-existing failureToPay element. The idea is that those new elements are distincts from this latter one, as they qualify the failure to pay in a manner that is explicit as part of the ISDA definitions. As such, there is no ambiguity. An alternative approach that consisted in qualifying this pre-existing failureToPay element was considered, but rejected because of its perceived level of indirection vis-à-vis the ISDA definitions.
• distressedRatingsDowngrade, maturityExtension and writedown: these three additional credit events have similarly been specified as boolean elements. Presence of the element as part of the instance document will then suffice to qualify any of those as an applicable credit event.

Mortgage CDS introduce the concept of floating amount events, which is not applicable to corporate CDS contracts.

• Specifies the eligible floating rate payment events through the following elements which are contained within the FloatingAmountEvents complex type:
  • principalShortfall;
  • interestShortfall;
  • writedown.
• The provisions that might be applicable in case the interest short fall applies (non-optional floatingAmountProvision extension).
• The events that can constitute to additional fixed payments (non-optional additionalFixedPayment extension):
  • interestShortfallReimbursement;
  • principalShortfallReimbursement;
  • The writedownReimbursement.

The optional obligations element has a category child element that represents the Obligation Category term. The ObligationCategory type is an enumeration that consists of values representing the following categories:

• Payment
• Borrowed Money
• Reference Obligations Only
• Bond
• Loan
• Bond or Loan

ISDA published in September 2004 additional provisions for U.S. Municipal Entity as Reference Entity (see http://www.isda.org/publications/pdf/additionalprovisions.pdf) and the associated form of confirmation (see http://www.isda.org/publications/docs/municdsconfirmation.doc) introduced three additional terms which could be selected as Obligation Characteristics and Deliverable Obligation Characteristics. These were:

• Full Faith and Credit Obligation Liability
• General Fund Obligation Liability
• Revenue Obligation Liability

The confirmation implied only one can be selected at a time.

These three elements were added as boolean elements within an optional choice group to the corresponding Obligations and DeliverableObligations complex types.

Obligation Characteristics are defined in a manner similar to credit events. In other words, each Obligation Characteristic has its own element. The applicability of the characteristic is indicated by the appearance of its corresponding obligationCharactersitic element.

7.6 physicalSettlementTerms and cashSettlementTerms

If settlement terms are specified in an FpML 5.7 credit default swap, then the settlement method of Physical Settlement or Cash Settlement is specified by the presence of either the physicalSettlementTerms or the cashSettlementTerms element respectively.

The physicalSettlementTerms element, which appears in Figure 8, represents the information specified in the Settlement Terms- Terms Relating to Physical Settlement section of the 2003 Confirmation.

The physicalSettlementPeriod contains one of three elements to represent the following conditions:

• businessDaysNotSpecified: Section 8.5/8.6 of the 1999/2003 CD Definitions applicable.
• businessDays: Explicit number of business days.
• maximumBusinessDays: Section 8.5/8.6 of the 1999/2003 CD Definitions capped at a specific number of business days, e.g. 10 days.

The optional deliverableObligations element is defined in a manner similar to the obligations element. The Deliverable Obligation Category is specified with the category element, which is of type ObligationCategory. Similar to an Obligation Characteristic, the applicability of a Deliverable Obligation Characteristic is indicated by the appearance of its corresponding element. It also bears mentioning that the applicability of Partial Cash Settlementappears as child element of the corresponding Deliverable Obligation Characteristic element.

Figure 9: physicalSettlementTerms element

The cashSettlementTerms element, which appears in Figure 10, represents the information specified in the Settlement Terms- Terms Relating to Cash Settlement section of the 2003 Confirmation. The mapping between this element and its corresponding section of the confirm is very straightforward.

Figure 10: cashSettlementTerms element

7.7 creditDefaultSwapOption

The creditDefaultSwapOption element defines the CDS option product in FpML.

The strike can be defined as spread, price or as the fixed rate.

7.7.1 Option Components

7.7.1.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. The forward entry will be deprecated as part of the 5.0 version and the integration of the equity option into this schema.

7.7.1.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.

7.7.1.2.1 Premium

The premium construct has a similar approach to 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.

7.8 Credit Event Notice

7.8.1 Background

The 2003 ISDA Credit Derivatives Definitions define "Credit Event Notice" as an irrevocable notice from a Notifying Party to the other party that describes a Credit Event that occurred.

A Credit Event Notice must contain a description in reasonable detail of the facts relevant to the determination that a Credit Event has occurred.

• EXHIBIT B to 2003 Credit Derivatives Definitions (pdf file)

FpML 5.7 supports Credit Event Notices. In FpML 5.7, Credit Event Notice is implemented as notification message (in 4.x, it is implemented as both static document (DataDocument) and notification message).

Credit Event Notices's main requirement as defined by the Credit Derivatives Working Group is to make the relationship to the corresponding ISDA legal framework more understandable.

7.8.2 Implementation

• The " CreditEventNotification" message is an extension of a " CorrectableRequestMessage". It adds an element called " creditEventNotice" and " party" with type " CreditEventNoticeDocument" to the notification message content.

• Why " CreditEventNotification" type? Because the " CreditEventNotice" type was already defined in the schema (This type is used to represent the Credit Event Notice information specified on a full confirmation. It is used to specify things like the notifying party and number of public sources. There was a name collision so the group decided to define "CreditEventNoticeDocument" as type containing the business document model.

The " creditEventNotice" element defines the content model for Credit Event Notice:

7.8.2.1 Description of some of the elements

affectedTransactions - Trades affected by this event.

The rationale for introducing a container for trade identifiers is because an individual trade can be referenced by 2 different partyTradeIdentifier elements - each allocated by a different party. So Bank A may know the trade as 123 and also know that their counterparty Bank B knows it as 567 and they'd wish to include both identifiers in the credit event notice but need to make it clear that 123 and 567 refer to the same trade.

referenceEntity:

creditEvent - Modeled as a substitution group in order to facilitate its extension. Each one of the possible values (bankruptcy, failureToPay, obligationDefault, obligationAcceleration, repudiationMoratorium, and restructuring) has its own complex type which extends the CreditEvent type. It has exactly the same behavior as an xsd:choice but it’s more extensible.

publiclyAvailableInformation - Modeled to describe the resource that contains the media representation of the business event. For example, can describe a file or a URL that represents the resource. This is the description of the different elements describing the resource:

• resourceId (mandatory): The unique identifier of the resource within the event.
• language (optional): Indicates the language of the resource, described using the ISO 639-2/T Code.
• sizeInBytes (optional): Indicates the size of the resource in bytes. Could be used by the end user to estimate the download time and storage needs.
• length (optional): Indicates the length of the product. For example, if the product were a PDF file, the length would be in pages.
• mimeType (mandatory): Indicates the type of media used to store the content. mimeType is used to determine the software product(s) that can read the content. MIME Types are described in RFC 2046.
• name (optional): The name of the resource.
• comments (optional): Any additional comments that are deemed necessary. For example, which software version is required to open the document? Or, how does this resource relate to the others for this event?
• url (optional): Indicates the URL at which the resource can be found.

7.8.2.2 Examples

This is an example of Credit Event Notice document: Credit Event Notice Sample (pdf file)

The following two FpML instance documents are based on this example:

• Credit Event Notice as notification message (xml file)

7.9 Appendix A: Naming differences between FpML 5.7 Credit Derivatives Subschema and 2003 ISDA Credit Derivatives Definitions

There are several places in the FpML 5.7 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.7 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.7 Last Call Working Draft 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.7 Last Call Working Draft 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
    • Averaging
    • Barriers
  • Digital Options
• Option Strategies (multiple simple options)

In addition, support for the following money market instrument is also provided:

• Term Deposits (including features)
  • Money Market Deposits
  • Dual Currency

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.1.1 Settlement Information

An optional settlementInformation structure has been included for each exchanged currency. This can be used in a variety of ways: flagging a trade for standard settlement, flagging a trade for settlement netting, or specifying the detailed settlement instructions for that particular currency flow.

8.2.1.1.1 Settlement Instruction

If the specific settlement instruction is included, then this is broken out into correspondent, intermediary, and beneficiary information. This includes the identification of the routing mechanism (e.g., SWIFT, Fedwire, etc.) that the trade will settle via and the id and account that the trade will settle via. Routing can be handled either via purely a routing id (e.g., SWIFT code), routing details (a customer name, address, and account number), or a combination of routing id and details. The following diagrams show the correspondent, intermediary, and beneficiary structures.

8.2.1.1.1.1 Correspondent Information

8.2.1.1.1.2 Intermediary Information

8.2.1.1.1.3 Beneficiary Information

8.2.1.1.1.4 Beneficiary Bank

8.2.1.1.1.5 Split Settlement

Split settlement is also accommodated. Split settlement will mean that there will be multiple beneficiaries associated with a single trade, where the payment amounts are broken down between beneficiaries. The following diagram shows how this has been modeled:

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.2.3 Non Deliverable Settlement

Non-deliverable settlement is catered for within the conventional FX single leg structure by including an optional non-deliverable information structure that is used to describe a particular type of FX forward transaction that is settled in a single currency (for example, a non-deliverable forward). This content identifies the agreed-upon settlement currency and describes the fixing date and time, as well as the settlement rate source that the fixing will be based upon. The non-deliverable structure is shown below.

If present the fixing element indicates a currency pair that should be observed to obtain the settlement rate for the trade. The details of where the rate should be sourced and when the rating should be performed are defined within the structure.

In FpML 5.5 an alternative structure that allows the definition of fixings from standard rate sources has been added to the schema.

8.2.4 Disruption Events

The disruption section of the FX single leg describes the settlement provisions that come into force if the normal settlement process cannot be carried out due to some unexpected market event.

A disruption section can be defined for each currency pair related to the final settlement as shown in the following diagram. Each section must define one or more provisions which in turn define a set of events and a set of fallbacks. Should any of the events listed inside a provision occur then any of the corresponding fallbacks can be used to try and achieve settlement. By having multiple provision sections it is possible to associate specific fallbacks with specific events if needed.

The elements used to denote events and fallbacks are defined using a substitution group to allow additional definitions to be more easily added either within the FpML schema or in bespoke extensions to it.

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.

FxOption structure now can be used for both 'vanilla', as well as for Averaging and Barriers options that are represented in fxOption as 'features' and not as separate products like in 4.x. (Note: the Barrier structure has been refactored in FpML 5.5 to support the correct definition of simple barrier products, e.g. the concept that a barrier must be crossed in a direction. In making the directional quality of a barrier separate from its in/out quality, we follow the approach taken in the Swift confirmation message format, and the confirmation templates in the 2005 ISDA FX Barrier Options Supplemental Definitions. Taking this approach also has the advantage that it is least disruptive to the existing schema.)

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.1 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.1.1 American Exercise

Fx American Exercise structure has a commencement date, expiry date, cut, latest value date and the ability to describe minimum and maximum currency amounts for multiple exercise. multipleExercise with optional limits on the notional size.

8.5.1.2 European Exercise

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

8.5.2 FX Features

With a vanilla option described, the model then provides optional features which may be used in a one-to-many fashion to add to the option to build up the desired structure.

8.5.2.1 Fx Barrier Feature

The 4.x FX barrier option model extended fx option product with spot rate, fx barrier and trigger payout. As part of the refactoring work, Asian and/or Barrier represented as a new features to the FxOption and not as separate products. An fxOption with barrier features - a conventional option except that it is changed in a predetermined way when the underlying trades at predetermined barrier levels. Foreign exchange barrier features defines the level and the condition for activation. A knock-in option pays nothing at expiry unless at some point in its life the underlying reaches a pre-set barrier and brings the option to life as a standard call or put. A knock-out option is a conventional option until the price of the underlying reaches a pre-set barrier price, in which case it is extinguished and ceases to exist. Barrier options have both a strike price and a barrier price.

The Barrier structure has been refactored in FpML 5.5 to support the correct definition of simple barrier products. The refactored structure provides an additional direction element following the barrierType. This would be an enumeration with values 'Up' and 'Down'. In addition it deprecates the use of the existing enumerable values: 'ReverseKnockin' and 'ReverseKnockout'; only 'Knockin', and 'Knockout' are necessary. In making the directional quality of a barrier separate from its in/out quality, we follow the approach taken in the Swift confirmation message format, and the confirmation templates in the 2005 ISDA FX Barrier Options Supplemental Definitions. Taking this approach also has the advantage that it is least disruptive to the existing schema.

The present observationStartDate and obervationEndDate elements provide the ability to describe, full barrier, forward barrier, partial barrier or window barrier options. In addition to the dates, the MT306 and the ISDA confirmation templates require the specification of the start and end times for a barrier in terms of the business center and time. In order to remain backwardly compatible with the present definitions, in FpML-5-5, the provision of start date times and end date times is added optionally, and if start date and end date are provided, observationStartTime and observationEndTime remain optional.

MT306: An MT306 barrier block will specify the end location and time and is always mandatory. In the case of the start time, the location is mandatory and time is optional. If no time is specified this implies that the barrier starts at the execution date time. The optionality of the start date is a concession to the fact that the exact time of execution is subjective and frequently unrecorded; and certainly should not be a matching field on a confirmation.

				Additional Conditions	:BRUP
				____________________________________________________________
				Barrier Block
				
				Type of Barrier	:SKOT
				Barrier Level	:1.5000000000
				____________________________________________________________
				Barrier Window Block
				
				Start Date	:Aug 11, 2011
				Location and Time	:USNY
				End Date	:Aug 13, 2012
				Location and Time	:USNY 10:00
				____________________________________________________________
				 

ISDA FX Barrier Options Supplemental Definitions 2005:The confirmation templates within the ISDA definitions provide, for example, in the Barrier Option template at Page 10:

				[Event Period Start Date and Time: [ ] at [ ] [a.m./p.m.] (local time in [ ]]23
				Event Period End Date and Time: [ ] at [ ] [a.m./p.m.] (local time in [ ]24]25
				
				23 Because the Trade Date is the most common Event Period Start Date for a Barrier Option Type, Section
				3.9(i) of this Supplement contains a presumption that, unless otherwise specified, the Event Period Start
				Date and Time is the Trade Date at the time the Transaction was entered into. Parties should specify the
				Event Period Start Date and Time if they wish to modify this presumption.
				
				24 Parties should include Event Period End Date and Time if they wish to modify the presumption in Section
				3.9(h) of this Supplement that the Event Period End Date and Time are the Expiration Date at the
				Expiration Time. Nonetheless, for an at-expiration Currency Option Transaction, parties may wish to
				specify that the Event Period End Date and Time are the Expiration Time on the Expiration Date.
				
				25 Event Period Start Date and Time and Event Period End Date and Time may be specified for any Barrier
				

American Barriers are represented using the observationStartXxxx and observationEndXxxx elements.

European Barriers are represented by providing a single observationPoint element, with the date equivalent to the trade expiry date as defined in the fxOption/EuropeanExercise or American Exercise elements, and the time either equivalent to the expiry time, or omitted.

Discrete Barriers are not supported by MT306, but a new structure added in FpML 5.5. will support them. Discrete Barriers would be represented by providing a collection of observationPoint elements, with individual observation times.

barrierType-This specifies whether the option becomes effective ("knock-in") or is annulled ("knock-out") when the respective barrier event occurs. Note: only 'Knockin', and 'Knockout' are necessary; 'ReverseKnockin' and 'ReverseKnockout' are DEPRECATED. direction-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. quotedCurrencyPair-Defines the two currencies for an FX trade and the quotation relationship between the two currencies. triggerRate-The market rate is observed relative to the trigger rate, and if it is found to be on the predefined side of (above or below) the trigger rate, a trigger event is deemed to have occurred. informationSource-The information source where a published or displayed market rate will be obtained, e.g. Telerate Page 3750. observationStartDate-The date on which the observation period for an american barrier starts. If the start date is not present, then the date and time of the start of the period is deemed to be the date and time the transaction was entered into. observationStartTime-The time on the start date at which the observation period for an american barrier starts. If the time is not present and the start date is equivalent to the transaction date, the time is deemed to be the time the transaction was entered into. If the time is not present and the start date is other than the transaction date, then the time is deemed to be the same as the expiration time. observationEndDate-The date on which the observation period for an american barrier ends. If the end date is not present, then the date and time of the end of the period is deemed to be the date and time of expiration. observationEndTime-The time on the end date at which the observation period for an american barrier ends. If the time is not present, then the time is deemed to be the same as the expiration time. observationPoint-The dates and times at which rate observations are made to determine whether a barrier event has occurred for a discrete or european barrier. If the time is not present then the time is deemed to be the same as the expiration time.

The FpML schema envisages that a double barrier product would be described using two of these barrier elements.

The FpML schema provides for the definition of the Barrier Determination Agent. The Barrier Determination Agent is a definition of the contract in a similar way to the Calculation Agent. The 'barrierDeterminationAgent' reference therefore reside as a child of the trade element in a similar way to the Calculation Agent.

The usage is:

				<trade>
				  <tradeHeader>…</tradeHeader>
				  <fxOption>…</fxOption>
				  …
				  <barrierDeterminationAgent href="Party1"/>
				</trade>
				
				<party id="Party1">
				  <partyId>LEI</partyId>
				  <!-- Other Party Information -->
				</party>
				

8.5.2.2 Fx Asian Feature

Foreign exchange asian features - (sometimes referred to as asian or average rate) captures the parameters for the average rate calculation. FxOption with asian feature is an option whose payout is based upon the average of the price of the underlying, typically (but not necessarily) over the life of the option. These options are popular because they are usually cheaper than conventional options because the averaging process over time reduces volatility.

FxAsianFeature includes a FX rateObservation component, a collection of specific observation dates, accompanied by a specific weighting factor and average rate options on occasion when struck already have agreed-upon rate observations in the past. FX rateObservation can be produced either as an independent representation of a series of specific observation dates, or to supplement the parametric representation of the observationSchedule (e.g., daily, 2nd Friday, etc.), utilizing the same rolling convention schemes as utilized within the interest rate derivatives area. The model is constructed as an “at-least-one-of” model which enforces the existence of observationSchedule, or rateObservation, or both. Below are the structures for an FX OTC asian feature.

The rateObservation collection is optionally accompanied by a rateObservationQuoteBasis, allowing this to be made explicit.

The following diagram shows a graphical view of a collection of specific observation dates, accompanied by a specific weighting factor and average rate options:

Where the observation schedule is represented parametrically, the rateObservation series may be absent, or limited to observations which have already occurred – but now the observed rate values are accompanied by their weighting factor:

A combination of an average rate and one or more barrier are supported.

8.5.3 Premium

8.5.4 Cash Settlement

The cash Settlement component specifies the currency and fixing details for cash settlement. It has the identical underlying type that is also used within FX Single leg and FX Swap products (see section 8.2.3.). This cash Settlement optional structure is produced only where it has been specified at execution time that the option wlll be settled into a single cash payment - for example, in the case of a non-deliverable option (although note, that an Fx option may be contractually cash settled, without necessarily being non-deliverable). Physical delivery means - entering into a spot transaction for currency delivered on both sides. Cash settlement means - settling into one of the option currency or quanto arrangement, and then supply FX spot rate observation and other parameters in the cash settlement block.

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.6.1 Option Style

The schema provides for a choice between Digital with American Exercise, as a grouped pair of elements of American exercise and a touch element. Digital with European Exercise, as a grouped pair of elements of European exercise and a trigger element.

American Barriers is represented using the observationStartXxx and observationEndXxx elements.

Discrete Barriers are not supported by MT306, but a new structure added in FpML 5.5. will support them. Discrete Barriers would be represented by providing a collection of observationPoint elements, with individual observation times.

European Barriers is represented using the grouping of the europeanExercise and trigger elements. In the case of a European Barrier, there is no need to specify a datepoint for the barrier, because it is intrinsically the same as the expiry date, which would be specified in the European Exercise block accompanying the trigger block.

8.6.1.1 American Exercise and American Barrier/ Discrete Barrier

Binary options, on the other hand, are more like American options (but with out multipleExercise element), meaning that the payout occurs if the spot rate trades through the trigger level at any time up to and including the expiry date. The four examples that have been included in the specification are the one-touch, no-touch, double one-touch, and double no-touch binary options.

8.6.1.1.1 American Exercise

commencementDate-The earliest date on which the option can be exercised.The earliest date on which the option can be exercised. expiryDate-The latest date on which the option can be exercised.The latest date on which the option can be exercised. expiryTime-Time at which the option expires on the expiry date.Time at which the option expires on the expiry date. cutName-The code by which the expiry time is known in the market.The code by which the expiry time is known in the market. latestValueDate-The latest date on which both currencies traded will settle.The latest date on which both currencies traded will settle.

8.6.1.1.2 American Barrier/ Discrete Barrier

The option may have one to many touch elements of type 'FxTouch' to describe the triggers.

Touch and no Touch Binary options have the concept that the trigger must be touched in a direction. That is, that the barrier is triggered if spot is at or above the barrier level or at or below the barrier level. In the MT306 format, the trigger direction is specified in Field 77D with values TRDN, TRUP. In line with the proposal for barrier options, the 'FxTouch' structure has been refactored in FpML 5.5 to define the trigger 'direction'. This segregates the 'touch'/'no touch' ('touchCondition') condition from the 'above'/'below' ('direction') condition. The 'direction' is of type 'TriggerConditionEnum'. This type is reused from the case of the European Digital, where the same definitions apply. This type's present the enumerated values 'Above' and 'Below' are deprecated in favour of the more precise new values 'AtOrAbove' and 'AtOrBelow'.

Mirroring the changes for Barrier Options, in FpML-5-5, the provision of start date times and end date times is added optionally, and if start date and end date are provided, observationStartTime and observationEndTime remain optional.

MT306:

						The Swift MT306 protocol does not support binary options with window barriers as there is no Trigger Window Block equivalent to the Barrier Window Block.
						

ISDA FX Barrier Options Supplemental Definitions 2005 (The confirmation templates within the ISDA definitions provide, for example, in the Binary Option template at Page 14 and 15):

						[Event Period Start Date and Time: [ ] at [ ] [a.m./p.m.] (local time in [ ]]16
						Event Period End Date and Time: [ ] at [ ] [a.m./p.m.] (local time in [ ]17]18
						
						16 Because the Trade Date is the most common Event Period Start Date for a Binary Option Type, Section
						3.9(i) of this Supplement contains a presumption that, unless otherwise specified, the Event Period Start
						Date and Time is the Trade Date at the time that the Transaction was entered into. Parties should specify
						the Event Period Start Date and Time if they wish to modify this presumption.
						
						17 Parties should include Event Period End Date and Time if they wish to modify the presumption in Section
						3.9(h) of this Supplement that the Event Period End Date and Time are the Expiration Date at the
						Expiration Time. Nonetheless, for an at-expiration Binary Option Type, parties may wish to specify that
						the Event Period End Date and Time are the Expiration Time on the Expiration Date.
						
						18 Event Period Start Date and Time and Event Period End Date and Time may be specified for any Binary
						Option Type, but they are more commonly used to define “Window Event Periods.”
						

touchCondition-This specifies whether the applied trigger is a touch or no touch type. direction-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. DEPRECATE: Values "Above" and "Below" are deprecated. quotedCurrencyPair-Defines the two currencies for an FX trade and the quotation relationship between the two currencies. triggerRate-The market rate is observed relative to the trigger rate, and if it is found to be on the predefined side of (above or below) the trigger rate, a barrier event is deemed to have occurred. spotRate-An optional element used for FX forwards and certain types of FX OTC options. For deals consumated in the FX Forwards Market, this represents the current market rate for a particular currency pair. For barrier and digital/binary options, it can be useful to include the spot rate at the time the option was executed to make it easier to know whether the market rate needs to move "up" or "down" to trigger a barrier event. informationSource-The information source where a published or displayed market rate will be obtained, e.g. Telerate Page 3750. observationStartDate-The date on which the observation period for an american trigger starts. If the start date is not present, then the date and time of the start of the period is deemed to be the date and time the transaction was entered into. observationStartTime-The time on the start date at which the observation period for an american trigger starts. If the time is not present and the start date is equivalent to the transaction date, the time is deemed to be the time the transaction was entered into. If the time is not present and the start date is other than the transaction date, then the time is deemed to be the same as the expiration time. observationEndDate-The date on which the observation period for an american trigger ends. If the end date is not present, then the date and time of the end of the period is deemed to be the date and time of expiration. observationEndTime-The time on the end date at which the observation period for an american trigger ends. If the time is not present, then the time is deemed to be the same as the expiration time.

8.6.1.2 European Exercise and European Barrier

Fx digital option model uses grammar to ensure triggers match the exercise style.

8.6.1.2.1 European Exercise

Digital options typically are defined as being European, meaning the observation occurs only if the spot rate trades above (or below) the trigger level on expiry date. The two examples that have been included in the specification are the digital and the range digital.

8.6.1.2.2 European Barrier

These 'trigger' structure allows to describe a simple European style digital option with one or more trigger levels. At least one 'trigger' element is mandatory and describes the nature of the trigger, the underlying, the trigger level and the rate source.

The 'triggerCondition' is of type TriggerConditionEnum. This type is reusable in the case of the American Digital, where the same definitions apply. Note, the enumerated values 'Above' and 'Below' are deprecated in favour of the more precise new values 'AtOrAbove' and 'AtOrBelow'.

triggerCondition-The condition that applies to a european trigger applied to an FX digital option. It determines where the rate at expiry date and time at must be relative to the triggerRate for the option to be exercisable. The allowed values are "AtOrAbove" and "AtOrBelow". DEPRECATE: Values "Above" and "Below" are deprecated. quotedCurrencyPair-Defines the two currencies for an FX trade and the quotation relationship between the two currencies. Note, the 'quotedCurrencyPair' element provides the ability to describe the underlying. The association of an underlying with each trigger; implies that there may be multiple underlyings. This is not a feature of basic digitals; however this is not something that we see any need to change as it would be required to support more complex digitals. triggerRate-The market rate is observed relative to the trigger rate, and if it is found to be on the predefined side of (above or below) the trigger rate, a barrier event is deemed to have occurred. spotRate-An optional element used for FX forwards and certain types of FX OTC options. For deals consumated in the FX Forwards Market, this represents the current market rate for a particular currency pair. For barrier and digital/binary options, it can be useful to include the spot rate at the time the option was executed to make it easier to know whether the market rate needs to move "up" or "down" to trigger a barrier event. Note, that in the standard confirmation process, the spot level is not a confirmed value. informationSource-The information source where a published or displayed market rate will be obtained, e.g. Telerate Page 3750.

8.6.2 Fx Option Payout

The payout element provides for a payout in 'Currency1' or 'Currency2'. The payout is specified as a precise amount and currency, which allows for digital options which pay out at less than 100% of the nominal.

currency-The currency in which an amount is denominated. amount-The non negative monetary quantity in currency units.The non negative monetary quantity in currency units. payoutStyle-The trigger event and payout may be asynchonous. A payout may become due on the trigger event, or the payout may (by agreeement at initiation) be deferred (for example) to the maturity date.The trigger event and payout may be asynchonous. A payout may become due on the trigger event, or the payout may (by agreeement at initiation) be deferred (for example) to the maturity date. settlementInformation-The information required to settle a currency payment that results from a trade.The information required to settle a currency payment that results from a trade.

8.6.2.1 Fx Option Payout Style

FX Option payoutStyle is an enumeration:

• 'Deferred' - If the trigger is hit, the option payout will not be paid now but will be paid on the value date of the original option.
• 'Immediate' - If the trigger is hit, the option payout will be paid immediately (i.e., spot from the payout date).

8.7 Term Deposit

The term deposit is an agreement between two parties to enter into a financial contract. Similar to a forward rate agreement, a term deposit is contained within a single component and contains no interim interest payments. It is an on-balance sheet transaction that pays interest at maturity based upon an agreed interest rate. While the term deposit instrument is technically an interest rate product, it is included within the FX section of FpML because many institutions that utilize FX transactions also conduct short-term deposits in their respective portfolios to fund foreign currency requirements.

Although there are a number of structured deposits that are occasionally transacted in the marketplace, including deposits with amortizing structure, rate set schedules, and periodic interest payment or interest recapitalization schedules, or even deposits that are denominated in one currency but pay interest in another currency, those types of transactions represent a significant minority of the number of deposits dealt in the wholesale financial marketplace. Therefore, the term deposit structure is intentionally very simple to accommodate the simple yet highly liquid deposit instruments.

The fixed interest rate + the foreign exchange option that can provide a higher rate of return become increasingly popular. These products are confirmed as a single trade which combines deposit and option data attributes. In FpML 5.1, a dual currency option has been modeled as a ‘feature’ that is embedded into a term deposit that causes the payout to be in a second currency.

Note that both the start date and maturity date of the term deposit is negotiated upfront and are typically of short duration, so the dates of these instruments are fixed. Any unforeseen holidays will generally cause for renegotiation of the contract. Therefore there are no allowances for date adjustments.

8.7.1 Term Deposit Features

The variants of main Term Deposit product are represented in the redesigned model as term deposit features (e.g. Dual Currency feature). There are other variants that could be added (e.g. deposit taker can decided interest and principal payment currency).

Dual Currency Term Deposits is a term deposit with an embedded option that causes the payout to be in a second currency. The fixed interest rate + the foreign exchange option can provide a higher rate of return. These products are confirmed as a single trade which combines deposit and option data attributes which has been modeled as a ' features' that can be added to a term deposit. Element ‘ dualCurrency' of type 'DualCurrencyFeature' represents Dual Currency Deposit using the 'termDeposit' product's 'features', instead of the 'strategy' like in 4.x model ( [termDeposit] and [fxSimpleOption] products).

8.8 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 Equity Derivative Options and Forwards Scope

The EQD Products Working Group has extended the FpML standard to cover the following Equity Derivative products

• Broker Equity Options;
• Long Form Equity Forwards;
• Long Form Equity Options;
• Short Form Equity Options represented as Transaction Supplements under ISDA Master Confirmation Agreements.

9.2 Overall Architecture

In FpML version 3.0 the equityOption component was defined to describe "vanilla" options with the following characteristics:

• put and call options;
• with American or European exercise styles;
• on single stocks or indices; and
• delivery being either cash or physical stock.

FpML 4.0 extended this component to encompass more exotic types of options, including:

• Bermudan exercise style;
• basket underlyings;
• forward starts;
• quantos and composites;
• averaging; and
• barriers, knock-ins, knock-outs and binary (digital) options.

FpML 4.1 introduced additional components for both "short form" transacation supplement and broker equity option representations, and a "long form" Equity Forward. All long and short form instances are derived by extension from long and short form base types:

• brokerEquityOption
• equityForward
• equityOption
• equityOptionTransactionSupplement

these components provide support for:

• Broker Equity Options;
• Long Form Equity Forwards;
• Long Form Equity Options;
• Short Form Equity Options represented as Transaction Supplements under ISDA Master Agreements.

Many of the above can be combined through the use of a single component architecture that has a number of optional features. Compound options (such as Butterfly and Straddle structures) can be represented by combining two or more equityOption components in a Strategy component. Simple strike or calendar spread strategies can be represented using the Strategy Feature component.

Through a combination of derivation by extension, and composing the available features, the vast majority of equity option structures that are used between wholesale market counterparties can be represented in FpML.

The product architecture draws directly on ISDA's 1996 and 2002 definitions for equity derivatives. Wherever possible the terminology and practice of the ISDA definitions has been adopted to ensure consistency between traditional and FpML contract representations.

9.2.1 brokerEquityOption

brokerEquityOption component implements the work of the ISDA Broker Standardization Subgroup by providing a short form representation suitable for use in broker confirmations. Support for the simple strategies Strike Spread and Calendar Spread is provided by strategyFeature.

9.2.2 equityForward

equityForward component implements ISDA 2002 Equity Derivative Long Form Forward.

9.2.3 equityOption

In the equityOption component buyerPartyReference and sellerPartyReference are pointer style references to Party components that specify the option buyer and seller respectively. The type of the option (call or put) is specified in optionType. The effective date for a forward starting option is specified in equityEffectiveDate

9.2.4 equityOptionTransactionSupplement

equityOptionTransactionSupplement implements Equity Derivative Transaction Supplements by providing a short form representation for use in trades governed by a Master Confirmation Agreement.

The underlyer of an equity option may be either a single underlyer, or basket, specified using the underlyer component specified below

The strike is expressed either as a price (strikePrice) or as a percentage ( strikePercentage) of the forward starting spot price. An optional Currency element caters for the case where the strike price is expressed as a monetary amount, rather than as a level.

The numberOfOptions element specifies the number of options in the option transaction. The optionEntitlement element specifies the number of shares per option. The number of options, strike price and notional are linked by the equation:

notional amount = number of options x option entitlement x strike price

Provided that two of notional amount, number of options and option entitlement are specified, then the third may be omitted.

spotPrice is the price per share, index or basket observed on the trade or effective date. It is only used for forward starting options.

The exercise provisions for the option are specified in the equityAmericanExercise, equityEuropeanExercise, and equityBermudaExercise style components. The equity exercise components are described in more detail below.

Quanto and Composite options are handled using the FxFeature Component.

Where necessary many other non-vanilla features are specified in the optional feature component. This component is described in more detail below.

The EquityPremium component specifies the amount and timing of the premium payment that is made for the equity option. It is described in more detail below.

Where the underlying is shares; the ExtraordinaryEvents component specifies marketevents affecting the issuer of those shares that may require the terms of the transaction to be adjusted. The methodOfAdjustmentEnum component specifies how adjustments will be made to the contract should one or more of the extraordinary events occur.

9.3 Component Descriptions

9.3.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 description element is used to provide a free-form text description of the asset, whereas 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.3.2 Equity Exercise

FpML supports three styles of equity option: European, American and Bermudan. For consistency of representation with interest rate derivatives each of these styles is represented using its own component. Each of these components is described more fully below. The automaticExercise element contains a boolean value. If true then each option not previously exercised will be deemed to be exercised at the expiration time on the expiration date without service of notice unless the buyer notifies the seller that it no longer wishes this to occur. 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 futuresPriceValuation element contains a boolean value to indicate whether or not the official settlement price as announced by the related exchange is applicable, in accordance with the ISDA 2002 definitions. The optionsPriceValuation element contains a boolean value to indicate whether or not the the official settlement price as announced by the related exchange is applicable, in accordance with the ISDA 2002 definitions. 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 settlementPriceSource element specifies the source from which the settlement price is to be obtained, e.g. a Reuters page, Prezzo di Riferimento, etc. The settlementType element shows how the transaction is to be settled when it is exercised. The values comes from list: Cash, Election, Physical.

9.3.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.3.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 equityMultipleExercise component). The option may be exercised on any business day in this period up to the latest time 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.3.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.3.3 Features

A group containing Swap and Derivative features.

9.3.3.1 Equity Option Feature

equityOptionFeatures has been re-named equityFeatures (type OptionFeatures). As part of SOTF remodeling work, equity option feature' s content is accessible in the Feature.model through the complex type OptionFeatures. Four types of option features are catered for: asians, barriers, knocks, and pass through payments. All of these are path-dependent options. Asian features are described below. Barriers may be caps or floors; knocks may be knock-ins or knock-outs - these share a common architecture that is described below. A binary option (also known as a digital option) is a special case of a barrier where the payout is specified to be a fixed amount rather than a percentage of the value of the underlying on the date that the option is triggered.

9.3.3.1.1 asian

An asian option is one in which an average price is used to derive the strike price ("averaging in") or the expiration price ("averaging out") or both. The type of averaging is specified in the averagingInOut element. The period over which the averaging is calculated is specified in the component averagingPeriodIn or averagingPeriodOut as appropriate. Both components have the same structure. The period is specified either as a calculation, using one or more schedule components (which permits specifications such as every Friday from and including 24 May 2002 to and including 22 November 2002), and/or as a list of explicit dates and times, using the averagingDateTimes component. It is permissible to use the list of dates and times to specify averaging points that are additional to those derived from the calculation rule specified in schedule components. In the event that any of the dates is not a business day then it is assumed that it will be rolled forward to the next business day in accordance with ISDA convention. The marketDisruption element specifies the action to be taken if it is not possible to obtain a price on one of the days used for averaging.

9.3.3.1.2 Barrier and Knock

A barrier option is one in which, if the option expires in the money, an additional payment will occur. With a barrier cap the additional payment will be made if the trigger level is approached from below, whereas with a barrier floor the additional payment will be made if the trigger level is approached from above. Knock options are of two types. A knock-in option does not come into effect until the trigger level has been reached, if it is never reached then the option expires worthless. Conversely, a knock-out option expires immediately the trigger level is reached.

A common structure is used to specify barrier caps, barrier floor, knock-ins and knock-outs. The diagram shows the barrierCap structure. The dates on which the underlying is valued to test for the occurrence of the trigger event are either expressed in one or more schedule components and/or as a list of explicit dates, using the triggerDates component. It is permissible to use the list of dates to specify trigger dates that are additional to those derived from the calculation rule specified in schedule components. In the event that any of the dates is not a business day then it is assumed that it will be rolled forward to the next business day in accordance with ISDA convention. The trigger component specifies that the trigger event either as a level or as a levelPercentage (of the strike). The optional featurePayment component specifies a payment to be made if the trigger event occurs. The payment date can be expressed either as an explicit date or as relative to some other date, such as the trigger date or the contractual expiry date.

9.3.3.1.3 Pass Through

This structure supports pass through payments from underlyers, such as dividend payments from equity underlyers. The structure is designed to support single options and baskets of options.

Example of pass through feature in a basket

		
	<passThrough>
	  <passThroughItem>
	    <payerPartyReference href="PartyA"/>
		  <receiverPartyReference href="PartyB"/>
		  <underlyerReference href="AholdEquity"/>
		  <passThroughPercentage>0.80</passThroughPercentage>
	  </passThroughItem>
	  <passThroughItem>
	    <payerPartyReference href="PartyA"/>
		<receiverPartyReference href="PartyB"/>
		<underlyerReference href="RoyalDutchEquity"/>
		<passThroughPercentage>1.20</passThroughPercentage>
	  </passThroughItem>
	</passThrough>
		

9.3.3.1.3.1 Alternate Approaches

This feature was also considered as a fully formed hybrid product, which could be characterised as a combination of an equity option, however the consensus opinion was that pass through was a simple feature, which could be added to the existing option feature block.

9.3.3.1.4 Dividend Adjustment

Container for Dividend Adjustment Periods, which are used to calculate the Deviation between Expected Dividend and Actual Dividend in that Period.

9.3.3.2 Fx Feature

FxFeature specifies the reference currency, either a Composite or Quanto feature: Composite- where multiple currencies can be involved. An option is struck on a foreign underlying at a value of the underlying in the investor's base currency. The payout is based on the investor's base currency at exercise. Quanto - where two currencies are involved. To adjust the investor's base currency protection on an underlying position which varies in value in the non-base currency.

9.3.3.3 Strategy Feature

A type for definining equity option simple StrikeSpread or CalendarSpread strategy features.

9.3.4 Equity Premium

The EquityPremium component specifies the amount and timing of the premium payment that is made for the equity option. payerPartyReference and receiverPartyReference are pointer style references to 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.3.5 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).
• Swaps that have specific adjustment conditions, such as execution swaps or portfolio rebalancing swaps;
• Swaps that involve the exchange of principal cashflows;
• Swaps that have inital and final stubs;
• Swaps which can be represented as Transaction Supplements under ISDA Master Agreements;

Extraordinary Events terms have been incorporated, to take into consideration the release of the 2002 ISDA Definitions for Equity Derivatives.

Trigger swaps, in which equity risk morphs into a fixed income risk once a certain market level is reached, may be supported in a subsequent release.

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: Return-type Swaps have 1-to-many Legs, all of which must be derived from the ReturnSwapLeg type. Instances of Legs are returnLeg (old equityLeg), 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. The possibility is provided for having swaps that do not have an interest leg (case of an outperformance swap where 2 equity underlyers are swapped, or a fully-funded swap where there is no financing component); 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 identification of the payer and receiver party for this leg; 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 payer and receiver party

The identification of the payer and receiver party of the equity leg is done similarly to the other types of swaps, through the payerPartyReference and the receiverPartyReference data elements.

10.3.1.2 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.3 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.3.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.3.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.3.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.3.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.3.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.3.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.3.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.

Figure 12: The single underlyer.

The basket component is to be applied in the case where there are several underlyers, which are then specifically described through the basketConstituent component. This basket component is structured as follows: an identification of the number of basket units (typically, one) and a description of each of the basket constituents (through a one-to-many relationship).

Figure 13: The basket.

The structure that describes the basket is quite more complex than the one that specifies the single underlyer. Besides defining the number of basket units (typically, one), the structure specifies each of the basket constituents through an asset description, a constituent weight, a dividend payout ratio, a price and a notional description. The underlyingAsset component having been already described, the points below focus on the four latter components:

• The constituentWeight specifies the number of units of each of the basket constituents and, optionally, their respective weight in the basket. It is an optional component, considering that some more exotic types of equity swaps do not have a relative weight associated with each their underlyer components.
• The dividendPayout ratio has been associated with the description of the underlyer rather than included in the definition of the return component in order to address the case where a different payout ratio is be associated with the respective components of a basket swap.
• The underlyerPrice component describes the price of each of the basket components; it is optional in order to take into consideration the cases where the market participants do not specify the breakdown by underlyer of the price that is defined at the leg level (which, in the case of a basket swap, corresponds to the notional of the equity leg of the swap). Its structure is based upon the Price complex type, which provides a great flexibility in the way the price of an asset can be defined. This price structure is described in more details through the later developments that are devoted to the valuation component.
• The underlyerNotional is also an optional component; it provides the possibility to break down by underlyer the notional for the equity leg, which can be particularly useful when several currencies are used across the various underlyers.

As an illustration of this structure of the basket component and an introduction to the upcoming developments that are devoted to the valuation, the example below presents the case of a basket swap which underlyers components are listed in various currencies.

Example 2 - Basket swap with underlyers listed in different currencies:

• The basket is comprised of one underlyer that is listed in EUR (TIM.MI) and one that is listed in GBP (VOD.L);
• The reference currency of the swap is USD (this information is carried through the equityAmount component, which is not indicated here);
• Each of the two basketConstituent structures carry the information about both its local price and its price after conversion in USD;
• The information about the currency conversion rates is specified through the valuation component (that is not depicted below), as this information is not specific to the underlyer;
• The initial price of the swap is USD 7,376,406. This corresponds to the multiplication of each of the underlyer prices by its respective quantity, after conversion in USD: 4.182*783,000 [TIM.MI ]+ 165*24,860 [VOD.L]. It also corresponds to the initial notional of the equity swap. This initial price is not depicted here, as it is part of the valuation component of the equity leg.

 <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.4 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.

The diagrams 15 and 16 below present the two sets of structures that are used for specifying these various cases: one (mandatory) structure that specifies the price and one (optional) structure that specifies the dates.

Figure 15: The initialPrice component of the valuation, with a specific focus on the part of the structure that specifies the price.

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>
			          

Example 4 - Specification of an initial price as an actual price that also includes commissions and FX terms:

• Basket swap, which price at the leg level corresponds to the multiplication of the respective prices and quantities of the various underlyer components, i.e. to the notional of the swap;
• Gross amount: 113,228,777 CAD;
• Net amount: 84,089,141 USD;
• Commission: 5 basis points
• Exchange rate: 1 USD = 1.34665 CAD
• 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>
	  <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 5 - 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>
			

Figure 16: The initialPrice component of the valuation, with a specific focus on the part of the structure that specifies the date and time of the initial valuation.

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.

Figure 17: The valuationPriceInterim component of the valuation, with a specific focus on the part of the structure that specifies the price.

Figure 18: The valuationPriceInterim component of the valuation, with a specific focus on the part of the structure that specifies the dates.

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.

Figure 19: The valuationPriceFinal component of the valuation, with a specific focus on the part of the structure that specifies the price.

Figure 20: The valuationRules component of the valuation, with a specific focus on the part of the structure that specifies the final valuation date.

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.

Figure 21: The paymentDates (old equityPaymentDate) component, that specifies the schedule of payment dates.

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.5 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;

Figure 22: The notional component.

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.6 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 23: 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.

Figure 24: The calculationDates component, that provides the opportunity to define calculation dates for more exotic types of equity swaps.

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.7 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.)

Figure 25: The return component.

This return component has two sets of element: 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, and the dividendConditions component, which describes the various conditions applicable to the dividend, including whether and how interests will be accrued if they are paid after the dividend pay date.

This second component is optional, as it does not apply in the case of a price return swap. Its dividend terms are the following:

The dividendReinvestment, as a Boolean data element that determines whether the dividend will be reinvested into the equity notional; The dividendEntitlement, to indicate when the counterparty is entitled to the dividend; The dividendAmount, to refer to one on the 3 Amounts: RecordAmount, ExAmount, PaidAmount; The dividendPaymentDate, to specify when the dividend will be paid. This date can be specified either through a set of pre-defined values that are associated with the dividendDateReference element that is part of this component, or as a specific date. These pre-defined values can refer either to dividend dates (ExDate, DividendPaymentDate, RecordDate) or to dates that relate to the swap contract (TerminationDate, EquityPaymentDate, FollowingPaymentDate); The dividendPeriodEffectiveDate and the dividendPeriodEndDate, to indicate when the swap is considered as active from the perspective of dividend processing and when such period ends; The extraOrdinaryDividends, to reference the party which determines if dividends are extraordinary in relation to normal levels; The excessDividendAmount, to determine Gross Cash Dividend per Share; The CurrencyAndDeterminationMethod.model, a choice between currency, determinationMethod and currencyReferenceto, to define return swap amount currency definition methods; The dividendFxTriggerDate, to specify the date on which the FX rate will be considered in the case of a Composite FX swap; The interestAccrualsMethod, to define how interests will be accrued on the dividend when this latter is paid some period of time after the dividend payment date. The numberOfIndexUnits, to define the Number Of Index Units applicable to a Dividend; The DeclaredCashAndCashEquivalentDividendPercentage.model, to declared Cash Dividend Percentage, or Cash Equivalent Dividend Percentage; The nonCashDividendTreatment, to define treatment of Non-Cash Dividends; The dividendComposition, to defines how the composition of Dividends is to be determined; The specialDividends, to specify the method according to which special dividends are determined.;

10.3.1.8 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.1.9 The FX Feature (old FX terms)

Equity Derivatives and Equity Swaps both now use a common FxFeature component

The fxFeature is an optional component that specifies the FX conversion terms that can be associated with the swap. This FX feature can either be Quanto or Composite FX. Both these components include a referenceCurrency element, which purpose is to explicitly state the reference currency of the swap.

Figure 26: The quanto component. The quanto component includes an explicit reference to a rate, through the fxRate element. One or several rates can be defined, in order to address the case where a basket swap is composed of several underlyers that are listed in different currencies.

The example below illustrates the application of this quanto component:

Example 15 - The quanto component:

• The business background for this trade is that the payment currency of the swap is USD, while some of the underlyers are listed in EUR and some others are listed in HKD. The payer of the equity return commits upfront to a set of exchange rates vis-a-vis the USD which are specified as part of the quanto component;
• The EUR is quoted per units of USD and the exchange rate is 0.99140;
• The HKD is also quoted per units of USD and the exchange rate is 7.80.

	<fxFeature>
	  <quanto>
	    <referenceCurrency id="ReferenceCurrency">USD</referenceCurrency>
	    <fxRate>
	      <quotedCurrencyPair>
	        <currency1>USD</currency1>
	        <currency2>EUR</currency2>
	        <quoteBasis>Currency2PerCurrency1</quoteBasis>
	      </quotedCurrencyPair>
	      <rate>0.99140</rate>
	    </fxRate>
	    <fxRate>
	      <quotedCurrencyPair>
	        <currency1>USD</currency1>
	        <currency2>HKD</currency2>
	        <quoteBasis>Currency2PerCurrency1</quoteBasis>
	      </quotedCurrencyPair>
	      <rate>7.80</rate>
	    </fxRate>
	  </quanto>
	</fxFeature>
	                        

Figure 27: The FX composite component. The FX composite component provides the framework for defining a currency rate at some point in the future. This can be done either by: defining a generic method using the determinationMethod component (for example, when it is agreed that the exchange rate will be determined "in good faith by the Calculation Agent"); specifying a relativeDate specifying fxSpotRateSource (the information source and fixing time and date reference that will be used for defining this exchange rate, using the fx determination component).

The example below illustrates the application of this compositeFx component:

Example 16 - The composite component:

• The payment currency of the swap is EUR;
• The exchange rate will be determined in good faith by the Calculation Agent.

	<fxFeature>
	  <compositeFx>
	    <referenceCurrency id="ReferenceCurrency">USD</referenceCurrency>
	    <determinationMethod>CalculationAgent</determinationMethod>
	  </compositeFx>
	</fxFeature>
	                        

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 payer and the receiver party (represented by PayerReceiver.model);
• 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);
• The initial and final stubs (represented by stubCalculationPeriod component).

Figure 28: The interestLeg of the returnSwap.

10.3.2.1 The payer and receiver party

The identification of the payer and receiver party of the equity leg is done similarly than for the equity leg of the swap, through the PayerReceiver.model.

10.3.2.2 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.

Figure 29: The interestLegCalculationPeriodDates component.

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.3 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.4 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.5 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 30: 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 initial and final stub

The representation of the stub periods for the equity swaps schema makes use of the Stub type that was initially developed for the interest rates schema.

The initialStub and the finalStub components respectively describe the initial and final stubs. For each of those, the component specifies the rate (or stub amount), the stub start date and the stub end date. The payment dates that relate to the stub period(s) are specified along with the payment dates of the main period, in the interestLegCalculationPeriodDates component.

10.3.4 The principal exchange

Some types of equity swaps do not have an interest leg. Their economic structure relies instead in the exchange of the principal of the swap between the parties. These are the fully funded and zero-strike swaps. The purpose of the principalExchangeFeatures component is to specify this feature that is associated with those swaps. (It should however be noted that the schema also accommodates some more exotic cases that would combine an interest leg which notional would be smaller than the notional of the equity leg, and that would also have a principal exchange.)

Figure 31: The exchange of principal exchange feature.

This component extends the design developed for the interest rate swaps (through the principalExchanges component) by adding the principalExchangeDescriptions component, which has the following features:

Figure 32: The exchange of principal exchanges component.

Figure 33: The exchange of principal exchange descriptions component.

• It specifies the payer and receiver party references specified by PayerReceiver.model;
• The each principalExchangeDate can be defined either as an actual date (using the adjustableDate component) or in relation to a date defined somewhere else in the document (via the relativeDate component);
• The principalExchangeAmount can be defined in three possible ways: (i) By pointing to an amount defined elsewhere in the swap document, through the use of the amountRelativeTo element; (ii) By using the determinationMethod element, that describes a method according to which an amount is determined; (iii) By using the principalAmount component, which allows to explicitly determine an actual amount.

Example 20 - Initial principal exchange:

• The principal exchange takes place at the initial period of the swap;
• The payment date is defined as being the effective date of the swap;
• The amount paid to Party A is USD 55,911.60.

	<principalExchangeFeatures>
	  <principalExchanges>
	    <initialExchange>true</initialExchange>
	    <finalExchange>false</finalExchange>
	    <intermediateExchange>false</intermediateExchange>
	  </principalExchanges>
	  <principalExchangeDescriptions>
	    <payerPartyReference href="PartyB"/>
	    <receiverPartyReference href="PartyA"/>
	    <principalExchangeAmount>
	      <principalAmount>
	        <currency>USD</currency>
	        <amount>55911.60</amount>
	      </principalAmount>
	    </principalExchangeAmount>
	    <principalExchangeDate>
	      <relativeDate>
	        <periodMultiplier>0</periodMultiplier>
	        <period>D</period>
	        <businessDayConvention>NotApplicable</businessDayConvention>
	        <dateRelativeTo href="EffectiveDate"/>
	      </relativeDate>
	    </principalExchangeDate>
	  </principalExchangeDescriptions>
	</principalExchangeFeatures>
	                

10.3.5 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.

Figure 32: The additionalPayment component.

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

• The payer and receiver parties are specified similarly to the swap legs and the principal exchange, through the payerPartyReference and receiverPartyReference elements;
• 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.6 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 33: 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.

Example 22 - Each of the parties have the right to early terminate the trade starting on Trade Date:

	<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:

• varianceSwap
• varianceSwapTransactionSupplement
• varianceOptionTransactionSupplement

these components provide support for:

11.2.2 varianceSwap

varianceSwap specifies the structure of a variance swap.

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. varianceLeg - Variance leg. The maximum allowable number of variance legs has been increased to unbounded to allow Variance Dispersion to be supported.

11.2.3 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.4 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.5 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 Dividend Derivatives Scope

The Equity Derivative Working Group extended FpML to cover:

• Dividend Swap Transaction Supplement

12.2 Overall Architecture

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

• dividendSwapTransactionSupplement

12.2.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. 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. dividendLeg - Dividend leg. fixedLeg - Fixed payment leg.

12.2.2 dividendLeg

dividendLeg - Floating Payment Leg of a Dividend Swap.

12.2.3 fixedLeg

fixedLeg - Fixed Payment Leg of a Dividend Swap.

13 CORRELATION PRODUCT ARCHITECTURE

13.1 Correlation Derivatives Scope

The Equity Derivative Working Group extended FpML to cover:

• Correlation Swaps

13.2 Overall Architecture

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

• correlationSwap

13.2.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.2.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.7 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 ExerciseProcedure construct

The extensions to the ExerciseProcedure relate to features that are needed to support the bond and CB options:

• splitTicket. Schema definition: This element typically applies to bond options. If Split Ticket is applicable, the party required to deliver bonds will divide the bonds to be delivered as notifying party desires to facilitate delivery obligations.
• limitedRightToConfirm. Schema definition: Has the meaning defined as part of the 1997 ISDA Government Bond Option Definitions, section 4.5 Limited Right to Confirm Exercise. If present, (i) the Seller may request the Buyer to confirm its intent if not done on or before the expiration time on the Expiration date (ii) specific rules will apply in relation to the settlement mode.

14.2.2.4 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.5 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 provides support for commodity swaps (whether fixed-float and float-float, or weather/weather), traditional commodity options (American, European and Asian) and its variations, as well as basket and digital options . FpML also supports contracts written on physically-settled electricity, natural gas, oil, coal, and environmental commodities. FpML provides support for physically-settled precious and non-precious metal forwards. At the core of the architecture is a representation for a commodity underlyer which is used within the commodity products, as well as, other products such as equity baskets. A representation of gold interest rate swap (official name: Gold Forward Offered Rate) has also been introduced, which is used within the commodity products but that can also be used within other products such as IRS.

For an overview of the commodities coverage in FpML and its linking with the legal documentation see the following document: FpML Commodities Coverage Matrix (pdf file)

15.2 Commodity Underlyer

There are two types of commodity underlyers: single commodity reference prices and the average of two or more commodity reference prices.

15.2.1 Commodity Underlyer -> Commodity Single 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'. commodityDetails-A coding scheme value to identify the commodity being traded more specifically. Where possible, this should follow the naming convention used in the 2005 ISDA Commodity Definitions. For example, 'Brent'. unit-A coding scheme value to identify the unit of measure (e.g. Therms) in which the undelryer is denominated. Where possible, this should follow the naming convention used in the 2005 ISDA Commodity Definitions. Either the 'exchange' or the 'publication' is specified. currency-The currency in which the Commodity Reference Price is published (e.g. GBP). publication-For those commodities being traded with reference to a price distributed by a publication, that publication should be specified in the 'publication' element.

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-No Annotation Available

deliveryDateRollConvention-The 'deliveryDateRollConvention' specifies, for a Commodity Transaction that references a listed future via the 'deliveryDates' element, the day on which the specified future will roll to the next nearby month prior to the expiration of the referenced future. If the future will not roll at all - i.e. the price will be taken from the expiring contract, 0 should be specified here. If the future will roll to the next nearby on the last trading day - i.e. the price will be taken from the next nearby on the last trading day, then 1 should be specified and so on.

multiplier-The 'multiplier' specifies the multiplier associated with the Transaction. The 'multiplier' element has two uses: (1) for Freight Transactions or any Calculation Period specified for a Freight Transaction, if an amount is specified as the Multiplier then it is captured by this element and (2) if the Transaction is a heat rate option, the heat rate multiplier is represented in this element. If multiplier is not provided, multiplier is assumed to be 1. (i.e. rate source states 1 BBL of Oil as 90 Dollars. Multiplier of 10 will change the value to 900 dollars.)

15.2.2 Commodity Underlyer -> Commodity Basket Underlyer

CommodityBasket-Describes the swap's underlyer when it has multiple asset components.

BasketIdentifier.model-A group that specifies a name and an identifier for a given basket. CommodityBasket.model-No Annotation Available

15.2.2.1 Commodity Underlyer -> Commodity Basket Underlyer - BasketIdentifier.model

BasketIdentifier.model-A group that specifies a name and an identifier for a given basket.

basketName-The name of the basket expressed as a free format string. FpML does not define usage rules for this element. basketId-A CDS basket identifier

15.2.2.2 Commodity Underlyer -> Commodity Basket Underlyer - CommodityBasket.model

CommodityBasket.model-No Annotation Available

notionalQuantityBasket-No Annotation Available notionalAmountBasket-No Annotation Available

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 repeating '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 simple commodity swap will contain two legs, typically one fixed and one floating, but the repetition allows more complex multi-legged structures to be represented.

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 commoditySwap - CommodityContent

CommodityContent.model-Items common to all Commodity Transactions.

commonPricing-If Common Pricing is elected (“true”) for a Transaction with referencing more than one Commodity Reference Price then no date will be a Pricing Date unless such a date is a day on which all Commodity Reference Prices are scheduled to be published. marketDisruption-Contains contract terms related to triggers and responses to market disruptions as defined in the 1993 or 2005 Commodity Definitions. settlementDisruption-Describes contract terms related to the consequences of Bullion Settlement Disruption Events. rounding-Rounding direction and precision for amounts.

15.3.3 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. CommodityPaymentDates.model-The different options for specifying the Payment Date. This will consist of either a set of Payment Dates or else a Payment Date schedule. CommodityFreightFlatRate.model-The Flat Rate, applicable to Wet Voyager Charter Freight Swaps.

As with other FpML leg structures the payer and receiver parties are explicitly indicated in the 'payerPartyReference' and 'receiverPartyReference'.

The role of the remaining elements is as follows:

• The 'calculationPeriods' or 'calculationDates' if the Calculation Periods are all one day long or the 'calculationPeriodsSchedule' is only intended to be used if the Calculation Periods differ on each leg. If Calculation Periods mirror another leg, then the 'calculationPeriodsReference' element should be used to point to the Calculation Periods on that leg or 'calculationPeriodsDatesReference' element should be used to point to the single-day-duration Calculation Periods on that leg or the 'calculationPeriodsScheduleReference' can be used to point to the Calculation Periods Schedule for that leg.
• 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.
• On the other hand, if the fixed price varies over the life of the trade, then the 'fixedPriceSchedule' structure is used instead of the 'fixedPrice'. Note that the intention is that a fixed price 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 fixed price schedule to the calculation periods as clearly as possible. The fixed price 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).
• The 'totalPrice' structure specifies the total amount of all fixed payments due during the term of the trade.
• The notional amount is specified stating either the 'notionalQuantity' or if the notional changes over the life of the transaction, then the 'notionalQuantitySchedule' is specified. The 'settlementPeriodsNotionalQuantity' should be specified for an electricity transaction, the Notional Quantity for a one or more groups of Settlement Periods to which the Notional Quantity is based. If the schedule differs for different groups of Settlement Periods, this element should be repeated. 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). If notional amount mirror another leg, then the 'quantityReference' element should be used to point to the Notional Quantity.
• The 'paymentDates' structure supports either the definition of dates as either a series of unadjusted dates along with a date roll convention and business calendar location list for adjustment, or as set of adjusted dates relative to some other date schedule defined elsewhere in the product (e.g. in the floating leg).
• The 'relativePaymentDates' are specified when the payment dates are relative to the calculation periods.
• The Flat Rate, applicable to Wet Voyager Charter Freight Swaps. Whether the Flat Rate is the New Worldwide Tanker Nominal Freight Scale for the Freight Index Route taken at the Trade Date of the transaction or taken on each Pricing Date. The 'flatRateAmount', If 'flatRate' is set to 'Fixed', is the actual value of the Flat Rate.

15.3.4 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. CommodityPaymentDates.model-The different options for specifying the Payment Date. This will consist of either a set of Payment Dates or else a Payment Date schedule. CommodityFreightFlatRate.model-The Flat Rate, applicable to Wet Voyager Charter Freight Swaps.

As with the 'fixedLeg' they parties obligation to pay and receive the payments are explicitly indicated by the 'payerPartyReference' and 'receiverPartyReference' elements.

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.4.1 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. conversionFactor-If the Notional Quantity is specified in units that do not match the units in which the Commodity Reference Price is quoted, the scaling or conversion factor used to convert the Commodity Reference Price units into the Notional Quantity units should be stated here. If there is no conversion, this element is not intended to be used. rounding-Rounding direction and precision for price values. In some trades, there may be a spread-The spread over or under the Commodity Reference Price for this leg of the trade. If the spread is not constant over the life of the trade, spreadSchedule-The spread over or under the Commodity Reference Price for this leg of the trade for each Calculation Period. spreadPercentage-The spread percentage over or under the Commodity Reference Price for this leg of the trade. fx-Defines how observations of FX prices are to be used to calculate a factor with which to convert the observed Commodity Reference Price to the Settlement Currency.

15.3.4.1.1 pricingDates

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

CommodityCalculationPeriodsPointer.model-Model group enables users to reference a Calculation Periods schedule in the form of a series of actual dates in a calculationPeriods container or in the form of a parameterized schedule in a calculationPeriodsSchedule container. lag-The pricing period per calculation period if the pricing days do not wholly fall within the respective calculation period. PricingDays.model-No Annotation Available businessCalendar-Identifies a commodity business day calendar from which the pricing dates will be determined. calendarSource-Used in conjunction with an exchange-based pricing source. Identifies a date source calendar from which the pricing dates and thus roll to the next contract will be based off (e.g. pricing is based on the NYMEX WTI First Nearby Futures Contract, if “Future” is chosen, the pricing will roll to the next futures contract on expiration, if “ListedOption” is chosen, the pricing will roll to the next futures contract on the Option expiration date which is three business days before the expiration of the NYMEX WTI futures contract.) Omitting this element will result in the default behavior expected with the pricing source described within the commodity element. settlementPeriods-Specifies a set of Settlement Periods associated with an Electricity Transaction for delivery on an Applicable Day or for a series of Applicable Days. settlementPeriodsReference-Allows a set of Settlement Periods to reference one already defined elsewhere in the trade structure. pricingDates-A list of adjustable dates on which the trade will price. Each date will price for the Calculation Period within which it falls.

15.3.4.1.2 fx

fx-Defines how observations of FX prices are to be used to calculate a factor with which to convert the observed Commodity Reference Price to the Settlement Currency.

CommodityFx-A type defining the FX observations to be used to convert the observed Commodity Reference Price to the Settlement Currency. The rate source must be specified. Additionally, a time for the spot price to be observed on that source may be specified, or else an averaging schedule for trades priced using an average FX rate. primaryRateSource-The primary source for where the rate observation will occur. Will typically be either a page or a reference bank published rate. secondaryRateSource-An alternative, or secondary, source for where the rate observation will occur. Will typically be either a page or a reference bank published rate. fxType-A type to identify how the FX rate will be applied. This is intended to differentiate between the various methods for applying FX to the floating price such as a daily calculation, or averaging the FX and applying the average at the end of each CalculationPeriod. averagingMethod-The parties may specify a Method of Averaging when averaging of the FX rate is applicable. fixingTime-The time at which the spot currency exchange rate will be observed. It is specified as a time in a specific business center, e.g. 11:00am London time. fxObservationDates-No Annotation Available PricingDays.model-No Annotation Available LagOrReference.model-Allows a Lag or a LagReference to be specified. CommodityCalculationPeriodsPointer.model-Model group enables users to reference a Calculation Periods schedule in the form of a series of actual dates in a calculationPeriods container or in the form of a parameterized schedule in a calculationPeriodsSchedule container.

15.3.5 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. paymentDates-The Payment Dates of the trade relative to the Calculation Periods or Calculation DateThe Payment Dates of the trade relative to the Calculation Periods or Calculation Date 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.5.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.5.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 CalculationPeriodsReference-A pointer style reference to a calculation periods schedule defined elsewhere - note that this schedule consists of a series of actual dates in a calculationPeriods container.

15.3.5.3 weatherLeg - weatherNotionalAmount

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

15.3.5.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. businessDays-A day on which commmercial banks settle payments and are open for general business in the place(s) specified in the Confirmation. See Section 1.3 of the ISDA 2005 Commodity Definitions. dataCorrection-The date payment often revised after its publication, this indicates if the payment date could be recalculated. correctionPeriod-If 'dataCorrection'=true, this indicates how long after the initial publication of the data corrections can be made. 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. rounding-Rounding direction and precision for price values.

15.3.5.5 weatherLeg - paymentDates

CommodityRelativePaymentDates-The Payment Dates of the trade relative to the Calculation Periods.

payRelativeTo-Specifies whether the payment(s) occur relative to a date such as the end of each Calculation Period or the last Pricing Date in each Calculation Period. payRelativeToEvent-Specifies whether the payment(s) occur relative to the date of a physical event such as issuance of a bill of lading. CommodityCalculationPeriodsPointer.model-Model group enables users to reference a Calculation Periods schedule in the form of a series of actual dates in a calculationPeriods container or in the form of a parameterized schedule in a calculationPeriodsSchedule container. paymentDaysOffset-Specifies any offset from the adjusted Calculation Period start date, adjusted Calculation Period end date or Calculation Date applicable to each Payment Date. BusinessCentersOrReference.model-No Annotation Available

15.3.5.6 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. dataProvider-The provider of either temperature data or precipitation data specified by the parties in the related Confirmation. finalEditedData-If specified by the parties to apply in the related Confirmation, Final Edited Data means that the parties will have recourse to Primary Disruption Fallbacks even if relevant data is available from the Data Provider, so long as such data is not published in its final edited form. Otherwise the parties will have recourse to Primary Disruption Fallbacks only if relevant data is unavailable from the Data Provider on a relevant day. weatherStation-The source or sources of weather index data specified by the parties in the related Confirmation. Examples include: AU-CBM (the Commonwealth Bureau of Meteorology in Australia) and CM-SMI (the Swiss Meteorological Institute). weatherStationFallback-If weather index data is not available for the weather station specified by the parties in the related Confirmation, the first alternative Weather Index Station. weatherStationSecondFallback-If weather index data is neither available for the weather station specified by the parties in the related Confirmation nor the first alternative Weather Index Station, the second alternative Weather Index Station. alternativeDataProvider-A provider of either temperature data or precipitation data specified by the parties in the related Confirmation. If the parties fail to specify an Alternative Data Provider, the "Fallback Data" Disruption Fallback will not apply. synopticDataFallback-If the parties specify "Not Applicable", the "Synoptic Data" Disruption Fallback will not apply. Synoptic Data means that maximum and/or minimum temperature or daily precipitation at the location for the Missing Data Day will be the maxium and/or minimum temperature or daily precipitation for that day at the Location (Weather Index Station) which has not been subject to ultimate quality control, integrity or verification process. adjustmentToFallbackWeatherStation-The Weather Index Station from which data with which to apply the "Adjustement to Fallback Station Data" terms. See Section 11.20 of the 2005 ISDA Commodity Definitions. primaryDisruptionFallbacks-A list of actions available to the parties should a Primary Disruption Event occur. A Primary Disruption Event means if maximum or minimum temperature or precipitation data for a Missing Data Day is required to determine a Payment Amount then the maximum and/or minimum temperature or the daily precipitation for that day will be determined in accordance with the first applicable Primary Disruption Fallback. secondaryDisruptionFallbacks-A list of actions available to the parties should a Secondary Disruption Event occur. A Primary Disruption Event means if maximum or minimum temperature or precipitation data for a Missing Data Day is required to determine a Payment Amount then the maximum and/or minimum temperature or the daily precipitation for that day will be determined in accordance with the first applicable Secondary Disruption Fallback.

15.3.6 Physical Leg

15.3.6.1 Coverage

The support for physically-settled commodity swap trades includes,

• Natural Gas
• Oil
• Electricity
• Coal
• Environmental

15.3.6.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.6.2.1 Gas Physical Leg

gasPhysicalLeg

PayerReceiver.model-No Annotation Available deliveryPeriods-The different options for specifying the Delivery or Supply Periods. Unless the quantity or price is to vary periodically during the trade or physical delivery occurs on a periodic basis, periodsSchedule should be used and set to 1T.The different options for specifying the Delivery or Supply Periods. Unless the quantity or price is to vary periodically during the trade or physical delivery occurs on a periodic basis, periodsSchedule should be used and set to 1T. 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.6.2.1.1 gasPhysicalLeg - deliveryPeriods

periods-The Delivery Periods for this leg of the swap. This type is only intended to be used if the Delivery Periods differ from the Calculation Periods on the fixed or floating leg. If DeliveryPeriods mirror another leg, then the calculationPeriodsReference element should be used to point to the Calculation Periods on that leg - or the calculationPeriodsScheduleReference can be used to point to the Calculation Periods Schedule for that leg. periodsSchedule-The Delivery Periods for this leg of the swap. This type is only intended to be used if the Delivery Periods differ from the Calculation Periods on the fixed or floating leg. If DeliveryPeriods mirror another leg, then the calculationPeriodsReference element should be used to point to the Calculation Periods on that leg - or the calculationPeriodsScheduleReference can be used to point to the Calculation Periods Schedule for that leg. CommodityCalculationPeriodsPointer.model-Model group enables users to reference a Calculation Periods schedule in the form of a series of actual dates in a calculationPeriods container or in the form of a parameterized schedule in a calculationPeriodsSchedule container. supplyStartTime-The time at which gas delivery should start on each day of the Delivery Period(s).The time at which gas delivery should start on each day of the Delivery Period(s). supplyEndTime-The time at which gas delivery should end on each day of the Delivery Period(s).The time at which gas delivery should end on each day of the Delivery Period(s).

15.3.6.2.1.2 gasPhysicalLeg - product

type-The type of gas to be delivered. calorificValue-The calorific value of the gas to be delivered, specified in megajoules per cubic meter (MJ/m3). quality-The quality of the gas to be delivered.

15.3.6.2.1.3 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.6.2.1.4 gasPhysicalLeg - deliveryQuantity

CommodityFixedPhysicalQuantity.model-The different options for specifying a fixed physical quantity of commodity to be delivered. minPhysicalQuantity-The minimum quantity to be delivered. If separate minimums need to be specified for different periods (e.g. a minimum per day and a minimum per month) this element should be repeated. maxPhysicalQuantity-The maximum quantity to be delivered. If separate minimums need to be specified for different periods (e.g. a minimum per day and a minimum per month) this element should be repeated. electingParty-Indicates the party able to choose whether the gas is delivered for a particular period e.g. a swing or interruptible contract.

15.3.6.2.2 Oil Physical Leg

Physically settled oil or refined products leg.

15.3.6.2.2.1 oilPhysicalLeg - deliveryPeriods

15.3.6.2.2.2 oilPhysicalLeg - product

15.3.6.2.2.3 oilPhysicalLeg - deliveryConditions

15.3.6.2.2.4 oilPhysicalLeg - deliveryQuantity

15.3.6.2.3 Electricity Physical Leg

Physically settled electricity leg.

15.3.6.2.3.1 electricityPhysicalLeg - deliveryPeriods

15.3.6.2.3.2 electricityPhysicalLeg - product

15.3.6.2.3.3 electricityPhysicalLeg - deliveryConditions

15.3.6.2.3.4 electricityPhysicalLeg - deliveryQuantity

15.3.6.2.4 Coal Physical Leg

Physically settled coal leg.

15.3.6.2.4.1 coalPhysicalLeg - deliveryPeriods

15.3.6.2.4.2 coalPhysicalLeg - product

15.3.6.2.4.3 coalPhysicalLeg - deliveryConditions

15.3.6.2.4.4 coalPhysicalLeg - deliveryQuantity

15.3.6.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. deliveryDate-The date on which allowances are to be delivered as specified in the related Confirmation.The date on which allowances are to be delivered as specified in the related Confirmation. paymentDate-No Annotation Available BusinessCentersOrReference.model-No Annotation Available failureToDeliverApplicable-Applies to EU Emissions Allowance Transactions. Holds the Failure to Deliver (Alternative Method) election. Used to determine how provisions in Part [7] Page 7 (B) Failure to Deliver Not Remedied are to be applied.Applies to EU Emissions Allowance Transactions. Holds the Failure to Deliver (Alternative Method) election. Used to determine how provisions in Part [7] Page 7 (B) Failure to Deliver Not Remedied are to be applied. eEPParameters-Applies to EU Emissions Allowance Transactions. Contains a series of parameters controlling Excess Emissions Penalty payments.Applies to EU Emissions Allowance Transactions. Contains a series of parameters controlling Excess Emissions Penalty payments.

15.3.6.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.6.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. compliancePeriod-Applies to E.U. Emissions Allowance Transactions. Describes Specified Compliance Period for which the Allowances are issued. 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.6.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.3.6.2.5.4 environmentalPhysicalLeg - deliveryDate

deliveryDate-The date on which allowances are to be delivered as specified in the related Confirmation.The date on which allowances are to be delivered as specified in the related Confirmation.

adjustableDate-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 centers, together with the convention for adjusting the date. relativeDate-A date specified as some offset to another date (the anchor date).

15.3.6.2.5.5 environmentalPhysicalLeg - paymentDate and businessCenters

paymentDate-No Annotation Available

15.3.6.2.5.6 environmentalPhysicalLeg - failureToDeliverApplicable

failureToDeliverApplicable-Applies to EU Emissions Allowance Transactions. Holds the Failure to Deliver (Alternative Method) election. Used to determine how provisions in Part [7] Page 7 (B) Failure to Deliver Not Remedied are to be applied.Applies to EU Emissions Allowance Transactions. Holds the Failure to Deliver (Alternative Method) election. Used to determine how provisions in Part [7] Page 7 (B) Failure to Deliver Not Remedied are to be applied.

15.3.6.2.5.7 environmentalPhysicalLeg - EEPParameters

EEPParameters-Excess Emission Penalty related parameters.

eEPApplicable-If Excess Emission Penalty is specified to be applicable in the Confirmation then the Excess Emission Penalty will be determined in the manner specified in the Confirmation (see other EEP parameters) riskPeriod-Used to determine how provisions in Part [7] Page 7 (B) Failure to Deliver Not Remedied are to be applied. equivalentApplicable-When "true" the EEP Equivalent is applicable. See Part [7] definition of EEP Equivalent. penaltyApplicable-When "true" the Excess Emissions Penalty is applicable. See Part [7] definition of Excess Emissions Penalty.

15.4 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. CommodityContent.model-Items common to all Commodity Transactions.

15.4.1 commodityForward - fixedLeg

The fixed payment of the Commodity Forward product is represented using the fixedLeg element of type NonPeriodicFixedPriceLeg.

PayerReceiver.model - a complex group containing references to the identity of the paying party, the receiving party and the accounts used by each. 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. quantityReference-A pointer style reference to a quantity defined on another leg.A pointer style reference to a quantity defined on another leg. CommodityPaymentDates.model-The different options for specifying the Payment Date. This will consist of either a set of Payment Dates or else a Payment Date schedule.

15.4.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. PayerReceiver.model - a complex group containing references to the identity of the paying party, the receiving party and the accounts used by each. CommodityCalculationPeriods.model-The different options for specifying the Calculation Periods. commodity-Identifies the underlying asset when it is a listed commodity. quantityReference-A pointer to a specification of quantity defined elsewhere.A pointer to a specification of quantity defined elsewhere. 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. CommodityPaymentDates.model-The different options for specifying the Payment Date. This will consist of either a set of Payment Dates or else a Payment Date schedule.

The 'commodityForwardLeg' element is placeholder within commodityForward structure for the actual Precious and Non-Precious metal legs (e.g. bullionPhysicalLeg and metalPhysicalLeg).

15.4.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.4.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. conversionFactor-If the Notional Quantity is specified in a unit that does not match the unit in which the Commodity Reference Price is quoted, the scaling or conversion factor used to convert the Commodity Reference Price unit into the Notional Quantity unit should be stated here. If there is no conversion, this element is not intended to be used.If the Notional Quantity is specified in a unit that does not match the unit in which the Commodity Reference Price is quoted, the scaling or conversion factor used to convert the Commodity Reference Price unit into the Notional Quantity unit should be stated here. If there is no conversion, this element is not intended to be used. 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. conversionFactor-If the Notional Quantity is specified in a unit that does not match the unit in which the Commodity Reference Price is quoted, the scaling or conversion factor used to convert the Commodity Reference Price unit into the Notional Quantity unit should be stated here. If there is no conversion, this element is not intended to be used.If the Notional Quantity is specified in a unit that does not match the unit in which the Commodity Reference Price is quoted, the scaling or conversion factor used to convert the Commodity Reference Price unit into the Notional Quantity unit should be stated here. If there is no conversion, this element is not intended to be used.

15.4.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. shape-The physical shape(s) which can be delivered in Seller's option. brand-The brand(s) of material which can be delivered in Seller's option. grade-The grade(s) of material which can be delivered in seller's option.

15.4.4.2 commodityForward - metalPhysicalLeg - deliveryPeriods

deliveryPeriods-The period during which delivery/deliveries of Metal may be scheduled.The period during which delivery/deliveries of Metal may be scheduled.

periods-The Delivery Periods for this leg of the swap. This type is only intended to be used if the Delivery Periods differ from the Calculation Periods on the fixed or floating leg. If DeliveryPeriods mirror another leg, then the calculationPeriodsReference element should be used to point to the Calculation Periods on that leg - or the calculationPeriodsScheduleReference can be used to point to the Calculation Periods Schedule for that leg. periodsSchedule-The Delivery Periods for this leg of the swap. This type is only intended to be used if the Delivery Periods differ from the Calculation Periods on the fixed or floating leg. If DeliveryPeriods mirror another leg, then the calculationPeriodsReference element should be used to point to the Calculation Periods on that leg - or the calculationPeriodsScheduleReference can be used to point to the Calculation Periods Schedule for that leg. CommodityCalculationPeriodsPointer.model-Model group enables users to reference a Calculation Periods schedule in the form of a series of actual dates in a calculationPeriods container or in the form of a parameterized schedule in a calculationPeriodsSchedule container.

15.4.4.3 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. totalQuantityTolerance-The +/- percent tolerance in seller's option which applies to the total quantity delivered over all shipment periods. periodQuantityTolerance-The +/- percentage quantity tolerance in seller's option which applied to each shipment period. title-Describes how and when title to the commodity transfers.

15.4.4.4 commodityForward - metalPhysicalLeg - CommodityFixedPhysicalQuantity.model

CommodityFixedPhysicalQuantity.model-The different options for specifying a fixed physical quantity of commodity to be delivered.

physicalQuantity-The Quantity per Delivery Period. physicalQuantitySchedule-Allows the documentation of a shaped quantity trade where the quantity changes over the life of the transaction. totalPhysicalQuantity-The Total Quantity of the commodity to be delivered.

15.5 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. BuyerSeller.model-No Annotation Available The 'buyerPartyReference' and 'sellerPartyReference' contain references to the parties that buy or sell the instrument respectively. Buying the instrument means paying for the instrument and receiving the rights defined by it. On the other hand, selling the instrument means granting the rights defined by the instrument and in return receiving a payment for it. 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. CommodityContent.model-Items common to all Commodity Transactions.

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.5.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. The commodity option featuers can include asian/averagin and or barrier (see below). 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. 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.5.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.

The commodity option featuers can include asian/averagin and or barrier:

15.5.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:

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.5.1.1.2 commodityOption - CommodityFinancialOption - CommodityOptionFeatures - CommodityBarrier

CommodityBarrier-The specification of how a barrier option will trigger (that is, knock-in or knock-out) or expire based on the position of the spot rate relative to trigger level.

The following elements are specific to commodity barrier option:

knock-The knock feature of a commodity barrier option. featurePaymentAmount-In the case of barrier options where the option automatically expires and the barrier is breached in such a way to to result in a "knock-out" vent, this amount is paid to the the option holder so as to refund or rebate a portion of any premium paid. trigger-No Annotation Available

15.5.1.1.2.1 commodityOption - CommodityFinancialOption - CommodityOptionFeatures - CommodityBarrier - trigger

CommodityTrigger-The barrier which, when breached, triggers the knock-in or knock-out of the barrier option.

CommodityTrigger-The barrier which, when breached, triggers the knock-in or knock-out of the barrier option. levelQuantity-The amount used the specify the barrier in terms of an quantity of commodity or a change in the quantity of commodity. In confirmations this is often described as the "Strike Volume" or "Strike Quantity". levelUnit-The units (e.g. BCF) used to specify the barrier in terms of an quantity of commodity or change in the quantity of commodity. levelPercentage-A barrier expressed as a percentage of notional quantity or commodity price level. triggerType-For barrier options: the specification of how an option will trigger or expire based on the position of the spot rate relative to the trigger level. For trades with selectable notionals: the specification of the conditions where one of the alternative notional values would apply.

15.5.1.1.2.2 commodityOption - - CommodityFinancialOption - CommodityOptionFeatures - CommodityBarrier - Feature Payment Amount

Optional feature payment to the option buyer on knock-out.

15.5.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.5.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. automaticExercise-Specifies whether or not Automatic Exercise applies to a Commodity Option Transaction. writtenConfirmation-Specifies whether or not Written Confirmation applies to a Commodity Option Transaction. 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. fx-FX observations to be used to convert the observed Commodity Reference Price to the Settlement Currency. conversionFactor-If the Notional Quantity is specified in a unit that does not match the unit in which the Commodity Reference Price is quoted, the scaling or conversion factor used to convert the Commodity Reference Price unit into the Notional Quantity unit should be stated here. If there is no conversion, this element is not intended to be used. CommodityPaymentDates.model-The different options for specifying the Payment Date. This will consist of either a set of Payment Dates or else a Payment Date schedule.

15.5.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. latestExerciseTime-For a Bermuda or American style option, the latest time on an exercise business day (excluding the expiration date) within the exercise period that notice can be given by the buyer to the seller or seller's agent. Notice of exercise given after this time will be deemed to have been given on the next exercise business day. latestExerciseTimeDetermination-Latest exercise time determination method. expirationTime-The specific time of day on which the option expires.The specific time of day on which the option expires. multipleExercise-The presence of this element indicates that the option may be partially exercised. It is not applicable to European or Asian options.The presence of this element indicates that the option may be partially exercised. It is not applicable to European or Asian options.

15.5.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. expirationTime-The specific time of day on which the option expires.The specific time of day on which the option expires.

15.5.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.5.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 weatherCalculationPeriodsReference-No Annotation Available

15.5.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.5.2.2 commodityOption - CommodityWeatherOption - weatherNotionalAmount

weatherNotionalAmount-No Annotation Available

15.5.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. fx-FX observations to be used to convert the observed Commodity Reference Price to the Settlement Currency.

15.5.2.3.1 paymentDates

paymentDates-Dates on which payments will be made.

15.5.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.5.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. businessDays-A day on which commmercial banks settle payments and are open for general business in the place(s) specified in the Confirmation. See Section 1.3 of the ISDA 2005 Commodity Definitions. dataCorrection-The date payment often revised after its publication, this indicates if the payment date could be recalculated. correctionPeriod-If 'dataCorrection'=true, this indicates how long after the initial publication of the data corrections can be made. 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. rounding-Rounding direction and precision for price values.

15.5.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. DataProvider-Specify as applicable. Parties may wish to refer to the state meteorological authority in a particular location or to an exchange or other third party data provider. Parties may find the definitions in the Commodity Definitions useful as a means of identifying potential Data Providers. finalEditedData-If specified by the parties to apply in the related Confirmation, Final Edited Data means that the parties will have recourse to Primary Disruption Fallbacks even if relevant data is available from the Data Provider, so long as such data is not published in its final edited form. Otherwise the parties will have recourse to Primary Disruption Fallbacks only if relevant data is unavailable from the Data Provider on a relevant day. weatherStation-The source or sources of weather index data specified by the parties in the related Confirmation. Examples include: AU-CBM (the Commonwealth Bureau of Meteorology in Australia) and CM-SMI (the Swiss Meteorological Institute). finalEditedData-If specified by the parties to apply in the related Confirmation, Final Edited Data means that the parties will have recourse to Primary Disruption Fallbacks even if relevant data is available from the Data Provider, so long as such data is not published in its final edited form. Otherwise the parties will have recourse to Primary Disruption Fallbacks only if relevant data is unavailable from the Data Provider on a relevant day. weatherStationFallback-If weather index data is not available for the weather station specified by the parties in the related Confirmation, the first alternative Weather Index Station. weatherStationSecondFallback-If weather index data is neither available for the weather station specified by the parties in the related Confirmation nor the first alternative Weather Index Station, the second alternative Weather Index Station. alternativeDataProvider-A provider of either temperature data or precipitation data specified by the parties in the related Confirmation. If the parties fail to specify an Alternative Data Provider, the "Fallback Data" Disruption Fallback will not apply. synopticDataFallback-If the parties specify "Not Applicable", the "Synoptic Data" Disruption Fallback will not apply. Synoptic Data means that maximum and/or minimum temperature or daily precipitation at the location for the Missing Data Day will be the maxium and/or minimum temperature or daily precipitation for that day at the Location (Weather Index Station) which has not been subject to ultimate quality control, integrity or verification process. adjustmentToFallbackWeatherStation-The Weather Index Station from which data with which to apply the "Adjustement to Fallback Station Data" terms. See Section 11.20 of the 2005 ISDA Commodity Definitions. primaryDisruptionFallbacks-A list of actions available to the parties should a Primary Disruption Event occur. A Primary Disruption Event means if maximum or minimum temperature or precipitation data for a Missing Data Day is required to determine a Payment Amount then the maximum and/or minimum temperature or the daily precipitation for that day will be determined in accordance with the first applicable Primary Disruption Fallback. secondaryDisruptionFallbacks-A list of actions available to the parties should a Secondary Disruption Event occur. A Primary Disruption Event means if maximum or minimum temperature or precipitation data for a Missing Data Day is required to determine a Payment Amount then the maximum and/or minimum temperature or the daily precipitation for that day will be determined in accordance with the first applicable Secondary Disruption Fallback.

15.5.2.6.1 WeatherStation

WeatherStation-Weather Station.

The same content applies to 'weatherStationFallback' and 'weatherStationSecondFallback'.

weatherStationCity-No Annotation Available weatherStationAirport-No Annotation Available weatherStationWBAN-No Annotation Available weatherStationWMO-No Annotation Available

15.5.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.6 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. BuyerSeller.model - a complex group containing information on the identities of the parties to the transaction and the account information of each party. 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. CommodityContent.model-Items common to all Commodity Transactions.

15.6.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. settlementCurrency-The currency into which the Commodity Swap Transaction will settle. If this is not the same as the currency in which the Commodity Reference Price is quoted on a given floating leg of the Commodity Swap Transaction, then an FX rate should also be specified for that leg. 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. CommodityContent.model-Items common to all Commodity Transactions.

15.6.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. automaticExercise-Specifies whether or not Automatic Exercise applies to a Commodity Option Transaction. writtenConfirmation-Specifies whether or not Written Confirmation applies to a Commodity Option Transaction.

15.6.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. PayerReceiver.model-No Annotation Available paymentDate-The payment date, which can be expressed as either an adjustable or relative date.The payment date, which can be expressed as either an adjustable or relative date. paymentAmount-Non negative payment amount.Non negative payment amount. premiumPerUnit - Not used in Swaptions

15.6.4 commoditySwaption - CommodityContent

CommodityContent.model-Items common to all Commodity Transactions.
The 'commonPricing', 'marketDisruption', and 'rounding' elements are common across all commodity transactions. For a detailed description of them see the commoditySwap section.

commonPricing-If Common Pricing is elected (“true”) for a Transaction with referencing more than one Commodity Reference Price then no date will be a Pricing Date unless such a date is a day on which all Commodity Reference Prices are scheduled to be published. marketDisruption-Contains contract terms related to triggers and responses to market disruptions as defined in the 1993 or 2005 Commodity Definitions. settlementDisruption-Describes contract terms related to the consequences of Bullion Settlement Disruption Events. rounding-Rounding direction and precision for amounts.

15.7 commodityBasketOption

The commodityBasketOption defines a commodity basket option product

CommodityBasketOption-No Annotation Available optionType-The type of option transaction.The type of option transaction. e.g. a call option or a put option. CommodityBasketOptionFeatures.model-Describes the features a commodity basket option. notionalQuantityBasket-No Annotation Available notionalAmountBasket-No Annotation Available strikePriceUnderlyingReference-No Annotation Available strikePriceBasketReference-No Annotation Available CommodityStrikePrice.model-The different options for specifying the Strike price per unit. 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. exercise-The parameters for defining how the commodity option can be exercised and how it is settled.The parameters for defining how the commodity option can be exercised and how it is settled. premium-The option premium payable by the buyer to the seller.The option premium payable by the buyer to the seller. CommodityContent.model-Items common to all Commodity Transactions.

15.7.1 commodityBasketOption - CommodityBasketOptionFeatures.model

Describes additional features within the Basket option

CommodityBasketOptionFeatures.model-Describes the features a commodity basket 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. calculationPeriodsSchedule-A parametric representation of the Calculation Periods of the Commodity Option Transaction. calculationPeriods-An absolute representation of the Calculation Period start dates of the Commodity Option Transaction.

15.7.2 commodityBasketOption - notionalQuantityBasket

Describes notional quantity basket.

CommodityBasketByNotional-No Annotation Available underlying-Indicates the role of the option buyer with regard to this underlyer.Indicates the role of the option buyer with regard to this underlyer.

15.7.3 commodityBasketOption - notionalAmountBasket

Describes notional amount basket.

CommodityBasketByPercentage-No Annotation Available underlying-Indicates the role of the option buyer with regard to this underlyer.Indicates the role of the option buyer with regard to this underlyer. notionalAmount-No Annotation Available

15.7.4 commodityBasketOption - CommodityStrikePrice.model

Describes strike price.

CommodityStrikePrice.model-The different options for specifying the Strike price per unit. strikePricePerUnit-The currency amount of the strike price per unit. strikePricePerUnitSchedule-No Annotation Available

15.7.5 commodityBasketOption - CommodityFloatingStrikePrice.model

Describes floating strike price.

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. floatingStrikePricePerUnit-The currency amount of the strike price per unit. floatingStrikePricePerUnitSchedule-No Annotation Available

15.7.6 commodityBasketOption - Exercise

exercise

CommodityExerciseBasket-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 exercise period for an American style option together with the rules governing the quantity of the commodity that can be exercised on any given exercise date. 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. automaticExercise-Specifies whether or not Automatic Exercise applies to a Commodity Option Transaction. writtenConfirmation-Specifies whether or not Written Confirmation applies to a Commodity Option Transaction. 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. CommodityPaymentDates.model-The different options for specifying the Payment Date. This will consist of either a set of Payment Dates or else a Payment Date schedule.

15.7.7 commodityBasketOption - Premium

premium

15.7.8 commodityBasketOption - CommodityContent.model

CommodityContent.model

15.8 commodityDigitalOption

The commodityDigitalOption defines a commodity digital option product

CommodityDigitalOption-Defines the digital commodity option product type. Digital options exercise when a barrier is breached and are financially settled. The 'commodityDigitalOption' type is an extension of the 'commodityOption' product. optionType-The type of option transaction.The type of option transaction. e.g. a call option or a put option. 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).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). CommodityDigitalOptionFeatures.model-Describes features of the digital option. notionalAmount-Volume contracted when volume is specified as a currency-denominated amount. notionalQuantity-No Annotation Available totalNotionalQuantity-No Annotation Available exercise-The parameters for defining how the commodity option can be exercised and how it is settled.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. premium-The option premium payable by the buyer to the seller.The option premium payable by the buyer to the seller. CommodityContent.model-Items common to all Commodity Transactions.

15.8.1 commodityDigitalOption - CommodityDigitalOptionFeatures.model

Specific to financially-settled commodity digital options

CommodityDigitalOptionFeatures.model-Describes features of the digital 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. digital-The barrier and cash payout features of the digital option.

15.8.1.1 commodityDigitalOption - CommodityDigitalOptionFeatures.model - digital

Specific the commodity digital options' barrier:

CommodityDigital-Defined the conditions under which the digital option can triggers and, if triggered, what payment results. trigger-No Annotation Available featurePaymentAmount-The cash payment that is made when the digital barrier is breached.

15.8.1.1.1 commodityDigitalOption - CommodityDigitalOptionFeatures.model - Digital - Commodity Trigger

Trigger point at which feature is effective.

CommodityTrigger-The barrier which, when breached, triggers the knock-in or knock-out of the barrier option. levelQuantity-The amount used the specify the barrier in terms of an quantity of commodity or a change in the quantity of commodity. In confirmations this is often described as the "Strike Volume" or "Strike Quantity". levelUnit-The units (e.g. BCF) used to specify the barrier in terms of an quantity of commodity or change in the quantity of commodity. levelPercentage-A barrier expressed as a percentage of notional quantity or commodity price level. triggerType-For barrier options: the specification of how an option will trigger or expire based on the position of the spot rate relative to the trigger level. For trades with selectable notionals: the specification of the conditions where one of the alternative notional values would apply.

15.8.1.1.2 commodityDigitalOption - CommodityDigitalOptionFeatures.model - Digital - Feature Payment Amount

Feature Payment.

15.8.2 commodityDigitalOption - Exercise

exercise

CommodityDigitalExercise-The parameters for defining how the commodity digital option can be exercised. I differs from the CommodityExercise type in that it lacks a specification of Settlement Currency. The Settlement Currency is specified in the 'featurePayment' element. 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. automaticExercise-Specifies whether or not Automatic Exercise applies to a Commodity Option Transaction. writtenConfirmation-Specifies whether or not Written Confirmation applies to a Commodity Option Transaction. settlementCurrency-No Annotation Available CommodityPaymentDates.model-The different options for specifying the Payment Date. This will consist of either a set of Payment Dates or else a Payment Date schedule.

15.8.3 commodityDigitalOption - Premium

premium

15.8.4 commodityDigitalOption - CommodityContent.model

CommodityContent.model

15.9 commodityPerformanceSwap

A performance swap is a swap in which the payout(s) are based on the price performance of an index rather than the price level of the index.Example of price performance metrics include price return, price variance, price volatility, price correlation and price covariance. The commodityPerformanceSwap product provides a convenient and extendable means of representing performance swaps which are linked to commodity assets

One can represent different types of commodity performance swaps by selecting one-or-more types of performance legs. For example, a simple commodity return swap can be represented by choosing an interest leg and a return leg. An outperformance swap can be represented by choosing two return legs. A simple variance swap can be represented by choosing a single variance leg.

CommodityPerformanceSwap-A type describing a commodity performance swap in which one leg pays out based on the return on a reference commodity index or commodity reference price.

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

The commodityPerformanceSwap-A swap the payoff of which is linked to the performance of the underlying asset. Examples of potential performance features are return, correlation, covariance, variance and volatility.
The structure defines parameters for product-related information (e.g. dates, payout formula, underlying commodity, interest or fee rate, etc.). Other trade-related information (e.g. trade date, identifiers, legal documentation, etc.) is held in the containing 'trade' structure.

The commodityPerformanceSwapLeg-A placeholder within 'commodityPerformanceSwap' structure for the actual commodity swap legs (e.g. 'commodityReturnLeg' and 'commodityInterestLeg').

• effectiveDate-Specifies the Eeffective Date of the swap. It is an optional element because not all confirmations of total return swaps specify an Effective Date. In these cases the Term of the contract begins on the Trade Date.Specifies the Eeffective Date of the swap. It is an optional element because not all confirmations of total return swaps specify an Effective Date. In these cases the Term of the contract begins on the Trade Date.
  
• terminationDate-Specifies the Termination Date of the swap.Specifies the Termination Date of the swap.
  
• settlementCurrency-The currency in which the commodity performance swap transaction will settle. It is an optional element because not all confirmations of performance swaps specify a Settlement Currency.The currency in which the commodity performance swap transaction will settle. It is an optional element because not all confirmations of performance swaps specify a Settlement Currency.
  
• commodityPerformanceSwapLeg-A placeholder within 'commodityPerformanceSwap' structure for the actual commodity swap legs (e.g. 'commodityReturnLeg' and 'commodityInterestLeg').
  
• commodityInterestLeg-Specifies the fixed payments of a commodity performance swap. Sometimes also referred to as the fee.
  
• commodityReturnLeg-Specifies the return payments of a commodity return swap. There can be one or two return legs. In simple return swaps there is a return leg and an interest (a.k.a. 'fee') leg. In the case of a outperformance swap there are two return legs: the return performance of two commodity underlyers are swapped. In the case of a fully-funded return swap there is no financing component and, therefore, only a single return leg is specified.
  
• commodityVarianceLeg-Specifies the variance payments of a commodity variance swap.
  
• CommodityContent.model-Items common to all Commodity Transactions.
  
• earlyTermination-Specifies, for one or for both the parties to the trade, the date prior to the Termination Date from which the contract can be terminated.Specifies, for one or for both the parties to the trade, the date prior to the Termination Date from which the contract can be terminated.
  

Component Descriptions:

15.9.1 commodityPerformanceSwap - commodityReturnLeg

CommodityReturnLeg-A type describing the return leg of a commodity return swap.

PayerReceiver.model - The specification of the payer and receiver parties of the return leg is similarl to the approach used in other types of swaps: through the 'payerPartyReference' and the 'receiverPartyReference' data elements. CommodityCalculationPeriods.model-The different options for specifying the Calculation Periods. CommodityPaymentDates.model-The different options for specifying the Payment Date. This will consist of either a set of Payment Dates or else a Payment Date schedule. CommodityUnderlyerChoice.model-A type describing the type of underlyer: a single commodity or a basket of commodities. notionalAmount-Specifies the notional amount of a commodity performance type swap. It is a currency-denominated value (i.e. price-times-quantity). In confirmations is also referred to as the Notional Quantity (sic, expressed in currency units), Notional Amount, Equity Notional Amount and, in the case of reinvesting swaps, Initial Notional Amount. notionalAmountReference-A reference to the Return swap notional amount defined in another leg of the return swap. returnCalculation-Specifies, in relation to each Payment Date, the return percentage which, when multiplied times the notional amount is the amount to which the Payment Date relates.Specifies, in relation to each Payment Date, the return percentage which, when multiplied times the notional amount is the amount to which the Payment Date relates.

15.9.1.1 commodityPerformanceSwap - commodityReturnLeg - CommodityCalculationPeriods.model

CommodityCalculationPeriods.model-The different options for specifying the Calculation Periods.

calculationDates-The Calculation Period dates for this leg of the trade where the Calculation Periods are all one day long. Only dates explicitly included determine the Calculation Periods and there is a Calculation Period for each date specified. As such one-day Calculation Period are typical a physically-settled emissions or metals trades it is expected that this element will not be used in performance swaps. calculationPeriods-The Calculation Period start dates for this leg of the swap. This type is only intended to be used if the Calculation Periods differ on each leg. If Calculation Periods mirror another leg, then the calculationPeriodsReference element should be used to point to the Calculation Periods on that leg - or the calculationPeriodsScheduleReference can be used to point to the Calculation Periods Schedule for that leg. calculationPeriodsSchedule-The Calculation Periods for this leg of the swap. This type is only intended to be used if the Calculation Periods differ on each leg. If Calculation Periods mirror another leg, then the calculationPeriodsReference element should be used to point to the Calculation Periods on the other leg - or the calculationPeriodsScheduleReference can be used to point to the Calculation Periods Schedule for that leg. CommodityCalculationPeriodsPointer.model-Model group enables users to reference a Calculation Periods schedule in the form of a series of actual dates in a calculationPeriods container or in the form of a parameterized schedule in a calculationPeriodsSchedule container.

15.9.1.2 commodityPerformanceSwap - commodityReturnLeg - CommodityPaymentDates.model

CommodityPaymentDates.model-The different options for specifying the Payment Date. This will consist of either a set of Payment Dates or else a Payment Date schedule.

relativePaymentDates-The Payment Dates of the trade relative to the Calculation Periods. CommodityNonPeriodicPaymentDates.model-The different options for specifying the Payment Date.

15.9.1.3 commodityPerformanceSwap - commodityReturnLeg - CommodityUnderlyerChoice.model

CommodityUnderlyerChoice.model-A type describing the type of underlyer: a single commodity or a basket of commodities.

commodity-Describes the swap's underlyer when it has only one asset component. commodityBasket-Describes the swap's underlyer when it has multiple asset components.

15.9.1.4 commodityPerformanceSwap - commodityReturnLeg - notionalAmount

notionalAmount-Specifies the notional amount of a commodity performance type swap. It is a currency-denominated value (i.e. price-times-quantity). In confirmations is also referred to as the Notional Quantity (sic, expressed in currency units), Notional Amount, Equity Notional Amount and, in the case of reinvesting swaps, Initial Notional Amount.

amount-The non negative monetary quantity in currency units.The non negative monetary quantity in currency units. currency-The currency in which an amount is denominated. reinvestmentFeature-This element indicates whether the notional amount (or equivalent) is constant across each Calculation Period or whether the notional amount in each Calculation Period ("false") is the notional amount in the previous period multiplied by 1 + commodity index return in the current period ("true"). In cases where reinstementFeature = true the 'amount' element is the Initial Notional Amount (or equivalent).This element indicates whether the notional amount (or equivalent) is constant across each Calculation Period or whether the notional amount in each Calculation Period ("false") is the notional amount in the previous period multiplied by 1 + commodity index return in the current period ("true"). In cases where reinstementFeature = true the 'amount' element is the Initial Notional Amount (or equivalent).

15.9.1.5 commodityPerformanceSwap - commodityReturnLeg - returnCalculation

CommodityReturnCalculation-No Annotation Available

pricingDates-Describes which dates are valid dates on which to observe a price or index level valuationDates-Defines when a price or index level will be observed that will figure in the return calculation. simpleReturnOnNotional-The value is "true" when the cash settlement amount is the simple formula: Notional Amount * ((Index Level sub d / Index Level sub d-1) - 1). That is, when the cash settlement amount is the Notional Amount for the calculation period multiplied by the ratio of the index level on the reset date/valuation date divided by the index level on the immediately preceding reset date/valuation date minus one. The value is "false" otherwise.

15.9.2 commodityPerformanceSwap - commodityInterestLeg

CommodityInterestLeg-A type describing the fixed rate leg (a.k.a fee leg) of the commodity performance swap.

PayerReceiver.model - The specification of the payer and receiver parties of the return leg is similarl to the approach used in other types of swaps: through the 'payerPartyReference' and the 'receiverPartyReference' data elements. CommodityCalculationPeriods.model-The different options for specifying the Calculation Periods. Similar to commodityReturnLeg CommodityPaymentDates.model-The different options for specifying the Payment Date. This will consist of either a set of Payment Dates or else a Payment Date schedule. Similar to commodityReturnLeg notionalAmount-Specifies the notional amount of a commodity performance type swap. It is a currency-denominated value (i.e. price-times-quantity). In confirmations is also referred to as the Notional Quantity (sic, expressed in currency units), Notional Amount, Equity Notional Amount and, in the case of reinvesting swaps, Initial Notional Amount. Similar to commodityReturnLeg notionalAmountReference-A reference to the Return swap notional amount defined in another leg of the return swap. Similar to commodityReturnLeg notionalAmountReference-A reference to the Return swap notional amount defined in another leg of the return swap. interestCalculation-Specifies the fixed rate calculation on a performance swap. This amount may be referred to as the interest rate or the fee. The result of this calculation is a number that is multiplied times the notional amount yielding the fixed payment amount or fee amount.Specifies the fixed rate calculation on a performance swap. This amount may be referred to as the interest rate or the fee. The result of this calculation is a number that is multiplied times the notional amount yielding the fixed payment amount or fee amount.

15.9.2.1 commodityPerformanceSwap - commodityInterestLeg - interestCalculation

CommodityInterestCalculation-Specifies the fixed payment amount on a return swap. This amount may be referred to as the interest amount or the fee amount.

rate-The percentage that, when multiplied by the Notional Amount and the number of calendar days in the Calculation Period divided by the calendar days basis, is the fixed amount payed per Calculation Period. dayCountFraction-Specifies the number of calendar days in the Calculation Period divided by the calendar days basis e.g. actual number of days in the Calculation Period divided by 365.

15.9.3 commodityPerformanceSwap - commodityVarianceLeg

CommodityVarianceLeg-A type describing the variance leg of a commodity variance swap.

PayerReceiver.model - The specification of the payer and receiver parties of the return leg is similarl to the approach used in other types of swaps: through the 'payerPartyReference' and the 'receiverPartyReference' data elements. CommodityCalculationPeriods.model-The different options for specifying the Calculation Periods. Similar to commodityReturnLeg and commodityInterestLeg CommodityPaymentDates.model-The different options for specifying the Payment Date. This will consist of either a set of Payment Dates or else a Payment Date schedule. Similar to commodityReturnLeg and commodityInterestLeg CommodityUnderlyerChoice.model-A type describing the type of underlyer: a single commodity or a basket of commodities. Similar to commodityReturnLeg notionalAmount-Specifies the notional amount of a commodity performance type swap. It is a currency-denominated value (i.e. price-times-quantity). In confirmations is also referred to as the Notional Quantity (sic, expressed in currency units), Notional Amount, Equity Notional Amount and, in the case of reinvesting swaps, Initial Notional Amount. Similar to commodityReturnLeg and commodityInterestLeg notionalAmountReference-A reference to the Return swap notional amount defined in another leg of the return swap. Similar to commodityReturnLeg and commodityInterestLeg varianceStrikePrice-Specifies the variance strike price when this strike is expressed in variance units. Payments on the variance leg are equal to the national amount multiplied by the realized variance minus this variance strike price: notional amount * (realized variance - variance strike price). volatilityStrikePrice-Specifies the volatility strike price when this strike is expressed in standard deviation units. Payments on the variance leg are equal to the national amount multiplied by the realized volatility squared minus the volatility strike price squared. Notional amount * (realized volatility^2 - volatility strike^2). Squaring the volatility strike price converts the volatility strike price into a variance strike price. Squaring the realized volatility converts realized volatility to realized variance. varianceCalculation-Specifies, in relation to each Payment Date, the variance percentage which, when multiplied times the notional amount is the amount to which the Payment Date relates. For purposes of this representation the realized variance is: (annualizationFactor / N) * signma from i = 1 to N (ln (S sub (i+1)) / (S sub i)), where: ln is the natural logarithm, N is the number of pricing dates, S sub i is the relevant price on the observation date i. If nAdjustment is 'true' then the denominator of the annualization factor is (N - 1) rather than N. If realized volatility is the performance metric in a variance swap rather than realized variance then the square root of the formula above will appear in the confirmation.Specifies, in relation to each Payment Date, the variance percentage which, when multiplied times the notional amount is the amount to which the Payment Date relates. For purposes of this representation the realized variance is: (annualizationFactor / N) * signma from i = 1 to N (ln (S sub (i+1)) / (S sub i)), where: ln is the natural logarithm, N is the number of pricing dates, S sub i is the relevant price on the observation date i. If nAdjustment is 'true' then the denominator of the annualization factor is (N - 1) rather than N. If realized volatility is the performance metric in a variance swap rather than realized variance then the square root of the formula above will appear in the confirmation.

15.9.3.1 commodityPerformanceSwap - commodityVarianceLeg - varianceCalculation

varianceCalculation-Specifies, in relation to each Payment Date, the variance percentage which, when multiplied times the notional amount is the amount to which the Payment Date relates. For purposes of this representation the realized variance is: (annualizationFactor / N) * signma from i = 1 to N (ln (S sub (i+1)) / (S sub i)), where: ln is the natural logarithm, N is the number of pricing dates, S sub i is the relevant price on the observation date i. If nAdjustment is 'true' then the denominator of the annualization factor is (N - 1) rather than N. If realized volatility is the performance metric in a variance swap rather than realized variance then the square root of the formula above will appear in the confirmation.Specifies, in relation to each Payment Date, the variance percentage which, when multiplied times the notional amount is the amount to which the Payment Date relates. For purposes of this representation the realized variance is: (annualizationFactor / N) * signma from i = 1 to N (ln (S sub (i+1)) / (S sub i)), where: ln is the natural logarithm, N is the number of pricing dates, S sub i is the relevant price on the observation date i. If nAdjustment is 'true' then the denominator of the annualization factor is (N - 1) rather than N. If realized volatility is the performance metric in a variance swap rather than realized variance then the square root of the formula above will appear in the confirmation.

pricingDates-Describes which dates are valid dates on which to observe a price or index level. valuationDates-Defines when a price or index level will be observed that will figure in the return calculation. annualizationFactor-This specifies the numerator of an annualization factor. Frequently this number is equal to the number of observations of prices in a year e.g. 252. nAdjustment-Specifies whether denominator of the annualization factor is N ("false") or N - 1 ("true").

16 PRICING AND RISK ARCHITECTURE

16.1 Introduction

This section is the initial deliverable of the FpML Pricing and Risk Working Group (PRWG).

Included in this section are:

• A very brief introduction to derivatives pricing and risk, and how this specification relates to those processes.
• The scope of the initial deliverable
• The requirements to address that scope
• A high-level overview of the structures in the schema used to address the requirements.
• A more detailed explanation of the usage scenarios together with examples
• A short glossary

16.2 Derivatives Pricing and Risk

16.2.1 Pricing

Interest rate derivatives are typically priced (a.k.a. “valued”) by forecasting the future price and price evolution of the assets that underlie the derivative, using these forecasts to estimate the future cash flows of the derivative instrument, and then discounting these cash flows to the preset.

For example, interest rate swap cash flows are typically calculated based in part on an floating interest rate index (such as US Dollar 3 month LIBOR). An interest rate swap’s value is usually estimated by forecasting the floating rate (in this example, USD-LIBOR-3M), calculating the forecast cash flows, and then discounting them to the present using a discount curve.

More complex products such as option products frequently use a similar process, but price the instrument under a variety of forecasts and estimate the value of the derivative by averaging or otherwise combining the various forecasts.

This specification describes ways to represent the data that is needed for generating these forecasts, if required for valuation reporting.

16.2.2 Valuation and Risk Reporting

A series of values (“measures”) can be computed about derivatives. The measures include:

• a variety of price-like values (e.g. Net Present Value, Clean Price, Dirty Price, Accrued Interest, Cash Payable, etc.),
• the sensitivities of some of the above values (particularly the NPV) to changes in pricing assumptions
• other risk measures, such as Potential Exposure, Value At Risk, etc.

The specification provides way to represent these measures and if desired to describe them in some detail.

16.3 Pricing and Risk Scope

The Pricing and Risk scope for FpML 5.7 Last Call Working Draft is:

Valuation and basic risk on the following products:

• Vanilla IR Swaps (single and dual currency fix/float swaps, non-CMS/CMT)
  • Valuation reporting (trades only)
  • Market Data (Yield Curves, FX spot rates)
  • Market risk reporting (Delta Risk vs. Curve Inputs, FX exposures) for trades
• Credit Default Swaps
  • Valuation reporting for trades
  • Market Data (ir curves, credit spread, recovery rate, probability of default)
  • Market risk reporting (risk with respect to. the above variables) for trades
• IR Caps/Floors/ EuropeanSwaptions, and corresponding risk types
  • Valuation reporting for trades
  • Market data (volatility surfaces)
  • Market risk reporting
    • Volatility/Vega Risk
    • Convexity/Gamma Risk (applies to all products)
    • Time Decay/Theta (applies to all products)
• Portfolio level valuation and risk
  • Valuation
  • Risk reporting

The Pricing and Risk Working Group has also provided some definitions that might be useful for other types of valuation and risk reporting.

16.4 Requirements

16.4.1 Introduction

The aim of the FpML Pricing and Valuations Working Group (PRWG) is to define a set of extensions to the FpML schema that allow the description of:

• A request to provide valuation and risk information about a trade or group of trades, henceforth referred to as a Valuation Request.
• A report providing valuation and risk information about a trade or group trades, henceforth referred to as a Valuation Report.

16.4.2 Usage Scenarios

The intended uses of this specification include:

• Submitting valuation requests by relatively unsophisticated clients to more sophisticated providers, and returning the results.
• Submitting valuation requests from sophisticated trading users or applications to a valuation engine or system.
• Providing sensitivity results with a variety of levels of rigor and definitional detail
• Communicating market data between clients and providers for the purposes of either requesting valuations or explaining how valuation results were obtained.

These scenarios are described below in more detail in the “Use Cases and Examples” section.

16.4.3 Product Coverage

The products to be supported are those covered by the FpML 4.0 specification. However, we will in particular focus on the following product groupings:

• Vanilla IR Swaps (single and dual currency fix/float swaps, non CMS/CMT)
• Credit Default Swaps
• IR Caps/Floors and European Swaptions.

16.4.4 Valuation and Risk Measures

The specification and reporting of following valuation and risk measures are to be supported:

• Net Present Value
• Market Risk Sensitivities, including, but not limited to:
  • Interest Rate Delta (Sensitivity to Curve Inputs)
  • Interest Rate Delta (Sensitivity to Forward Rates)
  • Interest Rate Vega
  • Interest Rate Gamma
  • FX Spot Sensitivity
  • Credit Spread Sensitivity
  • Sensitivity to Probability of Default
  • Recovery Rate sensitivity

In addition, the schema should be easily extensible to allow additional valuation or risk measures to specified and reported.

16.4.5 Market and Pricing Data

The schema should allow the description of market or pricing data. Here we refer to market data as observable market rates or prices in some structured form (e.g. a yield curve of interest rates), and pricing data as market data that has been processed in some way (e.g. a term structure of discount factors).

This market and pricing data may be referred to by the Valuation Request as data to be used in calculating the requested valuation and risk measures, or can be included in the Valuation Report as data used to produce the reported valuation and risk measures.

In addition, a Valuation Request may refer to market and pricing data (as a group) by reference (e.g. an identifier denoting ‘use current market data’ or ‘use yesterday’s end-of-day market data).

16.4.6 Valuation Scenarios

The schema should allow the specification of shocks to one or more market data elements, collectively referred to as a Scenario, and the calculation and reporting of all applicable valuation and risk measures in the context of the Scenario rather than the base market data.

16.4.7 Portfolios

The schema should allow specification of a Valuation Request for a single trade or group of trades, henceforth referred to as a Portfolio. A trade may be defined ‘in place’, i.e. as a complete FpML trade representation, or by reference (e.g. a trade identifier). A portfolio may be specified in the following ways:

• A list of trades defined ‘in place’
• A list of trade references
• A portfolio reference (e.g. a portfolio identifier)
• A query or logical definition (e.g. all trades with counterparty x)

16.5 Overview of design

16.5.1 Overview

The Pricing and Risk schema is intended to meet the requirements described above. Because the requirements include both high-level, simplified representations as well as sophisticated, detailed definitions, the schema has been designed to allow a variety of amounts of detail to be provided. It will be up to the client and the provider to negotiate minimum requirements for data as well as well as the list of maximum supported elements.

The schema has been subdivided into several subschema files, corresponding to different topic areas, to reduce the number of definitions that a user needs to review and understand to be able to use the schema. These subschema include (where x-y is the FpML version number):

• fpml-asset-x-y.xsd – This includes some base types used throughout the pricing and risk schema, such as quotations characteristics, measure types, etc.
• fpml-valuation-x-y.xsd – This includes valuation result sets and related definitions.
• fpml-reporting-x-y.xsd – This include messages used for requesting and providing valuation reporting results.
• fpml-mktenv-x-y.xsd – This include definitions of market environment data structures such as yield curves, volatility matrices, and the like. It contains the largest set of definitions, but is not necessary for simple uses of the standard.
• fpml-riskdef-x-y.xsd – This includes detailed definitions of valuation and sensitivity results. They include detailed definitions of sensitivity calculations and are intended to be used by sophisticated users.

16.5.2 Shared Types

16.5.2.1 Introduction

The Pricing and Risk shared types include ways to represent valuations about single objects, such as assets or pricing inputs. They include quotation characteristics, measure types, and base level valuation structures.

16.5.2.2 Quotation Characteristics

The QuotationCharacteristics.model model group, and the corresponding type QuotationCharacteristics, allow a variety of descriptors to be applied to any particular quotation. These descriptors include items such as:

• The measure reported (ie. The type or purpose of the quotation)
• The units of measure
• Which point of view the quotation is expressed for (buyer, seller, mid-market)
• The currency of the quotation
• Whether the quotation is for opening of business, daily high/low/mid, close of day.
• A business center or the exchange (e.g. stock or futures exchange) needs also to be supplied if the time is supplied.
• The information source where a published or displayed market rate will be obtained, e.g. Telerate Page 3750.
• The time the quotation was recorded.
• The valuation date is the date when the quote was computed.
• How long the quotation remains valid
• For cash flow quotations, the type of cash flow. (This is a sub-measure; in a future draft this may be generalized further).

The Quotation Characteristics structures are used relatively consistently throughout the schema to describe values that may be reported.

16.5.2.3 Measure Types

“Measure Types” are represented by the “AssetMeasureType” type, which is an FpML scheme. A wide variety of measures have been defined (see “scheme values” for more information), but additional ones could also be defined. Current measures are divided into three broad categories:

• Valuation measures, such as NPV, cash, accrued interest.
• Sensitivity measures, such as BucketedInterestRateSensitivity
• Risk measures, such as Value at Risk.

Please see the FpML “schemes” documentation for a complete list of the measures. A number of measure types have been defined for areas beyond the current scope of this working group.

16.5.2.4 BasicQuotations

A BasicQuotation is a type that provides a value with a set of QuotationCharacteristics as defined above.

A BasicQuotation is provided for quoting simple assets where sensitivities are not required, e.g. for quotes for input instruments in curves

16.5.2.5 Valuation

Valuation is a type used as a base for types that represent valuations, i.e. quotations associated with objects for a particular valuation scenario.

It includes:

• An object reference, which identifies the object that is valued.
• An optional valuation scenario reference, which identifies the valuation scenario that this valuation is for.

Valuation is extended for objects such as assets and pricing structures.

16.5.2.6 Basic Asset Valuation

A BasicAssetValuation object extends the Valuation type with a BasicQuotation. It is used for representing basic valuations of assets such as benchmarks assets used as inputs to a yield curve. It is not typically used for reporting values of derivative instruments.

16.5.3 Valuation Sets and related definitions

The following types are used to represent valuations of assets and the corresponding sensitivity valuations. These definitions are mostly contained in the fpml-pr-x-y.xsd subschema file.

16.5.3.1 Quotation

The Quotation type is similar to the BasicQuotation but also allows a collection of sensitivities to be added. This allows sensitivities to be associated directly with a specific measure, to provide a precise relationship between the sensitivities and the base value. (Note that both the base value and the sensitivities are optional, so that only one or the other could be reported.)

16.5.3.2 Asset Valuation

The AssetValuation type extends the Valuation types with a full Quotation and an FX rate. The full Quotation allows values (and the associated sensitivities) to be represented for a single asset, such as a trade or a portfolio. The FX rate indicates the rate of a currency conversion that may have been used to compute valuations.

16.5.3.3 Sensitivity Set

A Sensitivity Set is collection of sensitivities, normally related somehow. It is used for containing a mini “risk report” for a single asset, e.g. bucketed interest rate delta risk for a trade or portfolio.

It can contain:

• The name of the sensitivity sets, used to describe its purpose to a human.
• A reference to the definition of the sensitivity set, used to fully explain the meaning of the sensitivities
• A collection of sensitivities.

16.5.3.4 Sensitivity

A sensitivity is a structure that contains a numerical result for the sensitivity of a valuation to a pricing input change:

It contains only a single numeric value. The associated valuation is obtained via containment (i.e. the sensitivity is directly under the same quotation structure). It has two optional attributes: A name, which is a human-readable description of the sensitivity value (e.g the “2Y” point on an interest rate delta curve), and a definitionRef, which is a reference to a Sensitivity Defintion (described in detail below). At least one of these two attributes must be filled it.

The units of the sensitivity (and other quotation characteristics) can be provided via the Sensitivity Definition or the Sensitivity Set definition. If a quotation characteristic is provided at both levels, the finer grained one (ie. that applying to the SensitivityDefinition) prevails.

16.5.3.5 Valuation Set

The valuation set, in effect a short “risk report” or “valuation report”, is a collection of valuations, together with some identifying and descriptive information.

Contents include:

• The name of the valuation set, for human readers
• The valuation scenario that was applied (this describes items such as valuation date, the base counterparty, and the market environment).
• The base party, from which point of view the valuations are computed.
• The default quotation characteristics (used to abbreviate large valuation sets containing many similar quotations, such as NPVs).
• The definitions of any sensitivity sets, ie. definitions of the sensitivity risk reports provided.
• A flag indicating whether the market environment is or should be included.
• A collection of asset valuations, as described above.

16.5.3.6 Valuation Scenario

The Valuation Scenario is a type that is used to define how the valuation was (or is to be) computed. It specifies the input assumptions for the valuations.

It includes, or can include:

• A name, for humans to understand the purpose.
• The date for which the valuation is performed.
• A reference to the market environment (see below).
• Constructs for defining how the base market environment is to be adjusted prior to valuation. (See below in risk definitions for more detail.)

16.5.3.7 Summary

Following is an overview diagram showing many of the structures described above.

16.5.4 Pricing Inputs

16.5.4.1 Overview

This section describes representations for market inputs, such as yield curves and volatility matrices. These market inputs may be shared for the purpose of requesting a valuation or of reporting how a valuation was obtained.

Market inputs are divided into two main types:

• Pricing Structures provide a name/identifier to allow the pricing input to be referenced and identified, but provide no values.
• Pricing Structure Valuations provide values (inputs and/or outputs) for a pricing structure. They are typically associated with a particular valuation scenario.

Each of these is specialized into a variety of pricing input structures, which are in turn built out of building blocks such as TermCurves (for representing term structures) and Underlying Assets with quotations.

A collection of pricing inputs is defined by a “market” or “market Environment.”

16.5.4.2 Abstract Structures

The Pricing Structure type is used as a placeholder for identifying a pricing input, such as a curve or matrix. It is extended for particular pricing structures.

The Pricing Structure Valuation type is used to hold valuations associated with the pricing structure. It includes

• A reference to the pricing structure that is valued.
• A reference to the valuation scenario that this is for
• A variety of pieces of date information to describe the valuation.

16.5.4.3 Term Points and Curves

A term curve is a building block structure used to represent a set of market values over a term structure. It contains a set of Term Points, as well as some information about interpolation and extrapolation. It is used for representing term structures such as discount factor curves.

The Term Point allows bid, ask, mid, and spread values to be specified for a particular term. The Term is in turn defined as a tenor and/or a date.

16.5.4.4 Underlying Assets

Underlying assets are used to represent simple benchmark assets, in this case for constructing market inputs such as curves. Underlying assets have a number of shared attributes:

Most of the shared elements of an underlying asset are self-explanatory. The “definition” element allows a reference to a full FpML product definition for the instrument, to allow a more complete definition to be provided.

In addition, a variety of specialized underlying assets have been produced, including, for example:

• Bonds – typically used for government bonds
• Cash – used to represent currency assets that need to be discounted
• Deposit – used to represent simple term deposits
• FxRate – used to represent FX spot rates used to build pricing inputs (like FX forward curves)
• RateIndex – used to represent interest rate indexes, such as Libor.
• SimpleFra – used to represent Floating Rate Agreement rates used to construct yield curves.
• SimpleIrSwap – used to represent benchmark Interest Rate Swaps used to construct yield curves.

These are all contained in the fpml-asset-x-y.xsd schema file.

16.5.4.5 Quoted Asset Sets

The quoted asset set allows a set of underlyingAssets to be created and quotations to be provided for them:

It is used for calibrating pricing inputs, such as yield curve inputs, and for providing a set of quotes for instruments, such as FX rates, Floating Rate Index rates, etc.

16.5.4.6 Yield Curves

Yield curves are relatively complex and are divided into several types, including:

• Yield Curve – basic curve identifier
• Yield Curve Valuation – holder of valuation information about a yield curve
• Zero Curve – component of Yield Curve Valuation to hold a zero curve
• Forward Curve – component of Yield Curve Valuation to hold forward curve(s).

16.5.4.6.1 Yield Curve

This structure provides a high level identifier for an interest rate curve model.

16.5.4.6.2 Yield Curve Valuation

The Yield Curve Valuation is a type of Pricing Structure Valuation that is able to hold a variety of pieces of information about an interest rate model, including:

• An optional set of input instruments used for building the yield curve
• An optional zero curve, used for representing a term structure of zero-coupon interest rates.
• An optional discount factor curve, used for representing a term structure of discount factors
• Optional forward curves, used for representing forward rate projections for specific indexes.

16.5.4.6.3 Zero Rate Curve

A zero rate curve provides a term structure of zero coupon interest rates.

16.5.4.6.4 Forward Rate Curve

A forward rate curve represents a set of forward rates for a particular floating rate index asset.

16.5.4.7 FX Forward Curves

The FXCurve structure represents the abstract pricing model associated with forecasting FX rates. It extends PricingInput, adding a quoted currency pair to identify what is quoted.

The FXCurveValuation represents the valuation for forecasting FX rates. It extends PricingInputValuation.

16.5.4.8 Credit Curves

The CreditCurve structure represents the abstract pricing model associated with forecasting Credit market values (such as default probabilities). It extends PricingInput, adding several characteristics identifying the credit entity that is quoted.

The Credit Curve Valuation models the valuation of a credit curve:

The default probability curve is a special type of pricing input valuation that models the default probability of a credit entity:

16.5.4.9 Multi-dimensional Pricing Data

The multi-dimensional pricing data structure is used to represent complex pricing structures such as volatility matrices. It consists of a set of Pricing Structure Points.

The Pricing Structure Point represents a single point of a multi-dimensional pricing structure. It provides a coordinate or coordinate reference (e.g. a combination of expiration, strike, and/or tenor), plus a value and some optional quotation characteristics.

The Pricing Data Point Coordinate allows a choice of index dimension.

16.5.4.10 Markets

A market collects a set of the above pricing structures to provide an environment for valuing a set of assets.

It contains:

• A set of benchmark quotes for benchmark instruments, such as FX rates and IR indices.
• A set of pricing structures and their associated valuations.
• A set of benchmark pricing methods, which associate benchmark assets with corresponding pricing structures. These, for example, allow the forecast model for an interest rate index to be specified.

16.5.5 Risk Definition

16.5.5.1 Overview

Contains definitions relating to sensitivities and valuation scenarios.

16.5.5.2 Sensitivity Set Definitions

The Sensitivity Set Definition describes a set of related sensitivities, providing a name, a set of characteristics, a reference to the valuation scenario, a reference to the pricing input (e.g. to the yield curve), and a set of definition of the individual sensitivities.

16.5.5.3 Sensitivity Definitions

The Sensitivity Definition is used to define each individual sensitivity. It can contain a name and a valuation scenario (if these are different from those of the Sensitivity Set Definition), as well as either an explicit definition of the derivatives that was computed, or a listing of the term structure point or coordinates that the sensitivity corresponds to.

16.5.5.3.1 Pricing Parameter Derivative

The Pricing Parameter derivative describes a single partial derivative. It indicates the pricing parameter to which the sensitivity is computed, the units of the reported value, and how the derivative is computed (numerically or analytically).

16.5.5.3.2 Derivative Formula

The derivative formula describes how to compute a derivative from a set of partial derivatives. It is normally only required for complex derivatives, such as Hessians, cross-gammas, etc.

16.5.5.4 Valuation Scenario

Valuation scenerios used (requested/reported) in this valuation set. E.g., the EOD valuation scenario for a particular value date. Used for the first occurrence of a valuation scenario in a document.

16.5.5.4.1 Pricing Parameter Shift

The pricing parameter shift describes how a pricing parameter can be shifted, e.g. to define a valuation scenario.

16.5.6 Query Portfolio

The QueryPortfolio type allows a portfolio to be created by grouping together trades that meet specific criteria. These criteria are defined by one or more elements of type QueryParameter. A QueryParameter contains a triplet consisting of elements of type QueryParamterId, QueryParameterValue, and QueryParameterOperator. A queryParameterId element will state a specific criteria such as product, or payment date, from a list defined by attribute queryParameterIdScheme. The queryParameterValue for that stated queryParameterId will provide a value for comparison such as swap, or 20040923, and the queryParameterOperator will define the nature of the comparison such as equals, or greater than, from a list defined by attribute queryParameterOperatorScheme.

A queryPortfolio element identified as port1 by its id attribute that is composed of swap trades with payment dates greater than 20040923 would be created using the following XML segment:

<queryPortfolio id="port1">
	<queryParameter>
		<queryParameterId queryParameterIdScheme="http://www.fpml.org/spec/2004/query-parameter-id-1-0">product</queryParameterId>
		<queryParameterValue>swap</queryParameterValue>
		<queryParameterOperator queryParameterOperatorScheme="http://www.fpml.org/spec/2004/query-parameter-operator-1-0">equals</queryParameterOperator>
	</queryParameter>
	<queryParameter>
		<queryParameterId queryParameterIdScheme="http://www.fpml.org/spec/2004/query-parameter-id-1-0">PaymentDate</queryParameterId>
		<queryParameterValue>20040923</queryParameterValue>
		<queryParameterOperator queryParameterOperatorScheme="http://www.fpml.org/spec/2004/query-parameter-operator-1-0">greater than</queryParameterOperator>
	</queryParameter>
</queryPortfolio>

                          

The queryParameters within a queryPortfolio are implicitly ANDed together. Query Portfolios can also be created by defining queryPortfolio elements that are children of another queryPortfolio. In this case the child queryPortfolios are ORed together.

A queryPortfolio element identified as Port3 by its id attribute that is composed of swap, or equitySwap trades with payment dates greater than 20040923 would be created using the following XML segment:

<queryPortfolio id="port3" >
	<queryPortfolio id="port1">
		<queryParameter>
			<queryParameterId queryParameterIdScheme="http://www.fpml.org/spec/2004/query-parameter-id-1-0">product</queryParameterId>
		                              <queryParameterValue>swap</queryParameterValue>
		                              <queryParameterOperator queryParameterOperatorScheme="http://www.fpml.org/spec/2004/query-parameter-operator-1-0">equals</queryParameterOperator>
		</queryParameter>
		<queryParameter>
			<queryParameterId queryParameterIdScheme="http://www.fpml.org/spec/2004/query-parameter-id-1-0">PaymentDate</queryParameterId>
			<queryParameterValue>20040923</queryParameterValue>
			<queryParameterOperator queryParameterOperatorScheme="http://www.fpml.org/spec/2004/query-parameter-operator-1-0">greater than</queryParameterOperator>
		</queryParameter>
	</queryPortfolio>
	<queryPortfolio id="port2" >
		<queryParameter>
			<queryParameterId queryParameterIdScheme="http://www.fpml.org/spec/2004/query-parameter-id-1-0">product</queryParameterId>
		                             <queryParameterValue>equitySwap</queryParameterValue>
		                             <queryParameterOperator queryParameterOperatorScheme="http://www.fpml.org/spec/2004/query-parameter-operator-1-0">equals</queryParameterOperator>
		</queryParameter>
		<queryParameter>
			<queryParameterId queryParameterIdScheme="http://www.fpml.org/spec/2004/query-parameter-id-1-0">PaymentDate</queryParameterId>
			<queryParameterValue>20040923</queryParameterValue>
			<queryParameterOperator queryParameterOperatorScheme="http://www.fpml.org/spec/2004/query-parameter-operator-1-0">greater than</queryParameterOperator>
		</queryParameter>
	</queryPortfolio>
</queryPortfolio>
                              

A queryPortfolio may either consist of queryParameters or other queryPortfolios, but not both.

16.5.7 Valuation Messaging

16.5.7.1 Introduction

The “fpml-reporting-x-y.xsd” subschema contains definitions relating to requesting valuations and reporting them in the form of messages.

This includes:

• TradeValuationItem
• PortfolioValuationItem
• RequestValuationReport
• ValuationReport
• PositionReport

16.5.7.2 Messaging Guidelines for 'Valuation Report' and 'Position Report'

The FpML Pricing and Risk definitions include two types of messages for reporting valuations. PositionReport and ValuationReport should be used under certain criteria.

• The PositionReport is a relatively simple structure intended to link trade economics and valuation information for applications that require notification of the current open positions and their valuations. It is not intended for complex risk reporting applications.
• The ValuationReport is a structure that groups related valuation information and supports anywhere from simple to complex reports. It is intended to be used when the primary application is to report valuations and sensitivities and not trade economics.

These guidelines are provided to assist implementers on the correct valuation message usage.

Use the ValuationReport in any of the following cases:

• When reporting portfolio-level information
• When reporting trade level valuations without the trade economics, e.g. a list of NPVs for a large number of trades.
• When reporting sensitivities
• When reporting on valuation scenarios, such as stress tests
• When providing market inputs
• When responding to a ValuationRequest message

Use the PositionReport message:

• When providing both trade economics and valuations together
• When providing a statement of current position, rather than any kind of what-if analysis
• When performing portfolio reconciliation

16.5.7.3 TradeValuationItem

A trade valuation item identifies a trade or trades to be valued, and contains a valuation set that describes the required valuation measures. If the trade not defined, the measures defined by the valuation set are requested for all trades in the relevant portfolio.

16.5.7.4 PortfolioValuationItem

A portfolio valuation item identifies portfolio to be valued, and contains a valuation set that describes the required valuation measures.

16.5.7.5 RequestValuationReport

This is a request message for requesting portfolio and/or trade valuations. It contains portfolio and/or trade valuation items that are requested.

16.5.7.6 ValuationReport

This is a response message, sent in response to a “RequestValuationReport” message. It contains portfolio and/or trade valuation items and optionally market data.

16.5.7.7 PositionReport

This is a notification message to support position reporting. It can send one or multiple positions. It implements the requirements defined by DSWG for position reports.

It contains:

• Version attribute
• Message header, giving addressing and message identification information
• An optional asOfDate, identifying the date for which the report has been prepared.
• An optional data set name, to assist subdividing a feed into multiple files.
• A set of default quotation characteristics, which can include for example the default reporting currency for NPV, the market side (mid/bid/ask), etc.
• A collection of positions, including valuation information.
• The parties referenced by the trades or involved in the reporting process.

16.5.7.7.1 Position

This type is used to hold individual positions. Currently only positions based on single OTC contracts are used.

It contains:

• Information about the roles of the parties with respect to reporting the positions.
• The components that create this position, currently a trade or a reference to a trade.
• Position level scheduled dates, such as final payment dates, in a simple and flexible format.
• Valuations reported for the position, such as NPV or accrued interest. The asset/object references in the valuations should refer to the deal or components of the deal in the position, e.g. legs, streams, or underlyers.

16.6 Use Cases/Examples

Pricing and Risk Use Cases/Examples are available at fpml-5-7-examples.html

16.7 Glossary

Many of the terms used in this document can be, and often are, interpreted in a wide fashion throughout the derivatives industry and in particular in the context of derivatives pricing and risk management systems and technology. Often, the same term may be used to convey similar but subtly different concepts in two different institutions. This section attempts to define what various common terms used within this document are meant convey.

16.7.1 Valuation

The act of calculating one or more ‘Valuation Measures’ for a trade.

16.7.2 Risk

The exposure of the value of a trade to one or more non-deterministic variables.

16.7.3 Valuation Measure

A value that can be calculated for a trade at some given point in time. Valuation Measures may be generically applicable for all trade types, for example Present Value, or may be specific to certain trade type, for example Accrued Interest or Yield. Valuation Measures may vary from one day to the next, distinguishing them from static trade information such as maturity date, counterparty etc.

16.7.4 Risk Measure

A particular type of ‘Valuation Measure’ that measures the exposure of the value of a trade to a particular variable or set of variables. Examples include Interest Rate Sensitivity, Credit Spread Sensitivity, VAR, DEAR, RAROC, Peak Credit Exposure.

16.7.5 Market Environment

A term that refers to the complete set of market data required (or available) to value a trade or portfolio. A Market Environment is made up of one more ‘Market Data’ elements.

16.7.6 Market Data

A list of related market data values that are typically grouped together for pricing purposes. Examples include an Interest Rate Yield Curve, a Credit Spread Curve, a collection of FX spot rates, a Volatility Surface, a term curve of Discount Factors or a Default Probability Curve.

16.7.7 Market Data Value

A single value associated with a particular market observable instrument or synthetically derived instrument. Examples might include the par rate for a 5 year Swap, the discount factor for a synthetic 5 year zero-coupon bond or the volatility of an At-the-Money 3-into-5 Swaption.

16.7.8 Pricing Data

Data required by a particular pricing model that is not directly associated with a market observable instrument or a synthetically derived instrument. An examples would be factor loadings for a multi-factor HJM/BGM Monte Carlo model.

16.7.9 Portfolio

An abstract definition of a group of trades.

16.7.10 Scenario

A grouping of one or more shocks to be applied to a ‘Market Environment’.

16.7.11 Sensitivity

A particular type of ‘Risk Measure’ that measures the sensitivity of the value of a trade to a change in one or more items of market data.

16.7.12 Shock

A change to be applied to a single ‘Market Data’ element within a ‘Market Environment’. The shock may affect one or more ‘Market Data Values’ within the specified ‘Market Data’ element.

16.8 Validation Rules

16.8.1 Introduction

This section describes how to define some validation rules that cannot be enforced by the schema. It is intended as input to the Validation Working Group.

16.8.2 Reference Integrity

Intra-document references have been typed in the schema (e.g. “ValuationScenarioReference” is a reference to a ValuationScenario.) In XML schema the type of the target cannot easily be enforced; this should be enforced in the valuation rules.

16.8.3 Date uniqueness

Frequently in pricing structures (especially curves) it is not allowed to have multiple values referring to the same point. For instance, there can be only one discount factor for a single DF curve on a given date.

16.8.4 Optionality

There are many optional elements in the schema. This means that it is difficult to ensure that some kind of necessary data are present. Here are some suggested checks:

• For a given AssetValuation, a ValuationScenarioReference should be supplied either directly or in the containing ValuationSet.
• If the marketEnvironmentIncluded flag is true, a market environment should be included.

16.8.5 Names/Definitions

For sensitivities, either the name or the definitionRef attribute (or both) must be filled in. It is not easy to enforce this requirement in the schema.

16.8.6 Consistency of definitions/references

Where there are two ways to traverse references upward through parallel structures, the resulting destination must be the same. For example, assume that a Sensitivity has a definitionRef to a SensitivityDefinition. This is contained within a SensitivitySetDefinition. If the SensitivitySet that contains the Sensitivity also has a definitionReference, it must be the same SensitivitySetDefinition as before. Following is an illustration:

Similarly, there will normally be consistency between valuation scenario references in sensitivity definitions and those in sensitivity set definitions, if they are present in both.

16.9 Appendix: Design Decisions

This section discusses issues that had particular complexity in representation, together with options for resolving these issues and a rationale for the chosen solution

16.9.1 Abstract vs. Actual Products

16.9.1.1 Issue 1: Defining an abstract product

The FpML specification deals with actual trades, that is products that have been or are in the process of being traded between two counterparties. When it comes to Valuation, there is a need for abstract deals, representing typically what the Broker market is quoting. The question is how to represent these “abstract deals”.

Options:

• Define these abstract products from scratch. This can be done in two different ways:
  • a) Provide short definitions and rely on market convention. At the extreme, these could be only names, e.g. SWAPUSD-10Y. The advantage is that the task can be carried out relatively fast, counting on the fact that the number of abstract deals needed is small. The disadvantage is that relying on market conventions, can potentially lead to a disagreement between two parties.
  • b) Provide a thorough definition. This would avoid ambiguity but it means the PRWG could potentially have to redo a large part of what the a FpML product group has already done.

Both of the above (a,b) cases would require that systems be enhanced to parse these new definitions.

• Reuse the FpML standard to define abstract trades. Disadvantages related to this approach include:
  • a) Some elements in the FpML standard are irrelevant for abstract products (for example parties).
  • b) Some elements must be “tweaked” to accommodate specificity of the abstract trades. Typically, an abstract trade is usually defined as a “sliding maturity” product (the case of futures being more ambiguous) whereas a real deal has a converging maturity. Dates accommodates the latter, tenors the former.
  • c) These definitions are verbose.
  • d) Some abstract deals are not defined by FpML (typically the discount factor of maturity T is a very useful concept when it comes to valuation).
  • Even with the above (a,b,c,d) issues, there are noticeable advantages to this approach including :
  • a) Leveraging the existing standard and reusing existing definitions, would avoid redundant work and mistakes.
  • b) Enhancing systems that already process FpML to deal with abstract products is an easier task.

16.9.1.2 Issue 2: Use of tenors instead of absolute dates

The main difference of abstract deals with FpML products is that most of the times these deals are “sliding” instead of “converging”, that is their maturity is not fixed and they cannot be defined in terms of dates but in terms of “tenors”.

16.9.1.3 Issue 3: Stub definitions

In FpML, the stub is defined in terms of dates (FirstRegularPeriodStartDate...). Since in abstract deals this is not possible we must define the stubs a priori. There are implicit market conventions for these but they are rather loosely defined. A stub can be placed:

• at the beginning
• at the end
• both

The term of a stub can be:

• short, which means shorter than the regular period
• long

It is always possible to create a short stub from a long one by creating an extra-regular period. The reciprocal is true, by aggregating the short period to the next or previous regular period.

The market convention tends to refuse to have a stub that is “too” short (say 10 days).

The only reason why you would have a stub at the beginning and at the end is because the Roll Convention is not on the start or termination date.

16.9.2 Product and Trade Identification and Description

16.9.2.1 Issue 1: Trade Summaries

The example valuation and risk reports generally include some kind of trade information summary, but FpML does not currently support this type of summary.

16.9.2.2 Options:

• Create a summary view for required products.
• Include full trade details
• Reference trade via ID or xml reference.

16.9.2.3 Solution:

Reference the trade via ID or xml reference. Do not create a trade summary.

16.9.2.4 Rationale:

Trade summaries are mostly useful for humans, not computers. FpML should provide a useful, forward-looking solution, not try to mechanize the past.

16.9.2.5 Issue 2: Trade Identification

FpML allows trades to be identified by multiple external IDs (tradeIdentitifier/partyTradeIdentifier). Trades can also be identified by an internal XML document identifier (as long as the trade is in the same FpML document.).

16.9.2.6 Options:

• 1. Allow single external ID per trade
• 2. Allow multiple external IDs per trade
• 3. Use XML internal ID for each trade.

16.9.2.7 Solution:

Number 2

16.9.2.8 Rationale:

Most valuation reports will be for a large number of trades not sent in the same document, so an internal XML ID is not useful, and there is no FpML-standard document identification scheme.

16.9.3 Pricing Inputs

16.9.3.1 Issue 1: Term Representation

It will be necessary to be able to represent term structures for a variety of pricing inputs as well as for risk reports. There are a variety of ways to represent the time dimension for the term structure.

16.9.3.2 Options

• Explicit date
• Tenor (number plus period)
• Reference to another structure that contains a date.
• Number of days
• Year Fraction

16.9.3.3 Solution:

• For yield curves:
  • Date is mandatory
  • Tenor is optional
  • Reference to another structure is optional
  • Year fraction is optional

• For volatility surfaces
  • Tenor is normally required.
  • Date is optional.
  • Reference to another structure is optional
  • Year fraction is optional

• For credit spread / recovery rate curves
  • Date is mandatory
  • Tenor is optional
  • Reference to another structure is optional
  • Year fraction is optional

16.9.3.4 Rationale:

• Dates are most useful for yield curves and most explicit.
• Tenors are the market convention for credit spread curves, but use of dates as default will make the curves consistent with yield curves.
• For volatility surfaces, precise dates aren’t so important and using tenor provides better usability.
• Year fraction is a calculated value and can’t necessarily be supported by all systems.
• Number of days could be supported by using the tenor (in days).

Comment: it would be more consistent to make the same index (e.g. date) mandatory for everything. If someone wanted to roll the vol surface to another day, they could do this as long as the sender had supplied a tenor.

16.9.3.5 Issue 2: Ability to handle different dimensionality for pricing inputs

• Some pricing inputs, especially volatility representations, can vary in dimensionality. (points vs. curves vs. surfaces vs. cubes). We need to be able to accommodate this.
• There is considerable similarity across pricing inputs in the need for term structures of various dimensionality. It would be nice to reuse this.

16.9.3.6 Options:

• Separate structures for each pricing input/number of dimensions.
• Single n-dimensional structure
• Generic ability to add another term structure dimension to an existing structure.

16.9.3.7 Solution:

Generic ability to add another term structure dimension to an existing structure.

16.9.3.8 Rationale:

• Generic structure may be too abstract to handle easily.
• Separate Structures don’t provide reuse.

16.9.3.9 Issue 3: Dates used within pricing structures

For a single market input (e.g. curve), there are multiple dates that can describe the data. These include:

• Date of input points – date data was retrieved from.
• Base date – date used a base for computation. (Typical this will be the same as above, but not always.)
• Spot date – base date plus settlement lag for the currency. (“days to spot”).
• Date/time generated - the date and time the calculation was actually performed.

Which of these should be required and/or optional?

16.9.3.10 Solution:

• Base date should be required
• Input data date should be optional; normally this would not be supplied if the same as base date.
• Spot date would be optional
• Date generated would be optional.

16.9.3.11 Rationale:

• Base date is necessary for understanding the meaning of the values expressed by the curve.
• Spot date is derivable from base date.
• Input data date is normally same as base date, except in unusual cases.
• Date generated is useful for tracking and sequencing purposes, but has no other processing significance.

16.9.3.12 Issue 4: Compactness of term structure indexes

FpML architectural guidelines and standard XML modeling practice require putting business data in elements. However, for repeated numerical data like term structures, i) this produces very verbose, possibly difficult-to-read XML, and ii) the term structure indexes can be thought of as meta-data anyway, since the real data is the numerical value.

16.9.3.13 Options:

1. Indexes in elements reusing existing FpML structures, e.g.:

<dfpoint>
	<date>2004-06-01</date>
<tenor>
<periodMultiplier>1</periodMultiplier>
</period>D</period>
</tenor>
<value>0.995</value>
</dfpoint>
                                

2. Indexes in elements using more compact structures, e.g.:

<dfpoint>
	<date>2004-06-01</date>
<tenor>1D</tenor>
<value>0.995</value>
</dfpoint>
                                

3. Indexes in attributes:

<df date=”2004-06-01” tenor=”1D”>0.995</df>
                                

16.9.3.14 Solution:

We have chosen to use the fully expanded form, but to allow referencing some of the coordinates so that the information does not have to be repeated.

16.9.3.15 Rationale:

Compromise that preserves FpML design rules but allows a more compact representation.

• solution 1: 134 characters = 3.1 x
• solution 2: 79 characters = 1.8 x
• solution 3: 43 characters = 1.0 x

16.9.3.16 Issue 6: Handling of currency conversion

16.9.3.17 Solution:

FX rates need to be treated as pricing / reporting inputs

16.9.3.18 Rationale:

FX conversion is often required in reporting values and risks.

16.9.3.19 Issue 7: Handling of credit default swap basis conventions

This applies to credit default swaps and recovery rates. Are all CDS basis conventions required for specification of credit curves?

16.9.3.20 Option 1: partial description

• Reference entity – underlying entity used to determine default condition. Should include the full name, RED identifier and/or other standard identifier. For index transactions, a unique identifier (e.g. DJ TRAC-X NA 100 Series 2)
• Debt seniority – One of the following: senior, T3 Subordinated, LT2 Subordinated, UT2 Subordinated, T1 Subordinated
• Secured – Yes / No flag if the protection is on secured debt.
• Currency – Currency of the protection payout
• Restructuring event - no restructuring, modified restructuring, modified modified restructuring, etc.
• Optional descriptor – ability to add additional terms to distinguish this set of market data

16.9.3.21 Option 2: full description:

Contract Term	Description	Options/Value	Defaults
Reference Entity	Underlying entity used to determine default condition. Should include the full name, RED identifier and/or other standard identifier	Text name of the underlying entity; RED identifier of the underlying entity; Other identifier of the underlying entity	N/A
Credit Event	The material credit event. Multiple selection and at least one required. Modified Restructuring is where a Restructuring event is allowed but a Restructuring Maturity Limitation applies	Bankruptcy; Failure To Pay; Restructuring; Modified Restructuring; Modified-Modified Restructuring; No Restructuring	Bankruptcy; Failure To Pay; Restructuring
Seniority	The seniority of the deliverable obligation. Single selection and required.	Senior; Sub Tier 1; Sub (Upper Tier 2); Sub (Lower Tier 2); Sub Tier 3	Senior
Secured Flag	Whether the deliverable obligation is secured or unsecured. Single selection and required.	No
Currency	The currency of denomination of the deliverable obligation. Single selection and required.	List of supported currencies	USD
Obligation Category	What sort of reference payment will trigger a credit event. Single selection and required.	Payment; Borrowed Money; Reference Obligations Only; Bond or Loan; Bond; Loan;	Borrowed Money
Deliverable Obligation Category	What sort of obligation may be delivered in the event of the credit event. Single selection and required.	Payment; Borrowed Money; Reference Obligations Only; Bond or Loan; Bond; Loan;	Bond or Loan
ISDA CD Definitions	Specifies what ISDA document and supplement (if any) is applicable to this curve. Multiple selection and required.	1999 ISDA; 1999 Successor Supplement; 1999 Convert Supplement; 1999 MR Supplement; 2003 ISDA	1999 ISDA; 1999 Successor Supplement; 1999 Convert Supplement; 1999 MR Supplement;
Deliverable Exclusions	Security types excluded from delivery of this contract	Exclude zero coupon; Exclude convertible; Exclude floating rate note	None
Obligation characteristics	Types of obligations that may be considered for default determination	Pari Passu Ranking; Not Contingent; Not Domestic Issuance; Not Domestic Currency; Not Sovereign Lender; Listed; Not Domestic Law; Specified Currency OECD; Specified Currency non-OECD	Multiple selection
Deliverable obligation characteristics	Types of securities that can be delivered to the protection holder upon trigger of the contract	Pari Passu Ranking; Not Contingent; Not Domestic Issuance; Not Domestic Currency; Not Sovereign Lender; Listed; Not Domestic Law; Specified Currency OECD; Specified Currency non-OECD; Accelerated or Matured; Not Bearer	Multiple selection

16.9.3.22 Option 3: fpml CD 4.x specification:

Refer to the existing fpml CD v4.0 specification for all references to unique terms defining CDS instruments

16.9.3.23 Solution:

Option 1: Use the partial description.

16.9.3.24 Rationale:

Simplified approach captures most relevant components for determining pricing basis. Can be expanded at a later time using the optional field (or via amendments to the specification).

16.9.4 Valuation Reporting

16.9.4.1 Issue 1: How much detail is needed for the NPVs?

16.9.4.2 Options:

• Pay vs. receive?
• Cash flows on value date
• Currency translation
• Pricing currency
• Valuation date
• Underlying security or benchmark price if applicable
• Volatility and Delta if applicable

16.9.4.3 Solution:

Use Asset Measures to allow a variety of results to be returned.

16.9.4.4 Rationale:

This allows a user to extend the standard to provide more types of returned values.

16.9.4.5 Issue 2: Reporting Currency

Reporting should be in a single specified currency, with currency conversion rates and the source of those rates identified for any trades not in the reporting currency.

16.9.5 Risk Types and Measures

16.9.5.1 Issue 1: Risk types and measures

Need to specify the risk type and measure of the submitted risk figures.

Risk Types

There are a number of broad market risk types.

• Interest Rate
• Credit Spread
• FX Rate
• Equity Price
• Commodity Price

Risk Measures

For each of the broad risk types a number of risk measures are used. Risk measures are typically generated by perturbing the valuation parameters and calculating the effect on the net present value of the trades or portfolio.

• Delta, first order sensitivity to a shift in the valuation parameter
  • Parallel shift (applicable to all risk types)
  • 1-dimensional, bucketed risk (applicable yield curves and credit curves)
• Gamma, second order sensitivity to a shift in the valuation parameter
  • Parallel shift
  • 1-dimensional
• Vega
  • Parallel shift
  • 2 or 3 dimensional, risk against each individual entry in the volatility surface/cube
• Scenario
  • A single number representing the sensitivity to a shift in the valuation parameters defined by a (separately) specified scenario

16.9.5.2 Solution

We therefore need to be label a risk figure with an entry from the following hierarchy.

• Market Risk
  • Interest Rate
    • Delta
    • Gamma
    • Vega
    • Scenario
  • Credit Spread
    • Delta
    • Gamma
    • Vega
    • Scenario
  • FX Rate
    • Delta
    • Gamma
    • Vega
    • Scenario
  • Equity Price
    • Delta
    • Gamma
    • Vega
    • Scenario
  • Commodity Price
    • Delta
    • Gamma
    • Vega
    • Scenario
  • Scenarios cross risk type
• Credit Risk
  • Current Exposure
  • Potential Exposure

For yield curves, the shifts can be performed in either

• Input Rates
  • The yield curve benchmark prices
• Output rates of resulting term structure of
  • The resulting term structure of implied
    • Zero Rates
    • Forward Rates
    • Par Rates

Other valuation parameters typically do not have both input and output values.

16.9.5.3 Solution

The risk data must include a reference to the perturbed node of a valuation parameter. And the node can be an input node or an output node.

References can be either to a bucket node / matrix element or it can be reference to the full yield curve / volatility / object. In the latter case it is a parallel shift greek.

16.9.5.4 Issue2: Shift size

Shift sizes can potentially be a subject for discussion. Either we specify one standard definition or we include the shift size in the message.

16.9.5.5 Solution

In order to keep the complexity down, we define the shift sizes to be

• Delta and gamma sensitivities are based on shift size
  • interest rates 1 basis point (0.01%)
  • credit spreads 1 basis point (0.01%)
• Vega
  • all risk types 1%
• Scenarios
  • The shift size for each individual risk factor is specified in separate scenario representation which includes a large set of references to the nodes in valuation parameters and shift sizes.

16.9.5.6 Issue 3 Shift method

A number of different shift methods are used when calculating sensitivities (central differences, right hand side, scaling etc).

16.9.5.7 Solution

It is not our ambition to harmonize calculation methods but rather to reach a common understanding of the resulting numbers. We therefore leave out the applied method from the message.

16.9.5.8 Issue 4 Risk currency

The currency in which a risk figure is expressed is needed.

16.9.5.9 Solution

Typically the risk figures are expressed in the same currency as the currency of the trade. Trades involving more than one currency will have its risk expressed separately against yield curves etc for each currency. The currency element should be part of the message.

17 COLLATERAL MANAGEMENT ARCHITECTURE

17.1 Collateral Management Scope

The FpML Collateral Working Group has extended the FpML standard to cover the following business processes:

• Margin Call
• Collateral Substitution
• Interest

17.2 Availaible in Reporting View

Collateral Management support is only available in the reporting view. See the Reporting view for Collateral documentation, schema, and examples.

17.3 Introduction

This documentation is the FpML Collateral Working Group recommended extension of the FpML standard to support the definition of standard messages for the Collateral Management business process. This work builds on the requirements defined by the ISDA Collateral Committee in the November 12, 2009 publication Standards for the Electronic Exchange of OTC Derivative Margin Calls. The following sections describe the margin call, substitution and interest processes.

17.4 Collateral Concepts

The following concepts were applied in the interpretation of the ISDA Collateral Working Group requirements to FpML standard syntax.

17.4.1 Use Messaging as an Enabling Technology

The FpML messages have been designed to provide enough information to allow Collateral Management Systems to automatically process calls based on bilateral rule definition.

17.4.2 Support Real World Customer and Collateral System Needs

The FpML messages embrace the differences between organizations, business lines, service delivery and collateral systems (in house built and 3rd party vendor). The message definition supports the diversity of the collateral industry allowing organizations to communicate both standard and non-standard calls such as Segregated Independent Amounts and Gross Margin Calculations.

17.4.3 Unambiguous Messages

FpML avoids the use of -/+ amounts, all amounts have corresponding indicators of directions i.e. exposed party, due to, held by and supports message neutrality – i.e. values not expressed in caller terms to allow for machine to machine communication.

17.4.4 Variation Margin and Segregated Independent Amount

The FpML proposal provides the ability to identify separate margin requirements that relate to segregated independent amount and/or variation in the same margin call messages. The use of Segregated Independent Amount results from the practice that became more prevalent post Lehman Brothers and as described in the ISDA White Paper on Independent Amount (ISDA Collateral Committee web page, Independent-Amount-WhitePaper-Final.pdf ).

This mechanism was set up so that organizations could avoid having to set up two agreements and send two separate messages when calling for, and processing, both Variation and Segregated Independent Amount margin requirements. The way that the messages are defined however does not preclude organizations from still representing the margin requirements as separate and reflects the fact that some organizations will define agreements as separately.

The ability to process both requirements in a single message is not restricted to just the requestMargin message but applies to all messages. Therefore an organization can respond to a margin call for Variation Margin and Segregated Independent Amount in a single message indicating they can fully agree to the segregated requirement but only partially agree to the Variation requirement.

17.4.5 Margin Call Status

The FpML proposal requires only a single message to respond to a margin call request. This response known as the marginStatus message allows the responder to state the undisputed amount they can agree to in respect to the margin requirements received in the requestMargin message. The result of this approach will require the consumer of the marginStatus message to calculate whether or not the responder had fully agreed, partially disputed or fully disputed. This would be done by comparing the undisputed amount to the original call amount.

This approach was taken to avoid the potential ambiguity of the original ISDA Working Group requirement which could have resulted from a partial agreement message being sent where the agreed amount was then stated as 0 or the same amount as the original call amount. The use of an explicit undisputed amount makes it clearer as to the responders’ intention. It was noted that the consumer of a message that simply stated fully disputed would still have needed to interpret this to be an agreed amount of zero and used this in calculating disputed amounts for example.

The message reflects more a machine to machine interaction than a human to human interaction where you would naturally say I agree to your call or I dispute your call or I partially agree to x amount.

17.4.6 Support Full Disclosure for Effective Risk Mitigation

Both the requestMargin and marginCallStatus messages employ a common model to represent the details of the margin calculation from either the issuer of the requestMargin message or the responder to the requestMargin message in the marginCallStatus message.

• The issuer is able to provide details of exposure, independent amount, collateral and margin terms related to how they calculated the call make.
• The responder to the requestMargin message can provide as much detail as they are willing to disclose about how they decided upon the undisputed amount with which they respond to the request.

This ability to disclose more information beyond the requirements in the ISDA Working Group requirements is designed to give as much information as possible to the consumer of the marginCallStatus message to be able to understand the response and to avoid potential manual processes that could occur from a reduced message content transmission.

For example, the FpML proposal would reduce the need for an email or telephone exchange if the responder replied to the issuer of the call with an undisputed amount that was less than the original call amount and where the details of the threshold were provided and this was the cause of the partial dispute. In the ISDA Working Group requirements the Threshold and other Margin Terms such as MTA or Rounding were not required.

The advantage of this approach is that it enables a machine to machine comparison of the two sets of margin details to see differences in the results of the two calculations making exception detection simpler and allowing for enhanced STP options strategically.

17.4.7 Separation of Collateral Proposal from Margin Call Response

The FpML proposal separates out the response to the requestMargin message to details of what the responder is willing to agree to (marginCallStatus) and the details of what collateral they can provide to meet agreed amount (requestCollateralAcceptance).

This approach was taken to support the scenario where the responder wants to notify the issuer of the requestMargin message that they partially dispute the margin call but do not yet know what collateral is available to meet the undisputed amount. So that the dispute process can start as soon as possible the marginCallStatus message can be sent and the subsequent requestCollateralAcceptance will be sent once the collateral has been identified.

This breaks down the response process in to two pieces and provides message flow flexibility because the same requestCollateralAcceptance can be used for resubmission of a proposal following the rejection or counterproposal of the margin call issuing party.

17.4.8 Counter Proposal

The FpML proposal assumes that only the party that received the requestMargin message can send a collateral proposal by using the requestCollateralAcceptance message. It is also assumed that only the issuing party can respond to the requestCollateralAcceptance using the collateralAcceptanceStatus message. This keeps the relationship between the proposer and responder the same throughout the margin call process. This reduces the number of message types required to support the collateral proposal process to two.

The FpML proposal allows for the receiver of the requestCollateralAcceptance message to respond as to whether they accept or reject the proposal. They can also respond, in the case of a rejection with details of the collateral they would like to receive that is different than that being proposed.

The party that sent the requestCollateralAcceptance can then review the expected collateral request from the issuer of the call and choose to send a revised requestCollateralAcceptance message representing the counter proposal details.

17.4.9 Expected Collateral

Expected Collateral is supported in both the requestMargin and collateralAcceptanceStatus messages. They allow the message user to request collateral they would prefer to receive back in the case of returns, allowing for the explicit definition to the instrument identifier level. For deliver expected collateral requests only general collateral types and comments are supported because the user of the message does not know the exact holdings of the other party to be able to explicitly request a specific ISIN or Cusip be delivered.

17.4.10 Dispute Messages

The FpML proposal does not include support at this stage for the MC12 Request Portfolio and MC13 Acknowledgement Portfolio Sent messages because the group identified that this requirement is evolving as a result of the work of the ISDA Working Group on the Dispute Resolution Protocol (see the ISDA Collateral Committee web page) and would be best supported by a set of additional message sequences that reflects the evolving needs of dispute resolution including the use of bilateral and unilateral reconciliation services, the identification of multiple reasons for a dispute beyond the mark to market amounts and the relative maturity of different reconciliation and resolution approaches for each of those reasons. I.e. exposure vs. collateral reconciliation approaches.

17.4.11 Retraction, Acknowledgement and Exception Messages

The FpML proposal allows for retraction of all messages i.e. requestMargin, marginCallStatus, requestCollateralAcceptance, collateralAcceptanceStatus, disputeNotification. There are is also an acknowledgement message to allow the receiving party to acknowledge receipt of the message. The exception messages are used to notify the sending party of issues processing the message on the receiving side.

17.5 Margin Call Process

The Margin Call process defined in the ISDA Collateral Committee document covers the following message flow:

17.5.1 Mapping Table of ISDA Collateral Committee Messages to FpML Collateral Working Group Messages

The ISDA Collateral Committee Electronic Messaging Working Group defined 15 messages that represented the collateral Margin Call process. The following table shows the mapping of these 15 messages to their FpML equivalent.

ISDA Collateral Committee	FpML
MC1 - Issuance of Margin Call	requestMargin
MC2 - Rescind Issued Call	requestMarginRetracted
MC3a - Accept Call & Propose Collateral	marginCallStatus, requestCollateralAcceptance
MC3b - Accept Call	marginCallStatus
MC3c - Propose Collateral	requestCollateralAcceptance
MC4 - Rescind Call Response	marginCallStatusRetracted
MC5 - Full Dispute	marginCallStatus
MC6 - Partial Dispute	marginCallStatus, requestCollateralAcceptance
MC7 - Accept Notification of Collateral	collateralAcceptanceStatus
MC8 - Reject Notification of Collateral & Counter Propose	collateralAcceptanceStatus
MC9 - Accept Counter Proposal	collateralAcceptanceStatus
MC10 - Reject & Counter Propose	collateralAcceptanceStatus
MC11 - Acknowledge Dispute Notification	disputeNotification
MC12 - Request Portfolio	Out of Scope
MC13 - Acknowledgement Portfolio Sent	Out of Scope
No Equivalent	requestCollateralAcceptanceRetracted, collateralAcceptanceStatusRetracted, disputeNotificationRetracted

17.5.2 Proposed FpML Workflow

The following sequence diagram shows the proposed flow of FpML messages for the margin call process.

17.5.3 FpML Margin Call Messages

This section describes the different FpML messages that support the margin call process.

17.5.3.1 Margin Call Request (MC1) - requestMargin

The margin call request message, requestMargin, communicates the details of a margin calculation to the receiving party. This message supports the communication of both Variation Margin and Independent Amount requirements.

The main components of this message are as follows:

• Parties
  • marginCallIssuerPartyReference - The party issuing the margin call
  • marginCallReceiverPartyReference - The party receiving the margin call

• Agreement Details
  • Credit Support Agreement - The agreement executed between the parties and intended to govern the collateral arrangement for all OTC derivatives transactions between those parties.
  • Valuation Date - Close of Business date the Local Counterparty is valuing and issuing the margin call
  • Base Currency - Denomination currency as specified in the margin agreement

• MarginDetails.model
  • Mark to Market
    • Exposure - Consists of two elements, the first MarkToMarkExposureParty supports the definition of which party is the exposed party and which is the obligated party. Within FpML it is important to state both parties roll in the exposure details to avoid ambiguity. The parties referenced should be one of those defined in the Parties element. Therefore if Party A is the exposed party there Party Reference ID would be quoted and Party B would be the obligated party. The second element is the exposureAmount this is the amount to which the exposed party is exposed. This uses the Money type that can take but an amount and a currency.
    • Support for Gross Calculations - The mark to market model also supports the definition of the MarkToMarketConventionEnum. This allows two values Netted or Gross. When the value is Netted the exposureAmount is assumed to be the net market value of the portfolio (excluding independent amount, collateral, threshold and MTA). If Gross then two exposureAmounts could be provided one each for the two parties referenced in the Parties section respective exposure to each other. In the case of a Gross Margin Calculation both parties could be expected to call one other. Depending on the level of disclosure each party wishes to make they could decide to only provide the exposure amount from the perspective of the call they are making on the other party.
  • Independent Amount

    This element represents the aggregated independent amount related to a collateral agreement. In other areas of FpML independent amount has been used to define independent amounts related to individual trades within a portfolio.

    For the Collateral Messages the Aggregated Independent Amounts can be classified and quantified based on three types:

    • Trade - This is the total Independent Amount defined in the confirmations of individual trades. This would relate to the same Independent Amount defined in other FpML messages aggregated for a specific agreement.
    • valueAtRisk - A portfolio level Independent Amount that reflects portfolio change over a short time period using statistical techniques such as volatility and risk factor correlations. These amounts reflect the summation of independent Amounts due to Party A or Party B.
    • netOpenPosition - A portfolio level Independent Amounts related to a Parties Net Open Position (NOP). Net Open Position means the total of the Net Long FX and the Net Options in respect of each currency where: Net Long FX for any currency shall be the net amount (if any) of that currency which the Party "A" is long as against Party "B" in respect of all FX transactions.

    For each type it is necessary to define the giverPartyReference, the party that is required to post the independent amount and the takerPartyReference, the party that will receive the independent amount. The independent amount is defined in the paymentAmount element and a convention is provided. The convention can be NettedAfterThreshold, NettedBeforeThreshold or Segregated.

    Segregated Independent Amount is treated separately from Variation Margin. NettedAfterThreshold relates to independent amounts that are taken in to account once the exposure has been compared to the Threshold the residual being adjusted for any Netted After Threshold independent amount and before comparing to the collateral position. Netted Before Threshold is an additional amount that is applied to the exposure amount prior to comparison to the Threshold.

  • Margin Term - Margin Terms can be defined as they apply to Variation Margin and/or Segregated Independent Amount. For Variation Margin Terms a threshold, minimumTransferAmount and transferRounding are defined. For Segregated Independent Amount it is only necessary to provide a minimumTransferAmount and transferRounding. TransferRounding takes to elements direction and amount. The directions are either Up, Down or Closer. A currency can also be defined to represent the currency in which the margin terms are defined, which can be different to the baseCurrency.
  • Collateral - Collateral balances can be defined as they apply to Variation Margin, Segregated Independent Amount or both. Within each of these collateral categories it is possible to define the pendingCollateral, collateral that is currently agreed to be settled but not yet settled and heldCollateral, collateral that has already settled. For pending collateral it is required to supply details who is the giver of the collateral and the taker of the collateral in addition to the amount. For held collateral it is required to supply the holding party and the posting party in addition to the amount that is held.
• Margin Requirement

  This composite type supports the breakdown of the margin call in to its various requirements components. It is possible to define requirements for Variation Margin and/or Segregated Independent Amount. For each requirement type a deliver and or return element can be designated. A deliver or return will require the definition of the delivering party and the receiving party, the currency and the amount of the requirement. The margin requirement block supports up to 4 different requirement definitions:

  • Variation Delivery
  • Variation Return
  • Segregated Independent Amount Delivery
  • Segregated Independent Amount Return
• Margin Call Result This composite type is really just an aggregation of the data supplied in the Margin Requirement composite type. It allows for the sum of the deliver and return requirements in to a single Margin Call Amount for Segregated Independent Amount and/or Variation Margin. It is necessary to confirm the giver party and the taker party in addition to the margin call amount. This block exists more for usage/comparison to the other messages i.e. the comparison of Agreed Amount in the MarginStatus message to determine whether there is partial or full acceptance or disputing of the margin call amount.
• Expected Collateral Expected Collateral allows for the definition of collateral that the party making the margin call would prefer to receive or have returned. This can be defined for the Variation Requirement and /or the Segregated Independent Amount Requirement. For deliveries only the type of cash i.e. USD or security type i.e. US Treasuries is expected to be defined. For the return the calling party will know what they posted and therefore can define the expected collateral down to the specific instrument identifier, currency and amount.

17.5.3.2 Rescind Margin Call (MC2) - requestMarginRetracted

This message is used to notify the other party that you wish to rescind a previously sent requestMargin message. This requires reference to the parties, the original message being retracted and the reason for retraction.

The retraction reason includes a description and a reason code. The reason codes include:

• NewerCalculations - New exposure and/or collateral related data received which means there is now a newer calculation. This message rescinds the original call and notifies of a new message to come
• PartyReferenceMismatch - The message was sent to the wrong party or for the wrong agreement
• RevisedMarginTerms - The margin terms have been updated and the original margin call is no longer accurate a new margin calculation will be delivered reflecting the change or the call is simply rescinded as the result is a no action

17.5.3.2.1 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.

Any response or follow up to this message should contain the same 'correlationId' definition.

The rescind margin call message (MC2) reuses the same correlationId that was set in the margin request (MC1) message.

The correlation mechanism is described in detail in section 3.2.9 “Message Correlation” of the Business Process Architecture.

17.5.3.3 Margin Call Response (MC3b/MC5/MC6) - marginCallStatus

This message is used by the party that received the requestMargin message to respond detailing the extent to which they agree with the requested margin amounts. This message includes the same MarginDetails.model that is used in the requestMargin message however the responding party expresses the details based on their own margin calculation. It is optional as to the amount of information the responding party wishes to disclose. The more information provided the easier it is to identify differences in calculation and therefore which data needs to be reconciled. This message will not include details of the actual collateral that is proposed to meet the amounts being agreed to, this is covered by the requestCollateralAcceptance message.

• Agreed Amount - The agreedAmount block allows the responder to detail the undisputed amount for any Variation Margin requirement and/or Segregated Independent Amount requirement they may have received in the corresponding requestMargin message. They will confirm who they believe the giving and taking parties are and the amount and currency of the agreement amount.
• MarginCallResponseReason - This element allows you to provide additional details about your response. This takes the form of a description and a reason code. The description can be used to give information that may help the receiver understand your response and could hold information about your calculation that is not obvious from your calculation details i.e. stating that you considered the call date to be a non valuation day. The reason code covers many dispute reason types so that you can specify explicit details that would complement the information that could be garnered from full disclosure of the margin details. The list of reason codes are as follows:
  • MarkToMarketMismatch
  • BaseCurrencyMismatch
  • CreditSupportAgreementMismatch
  • HeldCollateralMismatch
  • IndependentAmountConventionMismatch
  • MarkToMarketConventionMismatch
  • NetOpenPositionIndependentAmountMismatch
  • PartyReferenceMismatch
  • PendingCollateralMismatch
  • SegregatedIndependentAmountMinimumTransferAmountMismatch
  • SegregatedIndependentAmountRoundingMismatch
  • SegregatedIndependentAmountThresholdMismatch
  • TradeLevelIndependentAmountMismatch
  • ValuationDateMismatch
  • ValueAtRiskIndependentAmountMismatch
  • VariationMarginMinimumTransferAmountMismatch
  • VariationMarginRoundingMismatch
  • VariationMarginThresholdMismatch

  Note: the reason codes will be populated in case of dispute or partial dispute.

• Modeling MC3/MC5/MC6 The ISDA Collateral Working Group specified three different message options in response to a margin call request. These related to full acceptance, full dispute and partial dispute. These can be modeled in the marginCallStatus message as follows:
  • Full Acceptance - The agreed amount will be the same as the margin call amount for the requirement type i.e. Variation Margin or Segregated Independent Amount
  • Full Dispute - The agreed amount will be zero for the requirement type i.e. Variation Margin or Segregated Independent Amount
  • Partial Dispute - The agreed amount will be greater than zero but less than the call amount for the requirement type i.e. Variation Margin or Segregated Independent Amount

  Note that the following combinations are supported:

  • Fully Agree to Variation Margin and Segregated Independent Amount
  • Fully Dispute to Variation Margin and Segregated Independent Amount
  • Partially Dispute Variation Margin and Segregated Independent Amount
  • Fully Agree to Variation Margin and Fully Dispute Segregated Independent Amount
  • Fully Agree to Variation Margin and Partially Dispute Segregated Independent Amount
  • Fully Dispute Variation Margin and Fully Agree Segregated Independent Amount
  • Fully Dispute Variation Margin and Partially Dispute Segregated Independent Amount
  • Partially Dispute Variation Margin and Fully Agree Segregated Independent Amount
  • Partially Dispute Variation Margin and Fully Dispute Segregated Independent Amount

  It is also possible to respond to just the Variation Margin or Segregated Independent Amount requirements separately.

17.5.3.4 Rescind Margin Call Response (MC4) - MarginCallStatusRetracted

This message allows the sender of a MarginCallStatus message to rescind their response. This could be used prior to sending a revised message. Details are provided about the two parties involved and the reference to the marginCallStatus message being rescinded and retraction details can also be provided. The retraction reason includes a description and a reason code.

The reason codes include:

• NewerCalculations - New exposure and/or collateral related data received which means there is now a newer calculation. This message rescinds the original margin call response and notifies of a new message to come
• PartyReferenceMismatch - The message was sent to the wrong party or for the wrong agreement
• RevisedMarginTerms - The margin terms have been updated and the original margin call response is no longer accurate a new margin status message will be delivered reflecting the change

17.5.3.5 Collateral Proposal (MC3c) - requestCollateralAcceptance

The requestCollateralAcceptance message is used to communicate the details of collateral that the receiver of the requestMargin message is willing to provide to meet the obligations agreed to in the marginCallStatus message. The message supports provision of collateral details to meet Variation Margin and/or Segregated Independent Amount obligations. The message requires details of the margin call issuer and margin call receiver and the agreed amounts that are being satisfied by the collateral proposal.

For each margin type being satisfied the proposedCollateral.model is used.

This consists of choice to provide the collateral details for Variation Margin only, both Variation Margin and Segregated Independent Amount or Segregated Independent Amount obligation details only. For each obligation type the ProposedCollateral composite type is used. This consists of a choice to provide details of either Deliver details only, both Deliver and Return details or only Return details.

For each movement direction type the ProposedCollateralDeliveryReturn type is used to describe the movements being proposed this type includes details of the delivering and receiving parties and the types of collateral being proposed. Multiple movements can be defined for each movement direction type. There are three collateral type options:

• Cash
  For cash collateral the following details are provided
  • Currency - When proposing cash collateral the currency of the cash collateral being proposed i.e. USD cash
  • nominalAmount - The amount of cash to be moved
  • valueDate - The date on which the proposed collateral will be settled
  • marketValue - The value of the proposed collateral movement prior to the application of any haircut amount.
  • haircut - The amount to which the collaterals market value will be discounted to take into account the ability to realize the value of that collateral. This amount will be defined as a multiplier i.e. 97% would be represented as 0.97. Typically for cash this would be 1 (100%) however it is noted that cash collateral can be subject to a haircut and therefore has been provided to support all potential scenarios.
  • collateralValue - This is the value of the proposed collateral after the application of the haircut. This amount would be defined in base currency for ease of comparison to the agreed amount to which the proposal is being used towards satisfying.
• Security
  The security type consists of the following elements:
  • assetReference - This is the reference to an instrument that is defined in the Asset block. This is the asset to be moved.
  • valueDate - The date on which the proposed collateral will be settled
  • Quantity - To represent the quantity of collateral to be moved there is a choice to provide either a nominalAmount or use the UnitContract.model whereby the numberOfUnits and unitPrice are provided. The UnitContract.model is typically used to represent equities and the nominalAmount is used for bonds.
    • NominalAmount.model
      • nominalAmount - nominal amount of the collateral to be moved.
      • dirtyPrice - Bond dirty price, expressed in percentage points, 100 is the initial value of the bond.
    • UnitContract.model
      • numberofUnits - The number of units (index or securities) to be moved.
      • unitPrice - The price of each unit
  • marketValue - The value of the proposed collateral movement based on price and quantity but prior to the application of any haircut.
  • haircut - The amount to which the collaterals market value will be discounted to take into account the ability to realize the value of that collateral. This amount will be defined as a multiplier i.e. 97% would be represented as 0.97.
  • collateralValue This is the value of the proposed collateral after the application of the haircut. This amount would be defined in based currency for ease of comparison to the agreed amount to which the proposal is being used towards satisfying.
• Letter of Credit
  For Letters of Credit two elements are required; identifier and amount. Note that the partyReference within the contract identifier should refer to the issuing bank.
  • amountThe value of the letter of credit
  • identifier A type defining a contract identifier issued by the indicated party
    • partyReference - A reference to a party identifier defined elsewhere in the document. The party referenced has allocated the contract identifier.
    • contractId - A contract id which is not version aware.
    • versionedContractId - A contract id which is version aware.
    • id
  • marketValue, haircut and collateralValue can be specified but are optional

  Note: the collateral schema is using a copy of the existing LcSummary type defined in the Loan 4.8 schema. The plan is to reference the official LcSummary once it is available in a later draft of FpML 5.1.

17.5.3.5.1 Assets

This block removes the need to repeat static data details for Assets that may be referred to in the different movement type sections. For example, if the requestCollateralAcceptance message was describing the collateral to be delivered to meet both a Variation Margin and Segregated Independent Amount with both obligation types requiring both a return of collateral and a delivery of new collateral then there could be four instances where the same asset is referred to in each of those sections.

		
<security>
	<assetReference href="xyz" />
	<valueDate>2010-06-02</valueDate>
	<nominalAmount>5000</nominalAmount>
	<dirtyPrice>100</dirtyPrice>	
	<marketValue>5000</marketValue>	
	<haircut>0.90</haircut>		
	<collateralValue>4500</collateralValue>
</security>

	

The assetReference element references the actual definition of the security within the assets block using an id/href mechanism.

The assets block contains a number of FpML underlying assets (i.e., defined by the underlyingAsset substitution group) that define the details of the asset being proposed. Many asset types such as bonds, equities, or cash are available in FpML.

		
<assets>
	<bond id="xyz">
		<instrumentId instrumentIdScheme="ISIN">GB0002634946</instrumentId>
		<description>BAE Systems</description>
		<currency>EUR</currency>
		<maturity>2030-10-14</maturity>
	</bond>       
	<equity id="eq01">
		<instrumentId instrumentIdScheme="ISIN">IBM.N</instrumentId>
		<description>ABN AMRO HOLDING NV</description>
		<currency>USD</currency>
		<exchangeId>AEX</exchangeId>
		<relatedExchangeId>LIFFE</relatedExchangeId>
	</equity>
	<cash id="cash01">
		<instrumentId instrumentIdScheme="cash">cash</instrumentId>
		<currency>USD</currency>
	</cash>
	...
	

17.5.3.6 Collateral Proposal Response (MC7/MC8) - collateralProposalStatus

The collateralProposalStatus is used by the party that receives a requestCollateralAcceptance message to provide feedback on whether they can accept the collateral proposals detailed.

This message references the parties involved in the message sequence and the reference to the margin call being responded to. The responding party can provide feedback for either Variation Margin proposals only, both Variation Margin and Segregated Independent Amount proposals and Segregated Independent Amount only proposals. The response details are handled through the ProposedCollateralResponse.model. This model provides the choice for defining which margin types to respond to and then margin type response has the following elements:

proposalApproved This is a Boolean response True or False as to whether the responder accepts the specific movements associated with a specific margin type proposal. Please note therefore that in the same message you can reject a Variation Margin movement proposal and accept a Segregated Independent Amount proposal and vice versa.

collateralResponseReason The responder has the option to provide a reasonCode and description or just a description related to the response to provide more information to the party requesting acceptance. The reasonCode options for rejection include:

expectedCollateral The expected collateral block allows the responder to provide additional details of collateral that they would prefer to receive from the other party. This block can be used when the responder rejects a set of movements and wants to provide feedback on the type of collateral they would prefer to receive. For a delivery the user can provide details of the type of collateral they would prefer to receive i.e. cash, securities or letters of credit. This will not go down to the individual instrument identifier level just to a type i.e. US Treasuries. This is because the responding party does not know the exact holdings of the other party.

For returns the responding party can state the exact movement composition they would prefer to receive back because they know the collateral they have previously posted to the other party that they would now like back. For returns this definition will be the same definition (ProposedCollateralDeliveryReturn) that is used within the requestCollateralAcceptance message.

The use of the expected collateral block allows for counter proposal it is expected that the party that sent the original requestCollateralAcceptance message will review the expected collateral suggestions and then submit a revised requestCollateralAcceptance message that takes into account the counter proposal. This differs from the ISDA Collateral Working Group requirements to allow the original proposer to accept or reject the counter proposal.

• InsufficientCollateral
• ConcentrationLimitExceeded
• InvalidIdentifier
• NonEligibleSecurity

17.5.3.7 Acknowledge Dispute (MC11) - disputeNotification

The disputeNotification message allows the party that receives the marginCallStatus message, where the responding party either fully or partially disputed the margin call, to acknowledge the dispute and state the expected resolution method.

The message includes details of the parties of the original margin request as well as the reference to the message itself. The sender can provide dispute notification for Variation Margin only, both Variation Margin and Segregated Independent Amount or Segregated Independent Amount only. For each margin type the following details can be provided.

• Disputed Amount - This is confirmation of the amount being disputed this would be the difference between the undisputed amount and the call amount from the requestMarginCall message
• Disputed Date - This is the date from which the Dispute is deemed by the sending party to have occurred on. It can be used for dispute aging purposes.
• Disputed Resolution Method - The disputeResolutionMethod can consist of either a resolutionCode and description, a resolution code only or a description only. The purpose of this element is to be able to provide details of how the dispute differences will be resolved. There could be more than one action that needs to be performed depending on the reasons for the dispute. For example, in the case of a portfolio difference the resolution method could be to perform a reconciliation of the two portfolios. The resolution method could be reconciliation and the details explain the preferred mechanism i.e. via a bilateral reconciliation service to which both parties will upload their respective portfolios. Or it could be a unilateral reconciliation where the notifying party requests the other party to send them a copy of the portfolio in excel format. Other resolution methods could include reconciliation of Independent Amounts, Collateral Positions or Margin Terms.

17.6 Collateral Substitution Process

The Substitution process defined in the ISDA Collateral Committee document covers the following message flow:

17.6.1 Mapping Table of ISDA Collateral Committee Messages to FpML Collateral Working Group Messages

The ISDA Collateral Committee Electronic Messaging Working Group defined 6 messages that represented the substitution process. The following table shows the mapping of these 6 messages to their FpML equivalent.

ISDA Collateral Committee	FpML
CS1 – Request Substitution	requestSubstitution
CS2 – Agree Collateral Substitution	substitutionStatus
CS5 – Reject Collateral Substitution	substitutionStatus
CS3 – Confirm Substitution	substituteConfirmationStatus
CS4 – Confirm Collateral Returned	returnConfirmationStatus
CS6 – Propose new line of Collateral	requestSubstitution
No Equivalent	requestSubstitutionRetracted, substitutionStatusRetracted

17.6.2 Proposed FpML Workflow

The following sequence diagram shows the proposed flow of FpML messages for the collateral substitution process.

17.6.3 FpML Collateral Substitution Messages

The following sections describe the different FpML messages that support the substitution process.

17.6.3.1 Request Substitution (CS1) - requestSubstitution

The request substitution message requestSubstitution communicates the details of a collateral exchange to the receiving party. This message supports substitutions of collateral related to Variation Margin and Segregated Independent Amount requirements.

Typically, it is the party that owns the collateral held by the other party that proposes a request for substitution.

The main components of this message are as follows:

• Parties
  • substitutionIssuerPartyReference - The party requesting the collateral substitution
  • substitutionReceiverPartyReference - The party receiving the collateral substitution
• Credit Support Agreement - The agreement executed between the parties and intended to govern the collateral arrangement for all OTC derivatives transactions between those parties.
• Collateal Return (return) - Used by the substitution issuer to request a return of collateral.
  • deliveringPartyReference / receivingPartyReference - specify the direction of the collateral movement
  • For each movement direction type the ProposedCollateralDeliveryReturn type (which was defined for the collateral proposal message) is reused to describe the movements being proposed this type includes details of the delivering and receiving parties and the types of collateral being proposed. Multiple movements can be defined for each movement direction type. There are three collateral type options: cash, security, letterOfCredit (see collateral proposal (MC3c) section for details)
• Collateral Delivery (deliver) - the substitution issuer proposes to deliver cash or specific securities of equivalent value to the returned collateral (return).

• assets - defines the set of FpML underlying assets that are to be substituted/exchanged (see section “Assets”)
• substitutionAmount - specifies the amount of collateral to be substituted.
• party - defines the parties

17.6.3.2 Collateral Substitution Response: Agree (CS2) / Reject (CS5) - substitutionStatus

The substitutionStatus message is used by the party that receives a requestSubstitution message to provide a response on whether or not they accept the proposed collateral exchange.

the original CS2 and CS5 messages can be modeled using this same FpML message.

The main components of this message are as follows: (Structures that have been covered earlier -such as header, correlationId, creditSupportAgreement, parties- have been omitted.)

• Parties
  • substitutionIssuerPartyReference - The party requesting the collateral substitution
  • substitutionReceiverPartyReference - The party receiving the collateral substitution
• The party can approve or reject the substitution request for Variation Margin and Segregated Independent Amount separately.

substitutionResponseReason - This element allows you to provide additional details about your response. This takes the form of a free-form description and a reason code. The list of reason codes are as follows:

• InsufficientCollateral
• InvalidIdentifier

Note: the reason code will be populated in case of a rejection. The reason codes are defined in FpML coding list collateral-substitution-response-reason

Examples

		
<variationMargin>
	<substitutionApproved>true</substitutionApproved>
</variationMargin>

<segregatedIndependentAmount>
	<substitutionApproved>false</substitutionApproved>
	<substitutionResponseReason>
		<reasonCode>InsufficientCollateral</reasonCode> 
		<description>The combined market value of the proposed securities …</description>
	</substitutionResponseReason>
</segregatedIndependentAmount>
	

17.6.3.3 Confirm Substitution (CS3) - substituteConfirmationStatus

The substituteConfirmationStatus (of type SubstituteReturnConfirmationStatus) is used by the party that receives a substitution response (substitutionStatus) to notify of the successful transfer of the substitute collateral.

The main components of this message are as follows:(Structures that have been covered earlier -such as header, correlationId, creditSupportAgreement, parties- have been omitted.)

• released - Boolean that specifies whether or not the substitution issuer has transferred the proposed collateral
• description - free form description

Examples

		
	<variationMargin>
		<released>true</released>
	</variationMargin>

	<segregatedIndependentAmount>
		<released>true</released>
		<description>Cash has been released please confirm and release your side of the sub</description>
	</segregatedIndependentAmount>
	

17.6.3.4 Confirm Collateral Return (CS4) - returnConfirmationStatus

The returnConfirmationStatus is used by the substitution receiver to notify the party that issued the substitution request that the collateral has been released. This message uses the same syntax as the CS3 message (both messages share type SubstituteReturnConfirmationStatus). The same released Boolean is used to specify the return status.

Example

		
<segregatedIndependentAmount>
	<released>true</released>
	<description>Collateral has been returned.</description>
</segregatedIndependentAmount>
	

17.7 Interest Payment Process

The Interest process defined in the ISDA Collateral Committee document covers the following message flows

Interest Message Exchange - utilizing matching service

Bilateral Interest Message Exchange - not utilizing matching service

17.7.1 Mapping Table of ISDA Collateral Committee Messages to FpML Collateral Working Group Messages

The ISDA Collateral Committee Electronic Messaging Working Group defined 5 messages that represented the interest payment process. The following table shows the mapping of these 5 messages to their FpML equivalent.

ISDA Collateral Committee	FpML
IN1 – Send Interest Notification	requestInterest
IN2 – Accept Interest Notification	interestStatus
IN3 – Reject Value Date	interestStatus
IN5 – Dispute Interest	interestStatus
IN4 – Amend Value Date Convention	requestInterest
No Equivalent	requestInterestRetracted, interestStatusRetracted, interestStatement

17.7.2 Proposed FpML Workflow

The following sequence diagram shows the proposed flow of FpML messages for the collateral interest process.

Interest Message Exchange using a Matching Service

Bilateral Interest Message Exchange

Matching Service vs Bilateral Exchange

Adapting the collateral messages to use a matching Service is done easily in FpML through additional header information available in all FpML messages. The copyTo field can be used.

The header for the IN1 message sent by one party to the matching service may look like:

		
<header>
	<messageId messageIdScheme="http://www.xyzbank.com/message-Id">666777900</messageId>
	<sentBy>XYZBICXXX</sentBy>
	<sendTo>MATCHINGSERVICE01</sendTo><!-- COPY SENT TO MATCHING SERVICE  -->
	<copyTo>ABCBICXXX</copyTo>
	<creationTimestamp>2010-08-25T12:00:00Z</creationTimestamp>
</header>
	

The matching service is defined as another party at the end of the message.

		
<party id="party3">				<!-- MATCHING SERVICE identification -->
	<partyId>MATCHINGSERVICE01</partyId>
	<partyName>Matching Corp</partyName>
</party>

	

The header for the IN2 message sent by the matching service to one party would look like:

		
<header>
	<messageId messageIdScheme="http://www.xyzbank.com/message-Id">888888888888</messageId>
	<inReplyTo messageIdScheme="http://www.abcbank.com/message-Id">666777900</inReplyTo>
	<sentBy>MATCHINGSERVICE01</sentBy><!--  message is sent by a matching service party -->
	<sendTo>XYZBICXXX</sendTo>
	<copyTo>ABCBICXXX</copyTo>
	<creationTimestamp>2010-09-25T15:00:00Z</creationTimestamp>
</header>
	

The ISDA Collateral Working Group requirements only discussed the scenario of utilizing a matching service for the Interest Process. The FpML messaging framework inherently extends the functionality to all collateral processes (i.e., interest, substitution and margin call).

17.7.3 FpML Interest Messages

The following sections describe the different FpML messages that support the interest process.

17.7.3.1 Send Interest Notification (IN1) - requestInterest

The Interest Notification requestInterest communicates interest owed to the receiving party on collateral held by the issuing party. This message supports the communication of both Variation Margin and Independent Amount requirements. There are two scenarios:

• During the interest period collateral was held by only one of the parties. Therefore only one party will need to make an interest payment. In FpML the singleDirection block is used to define the interest details. This is the typical scenario.
• During the interest period, collateral was held at some point by both parties. In this situation both parties owe interest to the other party. In FpML the bothDirections structure is used to the define interest details for each direction. The FpML messages support the definition of whether to treat these obligations on a netted vs gross basis.

The main components of this message are as follows: (Structures that have been covered earlier -such as header, correlationId, creditSupportAgreement, parties- have been omitted.)

• Parties
  • IssuerPartyReference - The party issuing the IN1 interest notification
  • ReceiverPartyReference - The party receiving the interest notification
• Interest Requirement - specifies the interest details (either singleDirection or BothDirections)
  • InterestPeriod - specifies the startDate and endDate
  • variationMargin and/or segregatedIndependentAmount - The party can specify the interest details for Variation Margin and Segregated Independent Amount separately.
    • singleDirection or bothDirections
• comment - free form comment

17.7.3.1.1 Single Direction (singleDirection)

The single direction structure within variationMargin or segregatedIndependentAmount contains the necessary information to communicate a single interest payment from the party holding collateral to the other.

The elements are:

• SingleTreatment
  • paymentDetails
    • payerPartyReference
    • receiverPartyReference
    • paymentDate
    • paymentAmount
    • method - cash or physical settlement
• InterestAccrued - specifies the interest details (either singleDirection or BothDirections)
  • deliveringPartyReference / receivingPartyReference - the direction of the interest payment
  • interest
    • currency
    • amount
  • withholdingTax
    • currency
    • amount
  • withholdingTaxTerms
    • jurisdiction
    • rate
  • interestCalculationTerms
    • calculationType
    • index
    • spread
    • dayCountFraction
  • interestCalculationDetails optional calculations can be included using this element. within interestCalculationDetails, repeatable a dailyInterestCalculation block can be used for each day of the calculation period (see next section)

Example

		
<singleDirection><!-- typical scenario: only one party will need to make an interest payment. -->
    <singleTreatment>
        <paymentDetails>
            <payerPartyReference href="party1"/>
            <receiverPartyReference href="party2"/>
            <paymentDate>
                <adjustableDate>
                    <unadjustedDate>2010-09-02Z</unadjustedDate>
                    <dateAdjustments>
                        <businessDayConvention>NONE</businessDayConvention>
                    </dateAdjustments>
                    <adjustedDate>2010-09-02Z</adjustedDate>
                </adjustableDate>
            </paymentDate>
            <paymentAmount>
                <currency>USD</currency>
                <amount>1271.55</amount>
            </paymentAmount>
            <method>PhysicalSettlement</method>
        </paymentDetails>
    </singleTreatment>
    <interestAccrued>
        <deliveringPartyReference href="party1"/>
        <receivingPartyReference href="party2"/>
        <interest>
            <currency>USD</currency>
            <amount>1371.55</amount><!-- the cumulative interest amount  -->
        </interest>
        <withholdingTax><!-- optional tax withholding information -->
            <currency>USD</currency>
            <amount>100</amount>
        </withholdingTax>
        <withholdingTaxTerms>
            <jurisdiction>US</jurisdiction><!-- referencing country code scheme -->
            <rate>0.002</rate>
        </withholdingTaxTerms>
        <interestCalculationTerms>
            <calculationType>Compounding</calculationType>
            <index>EUR-EONIA-Swap-Index</index>
            <spread>-0.0030</spread><!-- 30 basis points -->
            <dayCountFraction>ACT/360</dayCountFraction>
        </interestCalculationTerms>
	

17.7.3.1.2 Both Directions (bothDirections)

During the interest period, collateral was held at some point by both parties. In this situation both parties owe interest to the other party. In FpML the bothDirections structure is used to the define interest details for each direction. The FpML messages support the definition of whether to treat these obligations on a netted vs gross basis.

Net Treatment

For a net treatment, the following fields are required:

• netTreatment
  • paymentDetails - netted payment details
• 2 InterestAccrued - (as detailed earlier for the single direction), one for each interest payment direction.

Example

		
<bothDirections>
    <netTreatment><!--  IF NET treatment (other CHOICE is <grossTreatment>) -->
        <paymentDetails><!-- 1 occurence of <paymentDetails> for Net -->
            <payerPartyReference href="party2"/>
            <receiverPartyReference href="party1"/>
            <paymentDate>
                <adjustableDate>
                    <unadjustedDate>2010-09-02Z</unadjustedDate>
                    <dateAdjustments>
                        <businessDayConvention>FOLLOWING</businessDayConvention>
                        <businessCenters>
                            <businessCenter>USNY</businessCenter>
                            <businessCenter>BGLO</businessCenter>
                        </businessCenters>
                    </dateAdjustments>
                </adjustableDate>
            </paymentDate>
            <paymentAmount>
                <currency>USD</currency>
                <amount>500</amount>
            </paymentAmount>
            <method>PhysicalSettlement</method>
        </paymentDetails>
    </netTreatment>
    <interestAccrued><!-- 2 occurences of <interestAccrued> -->
        <deliveringPartyReference href="party2"/>
        <receivingPartyReference href="party1"/>
        <interest>
            <currency>USD</currency>
            <amount>1500</amount>
        </interest>
        <interestCalculationTerms>
            <calculationType>Simple</calculationType>
            <index>EUR-EONIA-Swap-Index</index>
            <spread>-0.0030</spread><!-- 30 basis points -->
            <dayCountFraction>ACT/360</dayCountFraction>
        </interestCalculationTerms>
    </interestAccrued>
    <interestAccrued>
        <deliveringPartyReference href="party1"/>
        <receivingPartyReference href="party2"/>
        <interest>
            <currency>USD</currency>
            <amount>1000</amount>
        </interest>
        <interestCalculationTerms>
            <calculationType>Simple</calculationType>
            <index>EUR-EONIA-Swap-Index</index>
            <spread>-0.0030</spread><!-- 30 basis points -->
            <dayCountFraction>ACT/360</dayCountFraction>
        </interestCalculationTerms>
    </interestAccrued>
</bothDirections>

Gross Treatment

For a gross treatment, the following fields are required:

• grossTreatment
  • 2 paymentDetails - one for each interest payment direction
• 2 InterestAccrued - (as detailed above), one for each interest payment direction.

Example

		
<bothDirections><!-- other CHOICE is <singleDirection> -->
    <grossTreatment><!-- IF GROSS treatment (other CHOICE is <netTreatment>) -->
        <paymentDetails><!-- 2 occurences of <paymentDetails> for Gross -->
            <payerPartyReference href="party1"/>
            <receiverPartyReference href="party2"/>
            <paymentDate>
                <adjustableDate>
                    <unadjustedDate>2010-09-02Z</unadjustedDate>
                    <dateAdjustments>
                        <businessDayConvention>FOLLOWING</businessDayConvention>
                        <businessCenters>
                            <businessCenter>USNY</businessCenter>
                            <businessCenter>BGLO</businessCenter>
                        </businessCenters>
                    </dateAdjustments>
                </adjustableDate>
            </paymentDate>
            <paymentAmount>
                <currency>USD</currency>
                <amount>1500</amount>
            </paymentAmount>
            <method>PhysicalSettlement</method>
        </paymentDetails>
        <paymentDetails>
            <payerPartyReference href="party2"/>
            <receiverPartyReference href="party1"/>
            <paymentDate>
                <adjustableDate>
                    <unadjustedDate>2010-09-02Z</unadjustedDate>
                    <dateAdjustments>
                        <businessDayConvention>FOLLOWING</businessDayConvention>
                        <businessCenters>
                            <businessCenter>USNY</businessCenter>
                            <businessCenter>BGLO</businessCenter>
                        </businessCenters>
                    </dateAdjustments>
                </adjustableDate>
            </paymentDate>
            <paymentAmount>
                <currency>USD</currency>
                <amount>500</amount>
            </paymentAmount>
            <method>PhysicalSettlement</method>
        </paymentDetails>
    </grossTreatment>
    <interestAccrued><!-- 2 occurences of <interestAccrued> -->
        <deliveringPartyReference href="party2"/>
        <receivingPartyReference href="party1"/>
        <interest>
            <currency>USD</currency>
            <amount>1500</amount>
        </interest>
        <interestCalculationTerms>
            <calculationType>Simple</calculationType>
            <index>EUR-EONIA-Swap-Index</index>
            <spread>-0.0030</spread><!-- 30 basis points -->
            <dayCountFraction>ACT/360</dayCountFraction>
        </interestCalculationTerms>
    </interestAccrued>
    <interestAccrued>
        <deliveringPartyReference href="party1"/>
        <receivingPartyReference href="party2"/>
        <interest>
            <currency>USD</currency>
            <amount>1000</amount>
        </interest>
        <interestCalculationTerms>
            <calculationType>Simple</calculationType>
            <index>EUR-EONIA-Swap-Index</index>
            <spread>0.25</spread>
            <dayCountFraction>ACT/360</dayCountFraction>
        </interestCalculationTerms>
    </interestAccrued>
</bothDirections>
	

17.7.3.1.3 Interest Calculation Details (interestCalculationDetails)

The party sending the interest notification can choose to include optional interest calculation details, detailing how the party arrived to the interest amount. Interest calculations are captured using a repeatable dailyInterestCalculation structure. One dailyInterestCalculation structure is used for each day of the interest period.

The available fields within dailyInterestCalculation are:

• calculationDate
• openingPrincipalAmount - current day's principal amount = previous day's principal amount +/- movement amount for today
• principalMovement - The aggregated settled collateral movement for the calculation date
• effectivePrincipalAmount - end of day balance (principalAmount) + previous day's cumulativeInterestAmount
• observedRate - the observed rate of the index specified in the interestCalculationTerms
• spread
• effectiveRate - observed rate adjusted for spread
• accruedInterestAmount - interest calculated for the calcution date
• cumulativeInterestAmount - accrued interest to the current calculation date

Example

		
<interestCalculationDetails><!-- optional interest calculations: -->
    <dailyInterestCalculation><!-- calculations for 1st day of period -->
        <calculationDate>2010-08-01Z</calculationDate>
        <openingPrincipalAmount>600000</openingPrincipalAmount>
        <principalMovement>
            <payerPartyReference href="party1"/>
            <receiverPartyReference href="party2"/>
            <paymentAmount>
                <currency>USD</currency>
                <amount>100000</amount>
            </paymentAmount>
        </principalMovement>
        <effectivePrincipalAmount>600000</effectivePrincipalAmount>
        <observedRate>0.043</observedRate>
        <spread>-0.0030</spread>
        <effectiveRate>0.040</effectiveRate>
        <accruedInterestAmount>666.66</accruedInterestAmount><!-- (0.40 * 600,000) / 360  -->
        <cumulativeInterestAmount>666.66</cumulativeInterestAmount>
    </dailyInterestCalculation>
    <dailyInterestCalculation>
        <!-- calculations for 2nd day of period -->
        <calculationDate>2010-08-02Z</calculationDate>
        <openingPrincipalAmount>650000</openingPrincipalAmount>
        <principalMovement>
            <!-- aggregated settled collateral movement for the calculation date -->
            <payerPartyReference href="party1"/>
            <receiverPartyReference href="party2"/>
            <paymentAmount>
                <currency>USD</currency>
                <amount>50000</amount>
            </paymentAmount>
        </principalMovement>
        <effectivePrincipalAmount>650666.66</effectivePrincipalAmount><!-- end of day balance (principalAmount) + previous day's cumulativeInterestAmount = $650000 + $666.66 -->
        <observedRate>0.042</observedRate>
        <spread>-0.0030</spread><!-- 30 basis points -->
        <effectiveRate>0.039</effectiveRate><!-- = observed rate adjusted with spread -->
        <accruedInterestAmount>704.89</accruedInterestAmount><!-- (0.39 * 650,666.66) / 360  -->
        <cumulativeInterestAmount>1371.55</cumulativeInterestAmount><!-- = day1 accrued interest ($666.66) + day 2 accrued interest ($704.89) -->
    </dailyInterestCalculation>
    <!-- calculations for subsequent days 3, 4, ..., n would go here (not shown) -->
</interestCalculationDetails>
	

17.7.3.2 Response to Interest Notification / Accept (IN2) - Reject Value Date (IN3) - Dispute Interest (IN5) - interestStatus

The interestStatus is used by the party that receives a requestInterest message to provide a response on whether or not they accept the proposed interest.

the original IN2, IN3 and IN5 messages can be modeled using the same FpML message.

The main components of this message are as follows. (Structures that have been covered earlier -such as header, correlationId, creditSupportAgreement- have been omitted.)

• Parties
  • IssuerPartyReference - The party issuing the IN1 interest notification
  • ReceiverPartyReference - The party receiving the interest notification
• The party can approve or reject the substitution request for Variation Margin and Segregated Independent Amount separately.

interestApproved This is a Boolean response True or False as to whether the responder accepts the specific movements associated with a specific margin type proposal. Please note therefore that in the same message you can reject a Variation Margin interest proposal and accept a Segregated Independent Amount proposal and vice versa.

interestResponseReason - This element allows you to provide additional details about your response. This takes the form of a free-form description and a reason code. The list of reason codes are as follows:

• InterestNotificationAccepted
• DisputedInterest
• RejectedValueDate
• RejectedTreatmentType

Note: the reason code will be populated in case of a rejection. The reason codes are defined in FpML coding list collateral-interest-response-reason

Example

		
<interestApproved>false</interestApproved>	<!-- IN5: Dispute Interest -->
<interestResponseReason>
	<reasonCode>DisputedInterest</reasonCode>	<!-- coding scheme -->
	<description>The interest amount is about half that expected</description>
</interestResponseReason>
	

17.7.3.3 Amend Value Date Convention (IN4) - requestInterest

The Amend Value Date Convention (IN4) message is in effect a new Send Interest Notification (IN1) message. Rather than defining a new, unnecessary message in FpML to model IN4, implementers can simply reissue an IN1 message with amended details.

17.7.3.4 Interest Statement - interestStatement

The interest statement is a new message that is not part of the original ISDA business requirements. It is a report detailing interest calculations which can be generated upon request, regardless of interest movements, i.e., independently of an interest notification (IN1).

The interest statement is similar in structure to the requestInterest (IN1) message except that no treatment is included. The daily calculation details are captured in the mandatory interestCalculationDetails structure. A dailyInterestCalculation is used for each day of the calculation period.

The main components of this message are as follows: (Structures that have been covered earlier -such as header, correlationId, creditSupportAgreement, parties- have been omitted.)

• Parties
  • IssuerPartyReference - The party issuing the IN1 interest notification
  • ReceiverPartyReference - The party receiving the interest notification
• Interest Requirement - specifies the interest details (either singleDirection or BothDirections)
  • InterestPeriod - specifies the startDate and endDate
  • variationMargin and/or segregatedIndependentAmount - The party can specify the interest details for Variation Margin and Segregated Independent Amount separately.
    • singleDirection or bothDirections
      • interestAccrued
• comment - free form comment

		
<interestCalculationDetails>
	<dailyInterestCalculation>
		<!-- calculations for 1st day of period -->
		<calculationDate>2010-08-01Z</calculationDate>
		<openingPrincipalAmount>600000</openingPrincipalAmount>
		<principalMovement>
			<payerPartyReference href="party1"/>
			<receiverPartyReference href="party2"/>
			<paymentAmount>
				<currency>USD</currency>
				<amount>100000</amount>
			</paymentAmount>
		</principalMovement>
		<effectivePrincipalAmount>600000</effectivePrincipalAmount>
		<observedRate>0.043</observedRate>
		<spread>-0.0030</spread>
		<effectiveRate>0.040</effectiveRate><!-- = observed rate adjusted with spread -->
		<accruedInterestAmount>666.66</accruedInterestAmount><!-- (0.40 * 600,000) / 360  -->
		<cumulativeInterestAmount>666.66</cumulativeInterestAmount>
	</dailyInterestCalculation>
	<dailyInterestCalculation>
		<!-- calculations for 2nd day of period -->
		<calculationDate>2010-08-02Z</calculationDate>
		<openingPrincipalAmount>650000</openingPrincipalAmount><!-- current day's principal amount = previous day's principal amount +/- movement amount for today -->
		<principalMovement>
			<!-- aggregated settled collateral movement for the calculation date -->
			<payerPartyReference href="party1"/>
			<receiverPartyReference href="party2"/>
			<paymentAmount>
				<currency>USD</currency>
				<amount>50000</amount>
			</paymentAmount>
		</principalMovement>
		<effectivePrincipalAmount>650666.66</effectivePrincipalAmount><!-- end of day balance (principalAmount) + previous day's cumulativeInterestAmount = $650000 + $666.66 -->
		<observedRate>0.042</observedRate>
		<spread>-0.0030</spread><!-- 30 basis points -->
		<effectiveRate>0.039</effectiveRate><!-- = observed rate adjusted with spread -->
		<accruedInterestAmount>704.89</accruedInterestAmount><!-- (0.39 * 650,666.66) / 360  -->
		<cumulativeInterestAmount>1371.55</cumulativeInterestAmount><!-- = day1 accrued interest ($666.66) + day 2 accrued interest ($704.89) -->
	</dailyInterestCalculation>
	<!-- calculations for subsequent days 3, 4, ..., n would go here (not shown) -->
</interestCalculationDetails>
	

18 CHANGES IN THIS VERSION

18.1 Changes compared to FpML 5.7 Second Working Draft (build#2)

• Credit Derivatives:
  • Added additional support for 2014 ISDA Credit Derivatives Definitions: an optional Boolean indicator standardReferenceObligation within the existing ReferenceObligation component. It indicates if the reference obligation is a Standard Reference Obligation. ISDA 2014 Term: Standard Reference Obligation.
• Business Process:
  • Enhanced Package Transactions representation:
    • Updated examples and schemes.
    • Within the packageHeader, added package type, size and originatingEvent
    • Within the tradeHeader, added originatingPackage including package id, size and sequence number: these will provide more information about the originating package and how this trade relates to it once the trade is separated from the package.
    • Pretrade view: Within tradePackage/allocations, added the “allocatingPartyReference” and changed the multiplicity of the allocations element to allow up to 2 instances of it
  • Partial termination of a TRS – Added an id attribute to the equity derivative “ActualPrice” type to allow price references to be made to it (See example #100 in confirmation/business-processes/execution-advice of a partial termination of a TRS)
  • Reporting:
    • Entity Classification: Within the reportingRegime, added partyEntityClassification as an improved way to relate an entity classification to a party (e.g., Financial/NonFinancial, Dealer/NonDealer, LocalParty/NonLocalParty)
    • Within the reportingRegime, added tradePartyRelationshipType to specify intragroup (ESMA), inter-affiliate (CSA). (See recordkeeping examples ex140, ex141, ex142)
    • Removed the now redundant intragroup flag introduced in WD1. Renamed isCompressedTrade to compressedTrade.
  • Confirmation view: Correction: Made ReportingRegime/supervisorRegistration optional when reportingRegime/Name is supplied. It had been made mandatory in Confirmation view in error since version 5.3. The original intention under recordkeeping was to mandate the existence of at-least-one-of (name, supervisorRegistration).
  • Predetermined Clearing: renamed specifiedClearingOrganizationPartyReference to predeterminedClearingOrganizationPartyReference to match last agreed working group documents/emails.
• The following issues have been resolved:
  • http://www.fpml.org/issues/view.php?id=1178
  • http://www.fpml.org/issues/view.php?id=1076

View PDF for details on schema changes

View PDF for details on validation rules changes

View SCHEME DEFINITIONS for details on coding schemes changes

18.2 Changes compared to FpML 5.6 Recommendation (build#5)

• Commodity Derivatives:
  • Added support for Commodity Performance Swap, a swap in which the payout(s) are based on the price performance of an index rather than the price level of the index. Current support price performance metrics include price return and price variance.
  • Enhanced the CommoditySwaption and commodityOption/commodityForward models to include a field indicating the pre-determined clearing organization for the resulting swap created due from swaption exercise. This change has been approved by the CommWG – see the minutes from Sep-18-2013's meeting.
• Credit Derivatives:
  • Added support for 2014 ISDA Credit Derivatives Definitions:
    • Within 'CreditEvents', added 'governmentalIntervention' credit event.
    • Added an optional Boolean indicator standardReferenceObligation within the existing ReferenceObligation component. It indicates if the reference obligation is a Standard Reference Obligation. ISDA 2014 Term: Standard Reference Obligation.
  • Added support for Credit index swaps quoted using price: Added 'marketPrice' to 'feeLeg' in fpml-cd.xsd and 'price' to 'quotationStyleEnum' enumeration
  • Enhanced the CreditDefaultSwapOption model to include a field indicating the pre-determined clearing organization for the resulting swap created due from swaption exercise. This change has been approved by the CDWG – see the minutes from Mar-26-2014's meeting.
• Interest Rate Derivatives:
  • Fixed incorrect 'PaymentCalculationPeriod' type's derivation introduced in FpML-4-6 as part of the rationalization of the 'Payment' type hierarchy. The 'PaymentCalculationPeriod' is not a type of Payment so derivation from 'PaymentBase' is inappropriate. Within 'PaymentCalculationPeriod' complex type, removed derivation from 'PaymentBase'.
  • Enhanced the Swaption model to include a field indicating the pre-determined clearing organization for the resulting swap created due from swaption exercise.
• Equity Derivatives:
  • Enhanced the DividendSwapOptionTransactionSupplement and VarianceOptionTransactionSupplement models to include a field indicating the pre-determined clearing organization for the resulting swap created due from swaption exercise.
• Business Process:
  • Package Transactions - Refined the "tradePackage" representation (a bundle or package of trades executed and cleared as part of a single transaction). Note: Package Transactions are available in Confirmation, Pretrade, and Reporting views. Regulatory reporting would be at the granular level, not at the package level. For pre-trade view, the list of supported products include CDS, IRS and FX NDF.
    • Within the packageHeader, added package type, size and originatingEvent
    • Within the tradeHeader, added originatingPackage including package id, size and sequence number: these will provide more information about the originating package and how this trade relates to it once the trade is separated from the package.
  • For post trade events (increases, terminations, novations) added support for a size change of a notional schedule, not just a single value
  • For post trade events (increases, terminations, novations) added support for a price change to support resetting during the event.
  • Added support for partial exercises on trades with multiple notionals (of various types)
  • Enhanced the consent business process to allow more information about approvals to be captured. (see confirmation examples consent/msg-ex400 and msg-ex401)
  • Added support for "clearing instructions" to the physicaly settled options (CreditDefaultSwapOption, CommoditySwaption, DividendSwapOptionTransactionSupplement, VarianceOptionTransactionSupplement) that specifies any instructions on how the physical settlement is to be effected when the option is exercised.
  • Partial termination of a TRS – Added an id attribute to the equity derivative “ActualPrice” type to allow price references to be made to it (See example #100 in confirmation/business-processes/execution-advice of a partial termination of a TRS)
• Reporting:
  • Joint and Several Liable Parties: Refined support for multiple legal entities with joint and several liability
    • Within party, added a groupType flag (JointAndSeveralLiability) followed by several party references.
    • Within party, removed jointAndSeveralLiability added in the first working draft.
  • Added a Facility Execution flag to indicate whether the particular product must be executed on a SEF or DCM.
    • Within reporting regime, added a mandatoryFacilityExectution flag and additional elements to specify whether the party invoked exception to not execute the trade on facility such as SEF and DCM even though the particular product is mandated to execute on a SEF.
  • Added to reduce the overuse of the category element:
    • Within partyTradeInformation, compressedTrade - Specifies whether this trade is a result of compression activity.
  • Entity Classification: Within the reportingRegime, added partyEntityClassification as an improved way to relate an entity classification to a party (e.g., Financial/NonFinancial, Dealer/NonDealer, LocalParty/NonLocalParty)
  • Within the reportingRegime, added tradePartyRelationshipType to specify intragroup (ESMA), inter-affiliate (CSA). (See recordkeeping examples ex140, ex141, ex142)
  • Confirmation view: Correction: Made ReportingRegime/supervisorRegistration optional when reportingRegime/Name is supplied. It had been made mandatory in Confirmation view in error since version 5.3. The original intention under recordkeeping was to mandate the existence of at-least-one-of (name, supervisorRegistration).
  • Predetermined Clearing: renamed specifiedClearingOrganizationPartyReference to predeterminedClearingOrganizationPartyReference to match last agreed working group documents/emails.
• Shared:
  • Schema clean-up as per standards' recomendation
    • Removed orphan types

18.3 Incompatible changes compared to FpML 5.6 (build#5)

None.

19 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
    • Strategy Product (strategy-A strategy product.
      )
    • InstrumentTradeDetails Product (instrumentTradeDetails-A type to hold trades of multiply-traded instruments. Typically this will be used to represent the trade resulting from a physically-settled OTC product where the underlying is a security, for example the exercise of a physically-settled option.
      )
    • 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.
      )
• Pricing and Risk:
  • Valuation Result Sets and Related Components
  • Market Environment Data Components
  • Valuation and Sensitivity Results
• Messaging Framework:
  • Messaging Components
  • Cash Flow Matching and Portfolio Reconciliation Components
  • Reporting Messaging Components
  • Business Event Notification Components
  • Collateral Messaging Components
• Reference:
  • Index and cross-reference of definitions
  • Schema and Example files - Provides zip file with FpML schemas and examples.

20 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.

21 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.