## 2 FpML OVERVIEW

### 2.1 FpML

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

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

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

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

### 2.2 Overview of the organization of the schema

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

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

This graph shows the relationship between the different subschema files.

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

### 2.3 Overview of Document Types

An FpML document can be either of two categories:

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

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

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

### 2.4 Using FpML

Before beginning to use FpML, an architect must answer several questions:

- How will the FpML be used? Is it primarily a messaging application, or primarily a data storage and retrieval application?
- If it is a messaging application, is there an existing workflow format that is used to coordinate interactions between the entities exchanging messages, or is a new one required?
- Will the FpML be used within a single institution, or across a number of institutions?
- What asset classes of products will be required?
- Will there need to be local data or product extensions?
- Are there any other XML schemas or DTDs the FpML needs to interact with?

If the application requires a new messaging layer, particularly if it will be used between institutions, the FpML messaging layer is recommended. If the application is primarily a data storage and retrieval application, the DataDocument type is available. For example, to store trades in an XML trade archive, and then retrieve them for a display or to generate, say, a confirmation, the DataDocument format will likely be sufficient. To implement a trade matching service between institutions, you should use the messaging layer.

### 2.5 The FpML root element

The FpML element forms the root for an FpML instance document. The structure of the FpML document depends on the "xsi:type" attribute. The simplest FpML document is a "DataDocument" (xsi:type='DataDocument'). This is similar to an FpML 3.0 document, and is described in the next section.

The FpML root element contains attributes that specify the FpML version ('4-3' for FpML 4.3), the schema name and location, the name space, and related properties, as well as the xsi:type. See the Architecture 2.1 specification for more details on this.

### 2.6 Annotations

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

#### 2.6.1 eCore

eCore is part of the Eclipse Modelling Framework. This is the modelling technology based on Eclipse based on a subset of UML.

eCore annotations add back the model information missing from XML Schema, specifically:

- The type of IDREFs
- Canonical namespace prefix
- Package names
- Root documents

In terms of implementation, the FpML Schema root element includes these additional attributes:

- the eCore namespace: xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
- the canonical namespace prefix: ecore:nsPrefix="fpml"
- the package name: ecore:package="org.fpml"
- the root element: ecore:documentRoot="FpML"

In addition, the ecore annotations specify the specific target of an href attribute:

    <xsd:complexType name="AccountReference">
    	<xsd:annotation>
    		<xsd:documentation xml:lang="en">Reference to an account.</xsd:documentation>
    	</xsd:annotation>
    	<xsd:attribute name="href" type="xsd:IDREF" use="required" ecore:reference="Account"/>
    </xsd:complexType>

Benefits of eCore annotations include:

- FpML controls the object oriented models built from FpML
- The same OO model is shared, which is good for interoperability
- Modelling use now work with FpML
- Developers who can't unerstand XML Schema, can understand UML
- The FpML Schema is still valid and XML Schema tools are unaffected

More details about eCore annotations are available at: http://www.eclipse.org/modeling/emf/docs/overviews/XMLSchemaToEcoreMapping.pdf

### 2.7 Main Components

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

#### 2.7.1 The DataDocument type

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

It contains:

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

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

#### 2.7.2 The Trade Component

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

##### 2.7.2.1 tradeHeader

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

##### 2.7.2.1.1 Primary Trade Identifier

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

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

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

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

##### 2.7.2.2 product

Product is an abstract concept in FpML and an actual product element is not used. Instead, one of the FpML products will appear directly under trade.

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

##### 2.7.2.2.1 Product Identification

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

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

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

##### 2.7.2.3 otherPartyPayment

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

##### 2.7.2.4 brokerPartyReference

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

##### 2.7.2.5 calculationAgent

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

##### 2.7.2.6 documentation

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

##### 2.7.2.6.1 contractualMatrix

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

Specifically it is designed to:

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

##### 2.7.2.6.1.1 Examples of using the contractualMatrix structure

For Interest Rate Derivatives:

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

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

For Credit Derivatives:

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

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

##### 2.7.2.7 collateral

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

##### 2.7.2.7.1 independentAmount

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

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

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

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

##### 2.7.2.8 governingLaw

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

#### 2.7.3 The Portfolio Component

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

#### 2.7.4 The Party Component

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

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

##### 2.7.4.1 Accounts

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

This is a description of the elements:

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

Example:

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

#### 2.7.5 Roles - the TradeSide Component

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

This is the description of the different roles currently defined:

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

##### 2.7.5.1 Using tradeSide

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

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

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

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

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

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

##### 2.7.5.2 Examples

- FX Single Leg with multiple roles and accounts (xml file)
- Two sided swap with multiple roles and accounts (xml file)
- Credit Default Swap Short Form US Corporate with broker role (xml file)

#### 2.7.6 The Product Component

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

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

#### 2.7.7 The Strategy Component

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

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

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

### 2.8 More Background on FpML's Design

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

#### 2.8.1 Rationale for Structured Approach

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

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

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

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

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

#### 2.8.2 Component Framework

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

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

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

#### 2.8.3 Coding Schemes

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

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

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

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

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

Previous | Top | Next
--- | --- | ---