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

1.9 TOOLS AND VALIDATION

2 FpML OVERVIEW

2.1 FpML

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

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

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

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

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

The following features are the SAME across all views:

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

The following features are DIFFERENT in different views:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

An FpML document can be either of two categories:

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

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

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

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.

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

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

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

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

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

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

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

2.8 Main Components

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

2.8.1 The DataDocument type

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

It contains:

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

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

2.8.2 The Trade Component

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

2.8.2.1 tradeHeader

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

2.8.2.1.1 Primary Trade Identifier

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

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

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

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

2.8.2.1.2 Party Trade Information

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

2.8.2.2 product

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

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

2.8.2.2.1 Product Identification

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

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

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

2.8.2.3 otherPartyPayment

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

2.8.2.4 brokerPartyReference

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

2.8.2.5 calculationAgent

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

2.8.2.6 documentation

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

2.8.2.6.1 contractualMatrix

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

Specifically it is designed to:

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

2.8.2.6.1.1 Examples of using the contractualMatrix structure

For Interest Rate Derivatives:

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

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

For Credit Derivatives:

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

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

2.8.2.6.2 Attachment

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

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

2.8.2.7 collateral

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

2.8.2.7.1 independentAmount

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

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

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

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

2.8.2.8 governingLaw

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

2.8.3 The Portfolio Component

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

2.8.4 The Party Component

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

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

This is a description of the elements:

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

Example:

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

2.8.5 The Account Component

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

This is a description of the elements:

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

Example:

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

2.8.6 The Product Component

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

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

2.8.7 The Strategy Component

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

2.9 More Background on FpML's Design

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

2.9.1 Rationale for Structured Approach

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

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

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

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

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

2.9.2 Component Framework

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

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

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

2.9.3 Coding Schemes

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

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

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

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

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

3 BUSINESS PROCESS ARCHITECTURE

3.1 Introduction

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

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

3.1.1 Why Business Messaging?

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

• Representation

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

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

• Semantics

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

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

• Business Process

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

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

• Transport

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

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

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

3.2 The Messaging Framework

3.2.1 Introduction

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

This new framework does the following:

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

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

The following section describes the new messaging framework.

3.2.2 Issues in FpML 4 Messaging Framework

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

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

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

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

3.2.3 Design Assumptions

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

3.2.3.1 Highly Assured Transport

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

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

3.2.3.2 No Preservation of Message Sequence

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

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

3.2.3.3 Long-Running Processes

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

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

3.2.3.4 Observable Completion

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

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

3.2.3.5 Consistent Message Correlation

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

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

3.2.3.6 Consistent Error Reporting

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

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

3.2.3.7 Consistent correction and retraction mechanism

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

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

3.2.3.8 Consistent Processes Across Trades and Post-trade Events

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

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

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

3.2.3.9 Transport Characteristics

3.2.3.9.1 Purpose

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

3.2.3.9.2 Layers

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

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

3.2.3.9.3 Reliable Mode

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

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

3.2.3.9.4 Bulk Transfer Mode

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

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

3.2.4 Transport Independence

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

From the top down, the four layers are:

3.2.4.1 Business Process

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

The FpML Specification models business processes in UML sequence diagrams.

3.2.4.2 Document

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

3.2.4.3 Messaging

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

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

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

3.2.4.4 Transport

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

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

3.2.5 Identification of Purpose

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

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

3.2.5.1 By Namespace (not used by FpML)

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

<?xml version="1.0"?>

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

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

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

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

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

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

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

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

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

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

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

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

3.2.6 General Pattern of Messages

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

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

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

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

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

• possibly, process-specific response messages

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

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

• requestConsent – initiating request

• consentAcknowledgement - acknowledgement

• consentException - exception

• requestConsentRetracted – retraction of the request

• consentGranted - response

• consentRefused – response

3.2.7 Naming Conventions

Messages follow this naming convention:

• requestXxx

• xxxAcknowledgement

• xxxException

• requestXxxRetracted

• xxx[Status] or xxx[Response]

3.2.8 Acknowledgements

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

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

3.2.9 Message correlation

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

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

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

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

• Every message will have a unique message identifier.

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

• The conversationId has been removed.

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

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

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

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

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

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

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

3.2.10 Message sequencing

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

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

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

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

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

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

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

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

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

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

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

3.2.11 Correlation ID optionality

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

3.2.12 Other topics

3.2.12.1 onBehalfOf

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

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

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

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

3.2.12.2 party roles

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

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

