Case Study: Brokerages Push XML for Finance

The country's largest brokerage firms are expanding basic XML specifications to define a new open and standard markup language for financial services. FpML v2.0 (Financial Products Markup Language) will provide developers important new guidelines for building B2B web services. But, even if you're not in finance, see how FpML highlights some keen insights on how your own industry should use Open Standards to construct web services transactions.

Tags: FpML, XML, Trade, DTD, Features, Standard, Business Processes,

The FpML v2.0 spec arises from consensus on XML for financial services reached by UBS Warburg, Merrill Lynch, Goldman Sachs, JPMorgan, Citigroup and others, under the umbrella of the International Swaps and Derivatives Association (ISDA), the international trade association for derivatives traders.

FpML is a protocol and an application of XML aimed at enabling e-commerce activities in the field of financial derivatives. The development of the standard, controlled by ISDA, 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. The current FpML 2.0, however, is focused on interest rate derivatives.

The Products Working Group has developed FpML 2.0 within the FpML Architecture Version 1.0 framework defined by the Architecture Working Group. Their 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); and
  • FpML referencing methodology, including guidelines for referencing coding schemes for:
    1. Interest Rate Caps;
    2. Interest Rate Floors;
    3. Interest Rate Swaption (European, Bermuda and American Styles; Cash and Physical Settlement);
    4. Extendible and Cancelable Interest Rate Swap Provisions; and
    5. Mandatory and Optional Early Termination Provisions for Interest Rate Swaps
      FX Resetable Cross-Currency Swap

    The FpML also looks to help devs better cope with complex mulit-party business rules and processes by bring more transparency to such rules. FpML provisions for this transparency include:

  • Definition of business processes that might result in the trade content between parties;
  • Definition of reference data related to the counterparty such as settlement instructions, location and contact details;
  • Specification or design of repositories that would house such "static data" as descriptions for the elements for the previous two elements of a transaction (business process, trade content between parties, settlement instructions, location and contact details); and
  • Identification of participating trading partners/parties is done using traditional means (the ISO standard bank identifier code BIC). However, with an eye toward an SOA (Services-Oriented Architecture), the FpML architecture supports the use and identification of alternative coding schemes through the Schemes mechanism.

  • The FpML 2.0 Recommendation, following the approach used with FpML 1.0, utilises a single DTD. However, with the expected addition of other asset classes (FX and Equities) in FpML 3.0 it is intended at that time to separate the DTD into multiple parts:

    -A shared components DTD

    -Several asset class specific DTDs

    -A main DTD which links the other DTDs to form the FpML standard.

    Components are Key

    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.

    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.

    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 Document Type Definition (DTD) as XML entities.

    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.