Top Financial Firms Architecting with XML
Last month, Reuters unveiled a new XML-based secure trade notification system that enables financial institutions to manage their trading capital and risk exposures better as well as improve operational efficiency. Reuters service, already selected by Lehman Brothers, offers a trade messaging hub to make a variety of financial integrations easier and cheaper. IDN takes a look.
Last month, Reuters unveiled a new XML-based secure trade notification system that enables financial institutions to manage their trading capital and risk exposures better as well as improve operational efficiency.
Reuters' service, already selected by Lehman Brothers, offers a trade messaging hub to make a variety of financial integrations easier and cheaper. At its core, Reuters Trade Notification Service (RTNS) is a trade messaging hub that facilitates the electronic transfer of all trade related messages. The service is already operational and is undergoing a controlled introduction.
RTNS will initially focus on trade affirmation and confirmation, and will be expanded to cover allocation and settlement instructions, amongst others. The service will support industry standard message formats such as FIX, FPML, as well as FIX and TWIST.
"The more complex the instrument, the more costly and complicated it is to process the transaction, especially given the number of technologies employed by the involved parties," commented Rich Kiel, Senior Vice President of Transactions, Reuters.
"The release of RTNS is in direct response to customer needs and allows users to lower their costs and operational risk by supporting all trade related messages - whether conducted by voice or over an electronic platform."
Inside the Power of FpML,
Financial Web Services
The country's largest brokerage firms took XML standards into their own hands, and over the last two years have expanded them to define a new open and standard markup language for financial services, FpML. See how execs at Merrill Lynch, JP Morgan and Citibank might help your industry implement your own set of specs for B2B and B2C web services.
FpML provides an overall template for execs in other vertical industries how they might map XML (schema and transmission) concerns to their needs for dataflow, business rules and access control.
The FpML standard, which is freely licensed (under the FpML public license), is intended to automate the flow of information across the entire derivatives partner and client network, independent of the underlying software or hardware infrastructure supporting the activities related to these transactions. FpML is of value when the direct communication of derivative trade descriptions and environment information between two firms is desired. Ultimately, it will allow for the electronic integration of a range of services, from electronic trading and confirmations to portfolio specification for risk analysis.
The FpML 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.
FpML looks to use XML as the standard meta-language for describing data shared between applications for all categories of privately negotiated derivatives. Now in its 4th version, FpML covers a range of financial products, including interest rate swaps and Forward Rate Agreements (Version 1); Common interest rate option products -- including caps, floors, swaptions, and cancelable and extendible swaps (Version 2); FX and Equity Derivatives (Version 3); and added equity derivatives, including credit derivatives (Version 4). Further, FpMLv4 defines a messaging framework, and is the first FpML version to be schema-based.
This parsing of the functions and application of the banking-specific markup language enabled the multi-vendor FpML Products Working Group to make recommendations covering many aspects of the design, deployment and testing of financial web services apps, including:
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:
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 recommendations utilizes a single DTD. However, with the expected addition of other asset classes (FX and Equities) to separate the DTD into multiple parts, as the FpML standard was applied to different financial "products"
-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.