3.2.12.3 separation of party and account

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

3.3 Business Processes

3.3.1 FpML 5 Business Processes

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

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

3.3.2 Transaction life cycle

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

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

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

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

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

3.3.3 Overall Messaging Flows

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

3.3.4 Generic (Multi-Event) Flows

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

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

Additional events have been added since version 5.5.

• basketChange
• corporateAction
• indexChange

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

3.3.4.1 FpML Payload in FIX RFQ Messages

The FpML-FIX Collaboration Working Group has developed a framework to use the FpML product definitions together with FIX. The products scope covers:

• Interest Rate Swaps
• Credit Default Swaps

The approach consists on using the FpML product representation together with the FIX Security Definition messages. Even though OTC derivatives are not securities, once the product representation has been exchanged between the parites, FIX messages are used to assign it an identifier. The identifier is then used through the entire RFQ and Execution processes withouth the need to exchange the product details anymore.

The FpML product representation used in pre-trade is consistent with the existing representation in other views such as confirmation. The pre-trade product representation is a subset of the legal confirmation representation. Since the FpML is encapsulated within the FIX Security Definitions messages, information regarding quantity/amount and price is defined within the FIX messages so this information is not included in the FpML representation.

Documentation and examples have been developed to illustrate the approach. They are available at:

• Integration of FpML IRS Payload with FIX.pdf
• Integration of FpML CDS Payload with FIX.pdf

FpML pre-trade examples are available in the Schema and Examples .zip available in this specification.

3.3.4.2 Quotation

3.3.4.2.1 Request Quote

The 4.x design of the RFQ processes was intended to cover both bilateral and exchange based quotation. The design splits the responsibility for providing quotes (the ‘Market Maker’) from that of distributing them (the ‘Quotation System’). This is an over complication as FpML cannot and should not define how the quotes derived. The new “RequestQuote” type only describes the communication between the requester and provider.

The process of creating a quotation may take time depending on the method (single calculator, exchange model, etc.) The quotation acknowledgement response should establish a unique quotation identifier.

3.3.4.2.2 Request Quote Correction

Request quote message can be corrected by requester, sending a corrected request for quote message with "isCorrection" element set to "true", and a unique quotation identifier and a sequence number to link a prior message.

3.3.4.2.3 Quotation Update

(Andrew’s paper suggests that an established unique quotation identifier is used to correlate a subsequent quotation notification with the request, but the quotation response message is not correctable. How then the corrections/updates work?)

The current model allows quote provider to update his quote, for example if there is a large market movement. The update should be correlated to the original quote by means original quotation reference

3.3.4.2.4 Request Quote Retraction

The request for quote can be retracted by the requester at anytime.

3.3.4.3 Ordering

3.3.4.3.1 Order Placement

In the 4.x models, order placement is called 'AcceptQuote' and assumes that order placement is always preceded by a quotation process. In 5.0 model, "PlaceOrder" makes it possible to initiate an order directly without a prior quote and an optional quote reference should be provided to correlate the processes if required.

3.3.4.3.2 Order Placement Update

The Place Order type allows an order requester to correct or update already placed order. The update should be correlated to the original quote by means original quotation reference (a unique quotation identifier and a sequence number to link a prior message) with "isCorrection" element set to "true".

3.3.4.3.3 Order Placement Retraction

The placed order can be retracted using Place Order Retracted type and correlated it to the order that is getting retracted.

3.3.5 Credit Limit Check Messages

A joint ISDA - FIA working group developed business and technical requirements to support Pre-Execution Clearing Certainty workflows. An FpML subgroup translated the requirements into a new set of messages included in this draft for industry review. The messages are available in the new pretrade view and include:

• Request Credit Limit Check - request message
• Limit Check Approved - response/acknowledgement message (full approval, partial approval are supported)
• Limit Check Refused - response/acknowledgement message
• Credit Limit Report (Fuel gauge)
• Set Credit Limit
• Credit Limit Response
• Suspend Credit (Kill Switch) - A kill is the cancelling of all open orders for a given party globally. It also entails cutting off the target party from placing any new orders from the time the kill is processed.
• Credit Limit Response (Limit Suspended)
• Restore Credit (Unkill) "Un-kill" or "Reinstate" message developed that would let SEFs know when a credit provider is happy for a killed party to begin trading again.
• Credit Limit Exception
• Order Status Notification
• Service Notification (heartbeat: loggin-on/logging-off) - Existing FpML message that allows a service to send a notification message to a user of the service.
  What is a heartbeat?
  • The heartbeat represents to your message counterparty that your application is connected and able to process a kill switch if one is sent – it must be implemented in the application layer rather than the messaging layer. (Note: the application layer sits on top of the messaging layer, so any messaging outage will mean that the application layer is also out. This means that the heartbeat could fail due to a networking issue but that it must be implemented to take the application layer into account as well.)
  \
  • Must be a two-way round-trip message i.e. a two-way handshake
  • Must be configurable between sender and recipient. e.g., Ability to agree that a system will be down for a planned outage. Number of heartbeats to be missed in order to constitute a failure (see next section below)

