FpML Financial product Markup Language
Working Draft 4 August 2003

Version: 4.0

This version: http://www.fpml.org/spec/2003/wd-fpml-4-0-2003-08-04

Latest version: http://www.fpml.org/spec/2003/wd-fpml-4-0-2003-08-04

Previous version: wd-fpml-4-0-2003-04-04

Errata for this version: http://www.fpml.org/spec/errata/wd-fpml-4-0-2003-08-04-errata.html

Copyright 1999 - 2003. All rights reserved.

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

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

Table Of Contents

1 INTRODUCTION AND OVERVIEW
1.1 STATUS OF THIS DOCUMENT
1.2 OTHER DOCUMENTATION
1.2.1 Schema Reference
1.3 WORKING GROUP MEMBERS AND ACKNOWLEDGEMENTS
1.3.1 Architecture Working Group
1.3.2 Messaging Working Group
1.3.3 Equity Derivatives Working Group
1.3.4 Credit Derivatives Working Group
1.3.5 IRD Products Working Group
1.3.6 FX Working Group
1.3.7 Overall Document Editing
1.4 INTRODUCTION
1.5 CHANGES IN THIS VERSION
1.5.1 Changes compared to WD#1
1.5.2 Changes compared to FpML 3.0
1.5.3 Incompatible changes to FpML 3.0
1.5.3.1 Change to XML Schema
1.5.3.2 Elimination of scheme defaults
1.5.3.3 Change to Intra-document Referencing
1.5.3.4 Change to Calculation Agent Reference
1.5.3.5 Change to Documentation Type
1.5.3.6 Introduction of Messaging
1.5.4 Planned Changes in Future Drafts
1.6 SCOPE
1.6.1 Architecture Framework
1.6.2 Equity Derivatives Options Scope
1.6.3 Equity Derivatives Swaps Scope
1.6.4 Credit Derivative Scope
1.6.5 IRD Scope
1.6.6 FX Scope
1.6.7 Messaging Scope
1.6.8 Energy Derivative Scope
1.6.9 Validation Scope
1.7 PRODUCT ARCHITECTURE OVERVIEW
1.7.1 Introduction
1.7.2 Component Framework
1.7.3 Overview of Core Components
1.7.3.1 The FpML root element
1.7.3.2 The Header Component
1.7.3.3 The Trade Component
1.7.3.3.1 tradeHeader
1.7.3.3.2 product
1.7.3.3.3 otherPartyPayment
1.7.3.3.4 calculationAgent
1.7.3.3.5 documentation
1.7.3.3.6 governingLaw
1.7.3.4 The Portfolio Component
1.7.3.5 The Party Component
1.7.3.6 The Product Component
1.7.3.7 The Strategy Component
1.7.4 Coding Schemes
1.8 CHARACTER ENCODING AND CHARACTER REPERTOIRE
1.8.1 Character Encoding
1.8.2 Character Repertoire

2 MESSAGE ARCHITECTURE
2.1 Introduction
2.1.1 Styles of Messaging
2.1.2 Transport Independence
2.1.3 Control Over Content
2.1.4 Identification of Purpose
2.1.4.1 By Namespace
2.1.4.2 By Element Name
2.1.4.3 By Element Type
2.2 The Message Framework
2.2.1 The Base Message
2.2.2 Requests, Responses and Notifications
2.3 The Message Protocols
2.3.1 B2B Trade Affirmation
2.3.1.1 The Affirmation Process
2.3.2 B2B Trade Confirmation
2.3.2.1 The Confirmation Process
2.3.2.2 The Matching Process
2.3.2.3 Error Handling
2.3.2.4 Bilateral Confirmation
2.3.2.4.1 Normal Operation
2.3.2.4.2 Mismatch
2.3.2.4.3 Confirmation Correction
2.3.2.4.4 Confirmation Cancellation
2.3.2.4.5 Alleged
2.3.2.4.6 Unmatched
2.3.2.5 Trilateral Confirmation
2.3.2.5.1 Normal Operation
2.3.2.5.2 Mismatch
2.3.2.5.3 Confirmation Correction
2.3.2.5.4 Confirmation Cancellation
2.3.2.5.5 Alleged
2.3.2.5.6 Unmatched
2.3.3 B2B General Processes
2.3.3.1 Trade Status Enquiry

