XML Standards for Financial Services

The ultimate goal of straight through processing is to replace the traditional phone and fax confirmations with a completely automated loop, from pre-trade communication and deal capture through to clearing and settlement. This involves automating the processes passing trade-related data between investment managers, brokers, clearing agencies, and custodians. The core of STP, therefore, lies in the exchange of information between disparate systems.

The structure of the information exchanged must be in a format that is agreed upon by the communicating parties and that is easily manipulated programmatically. The first requirement necessitates the presence of industry standards, and the second points to the use of XML as the data transport language.

XML standards for the financial services industry, therefore, are essential for the successful implementation of STP. XML documents must carry information for pre-trade analysis such as quote requests, trade information such as security details and order information, post-trade analytics such as market data, and settlement and clearing specifics.

The Current State of Affairs

The current trading infrastructure is characterized by excessive dependence on faxes and phones, manual procedures, lack of standardization, and expensive trade failures. SWIFT estimates that 59% of trade instructions required repair and query, each mistake costing the industry money, which aggregates to billions of dollars.

The workflow of securities trading involves three steps: Pre-trade, Trade, and Settlement. These are currently executed mostly in a six-step process: order entry, trade execution, confirmation, middle-office operations, clearing and settlement. As the system stands right now, trade information is re-entered at some stages which are a waste of resources and time.

For equities, a number of firms are using the FIX (Financial Information eXchange) protocol, which is a proprietary protocol to exchange information. It ties the message framework and the content of the message together which is makes its integration with other messaging standards such as SOAP difficult.

For over the counter and privately negotiated derivatives, it was traditionally very difficult to determine a standard because of the complex and dynamic nature of the securities. Hence, faxes and phone calls constituted the most common method of exchanging information on these products. The resulting heavily manual procedures made these trades more liable to errors and delays. This is costly and comes with a high operational risk.

For trade confirmation, Oasys, developed by Thompson Financial ESG, is a popular choice. The company has a subscriber base of more than 3,000 counterparties. Thomson provides a central host system which is accessed over a private network via X.25 or TCP/IP. The Oasys Workstation sends and receives data in ESG-proprietary frames.

Finally, for settlement information, over 7,000 banks in 192 countries use the SWIFT protocol worldwide. Formed in 1973, the Society for the Worldwide Interbank Financial Telecommunication (SWIFT) is an industry-owned cooperative that dominates the messaging services used by banks, brokers/dealers, and investment managers. SWIFT operates a messaging service for financial messages, such as letters of credit, payments, and securities transactions, between member banks worldwide. With the SWIFT network, a bank in Singapore can electronically swap customer and interbank funds, clear checks, share balance information, or trade securities with an institution in New York. SWIFT messages are proprietary and not based on XML. SWIFT requires that each customer have a dedicated terminal with pre-accredited software.

For all the products and solutions outlined above, we see the following issues:

• Proprietary messaging frameworks
• Private networks
• No standardization
• Lack of interoperability

Just from one possible sequence of trading above, it is obvious that the need for STP is going to be very important. XML makes all these issues easier because, along with web services, or even proprietary vendor development, it can take the data and make it easily accessible and flexible.

Moving Towards XML Standards

The value of industry standards has been recognized for some time and industries as varied as bioinformatics to chemicals are using XML standards to streamline the communication between counterparties, suppliers and customers and so forth. In the financial services industry, there are currently several standards being developed. In light of STP, I will discuss FIXML, FpML, and SWIFT. FIXML is used to describe information exchanged on standardized instruments while FpML describes information for over the counter derivative instruments.

FIXML: Trade Messages

The Financial Information Exchange protocol (FIX) is an industry protocol used for communicating securities information in specific electronic messages. This includes information such as getting quotes, market data, and trade orders. FIX is widely popular, and, according to one study: used by 82% of brokers.

The most important feature of FIX that differentiates it from other protocols in the financial industry is that FIX is a connected, session-based protocol. The FIX protocol consists of two layers, known as the Session Layer and the Application Layer. The Session layer contains all the session related information; all the business related information such as quote and order information resides in the Application Layer. The proprietary format follows a <TAG>=<VALUE><DELIMITER> CSV format and requires FIX engines to use the protocol. One example of this, 38=10000, which means that the Order quantity is 100000.

