2.2 Overview of the organization of the schema

2.3 Overview of Document Types

2.4 Using FpML 4.2

2.5 The FpML root element

2.6 DataDocument type

2.6.1 The FpML 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:

• Optional validation rules identification
• A trade or trades
• A portfolio or portfolios
• An event or events
• A party or parties

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

In addition, the FpML root element includes attributes for:

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

2.6.2 The Trade Component

The trade is the top-level component within the root element FpML. A trade is an agreement between two parties to enter into a financial contract and the trade component in FpML contains the information necessary to execute and confirm that trade.

2.6.2.1 tradeHeader

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

2.6.2.3 otherPartyPayment

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

2.6.2.4 brokerPartyReference

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

2.6.2.5 calculationAgent

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

2.6.2.6 documentation

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

2.6.2.6.1 contractualMatrix

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

Specifically it is designed to:

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

2.6.2.6.1.1 Examples of using the contractualMatrix structure

For Interest Rate Derivatives:

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

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

For Credit Derivatives:

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

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

2.6.2.8 governingLaw

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

2.6.3 The Portfolio Component

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

2.6.4 The Party Component

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

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

2.6.4.1 Accounts

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

This is a description of the elements:

• accountId: An account identifier. For example an Account number.
• accountName: The name by which the account is known.
• accountBeneficiary: The beneficiary of the account.

Example:

                                        ...
<account id="LDF_CUSTODY">
        <accountId accountIdScheme="http://bony.com/custody"/>
        <accountName>London Diverisified Fund Custody Account</accountName>
        <accountBeneficiary href="LDF"/>
</account>
                                        ...
                                        

2.6.5 Roles - the TradeSide Component

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

This is the description of the different roles currently defined:

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

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

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

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

2.6.6 The Product Component

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

• Interest rate swaps
• FRAs
• caps/floors
• swaptions
• FX spot/forwards
• FX swaps
• FX options
• Equity options
• Equity swaps
• Equity forwards
• Credit default swaps

2.6.7 The Strategy Component

This component defines a special kind of product that allows the structuring of trade by combining any number of products within a strategy. A trade can be of a strategy rather than of a base product; this strategy can then in turn contain other products, such as multiple options. For example, you could define a strategy consisting of an FX call and an FX put to create a straddle or strangle, and then create a trade of that strategy.

This component also defines the simple strategies of strike spread and calendar spread for Equity Options

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

2.7 More Background on FpML's Design

2.7.1 Rationale for Structured Approach

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

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

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

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

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

2.7.2 Component Framework

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

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

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

2.7.3 Coding Schemes

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

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

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

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

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