3 INTEREST RATE DERIVATIVE PRODUCT ARCHITECTURE
3.1 Interest Rate Swap
3.2 Forward Rate Agreement
3.3 Option Components
3.3.1 European Exercise
3.3.2 American Exercise
3.3.3 Bermuda Exercise
3.3.4 Early Termination Provision
3.3.5 Cancelable Provision
3.3.6 Extendible Provision
3.3.7 Swaption
3.3.8 Cap / Floor
3.4 Cash Settlement

4 CREDIT DERIVATIVE PRODUCT ARCHITECTURE
4.1 Introduction
4.2 creditDefaultSwap
4.3 generalTerms
4.4 feeLeg
4.5 protectionTerms
4.6 settlementTerms
4.7 Appendix A: Naming differences between FpML 4.0 Credit Derivatives Subschema and 2003 ISDA Credit Derivatives Definitions

5 FX PRODUCT ARCHITECTURE
5.1 Foreign Exchange Spot and Forward
5.2 Foreign Exchange Swap
5.3 Foreign Exchange Simple Option
5.4 Foreign Exchange Barrier Option
5.5 Foreign Exchange Binary and Digital Options
5.6 Foreign Exchange Average Rate Option
5.7 Term Deposits
5.8 Trade Strategies

6 EQUITY DERIVATIVE OPTIONS PRODUCT ARCHITECTURE
6.1 Overall Architecture
6.2 Component Descriptions
6.2.1 underlyer
6.2.2 equityExercise
6.2.3 equityEuropeanExercise
6.2.4 equityAmericanExercise
6.2.5 equityBermudanExercise
6.2.6 FXFeature
6.2.7 equityOptionFeatures
6.2.8 asian
6.2.9 barrierCap
6.2.10 equityPremium
6.2.11 Adjustment of dates in Equity Options

7 EQUITY DERIVATIVE SWAPS PRODUCT ARCHITECTURE
7.1 Introduction
7.2 Equity Swap
7.2.1 Scope of the FpML representation for equity swaps
7.2.2 The structure of the equity swap
7.2.3 The equity leg
7.2.3.1 The payer and receiver party
7.2.3.2 The effective date and the termination date
7.2.3.3 The underlyer
7.2.3.4 The valuation
7.2.3.5 The notional amount
7.2.3.6 The equity amount
7.2.3.7 The return
7.2.3.8 The notional adjustment
7.2.3.9 The FX terms
7.2.4 The interest leg
7.2.4.1 The payer and receiver party
7.2.4.2 The calculation dates
7.2.4.3 The notional amount
7.2.4.4 The interest amount
7.2.4.5 The interest calculation
7.2.5 The principal exchange
7.2.6 The additional payments when involving the principal parties to the trade
7.2.7 The optional early termination

8 APPENDIX I - Changes to Previous Version: wd-fpml-4-0-2003-04-04
8.1 Global Changes
8.1.1 Conversion of global to local elements
8.1.2 Conversion of schemes to enumerations
8.1.3 Elimination of scheme default attributes
8.1.4 Updating of examples
8.2 Content Changes
8.2.1 masterAgreement element optional
8.2.2 LegalEntity complex type added
8.2.3 IMMCAD/CADIMM
8.2.4 RollConvention = NONE/None
8.2.5 Year digits description
8.2.6 Equity Swaps Schema Corrections
8.2.7 Credit Derivative Scheme Changes
8.2.8 Credit Derivatives Schema Changes
8.2.9 Message Reject Changes
8.2.10 Corrections
8.3 Changes rolled forward from FpML 3.0
8.3.1 Add the ability to specify an initial fixing date rule
8.3.2 Add unadjusted dates to cashflow representation
8.3.3 Add unadjusted dates to cashflow representation
8.3.4 Add unadjusted dates to cashflow representation
8.3.5 Add resetDate to FxLinkedNotionalAmount
8.3.6 Add initial value to FxLinkedNotionalSchedule
8.3.7 Element Description Update
8.3.8 relevantUnderlyingDate made optional

1 INTRODUCTION AND OVERVIEW

1.1 STATUS OF THIS DOCUMENT

This is the FpML 4.0 Working Draft #2 for review by the public and by FpML members and working groups. It is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to use FpML Working Drafts as reference material or to cite them as other than "work in progress". This is work in progress and does not imply endorsement by ISDA.

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