Figure 1: Structure of the FIX Protocol

FIX realized that the tight coupling between the Session and Application Layers was resulting in a less flexible protocol. In order to base it on a standard format, FIXML was devised in as an XML vocabulary based on the FIX protocol. Essentially, FIXML takes a FIX tag value format and represents it in XML. These FIXML messages are then embedded within the traditional FIX headers and trailers. By doing so, it minimizes the impact on existing implementations of FIX, requiring just an XML parser for an existing FIX engine to communicate. Therefore our Order quantity example now becomes:

 <OrderQuantity>

   <OrderQty>10000</OrderQty>

 </OrderQuantity>

This approach has, however, received some criticism from the industry, which believes that FIXML is merely an XML representation of the FIX protocol that doesn't take full advantage of the capabilities of XML. The fact remains that now FIX can be carried in any messaging protocol in the message body and this extends its flexibility and interoperability potential. Currently, FIXML is in DTD format and can be downloaded from the FIX website.

FpML: Derivatives Products

FpML (Financial products Markup Language) is an XML-based standard for complex financial products. FpML aims to standardize and streamline trading and exchange of information in the field of privately negotiated financial securities such as derivatives, swaps, and structured products. Currently, the standard covers interest rate swaps and Forward Rate Agreements (FRAs), equity, FX, and interest rate derivatives. This is the only protocol that was developed with the specific aim of using XML and therefore has many advantages over FIXML.

Automation is very hard when privately negotiated instruments are involved. Each trade is a unique instrument that can only be communicated by exchanging all the economic terms. The challenge is to capture the contract terms electronically in a format that supports the complexity and variety of derivative product features. The FpML working standard uses XML to attain this flexibility; it is available in both DTD and schema format from the FpML site.

The structure of FpML consists of three main structures:

• The trade component addresses the question of what constituted the trade; in other words, what was the nature of the contract. For example, an equity option is the right to buy an equity (or stock) at a certain price.
• The party component represents details on the counterparty which was involved in the trade. This is the counterparty.
• The portfolio component links one trade to the basket or portfolio of trades in which it is kept. This is important when doing risk analysis because the analyst must know the portfolio in which the trade is kept.

Thus, at a top level, we have in the FpML namespace:

<FpML>

  <trade  ... />

  <party ... />

  <portfolio ... />

</FpML>

The main part of the schema lies in the trade component which consists of the many different products such as swap, equity option and fra. Each type of product has its own datatype library that contains components specific to that particular product. Financial firms can extend the FpML schema by adding on instruments in new datatype libraries.

Note that unlike FIX, FpML focuses on the product information. Hooks for messaging and encryption can be added by companies themselves.

The FpML.org site is the hub of the company and contains pertinent documents on architecture, messaging, migration to schemas and versioning schemas. It also plans to publish a site on extending the schema. Best practices for XML schemas are followed as far as possible.

SWIFT & ISO 15022 XML: Integrating it All

Current constraints on efficiencies in exchanging financial information have also been realized by SWIFT, which claims that its biggest priority is to move to XML. In fact, it is planning to incorporate FIX and FpML into a new standard referred to as ISO 15022XML. The resultant protocol is to leverage FIX Protocol's expertise in the pre-trade/trade execution domain, and Swift's post-trade domain expertise to bring together different parts of the trade life cycle and work through issues hindering straight-through-processing (STP). This is a very slow process and work on the integration has not gone far. However, given SWIFT's base of 7,000 banks internationally, there is a great deal of interest in ISO 15022 XML, and it is thought that it will be the predominant XML standard if it does come to fruition.

Future Directions

There is some speculation over which standard to use and how. Are these standards in a stage where they can be used? FIX is already a common protocol for exchanging information and the move to FIXML should not be difficult given that the latter is just an XML version of the former. FpML is being used internally by many financial institutions on Wall Street. Standards also being developed for the following requirements; Market Data, Risk Management, Reporting and Counter Party information. Since these protocols are based on XML, the whole document or part of the document can be encrypted using digital signatures. This will greatly streamline the confirmation part of the trading process. In addition, the fact that the standards are XML standards opens them to use with messaging frameworks using any protocol including the FIX session Layers.