FpML 4.4 Recommendation

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

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.

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 2.1. 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 the organization of the schema

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

Core Definitions:
- fpml-main-4-4.xsd - Root definitions.
- fpml-doc-4-4.xsd - Trade and contract definitions and definitions relating to validation.
- fpml-shared-4-4.xsd - Shared definitions used widely throughout the specification. These include items such as base types, shared financial structures, etc.
- fpml-enum-4-4.xsd - Shared enumeration definitions. These definitions list the values that enumerated types may take.
- fpml-asset-4-4.xsd - Underlyer definitions plus some types used by them (e.g. ones relating to commissions or dividend payouts).
Products:
- IRD
  - fpml-ird-4-4.xsd - Interest rate derivative product definitions.
- FX
  - fpml-fx-4-4.xsd - Foreign exchange product definitions.
- CD
  - fpml-cd-4-4.xsd - Credit derivative product definitions.
- EQD
  - fpml-correlation-swap-4-4.xsd - Correlation Swap and Correlation Swap Option Product Definitions.
  - fpml-dividend-swap-4-4.xsd - Dividend Swap and Dividend Swap Option Product Definitions.
  - fpml-eqd-4-4.xsd - Equity Option and Equity Forward Product Definitions.
  - fpml-eq-shared-4-4.xsd - Definitions shared by types with Equity Underlyers.
  - fpml-return-swaps-4-4.xsd - Return Swaps Product Definitions.
  - fpml-variance-swaps-4-4.xsd - Variance Swap and Variance Swap Option Product Definitions.
- Bond Options
  - fpml-bond-option-4-4.xsd - Bond and Convertible Bond Options Product Definitions.
- Option shared
  - fpml-option-shared-4-4.xsd - Shared option definitions used for defining the common features of options.
- Loan
  - fpml-loan-4-4.xsd - Loan product definitions and notices.
Pricing and Risking:
- fpml-valuation-4-4.xsd – Valuation result sets and related definitions.
- fpml-reporting-4-4.xsd – Messages used for requesting and providing valuation reporting results.
- fpml-mktenv-4-4.xsd – Definitions of market environment data structures such as yield curves, volatility matrices, and the like.
- fpml-riskdef-4-4.xsd – Definitions of valuation and sensitivity results. They include detailed definitions of sensitivity calculations and are intended to be used by sophisticated users.
Messaging Framework:
- fpml-msg-4-4.xsd - Definitions related to messaging and workflow.
- fpml-allocation-4-4.xsd - Allocation Components
- fpml-confirmation-4-4.xsd - Confirmation components
- fpml-contract-notification-4-4.xsd - Contract notification components
- fpml-credit-event-notification-4-4.xsd - Credit event notification components
- fpml-matching-status-4-4.xsd - Matching Status Components
- fpml-pretrade-4-4.xsd - Pre-trade messaging components
- fpml-tradeexec-4-4.xsd - Trade execution messaging components
- fpml-trade-notification-4-4.xsd - Trade notification Components
- fpml-posttrade-confirmation-4-4.xsd - Post-trade confirmation messaging components
- fpml-posttrade-execution-4-4.xsd - Post-trade execution messaging components
- fpml-posttrade-negotiation-4-4.xsd - Post-trade negotiation messaging components
- fpml-posttrade-4-4.xsd - Post-trade messaging components
- fpml-reconciliation-4-4.xsd - Cash flow matching and Portfolio Reconciliation messaging components

This graph shows the relationship between the different subschema files.

This organization may be refined in the future. In particular, it is likely that fpml-shared will be split into smaller pieces.

2.3 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 3.0 document. The DataDocument type is provided for maximum compatibility with 3.0, and 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 Object Model (PDF) - Gives an overview of all the financial products covered in FpML and their interrelationships.
FpML Messaging Object Model (PDF) - Gives an overview of the FpML Messaging Framework.

2.4 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.5 The FpML root element