Public discussion of FpML takes place on the FpML Discussion List: discuss@fpml.org which you can join at the following link:

http://www.fpml.org/mailing-lists/join-discuss.asp

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

http://www.fpml.org/mailing-lists/join-discuss.asp

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

http://www.fpml.org/spec

While implementation experience reports are welcomed, the FpML Standards Committee will not allow early implementation to constrain its ability to make changes to this specification prior to final release.

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

1.2 OTHER DOCUMENTATION

• Examples
• Scheme Definitions

1.2.1 Schema Reference

• Main Components
• Shared Components
• Shared Enumeration definitions
• Equity Derivative Options Components
• Equity Swaps Components
• FX Components
• Interest Rate Components
• Credit Derivative Components

1.3 WORKING GROUP MEMBERS AND ACKNOWLEDGEMENTS

This document was produced by the following working groups:

1.3.1 Architecture Working Group

• Andrew Jacobs (IBM), chair
• Kulbir Arora (Goldman Sachs)
• James Battle (Ironbark Ltd.)
• Tom Carroll (UBS Warburg)
• Igor Dayen (Object Centric Solutions)
• Daniel Dui (University College London)
• Ayesha Malik (AIG)
• Ned Micelli (Reuters)
• David Slight (Microsoft)
• Ashutosh Tripathi (BP)

1.3.2 Messaging Working Group

• Karel Engelen (ISDA), chair
• Guy Gurden (Swapswire)
• Keri Jackson (Bank of America)
• Andrew Jacobs (IBM)
• Francoise Massin (SWIFT)
• Ned Micelli (Reuters)
• Justin Oglethorpe (Citigroup)
• Rick Schumacher (Wall Street Systems)
• Bill Specht (Currenex)
• Robert Stowsky (Brook Path Partners)

1.3.3 Equity Derivatives Working Group

Voting Members

• Andrew Parry (Deutsche Bank), chair
• Tony Belverstone (Syntegra)
• Simon Brooke (Deutsche)
• Gordon McDermid (CSFB)
• Libby Doughty (Goldman Sachs)
• Tracy Ruparell (MSDW)
• Deepesh Tanna (Barclays Capital)

Non-Voting Members

• Lesly Armand (Kinetech)
• Simon Dewberry (SSMB)
• Jean Bouez (HSBC)
• Michael J. Doyle (Goldman Sachs)
• Pierre Lamy (Goldman Sachs)
• Ralf Lemster (Ralf Lemster Financial Translations)
• Claude Martini (INRIA)
• Tina Shiali (Barclays Capital)
• Jonathan Smart (Deutsche Bank)
• Kathy Wallis (Goldman Sachs)
• Ben Wydell (Barclays Capital)

1.3.4 Credit Derivatives Working Group

• Ben Lis (creditex), chair
• Kathy Andrews (Deutsche Bank)
• Tim Black (UBS Warburg)
• Elaine Bannerman (Bank of America)
• John Cobbledick (Sungard)
• Gareth Connolly (Credit Suisse First Boston)
• Mazy Dar (creditex)
• Karel Engelen (ISDA)
• Tony Hernandez (ISDA)
• Guy Gurden (Swapswire)
• Geoff Norris (BNP Paribas)
• Robin Shuk (Bank of America)
• John Weir (Goldman Sachs)
• Christina Yeung (Goldman Sachs)

1.3.5 IRD Products Working Group

• Steven Lord (UBS Warburg), chair
• Andrew Addison (Merrill Lynch)
• Ariane Athalie (BNP Paribas)
• Owen Bugge (Blackbird)
• Marisol Collazo (Mizuho Capital Markets)
• Marie-Paule Dumont (S.W.I.F.T.)
• Alexander Ernst (RiskTrak Financial)
• Tom Fahy (Goldman Sachs)
• Doug Gallager (Reval.com)
• Mark Golding (JPMorgan)
• David Gorans (BNP Paribas)
• Guy Gurden (SwapsWire)
• Paul Hoskins (Barclays Capital)
• Saleem Huda (Algorithmics)
• Vlad Iordanov (FinTrack Systems)
• Keri Jackson (independent)
• Sathy Kovvali (Citigroup)
• Philippe Negri (SunGard Trading And Risk Systems)
• Michael North (Reuters)
• Henry Teng (UBS Warburg)
• Ian Thomas(Credit Suisse First Boston)
• Patrick Treanor (Wall Street Systems)
• Olga Urrutia (S.W.I.F.T.)
• James Williams (Deutsche Bank)
• Barry Witkow (Treasury Connect)
• Chuck Witter (Bank of America)