Some of the messages (i.e., request limit check, order status notification) may carry a product payload. Note that certain product fields are being considered for the next draft of version 5.5.

Glossary:

• Credit Limit or "Limit" - A maximum value, which could be of various types (e.g. initial margin, dv01/cs01, notional, etc.), that an entity is willing to provide to another party with whom they have a contractual relationship for the purposes of clearing.
• Credit Model or "Model" - The method jointly employed by the Credit Extender and Limit Checker for a given Credit User through which the credit value of a trade is verified to be within the credit limit prior to the placement of an order and the execution of a trade. The FIA/ISDA group has currently defined 3 Pre-Execution models (Push, Ping, Plus One)
• Credit Extender - An entity that provides credit to another party with whom they have a contractual relationship for the purposes of facilitating clearing of that party’s trades. Examples include: FCMs who provide credit to end users, or CCPs who provide credit to FCMs.
• Credit User - An entity that receives credit from a credit extender and leverages that credit to clear trades intraday.
  • Asset Manager with a limit at an FCM
  • FCMs with limits at a CCP
• Limit Checker - An entity that employs a systematic method in order to determine whether the credit value of a swap executed by a credit user is within the acceptable maximum credit value provided by a credit extender.
  • FCMs checking their client’s limit utilization
  • CCPs checking their Clearing Member’s limit utilization
  • CCPs checking an FCM’s client’s limit utilization on the FCM’s behalf
  • Credit Hub check an FCM’s client’s limit utilization on the FCM’s behalf
  • etc...
• Velocity - Velocity is the time interval for which the limit applies. For instance one may set a limit which says $100M per 10 minutes. The velocity of the $100MM is 10 minutes.
• Clip Size - The clip size is the amount (or clip) threshold under the velocity limit. So using the prior example the clip size is $100M the velocity of the clip is 10 Minutes.

3.3.6 Service Notification

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

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

4 VALIDATION ARCHITECTURE

4.1 Validation Rules

The rules are currently in the process of being reviewed and will be added with in the next 5.5 publication.

4.2 Reference Implementations

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

4.2.1 Java and C#

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

4.2.2 Java/XPath

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

4.2.3 CLiX

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

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

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

4.3 Test Cases

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

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

4.4 Target Audience

This document should be useful to:

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

4.5 Background

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

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

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

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

<calculationPeriodDates>

  <effectiveDate>

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

    ..

  </effectiveDate>

  <terminationDate>

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

    ..

  </terminationDate>

  ..

</calculationPeriodDates>

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

<calculationPeriodDates>

  <effectiveDate>

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

    ..

  </effectiveDate>

  <terminationDate>

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

    ..

  </terminationDate>

  ..

</calculationPeriodDates>

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

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

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

4.6 Rule Specifications

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

4.6.1 General Principles and Guidelines

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

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

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

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

4.6.2 Mathematical Notation

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

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

The approved mathematical symbols are:

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

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

4.6.3 Rule Definition and Layout

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

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

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

Rule layout:

An example rule:

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

4.6.4 Defining New Terms as Functions

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

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

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

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

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

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

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

Each function must have a single result type.

There can be any number of parameters to a function.

4.6.4.1 How to use functions?

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

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

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

4.6.5 Formatting

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

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

Formatting is defined in stylesheet rules.css.

4.7 Technical Guidelines

4.7.1 Implementations

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

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

4.7.2 Evaluation of Dates

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

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

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

4.7.3 Contains

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

4.8 Revision and Publication Process

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

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

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

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

4.9 Normativity and its Implications

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

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

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

5 CROSS-ASSET PRODUCT ARCHITECTURE

The CROSS-ASSET PRODUCTS are out of the scope of the Pretrade view at this stage. For more information, please see the FpML Roadmap.

6 INTEREST RATE DERIVATIVE PRODUCT ARCHITECTURE