The FpML element forms the root for an FpML instance document. The structure of the FpML document depends on the "xsi:type" attribute. The simplest FpML document is a "DataDocument" (xsi:type='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 ('4-3' for FpML 4.3), the schema name and location, the name space, and related properties, as well as the xsi:type. See the Architecture 2.1 specification for more details on this.

2.6 Annotations

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

2.6.1 eCore

eCore is part of the Eclipse Modelling Framework. This is the modelling technology based on 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.7 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.7.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.7.2 The Trade Component

The trade is the top-level component within the root element FpML. 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.

2.7.2.1 tradeHeader

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

2.7.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>
		<tradeId tradeIdScheme="http://www.investmentmgm.com/coding-scheme/trade-id">CDI290204</tradeId>
        		<version>1</version>
    	</versionedTradeId>
    	<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.7.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.

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

2.7.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.7.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.7.2.4 brokerPartyReference

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

2.7.2.5 calculationAgent

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

2.7.2.6 documentation

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

2.7.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.7.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.7.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.7.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.7.2.8 governingLaw

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

2.7.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.7.4 The Party Component

The party component holds information about a party in involved any of the trades or portfolios included in the document. The parties involved will be the principals to a trade and potentially additional third parties such as a broker. For this release, this component is restricted to party identification.

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 (tradeSide structure) to the party component.

2.7.4.1 Accounts

Within the party component includes information about accounts. A party can have multiple accounts.

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.

Example:

                                        ...
<party id="BONY">
        <partyId>BankNY</partyId>
        <partyName>Bank of New York</partyName>
        <account id="LDF_CUSTODY">
                <accountId accountIdScheme="http://bony.com/custody">12344455</accountId>
                <accountName>London Diverisified Fund Custody Account</accountName>
                <accountBeneficiary href="LDF"/>
        </account>
</party>
                                        ...

2.7.5 Roles - the TradeSide Component

FpML introduced the definition of roles in version 4.2. The ability to specify principal/agent relationships (trading on behalf of) is a very important feature for using FpML, for example in the prime brokerage area.

This is the description of the different roles currently defined:

orderer: The Party placing the order. This could be a fund manager acting on behalf of a client, or a hedge fund acting on it's own behalf. This is the role with the investment discretion.
introducer: Party that can relay an order directly to the trading floor at a firm. This is potentially a different firm, but may be the same as that taking the order. In effect the introducer is the first dealer to take the order. The reason an introducing dealer may forward a trade is sometime because it doesn't have the capacity to execute effectively but does have the relationship with the Orderer. Introducing Party is an industry standard term. This is semantically equivalent to the FIX and ISO20022 Introducing Firm.
executor: The Party executing or striking the trade. Executing Party is an industry standard term. This is semantically equivalent to the FIX and ISO20022 Executing Firm or Trader.
confirmer: The party that undertakes the confirmation process for this Trade Side. The confirmer essentially manages the matching and affirmation of trades. This is often the creditor or is increasingly outsourced to service providers such as Swapswire.
creditor: The party whose name appears on the contract as being responsible for credit of the trade. This is the party in the Trade Side the credit risk is against. For example if a hedge fund was to trade in the name of it's prime broker, then the prime broker would be the creditor.
calculater: The calculater is the Party that calculates, negotiates, and agrees the values to be paid at each payment date.
settler: The Settler is the party that makes the payments. Increasingly this is a service that can be externalized from the other roles. An example of a settlement service provide is SwapClear.
beneficiary: The party that suffers the economic effect of the trade. This is usually referred to as the primary Principal in FIX and ISO20022 - which is slightly confusing in that there are potentially many Princiapal/Agency relationships. The beneficiary may be distinct from the creditor - an example is a Hedge Fund trading in the name of it's Prime Broker.
accountant: The Accountants for the trade. There are potentially many accountants. This is known in FIX and ISO20022 for Collective Investment Vehicles as the Third Party Administrator (TPA), however all trades for all parties have at least one party accounting for the trade.

2.7.5.1 Using tradeSide

In order to define specific roles, the payerPartyReference/receiverPartyReference will point to a tradeSide structure instead of pointing to a party:

                                        ...
<payerPartyReference href="CHASE_SIDE_1"/>
<receiverPartyReference href="ABN_SIDE_1"/>
                                        ...

Each one of the tradeSide defines the set of roles for a specific side of the trade.

                                        ...
<tradeSide id="CHASE_SIDE_1">
        <orderer>
                <party href="CHASE_PARTY"/>
        </orderer>
        <creditor>
                <party href="CHASE_PARTY"/>
         </creditor>
</tradeSide>
                                        ...
<tradeSide id="ABN_SIDE_1">
        <orderer>
                <party href="LDF"/>
        </orderer>
        <creditor>
                <party href="ABN_PARTY"/>
        </creditor>
        <beneficiary>
                <account href="LDF_CUSTODY"/>
        </beneficiary>
</tradeSide>
                                        ...

Each role points to a party or to a specific account within a party.

                                        ...
<party id="CHASE_PARTY">
        <partyId>CHASUS33</partyId>
        <partyName>CHASE</partyName>
</party>
<party id="LDF">
        <partyId>LDF</partyId>
        <partyName>Londin Diversified Fund</partyName>
</party> 
<party id="ABN_PARTY">
        <partyId>ABNANL2A</partyId>
        <partyName>ABN Amro</partyName>
</party>
<party id="BONY">
        <partyId>BankNY</partyId>
        <partyName>Bank of New York</partyName>
        <account id="LDF_CUSTODY">
                <accountId accountIdScheme="http://bony.com/custody">12344455</accountId>
                <accountName>London Diverisified Fund Custody Account</accountName>
                <accountBeneficiary href="LDF"/>
        </account>
</party>
                                        ...

2.7.5.2 Examples

2.7.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
Correlation swap
Correlation swap option
Credit default swaps
Dividend swap
Dividend swap option
Variance swap
Variance swap option

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

2.8 More Background on FpML's Design

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

2.8.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.8.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.8.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 centers, 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 business process the messaging working group has extended the core FpML grammar to add a framework for defining messages and their content. This section describes some business processes and shows how they are 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.1.2 Design Assumptions

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

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.
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.
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.
All business process definitions must have an observable completion. The set of messages defining a business process needs to be complete. In addition, timeouts must be defined if necessary.

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.1.2.1 Transport Characteristics

3.1.2.1.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.1.2.1.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.1.2.1.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.1.2.1.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.1.3 Styles of Messaging

In general computer systems commonly use two styles of messaging to exchange information between each other, namely:

Request/Response

A style of exchange in which one system sends a message to the other to asking it to perform some function, the result of which is encapsulated in an appropriate response and returned.
Notification

A style of exchange in which a system sends a message describing a business event that has occurred and may be of interest to others.

The receipt of either kind of message may cause additional messages to be generated and sent as part of the processing to obtain information from other systems or to inform them of the business event underway.

3.1.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.1.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.1.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.1.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.1.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.1.5 Control Over Content

The design of a grammar must strike a balance between the degree of flexibility it allows and the complexity of its validation. An overly lax grammar allows the construction of documents that, whilst syntactically correct, may have no valid business interpretation. On the other hand a very rigid grammar may require many more grammatical productions in order to enumerate only the valid combinations.

In general it makes sense for a grammar to be strict when it can be achieved easily and without too much additional definition, and lax where flexibility is required (e.g. for proprietary extensions, etc.). In the case of the message framework the grammar provides a mechanism for ensuring that messages have the correct content that applies to them.

3.1.6 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 message framework is based on type substitution (option 3 - By Element Type) as it gives the greatest control over validation whilst allowing easy extension of the message elements. Below is a short explanation of the three techniques:

3.1.6.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.1.6.2 By Element Name (not used by FpML)

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

<?xml version="1.0"?>

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

To ensure that the content of the FpML element is always a valid message element the grammar would have to use either a choice group (which would limit extensibility) or a substitution group (which is extensible) to define the acceptable elements.

Whilst the root element could be used to indicate the function it is more likely that a child would be used so that all FpML documents would still have the FpML element as the root.

In this model the message header must be generic, that is suitable for any kind of message. There is no way in XML to validate that the content is suitable for the type of message content that follows.

3.1.6.3 By Element Type

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.1.7 Representing Internal Trades

The focus of FpML to date has been on the focus description of trades for B2B purposes. At the same time many of the existing implementations have been for internal trade exchanges between systems.

Extending FpML to handle internal trade information entails adding additional elements to the current schema to hold the values needed to categorize a trade for internal purposes. There are several ways this information could be added to the schema (e.g. optional elements, alternative inheritance structures, inheritance by restriction) each with its own properties in terms of ease of validation or affects on document style. The FpML Architecture specification contains examples of how bespoke extensions can be made to the schema.

3.1.8 Sequence Diagram

A UML diagram that defines information flows. It focuses on the temporal order of the messages. Business Analysts can find sequence diagrams useful to communicate how the business currently works by showing how various business objects interact.

images/messaging/BilateralAlreadySubmitted.gif

At the top of each diagram we see the names of actors or business objects involved in the process we want to describe. In the diagram above, Confirmation Requester and Confirmation Provider are examples of actors involved in the confirmation process.

The rectangles represent the systems involved in the process, e.g. Trading System, Confirmation System, and Matching System. However, in some other versions of sequence diagrams, the rectangles represent the actors or business objects.

Usually the actor or business object on the left side starts the interaction. Descending from each object is a line known as the “lifeline”. These lines define the time axis of the diagram. By convention, time proceeds in a downward direction. This practice is used in the FpML documentation.

The arrows between the lifelines represent messages being sent between the actors. For example, in the diagram above, RequestTradeConfirmation and TradeAlreadySubmitted are examples of messages being sent between the Confirmation Requester and the Confirmation Provider.

The white narrow rectangles that the arrows terminate on are called “activations”. For example, the rectangles between the RequestTradeConfirmation and TradeAlreadySubmitted messages in the diagram above are activations. They show the duration of the execution of a method or action in response to a message.

If you need more information regarding sequence or other UML diagrams, you can easily find UML diagram tools and tutorials by searching on the Internet.

3.2 The Message Framework

Versions of FpML prior to 4.0 have allowed the construction of documents which contain only product definitions. The original proposal for FpML 4.0 was to force a transition directly to messages by making some message elements mandatory in every document. However after further consideration it was decided to restructure the framework to allow both styles of definition giving FpML backwards compatibility with existing solutions and the scope to expand into new B2B (or A2A) messaging applications.

The following document give a general overview of what FpML Messages are available to support business processes: FpML Messaging Object Model (PDF)

3.2.1 The Base Document

The XML schema for FpML defines the type of the root FpML element to be 'Document', an abstract type with an empty content model save only for the standard FpML version.

The Document type serves as the base type in an inheritance scheme that provides the content model definitions for actual message types.

3.2.1.1 Data Documents

The DataDocument type provides the same content model as the pre XML schema version of FpML allowing the construction of documents that contain only product definitions.

To make an FpML 3.0 DTD based document compatible with the FpML 4.0 schema as a DataDocument a number of changes are required to the instance document, namely:

The <!DOCTYPE> reference must be removed from the document.
Where the <FpML> element defines a non-standard or institution specific default scheme attribute value it must be propagated the scheme attribute on all the appropriate elements.
A reference to the FpML schema as the default namespace must be added.
A reference to the W3C XML schema instance schema must be added and assigned to a namespace (e.g. 'xs' or 'xsi').
A reference to the W3C XML Digital Signature schema must be added and assigned to a namespace (e.g. 'dsig').
The type of the <FpML> element must be set to 'DataDocument'.
A schemaLocation attribute may be added to the <FpML> element to hint at the location of the schema for XML tools that do not perform full 'entity resolving'.

3.2.2 The Base Message

The core definitions within the schema establish a set of abstract base classes, 'Message' , 'MessageHeader' and a model group called 'MessageHeader.model' from which all the other definitions are composed by.

The message header used xsd:restriction in previous versions in order to restrict the content model for requests, responses, and notifications. But tools issues with xsd:restriction made the Architecture Working Group to change the architecture of the message header using model groups and xsd:extension instead of xsd:restriction.

The following XML schema fragment shows how these types and group are defined.

 <xsd:complexType name="Message" abstract="true">
	<xsd:complexContent>
		<xsd:extension base="Document"/>
	</xsd:complexContent>
</xsd:complexType>

  <xsd:complexType name="MessageHeader" abstract="true">	
	<xsd:sequence>
		<xsd:element name="conversationId" type="ConversationId" minOccurs="0"/>		
		<xsd:element name="messageId" type="MessageId"/>	
	</xsd:sequence>
</xsd:complexType>
<xsd:group name="MessageHeader.model">
	<xsd:sequence>
		<xsd:element name="sentBy" type="MessageAddress"/>
		<xsd:element name="sendTo" type="MessageAddress" minOccurs="0" 
maxOccurs="unbounded"/>
		<xsd:element name="copyTo" type="MessageAddress" minOccurs="0" 
maxOccurs="unbounded"/>
		<xsd:element name="creationTimestamp" type="xsd:dateTime"/>
		<xsd:element name="expiryTimestamp" type="xsd:dateTime" minOccurs="0"/>
		<xsd:element name="partyMessageInformation" type="PartyMessageInformation" 
minOccurs="0" maxOccurs="unbounded"/>
		<xsd:element ref="dsig:Signature" minOccurs="0" maxOccurs="unbounded"/>
	</xsd:sequence>
</xsd:group>

The content of Requests, Responses, and Notifications Message Headers differ in the inReplyTo element so it is not included in the model group. Each specific type would control the existance and cardinality of the inReplyTo element. The role of each element is given below.

conversationId allows a message sender to create a common context for a number of separate message exchanges.
messageId contains the senders unique identifier for a message.
inReplyTo contains the unique identifier for the request message that is being responded to.
sentBy identifies the system or party sending a message.
sendTo identifies the systems or parties who will receive a message and should act upon it.
copyTo identities other systems or parties who will receive a message but who do not have to act upon it.
creationTimestamp describes the time when the sender created the message.
expiryTimestamp defines a time after which the sender will consider the message expired.
dsig:Signature allows the inclusion of W3C digital signatures within the message.

The validation element in the Message type contains the URI for a set of additional validation rules to be applied to the document during processing.

3.2.3 Requests, Responses and Notifications

The following image shows the construction of just one message style type, as with in the exception of the type of the header element, they are all the same.

<xsd:complexType name="RequestMessage" abstract="true">
	<xsd:complexContent>
		<xsd:extension base="Message">
			<xsd:sequence>
				<xsd:element name="header" type="RequestMessageHeader"/>
				<xsd:group ref="Validation.model"/>
			</xsd:sequence>
		</xsd:extension>
	</xsd:complexContent>
</xsd:complexType>

<xsd:complexType name="RequestMessageHeader">
	<xsd:complexContent>
		<xsd:extension base="MessageHeader">
			<xsd:sequence>
				<xsd:group ref="MessageHeader.model"/>
			</xsd:sequence>
		</xsd:extension>
	</xsd:complexContent>
</xsd:complexType>

<xsd:complexType name="ResponseMessage" abstract="true">
	<xsd:complexContent>
		<xsd:extension base="Message">
			<xsd:sequence>
				<xsd:element name="header" type="ResponseMessageHeader"/>
				<xsd:group ref="Validation.model"/>
			</xsd:sequence>
		</xsd:extension>
	</xsd:complexContent>
</xsd:complexType>

<xsd:complexType name="ResponseMessageHeader">
	<xsd:complexContent>
		<xsd:extension base="MessageHeader">
			<xsd:sequence>
				<xsd:element name="inReplyTo" type="MessageId"/>
				<xsd:group ref="MessageHeader.model"/>
			</xsd:sequence>
		</xsd:extension>
	</xsd:complexContent>
</xsd:complexType>

<xsd:complexType name="NotificationMessage" abstract="true">
	<xsd:complexContent>
		<xsd:extension base="Message">
			<xsd:sequence>
				<xsd:element name="header" type="NotificationMessageHeader"/>
				<xsd:group ref="Validation.model"/>
			</xsd:sequence>
		</xsd:extension>
	</xsd:complexContent>
</xsd:complexType>

<xsd:complexType name="NotificationMessageHeader">
	<xsd:complexContent>
		<xsd:extension base="MessageHeader">
			<xsd:sequence>
				<xsd:element name="inReplyTo" type="MessageId" minOccurs="0"/>
				<xsd:group ref="MessageHeader.model"/>
			</xsd:sequence>
		</xsd:extension>
	</xsd:complexContent>
</xsd:complexType>

3.2.4 Error Handling

If a message cannot be processed for some technical reason such as: it has become corrupted, is not XML or is not a valid FpML message, then the receiver returns a 'MessageRejected' message to the sender. Usually the message will require manual intervention to diagnose and solve any problems. Such rejections will not be show on any of the diagrams in this paper.

If the message cannot be processed because the request is invalid, given the state of the data to which it applies, then an appropriate business level notification is returned to the sender (e.g. 'TradeNotFound', 'TradeAlreadyMatched', etc.) which in turn could be used to invoke either an automatic recovery or a manual intervention.

The design of the rejection message allows for the inclusion of multiple computer readable error descriptions. Each error is described by a collection of elements with the following interpretation:

The reasonCode element contains a numeric code (taken from a standard list) which outlines the kind of error detected.
The location element contains either a line and column number (separated by a comma) or an XPath expression. The value of the locationType attribute defines which type of location has been given. It may take the values 'lexical' or 'xpath'.
The description element contains human readable text detailing the error.
If the error is the result of a violation of a validation rule then the element validationRuleId contains the rule's identifier (e.g. 'ird-1').
The additionalData element may contain extra information useful in diagnosing the reason for failure.

Another additionalData element is associated with the MessageRejected message after the error list to allow the source for the failed XML document to be returned. A CDATA section must be placed around the source message to prevent its interpretation as XML content. The following diagram shows the design for the complete message.

In order to encapsulate one XML message within another the addition data section would have to use an XML CDATA encoding to prevent the parser from attempting to process the contents.

Message rejections may use any of the following list of error codes to indicate the reason for failure. Institutions may define their own additional error codes in the numeric range provided for user errors.

Level 100: Message transport and delivery problems

100: Default transport error code
101: Transport unavailable
102: Unknown recipient/destination
103: Delivered to wrong recipient
104: Timeout - message delivered past expiration
105: This type of message not accepted on this transport
106: Message generation problem (e.g. data conversion)
110: Message corrupted (e.g. CRC failure)
111: Message text doesn't match digital signature hash

Level 200: Message Integrity and Processing problems

200: Default message processing error code
201: Lexical problem - not well-formed XML
202: Unsupported character set
203: Empty or missing content
204: Content too large
210: System unavailable
211: Message component text doesn't match digital signature hash

Level 300: Message Validation Problems

300: Default validation error code
301: Unknown or unsupported DTD/Schema
302: Unsupported FpML version
303: Invalid FpML message - message doesn't validate w.r.t. specified DTD/schema
304: Validation failure - unsupported message type
305: Validation failure - mandatory FpML rule (a rule we say must always be followed)
306: Validation failure - master agreement rule (a rule 2 parties agree to follow)
307: Validation failure - business policy (a rule that only the recipient has)
308: Validation failure - unsupported product/asset
310: Signature required - message content must be signed
311: Signature not accepted - problem with message signer (cert revoked, unacceptable principal, etc.)

Level 400: Business Process/Workflow Problems

400: Default business process error code
401: Don't know - unrecognized trade
402: Suitability - trade can't be done for client or dealer suitability reasons
403: Credit - trade can't be done for credit reasons
404: Not interested - recipient chooses not to respond
410: Message arrived too late - e.g. trade no longer exists
411: Message expired - message arrived on time, but a response was not generated in time

Level 500: User Defined

3.3 The Business Processes

FpML releases to date have concentrated on defining only product structure. These products are the key part of many messages but in order to have a meaningful 'conversation' additional information is required to express the action that the message sender believes the message receiver should perform upon receipt of the message. Usually a key data structure like a product and/or party is the main component of the data that accompanies the request but for some actions additional parameters may need to be included.

3.3.1 B2B Request for Quote

This section outlines a process for requesting and obtaining a quote for a trade prior to entering into a full contractual trade. The processes shown are based on those in use today in markets that already have an established electronic market.

Within this section well shall refer to two types of market participant, namely:

Market Makers

Dealers who will typically provide either a one or two way price on a given financial instrument.
Market Takers

Traders who will typically request and subsequently trade on prices provided by market makers.

A request for quote process could be conducted directly between a market maker and a market taker (e.g. Citigroup's 'CitiFx FX Benchmark' service) or more commonly through an electronic exchange or trading portal where several market makers may quote on the same request.

3.3.1.1 Product Specification for RFQ

The specification of products in request for quote messages is different than for those in post trade messages. The product may be more ambiguous (e.g. it may not specify whether it is a buy or sell) and irrelevant settlement specific data can be omitted.

The 'symmetric' nature of FpML product specifications creates some additional problems when considering their generalization into pre-trade messages. FpML avoids the use of simple 'buy' and 'sell' indicators by associating parties with components of a product and indicating their obligation (i.e. payer or receiver). However this approach has three problems in the pre-trade space.

Anonymity

In some negotiations the identity of the market taker may not be known until an agreement has been reached. FpML requires party information within a product specification to identify obligations. An identity could only be hidden if a standard 'dummy' party was allowed in negotiation messages.
Multicasting

A market taker may request quotes on the same product from many market makers. Given the current definitions the product definition would need to be customized for each potential recipient. Alternatively another 'dummy' party could be used to represent any maker.
Two Way Quotes

In many negotiations the intent of the market taker is unclear and market maker provides both a buy and a sell price. The use of party to identify obligation in an FpML product means that can only have one interpretation (i.e. it is either a buy or a sale, it can never be both).

It is clear that if the current style of product definition is to be used for pre-trade then some additional conventions will need to be adopted.

Whilst it would be possible to generalize the current post trade definitions by making some of the current elements optional (so they could be excluded in RFQs) and the addition of extra optional elements of quote specific data this would lead to possibility that RFQ products could appear in post trade messages (and vice versa). Syntactically such messages would be valid and extra validation rules could need to defined to detect this semantic error.

A simpler solution would be to define a new set of product definitions specifically for pre-trade messages based on a similar framework as is used for the existing post-trade products. To implement this a new global element and base type are needed to serve as the attachment point for substituting definitions.

Given these definitions quotable versions of the existing products can be created, for example for FX:

Using this definition it is possible to express the intention of the transaction (e.g. the currencies, delivery date(s) and notional amount) whilst leaving other values (i.e. the exchange rate) out.

<quotableFxSingleLeg>
  <exchangedCurrency>
    <paymentAmount>
      <currency>GBP</currency>
      <amount>1000000</amount>
    </paymentAmount>
    <paymentDate>
      <unadjustedDate>2003-07-25</unadjustedDate>
      <dateAdjustments>
        <businessDayConvention>FOLLOWING</businessDayConvention>
        <businessCentersReference href="CENTERS"/>
      </dateAdjustments>
    </paymentDate>
 </exchangedCurrency1>
  <exchangeRate>
    <quotedCurrencyPair>
      <currency1>USD</currency1>
      <currency2>GBP</currency2>
      <quoteBasis>CCY1PERCCY2</quoteBasis>
    </quotedCurrencyPair
  </exchangRate>
</quotableFxSingleLeg>

By keeping the quotation product definition close to that of the post-trade product (e.g. using the same element names and ordering) a responding message can be constructed by copying sections of the input message (e.g. parts of the parsed DOM tree representation) and enriching it with any required data to form the full product definition.

In order to create the example definition for FX two other definitions had to be generalized, namely QuotablePayment (from Payment) and QuotableMoney (from Money). These definitions have no direct relationship with their fully formed partners, they are simply modified copies of the original XML schema definitions, although it would be possible to define them using 'inheritance by restriction' (e.g. Money could be inherited from QuotableMoney making the amount element mandatory, Payment and QuotablePayment could be derived from some generic common base class).

3.3.1.2 Bilateral Request for Quote

This section describes the follow of messages required in a bilateral exchange directly between a market maker and a market maker. It is assumed that market maker operates two systems to support his trading business: one to manage his communication with market takers (the quotation system) and one to record transactions (the trading system). The features of these two logical systems could reside in a single physical implementation.

The following diagram shows the sequence of message exchanges (including an additional flow for a quote update) under normal operation.

images/messaging/BilateralRequestForQuote.jpg

The role of each of the messages is as follows:

The market taker sends the quotation system a RequestQuote message describing the properties of the transaction in which he is interested in. The quotation system forwards the message on to the market maker for attention. The RequestQuote message uses the QuotableProduct definition to allow the product to be loosely defined.

Note that the message allows more than one product be to included to allow a number of quotes to be request simultaneously.

The market determines either a one-way or two-way price for the product and the left of time for which that quote will be honored and returns it to the market taker via the quotation system. The market marker can quote for a subset of the requested products (or none of them by not responding at all).

The market taker accepts the quote and informs the quotation system of which quote (if the price was two-way) was taken by returning a fully formed trade (possibly containing the market takers settlement information). The quotation system forwards the acceptance to the trading system.

The quotation system should ensure that details of the trade within the AcceptQuote match the quotation provided earlier and that the quote is still valid.
When the trading system confirms its acceptance of the transaction by returning it in a TradeExecution message, informing each party that the trade is complete.

The role of the quotation system in the above processing is to ensure that both market makers and market takers are treated fairly during the quotation process, by maintaining an audit record of message from both parties in order of arrival.

In practice the negotiation of a rate or price for a transaction may require more message exchanges than shown in the last example and there are a number of different outcomes that can occur, namely:

The market taker may choose not to act on the quote, leaving it instead to expire at the time designated by the market maker.

images/messaging/BilateralQuoteNotUsed.jpg

There are no messages to inform parties of the expiration of a quote, rather it is discovered by exception when a stale quote is acted upon (shown later).
The market maker may choose to refine a previously made quote to reflect a change in market conditions. A marker taker may be tempted to trade on the new quote (as shown in the following diagram) or may leave it to expire or be cancelled.

images/messaging/BilateralUpdateQuote.jpg

The market taker may re-request a quote for the same product for which he requested an earlier quotation. If the earlier quotation is still active then the request could be ignored or an update sent to original request. If the quote has expired then the normal quotation process is repeated.

images/messaging/BilateralRepeatQuote.jpg

A market taker may attempt to take up a quotation after it has become expired. This could be accidental or caused through synchronization issues between the systems (e.g. differences between system clocks, message delays or processing order).

images/messaging/QuoteAlreadyExpired.jpg

3.3.2 Trade Execution

This section contains the set of messages to report a new block trade and to modify or cancel the report.

3.3.2.1 TradeExecution

This message is used to report the execution of a block-level trade. Its content model is similar to the previous TradeCreated message, which was deprecated in FpML 4.2. It is also similar to an NOE (Notice of Execution) in FIX.

It contains a trade and 2 or more parties.

3.3.2.2 TradeExecutionModified

This message is used to report a modification to a previously-reported trade execution.

Content model includes:

optionally, the original version of the trade, or just an identifier
the revised version of the trade
2+ parties

images/messaging/TradeExecutionModified.jpg

3.3.2.3 TradeExecutionCancelled

This message is used to cancel a previously reported trade execution, e.g. if the trade was raised in error.

Content model includes either a trade identification section or a complete trade, plus one or more parties.

images/messaging/TradeExecutionCancelled.jpg

3.3.2.4 Workflows

3.3.2.4.1 TradeExecution within the Trade Lifecycle

The TradeExecution message could be the first message in a flow, or could happen as the result of a previous RFQ process.

In the case of an RFQ, the 'QuoteAcceptanceConfirmed' message of FpML 4.x has been deprecated in 4.4, and removed in version 5.0, and the TradeExecution message must be used in its place.

The TradeExecution message would typically be followed by an allocation process, initiated by the RequestAllocation message.

The following diagram illustrates the overall flow of an RFQ, Trade Execution, and Allocation process:

images/messaging/RFQTradeExecAllocation.jpg

3.3.2.4.2 Correction and cancellation flow

In the case of an error in the original TradeExecution message, the TradeExecutionModified message is provided to correct the details.

The following diagram illustrates the scenario where a trading platform reports an execution, then corrects it twice (presumably due to an interaction out of scope of this diagram, such as GUI interactions), then finally decides that the trade was raised in error and cancels it.

images/messaging/TradeExecCorrectionCancellation.jpg

3.3.3 B2B Trade Affirmation

Within the context of FpML, trade affirmation is considered to be a notification of trade execution. An affirmation message may be sent internally or externally after the trade negotiation has completed. At this point the trade may not have been legally confirmed between the two principal parties. Trade affirmations may also be sent by a third party, e.g. a broker, to the principal parties involved.

3.3.3.1 The Affirmation Process

There are a few basic patterns that are used in the industry today for delivery of trade affirmation messages. In all cases the workflow is basically the same. That is, a notification message is sent from a trading system (either an internal/external system or broker) followed by an acknowledgement of receipt (response message) from the message receiver. Acknowledgement of receipt is used to complement the asynchronous nature of the affirmation message and to assure that the message is not deleted from the originating system prior to being persisted in the destination system.

The following sequence diagram illustrates the process for one side of a bilateral affirmation. Both parties to the trade may be executing this process to obtain an affirmation from each other.

images/messaging/BilateralTradeAffirmation.gif

The affirmation message typically contains the same information that is contained in a trade confirmation message. Some details, such as settlement information, could be omitted if it is unknown to the affirmation sender. The following diagram shows the content model for a 'TradeAffirmation' message.

The response to the affirmation message indicates its acceptance and indicates the transaction to which it applies. The content model for it is as follows:

If the trade affirmation is being generated by a third party, such as a broker, then affirmation could be sought from one side and then the other, or from both simultaneously as shown in the following diagram.

images/messaging/TrilateralTradeAffirmation.gif

The data content of the messages is the same as in the bilateral case.

3.3.4 B2B Trade Confirmation

Today the procedure for achieving trade confirmation is manual for most OTC derivative transactions. Principally this is because the information describing the economic and legal liabilities of the transaction are embedded within a native text document and set amongst legal wording. A skilled human reader is needed to extract and compare the relevant information to determine if it matches the bank's own definition of the same deal.

This section describes how the process of trade confirmation for OTC derivatives might be achieved electronically through the exchange of a sequence of 'messages' between the two parties' computer systems. This can only take place if the parties involved have identified and 'marked-up' the salient details of the transaction using a common vocabulary of terms and data structure, such as those provided by the FpML product definitions.

3.3.4.1 The Confirmation Process

There are two common styles for trade confirmation used by the finance industry today:

Bilateral confirmation models the current manual process where one party (the confirmation requester) creates a legal definition of the trade, signs it and sends it to the other party (the confirmation provider) who checks and then countersigns the document and returns it.

images/messaging/BilateralConfirmation.gif

This countersigned document becomes the legally binding definition from the transaction once it has been acknowledged back to the requester.

Both parties might be attempting to obtain a confirmation from the other with this method at the same time.
Trilateral confirmation involves both parties to a trade each generating and sending a copy of the agreed upon trade to an independent third party. When the third party determines that two trades match it sends an identical trade representation to both parties to confirm the match.

images/messaging/TrilateralConfirmation.gif

The trade description generated by the confirming service becomes the legally binding trade representation.

3.3.4.2 The Matching Process

Matching and comparison are central to confirmation process. In basic terms the matching operation is carried out as follows.

Each new request to confirm a trade results in a search of the system's set of currently unmatched trades to determine if a viable match exists. A trade is comprised of a set of data items that describe its properties and each one of these in turn falls into one of following three categories:

Identifying financial items that, if present, must exactly (or within tolerance) match (e.g. common trade identifier, trade date, maturity, product type, currencies, notional amounts, parties, etc.).
Non-identifying items that should exactly (or within tolerance) match (e.g. business centers, date roll conventions, etc.).
Items irrelevant to the matching process (e.g. comments).

As a result of the matching process a trade is said to be:

Matched - If all identifying and non-identifying items agree.
Mismatched - If all identifying items agree but the non-identifying items differ.
Unmatched - No match on identifying items could be found.

If a trade is matched then both descriptions of a trade are fully reconciled and the parties can agree that it is confirmed. If the trades contain identification information that shows that they should have matched but other significant details differ then the trade is mismatched.

If no match was found then the system must assume that it is yet to receive a copy of the trade from the other party and should add it to the set of unmatched trades and wait for the next request.

Some additional actions are required to prevent trades remaining unmatched indefinitely. There are two cases that can give rise to this situation:

The counterparty failed to enter and send his definition of the transaction (so no counter-trade exists in the system).
The counterparty incorrectly identified the true party (in which case a counter-trade exists but will never match).

To attempt to recover from both cases after a trade has remained unmatched for a period of time, the system should send a message to the alleged counterparty in order to provoke them into investigating whether they need to send a new trade or correct an existing unmatched trade.

If after an additional time period the trade still remains unmatched, it should be returned as failed.

3.3.4.3 Bilateral Confirmation

The following sections illustrate the end-to-end sequence of message exchanges required to confirm a transaction directly between two parties and the various outcomes that are possible.

3.3.4.3.1 Normal Operation

Under normal operation we would expect a match to be found as soon as both the internally and externally generated copies of the trade are submitted to the confirmation engine.

images/messaging/BilateralNormalOperation.gif

Following a trade negotiation each side generates a 'RequestTradeConfirmation' message which is sent to the confirmation provider's system. These requests are used to initiate a trade matching operation. The structure of the request message is shown below.

images/messaging/RequestTradeConfirmation.jpg

If the request is valid then the trade is passed to the matching engine for processing. The 'RequestTradeMatch' message needs the same basic data content as the confirmation request message.

When a match is found the associated notification message needs to identify the two trades (via their identifiers) to the participants.

To finish the process the confirmation requestor confirms his acceptance of the match by issuing a 'ConfirmTrade' message that contains a reference to the matched trade.

The final notification of the confirmation provider reiterates the legally binding definition of the trade.

If the request contains the details for a transaction which has already been processed by the confirmation service then a number of possible errors can result in response to the request:

If a request to confirm the same trade was made previously and the trade is currently unmatched or mismatched, then the service should reply with a 'TradeAlreadySubmitted' message.

The 'TradeAlreadySubmitted' message has the following content model:

images/messaging/TradeAlreadySubmitted.jpg

If a request to confirm the same trade was made previously and the trade was successfully matched, then the service should reply with a 'TradeAlreadyMatched' message.

images/messaging/BilateralAlreadyMatched.gif

The 'TradeAlreadyMatched' message has the following content model:

images/messaging/TradeAlreadyMatched.jpg

3.3.4.3.2 Mismatch

If a mistake has occurred in the generation of one trade confirmation request it is possible that the system can detect that two trades should have matched (e.g. they contain a common unique trade identifier) but that they cannot due to significant differences.

The confirmation system keeps trades in its pool following the mismatch notification to allow a subsequent correction or cancellation to be applied to the trade.

The 'TradeMismatched' notification must contain the participants trade identifier as well as the identifier for the counter-trade that it should have matched, together with any other potential matches.

3.3.4.3.3 Confirmation Correction

Whilst a trade is unconfirmed the requesting party may send new copies of the transaction data to replace the original trade details. The data content of the replacing transaction should match the same requirements as those for initiation. Transactions must be fully re-specified (rather than just the incremental differences). The content model for the 'ModifyTradeConfirmation' message which requests this is as follows:

images/messaging/ModifyTradeConfirmation.jpg

There are a number of scenarios that can result in the processing of such messages:

The confirmation system may not be able to locate the original trade description to be modified.

images/messaging/BilateralModifyTradeNotFound.gif

The generated 'TradeNotFound' message contains the identifier for the trade the system was unable to find.

The modification may be accepted and propagated to the matching engine but the trade remains unmatched.

images/messaging/BilateralModifyUnmatched.gif

As with the initial matching request the 'ModifyTradeMatch' message contains a full copy of the trade.

The modification may be accepted and propagated to the matching engine resulting in a mismatched trade.

images/messaging/BilateralModifyMismatch.gif

The modification may be accepted and propagated to the matching engine resulting in a matched trade.

images/messaging/BilateralModifyMatch.gif

3.3.4.3.4 Confirmation Cancellation

Whilst a trade is unconfirmed the requesting party may ask the entire confirmation action to be cancelled. The cancellation message needs only to contain the information necessary to identify the transaction it affects and must match a currently unconfirmed transaction.

images/messaging/CancelTradeConfirmation.jpg

As in earlier cases there are a number of possible processing scenarios depending on the state of the trade within the confirmation system, namely:

If the cancellation applies to a trade that can not be located, then the sequence of messages is as follows:

images/messaging/BilateralCancelTradeNotFound.gif

If the cancellation applies to an existing unmatched trade then, it generates the following messages:

images/messaging/BilateralConfirmationCancelled.gif

Once the confirmation system has identified the trade as unmatched it must request that the matching system remove the trade from its storage. This is done through a 'CancelTradeMatch' message.

The response to the confirmation requester completes the process by acknowledging that the confirmation request is cancelled.

images/messaging/ConfirmationCancelled.jpg

If the cancellation applies to a trade which has already been matched, then the message flow is as follows:

images/messaging/BilateralCancelTradeAlreadyMatched.gif

3.3.4.3.5 Alleged

When the confirmation provider detects an unmatched trade that has been outstanding for a period of time, it sends a copy of the transaction to the indicated counterparty. The trade is not removed from the unmatched trade set so that a subsequent new trade confirmation or modification request may match against the trade.

images/messaging/BilateralTradeAlleged.gif

The 'TradeAlleged' message must provide the identification information for the transaction that is alleged against the counterparty. A confirmation service might provide additional information to suggest current unmatched trades that might be a counter transaction.

3.3.4.3.6 Unmatched

A request for trade confirmation that remains unmatched, even after alleged trade processing, for a length of time, should be returned to the requester within a message indicating a failure to match.

images/messaging/BilateralTradeUnmatched.gif

The 'TradeUnmatched' notification contains identification information for the unmatched trade and may contain suggestions for possible counter trades.

3.3.4.4 Trilateral Confirmation

This section illustrates some processes in action with a third party performing the matching process. In general the sequence of requests and responses is the same as in the bilateral case and there are no additional trilateral specific message types.

3.3.4.4.1 Normal Operation

As before the confirmation process is begun when the trading parties send a description of the trade to the confirmation system, now external to both parties.

images/messaging/TrilateralNormalOperation.gif

The presence of the third party allows the match to be taken as legally binding and it is automatically considered confirmed without the need for any further messages.

If the request contains the details of a transaction that has already been processed by the conformation service then a number of possible errors can result from the request, namely:

If the trade has already been submitted and is currently unmatched or mismatched the service should reply with a 'TradeAlreadySubmitted' message.

images/messaging/TrilateralAlreadySubmitted.gif

If the trade has already been processed and has been matched, then the service should reply with a 'TradeAlreadyMatched' message.

images/messaging/TrilateralAlreadyMatched.gif

3.3.4.4.2 Mismatch

The message pattern for the detection of a mismatch is the same as in the bilateral processing case.

3.3.4.4.3 Confirmation Correction

As in the bilateral case either party can request that the details of an unmatched trade be replaced with a new definition. The series of scenarios are identical to the bilateral cases.

If no corresponding trade can be found in the confirmation system then a 'TradeNotFound' messages is generated.

images/messaging/TrilateralModifyTradeNotFound.gif

The modification may be accepted and propagated to the matching engine but the trade remains unmatched.

images/messaging/TrilateralModifyUnmatched.gif

The modification may be accepted and propagated to the matching engine resulting in a mismatched trade.

images/messaging/TrilateralModifyMismatch.gif

The modification may be accepted and propagated to the matching engine resulting in a matched trade.

images/messaging/TrilateralModifyMatch.gif

3.3.4.4.4 Confirmation Cancellation

As in the bilateral case either party can request that the confirmation processing for an unmatched trade be suspended and the trade definition removed from the set of unmatched trades.

If the cancellation applies to a trade that can not be located, then the sequence of messages is as follows:

images/messaging/TrilateralCancelTradeNotFound.gif

If the cancellation applies to an existing unmatched trade, then it generates the following messages:

images/messaging/TrilateralConfirmationCancelled.gif

If the cancellation applies to a trade which has already been matched, then the message flow is as follows:

images/messaging/TrilateralCancelTradeAlreadyMatched.gif

3.3.4.4.5 Alleged

The process of notifying a counterparty of an alleged trade is exactly the same as in the bilateral case.

images/messaging/TrilateralTradeAlleged.gif

3.3.4.4.6 Unmatched

As in the bilateral case any trades that remain unmatched, even after alleged trade processing has been attempted, are eventually removed from the unmatched trade set.

images/messaging/TrilateralTradeUnmatched.gif

3.3.5 B2B General Processes

3.3.5.1 Trade Status Enquiry

At a number of points in the confirmation process it is possible that one or the other or both parties to a transaction received an unexpected error message from the other or the central service.

In order to determine the correct course of action to recover from such an error the participants need to determine the perceived state of their transaction within the other party's systems. This indicates that a simple status enquiry operation would be required to recover the necessary information.

For efficiency the trade status enquiry message should allow more than one transaction to be checked at a time (e.g. all outstanding unmatched trades, etc.). Its content model is as follows:

The response message returns each identifier with a suitable status code value (i.e. unmatched, matched, confirmed, not known, etc.).

3.3.6 A2A Trade Updates

Most financial institutions use a collection of systems to manage their trade portfolios, usually with each system providing functionality specific to either a financial product (e.g. foreign exchange, equity, money markets, etc.) or part of the trade processing lifecycle (e.g. trading, risk management, settlement, etc.).

As consequence of this distribution of function, information must be transferred between systems in order to facilitate the administration and execution of the transactions over time. In order to maintain consistency between the master copy of a transaction and any replicas of it that may have been created in other systems any change that is applied to the master copy must be notified to the downstream systems so that they too may (if appropriate) update to reflect the change.

Changes to transactions occur for two primary reasons, namely:

Human error may have caused a discrepancy in the values which parametrically describe the transaction and may be subsequently discovered and corrected.
Manual or automated processing related to behavior of the financial product may cause the transaction to change (e.g. option exercise, maturity, etc.)

There are two common ways in which notifications for transaction changes are constructed. One approach is to consider having only two message types, one to indicate the creation of a transaction and another to cause its deletion. In this style an update would be considered to be a deletion of the old transaction image immediately followed by a re-creation of the transaction its new state. Such a protocol will allow the accurate transfer of information between two systems but it fails to relate the two events making it hard to see what the actual cause of the change was.

A better approach is to have a family of messages, each customized to a specific event so that the receiver can adjust its representations of the affected information and at the same time record a connection between the affected items. Such messages can be processed 'atomically' taking the data from one consistent state to another, and at no time leaving the changes incomplete.

The following diagram shows the processing sequence shared by all such notifications. Note that in a real environment the notification message is more likely to be 'multicast' to a number of receivers rather than just one as in the example and/or may pass through some intermediate routing service.

3.3.7 A2A Generic Trade Notifications (Deprecated)

The A2A Trade Notifications messages have been deprecated. See Contract Notifications section for new meessages replacing them.

3.3.7.1 Trade Creation (Deprecated)

When a system that acts as source of trade information detects that a new trade has been created it should create and send a TradeCreated notification to inform downstream systems.

3.3.7.2 Trade Amendment (Deprecated)

When a system that acts as source of trade information detects that an existing trade has been modified it should create and send a TradeAmended notification to inform downstream systems.

3.3.7.3 Trade Cancellation (Deprecated)

When a system that acts as source of trade information detects that a previously existing trade has been cancelled it should create and send a TradeCancelled notification to inform downstream systems.

3.3.8 Novations

3.3.8.1 Introduction

This section looks at how the entire trade novation process can be represented as an exchange of FpML based messages between parties.

A novation is a transaction in which a ‘transferor’ transfers to a ‘transferee’, with the consent of the ‘remaining party’, all of its rights and obligations under the contract in respect to the novated amount. The effect of the agreement is that for the ‘novated amount’ (i.e. all or part of the outstanding notional amount), the old transaction between the transferor and the remaining party is terminated, and a new transaction is executed between the remaining party and the transferee with economic terms identical to those of the old transaction.

A three-way novation is between a transferee, a transferor and a remaining party. The typical four-way novation is between a transferee, a transferor, a remaining party and a related second remaining party (where remaining party had the deal with the transferor, and the second remaining party is a related company to the remaining party who assumes the deal with the transferee).

The process model for novation has been split into two sections.

During the discovery stage the parties negotiate the details of the novation (e.g. the amount to be novated and any payment required in return) and consent for the novation is obtained from each party.
Assuming consent has been obtained then in the second stage the negotiated details are acted upon and the actual transfer of rights and obligations is performed.

As the negotiation today is largely conducted by telephone the first stage of the process is optional and processing can begin directly with the second stage.

3.3.8.2 The Novation Process

Scenario:

Institutions ABC (the ‘transferor’) and DEF (the ‘remaining party’) have previously negotiated and confirmed a transaction of some kind. ABC now decides that it would like to novate all or part of the transaction to a third party XYZ (the ‘transferee’).

The following diagrams assume direct and reliable communication between all of the parties (possibly through some central hub).

3.3.8.2.1 Phase 1: Consent and Negotiation

Before a novation can take place all the parties must give consent to the transfer of rights and liabilities. As the transferor is the initiator of the novation they should be the party that sends the initial messages.

The key problem is one of ensuring that all parties are aware of the acceptance or non-acceptance of their counterparts. The transferor could contact each in turn to request their consent but a more elegant solution to use multiple ‘sendTo’ and ‘copyTo’ facilities of the message header to pass requests and responses between all parties simultaneously.

A ‘NovationConsentRequest’ message passes details of the previously negotiated transaction that the transferor wishes to novate as well as describing the identity and roles of each party. As the same message is sent to both the transferee and remaining party it must contain the complete description of the underlying transaction (rather than just a reference) as the transferee will have no record of it.

Figure 1 (above) Successful Novation Consent

The XML model of the ‘NovationConsentRequest’ would look as follows.

The required ‘transferor’, ‘transferee’, and ‘remainingParty’ elements, with the optional ‘otherRemainingParty’ element, indicate the roles in the transaction by providing references to the ‘party’ elements.

The optional ‘otherRemainingParty’ element is not applicable in a three-way novation and should be omitted. In a four-way novation the party referenced is Transferee 2. Transferee 2 means a party which accepts by way of novation the rights, liabilities, duties and obligations of Transferor 2. ISDA 2004 Novation Term: Transferee 2 (four-way novation).

The ‘oldTransaction’ indicates the original trade between the transferor and the remaining party. This can alternately be represented by the ‘oldTransactionReference’. The ‘newTransaction’ indicates the new trade between the transferor and the remaining party (for a 3-way novation) or other remaining party (for a 4-way novation). This can alternately be represented by 'newTransactionReference'.

The ‘novationDate' is the date on which the rights, obligations etc. transfer between the parties. The 'novationTradeDate' is the date on which the parties agree that they will novate. If a 'novationTradeDate' is not specified, the 'novationTradeDate' will be deemed to be the 'novationDate'. The ‘novatedAmount’ (or ‘novatedNumberOfOptions’) by validation rule must be of the same currency and equal to or less than the appropriate notional amount in the product element within the ‘oldTransaction’ between the transferor and the remaining party.

The 'fullFirstCalculationPeriod’ is of type boolean. If its value is 'true', ‘fullFirstCalculationPeriod’ has the implicit value of “applicable” as detailed in the ISDA novation agreement. On the other hand, if its value is 'false', it has the implicit value of "inapplicable".

The 'firstPeriodStartDate' with respect to the Transferee and Remaining Party is included in the Novations message to be able to make sense of the “new transaction” without requiring reference back to the “old transaction”. The 'href' attribute references the relevant party that is making the payments

The 'nonReliance' element corresponds to the non-Reliance section in the 2004 ISDA Novation Definitions, section 2.1 (c) (i). The element appears in the instance document when non-Reliance is applicable

The 'creditDerivativesNotices' element should be specified if one or more of either a Credit Event Notice, Notice of Publicly Available Information, Notice of Physical Settlement or Notice of Intended Physical Settlement, as applicable, has been delivered by or to the Transferor or the Remaining Party. The type of notice or notices that have been delivered should be indicated by setting the relevant boolean element value(s) to true.

The absence of the 'creditDerivativesNotices' element means that no Credit Event Notice, Notice of Publicly Available Information, Notice of Physical Settlement or Notice of Intended Physical Settlement, as applicable, has been delivered by or to the Transferor or the Remaining Party.

If the receiving party agrees with the novation then they should respond with a ‘NovationConsentGranted’ message. The Transferor or the Transferee may include the details of a payment representing the market value of the transaction.

Since the Novation transaction itself is governed by one or more ISDA contractual definitions and supplements these are specified within the Novation structure with the following two elements: 'contractualDefinitions' and 'contractualSupplements'.

For example, for an IRS novation this will typically reference the 2004 ISDA Novation Definitions and the 2000 ISDA Definitions. For Credit Derivatives it references the 2004 ISDA Novation Definitions, the 2003 ISDA Credit Derivatives Definitions and the May Supplement. So for interest rate products, the following values might be specified:

<novation>
		...
		<contractualDefinitions>ISDA2004Novation</contractualDefinitions>
		<contractualDefinitions>ISDA2000</contractualDefinitions>
		 ...
</novation>

And for credit derivatives, the following values might be specified:

<novation>
		...
		<contractualDefinitions>ISDA2004Novation</contractualDefinitions>
		<contractualDefinitions>ISDA2003Credit</contractualDefinitions>
		<contractualSupplement>ISDA2003CreditMay2003</contractualSupplement>
		...
</novation>

If the transferee or remaining party choose not to perform the requested novation then they can respond with a ‘NovationConsentRefused’ message.

The use of this message results in three possible message flows in the case of refusal (e.g. transferee refuses, remaining party refuses or both refuse). In all cases all of the parties are aware of the outcome and can continue processing appropriately.

Figure 2 (above) Unsuccessful Novation Consent (Remaining Party Refuses)

Figure 3 (above) Unsuccessful Novation Consent (Transferee Refuses)

Figure 4 (above) Unsuccessful Novation Consent (Both Parties Refuse)

At end of the process each party should be aware of consent status of the others. Once the transferor has received two; NovationConsentGranted’ messages and has assessed the payment terms specified by the transferee they may either begin the actual novation or request an alternative novation consent with another transferee.

All of the messages exchanged during the negotiation may have passed through an intermediary (such as a confirmation provider) who may monitor message flow, but who plays no part in the initial discovery stage.

3.3.8.2.2 Transfer of Rights and Obligations

Once all parties have consented to novate a transaction a message from any of the parties may start the transfer process.

The novation process closely resembles that for trade matching and confirmation however there are two underlying transactions that must both be matched for the novation as a whole to be confirmed.

The transferor and remaining party must agree on the details of the old transaction
The transferee and remaining party must agree on the details of the new transaction
Transferor and transferee need to agree on the payment

A novation is considered confirmed when all three parties have submitted a valid ‘RequestNovationConfirmation’ message containing matching transaction descriptions. Any of the parties may initiate the matching process by sending their message first.

The data content of this message varies according to the sender, specifically:

The transferor will provide only the old transaction details (or old transaction identifier) and possible payment details if to the transferee
The transferee will provide only the new transaction details and possible payment details if to the transferor
The remaining party will provide both the old and new transaction details.

The XML grammar for this message does not enforce this content model, rather it is intended to be asserted by a validation rule.

The sequence of processing and messages generated by a confirmation system in response to a request for confirmation will vary according to the order of their arrival from the parties. The diagram ‘Novation model 1’ shows an example of the flows assuming that remaining party sends first followed by the transferor and finally the transferee.

Similar to the trade confirmation process, first request generates ‘NovationAlleged’ messages to inform the other parties that a novation process has been started. Once a party has sent in its confirmation request it receives status notifications until either confirmation is achieved or the process is aborted.

The main difference being that for trade confirmation the alleged messages are only sent after a timeout period.

Novation model 1(above)

Novation model 2 (above): Order as per original Trade Confirmation

The following diagrams show the model for each status message:

NovationAlleged Message:

NovationMatched Message:

NovationConfirmed Message

The following items are not specifically addressed in the examples above:

The matching of the payment details
The error conditions

3.3.9 Terminations

The Termination representation in FpML is used for decreasing the notional value of a trade or fully terminating the trade.

The trade element allows the details of the underlying trade to be specified. Alternately, the tradeReference can be used to reference the previously confirmed trade. The terminationTradeDate is the date on which the the parties enter into the termination transaction. The terminationEffectiveDate is the date on which the termination becomes effective.

To indicate a full termination the “full” element is used. Alternately, for partial terminations the “partial” element is used. Depending on the type of product, the amount of the decrease is specified in the decreaseInNotionalAmount or decreaseInNumberOfOptions elements. Similarly, the outstanding amount of the trade after the partial termination is specified in the outstandingNotionalAmount or outstandingNumberOfOptions elements.

A payment for the right of termination may occur.

3.3.9.1 Negotiation Messages

FpML defines simple request/response messages for negotiating Terminations:

TradeTerminationRequest is a request message for requesting a Termination. TradeTerminationResponse is a response to the request for Termination.

3.3.9.2 Confirmation Messages

FpML defines a request and a notification message for confirming Terminations:

RequestTerminationConfirmation is used for requesting that the contained termination be put forward for matching and confirmation.The TerminationConfirmed (notification) message is generated when a Termination is determined to be confirmed.

3.3.10 Increases

The Increase representation in FpML is used for increasing the notional amount of a trade.

The trade element allows the details of the underlying trade to be specified. Alternately, the tradeReference can be used to reference the previously confirmed trade. The increaseTradeDate is the date on which the parties enter into the increase transaction. The increaseEffectiveDate is the date on which the increase becomes effective.

Depending on the type of product, the amount of the increase is specified in the increaseInNotionalAmount or increaseInNumberOfOptions elements. Similarly, the outstanding amount of the trade after the increase is specified in the outstandingNotionalAmount or outstandingNumberOfOptions elements.

A payment for the right of increase may occur.

3.3.10.1 Negotiation Messages

FpML defines simple request/response messages for negotiating Increases:

TradeIncreaseRequest is a request message for requesting an Increase. TradeIncreaseResponse is a response to the request for an Increase.

3.3.10.2 Confirmation Messages

FpML defines a request and a notification message for confirming Increases:

RequestIncreaseConfirmation is used for requesting that the contained increase be put forward for matching and confirmation.The IncreaseConfirmed (notification) message is generated when an Increase is determined to be confirmed.

3.3.11 Amendments

The Amendment representation in FpML is used for amending the terms of a trade.

The trade element is used to represent the details of the amended trade. (Note that the use of tradeReference is insufficient for providing the amended trade details and is not allowed.) The amendmentTradeDate is the date on which the parties enter into the amendment transaction. The amendmentEffectiveDate is the date on which the amendment becomes effective.

A payment for the right of amendment may occur.

3.3.11.1 Negotiation Messages

FpML defines simple request/response messages for negotiating Amendments:

TradeAmendmentRequest is a request message for requesting an Amendment. TradeAmendmentResponse is a response to the request for an Amendment.

3.3.11.2 Confirmation Messages

FpML defines a request and a notification message for confirming Amendments:

RequestAmendmentConfirmation is used for requesting that the contained amendment be put forward for matching and confirmation.The AmendmentConfirmed (notification) message is generated when an Amendment is determined to be confirmed.

3.3.12 Allocations

Allocations are the division of a single market trade across two or more investors/funds.

3.3.12.1 Linking Mechanism

This section describes the way of representing allocations in FpML. This is done using the existing FpML trade structure in order to represent both, the block and the allocated trades.

3.3.12.1.1 Design Assumptions

To identify block and allocated trades inside the current FpML trade structure.
The allocated trades may be not known upfront so the solution covers two situations:
- The system knows upfront the block and the allocated trades.
- The system knows the block trade but not the allocated trades.
To allow for 2-way linkage, this means to:
- Indicate the block trade and the id for the subsequent allocated trades.
- Indicate in an allocated trade the id for the original block trade.
The tradeId element for any kind of trades (normal, block, allocated) should be kept at the same location as currently stands in the FpML trade structure.

3.3.12.1.2 Implementation

The implementation uses type substitution in PartyTradeIdentifier type so in the case that a trade is a block trade, the element has the following structure:

 
...
<partyTradeIdentifier xsi:type="BlockTradeIdentifier" >
...

In case the trade is an allocated trade, the element has the following structure:

 
...
<partyTradeIdentifier xsi:type=”AllocationTradeIdentifier" >
...

BlockTradeIdentifier and AllocationTradeIdentifier are derived types (extension) of PartyTradeIdentifier.

This is the schema structure for the new types:

3.3.12.1.3 Examples

This is an analysis of the different situations:

Example:

"Long-Form" Allocation of a Credit Default Swap (xml file)

3.3.12.1.3.1 Normal Trade

 
                                                        ...
<tradeHeader>
        <partyTradeIdentifier>
                <partyReference href=”BGI”/>
                <tradeId tradeIdScheme=”http://abc.com”>ABC100</tradeId>
        </partyTradeIdentifier>
</tradeHeader>                                                        
                                                        ...

3.3.12.1.3.2 Normal trade that is subsequently split/allocated into two trades

It is allocated into two trades ABC101 and ABC102. The block trade includes links (allocationTradeId) to the allocated trades.

 
                                                        ...
<tradeHeader>
        <partyTradeIdentifier xsi:type=”BlockTradeIdentifier”>
                <partyReference href=”BGI”/>
                <tradeId tradeIdScheme=”http://abc.com”>ABC100</tradeId>
                <allocationTradeId>  
                        <partyReference href=”Fund1”/>
                        <tradeId tradeIdScheme=”http://abc.com”>ABC101</tradeId>
                </allocationTradeId>
                <allocationTradeId>  
                        <partyReference href=”Fund2”/>
                        <tradeId tradeIdScheme=”http://abc.com”>ABC102</tradeId>
                </allocationTradeId>
        </partyTradeIdentifier>
</tradeHeader>                                                        
                                                        ...

3.3.12.1.3.3 Block Trade that is identified upfront without knowing the allocated trades

The trade is identified as block trade (xsi:type="BlockTradeIdentifier) but there aren't links to the allocated trades (no allocationTradeId elements appear).

 
                                                        ...
<tradeHeader>
        <partyTradeIdentifier xsi:type=”BlockTradeIdentifier”>
                <partyReference href=”BGI”/>
                <tradeId tradeIdScheme=”http://abc.com”>ABC100</tradeId>
        </partyTradeIdentifier>
</tradeHeader>                                                
                                                        ...

3.3.12.1.3.4 Each of the resulting allocated trades

Each of the resulting allocated trades is a separate FpML trade element. Each one of the trades is identified as allocated trade with the xsi:type="AllocationTradeIdentifier".

Allocated trade ABC101:

 
                                                        ...
<tradeHeader>
        <partyTradeIdentifier xsi:type=”AllocationTradeIdentifier”>
                <partyReference href=”Fund1”/>
                <tradeId tradeIdScheme=”http://abc.com”>ABC101</tradeId>
                <blockTradeId>  
                        <partyReference href=”BGI”/>
                        <tradeId tradeIdScheme=”http://abc.com”>ABC100</tradeId>
                </blockTradeId>
        </partyTradeIdentifier>
</tradeHeader>
                                                        ...

Allocated trade ABC102:

 
                                                        ...
<tradeHeader>
        <partyTradeIdentifier xsi:type=”AllocationTradeIdentifier”>
                <partyReference href=”Fund2”/>
                <tradeId tradeIdScheme=”http://abc.com”>ABC102</tradeId>
                <blockTradeId>  
                        <partyReference href=”BGI”/>
                        <tradeId tradeIdScheme=”http://abc.com”>ABC100</tradeId>
                </blockTradeId>
        </partyTradeIdentifier>
</tradeHeader>                                                        
                                                        ...

3.3.12.1.4 Validation Rule

With this implementation, there are potential situation where the use of type substitution in partyTradeIdentifier may be confusing. Let’s see the situation where there are multiple partyTradeIdentifier elements:

 
                                                ...
 <tradeHeader>
...
        <partyTradeIdentifier xsi:type=”BlockTradeIdentifier”>
                <partyReference href=”BGI”/>
                <tradeId tradeIdScheme=”http://abc.com”>ABC100</tradeId>
        </partyTradeIdentifier>
        <partyTradeIdentifier xsi:type=”BlockTradeIdentifier”>
                <partyReference href=”RBS”/>
                <tradeId tradeIdScheme=”http://rbs.com”>RBS100</tradeId>
        </partyTradeIdentifier>
…
</tradeHeader>                                        
                                                ...

The two partyTradeIdentifier are making reference to the same trade (block trade in this case). A validation rule should enforce that the xsi:type value should be the same for both partyTradeIdentifier elements in order to be consistent. Otherwise, you may have a potential situation where one of the partyTradeIdentifier element contains a value in the xsi:type attribute but the other doesn't’t: This situation potential case may be confusing for implementers. This potential issue applies also when the xsi:type values equals to AllocationTradeIdentifier.

3.3.12.1.5 N-Level Allocations

The BlockTradeIdentifier type supports the representation of N-level allocations in FpML. This basically means the ability to allocate a block trade to multiple allocation trades, and then allocate these in turn to other allocation trades (and so on if desired).

The support of N-Level Allocations is done with partyTradeIdentifier derived type named BlockTradeIdentifier that includes the allocationTradeId element and the blockTradeId element.

3.3.12.2 AllocationCreated, AllocationAmended, AllocationCancelled

This section introduces three generic A2A allocation messages in FpML. Each one of these is a notification message sending an allocation (represented as collection of trades). This allocation is a group of trades identified as block or allocated trades. The identification of these trades is done using the linking mechanism described above in order to identify and to link block and allocated trades in FpML.

The implementation introduces three notification messages named AllocationCreated, AllocationAmended, and AllocationCancelled. The structure of these messages is very similar to the existing “generic A2A notification messages” called TradeCreated, TradeAmended, and TradeCancelled messages. However, instead of sending a single trade, the new allocation messages are sending a collection of trades.

This is the proposed schema structure:

AllocationCreated:

AllocationAmended:

AllocationCancelled:

3.3.12.3 Allocations - Short Form Representation

This section describes a representation of allocation trades with the following features:

Supports a "short-form" allocation representation, in which the key block economics are stated once, and the allocation data is contained in a terse matrix.
Supports credit and collateral requirements, and approval management (per subaccount).
Supports fees that must be allocated ("block" fees) and fees that should not be allocated ("third party" fees).

There are two basic design principles:

The first principle is that models should always provide the option to correlate by identifier or by the entire trade but never a partial trade that requires matching.
The second principle is that the "short-form" representation of allocations should be possible in post-trade messages.

The agreement of the Messaging Working Group was to place this "short-form" representation within the trade structure in order to use this form of representation across the different post-trade messages.

Example:

"Short-Form" Allocation of a Credit Default Swap (xml file)

3.3.12.3.1 RequestAllocation

FpML message supporting the allocation "short-form" representation with a reference to the trade instead of sending the whole trade details.

The response to this message would be an AllocationCreated notification message incorporating full FpML trade representation for the block and the allocated trades.

3.3.13 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.3.13.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 does not cover at this point the process of cashflow netting among counterparties. The underlying implication of the standard is each party will present to the matching process netted payment when applicable within a trade. Payment netting across trades is however outside of the scope of this standard at the present time.

This section is organized as follows:

Design principles
Messaging and schema structure
Usage guidelines

3.3.13.2 Design Principles

This standard for cashflow matching has been 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.

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. As a result, cashflows that would result from cross-trade netting are not supported by this standard. 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:

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.

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 trade. 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.
See Annex B for state diagram of the process.

3.3.13.3 Messaging and Schema Structure

3.3.13.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.3.13.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.3.13.3.3 CancelTradeCashflows

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

images/messaging/CancelTradeCashflows.jpg

3.3.13.3.4 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 (product-type-1-0.xml)
Cash flow type scheme (cashflow-type-1-0.xml
Updated asset measure scheme (asset-measure-4-0.xml)
Cash flow status scheme (trade-cashflows-status-1-0.xml)

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

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

The examples can be found at http://www.fpml.org/spec/2006/wd-fpml-4-2-2006-02-15/html/fpml-4-2-examples-frame.html

3.3.13.4.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.3.13.4.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.3.13.4.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.3.13.5 Annex A: Class Diagram

3.3.13.6 Annex B: State Machine Diagram

3.3.14 Portfolio Reconciliation

3.3.14.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.3.14.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.3.14.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.3.14.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.3.14.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.3.14.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.3.14.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.3.14.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.3.14.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.3.14.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 requestor 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 requestors 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.3.14.4 Messaging and Schema Structure

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

3.3.14.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 complete contract details, or an element identifying the version of the position that included the full trade definition, or trade reference (mainly used for reporting purposes), or contract reference .
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.3.14.4.2 PositionsAcknowledged

When a reconciliation provider has processed a ‘PositionsAsserted’ it MAY return a ‘PositionsAcknowledged’ to the requestor. 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.3.14.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.3.14.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.3.14.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.3.14.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.3.14.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.3.14.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.3.14.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.3.15 Contract Notifications

With the introduction of the new messages described further in this section we want to make a clearer distinction between the notifications distributed between the active participants in a business process and those who do not play an active role but need to be informed of the outcome.

Participants within a business process typically establish a common context (such as a trade) for their messages and can often abbreviate their communications through the use of reference identifiers rather than having to pass complete data descriptions every time.

Downstream participants (i.e. not directly involved in the business process) typically do not see any of this communication and the final notification most likely is the first time downstream participants see the affected business data. To simplify their processing it is often better to send them a summary of the business process that contains both the initial and final states of the affected data.

Since FpML release 4.0 the schema has included some basic trade notification messages which where described as ‘Application to Application’ (A2A). The use of these messages (e.g. ‘TradeCreated’, ‘TradeAmended’ and ‘TradeCancelled’) is deprecated and that the notification message types described in this section are used instead.

3.3.15.1 Contract vs. Trade

Historically in FpML, there was no distinction between “trade” and “contract”.

However, the term "trade" should only be used to refer to the trading event and the resulting trade specifications. From there on all changes to the contracts should not be called trades, nor should the contract itself.

Trade is the transaction between a buyer and seller. Contract is the legal agreement that governs the transaction. In the contract, we can reuse the same information that details the transaction, but the contract is the legal agreement between the parties. Trade has been overloaded in FpML to cover the meaning of a contract, but that’s a mistake. Parties amend contracts, novate contracts, terminate contracts, increase contracts, not trades.

In order to allow for this distinction, a new definition of Contract has been introduced. The contract content is similar to the existing FpML trade content model but some elements have been omitted since they are not relevant for the contract definition. The omitted elements include:

brokerPartyReference: this is a single reference to a party. The model doesn’t support brokers acting on behalf of multiple parties.
tradeSide: even though there is a need to support roles within the contract model, the current tradeSide model needs to be reviewed in order to make sure that it supports only the relevant information for contracts. This will be done in a later phase.

3.3.15.2 Contract Identification

3.3.15.2.1 Primary Contract Identifier

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

<identifier>
	<partyReference=”INVM1”/>
    	<versionedContractId>
        		<contractId contractIdScheme="http://www.investmentmgm.com/coding-scheme/contract-id">CDI290204</contractId>
        		<version>1</version>
    	</versionedContractId>
    	<versionedContractId>
        		<contractId contractIdScheme=”valuation-system/contract-id”>VS3456332</contractId>
        		<version>1</version>
    	</versionedContractId>
</identifier>

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

Recipients may choose to process all contract 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 contract.
Recipients may choose to process a single contract identifier. In that case, participants must agree which system source is relevant, and ignore the others. Participants must exchange the contractIdScheme values that are going to be relevant for processing. In the example above, the recipient may keep the contract id of ‘http://www.investmentmgm.com/coding-scheme/contract-id’ and ignore the other contract id.

3.3.15.3 ContractCreated

The notification message indicating that a contract has been created at the allocation level. The FpML trade representation has an allocation node, the assumption is that the contract definition is at the allocation level, so no allocation node appears.

3.3.15.4 ContractCancelled

The ContractCancelled notification allows a contract created by mistake to be cancelled entirely.

3.3.15.5 Business Event Notifications

The business events notifications are considered to be ‘facts’ to be acted upon immediately.

This section describes the messages to support notification of full and partial terminations, novations, and increases.

The contract notifications represent an instruction to in some way adjust a contract on an effective date. The act of negotiating the instruction is 'historic fact' but the actual execution of the instruction MAY BE a future action (e.g. to be performed sometime after the instruction has been sent). As a consequence it should be possible to issue corrections or cancellations to the original instruction without needing using compensating transactions.

A simple analogy is a hotel room booking. Having made room booking (e.g. ContractCreated) the client can change the date, type of room, cancel etc. right up until the date that he's supposed to stay (‘instruction execution’). After then his booking is ‘executed’ and he's financially liable regardless of whether he actually stayed or not. If he was to receive a refund for not staying it is likely that it would have to be negotiated and take into account some administration fees (like a termination).

Once the instruction is executed correction and/or cancellation should not be possible and a compensating transaction would have to be issued. When we expand the message set in a future phase it would be possible to include reverse flows for status information (e.g. notification of actual instruction execution) and error conditions (e.g. rejection of corrections to executed instructions).

The pattern of message is simple notification with business errors generated for ‘negative acknowledgement’ conditions.

3.3.15.5.1 Termination

The termination messages allow details of a full or partial termination to be distributed to downstream participants. Please note that the notification messages split between full and partial terminations. This allows recipient to know the action at the message type level without having to inspect the content of the message.

3.3.15.5.1.1 ContractFullTermination

A ‘ContractFullTermination’ message provides the recipient with the latest terms for a full termination of the indicated contract.

images/messaging/ContractFullTermination.jpg

3.3.15.5.1.2 ContractFullTerminationCancelled

A ‘ContractFullTerminationCancelled’ message provides the recipient with an instruction to cancel a specific full termination event of the indicated contract.

images/messaging/ContractFullTerminationCancelled.jpg

3.3.15.5.1.3 ContractPartialTermination

The ‘ContractPartialTermination’ message indicates that a contract has been terminated partially.

images/messaging/ContractPartialTermination.jpg

3.3.15.5.1.4 ContractPartialTerminationCancelled

A ‘ContractPartialTerminationCancelled’ message provides the recipient with an instruction to cancel a specific partial termination event of the indicated contract.

images/messaging/ContractPartialTerminationCancelled.jpg

3.3.15.5.2 Novation

The novation messages allow details of a full or partial novation to be distributed to downstream participants.

3.3.15.5.2.1 ContractNovated

A ‘ContractNovated’ message provides the recipient with the latest terms for a full or partial novation of the indicated contract.

3.3.15.5.2.2 ContractNovatedCancelled

A ‘ContractNovatedCancelled’ message provides the recipient with an instruction to cancel a specific novation event of the indicated contract.

images/messaging/ContractNovatedCancelled.jpg

3.3.15.5.3 Increase

The increase message describes a negotiated increase in the economic value of a trade. An increase can also be used to correct an erroneous partial termination.

Please note that increase and partial termination use the same ChangeContractSize content model.

3.3.15.5.3.1 ContractIncreased

A ‘ContractIncreased’ message provides the recipient with the terms for an economic enlargement of the indicated contract.

3.3.15.5.3.2 ContractIncreasedCancelled

A ‘ContractIncreasedCancelled’ message provides the recipient with an instruction to cancel a specific increase event of the indicated contract.

images/messaging/ContractIncreasedCancelled.jpg

5 INTEREST RATE DERIVATIVE PRODUCT ARCHITECTURE

5.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 center). 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 center 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:

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

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

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

5.2.1 Implementation

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.5.8 Cap / Floor

Caps and Floors are defined as one or more capFloorStreams and zero or more additionalPayments. The capFloorStream re-uses the FpML_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

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

6 CREDIT DERIVATIVE PRODUCT ARCHITECTURE

6.1 Introduction

This section provides an in-depth review of the product architecture of FpML 4.4 Credit Derivatives. The products covered by FpML 4.4 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.

6.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 4.4 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 4.4 Credit Derivatives that differ in name from their corresponding terms in the 2003 Definitions. In FpML 4.4 it is possible to represent credit default swap trades done under either the 1999 or the 2003 definitions.

The FpML 4.4 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 4.4 Credit Derivatives usable in all stages of the credit default swap trade lifecycle.

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

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

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

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

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

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

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

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

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 4.4.
The Notice and Account Details and Offices sections of the confirmation do not have a direct analog in the FpML 4.4 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.

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

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

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.

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

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.

6.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 andCoupon 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 Couponand Maturity terms respectively.

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

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

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

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

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

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

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.

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

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>

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

6.4 feeLeg

6.4.1 Credit default swap

The feeLeg element represents the information specified in theFixed Payments section of the 2003 Confirmation. In other words, this is where the payment stream from Fixed Rate Payer to theFloating Rate Payer is specified. This element reuses types and elements from FpML 4.4 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 4.4 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 4.4 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>
    <firstPaymentDate>2003-02-01</firstPaymentDate>
    <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 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
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>
	...

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

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

6.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 empty element. 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 creditEvent.

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/>
  <failureToPay>
    <paymentRequirement>
      <currency>USD</currency>
      <amount>1000000</amount>
    </paymentRequirement>
  </failureToPay>
  <restructuring>
    <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/>
      <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.

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

6.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 empty elements, using the Empty type. 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.

6.6 physicalSettlementTerms and cashSettlementTerms

If settlement terms are specified in an FpML 4.4 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

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

6.7.1 Option Components

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

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

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

6.8 Credit Event Notice

6.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 4.4 supports Credit Event Notices. Credit Event Notice is implemented in FpML as static document (DataDocument) and notification message ( both described below).

The existence of a static document representation (DataDocument) was a result of two main requirements defined by the Credit Derivatives Working Group:

It makes the relationship to the corresponding ISDA legal framework more understandable.
Other messaging standards allow an FpML document as payload.

6.8.2 Implementation

The representation as static document required the introduction of a new "event" element in the DataDocument. As mentioned before, Credit Event Notice is also modeled in the messaging framework as notification message.
The static document approach constrains the current DataDocument structure, introducing an "xsd:choice" element. The reason for that was to avoid permutations between the existing elements.

<xsd:complexType name="DataDocument">
        <xsd:annotation>
            <xsd:documentation xml:lang="en">A type defining a content model that is backwards
                compatible with older FpML releases and which can be used to contain sets of data
                without expressing any processing intention.</xsd:documentation>
        </xsd:annotation>
        <xsd:complexContent>
            <xsd:extension base="Document">
                <xsd:sequence>
                    <xsd:group ref="Validation.model"/>
                    <xsd:choice>
                        <xsd:sequence>
                            <xsd:element name="trade" type="Trade"  minOccurs=”0” maxOccurs="unbounded">
                                <xsd:annotation>
                                    <xsd:documentation xml:lang="en">The root element in an FpML
                                        trade document.</xsd:documentation>
                                </xsd:annotation>
                            </xsd:element>
                            <xsd:element name="portfolio" type="Portfolio" minOccurs="0" maxOccurs="unbounded">
                                <xsd:annotation>
                                    <xsd:documentation xml:lang="en">An arbitrary grouping of trade
                                        references (and possibly other portfolios).</xsd:documentation>
                                </xsd:annotation>
                            </xsd:element>
                        </xsd:sequence>
                        <xsd:sequence>
                            <xsd:element ref="event" maxOccurs="unbounded">
                                <xsd:annotation>
                                    <xsd:documentation xml:lang="en">A business event.</xsd:documentation>
                                </xsd:annotation>
                            </xsd:element>
                        </xsd:sequence>
                    </xsd:choice>
                    <xsd:element name="party" type="Party" minOccurs="0" maxOccurs="unbounded">
                        <xsd:annotation>
                            <xsd:documentation xml:lang="en">The parties obligated to make payments
                                from time to time during the term of the trade. This will include,
                                at a minimum, the principal parties involved in the swap or forward
                                rate agreement. Other parties paying or receiving fees, commissions
                                etc. must also be specified if referenced in other party payments.</xsd:documentation>
                        </xsd:annotation>
                    </xsd:element>
                </xsd:sequence>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>

The “event” element is a substitution group for "creditEventNotice". This means that "creditEventNotice will appear in the instance document, not "event".
The "creditEventNotification" message is an extension of a "NotificationMessage". It adds a single element called "creditEventNotice" with type "CreditEventNoticeDocument" to the notification message content.

Why "CreditEventNoticeDocument" type? Because the "CreditEventNotice" type was already defined in the Credit Derivatives subschema (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.
"creditEventNoticeDocument" is an extension of "Event" type. "Event" type is a container of events. It only contains "eventId" (an optional element to provide a unique id for each event). The idea is that this container will group other event structures.

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

6.8.2.1 Description of some of the elements

eventId - An event 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.

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.

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

6.9 Appendix A: Naming differences between FpML 4.4 Credit Derivatives Subschema and 2003 ISDA Credit Derivatives Definitions

There are several places in the FpML 4.4 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 4.4 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.

9 RETURN SWAPS PRODUCT ARCHITECTURE

9.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 and 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;
Variance Swaps (deprecated, a separate varianceSwap product element has been created - See Variance Product Architecture)

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.

9.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, Variance Swaps (deprecated).

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.

9.3 Deprecation of the equitySwap element

The use of the term 'equity' reflected the historical origin of the products defined in fpml-eqs (equity swap) subschema. They came out of the equity market as products and the contribution out of an equity team.

However, one of the most frequent uses of the 'equitySwap' element was for representing multiple types of Total Return Swaps, which could not be described as equities. The EquitySwap product type coped admirably with these but was misnamed. This was very confusing for implementers so the FpML Standards Committee decided that the EquitySwap types should be renamed ReturnSwap and that the equitySwap element should be deprecated and substituted by a new returnSwap element.

The equitySwap element will be removed in FpML version 5.0. It will still be represented in the 4.x versions for backward compatibility reasons.

9.4 Return Swaps Scope

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;
Variance Swaps (deprecated, a separate varianceSwap product element has been created - See Variance Product Architecture)

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.

9.5 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, varianceLeg (deprecated)
- 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);
- The varianceLeg (deprecated) component defines the variance leg of the swap.
Note: The equityLeg has been deprecated in FpML 4.2 Second Working Draft and it will removed in the next major release. FpML encourages the use of the returnLeg instead of equityLeg since it's a more generic representation.
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.

9.6 The Return Swap Framework

The Return Swap Framework is based on the Equity Swap proposal from Goldman Sachs, which has been a major contribution to FpML, and proved its value over time, acting both as a basis for extension, and an inspiration for other work.

The scope of the Return Swap is the exchange of price and/or cash flow return on and asset against a payment stream. The key points from a modelling perspective are that:

We have clearly identified the nature of the Product at the top level
Are exchanging directional streams, which are not netted
Only have content in the which is required to model a Return Swap

Due to the utility of the Return Swap model, we have used it to model Variance Swap, and propose to use it to model Correlation Swap, by creating leg types within the Return Swap model which:

Do not identify the nature of the Product at the top level, which remains Return Swap, rather the 'Product per Risk Factor'
Use single netted legs
Have content in the Return Swap model which is not applicable, meaning that we have a great deal of content which is schema legal, but has no business sense, and so requires the creation and application of business rules for correct processing

For all these reasons, the working group is moving to a 'Product per Risk Factor' approach. The varianceLeg has been deprecated in version 4.3 and a new varianceSwap product has been created. Future products will follow the same direction.

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

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

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

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

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

The equity:

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

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.

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.

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.

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.

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.

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 10 below provides a high-level view of these two alternative structures, which are detailed in the following paragraphs.

Figure 10: 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 dividend payout 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 seven members of the underlyingAsset substitution group (bond, convertibleBond, equity, exchangeTradedFund, future, index, mutualFund) do not appear in this diagram: only the basis elements are represented.

Figure 11: 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 basketConstituents 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 12: 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 dividend payout 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>

9.8.4 The valuation

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

Figure 13: 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 14 and 15 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 14: 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, 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 15: 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 16: The valuationPriceInterim component of the valuation, with a specific focus on the part of the structure that specifies the price.

Figure 17: 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>PriceAtValuationTime</determinationMethod>
  <valuationTimeType>Close</valuationTimeType>
  <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>
</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.

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

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>Valuation time</determinationMethod>
  <valuationTimeType>Close</valuationTimeType>
  <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>
</valuationPriceInterim>
<valuationPriceFinal>
  <determinationMethod>HedgeUnwind</determinationMethod>
  <valuationDate id="FinalValuationDate">
    <adjustableDate>
      <unadjustedDate>2003-03-12</unadjustedDate>
      <dateAdjustments>
        <businessDayConvention>NotApplicable</businessDayConvention>
      </dateAdjustments>
    </adjustableDate>
  </valuationDate>
</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 18: The valuationPriceFinal component of the valuation, with a specific focus on the part of the structure that specifies the price.

Figure 19: The valuationPriceFinal 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 valuation date can be specified, while the possibility is provided to define several interim valuation dates. The equityValuationDates component used for specifying the interim valuation dates has then been substituted with the equityValuationDate 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>HedgeUnwind</determinationMethod>
  <valuationDate id="FinalValuationDate">
    <adjustableDate>
      <unadjustedDate>2004-02-03</unadjustedDate>
      <dateAdjustments>
        <businessDayConvention>NotApplicable</businessDayConvention>
      </dateAdjustments>
    </adjustableDate>
  </valuationDate>
</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 equityPaymentDates 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 equityPaymentDatesInterim 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 equityPaymentDateFinal component specifies the final payment date.

Figure 20: The paymentDate (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 center.

<rateOfReturn>
  <initialPrice>
    <netPrice>
      <currency>USD</currency>
      <amount>37.44</amount>
      <priceExpression>AbsoluteTerms</priceExpression>
    </netPrice>
  </initialPrice>
  <notionalReset>true</equityNotionalReset>
  <valuationPriceInterim>
    <determinationMethod>PriceAtValuationTime</determinationMethod>
    <valuationTimeType>Close</valuationTimeType>
    <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>
  </valuationPriceInterim>
  <valuationPriceFinal>
    <determinationMethod>HedgeUnwind</determinationMethod>
    <valuationDate id="FinalValuationDate">
      <adjustableDate>
        <unadjustedDate>2002-09-24</unadjustedDate>
        <dateAdjustments>
          <businessDayConvention>NotApplicable</businessDayConvention>
        </dateAdjustments>
      </adjustableDate>
    </valuationDate>
  </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>

9.8.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, three possible ways of defining this notional are available:

By specifying an actual amount and currency. This is used most often for the equity leg of the swap;
By referencing 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 specifying a determination method, using the determinationMethod component This is typically useful for forward swaps, which notional is not known on trade date.

Figure 21: The notional component.

The three 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 element is used so that the notional of the interest leg can refer to it (example 12 below).

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

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

This approach is typically used for specifying the notional 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>
  <amountRelativeTo 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 id="EquityNotionalAmount">
  <determinationMethod>Number of Shares * Initial Price</determinationMethod>
</notional>

9.8.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 22: The amount (old equityAmount) 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 paymentCurrency 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 determination method 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 reference 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 23: 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>

9.8.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 24: 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 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 dividendFxTriggerDate, to specify the date on which the FX rate will be considered in the case of a Composite FX swap;
The interestAccruals, to define how interests will be accrued on the dividend when this latter is paid some period of time after the dividend payment date.

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

9.8.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 25: The quanto component.

The quanto component includes an explicit reference to a rate, through the quantoRate 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 26: The compositeFx component.

The compositeFx 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") or by specifying the information source and fixing time and date reference that will be used for defining this exchange rate, using the fxDetermination component.

The example below illustrates the application of this compositeFx component:

Example 16 - The compositeFx 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>GoodFaith</determinationMethod>
  </compositeFx>
</fxFeature>

9.9 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 six categories of components, which are presented in the figure 27 below and respectively specify the following features of the interest leg:

The payer and the receiver party;
The calculation dates;
The notional amount;
The interest amount;
The interest calculation;
The initial and final stubs.

Figure 27: The interest leg of the equity swap.

9.9.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 payerPartyReference and receiverPartyReference data elements.

9.9.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 28: 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 effective date is defined similarly than for the equity leg, as one settlement cycle following the trade date;
The termination date is also defined in the same way than the equity leg, as corresponding to the last equity payment date;
The reset dates 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 interest payment dates 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>

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

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

9.9.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 29: 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>

9.10 The variance leg (deprecated)

The variance leg supports equity variance swaps as defined in ISDA Equity Variance Swap Transaction Supplements. Due to the need to maintain backwards compatibility in this release it has not been possible to change the existing equity leg in order to support both a "short form" representation, and the concept of return based on variance. Due to the diversity of choices supported by the Equity Swap Transacation Supplement a "short form" would in any case not be much more compact than "long form".

9.10.1 The Vanilla variance swaps

The vanilla variance swaps provide exposure to variance. They are considered to be path independent because the pay-off function is indifferent to the level of the underlyer closing prices when calculating realized variance.

9.10.2 conditional variance swaps

The conditional variance swaps introduce price path dependency. A daily return is only generated if the underlyer price satisfies one or more boundary levels (‘in range’). Therefore, the investor can take a composite view across underlyer variance and price levels.

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

9.12 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 30: The exchange of principal amounts.

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:

It specifies the payer and receiver party references;
The date of each of the principal exchanges 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 principal exchange amount 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.

swaps

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>

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

9.14 The optional early termination

The purpose of the equitySwapEarlyTermination 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 30 below presents the structure of this component:

Figure 32: The earlyTermination component.

Similarly to the other date-related components that are part of the equity 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>

15 PRICING AND RISK ARCHITECTURE

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

15.2 Derivatives Pricing and Risk

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

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

15.3 Pricing and Risk Scope

The Pricing and Risk scope for FpML 4.4 Recommendation 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.

15.4 Requirements

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

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

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

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

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

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

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

15.5 Overview of design

15.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-valuation-shared-x-y.xsd – This includes 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.

15.5.2 Shared Types

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

15.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.
The time the quotation was recorded.
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.

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

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

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

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

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

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

15.5.3.2 Asset Valuation

The AssetValuation type extends the Valuation types with a full Quotation. It allows values (and the associated sensitivities) to be represented for a single asset, such as a trade or a portfolio.

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

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

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

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

15.5.3.7 Summary

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

15.5.4 Pricing Inputs

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

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

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

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

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

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

15.5.4.6.1 Yield Curve

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

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

15.5.4.6.3 Zero Rate Curve

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

15.5.4.6.4 Forward Rate Curve

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

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

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

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

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

15.5.5 Risk Definition

15.5.5.1 Overview

The fpml-riskdef-x-y.xsd file contains definitions relating to sensitivities and valuation scenarios.

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

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

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

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

15.5.5.6 Derived Valuation Scenario

The Derived Valuation Scenario is a valuation scenario that is derived from another valuation scenario by the substitution or shift of market input data. It is used for scenario reporting, such as stress testing.

15.5.5.7 Pricing Parameter Shift

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

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

15.5.7 Valuation Messaging

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

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

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

15.5.7.4 PortfolioValuationItem

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

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

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

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

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

15.6 Use Cases/Examples

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

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

15.7.1 Valuation

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

15.7.2 Risk

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

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

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

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

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

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

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

15.7.9 Portfolio

An abstract definition of a group of trades.

15.7.10 Scenario

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

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

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

15.8 Validation Rules

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

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

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

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

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

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

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

15.9.1 Abstract vs. Actual Products

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

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

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

15.9.2 Product and Trade Identification and Description

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

15.9.2.2 Options:

Create a summary view for required products.
Include full trade details
Reference trade via ID or xml reference.

15.9.2.3 Solution:

Reference the trade via ID or xml reference. Do not create a trade summary.

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

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

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

15.9.2.7 Solution:

Number 2

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

15.9.3 Pricing Inputs

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

15.9.3.2 Options

Explicit date
Tenor (number plus period)
Reference to another structure that contains a date.
Number of days
Year Fraction

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

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

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

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

15.9.3.7 Solution:

Generic ability to add another term structure dimension to an existing structure.

15.9.3.8 Rationale:

Generic structure may be too abstract to handle easily.
Separate Structures don’t provide reuse.

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

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

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

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

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

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

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

15.9.3.16 Issue 6: Handling of currency conversion

15.9.3.17 Solution:

FX rates need to be treated as pricing / reporting inputs

15.9.3.18 Rationale:

FX conversion is often required in reporting values and risks.

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

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

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

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

15.9.3.23 Solution:

Option 1: Use the partial description.

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

15.9.4 Valuation Reporting

15.9.4.1 Issue 1: How much detail is needed for the NPVs?

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

15.9.4.3 Solution:

Use Asset Measures to allow a variety of results to be returned.

15.9.4.4 Rationale:

This allows a user to extend the standard to provide more types of returned values.

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

15.9.5 Risk Types and Measures

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

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

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

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

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

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

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

15.9.5.8 Issue 4 Risk currency

The currency in which a risk figure is expressed is needed.

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

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

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

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

Provider
Implementation Language	XQuery
Implemented Rules	FpML 4.4 Equity Derivatives Validation Rules: All EQD rules
Browse	N/A
Further Information	FpML Reference Implementation

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

FpML® Financial product Markup Language Recommendation 20 August 2008

Version: 4.4

This version: http://www.fpml.org/spec/fpml-4-4-12-rec-1

Latest version: http://www.fpml.org/spec/fpml-4-4-12-rec-1

Previous version: http://www.fpml.org/spec/fpml-4-4-9-tr-3/

Errata for this version: http://www.fpml.org/spec/fpml-4-4-12-rec-1/html/fpml-4-4-errata.html

Table Of Contents