1.3.6 FX Working Group

• Rick Schumacher (Wall Street Systems), chair
• Lee Buck (Morgan Stanley)
• Fred Burge (JP Morgan Chase)
• Marcello Davanzo (KPMG)
• Alexander Ernst (RiskTrak Financial)
• Gary Goldberg (FXPress)
• Rahul Gupta (FXAll)
• Lee Haines (Reuters)
• Richard Hall (Evolution)
• Antoine Hurstel (BNP Paribas)
• Bruce Kenney (Mizuho Capital Markets)
• Dan Kolner (UBS Warburg)
• Anna Lukasiak (Goldman Sachs)
• Tim Madeley (Cognotec)
• Francoise Massin (SWIFT)
• Donna McCollum (SunGard Trading Systems)
• Ned Micelli (Reuters)
• Justin Oglethorpe (Citigroup)
• Hugues Planzol (BNP Paribas)
• Frank Smith (Atriax)
• Gavin Smith (RCP Consultants)
• Bill Specht (Currenex)
• Tony Spraggs (Reuters)
• Viral Tolat (Integral)
• Jayesh Vira (SunGard Trading Systems)

1.3.7 Overall Document Editing

• Brian Lynn (Gem Soup), introduction, editorial, and scripting for overview sections
• Andrew Jacobs (IBM), automated documentation generation, schema consistency review

1.4 INTRODUCTION

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

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

1.5 CHANGES IN THIS VERSION

1.5.1 Changes compared to WD#1

Following is a brief list of the changes to be found in this working draft compared to working draft #1.

• Many "schemes" have been replaced by enumerations, in cases where the domain was judged to be relatively stable. In addition, all scheme default attributes have been removed from the FpML root element. Schemes that have been converted to enumerations no longer require a scheme default. Other schemes are now defaulted, where possible, as default attribute values in the schema. This change was made to improve the maintainability and readability of the FpML root element, and to make it clearer when non-default schemes are used.
• Most global element definitions have been turned into local element definitions. This change was made to reduce cross-asset name clashes and improve flexibility going forward. It also had the side benefit of reducing the documentation size by approximately 400-500 pages. This change has significantly changed the schema files, but not changed the instance documents.
• There have been a few smalll changes to Credit Derivative definitions (e.g. addition of new scheme values) to address the ISDA 2003 credit derivatives supplement.
• Enhancements to IRD cashflows recently incorporated into versions 2.0 and 3.0 have also been included in version 4.0.
• There have been a few changes to message headers and reject messages to address recommendations by the Validation working group.
• Most diagrams have been redone to improve quality.
• Example files have been renamed for clarity and consistency

1.5.2 Changes compared to FpML 3.0

Following is a brief list of the changes to be found in this document compared to FpML 3.0.

• Use of XML Schema. FpML 4.0 is the first FpML version to use XML Schema as the normative definition; this has affected the organization and contents of the type definitions section.
• New Equity Derivative products, including exotic options and equity swaps.
• New Credit Derivative products, specifically Credit Default Swaps.
• New Term Deposit product, in the FX section.
• Message Headers. A first version of an FpML messaging framework has been incorporated.
• Document production process. There have been some changes to the document production process.

1.5.3 Incompatible changes to FpML 3.0

The following changes have been introduced in FpML 4.0 which are incompatible with FpML 3.0

1.5.3.1 Change to XML Schema

FpML type definitions are now expressed using XML Schema. This replaces the document type reference (DOCTYPE directive) in each FpML document with new attributes for specifying namespaces and schema locations on the "FpML" root element. In addition the correct document content model must be selected by setting the type of the root element. The main body of the document is unaffected by the transistion to XML schema.

1.5.3.2 Elimination of scheme defaults

With the conversion of many schemes to enumerations, we have chosen to eliminate all scheme defaults from the FpML root element and replace them in some cases with default attribute values in the schema. To convert instance documents from version 3.0, you will need to remove scheme default attributes from the root element. In cases where a scheme has been converted to an enumeration, it will no longer be possible to use a proprietary set of domain values.