6.1 Interest Rate Swap

A swap component contains one or more instances of the swapStream component, zero or more instances of the additionalPayment component together with an optional cancelableProvision component,an optional extendibleProvision component and an optional earlyTerminationProvision component. A swapStream contains the elements required to define an individual swap leg.

Within an FpML swap there is no concept of a swap header. Details of payment flows are defined within swapStreams which each contain their own independent parameters. There can also be additionalPayment elements that contain fees. The additionalPayment component is identical to the otherPartyPayment component shown above.

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

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

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

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

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

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

• floatingRateIndex
• indexTenor.

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

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

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

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

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

In general, an interest rate swap will be a swap with a fixed leg and a floating leg, two floating legs, or two fixed legs. However, certain types of trades may contain more than two legs. FpML does not restrict the number of legs that may be defined. From a modeling perspective, FpML does not distinguish between a swap leg referencing a fixed rate and a swap leg referencing a floating rate, the difference being indicated by the existence, for example, of the resetDates component in a floating rate leg.

The structure of a swapStream is shown diagrammatically below:

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

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

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

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

The information relating to amounts and rates is collected in the calculationPeriodAmount and stubCalculationPeriodAmount components. fxLinkedNotionalSchedule is an alternative to notionalSchedule for defining notionals. This allows for the definition of FX Resetable trades by allowing for the notional of a stream to be linked to notionals from another stream by way of the spot fx rate.

Certain swapStream components are designated as being optional (although it would be more accurate to say that they are conditional). Thus a fixed rate stream never includes a resetDates component, but this is required for a floating rate stream. Similarly, the stubCalculationPeriodAmount component will be required if the swap leg has either an initial or final stub, or indeed both, but should otherwise not be specified. The principalExchanges component is required in the case of cross currency swaps or other types of swap involving exchanges of principal amounts.

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

The detailed structures within the swapStream are shown diagrammatically below:

6.1.1 Relative Swap

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

• Pricing requests
• Curve definitions

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

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

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

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

6.1.2 Non-Deliverable Settlement Provision

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

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

The InterestRateStream type contains an optional settlementProvision component.

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

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

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

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

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

The regular payments of the swap get assigned an Id:

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

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

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

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

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

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

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

6.2 Asset Swap

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

6.2.1 Implementation

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

6.2.2 Design Rationale

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

6.3 Inflation Swap

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

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

6.3.1 Design Approach

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

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

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

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

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

6.3.2 Implementation

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

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

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

6.3.2.1 Inflation Terms

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

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

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

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

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

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

6.4 Forward Rate Agreement

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

The structure of the fra component is shown diagrammatically below:

6.5 Option Components

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

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

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

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

6.5.1 European Exercise

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

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

6.5.2 American Exercise

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

6.5.3 Bermuda Exercise

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

6.5.4 Early Termination Provision

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

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

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

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

6.5.5 Cancelable Provision

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

6.5.6 Extendible Provision

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

6.5.7 Swaption

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

6.5.8 Cap / Floor

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

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

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

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

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

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

6.6 Cash Settlement

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

7 CREDIT DERIVATIVE PRODUCT ARCHITECTURE

7.1 Introduction

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

7.1.1 credit default swap

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

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

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

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

7.1.2 credit default swap index

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

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

7.1.3 credit default swap basket

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

7.1.4 mortgage credit default swap

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

7.1.4.1 Main differences between Mortgage and Corporate CDS

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

7.1.4.2 The Pay-As-You-Go model

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

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

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

7.1.5 loan credit default swap

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

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

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

7.1.6 credit default swap option

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

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

7.2 creditDefaultSwap

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

Figure 1: creditDefaultSwap element

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

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

2003 Confirmation	FpML creditDefaultSwap Element
General Terms	generalTerms
Fixed Rate Payments	feeLeg
Floating Payment	protectionTerms
Settlement Terms	physicalSettlementTerms or cashSettlementTerms
Notice and Account Details	N/A
Offices	N/A

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

Additional points to note:

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

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

7.3 generalTerms

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

Figure 3: generalTerms Element

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

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

The sellerPartyReference element represents the protection seller. This party is referred to as the Floating Rate Payer in the 2003 Definitions. Similarly, the buyerPartyReference element represents the protection buyer and is referred to as the Fixed Rate Payer in the 2003 Definitions. These elements reference the party elements underneath the FpML root element.

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

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

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

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

7.3.1 referenceObligation

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

7.3.1.1 bond and convertibleBond

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

