FpML Financial product Markup Language
Last Call Working Draft 14 Oct 2003
Version:
4.0
This version:
http://www.fpml.org/spec/2003/lcwd-fpml-4-0-2003-10-14
Copyright 1999 - 2003. All rights reserved.
Financial Products Markup Language is subject to the FpML Public License.
A copy of this license is available at http://www.fpml.org/documents/license
The FpML specifications provided are without warranty of any kind, either expressed or implied, including, without limitation, warranties that FpML, or the FpML specifications are free of defects, merchantable, fit for a particular purpose or non-infringing. The entire risk as to the quality and performance of the specifications is with you. Should any of the FpML specifications prove defective in any respect, you assume the cost of any necessary servicing or repair. Under no circumstances and under no legal theory, whether tort (including negligence), contract, or otherwise, shall ISDA, any of its members, or any distributor of documents or software containing any of the FpML specifications, or any supplier of any of such parties, be liable to you or any other person for any indirect, special, incidental, or consequential damages of any character including, without limitation, damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses, even if such party shall have been informed of the possibility of such damages.
This is the FpML 4.0 Last Call Working Draft for review by the public and by FpML members and working groups. It is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to use FpML Working Drafts as reference material or to cite them as other than "work in progress". This is work in progress and does not imply endorsement by ISDA.
The FpML Working Groups encourage reviewing organizations to provide feedback as early as possible. Comments on this document should be sent by filling in the form at the following link: http://www.fpml.org/issues. An archive of the comments is available at http://www.fpml.org/issues/archive.asp
Public discussion of FpML takes place on the FpML Discussion List: discuss@fpml.org which you can join at the following link:
http://www.fpml.org/mailing-lists/join-discuss.asp
There are also asset class-specific mailing lists; you can join them at the following link:
http://www.fpml.org/mailing-lists/join-discuss.asp
A list of current FpML Recommendations and other technical documents can be found at
http://www.fpml.org/spec
While implementation experience reports are welcomed, the FpML Standards Committee will not allow early implementation to constrain its ability to make changes to this specification prior to final release.
This document has been produced as part of the FpML 4.0 activity and is part of the Standards Approval Process.
The FpML documentation is organized into a number of subsections.
This document, "FpML-4-0-intro", provides overviews of the specification.
These are automatically generated reference documents detailing the contents of the various sections in the FpML schema.
- Examples - Provides sample FpML for each section.
- Scheme Definitions - Describes standard FpML schemes, and the values that they can take.
The Financial Products Markup Language (FpML) is a protocol enabling e-commerce activities in the field of financial derivatives. The development of the standard, controlled by ISDA (the International Swaps and Derivatives Association), will ultimately allow the electronic integration of a range of services, from electronic trading and confirmations to portfolio specification for risk analysis. All types of over-the-counter (OTC) derivatives will, over time, be incorporated into the standard. FpML 4.0 covers FX and Interest Rate, Equity, and Credit Derivatives.
FpML is an application of XML, an internet standard language for describing data shared between computer applications.
In WD#2 we changed the schema to make most element definitions local to a global type, rather than global. This was done to minimize cross-asset class name clashes. We received some feedback from implementers that they had been using global elements to define client-specific products, and thus that they did not agree with the change. The FpML Coordination Committee is currently investigating alternatives for achieving the goals of the change while meeting the needs of firms to customize products based on FpML. The FpML Standards Committee invites more comment on this topic.
The FpML Coordination committee has been considering some proposed extensions to the FpML trade header. These proposals include items such as trader and source system identification, status reporting, textual descriptions, etc. Some of these extensions may be incorporated in the FpML 4.0 Trial Recommendation as optional elements. The FpML Standards Committee invites comments on what extensions if any to the trade header should be supported by FpML.
In WD#2 we changed the schema to eliminate scheme default attributes. This was done for several reasons, including schema maintenance and document processing. We received some feedback from implementers that they had were using non-standard scheme defaults for frequently used elements and that this change would result in much larger and more difficult to read instance documents. The FpML Standards Committee invites more comment on this topic, particularly on the specific schemes that result in the greatest increase in document size/complexity. The FpML Coordination Committee is investigating alternatives for addressing this issue; some changes may be incorporated in to the Trial Recommendation or the upcoming Architecture guidelines to address this topic.
Following is a brief list of the changes to be found in this working draft compared to working draft #1.
- Many "schemes" have been replaced by enumerations, in cases where the domain was judged to be relatively stable. In addition, all scheme default attributes have been removed from the FpML root element. Schemes that have been converted to enumerations no longer require a scheme default. Other schemes are now defaulted, where possible, as default attribute values in the schema. This change was made to improve the maintainability and readability of the FpML root element, and to make it clearer when non-default schemes are used.
- Most global element definitions have been turned into local element definitions. This change was made to reduce cross-asset name clashes and improve flexibility going forward. It also had the side benefit of reducing the documentation size by approximately 400-500 pages. This change has significantly changed the schema files, but not changed the instance documents.
- There have been a few small changes to Credit Derivative definitions (e.g. addition of new scheme values) to address the ISDA 2003 credit derivatives supplement.
- Enhancements to IRD cashflows recently incorporated into versions 2.0 and 3.0 have also been included in version 4.0.
- There have been a few changes to message headers and reject messages to address recommendations by the Validation working group.
- Most diagrams have been redone to improve quality.
- Example files have been renamed for clarity and consistency
The following changes have been introduced in FpML 4.0 which are incompatible with FpML 3.0
FpML type definitions are now expressed using XML Schema. This replaces the document type reference (DOCTYPE directive) in each FpML document with new attributes for specifying namespaces and schema locations on the "FpML" root element. In addition the correct document content model must be selected by setting the type of the root element. The main body of the document is unaffected by the transition to XML schema.
With the conversion of many schemes to enumerations, we have chosen to eliminate all scheme defaults from the FpML root element and replace them in some cases with default attribute values in the schema. To convert instance documents from version 3.0, you will need to remove scheme default attributes from the root element. In cases where a scheme has been converted to an enumeration, it will no longer be possible to use a proprietary set of domain values.
dateRelativeTo now uses only the href attribute. This will affect instance documents and processors using this element. This change was made to eliminate redundancy, which will simplify maintenance of the schema, generation of FpML documents, and validation .
Intra-document references (using the "href" attribute) now no longer have a "#" prefix, due to the change to id/idref semantics from the xlink referencing style. This change is also planned to be made to FpML 3.0, but is incompatible with instance documents developed to date. To change instance documents to accommodate the change it will be necessary to remove the "#" prefix from href attribute values.
In FpML 3.0 an entry was added to the trade header to specify a calculation agent. With FpML 4.0 this has been rationalized with an entry in the trade element which specifies the calculation agent(s). Documents using the calculationAgentReference in the tradeHeader will need to be changed to use the calculationAgent element in the "trade" element.
The masterConfirmation element now appears before the contractualDefinitions element in the definition of the Documentation type. Furthermore, in FpML 4.0 the masterConfirmation element is no longer simply a date. In 4.0 it consists of a masterConfirmationType, masterConfirmationDate and an optional masterConfirmationAnnexDate.
All FpML 3.0 documents that contain a masterConfirmation element are incompatible with FpML 4.0. Do the following in order to upgrade your 3.0 documents to 4.0:
- If the document contains both a masterConfirmation and a contractualDefinitions element(s), reverse the order of these elements.
- Move the date value that appears in the masterConfirmation element to the element masterConfirmation.masterConfirmationDate.
- Add the element masterConfirmation.masterConfirmationType with the appropriate value.
Messages constructed using FpML 4.0 should make use of the new message framework to express the reason for the exchange of information, to identify the parties involved in the exchange and to describe the actual information itself.
A number of standard messages have been provided for trade affirmation and confirmation along with error reporting and trade status enquiry. FpML users can derive additional message types from the framework to meet specific messaging requirements currently outside FpML's scope.
To allow backwards compatibility with existing pre-FpML 4.0 documents a 'DataDocument' type has been provided which does not include message elements.
Because we rationalized some FX rate definition structures, there have been small changes (elements renamed or moved) in a few places, including FX linked notionals in IRD, and non-deliverable forwards and options in FX.
Following is a list of changes that are anticipated to be made by the time the document reaches Last Call Working Draft:
- A number of definitions that are used in several places in the document are likely to be moved to the "shared" subschema.
- In a number of places where the localization of global elements has created repeated definitions of the same basic type, we plan to create global types. Examples include intra-document references such as party references, invocations of schemes, etc.
- A number of global types are likely to be renamed to improve clarity of scope/purpose.
- We will attempt to rationalize/consolidate a number of definitions across asset classes.
- There have been several comments proposing localized enhancements, to areas including the tradeHeader and the party element, that are likely to be addressed.
The scope of FpML 4.0 includes all of the FpML 3.0 scope plus significantly broadened Equity Derivative product coverage, new Credit Derivative product coverage, and support for an FpML Messaging framework.
The various Working Groups have developed FpML 4.0 within an architecture framework updated from the FpML Architecture Version 1.0 framework defined by the Architecture Working Group. The original FpML 1.0 Architecture framework recommendations covered:
- XML tools for editing and parsing
- XML namespace usage within FpML
- FpML versioning methodology
- FpML content model - a new style for representing the FpML Document Type Definition (DTD)
- FpML referencing methodology, including guidelines for referencing coding schemes.
The principal changes from the original FpML 1.0 architecture framework include:
- Replacement of XML DTDs (Document Type Definitions) by XML Schemas, as described in a technical note published in 2002 by the FpML Architecture WG.
- Elimination of xlink-style referencing and its replacment with id/idref-style referencing (this change is also being adopted for FpML 3.0).
The Architecture Working Group intends to publish a new architecture framework incorporating the above changes, and some others, including, among other topics:
- Proprietary extensions to FpML
- Enhanced versioning support
- Digital signature support
This updated architecture framework is likely to be published as separate document during the working draft stage of FpML 4.0.
An FpML messaging working group has been formed to define a messaging framework and sample messages for selected business processes. FpML 4.0 Last Call Working Draft includes a preliminary version of this working group's output; it is expected to evolve somewhat in future drafts of FpML 4.0. Business processes currently addressed by this Working Group include:
- Trade Affirmation
- Trade Confirmation
To support these business processes, a number of messages have been defined. Please see the "Message Architecture" section for more informtion.
The Validation Working Group was set up to provide semantic, or business-level
validation rules for FpML 4.0. These validation rules, which are
aimed at normalizing the use of elements within FpML, are issued
separately from the main working draft document at a URL defined in the validation
section of this document.
The validation working group publishes with its releases:
- A set of rules described in English
- Positive and negative test case documents for each rule
- Non-normative reference implementations
The current working draft includes a set of rules for Interest Rate Derivatives. The working
group intends to continue its work to publish rules for shared component definitions,
additional rules for IRD, rules for credit derivatives and thereafter rules for the other
product types. It is expected that some of these rule sets will become available between
the publication of this draft and the Trial Recommendation.
In FpML 4.0 Last Call Working Draft the following FX products are covered:
- FX Spot
- FX Forward (including non-deliverable forwards, or NDFs)
- FX Swap
- FX Options (European and American; barriers, digitals, binaries, average rates; cash and physical settlement)
- Option Strategies (multiple simple options)
In addition, support for the following money market instrument is also provided:
The EQD Products Working Group has extended the FpML 3.0 standard to cover the following Equity Derivative Products:
- Bermudan exercise style
- Basket underlyings
- Forward starts
- Cash or Physical Settlement
- Quantos and Composites
- Averaging
- Barriers, Knock-Ins, Knock-Outs and Binary (Digital) Options
We have included support for various types of Equity Swaps, without any specific limitation. Those identified so far include:
- Single stock swaps as well as basket swaps
- Swaps that have an equity, index or a convertible bond underlyers, or a combination of these
- 2-legged swaps with a combination of an equity leg and a funding leg, as well as swaps that either have only one leg (e.g. fully funded swap) or multiple equity legs
- Swaps that have specific adjustment conditions, such as execution swaps or portfolio rebalancing swaps
- Zero-strike swaps, which do not have an interest rate component but rather involve the exchange of principal cashflows
The FpML representation of the equity swap is focused on representing the economic
description of the swap. The expectation is that the reference terms of the swap will
be defined either through the ISDA definitions or, when exceptions apply, through
master bilateral agreements that will be agreed between the parties to the trade
In order to support the above scope for both Equity Derivative and Equity Swap products we support operational features, such as contact information and governing documentation which are present in current documents defined by ISDA standards
In FpML 4.0 Last Call Working Draft no Energy Derivative products are covered. However, a working group is currently active in this area and is expected to provide support for the following products in the next version of FpML:
- Financial Gas swaps, caps/floors, and swaptions
- Financial Power swaps, caps/floors, and swaptions
- Financial Oil swaps, caps/floors, and swaptions
It is anticipated that support for physically-settled products will be incorporated in future versions of FpML.
Producers of FpML documents intended for interchange with other parties must encode such documents using either UTF-8 or UTF-16. Consumers of FpML documents must be able to process documents encoded using UTF-8, as well as documents encoded using UTF-16. For more information, see
http://www.w3.org/TR/REC-xml#charencoding
Unrestricted FpML elements may use any valid XML characters. For more information, see
http://www.w3.org/TR/REC-xml#charsets
Certain elements and attributes (such as scheme URIs) are defined with more restrictive types, such as xsd:normalizedString, xsd:token, or xsd:anyURI. For these types, please see the relevant data type definition in the XML Schema datatypes specification:
http://www.w3.org/TR/xmlschema-2/
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 lift 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 schemes. The original version of the FpML Architecture is located at http://www.fpml.org/spec/2001/rec-fpml-1-0-2001-05-14/index.asp. The latest version of the FpML architecture principles is described in detail in the FpML Architecture 2.0 document, to be released shortly. 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.
FpML is divided into several schema files, which organize the definitions into samller and more maintainable building blocks. These building blocks incude:
- fpml-main-4-0.xsd - root definitions, plus definitions related to trades.
- fpml-shared-4-0.xsd - shared definitions used widely throughout the specification. These include items such as base types, shared financial structures, etc.
- fpml-enum-4-0.xsd - shared enumeration definitions. These definitions list the values that enumerated types may take.
- fpml-msg-4-0.xsd - definitions related to messaging and workflow.
- fpml-ird-4-0.xsd - Interest rate derivative product definitions.
- fpml-fx-4-0.xsd - Foreign exchange product definitions.
- fpml-cd-4-0.xsd - Credit derivative product definitions.
- fpml-eqd-4-0.xsd - Equity derivative option product definitions.
- fpml-eqs-4-0.xsd - Equity derivative swap product definitions.
This organization may be refined in the future. In particular, it is possible that the trade-related definitions in fpml-main will be moved out to their own subschema in a future version of FpML, and it is likely that fpml-shared will be split into smaller pieces.
Before beginning to use FpML 4.0, 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, you should consider using (and extending) FpML messaging. If the application is primarily a data storage and retrieval application, you should consider using the DataDocument type, and avoiding FpML messaging. 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 consider using the messaging layer. It's worth pointing out that if you base your definitions on the DataDocument type, you can completely ignore FpML messaging, as none of the messaging definitions will be used.
The FpML element forms the root for an FpML instance document. The structure of the FpML document depends on the "xsi:type" attribute. The simplest FpML document is a "DataDocument" (xsi:type='DataDocument'). This is similar to an FpML 3.0 document, and is described in the next section.
The FpML root element contains attributes that specify the FpML version ('4-0' for FpML 4.0), the schema name and location, the name space, and related properties, as well as the xsi:type. See the upcoming Architecure 2.0 specification for more details on this.
The DataDocument type contains three elements, trades, portfolios and parties. Portfolios contain only trade references, if the trades themselves need to be included in the document then the trades can be included within the root element.
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. A DataDocument looks like this:
It contains:
- A trade or trades
- A portfolio or portfolios
- A party or parties
In addition, the FpML root element includes attributes for:
- Specifying the FpML version and related schemas and namespaces.
- Specifying the message type.
Each FpML document contains a message header, which provides a context for the document. The header includes information about the sender and recipient of the message and the purpose of the message. See the section on "Messaging Architecture" for more information.
The trade is the top-level component within the root element FpML. A trade is an agreement between two parties to enter into a financial contract and the trade component in FpML contains the information necessary to execute and confirm that trade.
The information within tradeHeader is common across all types of trade regardless of product. In FpML 4.0 this element contains the trade date and party trade identifiers.
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.
This component contains additional payments such as brokerage paid to third parties which are not part of the economics of a trade itself.
The calculation agent identifies the party or parties responsible for performing calculation duties, such as cash settlement calculations.
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.
The party component holds information about a party in involved any of the trades or portfolios included in the document. The parties involved will be the principals to a trade and potentially additional third parties such as a broker. For this release, this component is restricted to party identification.
It should be noted that an FpML document is not 'written' from the perspective of one particular party, i.e. it is symmetrical with respect to the principal parties. The particular role that a party plays in the trade, e.g. buyer, seller, stream payer/receiver, fee payer/receiver, is modeled via the use of references from the component where the role is identified to the party component.
The product component specifies the financial instrument being traded. This component captures the economic details of the trade. It is modeled as a substitution group; each asset class may create one or more product definitions. Some examples of products that different working groups have defined include:
- Interest rate swaps
- FRAs
- caps/floors
- swaptions
- FX spot/forwards
- FX swaps
- FX options
- Equity options
- Equity swaps
- Credit default swaps
This component defines a special kind of product that allows the structuring of trade by combining any number of products within a strategy. A trade can be of a strategy rather than of a base product; this strategy can then in turn contain other products, such as multiple options. For example, you could define a strategy consisting of an FX call and an FX put to create a straddle or strangle, and then create a trade of that strategy.
The Strategy component makes use of a composition pattern since strategy itself is a product. This means that strategies can themselves contain strategies.
This section provides some additional background on the design of FpML.
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.
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.
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 LCWD the handling of coding schemes has changed from previous versions of FpML, with the introduction of the use of enumerations and the elimination of scheme default attributes from the FpML root element. The following description refers to the updated approach.
One possible means of identifying value domains is to include the domain of permitted values within the schema, using an XML Schema enumeration structure. This mechanism has been adopted in the LCWD for element values that satisfy the following criteria:
- The list of allowable values is relatively short.
- The list of allowable values is not expected to change during the lifetime of the specification
- It's not possible to change the list of allowable values without affecting the meaning of the specification.
This leave a number of lists of values not meeting the above criteria that are represented by "schemes". "Schemes" are lists of values that can be changed dynamically without affecting the schema. They include items such as currency codes, party identifiers, business centers, floating rate indexes, etc. For these data elements, the "scheme" is a URI, as identified in an FpML attribute, that designates the universe of acceptable values the element may take. This scheme definition list is typically encoded as an XML document, but does not in general need to be. In cases where the ISDA wishes to designate a default scheme, this is recorded as a default attribute value in the schema. In other cases, the scheme attribute is required.
For further details on the architectural framework behind Schemes, refer to the FpML Architecture Version 1.0 document.
The FpML 4.0 Schema is the first release of the specification to place a messaging framework around the product descriptions to describe the context and use to which the information is expected to be put. This section describes a small set of complex types and elements that comprise a simple message framework that is used as the basis for defining business messages suitable for use in a 'Business-to-Business' (B2B) or 'Application-to-Application' (A2A) communications process.
These definitions introduce a new set of ideas that previously could not be used in FpML because of its reliance on DTDs as the formal specification of the grammar. The following sections describe the reasoning behind the features used in the framework.
In general computer systems commonly use two styles of messaging to exchange information between each other, namely:
-
Request/Response
A style of exchange in which one system sends a message to the other to asking it to perform some function, the result of which is encapsulated in an appropriate response and returned.
-
Notification
A style of exchange in which a system sends a message describing a business event that has occurred and may be of interest to others.
The receipt of either kind of message may cause additional messages to be generated and sent as part of the processing to obtain information from other systems or to inform them of the business event underway.
The FpML 4.0 schema explicitly models 'delivery' related information as part of the message itself. Some transports (i.e. SOAP, ebXML, etc.) allow such information to be placed in the 'envelope' that surrounds the message during delivery whilst others (e.g. message based middleware, files, etc.) do not.
Including a standard header within FpML messages increases consistency by providing a single format for delivering information regardless of the physical transport, ensures that it will be persisted if the message is archived, and allows more flexible use of features such as digital signatures.
The design of a grammar must strike a balance between the degree of flexibility it allows and the complexity of its validation. An overly lax grammar allows the construction of documents that, whilst syntactically correct, may have no valid business interpretation. On the other hand a very rigid grammar may require many more grammatical productions in order to enumerate only the valid combinations.
In general it makes sense for a grammar to be strict when it can be achieved easily and without too much additional definition, and lax where flexibility is required (e.g. for proprietary extensions, etc.). In the case of the message framework the grammar provides a mechanism for ensuring that messages have the correct content that applies to them.
The receiver of a message needs to be able to determine the function that the message is invoking. In XML there are three different techniques that can be used for indicating the purpose of a message.
The FpML message framework is based on type substitution as it gives the greatest control over validation whilst allowing easy extension of the message elements.
The receiver can look at the namespace from which the element definitions have been drawn and determine from it the function requested.
<?xml version="1.0"?>
<FpML version="4-0"
xmlns="http://www.fpml.org/2002/FpML-4-0-TradeConfirmationRequest">
<header>
... Message header
</header>
... Business data
</FpML>
Using namespaces it would be possible to create a highly extendable framework for FpML but it could lead to documents having to have every FpML element prefixed with a suitable namespace abbreviation although it may be possible to mitigate this by having the 'core' sub-schemas use no namespaces in their definition and take on the namespace of the one they are including into.
There may be further issues with related XML standards such as XPath as the namespace of the same included elements may not be consistent between documents.
The receiver can look at the name associated with an element within the message (either the root or one of the first level children) to determine the function requested.
<?xml version="1.0"?>
<FpML version="4-0" xmlns="http://www.fpml.org/2002/FpML-4-0">
<header>
... Message header
</header>
<tradeConfirmationRequest>
... Business data
</tradeConfirmationRequest>
</FpML>
To ensure that the content of the FpML element is always a valid message element the grammar would have to use either a choice group (which would limit extensibility) or a substitution group (which is extensible) to define the acceptable elements.
Whilst the root element could be used to indicate the function it is more likely that a child would be used so that all FpML documents would still have the FpML element as the root.
In this model the message header must be generic, that is suitable for any kind of message. There is no way in XML to validate that the content is suitable for the type of message content that follows.
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.
The focus of FpML to date has been on the focus description of trades for B2B purposes. At the same time many of the existing implementations have been for internal trade exchanges between systems.
Extending FpML to handle internal trade information entails adding additional elements to the current schema to hold the values needed to categorise a trade for internal purposes. There are several ways this information could be added to the schema (e.g. optional elements, alternative inheritance structures, inheritance by restriction) each with its own properties in terms of ease of validation or affects on document style.
In this document optional elements have been used to illustrate the changes but such definitions could be used in external messages and would pass basic XML schema validation. Their use could only be prevented through the use of additional validation rules applied post XML parsing.
The representation of a trade within a trading system may change many times during its lifetime as business processes, both internal (e.g. trade creation, amendment, authorisation, etc.) and external (e.g. matching, confirmation, settlement, exercise, etc.), are applied to it.
Systems that maintain local copies of trade descriptions need to be able to determine the state of a trade contained within a message with respect to their own copy. The trade identifier by itself is not enough to determine if one trade description is more recent than another. Some other piece of data that changes in a consistent manner is needed to determine the ordering between the two descriptions, such as either a timestamp or an incrementing version number.
To add a version number to FpML the 'TradeIdentifier' type could be extended as shown below.
The 'tradeVersion' value could be defined as either a simple incrementing integer value or as a more structured string value (e.g. 1.0, 2.4.2, etc.).
The current FpML 'TradeHeader' type records the minimum content required for trade identification. Normally an internal trade is stored along with more information used for internal accounting and reporting purposes.
The following diagram shows an enhanced 'TradeHeader' structure that can contain information describing the origination of the trade, the individuals responsible for its creation and the internal 'account'.
Combining these two changes would allow the creation of FpML documents with the following structure:
<FpML>
...
<trade>
<tradeHeader>
<partyTradeIdentifier>
<partyReference href="UBSW"/>
<tradeId>1234</tradeId>
<tradeVersion>1</tradeVersion>
<tradingSystem>London/FX/WallSt</tradingSystem>
<trader>Andrew Jacobs</trader>
<salesPerson>Karel Engelen</salesPerson>
<tradeAccount>LON/FX/PROP. TRADING</tradeAccount>
</partyTradeIdentifier
<tradeDate>2003-04-17</tradeDate>
</tradeHeader>
<tradeHeader>
<fxLeg>
...
</fxLeg>
...
</FpML>
Versions of FpML prior to 4.0 have allowed the construction of documents which contain only product definitions. The original proposal for FpML 4.0 was to force a transistion directly to messages by making some message elements mandatory in every document. However after further consideration it was decided to restructure the framework to allow both styles of definition giving FpML backwards compatibility with exisiting solutions and the scope to expand into new B2B (or A2A) messaging applications.
The XML schema for FpML 4.0 defines the type of the root FpML element to be 'Document', an abstract type with an empty content model save only for the standard FpML version.
The Document type serves as the base type in an inheritance scheme that provides the content model definitions for actual message types.
The DataDocument type provides the same content model as the pre XML schema version of FpML allowing the construction of documents that contain only product definitions.
To make an FpML 3.0 DTD based document compatible with the FpML 4.0 schema as a DataDocument a number of changes are required to the instance document, namely:
- The <!DOCTYPE> reference must be removed from the document.
- Where the <FpML> element defines a non-standard or institution specifi default scheme attribute value it must be proprogated the scheme attribute on all the appropriate elements.
- A reference to the FpML schema as the default namespace must be added.
- A reference to the W3C XML schema instance schema must be added and assigned to a namespace (e.g. 'xs' or 'xsi').
- A reference to the W3C XML Digital Signature schema must be added and assigned to a namespace (e.g. 'dsig').
- The type of the <FpML> element must be set to 'DataDocument'.
- A schemaLocation attribute may be added to the <FpML> element to hint at the location of the schema for XML tools that do not perform full 'entity resolving'.
The two core definitions within the schema establish two abstract base classes, 'Message' and 'MessageHeader' from which all the other definitions are derived.
The 'Message' type contains a single element 'header' that holds the message identification and delivery data defined by the 'MessageHeader' type. The Message type inherits the set of attributes used to identify the FpML coding schemes by extending the Document type. The elements that comprise a 'MessageHeader' are the superset of elements required for both request/response and notification messaging styles.
The following XML schema fragment shows how these types are defined.
<xsd:complexType name = "Message" abstract = "true">
<xsd:complexContent>
<xsd:extension base = "Document">
<xsd:sequence>
<xsd:element name = "header" type = "MessageHeader"/>
<xsd:group ref = "Validation.model"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name = "MessageHeader">
<xsd:sequence>
<xsd:element name = "conversationId" type = "ConversationId" minOccurs = "0"/>
<xsd:element name = "messageId" type = "MessageId"/>
<xsd:element name = "inReplyTo" type = "MessageId" minOccurs = "0"/>
<xsd:element name = "sentBy" type = "PartyId"/>
<xsd:element name = "sendTo" type = "PartyId" minOccurs = "0" maxOccurs = "unbounded"/>
<xsd:element name = "copyTo" type = "PartyId" minOccurs = "0" maxOccurs = "unbounded"/>
<xsd:element name = "creationTimestamp" type = "xsd:dateTime"/>
<xsd:element name = "expiryTimestamp" type = "xsd:dateTime" minOccurs = "0"/>
<xsd:element ref = "dsig:Signature" minOccurs = "0" maxOccurs = "unbounded"/>
</xsd:sequence>
</xsd:complexType>
Not all of the elements of 'MessageHeader' are relevant to all messaging styles and its content is restricted by subsequent definitions, The role of each element is given below.
- conversationId allows a message sender to create a common context for a number of separate message exchanges.
- messageId contains the senders unique identifier for a message.
- inReplyTo contains the unique identifier for the request message that is being responded to.
- sentBy identifies the party sending a message.
- sendTo identifies the parties who will receive a message and should act upon it.
- copyTo identities other parties who will receive a message but who do not have to act upon it.
- creationTimestamp describes the time when the sender created the message.
- expiryTimestamp defines a time after which the sender will consider the message expired.
- dsig:Signature allows the inclusion of W3C digital signatures within the message.
The validation element in the Message type contains the URI for a set of additional validation rules to be applied to the document during processing.
The schema derives three abstract message style types from the core messaging classes by restriction. For example a request message may not have an inReplyTo element where as it is made mandatory in a response.
The following image shows the construction of just one message style type, as with in the exception of the type of the header element, they are all the same.
In each case inheritance is used to restrict the content model of the base 'Message' type and change the type of the 'header' element. Each of these types is in turn a restriction of the generic 'MessageHeader' type with some elements either excluded or made mandatory.
<xsd:complexType name = "RequestMessage" abstract = "true">
<xsd:complexContent>
<xsd:restriction base = "Message">
<xsd:sequence>
<xsd:element name = "header" type = "RequestMessageHeader"/>
<xsd:group ref = "Validation.model"/>
</xsd:sequence>
<xsd:attributeGroup ref = "StandardAttributes.atts"/>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name = "RequestMessageHeader">
<xsd:complexContent>
<xsd:restriction base = "MessageHeader">
<xsd:sequence>
<xsd:element name = "conversationId" type = "ConversationId" minOccurs = "0"/>
<xsd:element name = "messageId" type = "MessageId"/>
<xsd:element name = "sentBy" type = "PartyId"/>
<xsd:element name = "sendTo" type = "PartyId" minOccurs = "0" maxOccurs = "unbounded"/>
<xsd:element name = "copyTo" type = "PartyId" minOccurs = "0" maxOccurs = "unbounded"/>
<xsd:element name = "creationTimestamp" type = "dateTime"/>
<xsd:element name = "expiryTimestamp" type = "dateTime" minOccurs = "0"/>
<xsd:element ref = "dsig:Signature" minOccurs = "0" maxOccurs = "unbounded"/>
</xsd:sequence>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name = "ResponseMessage">
<xsd:complexContent>
<xsd:restriction base = "Message">
<xsd:sequence>
<xsd:element name = "header" type = "ResponseMessageHeader"/>
<xsd:group ref = "Validation.model"/>
</xsd:sequence>
<xsd:attributeGroup ref = "StandardAttributes.atts"/>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name = "ResponseMessageHeader">
<xsd:complexContent>
<xsd:restriction base = "MessageHeader">
<xsd:sequence>
<xsd:element name = "conversationId" type = "ConversationId" minOccurs = "0"/>
<xsd:element name = "messageId" type = "MessageId"/>
<xsd:element name = "inReplyTo" type = "MessageId"/>
<xsd:element name = "sentBy" type = "PartyId"/>
<xsd:element name = "sendTo" type = "PartyId" minOccurs = "0" maxOccurs = "unbounded"/>
<xsd:element name = "copyTo" type = "PartyId" minOccurs = "0" maxOccurs = "unbounded"/>
<xsd:element name = "creationTimestamp" type = "dateTime"/>
<xsd:element name = "expiryTimestamp" type = "dateTime" minOccurs = "0"/>
<xsd:element ref = "dsig:Signature" minOccurs = "0" maxOccurs = "unbounded"/>
</xsd:sequence>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name = "NotificationMessage">
<xsd:complexContent>
<xsd:restriction base = "Message">
<xsd:sequence>
<xsd:element name = "header" type = "NotificationMessageHeader"/>
<xsd:group ref = "Validation.model"/>
</xsd:sequence>
<xsd:attributeGroup ref = "StandardAttributes.atts"/>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name = "NotificationMessageHeader">
<xsd:complexContent>
<xsd:restriction base = "MessageHeader">
<xsd:sequence>
<xsd:element name = "messageId" type = "MessageId"/>
<xsd:element name = "sentBy" type = "PartyId"/>
<xsd:element name = "sendTo" type = "PartyId" minOccurs = "0" maxOccurs = "unbounded"/>
<xsd:element name = "copyTo" type = "PartyId" minOccurs = "0" maxOccurs = "unbounded"/>
<xsd:element name = "creationTimestamp" type = "dateTime"/>
<xsd:element name = "expiryTimestamp" type = "dateTime" minOccurs = "0"/>
<xsd:element ref = "dsig:Signature" minOccurs = "0" maxOccurs = "unbounded"/>
</xsd:sequence>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
This document assumes throughout that the delivery of a message is guaranteed by the transport used to send it. If some communication error occurs that prevents delivery or causes the temporary loss of messages we shall assume that it is the transports responsibility to re-establish connection at a later time and resume communication from the point of failure.
If the message cannot be processed for some technical reason such as: it has become corrupted, is not XML or is not a valid FpML message, then the receiver returns a 'MessageRejected' message to the sender. Usually the message will require manual intervention to diagnose and solve any problems. Such rejections will not be show on any of the diagrams in this paper.
If the message cannot be processed because the request is invalid, given the state of the data to which it applies, then an appropriate business level notification is returned to the sender (e.g. 'TradeNotFound', 'TradeAlreadyMatched', etc.) which in turn could be used to invoke either an automatic recovery or a manual intervention.
The design of the rejection message must allow for the inclusion of a computer readable error code (taken from a standard list), location information for the source of the error (e.g. a XPath expression or line/character position) and a copy of the failed message. In addition where the problem was identified by business validation rules it may provide information regarding the rule that was breached and any relevant data. The following diagram shows the proposed message design for this.
In order to encapsulate one XML message within another the addition data section would have to use an XML CDATA encoding to prevent the parser from attempting to process the contents.
Message rejections may use any of the following list of error codes to indicate the reason for failure. Institutions may define thier own additional error codes in the numeric range provided for user errors.
- Level 100: Message transport and delivery problems
- 100: Default transport error code
- 101: transport unavailable
- 102: unknown recipient/destination
- 103: delivered to wrong recipient
- 104: timeout - message delivered past expiration
- 105: this type of message not accepted on this transport
- 106: message generation problem (e.g. data conversion)
- 110: Message corrupted (e.g. CRC failure)
- 111: Message text doesn't match digital signature hash
- Level 200: Message Integrity and Processing problems
- 200: Default message processing error code
- 201: Lexical problem - not well-formed XML
- 202: Unsupported character set
- 203: Empty or missing content
- 204: Content too large
- 210: System unavailable
- 211: Message component text doesn't match digital signature hash
- Level 300: Message Validation Problems
- 300: Default validation error code
- 301: Unknown or unsupported DTD/Schema
- 302: Unsupported FpML version
- 303: Invalid FpML message - message doesn't validate w.r.t. specified DTD/schema
- 304: Validation failure - unsupported message type
- 305: Validation failure - mandatory FpML rule (a rule we say must always be followed)
- 306: Validation failure - master agreement rule (a rule 2 parties agree to follow)
- 307: Validation failure - business policy (a rule that only the recipient has)
- 308: Validation failure - unsupported product/asset
- 310: Signature required - message content must be signed
- 311: Signature not accepted - problem with message signer (cert revoked, unacceptable principal, etc.)
- Level 400: Business Process/Workflow Problems
- 400: Default business process error code
- 401: Don't know - unrecognized trade
- 402: Suitability - trade can't be done for client or dealer suitability reasons
- 403: Credit - trade can't be done for credit reasons
- 404: Not interested - recipient chooses not to respond
- 410: Message arrived too late - e.g. trade no longer exists
- 411: Message expired - message arrived on time, but a response was not generated in time
- Level 500: User Defined
FpML releases to date have concentrated on defining only product structure. These products are the key part of many messages but in order to have a meaningful 'conversation' additional information is required to express the action that the message sender believes the message receiver should perform upon receipt of the message. Usually a key data structure like a product and/or party is the main component of the data that accompanies the request but for some actions additional parameters may need to be included.
This section outlines a process for requesting and obtaining a quote for a trade prior to entering into a full contractual trade. The processes shown are based on those in use today in markets that already have an established electronic market.
Within this section well shall refer to two types of market participant, namely:
A request for quote process could be conducted directly between a market maker and a market taker (e.g. Citigroup''s ''CitiFx FX Benchmark'' service) or more commonly through an electronic exchange or trading portal where several market makers may quote on the same request.
The specification of products in request for quote messages is different than for those in post trade messages. The product may be more ambiguous (e.g. it may not specifiy whether it is a buy or sell) and irrelevant settlement specific data can be omitted.
The 'symetric' nature of FpML product specifications creates some additional problems when considering their generalisation into pre-trade messages. FpML avoids the use of simple 'buy' and 'sell' indicators by associating parties with components of a product and indicating thier obligation (i.e. payer or receiver). However this approach has three problems in the pre-trade space.
-
Anonymity
In some negotiations the identity of the market taker may not be known until an agreement has been reached. FpML requires party information within a product specification to identify obligations. An identity could only be hidden if a standard 'dummy' party was allowed in negotiation messages.
-
Multicasting
A market taker may request quotes on the same product from many market makers. Given the current definitions the product definition would need to be customized for each potential recipient. Alternatively another 'dummy' party could be used to represent any maker maker.
-
Two Way Quotes
In many negotiations the intent of the market taker is unclear and market maker provides both a buy and a sell price. The use of party to identify obligation in an FpML product means that can only have one interpretation (i.e. it is either a buy or a sale, it can never be both).
It is clear that if the current style of product definition is to be used for pre-trade then some additional conventions will need to be adopted.
Whilst it would be possible to generalise the current post trade definitions by making some of the current elements optional (so they could be excluded in RFQs) and the addition of extra optional elements of quote specific data this would lead to possiblity that RFQ products could appear in post trade messages (and vice versa). Syntactically such messages would be valid and extra validation rules could need to defined to detect this semantic error.
A simpler solution would be to define a new set of product definitions specifically for pre-trade messages based on a similiar framework as is used for the existing post-trade products. To implement this a new global element and base type are needed to serve as the attachment point for substituting definitions.
Given these definitions quotable versions of the existing products can be created, for example for FX:
Using this definition it is possible to express the intention of the transaction (e.g. the currencies, delivery date(s) and notional amount) whilst leaving other values (i.e. the exchange rate) out.
<quotableFxSingleLeg>
<exchangedCurrency>
<paymentAmount>
<currency>GBP</currency>
<amount>1000000</amount>
</paymentAmount>
<paymentDate>
<unadjustedDate>2003-07-25</unadjustedDate>
<dateAdjustments>
<businessDayConvention>FOLLOWING</businessDayConvention>
<businessCentersReference href="CENTERS"/>
</dateAdjustments>
</paymentDate>
</exchangedCurrency1>
<exchangeRate>
<quotedCurrencyPair>
<currency1>USD</currency1>
<currency2>GBP</currency2>
<quoteBasis>CCY1PERCCY2</quoteBasis>
</quotedCurrencyPair
</exchangRate>
</quotableFxSingleLeg>
By keeping the quotation product definition close to that of the post-trade product (e.g. using the same element names and ordering) a responding message can be constructed by copying sections of the input message (e.g. parts of the parsed DOM tree representation) and enriching it with any required data to form the full product definition.
In order to create the example definition for FX two other definitions had to be generalised, namely QuotablePayment (from Payment) and QuotableMoney (from Money). These definitions have no direct relationship with their fully formed partners, they are simply modified copies of the original XML schema definitions, although it would be possible to define them using 'inheritance by restriction' (e.g. Money could be inherited from QuotableMoney making the amount element mandatory, Payment and QuotablePayment could be derived from some generic common base class).
This section describes the follow of messages required in a bilateral exchange directly between a market maker and a market maker. It is assumed that market maker operates two systems to support his trading business: one to manage his communication with market takers (the quotation system) and one to record transactions (the trading system). The features of these two logical systems could reside in a single physical implementation.
The following diagram shows the sequence of message exchanges (including an additional flow for a quote update) under normal operation.
The role of each of the messages is as follows:
-
The market taker sends the quotation system a RequestQuote message describing the properties of the transaction in which he is interested in. The quotation system forwards the message on to the market maker for attention. The RequestQuote message uses the QuotableProduct definition to allow the product to be loosely defined.
Note that the message allows more than one product be to included to allow a number of quotes to be request simultaneously.
-
The market market determines either a one-way or two-way price for the product and the left of time for which that quote will be honoured and returns it to the market taker via the quotation system. The market marker can quote for a subset of the requested products (or none of them by not responding at all).
-
The market taker accepts the quote and informs the quotation system of which quote (if the price was two-way) was taken by returning a fully formed trade (possibly containing the market takers settlement information). The quotation system forwards the acceptance to the trading system.
The quotation system should ensure that details of the trade within the QuoteAcceptance match the quotation provided earlier and that the quote is still valid.
-
When the trading system confirms its acceptance of the transaction by returning it in a QuoteAcceptanceConfirmed message (possibly after adding its own settlement information) the quotation system can issue TradeAffirmations to inform each party that the trade is complete.
-
Finally both parties confirm their acceptance of the TradeAffirmation to the quotation system to allow it to record the successful end of the transaction. (The TradeAffirmation and TradeAffirmed messages are described later)
The role of the quotation system in the above processing is to ensure that both market makers and market takers are treated fairly during the quotation process, by maintaining an audit record of message from both parties in order of arrival.
In practice the negotiation of a rate or price for a transaction may require more message exchanges than shown in the last example and there are a number of different outcomes that can occur, namely:
-
The market taker may choose not to act on the quote, leaving it instead to expire at the time designated by the market maker.
There are no messages to inform parties of the expiration of a quote, rather it is discovered by exception when a stale quote is acted upon (shown later).
-
The market maker may choose to refine a previously made quote to reflect a change in market conditions. A marker taker may be tempted to trade on the new quote (as shown in the following diagram) or may leave it to expire or be cancelled.
-
The market taker may re-request a quote for the same product for which he requested an earlier quotation. If the earlier quotation is still active then the request could be ignored or an update sent to original request. If the quote has expired then the normal quotation process is repeated.
-
A market taker may attempt to take up a quotation after it has become expired. This could be accidental or caused through synchronisation issues between the systems (e.g. differences between system clocks, message delays or processing order).
Within the context of FpML, trade affirmation is considered to be a notification of trade execution. An affirmation message may be sent internally or externally after the trade negotiation has completed. At this point the trade may not have been legally confirmed between the two principal parties. Trade affirmations may also be sent by a third party, e.g. a broker, to the principal parties involved.
There are a few basic patterns that are used in the industry today for delivery of trade affirmation messages. In all cases the workflow is basically the same. That is, a notification message is sent from a trading system (either an internal/external system or broker) followed by an acknowledgement of receipt (response message) from the message receiver. Acknowledgement of receipt is used to complement the asynchronous nature of the affirmation message and to assure that the message is not deleted from the originating system prior to being persisted in the destination system.
The following sequence diagram illustrates the process for one side of a bilateral affirmation. Both parties to the trade may be executing this process to obtain an affirmation from each other.
The affirmation message typically contains the same information that is contained in a trade confirmation message. Some details, such as settlement information, could be omitted if it is unknown to the affirmation sender. The following diagram shows the content model for a 'TradeAffirmation' message.
The response to the affirmation message indicates its acceptance and indicates the transaction to which it applies. The content model for it is as follows:
If the trade affirmation is being generated by a third party, such as a broker, then affirmation could be sought from one side and then the other, or from both simultaneously as shown in the following diagram.
The data content of the messages is the same as in the bilateral case.
Today the procedure for achieving trade confirmation is manual for most OTC derivative transactions. Principally this is because the information describing the economic and legal liabilities of the transaction are embedded within a native text document and set amongst legal wording. A skilled human reader is needed to extract and compare the relevant information to determine if it matches the bank's own definition of the same deal.
This section describes how the process of trade confirmation for OTC derivatives might be achieved electronically through the exchange of a sequence of 'messages' between the two parties' computer systems. This can only take place if the parties involved have identified and 'marked-up' the salient details of the transaction using a common vocabulary of terms and data structure, such as those provided by the FpML product definitions.
Matching and comparison are central to confirmation process. In basic terms the matching operation is carried out as follows.
Each new request to confirm a trade results in a search of the system's set of currently unmatched trades to determine if a viable match exists. A trade is comprised of a set of data items that describe its properties and each one of these in turn falls into one of following three categories:
- Identifying financial items that, if present, must exactly (or within tolerance) match (e.g. common trade identifier, trade date, maturity, product type, currencies, notional amounts, parties, etc.).
- Non-identifying items that should exactly (or within tolerance) match (e.g. business centers, date roll conventions, etc.).
- Items irrelevant to the matching process (e.g. comments).
As a result of the matching process a trade is said to be:
- Matched - If all identifying and non-identifying items agree.
- Mismatched - If all identifying items agree but the non-identifying items differ.
- Unmatched - No match on identifying items could be found.
If a trade is matched then both descriptions of a trade are fully reconciled and the parties can agree that it is confirmed. If the trades contain identification information that shows that they should have matched but other significant details differ then the trade is mismatched.
If no match was found then the system must assume that it is yet to receive a copy of the trade from the other party and should add it to the set of unmatched trades and wait for the next request.
Some additional actions are required to prevent trades remaining unmatched indefinitely. There are two cases that can give rise to this situation:
- The counterparty failed to enter and send his definition of the transaction (so no counter-trade exists in the system).
- The counterparty incorrectly identified the true party (in which case a counter-trade exists but will never match).
To attempt to recover from both cases after a trade has remained unmatched for a period of time, the system should send a message to the alleged counterparty in order to provoke them into investigating whether they need to send a new trade or correct an existing unmatched trade.
If after an additional time period the trade still remains unmatched, it should be returned as failed.
The following sections illustrate the end-to-end sequence of message exchanges required to confirm a transaction directly between two parties and the various outcomes that are possible.
Under normal operation we would expect a match to be found as soon as both the internally and externally generated copies of the trade are submitted to the confirmation engine.
Following a trade negotiation each side generates a 'RequestTradeConfirmation' message which is sent to the confirmation provider's system. These requests are used to initiate a trade matching operation. The structure of the request message is shown below.
If the request is valid then the trade is passed to the matching engine for processing. The 'RequestTradeMatch' message needs the same basic data content as the confirmation request message.
When a match is found the associated notification message needs to identify the two trades (via their identifiers) to the participants.
To finish the process the confirmation requestor confirms his acceptance of the match by issuing a 'ConfirmTrade' message that contains a reference to the matched trade.
The final notification of the confirmation provider reiterates the legally binding definition of the trade.
If the request contains the details for a transaction which has already been processed by the confirmation service then a number of possible errors can result in response to the request:
-
If a request to confirm the same trade was made previously and the trade is currently unmatched or mismatched, then the service should reply with a 'TradeAlreadySubmitted' message.
The 'TradeAlreadySubmitted' message has the following content model:
-
If a request to confirm the same trade was made previously and the trade was successfully matched, then the service should reply with a 'TradeAlreadyMatched' message.
The 'TradeAlreadyMatched' message has the following content model:
If a mistake has occurred in the generation of one trade confirmation request it is possible that the system can detect that two trades should have matched (e.g. they contain a common unique trade identifier) but that they cannot due to significant differences.
The confirmation system keeps trades in its pool following the mismatch notification to allow a subsequent correction or cancellation to be applied to the trade.
The 'TradeMismatched' notification must contain the participants trade identifier as well as the identifier for the counter-trade that it should have matched, together with any other potential matches.
Whilst a trade is unconfirmed the requesting party may send new copies of the transaction data to replace the original trade details. The data content of the replacing transaction should match the same requirements as those for initiation. Transactions must be fully re-specified (rather than just the incremental differences). The content model for the 'ModifyTradeConfirmation' message which requests this is as follows:
There are a number of scenarios that can result in the processing of such messages:
-
The confirmation system may not be able to locate the original trade description to be modified.
The generated 'TradeNotFound' message contains the identifier for the trade the system was unable to find.
-
The modification may be accepted and propagated to the matching engine but the trade remains unmatched.
As with the initial matching request the 'ModifyTradeMatch' message contains a full copy of the trade.
-
The modification may be accepted and propagated to the matching engine resulting in a mismatched trade.
-
The modification may be accepted and propagated to the matching engine resulting in a matched trade.
Whilst a trade is unconfirmed the requesting party may ask the entire confirmation action to be cancelled. The cancellation message needs only to contain the information necessary to identify the transaction it affects and must match a currently unconfirmed transaction.
As in earlier cases there are a number of possible processing scenarios depending on the state of the trade within the confirmation system, namely:
-
If the cancellation applies to a trade that can not be located, then the sequence of messages is as follows:
-
If the cancellation applies to an existing unmatched trade then, it generates the following messages:
Once the confirmation system has identified the trade as unmatched it must request that the matching system remove the trade from its storage. This is done through a 'CancelTradeMatch' message.
The response to the confirmation requester completes the process by acknowledging that the confirmation request is cancelled.
-
If the cancellation applies to a trade which has already been matched, then the message flow is as follows:
When the confirmation provider detects an unmatched trade that has been outstanding for a period of time, it sends a copy of the transaction to the indicated counterparty. The trade is not removed from the unmatched trade set so that a subsequent new trade confirmation or modification request may match against the trade.
The 'TradeAlleged' message must provide the identification information for the transaction that is alleged against the counterparty. A confirmation service might provide additional information to suggest current unmatched trades that might be a counter transaction.
A request for trade confirmation that remains unmatched, even after alleged trade processing, for a length of time, should be returned to the requester within a message indicating a failure to match.
The 'TradeUnmatched' notification contains identification information for the unmatched trade and may contain suggestions for possible counter trades.
This section illustrates some processes in action with a third party performing the matching process. In general the sequence of requests and responses is the same as in the bilateral case and there are no additional trilateral specific message types.
As before the confirmation process is begun when the trading parties send a description of the trade to the confirmation system, now external to both parties.
The presence of the third party allows the match to be taken as legally binding and it is automatically considered confirmed without the need for any further messages.
If the request contains the details of a transaction that has already been processed by the conformation service then a number of possible errors can result from the request, namely:
-
If the trade has already been submitted and is currently unmatched or mismatched the service should reply with a 'TradeAlreadySubmitted' message.
-
If the trade has already been processed and has been matched, then the service should reply with a 'TradeAlreadyMatched' message.
The message pattern for the detection of a mismatch is the same as in the bilateral processing case.
As in the bilateral case either party can request that the details of an unmatched trade be replaced with a new definition. The series of scenarios are identical to the bilateral cases.
-
If no corresponding trade can be found in the confirmation system then a 'TradeNotFound' messags is generated.
-
The modification may be accepted and propagated to the matching engine but the trade remains unmatched.
-
The modification may be accepted and propagated to the matching engine resulting in a mismatched trade.
-
The modification may be accepted and propagated to the matching engine resulting in a matched trade.
As in the bilateral case either party can request that the confirmation processing for an unmatched trade be suspended and the trade definition removed from the set of unmatched trades.
-
If the cancellation applies to a trade that can not be located, then the sequence of messages is as follows:
-
If the cancellation applies to an existing unmatched trade, then it generates the following messages:
-
If the cancellation applies to a trade which has already been matched, then the message flow is as follows:
The process of notifying a counterparty of an alleged trade is exactly the same as in the bilateral case.
As in the bilateral case any trades that remain unmatched, even after alleged trade processing has been attempted, are eventually removed from the unmatched trade set.
At a number of points in the confirmation process it is possible that one or the other or both parties to a transaction received an unexpected error message from the other or the central service.
In order to determine the correct course of action to recover from such an error the participants need to determine the perceived state of their transaction within the other party's systems. This indicates that a simple status enquiry operation would be required to recover the necessary information.
For efficiency the trade status enquiry message should allow more than one transaction to be checked at a time (e.g. all outstanding unmatched trades, etc.). Its content model is as follows:
The response message returns each identifier with a suitable status code value (i.e. unmatched, matched, confirmed, not known, etc.).
Most financial instititions use a collection of systems to manage thier trade portfolios, usually with each system providing functionality specific to either a financial product (e.g. foreign exchange, equity, money markets, etc.) or part of the trade processing lifecycle (e.g. trading, risk management, settlement, etc.).
As consequence of this distribution of function, information must be transferred between systems in order to facilitate the adminstration and execution of the transactions over time. In order to maintain consistency between the master copy of a transaction and any replicas of it that may have been created in other systems any change that is applied to the master copy must be notified to the downstream systems so that they too may (if appropriate) update to reflect the change.
Changes to transactions occur for two primary reasons, namely:
- Human error may have caused a descrepancy in the values which parametrically describe the transaction and may be subsequently discovered and corrected.
- Manual or automated processing related to behaviour of the financial product may cause the transaction to change (e.g. option exercise, maturity, etc.)
There are two common ways in which notifications for transcation changes are constructed. One approach is to consider having only two message types, one to indicate the creation of a transaction and another to cause its deletion. In this style an update would be considered to be a deletion of the old transaction image immediately followed by a re-creation of the transaction its new state. Such a protocol will allow the accurate transfer of information between two systems but it fails to relate the two events making it hard to see what the actual cause of the change was.
A better approach is to have a family of messages, each customised to a specific event so that the receiver can adjust its representations of the affected information and at the same time record a connection between the affected items. Such messages can be processed 'atomically' taking the data from one consistent state to another, and at no time leaving the changes incomplete.
The following diagram shows the processing sequence shared by all such notifications. Note that in a real environment the notification message is more likely to be 'multicast' to a number of recievers rather than just one as in the example and/or may pass through some intermediate routing service.
When a system that acts as source of trade information detects that a new trade has been created it should create and send a TradeCreated notification to inform downstream systems.
When a system that acts as source of trade information detects that an existing trade has been modified it should create and send a TradeAmended notification to inform downstream systems.
When a system that acts as source of trade information detects that a previously existing trade has been cancelled it should create and send a TradeCancelled notification to inform downstream systems.
This section defines the business validation rules architecture that was established
by the Validation Working Group. It contains introductory and background information about
the purpose of validation, a guide to how to make use of the documents published
by the Validation Working Group, and serves as a reference point for implementers.
The descriptions contained in this section are designed as supplementary information for the
following artefacts:
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: The document meets the basic XML well-formedness constraints,
all tags are terminated with matching end tags and the character set is
valid.
- Syntactically valid: The document is valid against the latest FpML schema
published by the Architecture Working Group.
- Semantically valid: 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.
The main document produced by the Validation Working Group is the set of validation
rules, expressed in English. The latest version can always be found at
http://www.fpml.org/2003/FpML-4-0/validation.
The document will eventually contain a set of rules broken down by asset class, together
with some that apply to shared component definitions. At the publication of this
working draft, the document contains only a preliminary set of rules for Interest Rate
Derivatives.
The Validation Working Group has not defined a notion of "completeness" for the rule sets.
A mature set of rules for the individual product types will have been the result of a
thorough investigation of the schema, and will have been subject to review and
consensus by stakeholders. If an interested party feels that additional rules should
apply, they can submit them for standardization by raising an issue through the usual
channels.
The Validation Working Group also publishes a set of test cases with each rule set
release. 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, 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.
- 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.
The following subsections explain how to make use of the validation rules in implementations,
the process by which rules are gathered and how releases are managed, and the normativity
of the rules.
The background section has broken down the levels of validity of an FpML document
into three levels, well-formed, syntactically valid and
semantically valid. In order to be semantically valid, the document has
to be syntactically valid, and in addition be valid against a version of
the validation rules.
The latest version of the validation rules can always be found at the
URL http://www.fpml.org/2003/FpML-4-0/validation.
The version is captured by means of a URI, which takes
the following form: http://www.fpml.org/2003/FpML-version/validation/release-date.
The version fragment identifies the version of the standard that the rule set
applies to, for example 4-0 for this version. The release-date
is the full release date of the validation rules in the form
yyyy-mm-dd. An example URL for the current working draft may be
http://www.fpml.org/2003/FpML-4-0/validation/2003-10-14.
The version of the rules published at the official web page is referred to
as the standard rules or the standard rule set. Every rule has
a unique identifier, and for the standard rule set the identifiers follow the
format product-number, e.g. ird-1. ird is the only allocated
product at the time of this writing.
It is likely that
implementors will want to tailor this rule set in order to meet their own processing
requirements. They can do this using a custom rule set. A custom rule set
is an agreed set of rules that is identified using a URI. The format of that URI
is unconstrained, but best practice would dictate that it should include a
publication date, version number, and possibly identifiers of a master agreement.
An example of this for two institutions ABC and DEF would be
http://www.aserviceprovider.com/FpML-4-0/2003-12-01/ABC-DEF.
The URI of the rule sets used to validate an FpML document can be
stored in the validation element, which is located in the root
element. The element is both optional and unbounded, and thus
many rule sets can be applied. This design addresses the following scenarios:
- Identifying the standard rule set - applications
can check whether the version of the standard rules they expect is among
the validation elements.
- Adding rules - parties that wish to perform more extensive internal
validation may specify URIs for additional rule sets.
- Customizing the standard rules - new rule sets can be defined as
subsets of the standard rules, and the new rule set URI inserted instead
of the standard URI.
The following example shows how a document generated by a fictitious service
provider might look:
<FpML>
...
<validation validationScheme="http://www.fpml.org/2003/FpML-4-0/validation/2003-10-14"/>
<validation validationScheme="http://www.aserviceprovider.com/FpML-4-0/2003-12-01"/>
...
</FpML>
Since validation has an impact on the workflow when FpML is used for messaging,
the messaging section of this working draft should be consulted for further
details on how to report rejection.
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.
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 trade.
Processing applications are not obliged to reject invalid trades. 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, as discussed in
the section on architecture concepts.
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.
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.
Pointers to the reference implementations are maintained at
http://www.fpml.org/2003/FpML-4-0/validation/reference.asp.
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.
A swap component contains one or more instances of the swapStream component, zero or more instances of the additionalPayment component together with an optional cancelableProvision component,an optional extendibleProvision component and an optional earlyTerminationProvision component. A swapStream contains the elements required to define an individual swap leg.
Within an FpML swap there is no concept of a swap header. Details of payment flows are defined within swapStreams which each contain their own independent parameters. There can also be additionalPayment elements that contain fees. The additionalPayment component is identical to the otherPartyPayment component shown above.
FpML also supports option related features. These include cancelable, extendible swaps and early termination provisions. Combining these together with swaptions into a single component was considered but rejected in favour of identifying the different option types with their own components. This provided more clarity and allowed for easier combination of the different options into a single trade. As such a swap can contain a cancelableProvision, extendibleProvision and an earlyTerminationProvision. All these components are very similar (and similar to the swaption component), re-use is achieved by using shared entities within each of the components.
FpML supports two representations of a swap stream; a parametric representation, and a cashflows representation. The parametric representation is designed to capture all the economic information required regarding dates, amounts and rates to allow trade execution and confirmation. The parametric representation is mandatory. The cashflows representation specifies an optional additional description of the same stream. The main purpose of this is to allow the inclusion of adjusted dates within an FpML representation of a trade. It can also be used to represent adhoc trades not achievable by easy manipulation of the parameters of a stream (i.e. by changing the adjusted dates). This would lead to the cashflows not matching those generated by the parameters (see more discussion later) and would also render the representation of the trade unsuitable for a confirmation. The spirit of FpML is that such manipulation of cashflows would be achieved by splitting a single stream into a number of streams though it is recognized that this may be impractical in some systems.
The cashflows representation is not self contained as it relies on certain information contained within the stream's parametric definition. The elements required from the parametric definition to complete the cashflows representation are:
The following elements and their sub-elements within the calculationPeriodAmount element:
- floatingRateIndex
- indexTenor
- rateTreatment
- finalRateRounding
- averagingMethod
- negativeInterestRateTreatment
- dayCountFraction
- discounting
- compoundingMethod.
The following elements and their sub-elements within the stubCalculationPeriodAmount element:
- floatingRateIndex
- indexTenor.
The inclusion of the cashflows representation is intended to support Application integration. For example, a financial institution may have one application that captures trade parameters and constructs the trade schedules and then publishes the result for use by other applications. In this case it may be either undesirable, or impossible, for each of the subscribing applications to store and calculate schedules.
The flexibility of the cashflows representation also allows payment and calculation schedules which can not be fully represented by the parametric description. If this situation arises, the mandatory parametric data should still be included in the document and the flag cashflowsMatchParameters should contain the value false to indicate that it is not possible to generate the cashflows from this parametric data. The setting of this flag to true means that the cashflows can be regenerated at any time without loss of information.
Parties wishing to take advantage of the facility for specifying cashflows which are inconsistent with the parametric representation will need to specify additional rules for how the parametric representation should be processed. This applies to both the creation of the parametric data as well as its interpretation.
The cashflows representation specifies adjusted dates, that is, dates that have already been adjusted for the relevant business day convention using the relevant set of business day calendars (lists of valid business days for each business center). The FpML standard does not specify the source of these business day calendars. This may lead applications to generate differing cashflow representations from the same parametric representation if they use different business day calendars. The use of adjusted dates also produces schedules that are only valid at a particular instance of time. Additional holidays for a business center may subsequently be introduced that would result in changes to the adjusted dates, which would not be reflected in the cashflows representation.
Analogous to cashflows being used to represent adjusted dates, with the addition of options it was important to be able to represented the adjusted dates associated with an option. Thus, where appropriate, a component includes an optional element to represent a schedule of adjusted dates for the option. Such a schedule would include details of adjusted dates such as adjusted exercise dates and cash settlement dates.
In general, an interest rate swap will be a swap with a fixed leg and a floating leg, two floating legs, or two fixed legs. However, certain types of trades may contain more than two legs. FpML does not restrict the number of legs that may be defined. From a modeling perspective, FpML does not distinguish between a swap leg referencing a fixed rate and a swap leg referencing a floating rate, the difference being indicated by the existence, for example, of the resetDates component in a floating rate leg.
The structure of a swapStream is shown diagrammatically below:
The components within a swapStream cannot be randomly combined and cannot be thought of as existing in their own right; they only make sense in the given context and in relationship to other components within the swapStream container.
In FpML, the schedule of dates within a swapStream is based around the calculationPeriodDates component. The definition of a calculation period in FpML differs in some respects from the International Swaps and Derivatives Association (ISDA) definition of Calculation Period. In the case of a trade involving compounding, ISDA introduces the concept of a Compounding Period, with several Compounding Periods contributing to a single Calculation Period. The FpML calculation period is equivalent to the ISDA definition of Compounding Period when compounding is applicable, i.e. the calculation period frequency will correspond to the compounding frequency. An FpML calculation period is directly comparable to the ISDA defined Calculation Period when only one calculation period contributes to a payment.
The other date components within swapStream are related to the calculationPeriodDates component. The paymentDates and resetDates components contain the information necessary to construct a schedule of payment and reset dates relative to the calculation period dates.
FpML uses the ISDA Floating Rate Option to specify the floating rate being observed. This scheme was used rather than attempting to parameterize into elements because although most floating rate indices are defined fully by a standard set of parameters (namely index, currency and fixing source) there are sometimes other details including fixing offsets and formulas. This approach allows for more flexibility in adding new floating rate indices without having to introduce new elements, although this comes at the expense of a self contained definition within the standard.
The information relating to amounts and rates is collected in the calculationPeriodAmount and stubCalculationPeriodAmount components. fxLinkedNotionalSchedule is an alternative to notionalSchedule for defining notionals. This allows for the definition of FX Resetable trades by allowing for the notional of a stream to be linked to notionals from another stream by way of the spot fx rate.
Certain swapStream components are designated as being optional (although it would be more accurate to say that they are conditional). Thus a fixed rate stream never includes a resetDates component, but this is required for a floating rate stream. Similarly, the stubCalculationPeriodAmount component will be required if the swap leg has either an initial or final stub, or indeed both, but should otherwise not be specified. The principalExchanges component is required in the case of cross currency swaps or other types of swap involving exchanges of principal amounts.
The payerPartyReference and receiverPartyReference elements indicate which party is paying and which receiving the stream payments. This is done by referencing the appropriate party within the party component.
The detailed structures within the swapStream are shown diagrammatically below:
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:
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.
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.
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.
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.
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.
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.
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 mis-recording 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.
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..
Caps and Floors are defined as one or more capFloorStreams and zero or more additionalPayments. The capFloorStream re-uses the FpML_InterestRateStream entity and thus its content is identical to a swapStream.
Though a capFloorStream allows the definition of fixed streams or known amount streams these are not the intended use of this component and there use would be considered an invalid FpML trade.
The floatingRateCalculation component has been amended to allow the specification of cap/floor structures within a single stream (e.g. straddles, corridors). The changes are:
- The occurrence rules for the components capRateSchedule and floorRateSchedule have been changed from 'zero or one' to 'zero or more'.
- An optional buyer and seller reference have been added to these schedules
These additions allow for multiple cap and floor rates to be added to the stream and to define precisely which party bought and sold them. To maintain backward compatibility with FpML1.0 the buyer and seller are optional. When absent the following rules apply:
- CapRateSchedule: BUYER = Stream payer SELLER = Stream receiver
- floorRateSchedule: BUYER = Stream receiver SELLER = Stream payer
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.
FpML 4.0 Credit Derivatives extends the product coverage of
FpML to include the credit default swap. In order to
define the scope of this work FpML adopted the definition of the credit default
swap used in the ISDA Year End 2001 Flash Survey:
"In a credit default swap one counterparty
(the protection seller) agrees to compensate another
counterparty (the protection buyer) if a specified company or Sovereign
(the reference entity) experiences a credit event, indicating it is or may be
unable to service its debts. The protection seller is paid a fee and/or
premium, expressed as an annualized percent of the notional in basis points,
regularly over the life of the transaction."
The FpML 4.0 Credit Derivatives Product Architecture draws heavily on
the 2003 ISDA Credit Derivatives Definitions (hereafter referred to as
the "2003 Definitions"). Wherever
feasible the terminology and practice of the ISDA definitions has been adopted
to ensure consistency between traditional and FpML contract representations.
Appendix A lists the elements in FpML 4.0 Credit Derivatives that differ in
name from their corresponding terms in the 2003 Definitions. In FpML 4.0 it is possible to represent credit default swap trades done under either the 1999 or the 2003 definitions.
The FpML 4.0
Credit Derivatives Subschema supports both a full confirmation and a
transaction supplement (i.e. economics of the trade) representation of the
credit default swap. The transaction supplement representation is a subset of
the elements contained in the full confirmation representation. This flexible
approach makes FpML 4.0 Credit Derivatives useable in all stages of the credit
default swap trade lifecycle.
This document
provides an in-depth review of the technical architecture of the FpML 4.0
Credit Derivatives Subschema.
Like all other
derivative products supported by FpML, the type used to represent the credit
default swap, CreditDefaultSwap, is defined as an extension of the Product type and the corresponding creditDefaultSwap element belongs to the product substitution group. The creditDefaultSwap element appears in Figure 1.
Figure 1: creditDefaultSwap element
The structure of
the creditDefaultSwap
element corresponds to the structure of the
Confirmation that appears in Exhibit A of the 2003 Definitions (hereafter
referred to as the
"2003 Confirmation").
The six sections that comprise the 2003 Confirmation and their
corresponding FpML elements appear in Figure 2.
2003 Confirmation
|
FpML creditDefaultSwap Element
|
|
General Terms
|
generalTerms
|
|
Fixed Rate
Payments
|
feeLeg
|
|
Floating
Payment
|
protectionTerms
|
|
Settlement
Terms
|
physicalSettlementTerms or
cashSettlementTerms
|
|
Notice and
Account Details
|
N/A
|
|
Offices
|
N/A
|
Figure 2: Sections of the 2003 Confirmation and their
corresponding FpML creditDefaultSwap elements.
Additional
points to note:
-
The id attribute and the productType and productId elements are inherited from the product type. They are not credit derivatives specific. Each product supported by FpML contains these elements.
-
Although Settlement
Terms are specified on a full confirmation, they are not necessarily
required for a transaction supplement or other activities in the trade
lifecycle. Therefore, the equivalent element (physicalSettlementTerms or cashSettlementTerms) is optional in FpML 4.0.
-
The Notice and
Account Details and Offices sections of the confirmation do not
have a direct analog in the FpML 4.0 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
.
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 scheduledTerminationDate element represents the Scheduled Termination Date term. This element can be specified as either an adjustable date or a relative date. For confirmation purposes a specific date will always be specified. Again, the AdjustableDate2 type allows the parties to explicitly specify a particular business day convention per the 2003 Definitions. The Interval type (e.g. 5 Y for a five year deal) is included because this way of expressing a scheduled termination date is quite commonly used in the pre-trade process and also in historical price databases.
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 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.
A referenceObligation element has either a bond or a convertibleBond as one of its child elements. The bond and convertibleBond 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. For a credit default swap one of these elements is
used to specify a Reference Obligation's CUSIP/ISIN, Maturity and
Coupon values. The instrumentId element is used to specify CUSIP/ISIN. The optional 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.
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.
Figure 4:
referenceInformation element
Although the structure of
referenceInformation
appears to be somewhat complex, the specification of Reference Entity and
Reference Entity 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>
</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>
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 5 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 5 General Terms that do not appear in
creditDefaultSwap.generalTerms element.
The feeLeg element represents the information specified on 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 4.0 Interest Rate
Derivatives.
The
feeLeg
allows representation of these types of payment schedules:
- 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
An optional cashflow representation is also permitted. The feeLeg
element appears in Figure 6.
Figure 6: 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.
The rollConvention
element is used to address the ambiguities that can otherwise occur
with regard to the actual payment dates, particularly when considering
month-end rolls and any initial stub. The
rollConvention
element typically takes a value of 1-30 or EOM.
It represents the actual unadjusted day in the month on which
payments would occur.
As in FpML 4.0 Interest Rate Derivatives, the
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
dayCountFraction
element should be omitted in the case of a Transaction Supplement.
Similarly, the optional
calculationAmount
element provides support for the full confirmation but should be omitted in the
case of a Transaction Supplement.
The addition of the
adjustedPaymentDate
element within
singlePayment
and
adjustedPaymentDates
component in
periodicPayment
allows the optional inclusion of a 'cashflows' like structure
consistent with what was done in FpML 4.0 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>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>ACT/360</dayCountFraction>
</fixedAmountCalculation>
</periodicPayment>
</feeLeg>
or in a Transaction Supplement
<feeLeg>
<periodicPayment>
<paymentFrequency>
<periodMultiplier>3</periodMultiplier>
<period>M</period>
</paymentFrequency>
<rollConvention>EOM</rollConvention>
<fixedAmountCalculation>
<fixedRate>0.0085</fixedRate>
</fixedAmountCalculation>
</periodicPayment>
</feeLeg>
Example 4 - Fixed Rate - Initial (Short) Stub:
- Effective Date: 30 September, 2002
- Scheduled Termination Date: 1 November, 2007
- Notional Amount: USD 5,000,000
- Fixed Rate: .85%
- Payment Frequency: 1 November 2002 and each February 1, May 1, August 1 and November 1
- Day Count Fraction: ACT/360
<feeLeg>
<periodicPayment>
<paymentFrequency>
<periodMultiplier>3</periodMultiplier>
<period>M</period>
</paymentFrequency>
<firstPaymentDate>2002-11-01</firstPaymentDate>
<rollConvention>1</rollConvention>
<fixedAmountCalculation>
<fixedRate>0.0085</fixedRate>
</fixedAmountCalculation>
</periodicPayment>
</feeLeg>
Example 5 - Fixed Rate - Initial (Long) Stub:
- Effective Date: 30 September, 2002
- Scheduled Termination Date: 1 November, 2007
- Notional Amount: USD 5,000,000
- Fixed Rate: .85%
- Payment Frequency: 1 February 2003 and each May 1, August 1, November 1 and February 1
- Day Count Fraction: ACT/360
<feeLeg>
<periodicPayment>
<firstPaymentDate>2003-02-01</firstPaymentDate>
<paymentFrequency>
<periodMultiplier>3</periodMultiplier>
<period>M</period>
</paymentFrequency>
<firstPaymentDate>2002-11-01</firstPaymentDate>
<rollConvention>1</rollConvention>
<fixedAmountCalculation>
<fixedRate>0.0085</fixedRate>
</fixedAmountCalculation>
</periodicPayment>
</feeLeg>
Example 6 - Fixed Amount - Single Payment:
- Effective Date: 1 November, 2002
- Scheduled Termination Date: 1 November, 2007
- Notional Amount: USD 5,000,000
- Fixed Amount: USD 100,000
- Payment Date: 2 November 2002
<feeLeg>
<singlePayment>
<adjustablePaymentDate>2002-11-02</adjustablePaymentDate>
<fixedAmount>
<currency>USD</currency>
<amount>100000.00</amount>
</fixedAmount>
</singlePayment>
</feeLeg>
Example 7 - Upfront Fee combined with Fixed
Rate Regular Schedule
- Effective Date: 1 November, 2002
- Scheduled Termination Date: 1 November, 2007
- Notional Amount: USD 5,000,000
- Upfront Payment Amount: USD 100,000
- Upfront Payment Date: 2 November 2002
- Fixed Rate: .85%
- Payment Frequency: Quarterly
- Day Count Fraction: ACT/360
<feeLeg>
<singlePayment>
<adjustablePaymentDate>2002-11-02</adjustablePaymentDate>
<fixedAmount>
<currency>USD</currency>
<amount>100000.00</amount>
</fixedAmount>
</singlePayment>
<periodicPayment>
<paymentFrequency>
<periodMultiplier>3</periodMultiplier>
<period>M</period>
</paymentFrequency>
<rollConvention>1</rollConvention>
<fixedAmountCalculation>
<fixedRate>0.0085</fixedRate>
</fixedAmountCalculation>
</periodicPayment>
</feeLeg>
Example 8 - Irregular Payment Schedule
- Effective Date: 1 November, 2002
- Scheduled Termination Date: 1 November, 2007
- Notional Amount: USD 5,000,000
- Fixed Amount of USD 100,000 on 2 November 2002 and USD 50,000 on 2 December 2002
.
<feeLeg>
<singlePayment>
<adjustablePaymentDate>2002-11-02</adjustablePaymentDate>
<fixedAmount>
<currency>USD</currency>
<amount>100000.00</amount>
</fixedAmount>
</singlePayment>
<singlePayment>
<adjustablePaymentDate>2002-12-02</adjustablePaymentDate>
<fixedAmount>
<currency>USD</currency>
<amount>50000.00</amount>
</fixedAmount>
</singlePayment>
</feeLeg>
Example 9 - Fixed Rate - Final (Short) Stub:
- Effective Date: 18 February, 2003
- Scheduled Termination Date: 20 March, 2008
- Notional Amount: USD 5,000,000
- Fixed Rate: .9%
- Payment Frequency: 20 March 2003 and each June 20, September 20 and March 20.
- Day Count Fraction: ACT/360
<feeLeg>
<periodicPayment>
<paymentFrequency>
<periodMultiplier>3</periodMultiplier>
<period>M</period>
</paymentFrequency>
<lastRegularPaymentDate>2003-03-20</lastRegularPaymentDate>
<rollConvention>20</rollConvention>
<fixedAmountCalculation>
<fixedRate>0.009</fixedRate>
</fixedAmountCalculation>
</periodicPayment>
</feeLeg>
Example 10 - Fixed Rate - Regular Schedule
(Including Optional Cashflows):
- Effective Date: 1 November, 2002
- Scheduled Termination Date: 1 November, 2003
- Notional Amount: USD 5,000,000
- Fixed Rate: .85%
- Payment Frequency: Quarterly
- Day Count Fraction: ACT/360
Note that the
adjustedPaymentDate
element values have not
been adjusted for any applicable business days.
<feeLeg>
<periodicPayment>
<paymentFrequency>
<periodMultiplier>3</periodMultiplier>
<period>M</period>
</paymentFrequency>
<rollConvention>1</rollConvention>
<fixedAmountCalculation>
<calculationAmount>
<currency>USD</currency>
<amount>5000000</amount>
</calculationAmount>
<fixedRate>0.0085</fixedRate>
<dayCountFraction>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>
The
protectionTerms
element, which appears in Figure 7, 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 7: protectionTerms element
The
only required child element of
protectionTerms
is
calculationAmount.
It represents
the term Floating Rate Payer Calculation Amount in the 2003
Definitions.
In order to indicate that a particular Credit Event is applicable in an FpML credit default swap trade, an element whose name is the Credit Event it represents appears as a child of the creditEvents element. If a
particular Credit Event has no attributes of its own (e.g. Bankruptcy),
it appears as an empty element. On the other hand, if it does have attributes
(e.g. Failure to Pay - Grace Period, Payment Requirement) then those
attributes appear as child elements of the creditEvent.
In the following example, these credit
events are applicable:
- Bankruptcy
- Failure to Pay with Grace Period Extension not applicable and Payment Requirement of USD 1,000,000.
- Restructuring (R)
- Default Requirement of USD 10,000,000.
And these conditions to credit event notice settlement
apply:
- Both the Buyer and Seller are notifying parties.
- Notice of Publicly Available Information
is a Condition to Payment - defaults apply for Public Source(s) and Specified
Number.
<creditEvents>
<bankruptcy/>
<failureToPay>
<paymentRequirement>
<currency>USD</currency>
<amount>1000000</amount>
</paymentRequirement>
</failureToPay>
<restructuring>
<restructuringType restructuringScheme =
"http://www.fpml.org/spec/2003/restructuring-1-0">R</restructuringType>
</restructuring>
<creditEventNotice>
<notifyingParty>
<buyerPartyReference href = "abc"/>
<sellerPartyReference href = "def"/>
</notifyingParty>
<publiclyAvailableInformation>
<standardPublicSources/>
<specifiedNumber>2</specifiedNumber>
</publiclyAvailableInformation>
</creditEventNotice>
</creditEvents>
Please note the following regarding the representation of the Restructuring credit
event:
- If the Restructuring credit event is not applicable, no
restructuring element should appear in the creditEvents element.
- If Restructuring as defined in the 2003 Definitions is applicable and a full confirmation is being represented, then the restructuring element should appear and the restructuringType element contains one of the three restructuring codes (see below).
- If Restructuring as defined in the 2003 Definitions is applicable and a transaction supplement is being represented, then only the restructuring element should appear (the actual restructuring type will be defined in the relevant master confirmation associated with the transaction supplement).
- If the 1999 Definitions are used and a transaction supplement is being represented, the actual restructuring type needs to be explicitly specified in the XML instance using the restructuringType element (same as one would do for a long form) since the 1999 master agreements are silent on the actual restructuring type.
The legal restructuring codes are:
- ModR: If Restructuring Maturity Limitation and Fully Transferable Obligation (Section 2.32 of the 2003 Definitions) applies.
- ModModR: If Modified Restructuring Maturity Limitation and Conditionally Transferable Obligation (Section 2.33 of the 2003 Definitions) applies.
- R: If neither Restructuring Maturity Limitation and
Fully Transferable Obligation or Modified Restructuring Maturity
Limitation and Conditionally Transferable Obligation are
applicable.
The optional obligations element has a
category
child element that represents the Obligation
Category term. The
ObligationCategory
type is an
enumeration that consists of values representing the following categories:
- Payment
- Borrowed Money
- Reference Obligations Only
- Bond
- Loan
- Bond or Loan
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.
If
settlement terms are specified in an FpML 4.0 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 8: physicalSettlementTerms element
The
cashSettlementTerms
element, which appears in
Figure 9, 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 9: cashSettlementTerms element
There
are several places in the FpML 4.0 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 10.
|
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 10: Naming differences between
FpML 4.0 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.
Foreign exchange single-legged instruments include spot and forwards. fxSingleLeg contains two instances of the exchangedCurrency component (the first currency and the second currency), either a single value date component for the trade or an optional value date per exchanged currency, a single instance of the exchangedRate component, and an optional nonDeliverableForward component.
The simple FX transaction contains two currencies which are exchanged between parties. The characteristics of each currency exchange: the currency, the amount, and optionally settlement instructions, are described in the exchangedCurrency structure. An optional payment date is allowed per currency, if there is a requirement to provide for date adjustments for each currency based upon business day conventions to accommodate unscheduled holidays.
The rate of exchange is required for a foreign exchange trade. The rate of exchange includes a reusable entity (FpML_QuotedCurrencyPair) that describes the underlying composition of the rate: the currencies and the method in which the rate is quoted. The actual trade rate is required, but other rate information such as spot rate and forward points are also accommodated. For non-base currency trades, side rates (or rates to base) are provided for.
Non-deliverable forwards are catered for within the conventional FX single leg structure by including an optional non-deliverable information structure. This contains identifies the agreed-upon settlement currency and describes the fixing date and time, as well as the settlement rate source that the fixing will be based upon. The non-deliverable structure is shown below.
Significant effort has been spent in the development of FX to incorporate the appropriate information required for trade confirmation and settlement. An optional settlementInformation structure has been included for each exchanged currency. This can be used in a variety of ways: not at all, flagging a trade for standard settlement, flagging a trade for settlement netting, or specifying the detailed settlement instructions for that particular currency flow.
If the specific settlement instruction is included, then this is broken out into correspondent, intermediary, and beneficary information. This includes the identificaiton of the routing mechaism (e.g., SWIFT, Fedwire, etc.) that the trade will settle via and the id and account that the trade will settle via. Routing can be handled either via purely a routing id (e.g., SWIFT code), routing details (a customer name, address, and account number), or a combination of routing id and details. The following diagrams show the correspondent, intermediary, and beneficiary structures.
Split settlement is also accommodated. Split settlement will mean that there will be multiple beneficiaries associated with a single trade, where the payment amounts are broken down between beneficiaries. The following diagram shows how this has been modeled:
Foreign exchange swaps are a very simple extension of FpML_FXLeg, whereby the FX swap is simply multiple legs. A standard FX swap contains two legs, whereby the second leg has a value date that is greater than the value date on the first leg. There are a variety of different types of FX swaps in the marketplace: standard (round-amount) swaps, overnight swaps, unequal-sided swaps, forward-forward swaps. Therefore, all of the features that are available within a standard spot or forward trade (described previously) can be utilized in describing an FX swap as well.
Foreign exchange simple options include standard European and American options. These are commonly referred to as "vanilla," or non-exotic, options. fxSimpleOption identifes the put currency and amount and call currency and amount, as well as the exercise style and premium information. The premium is structured similar to an exchanged currency for a conventional FX trade, where optional settlement information for the premium can be attached. In addition, there is an optional quotedAs structure that contains information about how the option was originally quoted, which can be useful. Below are the structures for a conventional FX OTC option.
Non-deliverable options are also supported by including the FpML_CashSettlement, which is the identical structure used within non-deliverable forwards.
A conventional option except that it is changed in a predetermined way when the underlying trades at predetermined barrier levels. A knock-in option pays nothing at expiry unless at some point in its life the underlying reaches a pre-set barrier and brings the option to life as a standard call or put. A knock-out option is a conventional option until the price of the underlying reaches a pre-set barrier price, in which case it is extinguished and ceases to exist. Barrier options have both a strike price and a barrier price.
An optionalbarrierTypeScheme is used to allow for differentiation between knockin, knockout, reverse knockin, and reverse knockout options. One or more barriers are supported. The reference spot rate, while optional, is recommended, as it determines whether the option need to go up or down (or is "out-of-the-money" or "in-the-money") in order to hit the barrier. Additionally, the payout is utilized to accommodate rebates when a barrier is hit. Below are the structures for an FX OTC barrier option.
The terms binary and digital are not clearly defined in the FX markets and can occasionally be synonomous. This is used to define an option that has a discontinuous payout profile. It typically pays out a fixed amount if the underlying satisfies a predetermined trigger condition or else pays nothing. Unlike the standard option, the amounts quoted are the payout amounts as opposed to a notional underlying amount.
Digital options typically are defined as being European, meaning the observation occurs only if the spot rate trades above (or below) the trigger level on expiry date. The two examples that have been included in the specification are the digital and the range digital.
Binary options, on the other hand, are more like American options, meaning that the payout occures if the spot rate trades through the trigger level at any time up to and including the expiry date. The four examples that have been included in the specification are the one-touch, no-touch, double one-touch, and double no-touch binary options. Below are the structures for FX OTC binary and digital options.
Foreign exchange average rate options (sometimes referred to as Asian options) are options whose payout is based upon the average of the price of the underlying, typically (but not necessarily) over the life of the option. Average rate options are popular because they are usually cheaper than conventional options because the averaging process over time reduces volatility.
fxAverageRateOption allows for either a parametric representation of the averaging schedule (e.g., daily, 2nd Friday, etc.), utilizing the same rolling convention schemes as utilized within the interest rate derivatives area. Alternatively, each specific averaging period can be identified, along with a specific weighting factor for that period. In addition, average rate options on occasion, when struck, already have agreed-upon rate observations in the past; the structure accommodates this as well.
The term deposit is an agreement between two parties to enter into a financial contract. Similar to a forward rate agreement, a term deposit is contained within a single component and contains no interim interest payments. It is an on-balance sheet transaction that pays interest at maturity based upon an agreed interest rate. While the term deposit instrument is technically an interest rate product, it is included within the FX section of FpML because many institutions that utilize FX transactions also conduct short-term deposits in their respective portfolios to fund foreign currency requirements.
Although there are a number of structured deposits that are occasionally transacted in the marketplace, including deposits with amortizing structure, rateset schedules, and periodic interest payment or interest recapitalization schedules, or even deposits that are denominated in one currency but pay interest in another currency, those types of transactions represent a significant minority of the number of deposits dealt in the wholesale financial marketplace. Therefore, the term deposit structure is intentionally very simple to accommodate the simple yet highly liquid deposit instruments.
Note that both the start date and maturity date of the term deposit is negotiated up front and are typically of short duration, so the dates of these instruments are fixed. Any unforeseen holidays will generally cause for renegotiation of the contract. Therefore, similar to FX instruments, there are no allowances for date adjustments.
One or more financial instruments, of any sort that are supported by the FpML specification, can be combined to form what is called a strategy. This can include various a package of the same or different asset classes in a single trade. Typical examples of this would include option packages (e.g., straddles, strangles) or a delta hedge (FX OTC option with spot risk hedged by FX spot deal). Additionally, other asset classes can be combined in a strategy (e.g., interest rate swap with FX, etc.).
In FpML version 3.0 the equityOption component was defined to describe
"vanilla" options with the following characteristics:
- put and call options;
- with American or European exercise styles;
- on single stocks or indices; and
- delivery being either cash or physical stock.
For FpML 4.0 this component has been extended to encompass
more exotic types of options, including:
- Bermudan exercise style;
- basket underlyings;
- forward starts;
- quantos and composites;
- averaging; and
- barriers, knock-ins, knock-outs and binary (digital) options.
Many of the above can be combined through the use of a
single component architecture that has a number of optional features.
Compound options (such as Butterfly and Straddle structures) can be
represented by combining two or more equityOption components in a
strategy component. In this way the vast majority
of equity option structures that are used between wholesale market
counterparties can be represented in FpML.
The product architecture draws heavily on ISDA's 1996
definitions for equity derivatives as updated by the emerging 2002
definitions. Wherever possible the terminology and practice of the ISDA
definitions has been adopted to ensure consistency between traditional and
FpML contract representations.
In the equityOption component buyerPartyReference
and sellerPartyReference are pointer style references
to party components that specify the option
buyer and seller respectively. The type of the option (call or put) is
specified in optionType. The effective date
for a forward starting option is specified in equityEffectiveDate
The underlyer of an equity option may be either a single underlyer, or basket, specified using
the underlyer component specified below
The strike is expressed either as a price (strikePrice)
or as a percentage (strikePercentage) of the forward starting spot
price. An optional currency element caters
for the case where the strike price is expressed as a monetary amount, rather
than as a level.
The numberOfOptions
element specifies the number of options in the option transaction. The
optionEntitlement element specifies the number of
shares per option. The number of options, strike price and notional are
linked by the equation:
notional amount = number of options x
option entitlement x strike price
Provided that two of notional amount, number of options
and option entitlement are specified, then the third may be omitted.
spotPrice is the price per share, index or basket observed on the trade or effective
date. It is only used for forward starting options.
The exercise provisions for the option are specified in
the equityExercise component. American,
European and (new in FpML 4.0) Bermudan styles are all catered for. The
equityExercise component is described in more
detail below.
Quanto options are handled using the new FXFeature
component, which is described below.
Where necessary many other non-vanilla features are
specified in the optional equityOptionFeatures component, which is also new
in FpML 4.0. This component is described in more detail below.
The equityPremium
component specifies the amount and timing of the premium payment that is made
for the equity option. It is described in more detail below.
Where the underlying is shares, the extraordinaryEvents
component specifies marketevents affecting the issuer of those shares that may require the terms of the
transaction to be adjusted. The methodOfAdjustment component specifies how
adjustments will be made to the contract should one or more of the
extraordinary events occur.
The underlyer component specifies the asset(s) on which the option is
granted, which can be either on either a singleUnderlyer
or basket, and consist of equity, index, or convertible bond components, or some combination of these
The description element is used to provide a free-form
text description of the asset, whereas instrumentId contains a short-form, unique
identifier (e.g. ISIN, CUSIP) for the asset. At least one instrumentId
must be present.
The exchangeId element
contains a short form unique identifier for an exchange. If omitted then the
exchange shall be the primary exchange on which the underlying is listed. The
relatedExchangeId element contains a short
form unique identifier for a related exchange. If omitted then the exchange
shall be the primary exchange on which listed futures and options on the
underlying are listed.
The clearanceSystem
element contains the identity of the clearance system to be used. If omitted,
the principal clearance system customarily used for settling trades in the
relevant underlying shall be assumed.
FpML 4.0 supports three styles of equity option: European,
American and Bermudan. For consistency of representation with interest rate
derivatives each of these styles is represented using its own component. Each
of these components is described more fully below. The
automaticExerciseApplicable element contains a
boolean value to indicate whether or not the option (or any remaining portion
of the option, if multiple exercise is permitted) is exercised automatically
if it expires in the money.
The equityValuation
component specifies the date and time on which the option is valued. The
element valuationTimeType enables the
valuation time to be expressed as relative to some other event, such as the
close of business for the exchange. Alternatively if its value is "Specific"
then the element valuationTime is used to
specify an explicit time of day.
The futuresPriceValuationApplicable element contains a
boolean value to indicate whether or not the official settlement price as
announced by the related exchange is applicable, in accordance with the ISDA
2002 definitions.
The settlementDate
component specifies when the option is to be settled relative to the
valuation date. If the settlement date is not specified explicitly then
settlement will take place on the valuation date. The settlementType component is used to specify whether
the option is settled in cash or physically.
The settlementPriceSource
element specifes the source from which the settlement price is to be
obtained, e.g. a Reuters page, Prezzo di Riferimento, etc.
The failureToDeliverApplicable element is used where
the underlying is shares and the transaction is to be physically settled. The
element contains a boolean value that, if "true", then a failure to deliver
the shares on the settlement date shall not be an event of default for the
purposes of the master agreement.
The sub-components of the equityEuropeanExercise component specify the date
and time when the option will expire. The element equityExpirationTimeType enables the expiration
time to be expressed as relative to some other event, such as the close of
business for the exchange. Alternatively if its value is "Specific" then the
element equityExerciseTime is used to specify
an explicit time of day.
The commencementDate and expirationDate are used to specify the period
during which the option may be exercised (more than once if permitted by the
equityMultipleExercise component). The option
may be exercised on any business day in this period up to the latest time
specified for exercise. The element equityExpirationTimeType enables the expiration
time to be expressed as relative to some other event, such as the close of
business for the exchange. Alternatively if its value is "Specific" then the
element equityExerciseTime is used to specify an explicit time of day.
The element latestExerciseTimeType enables the latest exercise
time to be expressed as relative to some other event, such as the close of
business for the exchange. Alternatively if its value is "Specific" then the
element latestExerciseTime is used to specify an explicit time of day.
The commencementDate and
expirationDate components are used to specify
the period during which the option may be exercised (more than once if
permitted by the equityMultipleExercise
component). The option may be exercised on any of the days in the list
bermudanExerciseDates up to the latest time specified for exercise. The
element equityExpirationTimeType enables the expiration
time to be expressed as relative to some other event, such as the close of
business for the exchange. Alternatively if its value is "Specific" then the
element equityExerciseTime is used to specify
an explicit time of day.
The element latestExerciseTimeType enables the latest exercise
time to be expressed as relative to some other event, such as the close of
business for the exchange. Alternatively if its value is "Specific" then the
element latestExerciseTime is used to specify
an explicit time of day.
The type of FX feature is specified in the element FXFeatureType, and may be
either Quanto or Composite
- Quanto - where two currencies are involved. To adjust the investor's base currency
protection on an underlying position which varies in value in the non-base currency.
- Composite - where multiple currencies can be involved. An option is struck on a
foreign underlying at a value of the underlying in the investor's base
currency. The payout is based on the investor's base currency at exercise.
The FX rate may be specified as an explicit rate using FXRate, or by using the
FXSource component to specify the source from which the FX rate is to be obtained.
Three types of option features are catered for in FpML
4.0: asians, barriers and knocks. All of these are path-dependent options.
Asian features are described below. Barriers may be caps or floors; knocks
may be knock-ins or knock-outs - these share a common architecture that is
described below.
A binary option (also known as a digital option) is a
special case of a barrier where the payout is specified to be a fixed amount
rather than a percentage of the value of the underlying on the date that the
option is triggered.
An asian option is one in which an average price is used
to derive the strike price ("averaging in") or the expiration price
("averaging out") or both. The type of averaging is specified in the
averagingInOut element.
The period over which the averaging is calculated is
specified in the component averagingPeriodIn
or averagingPeriodOut as appropriate. Both
components have the same structure. The period is specified either as a
calculation, using one or more schedule
components (which permits specifications such as every Friday from and
including 24 May 2002 to and including 22 November 2002), and/or as a
list of explicit dates and times, using the
averagingDateTimes component. It is permissible to
use the list of dates and times to specify averaging points that are
additional to those derived from the calculation rule specified in
schedule components. In the event that any of the
dates is not a business day then it is assumed that it will be rolled forward
to the next business day in accordance with ISDA convention.
The marketDisruption
element specifies the action to be taken if it is not possible to obtain a
price on one of the days used for averaging.
A barrier option is one in which, if the option expires in
the money, an additional payment will occur. With a barrier cap the
additional payment will be made if the trigger level is approached from
below, whereas with a barrier floor the additional payment will be made if
the trigger level is approached from above.
Knock options are of two types. A knock-in option does not
come into effect until the trigger level has been reached, if it is never
reached then the option expires worthless. Conversely, a knock-out option
expires immediately the trigger level is reached.
A common structure is used to specify barrier caps,
barrier floor, knock-ins and knock-outs. The diagram shows the
barrierCap structure.
The dates on which the underlying is valued to test for
the occurrence of the trigger event are either expressed in one or more
schedule components and/or as a list of explicit
dates, using the triggerDates component. It
is permissible to use the list of dates to specify trigger dates that are
additional to those derived from the calculation rule specified in
schedule components. In the event that any of the
dates is not a business day then it is assumed that it will be rolled forward
to the next business day in accordance with ISDA convention.
The trigger component
specifies that the trigger event either as a
level or as a levelPercentage
(of the strike).
The optional featurePayment component specifies a payment to be
made if the trigger event occurs. The payment date can be expressed either as
an explicit date or as relative to some other date, such as the trigger date
or the contractual expiry date.
The equityPremium
component specifies the amount and timing of the premium payment that is made
for the equity option. payerPartyReference
and receiverPartyReference are pointer style
references to party components that specify
the payer and receiver of the premium respectively.
In FpML 4.0 the premium amount can be expressed in a
number of ways: as a monetary amount (paymentAmount), as a price per option or as a
percentage of the notional - if more than one method is used then they must
be mutually consistent. There are circumstances in which no premium would be
specified, for example if the trade formed part of a put/call combo
structure.
The swapPremium element
holds a boolean value that, if "true" specifies that the premium is to be
paid in the style of payments under an interest rate swap contract.
When a date specified in an equity option contract falls
on a non-business day then it may be necessary to adjust it to be a business
day. At the time the contract is agreed it is not always possible to
determine whether or not a particular date in the future will be a business
day.
The meaning of "business day" varies according to the
context in which it is used. When the context is the payments of monetary
amounts then the rules for adjustment according to currency business days
apply, and the equity option product architecture uses the
same AdjustableOrRelativeDate
component ( or derivations ) as the interest rate and foreign exchange products.
However, when the context is the valuation or settlement
of equities or equity indices then the term "business day" means "exchange
business day". In this case the equity option product architecture specifies
the use of unadjusted dates with the adjustment rules being implicitly
inherited from the ISDA definitions.
FpML 4.0 Equity Derivative Swaps Product Architecture extends the product coverage of FpML to include the equity swap.
This document provides an in-depth review of the technical architecture of the FpML 4.0 Equity Swap subschema. The scope as well as the current limitations of this schema, which will be addressed through a next release, are described in the first section of this document.
Like all other derivative products supported by FpML, the type used to represent the equity swap, EquitySwap, is defined as an extension of the Product type and the corresponding equitySwap element belongs to the product substitution group.
The scope of this FpML representation for equity swaps is to capture the following types of swaps that have equity-related underlyers:
- Single stock swaps as well as basket swaps (i.e. swaps with multiple underlyers);
- Swaps that have a different types of underlying assets (equity, index, mutual funds, exchange-traded funds, convertible bond, futures), or a combination of these;
- 2-legged swaps with a combination of an equity leg and a funding leg, as well as swaps that either have only one leg (e.g. fully funded or zero-strike swap) or multiple equity legs (e.g. outperformance swaps);
- Swaps that have specific adjustment conditions, such as execution swaps or portfolio rebalancing swaps;
- Swaps that involve the exchange of principal cashflows.
This current version of the FpML representation for the equity swap is focused on specifying the economic features of the swap. The Extraordinary Events terms will be incorporated at a later point in time, and will take into consideration the recent release of the 2002 ISDA Definitions for Equity Derivatives.
Also, the trigger swaps, which equity risk morphs into a fixed income risk once a certain market level is reached, will be specified through a distinct schema that will be released at a later point.
The FpML representation of the equity swap relies on five key structures that are presented in the figure 1 below:
Figure 1: The equitySwap main components.
These five main components of the equity swap schema are the following:
- The equityLeg component specifies the equity leg of the swap. There can be one or several equity legs;
- The interestLeg component defines the interest leg of the swap. The possibility is provided for having swaps that do not have an interest leg (case of an outperformance swap where 2 equity underlyers are swapped, or a fully-funded swap where there is no financing component);
- The principalExchangeFeatures is an optional component that describes the case where principal cashflows are exchanged between the parties to the trade;
- Similarly to the interest rate swap (but with a different structure, that serves the specific features of the equity swaps), the additionalPayment component supports the other types of payments involving the parties to the trade, such as fees;
- Finally, the earlyTermination component specifies, for one or for both the parties to the trade, the date from which it can be early terminated.
The various sections below detail each of these five structures of the equity leg of the swap.
The figure 2 presents the structure of the equity leg of the swap, which has 10 categories of components:
Figure 2: The structure of the equity leg.
These 10 categories of components are described through the next few pages. They are the following:
- The identication of the payer and receiver party for this equity leg;
- The determination of the effective date and the termination date;
- The description of the underlying asset(s);
- The valuation terms;
- The specification of the notional;
- The determination of the equity payoff amount;
- The description of the return terms;
- The notional adjustments conditions;
- The currency exchange terms that can be associated with the equity leg of the swap.
The identification of the payer and receiver party of the equity leg is done similarly to the other types of swaps, through the payerPartyReference and the receiverPartyReference data elements.
The effective date and the termination date are similarly defined for both the interest and equity leg of the trade. Each of these dates can be specified either in reference to a date defined somewhere else in the document (using the relativeDate subcomponent), or as a specific date (using the adjustableDate subcomponent).
The figure 3 presents the effective date as an example of how these two components are structured:
Figure 3: The effectiveDate.
The example 1 below presents how these schema structures are used for defining the effective date of the equity swap as a function of the trade date (the elapse time between these being the settlement cycle of the underlying security assets) and the termination date as a function of the last payment of the swap. This corresponds indeed to the most frequent practice for confiming equity swaps.
Example 1 - Effective date as a function of the trade date and effective date as a function of the last payment date:
- Effective date: 3 business days after the trade date (defined in another part of the document and referred to through the TradeDate reference);
- Termination date: on the last payment date (also defined somewhere else in the document and referred to through the FinalEquityPaymentDate reference).
<effectiveDate id="EffectiveDate">
<relativeDate>
<periodMultiplier>3</periodMultiplier>
<period>D</period>
<dayType>ExchangeBusiness</dayType>
<businessDayConvention>NotApplicable</businessDayConvention>
<dateRelativeTo href="TradeDate"/>
</relativeDate>
</effectiveDate>
<terminationDate id="TerminationDate">
<relativeDate>
<periodMultiplier>0</periodMultiplier>
<period>D</period>
<businessDayConvention>NotApplicable</businessDayConvention>
<dateRelativeTo href="FinalEquityPaymentDate"/>
</relativeDate>
</terminationDate>
The underlyer component provides a detailed description of the characteristic of the underlying asset(s). Seven types of asset classes have been included as part of this release, of which six are actually used by the equity swap. These six underlying types are the convertible bond, the equity, the exchange-traded fund, the future contract, the index and the mutual fund. The seventh one is the bond, that is used by the schema for credit derivatives and will be later used by the schema for trigger swaps once it will be released. Each of these asset types has been defined by extending a component named underlyingAsset that contains some key attributes that are common across most of the underlyers: the identifier, the descriptive name, the currency of denomination, the stock exchange on which the underlyer is listed and the clearance system. With the exception of the identifier element, all these attributes are optional.
Thereafter is the description of these six types of underlyers that are used by the schema for equity swaps. These diagrams also present the respective schemes that have been associated with these components. Not surprisingly, the exchangeId is used quite often.
The equity:
Figure 4: The equity underlyer extends the underlyingAsset component by adding two (optional) elements: the related exchange and the options exchange.
The index:
Figure 5: The index underlyer extends the underlyingAsset component by adding two (optional) elements: the related exchange and the identifier of the reference future contract that may have been referenced as part of the swap contract.
The mutual fund:
Figure 6: The mutual fund underlyer extends the underlyingAsset component by adding two (optional) elements: the indicator of whether the fund is open or closed and the name of the fund manager.
The exchange-traded fund:
Figure 7: The exchange-traded fund underlyer extends the underlyingAsset component by adding three (optional) elements: the related exchange, the options exchange and the name of the fund manager.
The future contract:
Figure 8: The future contract underlyer extends the underlyingAsset component by adding four (optional) elements: the related exchange, the options exchange, the contract multiplier and the specific reference of the future contract that is used as part of the swap.
The convertible bond:
Figure 9: The convertible bond underlyer extends the underlyingAsset component through six elements that characterize the instrument (the related exchange, the issuer name, the coupon rate, the maturity date, the par value and the face amount); in addition, the underlyingEquity component describes the equity underlyer in which the convertible bond can be turned into.
These various types of underlyers can be combined through two different structures, depending upon whether the swap has only one underlyer or has multiple underlying assets: the singleUnderlyer structure or the basket structure. The figure 10 below provides a high-level view of these two alternative structures, which are detailed in the following paragraphs.
Figure 10: Overview of the two alternative types of underlying structured: the singleUnderlyer and the basket.
In the case of a single underlyer, the singleUnderlyer component specifies the number of open units, the description of the underlyer (through the underlyingAsset substitution group) and the dividend payout ratio (which is defined through the underlyer component rather than the return component for reasons that are related to the basket, and that are explained below). It should be noted that the seven members of the underlyingAsset substitution group (bond, convertibleBond, equity, exchangeTradedFund, future, index, mutualFund) do not appear in this diagram: only the basis elements are represented.
Figure 11: The single underlyer.
The basket component is to be applied in the case where there are several underlyers, which are then specifically described through the basketConstituents component. This basket component is structured as follows: an identification of the number of basket units (typically, one) and a description of each of the basket constituents (through a one-to-many relationship).
Figure 12: The basket.
The structure that describes the basket is quite more complex than the one that specifies the single underlyer. Besides defining the number of basket units (typically, one), the structure specifies each of the basket constituents through an asset description, a constituent weight, a dividend payout ratio, a price and a notional description. The underlyingAsset component having been already described, the points below focus on the four latter components:
- The constituentWeight specifies the number of units of each of the basket constituents and, optionally, their respective weight in the basket. It is an optional component, considering that some more exotic types of equity swaps do not have a relative weight associated with each their underlyer components.
- The dividend payout ratio has been associated with the description of the underlyer rather than included in the definition of the return component in order to address the case where a different payout ratio is be associated with the respective components of a basket swap.
- The underlyerPrice component describes the price of each of the basket components; it is optional in order to take into consideration the cases where the market participants do not specify the breakdown by underlyer of the price that is defined at the leg level (which, in the case of a basket swap, corresponds to the notional of the equity leg of the swap). Its structure is based upon the Price complex type, which provides a great flexibility in the way the price of an asset can be defined. This price structure is described in more details through the later developments that are devoted to the valuation component.
- The underlyerNotional is also an optional component; it provides the possibility to break down by underlyer the notional for the equity leg, which can be particularly useful when several currencies are used across the various underlyers.
As an illustration of this structure of the basket component and an introduction to the upcoming developments that are devoted to the valuation, the example below presents the case of a basket swap which underlyers components are listed in various currencies.
Example 2 - Basket swap with underlyers listed in different currencies:
- The basket is comprised of one underlyer that is listed in EUR (TIM.MI) and one that is listed in GBP (VOD.L);
- The reference currency of the swap is USD (this information is carried through the equityAmount component, which is not indicated here);
- Each of the two basketConstituent structures carry the information about both its local price and its price after conversion in USD;
- The information about the currency conversion rates is specified through the valuation component (that is not depicted below), as this information is not specific to the underlyer;
- The initial price of the swap is USD 7,376,406. This corresponds to the multiplication of each of the underlyer prices by its respective quantity, after conversion in USD: 4.182*783,000 [TIM.MI ]+ 165*24,860 [VOD.L]. It also corresponds to the initial notional of the equity swap. This initial price is not depicted here, as it is part of the valuation component of the equity leg.
<underlyer>
<basket>
<openUnits>1</openUnits>
<basketConstituent>
<equity>
<instrumentId instrumentIdScheme="RIC">TIM.MI</instrumentId>
<description>Telecom Italia Mobile spa</description>
<currency>EUR</currency>
<exchangeId exchangeIdScheme="http://www.fpml.org/schemes/4.0/exchangeId">Milan Stock Exchange</exchangeId>
</equity>
<constituentWeight>
<openUnits>783000</openUnits>
</constituentWeight>
<dividendPayout>
<dividendPayoutRatio>85</dividendPayoutRatio>
</dividendPayout>
<underlyerPrice>
<grossPrice>
<currency>EUR</currency>
<amount>4.14</amount>
<priceExpression>AbsoluteTerms</priceExpression>
</grossPrice>
<netPrice>
<currency>USD</currency>
<amount>4.182</amount>
<priceExpression>AbsoluteTerms</priceExpression>
</netPrice>
</underlyerPrice>
<underlyerNotional>
<currency>USD</currency>
<amount>3274506</amount>
</underlyerNotional>
</basketConstituent>
<basketConstituent>
<equity>
<instrumentId instrumentIdScheme="RIC">VOD.L</instrumentId>
<description>Vodafone Group</description>
<currency>GBP</currency>
<exchangeId exchangeIdScheme="http://www.fpml.org/schemes/4.0/exchangeId">London Stock Exchange</exchangeId>
</equity>
<constituentWeight>
<openUnits>24860</openUnits>
</constituentWeight>
<dividendPayout>
<dividendPayoutRatio>85</dividendPayoutRatio>
</dividendPayout>
<underlyerPrice>
<grossPrice>
<currency>GBP</currency>
<amount>110.00</amount>
<priceExpression>AbsoluteTerms</priceExpression>
</grossPrice>
<netPrice>
<currency>USD</currency>
<amount>165.00</amount>
<priceExpression>AbsoluteTerms</priceExpression>
</netPrice>
</underlyerPrice>
<underlyerNotional>
<currency>USD</currency>
<amount>4101900</amount>
</underlyerNotional>
</basketConstituent>
</basket>
</underlyer>
This is probably the most critical component of the equity swap schema, as its role is to describe the initial price upon which the equity swap is based, as well as the terms governing the future valuations of the equity leg.
The valuation component has four main sub-components: one that describes the initial price (initialPrice), one that describes the interim valuation price(s), when applicable (valuationPriceInterim), one that describes the final valuation price (valuationPriceFinal) and one that describes the equity payment dates (equityPaymentDates).
In addition to these quite complex components that will be detailed below, the equityNotionalReset element specifies whether the resets apply to the equity leg of the swap. This is done through a true/false boolean value.
Figure 13: The EquitySwapValuation type, that specifies the valuation terms of the equity leg of the swap.
The following developments present in more details the four main structures that are part of this EquitySwapValuation type: the initialPrice, the valuationPriceInterim, the valuationPriceFinal and the equityPaymentDates. Even if these components can appear quite complex at first glance, the objective here is to outline how they have been based upon a limited set of 'building blocks' that are systematically reused.
The purpose of the initialPrice component is to specify the initial price for the equity underlyer of the trade. In most of the cases, this price will be known. There can however be certain cases, such as a forward trade, where the actual price is not known on trade date and where the trade confirmation will rather specify the terms according to which this initial price will be determined at a later point.
The diagrams 14 and 15 below present the two sets of structures that are used for specifying these various cases: one (mandatory) structure that specifies the price and one (optional) structure that specifies the dates.
Figure 14: The initialPrice component of the valuation, with a specific focus on the part of the structure that specifies the price.
Three possible ways for defining the price of the underlyer are available: as an actual price and currency, in reference to an amount defined somewhere else in the document using the amountRelativeTo element, or by specifying a specific determination method using the determinationMethod component. Commissions can be associated with each of these three alternative definitions. For addressing the requirements related to composite FX swaps, the possibility is also provided, through the fxConversion component, to explicitly define the FX rate that has been used to convert the price from its listing currency to the reference currency of the swap.
Considering that in the vast majority of the cases the initial price is defined as an actual price and currency, the examples below will focus on detailing the various options available for specifying such actual price. The other possibilities offered through the Price type will be further detailed through the interim and final price components.
Example 3 - Specification of an initial price as an actual price that does not include commissions and FX terms:
- Price amount: 37.44;
- Price currency: USD;
- Price expression: in absolute terms (as opposed to as a percentage of the notional);
- There are no commissions nor FX terms associated with the price.
<initialPrice>
<netPrice>
<currency>USD</currency>
<amount>37.44</amount>
<priceExpression>AbsoluteTerms</priceExpression>
</netPrice>
</initialPrice>
Example 4 - Specification of an initial price as an actual price that also includes commissions and FX terms:
- Basket swap, which price at the leg level corresponds to the multiplication of the respective prices and quantities of the various underlyer components, i.e. to the notional of the swap;
- Gross amount: 113,228,777 CAD;
- Net amount: 84,089,141 USD;
- Commission: 5 basis points
- Exchange rate: 1 USD = 1.34665 CAD
- Price expression: in absolute terms (as opposed to as a percentage of the notional);
- There are no commissions nor FX terms associated with the price.
<initialPrice>
<commission>
<commissionDenomination>BPS</commissionDenomination>
<commissionAmount>5</commissionAmount>
</commission>
<grossPrice>
<currency>CAD</currency>
<amount>113228777</amount>
<priceExpression>AbsoluteTerms</priceExpression>
</grossPrice>
<netPrice>
<currency>USD</currency>
<amount>84089141</amount>
<priceExpression>AbsoluteTerms</priceExpression>
</netPrice>
<fxConversion>
<fxRate>
<quotedCurrencyPair>
<currency1>CAD</currency1>
<currency2>USD</currency2>
<quoteBasis>Currency2PerCurrency1</quoteBasis>
</quotedCurrencyPair>
<rate>1.34665</rate>
</fxRate>
</fxConversion>
</initialPrice>
Example 5 - Specification of an initial price as a percentage of the notional, without commissions nor FX terms:
- Price: 94.80278% of the notional amount.
<initialPrice>
<netPrice>
<amount>94.80278</amount>
<priceExpression>PercentageOfNotional</priceExpression>
</netPrice>
</initialPrice>
Figure 15: The initialPrice component of the valuation, with a specific focus on the part of the structure that specifies the date and time of the initial valuation.
This structure that specifies the date and time of the valuation will typically not be used as part of the definition of the initial price. This is because in most cases the initialPrice component specifies the price of the underlyer that is used as the initial reference point for the swap, and there is no need to refer to any specific date or time. Considering that this 'building block is defined and used in a quite similar same way for the interim and final price, it will be detailed through these latter.
The purpose of the valuationPriceInterim component is to specify the interim price(s) for the equity underlyer of the trade. This is an optional component, as it does not apply in the case of a bullet swap, where there is no reset date. Its other specificity vis-a-vis the initial and final valuation components it that this components can hold an array of valuation dates, as opposed to only one valuation date.
Similarly to the initialPrice component, the diagrams 16 and 17 below present the two sets of structures that are part of the valuationPriceInterim component: one structure that specifies the price and one structure that specifies the valuation dates. Both structures are mandatory.
Figure 16: The valuationPriceInterim component of the valuation, with a specific focus on the part of the structure that specifies the price.
Figure 17: The valuationPriceInterim component of the valuation, with a specific focus on the part of the structure that specifies the dates.
The example 6 below is very illustrative of the typical use of the valuationPriceInterim structure for representing the interim valuation prices of an equity swap:
- As part of the Price structure, the determinationMethod node of the choice sequence will be used for specifying how the future prices of the underlyer will be determined;
- The definition of the time of the valuation essentially relies upon the valuationTimeType element, that specifies the time of day at which the Calculation Agent values the underlyer: the valuationTime component, which purpose is to specify an actual valuation time, is expected to be used only in some rare cases;
- Most often, a schedule of valuation dates will be specified, to which the payment schedule will refer.
Example 6 - Typical example of how the valuationPriceInterim component is used to specify the the interim valuation:
- A schedule of 11 interim valuation dates is defined, that extends from October 12, 2001 to August 12, 2002;
- This schedule of dates already takes into consideration the expected exchange holidays. Hence, no business day convention is applicable;
- On each of these valuation dates, the equity underlyer will be valued at the market close.
<valuationPriceInterim>
<determinationMethod>PriceAtValuationTime</determinationMethod>
<valuationTimeType>Close</valuationTimeType>
<equityValuationDates id="InterimValuationDate">
<adjustableDates>
<unadjustedDate>2001-10-12</unadjustedDate>
<unadjustedDate>2001-11-13</unadjustedDate>
<unadjustedDate>2001-12-12</unadjustedDate>
<unadjustedDate>2002-01-14</unadjustedDate>
<unadjustedDate>2002-02-12</unadjustedDate>
<unadjustedDate>2002-03-12</unadjustedDate>
<unadjustedDate>2002-04-12</unadjustedDate>
<unadjustedDate>2002-05-13</unadjustedDate>
<unadjustedDate>2002-06-12</unadjustedDate>
<unadjustedDate>2002-07-12</unadjustedDate>
<unadjustedDate>2002-08-12</unadjustedDate>
<dateAdjustments>
<businessDayConvention>NotApplicable</businessDayConvention>
</dateAdjustments>
</adjustableDates>
</equityValuationDates>
</valuationPriceInterim>
The schema also provides the ability to address some more unusual situations. One of these relates to the case where the valuation dates are defined as a function of the equity payment dates. In such case, a specific consideration needs to be given to the various types of holidays, i.e. banking holidays versus exchange holidays. The relativeDateSequence component does provide such abiliy to define a date as a function of another date by applying a defined sequence of offsets, as opposed to only one offset as in the case of the relativeDate component. This case is illustrated in the example 7 below.
Example 7 - The interim valuation dates are defined in relation to the payment dates:
- The settlement cycle of the underlying equity is 3 business days;
- The valuation date is defined as a function of the payment date. Considering that the payment date happens after the valuation date, a negative value is then specified as the periodMultiplier element;
- In order to give consideration to the situations where the stock exchange is opened on certain banking holidays (e.g. Veteran Day in the United States) and vice-versa, a sequence of offsets is being applied. Considering a settlement cycle of 3 days, a first sequence of 2 currency business days is first applied, and then a sequence of 1 exchange business day. This avoids a situation where an offset of 3 currency business days could lead to specifying a valuation date that corresponds to an exchange business day.
- Considering that the first offset sequence of 2 business days applies to currency business days, the ISDA business day convention is applicable; it is not applicable for the second offset sequence, which refers to exchange business days.
<equityValuationDates id="InterimValuationDates">
<relativeDateSequence>
<dateRelativeTo href="InterimEquityPaymentDate"/>
<!--The first offset is 2 exchange business days prior to the payment date.-->
<dateOffset>
<periodMultiplier>-2</periodMultiplier>
<period>D</period>
<dayType>CurrencyBusiness</dayType>
<businessDayConvention>FOLLOWING</businessDayConvention>
<sequence>1</sequence>
</dateOffset>
<!--The second offset is 1 banking business day prior to the payment date.-->
<dateOffset>
<periodMultiplier>-1</periodMultiplier>
<period>D</period>
<dayType>ExchangeBusiness</dayType>
<businessDayConvention>NotApplicable</businessDayConvention>
<sequence>2</sequence>
</dateOffset>
<businessCenters id="PrimaryBusinessCenter">
<businessCenter>USNY</businessCenter>
</businessCenters>
</relativeDateSequence>
</equityValuationDates>
The example 8 below provides another example of an unusual definition of the interim valuation date. Here, the valuation dates are defined through a rule-based schedule, which corresponds to the market practice typically in use for fixed income swaps. This practice is however used only rarely in the case of equity derivatives.
Example 8 - The interim valuation dates are defined through a rule-based schedule:
- The underlyer is valued at the market close on each of the interim valuation dates;
- The final valuation is based on the price obtained by the payer of the equity return when unwinding his hedge position;
- The first valuation date is April 10, 2002;
- Each of the following valuations is scheduled on the 10th of each month, until the last valuation date which is scheduled on March 12, 2003;
- The business day convention is not applicable, because the terms 'Modified Following', 'Following', 'Preceding', etc. are not recognised ISDA terms in the context of exchange business days. On the other hand, the ISDA Definition for Equity Derivatives is, by default, to roll forward if a scheduled valuation date is not a exchange business day.
<valuationPriceInterim>
<determinationMethod>Valuation time</determinationMethod>
<valuationTimeType>Close</valuationTimeType>
<equityValuationDates id="InterimValuationDates">
<periodicDates>
<calculationStartDate>
<adjustableDate>
<unadjustedDate>2002-04-10</unadjustedDate>
<dateAdjustments>
<businessDayConvention>NotApplicable</businessDayConvention>
</dateAdjustments>
</adjustableDate>
</calculationStartDate>
<calculationPeriodFrequency>
<periodMultiplier>1</periodMultiplier>
<period>M</period>
<rollConvention>10</rollConvention>
</calculationPeriodFrequency>
<calculationPeriodDatesAdjustments>
<businessDayConvention>NotApplicable</businessDayConvention>
</calculationPeriodDatesAdjustments>
</periodicDates>
</equityValuationDates>
</valuationPriceInterim>
<valuationPriceFinal>
<determinationMethod>HedgeUnwind</determinationMethod>
<equityValuationDate id="FinalValuationDate">
<adjustableDate>
<unadjustedDate>2003-03-12</unadjustedDate>
<dateAdjustments>
<businessDayConvention>NotApplicable</businessDayConvention>
</dateAdjustments>
</adjustableDate>
</equityValuationDate>
</valuationPriceFinal>
The purpose of the valuationPriceFinal component is to specify the final price for the equity underlyer of the trade.
In a similar way than what has been previously detailed for the components that specify the initial and the intermediate valuations, the diagrams 18 and 19 below respectively detail the structure that specifies the final price and the structure that specifies the date on which this valuation will take place. Both structures are mandatory.
Figure 18: The valuationPriceFinal component of the valuation, with a specific focus on the part of the structure that specifies the price.
Figure 19: The valuationPriceFinal component of the valuation, with a specific focus on the part of the structure that specifies the final valuation date.
It can be noted at this point that the only difference between this valuationPriceFinal component and the valuationPriceInterim component is that only one final valuation date can be specified, while the possibility is provided to define several interim valuation dates. The equityValuationDates component used for specifying the interim valuation dates has then been substituted with the equityValuationDate component, which allows only one date.
The example 8 below presents the most common use of this structure, a specific final valuation date being defined while the final price is specified through the use of the determinationMethod element. Of course, if the interim valuation dates would be defined in reference to the payment dates (as illustrated in the example 7) or through a rule-based schedule (example 8), such method would also be applied for defining the final valuation date.
Example 9 - The most common definition of the final valuation:
- The final price of the equity underlyer will correspond to the price at which the payer of the equity leg will unwind his hedge position;
- A commission of 60 basis points will be applied to this price;
- The final valuation date is February 3, 2004;
- In accordance to the market practice, this date has been determined by the Calculation Agent as corresponding to an exchange business day. As previously indicated, the terms 'Modified Following', 'Following', 'Preceding', etc. are not recognised ISDA terms in the context of exchange business days.
<valuationPriceFinal>
<commission>
<commissionDenomination>BPS</commissionDenomination>
<commissionAmount>60</commissionAmount>
</commission>
<determinationMethod>HedgeUnwind</determinationMethod>
<equityValuationDate id="FinalValuationDate">
<adjustableDate>
<unadjustedDate>2004-02-03</unadjustedDate>
<dateAdjustments>
<businessDayConvention>NotApplicable</businessDayConvention>
</dateAdjustments>
</adjustableDate>
</equityValuationDate>
</valuationPriceFinal>
The last structure that participates in the definition of the equity swap valuation is the schedule of equity payment dates. These dates are specified through the equityPaymentDates component. The structure of this component is threefold:
- An Identifier is associated to the equityPaymentDates root component, in order to allow to specify a generic reference to these payment dates. This unique reference to the payment dates is used through the dividend component, when it is specified that the dividend will be paid on the next equity payment date (see below the section related to the return component of the equity leg);
- The equityPaymentDatesInterim component specifies the interim payment dates of the swap. It is optional to address the case of bullet swaps that do not have interim equity resets;
- The equityPaymentDateFinal component specifies the final payment date.
Figure 20: The equityPaymenDate component, that specifies the schedule of equity payment dates.
The structure of the equityPaymentDatesInterim and the equityPaymentDateFinal is very similar. The only difference is that several dates can be specified in the first case, and only one date in the latter.
As a result, both the interim and the final payment dates can be defined either as a schedule of dates or in reference to a date defined somewhere else in the document. This latter approach is used most often, with the equity payment dates being specified as one settlement cycle after the valuation date to which they relate. This is illustrated through this final example relating to the valuation component, which provides a complete view of how the valuation dates are defined as an actual schedule of dates to which the payment dates refer.
Example 10 - Equity swap which payment dates are defined in relation to the schedule of valuation dates:
- The initial price of the swap is USD 37.44;
- A schedule of 12 valuation dates is defined: 11 interim valuation dates (from October 12, 2001 to August 12, 2001) and 1 final valuation date (September 24, 2002);
- The equity underlyer is to be valued at the market close on each of the interim valuation dates. Its final valuation will correspond to the price at which the payer of the equity return unwinds his hedge;
- The equity payment dates are scheduled 3 currency business days after each of the valuation dates. Considering that these are currency business days, as opposed to exchange business days, the 'Following' business day convention is specified, New York being the reference business center.
<valuation>
<initialPrice>
<netPrice>
<currency>USD</currency>
<amount>37.44</amount>
<priceExpression>AbsoluteTerms</priceExpression>
</netPrice>
</initialPrice>
<equityNotionalReset>true</equityNotionalReset>
<valuationPriceInterim>
<determinationMethod>PriceAtValuationTime</determinationMethod>
<valuationTimeType>Close</valuationTimeType>
<equityValuationDates id="InterimValuationDate">
<adjustableDates>
<unadjustedDate>2001-10-12</unadjustedDate>
<unadjustedDate>2001-11-13</unadjustedDate>
<unadjustedDate>2001-12-12</unadjustedDate>
<unadjustedDate>2002-01-14</unadjustedDate>
<unadjustedDate>2002-02-12</unadjustedDate>
<unadjustedDate>2002-03-12</unadjustedDate>
<unadjustedDate>2002-04-12</unadjustedDate>
<unadjustedDate>2002-05-13</unadjustedDate>
<unadjustedDate>2002-06-12</unadjustedDate>
<unadjustedDate>2002-07-12</unadjustedDate>
<unadjustedDate>2002-08-12</unadjustedDate>
<dateAdjustments>
<businessDayConvention>NotApplicable</businessDayConvention>
</dateAdjustments>
</adjustableDates>
</equityValuationDates>
</valuationPriceInterim>
<valuationPriceFinal>
<determinationMethod>HedgeUnwind</determinationMethod>
<equityValuationDate id="FinalValuationDate">
<adjustableDate>
<unadjustedDate>2002-09-24</unadjustedDate>
<dateAdjustments>
<businessDayConvention>NotApplicable</businessDayConvention>
</dateAdjustments>
</adjustableDate>
</equityValuationDate>
</valuationPriceFinal>
<equityPaymentDates id="EquityPaymentDate">
<equityPaymentDatesInterim id="InterimEquityPaymentDate">
<relativeDates>
<periodMultiplier>3</periodMultiplier>
<period>D</period>
<dayType>CurrencyBusiness</dayType>
<businessDayConvention>FOLLOWING</businessDayConvention>
<businessCenters id="PrimaryBusinessCenter">
<businessCenter>USNY</businessCenter>
</businessCenters>
<dateRelativeTo href="InterimValuationDate"/>
</relativeDates>
</equityPaymentDatesInterim>
<equityPaymentDateFinal id="FinalEquityPaymentDate">
<relativeDate>
<periodMultiplier>3</periodMultiplier>
<period>D</period>
<dayType>CurrencyBusiness</dayType>
<businessDayConvention>FOLLOWING</businessDayConvention>
<businessCentersReference href="PrimaryBusinessCenter"/>
<dateRelativeTo href="FinalValuationDate"/>
</relativeDate>
</equityPaymentDateFinal>
</equityPaymentDates>
</valuation>
The notional component specifies the notional of each of the legs of the swap (it is indeed also present in the interest leg of the trade). Similarly to the price of the underlyer, three possible ways of defining this notional are available:
- By specifying an actual amount and currency. This is used most often for the equity leg of the swap;
- By referencing an amount specified somewhere else in the document. This is typically the case of the interest leg of the swap, which notional refers to notional specified through equity leg;
- By specifying a determination method, using the determinationMethod component This is typically useful for forward swaps, which notional is not known on trade date.
Figure 21: The notional component.
The three examples below illustrate each of these cases mentioned before:
Example 11 - The explicit notional amount:
- This approach is typically used for specifying the notional of the equity leg of the swap;
- The identifier attribute associated with the notional element is used so that the notional of the interest leg can refer to it (example 12 below).
<notional id="EquityNotionalAmount">
<notionalAmount>
<currency>USD</currency>
<amount>28469376</amount>
</notionalAmount>
</notional>
Example 12 - The reference to a notional defined somewhere else in the document:
- This approach is typically used for specifying the notional of the interest leg of the swap;
- The relationship with the notional amount specified in the equity leg is established via the href, which refers to the value specified through the identifier associated with the explicit notional amount.
<notional>
<amountRelativeTo href="EquityNotionalAmount"/>
</notional>
Example 13 - The use of the determinationMethod for specifying the notional amount:
- The initial price of the equity underlyer is not known on trade inception: it will be determined at a later point;
- As a consequence, only the method through which the notional is calculated is specified as part of the swap.
<notional id="EquityNotionalAmount">
<determinationMethod>Number of Shares * Initial Price</determinationMethod>
</notional>
The main purpose of the equityAmount component is to specify the method that determines the equity amount to be paid/received on each of the equity payment dates. Its role however goes quite beyond this, as it also specifies:
- Whether the swap will cash settle of physically settle;
- The settlement currency of the equity leg of the swap.
Figure 22: The equityAmount component.
This equityAmount component is based on the LegAmount type that is also used for defining the interestAmount. It extends this type by adding a boolean cashSettlement element that specifies whether the swap will cash or physically settle.
The paymentCurrency is the first component of this structure. It specifies the payment currency of the equity leg of the swap through three possible methods:
- As an actual ISO currency code;
- As a determination method description, applicable in the case of some exotic swap where the payment currency of the trade will be a function of certain parameters;
- Through the reference to a currency defined somewhere else in the document, as in the case of a quanto swap or a composite FX swap which reference currency is specified through the fxTerms component.
The core of the equityAmount component is its second component, which specifies the payoff of the equity leg. This can done in three possible ways:
- The referenceAmount element is aimed at holding the reference to the standard ISDA definition of the equity amount. (It can however be used beyond this sole purpose, as it is defined as a string element, without any specific enumerations;
- The formula component is aimed at the exotic equity swaps, which equity payoff needs to be described through a mathematical formula. To meet this purpose, the formula component provides a flexible structure for describing the equity payoff, using the combination of the formulaDescription component that provides a literary description of the payoff, the math container that uses the xsd:any XML structure to hold any type of formula description, and the formulaComponent element that describes the various components of the formula.
- As an alternative to the XML representation of each of the details of the equity payoff, the encodedDescription element provides the ability to encode an image that describes the payout formula, using a base64Binary structure.
The optional calculationDates component is also aimed at these more complex equity swaps. It provides the possibility to define calculation dates (such as observation points in the case of an equity payoff that is a function of some specific market levels). These calculation dates can be specified similarly to the valuation dates:
- As an actual schedule of dates, using the adjustableDates component;
- In relation to some dates defined elsewhere in the document, using the relativeDateSequence component;
- Through a rule-based schedule, using the periodicDates component.
Figure 23: The calculationDates component, that provides the opportunity to define calculation dates for more exotic types of equity swaps.
Example 14 - The use of the equityAmount component for a vanilla equity swap:
- The payment currency of the equity leg is USD;
- The payoff amount of the equity leg is specified as the ISDA standard definition, i.e. equal to the product of the equity notional amount and the rate of return;
- The settlements will be made in cash.
<equityAmount>
<paymentCurrency id="EquityPaymentCurrency">
<currency>USD</currency>
</paymentCurrency>
<referenceAmount>ISDA Standard</referenceAmount>
<cashSettlement>true</cashSettlement>
</equityAmount>
The return component encapsulates the information that defines the dividend to be paid to the receiver of the equity amounts, with the exception of the dividend payout ratio, that is specified through the underlyer component. (As explained earlier, this is because a specific payout ratio can be associated with each underlyer component in the case of basket swaps; such situation can typically be related to different tax regimes across countries when those various underlyers originate from different market places.)
Figure 24: The return component.
This return component has two sets of element: the returnType element, that specifies (through an enumeration) whether the contract is a total return swap, a price return swap or a dividend return swap, and the dividendConditions component, which describes the various conditions applicable to the dividend, including whether and how interests will be accrued if they are paid after the dividend pay date. This second component is optional, as it does not apply in the case of a price return swap. Its dividend terms are the following:
-
The dividendReinvestment, as a Boolean data element that determines whether the dividend will be reinvested into the equity notional;
-
The dividendEntitlement, to indicate when the counterparty is entitled to the dividend;
-
The dividendPaymentDate, to specify when the dividend will be paid. This date can be specified either through a set of pre-defined values that are associated with the dividendDateReference element that is part of this component, or as a specific date. These pre-defined values can refer either to dividend dates (ExDate, DividendPaymentDate, RecordDate) or to dates that relate to the swap contract (TerminationDate, EquityPaymentDate, FollowingPaymentDate);
-
The dividendPeriodEffectiveDate and the dividendPeriodEndDate, to indicate when the swap is considered as active from the perspective of dividend processing and when such period ends;
-
The dividendFxTriggerDate, to specify the date on which the FX rate will be considered in the case of a Composite FX swap;
-
The interestAccruals, to define how interests will be accrued on the dividend when this latter is paid some period of time after the dividend payment date.
The notionalAdjustments component specifies whether the adjustment to the equity notional of the swap will obey to certain specific terms. These terms can be, according to the current industry practice, threefold: standard, execution and portfolio rebalancing. An execution-style swap is a trade where the quantity of underlyers is expected to vary quite often; in order to facilitate these later 'executions', the parties agree in advance on contractuals terms that will facilitate these expected adjustments to the contract. A portfolio-rebalancing swap is a trade where the basket components will be often adjusted not only in terms of quantities but also in terms of types of underlyers; similarly to the previous case, some specific language will typically accomodate such adjustments.
These legal terms are however not specified through the schema representation of the equity swap. There are two reasons for this. The first one is that they are not part of the ISDA Definitions for Equity Derivatives. The second reason is that this current version of the equity swap schema is focused on representing the economic description of the trade. These legal terms are then not part of it.
The fxTerms is an optional component that specifies the FX conversion terms that can be associated with the swap. These FX terms can either be Quanto or Composite FX. Both these components include a referenceCurrency element, which purpose is to explicitly state the reference currency of the swap.
Figure 25: The quanto component.
The quanto component includes an explicit reference to a rate, through the quantoRate element. One or several rates can be defined, in order to address the case where a basket swap is composed of several underlyers that are listed in different currencies.
The example below illustrates the application of this quanto component:
Example 15 - The quanto component:
- The business background for this trade is that the payment currency of the swap is USD, while some of the underlyers are listed in EUR and some others are listed in HKD. The payer of the equity return commits upfront to a set of exchange rates vis-a-vis the USD which are specified as part of the quanto component;
- The EUR is quoted per units of USD and the exchange rate is 0.99140;
- The HKD is also quoted per units of USD and the exchange rate is 7.80.
<fxTerms>
<quanto>
<referenceCurrency id="ReferenceCurrency">USD</referenceCurrency>
<fxRate>
<quotedCurrencyPair>
<currency1>USD</currency1>
<currency2>EUR</currency2>
<quoteBasis>Currency2PerCurrency1</quoteBasis>
</quotedCurrencyPair>
<rate>0.99140</rate>
</fxRate>
<fxRate>
<quotedCurrencyPair>
<currency1>USD</currency1>
<currency2>HKD</currency2>
<quoteBasis>Currency2PerCurrency1</quoteBasis>
</quotedCurrencyPair>
<rate>7.80</rate>
</fxRate>
</quanto>
</fxTerms>
Figure 26: The compositeFx component.
The compositeFx component provides the framework for defining a currency rate at some point in the future. This can be done either by defining a generic method using the determinationMethod component (for example, when it is agreed that the exchange rate will be determined "in good faith by the Calculation Agent") or by specifying the information source and fixing time and date reference that will be used for defining this exchange rate, using the fxDetermination component.
The example below illustrates the application of this compositeFx component:
Example 16 - The compositeFx component:
- The payment currency of the swap is EUR;
- The exchange rate will be determined in good faith by the Calculation Agent.
<fxTerms>
<compositeFx>
<referenceCurrency id="ReferenceCurrency">USD</referenceCurrency>
<determinationMethod>GoodFaith</determinationMethod>
</compositeFx>
</fxTerms>
The interest leg of the equity swap leverages for the most part the schema developed for the interest rate swaps.
However, instead of simply reusing the entire swapStream, the interest rate leg of the equity swap schema reuses certain of the components that are part of this swapStream.
This design approach is motivated by the differences in market practices that exist between the equity and fixed income products. The industry practice for the equity swaps consists in defining a schedule of actual dates for the equity valuation, while most of the other swap dates are defined in reference to this schedule. The practice in place in the interest rate area consists, on the other hand, in defining a rule-based schedule. As a result, the swapStream features are largely focused on defining such periodicity rules along with the appropriate calendar exceptions, and do not provide the possibility for defining a complete schedule of actual dates (if we except through the firstPeriodStartDate, the firstRegularPeriodStartDate and the lastRegularPeriodEndDate) and references to these.
Instead of leveraging the whole swapStream component, the interest leg of the equity swap leverages then components at a more granular level, such as the resetFrequency component, the interestCalculation component and the calculationPeriodDatesReference element.
As a result, the interest leg of the equity swap has five categories of components, which are presented in the figure 27 below and respectively specify the following features of the interest leg:
- The payer and the receiver party;
- The calculation dates;
- The notional amount;
- The interest amount;
- The interest calculation.
Figure 27: The interest leg of the equity swap.
The identification of the payer and receiver party of the equity leg is done similarly than for the equity leg of the swap, through the payerPartyReference and receiverPartyReference data elements.
The interestLegCalculationPeriodDates component defines the various dates associated with the interest leg of the swap:
- The effective date, through the effectiveDate component, also used for the equity leg of the swap;
- The termination date, through the terminationDate component that is also similar to the equity leg;
- The reset dates, via the interestRateResetDates component;
- The payment dates, through the interestRatePaymentDates component.
The diagram below presents the key features of these different date structures. Three of these components are structured in the same way: the effectiveDate, the terminationDate and the interestRatePaymentDates. These components indeed all provide the possibility to define a date (or several dates, in the case of the interestRatePaymentDates component) as either an actual date or in reference to a date specified somewhere else in the document.
The interestRateResetDates component has been developed as a simplified version of the ResetDates type that is part of the interest rates derivatives schema. Three of the seven components that are part of this ResetDates type have indeed been reused:
- The calculationPeriodDatesReference is an empty element that holds an href into the identifier attribute that is associated with the interestLegCalculationPeriodDates;
- The resetRelativeTo specifies whether the reset dates are determined with respect to each adjusted calculation period start date or adjusted calculation period end date;
- The resetFrequency component provides the possibility to define a specific reset frequency, instead of defining the reset in relation to the various interest calculation dates: the effective date, the respective interest payment dates and the termination date.
Figure 28: The interestLegCalculationPeriodDates component.
The example below presents a typical example of how this schema is applied to the standard interest leg of an equity swap:
Example 17 - The calculation period dates of the interest leg of an equity swap:
- The effective date is defined similarly than for the equity leg, as one settlement cycle following the trade date;
- The termination date is also defined in the same way than the equity leg, as corresponding to the last equity payment date;
- The reset dates for the floating rate are defined as corresponding to the first day of each of the calculation periods by referencing the identifier that is associated with the interestLegCalculationPeriodDates node;
- The interest payment dates are specified in reference to the equity payment dates: this is called a combined reset, as a net amount corresponding to the difference between the interest and the equity amount will be exchanged on each payment date.
<interestLegCalculationPeriodDates id="InterestLegPeriodDates">
<effectiveDate>
<relativeDate>
<periodMultiplier>3</periodMultiplier>
<period>D</period>
<dayType>ExchangeBusiness</dayType>
<businessDayConvention>NotApplicable</businessDayConvention>
<dateRelativeTo href="TradeDate"/>
</relativeDate>
</effectiveDate>
<terminationDate>
<relativeDate>
<periodMultiplier>0</periodMultiplier>
<period>D</period>
<businessDayConvention>NotApplicable</businessDayConvention>
<dateRelativeTo href="FinalEquityPaymentDate"/>
</relativeDate>
</terminationDate>
<interestLegResetDates>
<calculationPeriodDatesReference href="InterestLegPeriodDates"/>
<resetRelativeTo>CalculationPeriodStartDate</resetRelativeTo>
</interestLegResetDates>
<interestLegPaymentDates>
<relativeDates>
<periodMultiplier>0</periodMultiplier>
<period>D</period>
<businessDayConvention>NotApplicable</businessDayConvention>
<dateRelativeTo href="EquityPaymentDate"/>
</relativeDates>
</interestLegPaymentDates>
</interestLegCalculationPeriodDates>
The notional amount is defined through the same structure than for the equity leg of the swap: the notional component. As mentioned earlier, and illustrated through the example 12, this component is most often used for referencing the notional amount that is defined as part of the equity leg.
The interest amount is defined in the same way than the equity amount: using the LegAmount complex type. Used through the interest leg, it specifies the following elements:
- The settlement currency of the interest leg of the swap;
- The interest amount of the swap, either by referencing the standard ISDA Definition or by describing a very specific formula.
Example 18 - The interest amount of an equity swap:
- This example illustrates a swap that has FX terms which are referenced through the fxTerms component that is part of the equity leg. An identifier is associated with the reference currency that is defined as part of that component, and the href that is part of the paymentCurrency element refers to this identifier;
- The interest amount is specified by reference to the ISDA Equity Derivatives Definitions.
<interestAmount>
<paymentCurrency href="ReferenceCurrency"/>
<referenceAmount>Standard ISDA</referenceAmount>
</interestAmount>
The interestCalculation component specifies the interest rate reference of the swap (by referring either to a fixed interest rate or to a floating reference rate) and the day count fraction to be applied. As indicated in the introduction to the interest leg section, this structure has been developed by leveraging the components defined for the interest rate swap schema.
Figure 29: The interestCalculation component.
The example below presents a typical example of how this interestCalculation component can be applied for specifying the floating rate of an equity swap:
Example 19 - Specifying the floating rate of an equity swap:
- The reference rate is 3 month USD-LIBOR-BBA;
- The spread is plus 50 basis points;
- The day count fraction is actual number of days / 360 days.
<interestCalculation>
<floatingRateCalculation>
<floatingRateIndex>USD-LIBOR-BBA</floatingRateIndex>
<indexTenor>
<periodMultiplier>3</periodMultiplier>
<period>M</period>
</indexTenor>
<spreadSchedule>
<initialValue>0.0050</initialValue>
</spreadSchedule>
</floatingRateCalculation>
<dayCountFraction>ACT/360</dayCountFraction>
</interestCalculation>
Some types of equity swaps do not have an interest leg. Their economic structure relies instead in the exchange of the principal of the swap between the parties. These are the fully funded and zero-strike swaps. The purpose of the PrincipalExchangeFeatures component is to specify this feature that is associated with those swaps. (It should however be noted that the schema also accomodates some more exotic cases that would combine an interest leg which notional would be smaller than the notional of the equity leg, and that would also have a principal exchange.)
Figure 30: The exchange of principal amounts.
This component extends the design developed for the interest rate swaps (through the principalExchanges component) by adding the PrincipalExchangeDescriptions component, which has the following features:
- It specifies the payer and receiver party references;
- The date of each of the principal exchanges can be defined either as an actual date (using the adjustableDate component) or in relation to a date defined somewhere else in the document (via the relativeDate component);
- The principal exchange amount can be defined in three possible ways: (i) By pointing to an amount defined elsewhere in the swap document, through the use of the amountRelativeTo element; (ii) By using the determinationMethod element, that describes a method according to which an amount is determined; (iii) By using the principalAmount component, which allows to explicitly determine an actual amount.
Example 20 - Initial principal exchange:
- The principal exchange takes place at the initial period of the swap;
- The payment date is defined as being the effective date of the swap;
- The amount paid to Party A is USD 55,911.60.
<principalExchangeFeatures>
<principalExchanges>
<initialExchange>true</initialExchange>
<finalExchange>false</finalExchange>
<intermediateExchange>false</intermediateExchange>
</principalExchanges>
<principalExchangeDescriptions>
<payerPartyReference href="PartyB"/>
<receiverPartyReference href="PartyA"/>
<principalExchangeAmount>
<principalAmount>
<currency>USD</currency>
<amount>55911.60</amount>
</principalAmount>
</principalExchangeAmount>
<principalExchangeDate>
<relativeDate>
<periodMultiplier>0</periodMultiplier>
<period>D</period>
<businessDayConvention>NotApplicable</businessDayConvention>
<dateRelativeTo href="EffectiveDate"/>
</relativeDate>
</principalExchangeDate>
</principalExchangeDescriptions>
</principalExchangeFeatures>
Similarly to the principal exchange, the EquitySwapAdditionalPayment complex type extends the design developed for the interest rate swaps by providing the ability to define dates in relation to other dates, as well as to specify the calculation logic that supports certain types of fees.
Figure 31: The additionalPayment component.
This additionalPayment structure leverages some of the features that are also used through other components:
- The payer and receiver parties are specified similarly to the swap legs and the principal exchange, through the payerPartyReference and receiverPartyReference elements;
- The additionalPaymentAmount component provides the flexibility to define an actual amount (through the paymentAmount component) and/or to describe the methodology for determining such amount, leveraging the fomula component developed for the LegAmount complex type;
- Similarly to the PrincipalExchangeFeatures component, the date of each of the additional payments can be defined either as actual dates or in relation to dates defined somewhere else in the document, through respectively the adjustableDate and the relativeDate components;
- The optional paymentType string element provides the opportunity to characterize the additional payment.
Example 21 - Upfront fee:
- An upfront fee is parid by Party A to Party B, on the effective date of the swap;
- This upfront fee is equal to: 18388000 * Reference Price * [6.5% (the upfront Fee) + 0.63% (taxes)].
<additionalPayment>
<payerPartyReference href="PartyA"/>
<receiverPartyReference href="PartyB"/>
<additionalPaymentAmount>
<formula>
<formulaDescription>18388000 * Reference Price * [6.5% (the upfront Fee) + 0.63% (taxes)]</formulaDescription>
<math>
<mn>18388000 </mn>
<mo>*</mo>
<mi>ReferencePrice</mi>
<mo>*</mo>
<mo>(</mo>
<mn>6.5</mn>
<mo>%</mo>
<mo>+</mo>
<mn>0.63</mn>
<mo>%</mo>
<mo>)</mo>
</math>
<formulaComponent name="ReferencePrice">
<componentDescription>Volume-weighted average price per share of underlying security on Trade Date</componentDescription>
</formulaComponent>
</formula>
</additionalPaymentAmount>
<additionalPaymentDate>
<relativeDate>
<periodMultiplier>0</periodMultiplier>
<period>D</period>
<businessDayConvention>NotApplicable</businessDayConvention>
<dateRelativeTo href="EffectiveDate"/>
</relativeDate>
</additionalPaymentDate>
<paymentType>Upfront fee</paymentType>
</additionalPayment>
The purpose of the equitySwapEarlyTermination component is to specify the date from which each of the parties to the trade may have the right to terminate it early. The figure 30 below presents the structure of this component:
Figure 32: The earlyTermination component.
Similarly to the other date-related components that are part of the equity swap, the date can be specified using either the adjustableDate component or the relativeDate component. Considering that the standard market practice is to provide the ability for both the parties to the trade to early terminate it starting on Trade Date, the relativeDate element should be used most often. This is illustrated in the example below.
Example 22 - Each of the parties have the right to early terminate the trade starting on Trade Date:
<earlyTermination>
<partyReference href="PartyA"/>
<startingDate>
<dateRelativeTo href="TradeDate"/>
</startingDate>
</earlyTermination>
<earlyTermination>
<partyReference href="PartyB"/>
<startingDate>
<dateRelativeTo href="TradeDate"/>
</startingDate>
</earlyTermination>
Type: Schema Revision
Refers to: all schema files.
Description: As a result of the change of global to local elements in the previous draft, there was considerable redundant information in the schema files, i.e. the same elements were defined repeatedly. The following types were factored out to minimize redundancy, and improve maintainability and readability in the schema files.
Rationale: minimize redundancy, and improve maintainability and readability in the schema files.
- Most "href" attributes were factored out by defining types including PartyReference, NotionalReference, DateReference, etc.
- DateRelativeTo was factored out as a type
- AmountRelativeTo was factored out as a type
- Types were defined for remaining schemes, to simplify the schemas.
- Redundant documentation was deleted.
Type: Schema Revision
Refers to: all fpml-shared-4-0.xsd and most example files.
To reduce redundancy, the element content of the dateRelativeTo element has been eliminated. Instead, users should use the href target to determine the date to which this one is relative. There have been some related changes:
- The id targeted for CashSettlementPaymentDate has been moved down to the appropriate component, affecting the IRD schema and a couple of examples (#17-19).
- The id targeted for MandatoryEarlyTermination has been moved down to the appropriate component, affecting the IRD schema and one example (#16).
Type: Schema Revision
Refers to: all schema files.
To reduce the redundancy in the schema files and improve the consistency in the documentation, a new structure has been introduced in the schema files. The xsd:group structure allows a set of components to be included into a number of element or type definitions. It allows factoring out of repeated elements without changing the structure of the instance documents. This structure has been used for the following:
- payerPartyReference and receiverPartyReference, used in a number of places in the schema.
- buyerPartyReference and sellerPartyReference, used in a number of places in the schema.
- businessCenters or businessCentersReference, used in several places in the schema.
Type: Schema Revision
Refers to: fpml-main-4-0.xsd, fpml-msg-4-0.xsd, FX Example #10, messaging examples.
Description: The tradeIdScheme and messageIdScheme attibutes have been made "required", and the few examples that did not already have these have been updated accordingly.
Rationale: These schemes cannot be defaulted and therefore must be identified.
Type: Schema Revision
Refers to: fpml-ird-4-0.xsd, fpml-enum-4-0.xsd, IR Example #8
Description: The fraDiscounting element has been changed from a boolean to an enumeration, to support AFMA discounting conventions.
Type: Schema Revision
Refers to: fpml-ird-4-0.xsd
Description: An optional premium element has been added to allow a premium to be specified.
Type: Schema Revision
Refers to: fpml-shared-4-0.xsd, fpml-eqs-4-0.xsd, fpml-fx-4-0.xsd
Description: These three types were refactored to provide a consistent treatment of Fx conversions across asset classes. This resulted in the following changes:
- informationSource in FxSpotRateSource became primaryRateSource, and an optional secondaryRateSource was added. This affected some IRD examples with FX-linked notionals.
- FxDetermination was eliminated and replaced by FxSpotRateSource, which now has identical content to the old FxDetermination.
- FxFixing is now an extension of FxSpotRateSource. This changed the order of two elements, quotedCurrencyPair and fixingDate, and affected some FX examples with non-deliverable characteristics.
Type: Schema Revision
Refers to: fpml-eqd-4-0.xsd, examples
Description: There were a number of element and attribute names beginning with FX that were changed to follow the FpML conventions, ie. to start with "fx".
Rationale: consistency, following standards
- fxFeature
- fxFeatureType
- fxFeatureTypeScheme
- fxRate
- fxSource
Type: Schema Revision
Refers to: fpml-eqd-4-0.xsd, scheme definitions, examples
Description: There were a number of schemes that were either not defined or not defaulted. Some of these have been converted to enumerations, while others have been supplied. In some cases this slightly affected examples.
Rationale: Support validation.
- DayOfWeek scheme
- AveragingInOut scheme
- FrequencyTypeScheme
- FrequencyType
- MarketDisruption scheme
- FXFeatureTypeScheme
Type: Schema Revision
Refers to: fpml-eqs-4-0.xsd
Description: There have been a number of changes to the EQS schema, to:
- Extend its coverage to the trigger swaps;
- Improve its clarity as well as its applicability;
- Conform to the FpML standard.
- The DividendPaymentDate type has been simplified by replacing the dateRelativeTo node with an extension of the enumerations associated with the dividendDateReference element.
- The following enumeration values have been added to the DividendDateReferenceEnum that is associated with this dividendPaymentDate component: TerminationDate (the dividend is paid on the termination date of the swap), NextPaymentDate (the dividend is paid on the following payment date of the swap) and EquityPaymentDate (the dividend is paid on the following equity payment date of the swap).
- A 'trigger' node has been added to the equityLeg of the swap, that defines the trigger either as a cap or as a floor. This structure leverages the Trigger type that was defined through the EQD schema.
- In relation to the change for adding the trigger node, an optional activeLegStatus element has been added to each of the swap legs that provides the ability to position a leg into an 'inactive' status until the trigger is activated (in a previous draft versiom, this had been done through an attribute). This element will be present in the case of a trigger swap (even if someone could argue that there is nothing in the schema to enforce this).
- The Price complex type has been adjusted by having a currency element for both the grossPrice and the netPrice, instead of having a currency element across these two elements. This will provide more flexibility in case of FX terms, by allowing to express the gross price in the local currency and the net price in the reference currency of the swap. Also, in order to comply with the FpML design standards, the 'percentage' attribute has been eliminated and replaced with a 'priceExpression' element that contains two enumeration values that have been created through the new PriceExpressionEnum simple type: AbsoluteTerms and PercentageOfNotional. In conjunction with both these changes, a complex type called ActualPrice has been created that encapsulates these features.
- The basket component has been further specified by adding two optional components, that respectively specify the price and the notional of each of the underlying components. The purpose here is to provide the opportunity to have more specific information when confirming the trade. As indicated in the comments describing these two components, they are not required for specifying the economic of the trades, considering that the price and the notional that characterize the swap are positioned at the leg level. This is an optional set of supplemental information.
Besides these changes, we have taken the opportunity of the suppression of the global elements for improving the clarity of the schema by removing whenever possible the 'equitySwap' prefix that had been introduced in order to avoid name clashes with other global elements that had been defined with a different structure. Here are these elements which name has been simplified:
- The naming of the element equitySwapEffectiveDate has been changed to effectiveDate;
- The naming of the element equitySwapTerminationDate has been changed to terminationDate;
- The naming of the element equitySwapNotional has been changed to notional. In relation to this change, the optional choice node that contains the actual notional amount has been changed from 'notional' to 'notionalAmount';
- The naming of the element equitySwapEarlyTermination has been changed to earlyTermination.
- The naming of the element equitySwapAdditionalPayment has been changed to additionalPayment.
- The naming of the type Valuation to has been changed to EquitySwapValuation.
Following the design recommendations developed through the FpML the coordination committee, the following further changes have also been made:
- The following elements wich refer, through an href, to other elements within the schema have been declared as empty: amountRelativeTo, dividendPeriodEffectiveDate and dividendPeriodEndDate.
- The cashSettlement data field of the LegAmount type has been defined as an element that extends the LegAmount type in the case of the equityAmount component, as opposed to an attribute of it.
- The principalExchangeScheme has been eliminated. This attribute was associated with the principalExchangeDescription node and its purpose was to characterize each of the principalExchange nodes present in the document as to whether it is an initial exchange, an intermediary exchange or a final exchange. This approach was considered more precise than the principalExchanges component, which specify through boolean elements the type of principal exchange present in the document, but does not tell which one is which when several exist. Considering that the attrribute in place violated the FpML design standard according to which only leaf elements should have business content, it has just been removed.
- As an implication of the elimination of the principalExchangeScheme, the PrincipalExchangeEnum has also been removed from the fpml-enum-4-0.xsd schema.
- The dateIncluded boolean attribute associated with the dividendPeriodEffectiveDate and the dividendPeriodEndDate has been eliminated. This attribute was optional, and considered as not necessary in the current state of the confirmations. Considering that it violated the FpML design standard according to which only leaf elements should have business content, it has been removed.
- The optional href attribute associated with the effectiveDate and the terminationDate has also been suppressed, as it was redundant with the href attribute that is part of the dateRelativeTo component and also violated the FpML design standard according to which only leaf elements should have business content.
Last but not least, the schema annotations have been updated to clarify the use of the href when the relativeDate component is being used.
Type: Schema Revision
Refers to: fpml-cd-4-0.xsd
Description: There have been a number of changes to the CD schema. Some of these changes were motivated by changes in the ISDA documetation. Some are simplifications or corrections of errors pointed out to us by early adopters.
- Created complex type AdjustableDate2.
- Changed data type of effectiveDate element to AdjustableDate2.
- Created complex type ScheduledTerminationDate.
- Changed data type of scheduledTerminationDate to ScheduledTerminationDate.
- Added an optional businessCenter element into the CreditEventNotice complex type.
- Added an optional multipleCreditEventNotices element to the Restructuring complex type.
- Removed the creditEvent substitution group.
- Replaced the creditEvent+ element with a sequence of the specific credit events.
- Allowed only a single currency in the notDomesticCurrency element. Created a new type called NotDomesticCurrency to support this.
- Removed the obligationCharacteristic substitution group.
- Replaced the obligationCharateristic+ element with a sequence of the specific obligation characteristics.
- Removed the deliverableObligationCharac substitution group.
- Replaced the (obligationCharacteristic+, deliverableObligaticCharac+) elements with a sequence of the specific deliverable obligation characteristics.
- Renamed the complex type DirectLoanParticipation to LoanParticipation.
- Added an indirectLoanParticipation element as a possible deliverable obligation characteristic. This element has type LoanParticpation.
- Allowed the notContingent element to be specified as a possible obligation characteristic.
- Renamed the complex type CurrencyObligationCharac to SpecifiedCurrency, since the specifiedCurrency element is the only element that uses the type.
- Added a settlementCurrency element to the definition of the SettlementTerms complex type.
- Removed the settlementCurrency element from the definition of CashSettlementTerms.
- Removed the settlementCurrency substitution group.
- Dropped the cds prefix in the following element names: cdsCashSettlemntTerms, cdsValuationDate, and cdsValuationTime. Local element definitions allowed this change.
- Replaced the settlementCurrency element in the GeneralTerms element with a choice between cashSettlementTerms and physicalSettlementTerms.
- Moved the enumerations ObligationCategory and ValuationMethod to the enumeration file fpml-enum-4-0.xsd Renamed them ObligationCategoryEnum and ValuationMethodEnum in order to comply with FpML naming conventions.
- Created a new complex type called Empty. Used it to replace the following empty types: BusinessDaysNotSpecified, CreditEvent, DeliverableObligationCharac, MultipleCreditEventNotices, MultipleHolderObligation, ObligationCharacteristic, PartialCashSettlement, StandardPublicSources.
- Made numerous corrections and enhancements to element definitions.
- Changed type of the maximumMaturity element to Interval.
- Changed the type of the following elements from integer to nonNegativeInteger: cashSettlementBusinessDays, physicalSettlementPeriod/businessDays, physicalSettlementPeriod/maximumBusinessDays, singleValuationDates/businessDays.
- Changed the type of the following elements from integer to positiveInteger: multipleValuationDates/businessDaysThereafter, multipleValuationDates/numberValuationDates.
- Allowed a calculationAgentCity to be specified without also specifying a
Calculation Agent.
- Associated a default scheme with the additionalTerm element.
Type: Example/Scheme Value Revision
Refers to: Most examples, fpml-4-0-schemeDefinitions.xml
Description: We began validating scheme values, and as a result we corrected a number of examples and added a few scheme values. A number of scheme URIs have been updated as a results
Rationale: Provide precise examples.
- EQD and EQS examples:
- changed masterAgreement of ISDA to ISDA2002
- changed contractualDefinitions values of ISDA_2000 to ISDA2000
- changed contractualDefinitions values of ISDA_1996_EquityDerivative to ISDA1996Equity
- changed contractualDefinitions values of ISDA_1998_FX to ISDA1998FX
- changed governingLaw values of English Law to GBEN
- changed settlementPriceSource vaslues of Close to OfficialClose
- eqd ex10: changed businessCenter value of Frankfurt to DEFR, eliminated scheme URI for businessCenter and rateSource
- eqs ex04: principalExchangeScheme ... TBD
- IRD: added BankOfJapan to informationProviderScheme
- FX: changed REUTERS to Reuters in informationProviderScheme fields
- FX: #7, #11, #20, #21 - changed informationProviderScheme uri to an "extra", to indicate that these are non-standard information providers. Implementers should note that in future drafts of this standard, the FX rate source structure may be modified to accommodate more comprehensive support for ISDA's "settlement rate option" concept, as defined in the 1998 ISDA FX and Currency Option definitions.
- IRD #1,2: set URI to the old currency URI.
Type: Schema and Scheme URI Revision
Refers to: fpml-4-0-schemeDefinitions.xml, fpml-shared-4-0.xsd
The default currency scheme has been changed to include the date of the last ISO currency code revision, 2001-08-15.
IRD examples #1,2 have been updated to refer to the old URI.
Type: Example Revision
IRD Examples #12, #13, 19, 27
The href attribute in the dateRelativeTo in the cashSettlementValuation component of examples 12 and 13 pointed incorrectly to the cashSettlement structure. This has been corrected to point to the exercise structure.
There was a typo of 20011 in the temination date in #19.
There was a typo of 6 in the calculation period multiplier of side 1 date in #27; it was changed to 3.
Type: Schema Revision
Refers to: streetLine element in fpml-shared-4-0.xsd.
Description: It there were two ways that multiple sstreet lines could be defined. One has been eliminated.
Rationale: Improve consistency of FpML using addresses.
Type: Documentation Change
Refers to: partyIdScheme in fpml-4-0-schemeDefinitions.xml
Description: Updated Dun & Bradstreet to D & B, and the URL of their website to http://dnb.com, due to a name change in their organization.
Type: Documentation Change
Refers to: CalculationPeriod in fpml-ird-4-0.xsd.
Description: The description of calculationPeriodNumberOfDays appeared under notionalAmount. The documentation has been corrected.
Type: Documentation Change
Refers to: RateTreatmentEnum in fpml-enum-4-0.xsd.
Description: The description of negative interest treatment had overwritten the correct documentation. The correct documentation has been restored.
Type: Documentation Script Change
Affects : All scheme reference sections.
Description: Corrected the "Used by" section for Complex Types. Added support for xsd:group. Corrected some incorrect URLs in "used by" links.