1.5.3.3 Change to Intra-document Referencing

Intra-document references (using the "href" attribute) now no longer have a "#" prefix, due to the change to id/idref semantics from the xlink referencing style. This change is also planned to be made to FpML 3.0, but is incompatible with instance documents developed to date. To change instance documents to accommodate the change it will be necessary to remove the "#" prefix from href attribute values.

1.5.3.4 Change to Calculation Agent Reference

In FpML 3.0 an entry was added to the trade header to specify a calculation agent. With FpML 4.0 this has been rationalized with an entry in the trade element which specifies the calculation agent(s). Documents using the calculationAgentReference in the tradeHeader will need to be changed to use the calculationAgent element in the "trade" element.

1.5.3.5 Change to Documentation Type

The masterConfirmation element now appears before the contractualDefinitions element in the definition of the Documentation type. Furthermore, in FpML 4.0 the masterConfirmation element is no longer simply a date. In 4.0 it consists of a masterConfirmationType, masterConfirmationDate and an optional masterConfirmationAnnexDate.

All FpML 3.0 documents that contain a masterConfirmation element are incompatible with FpML 4.0. Do the following in order to upgrade your 3.0 documents to 4.0:

• If the document contains both a masterConfirmation and a contractualDefinitions element(s), reverse the order of these elements.
• Move the date value that appears in the masterConfirmation element to the element masterConfirmation.masterConfirmationDate.
• Add the element masterConfirmation.masterConfirmationType with the appropriate value.

1.5.3.6 Introduction of Messaging

Messages constructed using FpML 4.0 should make use of the new message framework to express the reason for the exchange of information, to identify the parties involved in the exchange and to describe the actual information itself.

A number of standard messages have been provided for trade affirmation and confirmation along with error reporting and trade status enquiry. FpML users can derive additional message types from the framework to meet specific messaging requirements currently outside FpML's scope.

To allow backwards compatibility with existing pre-FpML 4.0 documents a 'DataDocument' type has been provided which does not include message elements.

1.5.4 Planned Changes in Future Drafts

Following is a list of changes that are anticipated to be made by the time the document reaches Last Call Working Draft:

• A number of definitions that are used in several places in the document are likely to be moved to the "shared" subschema.
• In a number of places where the localization of global elements has created repeated definitions of the same basic type, we plan to create global types. Examples include intra-document references such as party references, invocations of schemes, etc.
• A number of global types are likely to be renamed to improve clarity of scope/purpose.
• We will attempt to rationalize/consolidate a number of definitions across asset classes.
• There have been several comments proposing localized enhancements, to areas including the tradeHeader and the party element, that are likely to be addressed.

1.6 SCOPE

The scope of FpML 4.0 includes all of the FpML 3.0 scope plus significantly broadened Equity Derivative product coverage, new Credit Derivative product coverage, and support for an FpML Messaging framework.

1.6.1 Architecture Framework

The various Working Groups have developed FpML 4.0 within an architecture framework updated from the FpML Architecture Version 1.0 framework defined by the Architecture Working Group. The original FpML 1.0 Architecture framework recommendations covered:

• XML tools for editing and parsing
• XML namespace usage within FpML
• FpML versioning methodology
• FpML content model - a new style for representing the FpML Document Type Definition (DTD)
• FpML referencing methodology, including guidelines for referencing coding schemes.

The principal changes from the original FpML 1.0 architecture framework include:

• Replacement of XML DTDs (Document Type Definitions) by XML Schemas, as described in a technical note published in 2002 by the FpML Architecture WG.
• Elimination of xlink-style referencing and its replacment with id/idref-style referencing (this change is also being adopted for FpML 3.0).

The Architecture Working Group intends to publish a new architecture framework incorporating the above changes, and some others, including, among other topics:

• Proprietary extensions to FpML
• Enhanced versioning support
• Digital signature support

This updated architecture framework is likely to be published as separate document during the working draft stage of FpML 4.0.

1.6.2 Equity Derivatives Options Scope

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

• Bermudan exercise style
• Basket underlyings
• Forward starts
• Cash or Physical Settlement
• Quantos and Composites
• Averaging
• Barriers, Knock-Ins, Knock-Outs and Binary (Digital) Options