7.3.1.2 mortgage

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

The extensions specific to the mortgage structure are the following:

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

7.3.1.3 loan

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

The extensions specific to the loan structure are the following:

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

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

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

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

7.3.2 referenceInformation

Figure 4: referenceInformation element

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

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

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

Example 1 - Reference Entity only:

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

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

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

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

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

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

7.3.3 indexReferenceInformation

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

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

Figure 5: indexReferenceInformation element

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

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

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

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

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

Some illustrative example FpML snippets including the optional elements follow:

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


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

7.3.3.1 Index Tranche

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

7.3.3.2 Settled Entity Matrix

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

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

7.3.4 basketReferenceInformation

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

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

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

7.3.4.1 Basket Tranche and Nth to Default

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

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

Some illustrative example FpML snippets follow:

<generalTerms>
  ...
  <basketReferenceInformation>
   <referencePool>
     <referencePoolItem>
	<referencePair>
		<referenceEntity id="agriumEntity">
			<entityName>Agrium Inc.</entityName>
			<entityId entityIdScheme="http://www.fpml.org/spec/2003/entity-id-RED-1-0">
008HA7</entityId>
		</referenceEntity>
		<referenceObligation>
			<bond>
				<instrumentId instrumentIdScheme="http://www.fpml.org/spec/2002/
instrument-id-CUSIP-1-0">008916AB4</instrumentId>
				<couponRate>0.077</couponRate>
				<maturity>2017-02-01</maturity>
			</bond>
			<primaryObligorReference href="agriumEntity"/>
		</referenceObligation>
		<entityType>NorthAmericanInvestmentGrade</entityType>
	</referencePair>
   </referencePoolItem>
   <referencePoolItem>
	<referencePair>
		<referenceEntity id="tenetEntity">
			<entityName>Tenet Healthcare Corporation</entityName>
			<entityId entityIdScheme="http://www.fpml.org/spec/2003/entity-id-RED-1-0">
8G836J</entityId>
		</referenceEntity>
		<referenceObligation>
			<bond>
				<instrumentId instrumentIdScheme="http://www.fpml.org/spec/2002/
instrument-id-CUSIP-1-0">88033GAT7</instrumentId>
				<couponRate>0.06</couponRate>
				<maturity>2011-12-01</maturity>
			</bond>
			<primaryObligorReference href="tenetEntity"/>
		</referenceObligation>
		<entityType>NorthAmericanInvestmentGrade</entityType>
	</referencePair>
     </referencePoolItem>
   </referencePool>
   <nthToDefault>1</nthToDefault>
  </basketReferenceInformation>
  ...
</generalTerms>
		

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

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

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

7.4 feeLeg

7.4.1 Credit default swap

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

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

• Fixed Amount, Regular Schedule
• Fixed Rate, Regular Schedule
• Fixed Rate, Month-End Rolls
• Fixed Rate, Initial (Short) Stub
• Fixed Rate, Initial (Long) Stub
• Fixed Rate, Final (Short) Stub
• Fixed Rate, Final (Long) Stub
• Fixed Amount, Single Payment
• Upfront Fee and Fixed Rate, Regular Schedule
• Irregular Payment Schedule

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

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

Figure 7: feeLeg element

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

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

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

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

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

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

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

Here are some example fee schedules:

Example 1 - Fixed Rate - Regular Schedule:

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

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

or in a Transaction Supplement

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

Example 2 - Fixed Amount - Regular Schedule:

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

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

Example 3 - Fixed Rate - Month-End Rolls:

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

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

or in a Transaction Supplement

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

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

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

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

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

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

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

Example 6 - Fixed Amount - Single Payment:

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

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

Example 7 - Upfront Fee combined with Fixed Rate Regular Schedule

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

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

Example 8 - Irregular Payment Schedule

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

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

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

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

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

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

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

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

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

Example 11 - firstPeriodStartDate - Novations Support

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

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

Old Transaction FpML (abbreviated) representation:

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

For the New Transaction the FpML representation would show:

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

New Transaction FpML (abbreviated) representation:

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

Example 12 - Periodic payments - stepping notional

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

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

Example 13 - Irregular Payments, stepping notional

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

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

7.4.2 Credit default swap index

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

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

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

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

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

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

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

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

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

7.4.3 Mortgage derivatives

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

Fixed Amount:

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

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

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

7.5 protectionTerms

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

Figure 8: protectionTerms element

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

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

In the following example, these credit events are applicable:

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

And these conditions to credit event notice settlement apply:

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

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

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

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