1.6.3 Equity Derivatives Swaps Scope

We have included support for various types of Equity Swaps, without any specific limitation. Those identified so far include:

• Single stock swaps as well as basket swaps
• Swaps that have an equity, index or a convertible bond underlyers, 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 swap) or multiple equity legs
• Trigger swaps, which equity return is replaced by a fixed income return once certain market conditions are met
• Swaps that have specific adjustment conditions, such as execution swaps or portfolio rebalancing swaps
• Zero-strike swaps, which do not have an interest rate component but rather involve the exchange of principal cashflows

The FpML representation of the equity swap is focused on representing the economic description of the swap. The expectation is that the reference terms of the swap will be defined either through the ISDA definitions or, when exceptions apply, through master bilateral agreements that will be agreed between the parties to the trade

In order to support the above scope for both Equity Derivative and Equity Swap products we support operational features, such as contact information and governing documentation which are present in current documents defined by ISDA standards

1.6.4 Credit Derivative Scope

In FpML 4.0 Working Draft #2 the following Credit Derivative products are covered:

• Credit Default Swap (full confirm and transaction supplement representations)

1.6.5 IRD Scope

In FpML 4.0 Working Draft #2 the following Interest Rate Derivative products are covered:

• Single and Cross-Currency Interest Rate Swap
• Forward Rate Agreement
• Interest Rate Cap
• Interest Rate Cap
• Interest Rate Floor
• Interest Rate Swaption (European, Bermuda and American Styles; Cash and Physical Settlement)
• Extendible and Cancelable Interest Rate Swap Provisions
• Mandatory and Optional Early Termination Provisions for Interest Rate Swaps
• FX Resetable Cross-Currency Swap

1.6.6 FX Scope

In FpML 4.0 Working Draft #2 the following FX products are covered:

• FX Spot
• FX Forward (including non-deliverable forwards, or NDFs)
• FX Swap
• FX Options (European and American; barriers, digitals, binaries, average rates; cash and physical settlement)
• Option Strategies (multiple simple options)

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

• Term Deposits

1.6.7 Messaging Scope

An FpML messaging working group has been formed to define a messaging framework and sample messages for selected business processes. FpML 4.0 Working Draft #2 includes a preliminary version of this working group's output; it is expected to evolve somewhat in future drafts of FpML 4.0. Business processes currently addressed by this Working Group include:

• Trade Affirmation
• Trade Confirmation

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

1.6.8 Energy Derivative Scope

In FpML 4.0 Working Draft #2 no Energy Derivative products are covered. However, a working group is currently active in this area and is expected to provide support for the following products in the next version of FpML:

• Financial Gas swaps, caps/floors, and swaptions
• Financial Power swaps, caps/floors, and swaptions
• Financial Oil swaps, caps/floors, and swaptions

It is anticipated that support for physically-settled products will be incorporated in future versions of FpML.

1.6.9 Validation Scope

An FpML validation working group began in February 2003. This draft incorporates some initial results from that working group, in the message header and reject message.

1.7 PRODUCT ARCHITECTURE OVERVIEW

1.7.1 Introduction

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.

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

1.7.3 Overview of Core Components

The root element contains three elements, trades, portfolios and parties. 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.

1.7.3.1 The FpML root element



The FpML element forms the root for an FpML instance document. The structure of the FpML document depends on the "type" attribute, which is a subtype of "Message". The simplest FpML document is a "DataDocument", which is similar to an FpML 3.0 document. A DataDocument looks like this:



It contains:

• A trade or trades
• A portfolio or portfolios
• A party or parties

In addition, the FpML root element includes attributes for:

• Specifying the FpML version and related schemas and namespaces.
• Specifying the message type.

1.7.3.2 The Header Component

Each FpML document contains a message header, which provides a context for the document. The header includes information about the sender and recipient of the message and the purpose of the message. See the section on "Messaging Architecture" for more information.

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



1.7.3.3.1 tradeHeader

The information within tradeHeader is common across all types of trade regardless of product. In FpML 4.0 this element contains the trade date and party trade identifiers.



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

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



1.7.3.3.4 calculationAgent

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

1.7.3.3.5 documentation

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

1.7.3.3.6 governingLaw

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

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



1.7.3.5 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 to the party component.



1.7.3.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
• Credit default swaps

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

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



1.7.4 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 WD#2 the handling of coding schemes has 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 has been adopted in WD#2 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 document.

1.8 CHARACTER ENCODING AND CHARACTER REPERTOIRE

1.8.1 Character Encoding

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

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

1.8.2 Character Repertoire

FpML element content, as well as values of the FpML id and href attributes, may use any valid XML characters. For more information, see

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

2 MESSAGE ARCHITECTURE

2.1 Introduction

The FpML 4.0 Schema is 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 suitable for use in a 'Business-to-Business' (B2B) or 'Application-to-Application' (A2A) 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.

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

2.1.2 Transport Independence

The FpML 4.0 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 whilst others (e.g. message based middleware, files, etc.) do not.

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.

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

2.1.4 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 as it gives the greatest control over validation whilst allowing easy extension of the message elements.

2.1.4.1 By Namespace

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

2.1.4.2 By Element Name

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.

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

2.2 The Message Framework

This section documents the definitions included in the FpML 4.0 schemas that implement the message framework.

Note that the schema diagrams in this section do not show the standard attributes (e.g. version, scheme defaults, etc.) normally associated with the FpML element to reduce the size of the images. Consult the XML schema to see the full definitions of these types and elements.

2.2.1 The Base Message

The two core definitions within the schema establish two abstract base classes, 'Message' and 'MessageHeader' from which all the other definitions are derived.



The 'Message' type contains a single element 'header' that holds the message identification and delivery data defined by the 'MessageHeader' type. The Message type inherits the set of attributes used to identify the FpML coding schemes by extending the Document type. The elements that comprise a 'MessageHeader' are the superset of elements required for both request/response and notification messaging styles.

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

<xsd:complexType name = "Message" abstract = "true">
  <xsd:complexContent>
    <xsd:extension base = "Document">
      <xsd:sequence>
        <xsd:element name = "header" type = "MessageHeader"/>
      </xsd:sequence>
    </xsd:extension>
  </xsd:complexContent>
</xsd:complexType>

<xsd:complexType name = "MessageHeader">
  <xsd:sequence>
    <xsd:element ref = "conversationId" minOccurs = "0"/>
    <xsd:element ref = "messageId"/>
    <xsd:element ref = "inReplyTo" minOccurs = "0"/>
    <xsd:element ref = "sentBy"/>
    <xsd:element ref = "sendTo" minOccurs = "0" maxOccurs = "unbounded"/>
    <xsd:element ref = "copyTo" minOccurs = "0" maxOccurs = "unbounded"/>
    <xsd:element ref = "creationTimestamp"/>
    <xsd:element ref = "expiryTimestamp" minOccurs = "0"/>
    <xsd:element ref = "dsig:Signature" minOccurs = "0" maxOccurs = "unbounded"/>
  </xsd:sequence>
</xsd:complexType>
			

Not all of the elements of 'MessageHeader' are relevant to all messaging styles and its content is restricted by subsequent definitions, 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 party sending a message.
• sendTo identifies the parties who will receive a message and should act upon it.
• copyTo identities other 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.

2.2.2 Requests, Responses and Notifications

The schema derives three abstract message style types from the core messaging classes by restriction. For example a request message may not have an inReplyTo element where as it is made mandatory in a response.

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.



In each case inheritance is used to restrict the content model of the base 'Message' type and change the type of the 'header' element. Each of these types is in turn a restriction of the generic 'MessageHeader' type with some elements excluded or made mandatory.

<xsd:complexType name = "RequestMessage" abstract = "true">
  <xsd:complexContent>
    <xsd:restriction base = "Message">
      <xsd:sequence>
        <xsd:element name = "header" type = "RequestMessageHeader"/>
      </xsd:sequence>
      <xsd:attributeGroup ref = "StandardAttributes"/>
    </xsd:restriction>
  </xsd:complexContent>
</xsd:complexType>