The legal restructuring codes are:

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

7.5.1 Mortgage derivatives

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

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

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

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

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

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

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

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

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

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

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

7.6 physicalSettlementTerms and cashSettlementTerms

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

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

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

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

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

Figure 9: physicalSettlementTerms element

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

Figure 10: cashSettlementTerms element

7.7 creditDefaultSwapOption

The creditDefaultSwapOption element defines the CDS option product in FpML.

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

7.7.1 Option Components

7.7.1.1 OptionBase

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

7.7.1.2 OptionBaseExtended

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

7.7.1.2.1 Premium

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

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

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

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

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

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

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

8 FX PRODUCT ARCHITECTURE

The FX PRODUCTS are out of the scope of the Pretrade view at this stage. For more information, please see the FpML Roadmap.

9 EQUITY DERIVATIVE OPTIONS PRODUCT ARCHITECTURE

The EQUITY DERIVATIVE OPTIONS PRODUCTS are out of the scope of the Pretrade view at this stage. For more information, please see the FpML Roadmap.

10 RETURN SWAPS PRODUCT ARCHITECTURE

The RETURN SWAPS PRODUCTS are out of the scope of the Pretrade view at this stage. For more information, please see the FpML Roadmap.

11 VARIANCE PRODUCT ARCHITECTURE

The VARIANCE PRODUCTS are out of the scope of the Pretrade view at this stage. For more information, please see the FpML Roadmap.

12 DIVIDEND PRODUCT ARCHITECTURE

The DIVIDEND PRODUCTS are out of the scope of the Pretrade view at this stage. For more information, please see the FpML Roadmap.

13 CORRELATION PRODUCT ARCHITECTURE

The CORRELATION PRODUCTS are out of the scope of the Pretrade view at this stage. For more information, please see the FpML Roadmap.

14 BOND OPTIONS PRODUCT ARCHITECTURE

The BOND OPTIONS PRODUCTS are out of the scope of the Pretrade view at this stage. For more information, please see the FpML Roadmap.

15 COMMODITY DERIVATIVE PRODUCT ARCHITECTURE

The COMMODITY DERIVATIVE PRODUCTS are out of the scope of the Pretrade view at this stage. For more information, please see the FpML Roadmap.

16 CHANGES IN THIS VERSION

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

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

  View PDF for details on schema changes

  View SCHEME DEFINITIONS for details on coding schemes changes

16.2 Incompatible changes compared to FpML 5.4 - build#5

• CorrelationId:
  • In Confirmation, Reporting, Recordkeeping and Transparency Views - > fpml-msg.xsd - > within "CorrelationId": replaced the base class "xsd:normalizedString" with “Scheme” which restricts the "xsd:normalizedString" to maxLength value="255".
• Commodity Derivatives:
  • Recordkeeping View –> fpml-com-xsd -> within "SettlementPeriods" complex type: the "startDate" element's status changed from "optional" to "mandatory". Rational:Fix - to prevent the submission of the "endDate" without the "startDate". The change was agreed by the Commodity WG and approved by the Standards Committee (March-11-2013)

16.3 Changes compared to FpML 5.4 Recommendation

• Addition of a New Pre-trade View:
  • Business Process:
    • Added a set of Credit Limit Check messages to support Clearing Certainty work flows.
  • Added support for IRS and CDS products in pretrade. Expanded coverage of IRS product scope for pre-trade Credit Limit Check work flows, including Non deliverable settlement, cross currency swaps, asset swaps, averaging, stubs and discounting structures.

17 SCHEMA REFERENCE

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

• Core Definitions:
  • Main Components
  • Doc Components
  • Shared Components
  • Shared Enumeration definitions
  • Asset Components
• Products:
  • IRD
    • Interest Rate Components
  • CD
    • Credit Derivative Components
• Messaging Framework:
  • Messaging Components
  • Business Event Notification Components
  • Credit Limit Check Messaging Components
• Reference:
  • Index and cross-reference of definitions
  • Schema and Example files - Provides zip file with FpML schemas and examples.

18 SCHEMA AND EXAMPLES

• Description of Examples - Provides list and description of available FpML examples. All examples can be downloaded clicking the link below.

• Schema and Example files - Provides zip file with FpML Schema and all examples.

19 SCHEME DEFINITIONS

• Scheme Definitions - Describes standard FpML schemes, and the values that they can take.
• Coding Schemes (.zip file) - Package of internal FpML defined internal schemes defined as xml files.