<xsd:complexType name = "RequestMessageHeader">
  <xsd:complexContent>
    <xsd:restriction base = "MessageHeader">
      <xsd:sequence>
        <xsd:element ref = "conversationId" minOccurs = "0"/>
        <xsd:element ref = "messageId"/>
        <xsd:element ref = "sentBy"/>
        <xsd:element ref = "sendTo" minOccurs = "0" maxOccurs = "unbounded"/>
        <xsd:element ref = "copyTo" minOccurs = "0" maxOccurs = "unbounded"/>
        <xsd:element ref = "creationTimestamp"/>
        <xsd:element ref = "expiryTimestamp" minOccurs = "0"/>
        <xsd:element ref = "dsig:Signature" minOccurs = "0" maxOccurs = "unbounded"/>
      </xsd:sequence>
    </xsd:restriction>
  </xsd:complexContent>
</xsd:complexType>

<xsd:complexType name = "ReponseMessage">
  <xsd:complexContent>
    <xsd:restriction base = "Message">
      <xsd:sequence>
        <xsd:element name = "header" type = "ResponseMessageHeader"/>
      </xsd:sequence>
      <xsd:attributeGroup ref = "StandardAttributes"/>
    </xsd:restriction>
  </xsd:complexContent>
</xsd:complexType>

<xsd:complexType name = "ResponseMessageHeader">
  <xsd:complexContent>
    <xsd:restriction base = "MessageHeader">
      <xsd:sequence>
        <xsd:element ref = "conversationId" minOccurs = "0"/>
        <xsd:element ref = "messageId"/>
        <xsd:element ref = "inReplyTo"/>
        <xsd:element ref = "sentBy"/>
        <xsd:element ref = "sendTo" minOccurs = "0" maxOccurs = "unbounded"/>
        <xsd:element ref = "copyTo" minOccurs = "0" maxOccurs = "unbounded"/>
        <xsd:element ref = "creationTimestamp"/>
        <xsd:element ref = "expiryTimestamp" minOccurs = "0"/>
        <xsd:element ref = "dsig:Signature" minOccurs = "0" maxOccurs = "unbounded"/>
      </xsd:sequence>
    </xsd:restriction>
  </xsd:complexContent>
</xsd:complexType>

<xsd:complexType name = "NotificationMessage">
  <xsd:complexContent>
    <xsd:restriction base = "Message">
      <xsd:sequence>
        <xsd:element name = "header" type = "NotificationMessageHeader"/>
      </xsd:sequence>
      <xsd:attributeGroup ref = "StandardAttributes"/>
    </xsd:restriction>
  </xsd:complexContent>
</xsd:complexType>

<xsd:complexType name = "NotificationMessageHeader">
  <xsd:complexContent>
    <xsd:restriction base = "MessageHeader">
      <xsd:sequence>
        <xsd:element name = "messageId"/>
        <xsd:element name = "sentBy"/>
        <xsd:element name = "sendTo" minOccurs = "0" maxOccurs = "unbounded"/>
        <xsd:element name = "copyTo" minOccurs = "0" maxOccurs = "unbounded"/>
        <xsd:element name = "creationTimestamp"/>
        <xsd:element name = "expiryTimestamp" minOccurs = "0"/>
        <xsd:element ref = "dsig:Signature" minOccurs = "0" maxOccurs = "unbounded"/>
      </xsd:sequence>
    </xsd:restriction>
  </xsd:complexContent>
</xsd:complexType>
			

2.3 The Message Protocols

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.

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

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



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.



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

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

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

  

  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.

  

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

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

2.3.2.3 Error Handling

This document assumes throughout that the delivery of a message is guaranteed by the transport used to send it. If some communication error occurs that prevents delivery or causes the temporary loss of messages we shall assume that it is the transports responsibility to re-establish connection at a later time and resume communication from the point of failure.

If the 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 must allow for the inclusion of a computer readable error code (taken from a standard list) as well as some location information for the source of the error (e.g. a XPath expression) and a copy of the failed message. The following diagram shows a possible message design for this.



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.

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

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



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.



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:

  

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

  

  The 'TradeAlreadyMatched' message has the following content model:

  

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



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



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.

  

  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.

  

  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.

  

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

  

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



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:

  

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

  

  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.

  

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

  

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



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.



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



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



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

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



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.

  

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

  

2.3.2.5.2 Mismatch

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



2.3.2.5.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' messags is generated.

  

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

  

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

  

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

  

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

  

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

  

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

  

2.3.2.5.5 Alleged

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



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



2.3.3 B2B General Processes

2.3.3.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 INTEREST RATE DERIVATIVE PRODUCT ARCHITECTURE

3.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 favour 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 s