System and method for conducting web-based financial transactions in capital markets

Abstract

The present invention provides a system and method that enables users, such as institutional investors and financial institutions, to engage in capital market transactions, including the trading of Over-the-Counter financial products, via the Internet (including the World Wide Web). The system includes a variety of servers, applications, and interfaces that enable users to interactively communicate and trade financial instruments among one another, and to manage their portfolios. Interactive communications supported by the system include: requesting price quotes, monitoring and reviewing quote requests, issuing price quotes, monitoring and reviewing price quotes, negotiation between users, acceptance of price quotes, reporting, portfolio management, analysis of financial information and market data, calendaring, and communications among users and/or system administrators, including e-mail, chat, and message boards. The present invention also supports communications with the server side in an automated manner via an automated processor. Such automated communications enable connectivity with users' internal, back-end systems to execute automated, straight-through processing, including transaction pricing, payment scheduling and journaling, derivatives trading, trade confirmation, and trade settlement. Such communications are facilitated using a novel XML-based syntax (FinXML.TM.) and XSL-based processing language (FinScript.TM.). FinXML provides a standard data interchange language for capital market transactions and supports a broad set of elements and attributes that represent a wide variety of financial transactions, reference data, and market data. The common description of the FinXML syntax can be used for all aspects of straight-through-processing, including deal creation, confirmation, settlement, payment, risk management, and accounting.

Claims

What is claimed is:

1. A system for facilitating transactions involving the exchange of financial instruments, the system comprising:

(a) a transaction data parser that can extract transaction data describing a transaction conducted using the system, wherein the transaction data can include:

(i) a type of the transaction;

(ii) a plurality of parties to the transaction, including a member user and a provider user selected by the member user from a plurality of provider users;

(iii) a payment schedule pursuant to which a first party to the transaction will make one or more payments to a second party to the transaction; and

(iv) rate information which can include information relating to an interest rate or an exchange rate that can affect the calculation of the amount of one or more of the payments made pursuant to the payment schedule;

(b) a reference data parser that can extract profile information about the parties to the transaction; and

(c) a market data parser that can extract market data provided to the system, the market data including market interest rates or currency exchange rate.

2. The system of claim 1 wherein the type of the transaction is a foreign exchange spot.

3. The system of claim 1 wherein the type of the transaction is a foreign exchange forward.

4. The system of claim 1 wherein the type of the transaction is an interest rate fixed-float swap.

5. The system of claim 1 wherein the type of the transaction is an interest rate float-float swap.

6. The system of claim 1 wherein the type of the transaction is an interest rate cap.

7. The system of claim 1 in which the type of the transaction is an interest rate floor.

8. The system of claim 1 wherein the type of the transaction is a fixed deposit.

9. The system of claim 1 wherein the type of the transaction is a fixed loan.

10. The system of claim 1 wherein the type of the transaction is a float deposit.

11. The system of claim 1 wherein the type of the transaction is a float loan.

12. The system of claim 1 wherein the type of the transaction is a foreign exchange option.

13. The system of claim 1 wherein the type of the transaction is a foreign exchange swap.

14. The system of claim 1 wherein the type of the transaction is a cross currency fixed-fixed swap.

15. The system of claim 1 wherein the type of the transaction is a cross currency fixed-float swap.

16. The system of claim 1 wherein the type of the transaction is a cross currency float-float swap.

17. The system of claim 1 wherein the type of the transaction is a forward rate agreement.

18. The system of claim 1 wherein the type of the transaction is a customized trade.

19. A system for facilitating transactions involving the exchange of financial instruments, the system comprising:

(a) a member client node that can be used by a member user of the system to conduct a transaction;

(b) a provider client node that can be used by a provider user of the system to conduct the transaction with the member user; and

(c) a server node that facilitates the exchange of messages among the member client and provider client nodes, including a transaction message that includes information describing the transactions between the member user and the provider user, the server node including:

(i) an interactive trading mechanism that enables the member user to select the provider user from a plurality of provider users and to interactively negotiate the terms of the transaction with the selected provider user; and

(ii) an automated messaging system that facilitates the automated exchange of the transaction message between the server node and the provider client node.

20. The system of claim 19 wherein the messages whose exchange is facilitated by the server node can include:

(a) transaction data describing the transaction, including:

(i) a type of the transaction;

(ii) a plurality of parties to the transaction, including the member user and the provider user;

(iii) a payment schedule pursuant to which the member user will make one or more payments to the provider user; and

(iv) rate information which can include information relating to an interest rate or an exchange rate that can affect the calculation of the amount of one or more of the payments made pursuant to the payment schedule;

(b) reference data, including profile information about the parties to the transaction; and

(c) market data, including market interest rate or currency exchange rates.

21. The system of claim 19 wherein the negotiated terms include pricing of the transaction.

22. The system of claim 19 wherein the negotiated terms include acceptance of the pricing of the transaction.

23. The system of claim 19 wherein the negotiated terms include settlement of the transaction.

24. The system of claim 19 wherein both the member client node and the provider client node are physically remote from the server node.

25. An automated financial object conversion and messaging system for exchanging messages describing transactions involving the exchange of financial instruments between a provider user of the system and one or more other member users of the system, the system comprising:

(a) a server node that can convert a first set of internal objects, representing the terms of a transaction between the provider user and a member user of the system, into a transaction message employing a standard format for representing the transaction, wherein the first set of internal objects employs any format that can be utilized by a back-end system of the member user;

(b) a provider node that can convert the transaction message into a second set of internal objects, wherein the second set of internal objects employs any format that can be utilized by a back-end system of the provider user; and

(c) an automated message exchange mechanism that automatically can exchange messages employing the standard format, including the transaction message, between the server node and the provider node.

26. The system of claim 25 wherein the standard format is an XML format.

27. The system of claim 26 wherein the XML format can represent:

(a) transaction data describing the transaction, including:

(i) a type of the transaction;

(ii) a plurality of parties to the transaction, including the provider user and the member user of the system;

(iii) a payment schedule pursuant to which the member user will make one or more payments to the provider user; and

(iv) rate information which can include information relating to an interest rate or an exchange rate that can affect the calculation of the amount of one or more of the payments made pursuant to the payment schedule;

(b) reference data, including profile information about the parties to the transaction; and

(c) market data, including market interest rate or currency exchange rates.

28. A method for converting a first set of internal objects, representing the terms of a transaction involving the exchange of financial instruments between a provider user and a member user of a system for facilitating transactions involving the exchange of financial instruments, into a transaction message employing a standard format for representing the transaction, the method comprising the following steps:

(a) applying an XML mapping to the first set of internal objects in order to dynamically generate a Document Object Model tree; and

(b) applying an XSL stylesheet to convert the Document Object Model tree into the transaction message, wherein the transaction message includes transaction data describing the transaction, including:

(i) a type of the transaction;

(ii) a plurality of parties to the transaction, including the member user and a provider user selected by the member user from a plurality of provider users;

(iii) a payment schedule pursuant to which the member user will make one or more payments to the provider user; and

(iv) rate information which can include information relating to an interest rate or an exchange rate that can affect the calculation of the amount of one or more of the payments made pursuant to the payment schedule.

29. The method of claim 28 wherein the standard format is an XML format.

30. The method of claim 28 wherein the first set of internal objects includes Java objects.

31. A method for converting a transaction message employing a standard format for representing the terms of a transaction involving the exchange of financial instruments between a provider user and a member user of a system for facilitating transactions involving the exchange of financial instruments, and a first set of internal objects representing the transaction, the method comprising the following steps:

(a) applying an XSL stylesheet to the transaction message in order to dynamically generate a JavaScript program; and

(b) executing the JavaScript program to produce the first set of internal object, wherein the transaction message includes transaction data describing the transaction, including:

(i) a type of the transaction;

(ii) a plurality of parties to the transaction, including the member user and a provider user selected by the member user from a plurality of provider users;

(iii) a payment schedule pursuant to which the member user will make one or more payments to the provider user; and

(iv) rate information which can include information relating to an interest rare or an exchange rate that can affect the calculation of the amount of one or more of the payments made pursuant to the payment schedule.

32. The method of claim 31 wherein the standard format is an XML format.

33. The method of claim 31 wherein the first set of internal objects includes Java objects.

Description

FIELD OF THE INVENTION

This invention relates generally to the field of interactive and automated Web-based financial transaction applications, and in particular to interactive and automated systems and methods for conducting financial transactions and managing portfolios and related financial information in capital markets.

BACKGROUND

During the evolution of the Internet, including the World Wide Web, there has been a continual introduction of applications and services to enable individuals and organizations to conduct financial research, manage their financial portfolios, and engage in certain types of financial transactions. The wide array of applications and services ranges from on-line banking to stock quote and financial information services to sites that enable users to engage in on-line, real-time market trades involving various instruments such as stocks, stock options, bonds, and mutual funds. The trading services, for example E*TRADE Securities, Inc.'s "E*TRADE"<www.etrade.com>, Charles Schwab & Co., Inc.'s "Schwab.com" <www.schwab.com>, and Fidelity Brokerage Services, Inc.'s "Fidelity.com" <www.fidelity.com>, permit trading of standard instruments in recognized markets. In such services, the investor uses credit or an account set up through the trade service to engage in trades through the service's proprietary system and interfaces. Such services, which are geared towards individual investors, do not permit seamless integration with users' internal or back-end systems or the creation and trading of customized transactions. These services, and many others like them, do not enable trading between parties in currency derivatives or foreign exchange, or the pricing and modeling of other capital market transactions.

Some steps have been taken to tap into the potentially vast market of institutional investors wishing to engage in complex transactions via the Internet. The "Open Financial Exchange" (Intuit Inc., Microsoft Corp., CheckFree Corp.) <www.ofx.net> was created to provide a common specification for the electronic exchange of financial data between financial institutions, businesses, and consumers via the Internet that enables financial data exchange among disparate systems, in order to support online banking, bill payment and presentment, and the trading of stocks, bonds, and mutual funds. The Open Financial Exchange does not, however, provide a vocabulary, platform, and communication protocol to enable the creation, negotiation, and execution of complex, capital market transactions among financial institutions and institutional investors.

What is needed is a system and method that enables institutional investors and financial institutions to seamlessly create, price, negotiate, execute, settle and analyze complex, capital market transactions, including interest and currency derivatives, foreign exchange, loans and deposits, and fixed-income instruments, using a standard vocabulary and messaging system that enables seamless integration with the proprietary, existing systems of the users.

SUMMARY

The present invention provides a system and method that enables users, such as "Members" (e.g., institutional investors) and "Providers" (e.g., financial institutions), to engage in capital market transactions, including the trading of Over-the-Counter financial products, via the Internet (including the World Wide Web). The system includes a variety of servers, applications, and interfaces that enable users to interactively communicate and trade financial instruments among one another, and to manage their portfolios. Interactive communications supported by the system include: requesting price quotes, monitoring and reviewing quote requests, issuing price quotes, monitoring and reviewing price quotes, negotiation between Members and Providers, acceptance of price quotes, reporting, portfolio management, analysis of financial information and market data, calendaring, and communications among Members, Providers, and/or system administrators, including e-mail, chat, and message boards.

The present invention also supports communications with the server side in an automated manner via an automated processor (the "Connect Processor" and "Connect Messaging Server"). Such automated communications enable connectivity with users' internal, back-end systems to execute automated, straight-through processing, including transaction pricing, payment scheduling and journaling, derivatives trading, trade confirmation, and trade settlement. Such communications are facilitated using a novel XML-based syntax ("FinXML") and XSL-based processing language ("FinScript"). FinXML provides a standard data interchange language for capital market transactions and supports a broad set of elements and attributes that represent a wide variety of financial transactions, reference data, and market data. The common description of the FinXML syntax can be used for all aspects of straight-through-processing, including deal creation, confirmation, settlement, payment, risk management, and accounting.

BRIEF DESCRIPTION OF THE FIGURES

The above objects and description of the present invention may be better understood with the aid of the following text and accompanying drawings:

FIG. 1 shows the architecture of an embodiment of the present invention.

FIG. 2 shows a flowchart of the process by which Members and Providers conduct a financial transaction in an embodiment of the present invention.

FIG. 3 shows the structure of a FinXML "Trade" element in an embodiment of the present invention.

FIG. 4 shows the structure of a FinXML "External Party" element in an embodiment of the present invention.

FIG. 5 shows the structure of a FinXML "Internal Party" element in an embodiment of the present invention.

FIG. 6 shows the structure of a FinXML "Events" element in an embodiment of the present invention.

FIG. 7 shows the general architecture of the Connect Automated Processor in an embodiment of the present invention.

FIG. 8 shows an architectural overview of the Connect Automated Processor in an embodiment of the present invention.

FIG. 9 shows the layout of a Connect Message in an embodiment of the present invention.

FIG. 10 shows the structure of a Connect Message in an embodiment of the present invention.

FIG. 11 shows a diagram of the Connect Message Flow for the automated pricing (synchronous) function in an embodiment of the present invention.

FIG. 12 shows a diagram of the Connect Message Flow for the automated pricing (asynchronous) function in an embodiment of the present invention.

FIG. 13 shows a diagram of the Connect Message Flow for the semi-automated pricing (synchronous) function in an embodiment of the present invention.

FIG. 14 shows a diagram of the Connect Message Flow for the deal transmission (asynchronous) function in an embodiment of the present invention.

FIG. 15 shows the components utilized in converting financial objects into a FinXML document using FinScript in an embodiment of the present invention.

FIG. 16 shows a flowchart of the process of converting financial objects into a FinXML document using FinScript in an embodiment of the present invention.

FIG. 17 shows the components utilized in converting a FinXML document into financial objects using FinScript in an embodiment of the present invention.

FIG. 18 shows a flowchart of the process of converting a FinXML document into financial objects using FinScript in an embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

A. System Functionality

The technology of the present invention can be embodied in various forms to provide a platform for conducting interactive and automated financial transactions and management of portfolios and related financial information in capital markets. The platform enables members, including end-users and providers of financial products and services, to engage in the trading of standard and customized financial instruments in capital markets. System functionality includes: capture and pricing of financial instrument trades; presentation of real-time market data; saving of completed trades to a portfolio; management of trading workflow; transmission of trades to end-users' proprietary, back-end systems for pricing, trading, payment processing, confirmation, and settlement; performance of portfolio analysis; performance of risk management analysis; and inter-user communications.

In the present embodiment of the invention, the system includes both server-side and client-side functionality. The server-side functionality enables system users to interactively and seamlessly: engage in financial instrument trades; perform portfolio management, analysis, and reporting; obtain real-time market data and news; communicate with the system and other users via electronic mail, chat, and message boards; and maintain a calendar. The server-side includes interactive system servers that host such user activities, as well as one or more system databases, and an automated messaging server that controls communication with the automated back-end systems of clients.

The client side functionality includes an automated processor that communicates with the automated messaging server of the system side and serves as a seamless interface to the automated back-end systems and proprietary databases of clients. Thus, the system enables organizations with disparate systems and data to engage in transactions using the common functionality and interfaces of this invention. The client side also includes client web browsers that enable interactive communication with the system servers.

The invention described herein provides a standard, XML-based vocabulary to represent and facilitate the financial transactions, as well as a system and method for converting users' data and information to/from the standard vocabulary and communicating such information through the system in an automated manner.

1. System Architecture Overview

FIG. 1 illustrates the architecture of one embodiment of this invention. This embodiment is presented for purposes of illustration and description, and other embodiments will be apparent to and could be implemented by practitioners skilled in this art.

a. Server Side

The server side (sometimes referred to as the "CFOWeb System" in this embodiment) communicates with the client side (consisting of users known as "Members", e.g., corporations and institutional investors, and "Providers", e.g., financial institutions) via the Internet (including the World Wide Web) 10. The server side includes a variety of interactive system servers that provide functionality to users. Web Server 100 enables communications (through the Internet via a transfer protocol such as, e.g., HyperText Transfer Protocol or "HTTP/IP") between users who connect to the server side through their web browsers 30 and the various system servers. Trading server 160 provides a graphic user interface and applications that enable users to interactively trade financial derivatives among each other. Portfolio management server 170 provides a graphic user interface and applications that enable users to manage their portfolios of financial derivatives. Reports server 180 provides a graphic user interface and applications that enable users to run and produce standard and customizable reports regarding their portfolios, including mark to market, upcoming events, and trade lists. Analysis server 190 provides a graphic user interface and applications that enable users to run analytics against their portfolios, including valuation, and interest rate sensitivity. Calendar server 200 provides a graphic user interface and applications that enable users to automatically calendar key dates regarding settlement, payments, cash flows, and other details related to their financial derivative transactions and portfolios. News and research server 210 provides a graphic user interface and applications that enable users to obtain real-time market data and financial and other news, as well as proprietary third-party data feeds. News and research server 210 includes connections to real-time market data feeds and news services 220 and third-party data feeds 230.

The interactive system servers also include servers that enable communication among system users and administrators. Chat server 120 provides real-time chat, thus enabling users to engage in discussion forums related to financial derivatives. Paging server 130 enables users to build a messaging community and determine which users are online and available to receive messages at a given instance. E-mail server 140 provides an intra-system electronic mail vehicle, enabling communications among users and system administrators, including all aspects of a financial trade from quote requests to settlement. Message boards server 150 provides an arena for users and system administrators to post and read system-wide messages, as well as quote requests and quotes.

Automated messaging server 90 (sometimes referred to as the "Connect Messaging Server" in this embodiment) controls communications (through the Internet via a transfer protocol, e.g., HTTP/IP) between the various system servers of the server side and users whose internal, back-end systems 85 execute automated processes that require communication with the server side. Such automated processes could include transaction pricing 40, payment scheduling and journaling 50, derivatives trading 60, trade confirmation 70, and trade settlement 80. Communications between Connect Messaging Server 90 and the client side pass through automated processor 20 (sometimes referred to as the "Connect Processor" in this embodiment)--which shares the same functionality as automated messaging server 90--and automated message broker 25 and are facilitated using the "FinXML" vocabulary and the "FinScript" processing language, as described below.

The CFOWeb System includes one or more system databases 110, which store data related to the processing of financial transactions, as well as user communications and interactions with the system servers.

b. Client Side

The client side includes functionality that enables users--Members and Providers--to communicate, either interactively or in an automated manner, with the various system servers. Web browser 30 enables interactive communications (through the Internet via a transfer protocol, e.g., HTTP/IP) between users and the CFOWeb System with connection made on the server side at web server 100. Interactive communications might include: requesting price quotes (Members), monitoring and reviewing quote requests (Providers), issuing price quotes (Providers), monitoring and reviewing price quotes (Members), negotiation between Members and Providers, acceptance of price quotes (Members), reporting, portfolio management, analysis of financial information and market data, calendaring, and communications among Members, Providers, and/or system administrators, including e-mail, chat, and message boards.

Alternatively, users can communicate with the server side in an automated manner via Connect Processor 20 (and automated message broker 25) which communicates (through the Internet via a transfer protocol, e.g., HTTP/IP) with Connect Messaging Server 90. Such automated communications enable users' internal back-end systems 85 (which include one or more back-end databases 88) to execute automated processes, which could include transaction pricing 40, payment scheduling and journaling 50, derivatives trading 60, trade confirmation 70, and trade settlement 80. Such communications are facilitated using the "FinXML" vocabulary and the "FinScript" processing language, as described below.

2. Financial Transaction Functionality

For system users--Members and Providers--the functionality included in an embodiment of this invention can be categorized as follows: pre-transaction, transaction, post-transaction, and general. The present invention (i) automates or (ii) provides an interactive interface for such functionality.

a. Pre-Transaction

Members and Providers (or in other embodiments of this invention, Members and Members) that engage in a financial transaction of a type enabled by this invention proceed through a series of steps illustrated in FIG. 2. When a Member and Provider decide that they may engage in financial transactions in the future, the parties establish their relationship by executing certain agreements (step 300). Such agreements govern the rules of engagement, rate sources, confirmation and settlement procedures, and other information that can be reused over a series of transaction between the parties. The International Swaps and Derivatives Association, Inc. ("ISDA") <http://www.isda.org> provides certain standardized agreements (e.g., "1992 ISDA Master Agreement") that may be used by the parties for these purposes. The parties can carry out this step using the interactive e-mail function of the system (provided by e-mail server 140 in FIG. 1) to exchange information to be included in the agreements. In addition, by combining off-the-shelf electronic signature software with the system, the parties can electronically sign and exchange the standardized agreements. Members and Providers may engage in multiple iterations of this step, depending upon the number of standardized agreements that the parties will execute.

Next, the Member and Provider will negotiate one or more lines of credit to be assigned by the Provider to the Member for future transactions (step 310). Each Member will negotiate such line(s) of credit with each Provider with which the Member intends to engage in future transactions. In assigning a credit line to a Member, the Provider will analyze the Member's asset portfolio, credit ratings, and type of financial transactions to be executed by Member. The parties can carry out this step using the interactive e-mail function of the system (provided by e-mail server 140 in FIG. 1) to exchange information during the credit line negotiations.

b. Transaction

Once the Member and Provider have established their relationship and negotiated a credit line, the Member can commence the process of engaging in a financial transaction. The Member must decide on the type of transaction it wishes to execute (e.g., Foreign Exchange Spot, Foreign Exchange Forward, Interest Rate Swap, etc.) and structure the desired transaction (step 320). In this step, the Member will use the interactive trading function of the system (provided by trading server 160 in FIG. 1), including graphic user interfaces and tools. Depending upon the type of transaction, the structure might include pricing variables, an expiration period, a list of Providers to whom the Member would like to request pricing, and any other particulars specific to the Member and the desired transaction. For example, a Member might specify a Foreign Exchange Spot transaction in which the Member desires to buy 1 million Euro currency for U.S. Dollars, with the transaction request set to expire on Jul. 30, 2000 at 11:59 P.M. Pacific Standard Time.

After structuring the transaction, the Member submits a request for pricing of the transaction to one or more Providers (step 330), using the interactive trading function of the system (provided by trading server 160 in FIG. 1). Alternatively, the Member might communicate a request for pricing directly to a particular Provider using the interactive e-mail function of the system (provided by e-mail server 140 in FIG. 1). Such an e-mail communication would include a URL to the structured transaction and request for pricing.

Providers monitor and review the Member's pricing request (step 340) via communications between the automated messaging server 90 and automated processor 20, as will be described below. Such communications result in the posting of pricing requests on a request-monitoring interface hosted by the system. Upon reviewing the transaction and pricing request, including information about the particular Member (unless the Member's identity was not disclosed), a Provider can submit a pricing offer (i.e., price quote) to the requesting Member (step 350). The submission of the pricing offer occurs via a communication between the automated processor 20 and automated messaging server 90, as will be described below. Each pricing offer typically has an expiration period because of constantly changing market conditions, and the Provider may submit modified pricing offers to the Member.

The Member can monitor and review any pricing offers submitted by Providers (step 360) on a monitoring interface hosted by the system. The Member will select one or more pricing offers (step 370) and negotiate with the particular Provider(s) who provided the offer(s). In the present embodiment, such negotiations may occur using the interactive e-mail function of the system (provided by e-mail server 140 in FIG. 1) or through traditional methods (e.g., telephone calls). The number of iterations of negotiations will depend upon the market volatility and other conditions. In other embodiments of this invention, such negotiations may be unnecessary if certain parameters are met by a Provider's pricing offer.

Following negotiations regarding pricing offers, the Member will accept the best pricing offer (step 380) and communicate its acceptance to the Provider using the interactive trading function of the system (provided by trading server 160 in FIG. 1). The Provider will receive the Member's acceptance via communications between the automated messaging server 90 and automated processor 20, as will be described below. Such communications result in the posting of the Member's acceptance of the pricing offer on the request monitoring interface hosted by the system.

c. Post-Transaction

Upon receipt of the Member's acceptance, the Provider sends confirmation of the transaction to the Member (step 390), including specific terms, payment dates, and amounts. The Provider sends the confirmation information to the Member via communications between the automated processor 20 and the automated messaging server 90, as will be described below. The Provider's back-end system 85 provides automated processing of this information.

Following confirmation, the Member and Provider will submit the transaction to their respective back-end systems 85 (step 400) for purposes including internal accounting and payment scheduling. This step can be handled by the system via an automated connection between the automated processor 20 and the back-end system 85. Using their respective back-end systems 85, the Member and Provider schedule settlement of the transaction and future cash flows (step 410).

d. General

Interactive system functionality that can be accessed and implemented at any time by the Member and Provider includes: reporting; portfolio management; risk management; analysis of financial information and market data; e-mail communication with Members, Providers, and system administrators; chat with Members and Providers; message boards; calendaring; and paging.

B. Automated Processing and Transferring of Financial Information

The present embodiment of this invention supports financial transactions between Members and Providers by providing automated processing and transfer of the underlying financial information between the messaging server of the server side and the automated processor of the client side. The system enables such processing and transfer by using a novel tag-based language--FinXML.TM.--that describes financial instrument trades, including transaction-specific data, reference data, and market data. FinXML conforms to the Extensible Markup Language (XML) 1.0 Recommendation (Feb. 10, 1998), World Wide Web Consortium (Massachusetts Institute of Technology, Institut National de Recherche en Informatique et en Automatique, Keio University) <http://www.w3.org/TR/REC-xm1>. The XML Recommendation describes a set of rules for conforming documents that is based around the use of element tags which mark the components of a document or describe the structure of data files as textual documents.

FinXML also conforms to the 1991 ISDA Definitions (and 1998 Supplement) of the International Swaps and Derivatives Association, Inc. ("ISDA") <http://www.isda.org>. The ISDA Definitions provide a set of standard terms for use in privately-negotiated financial derivatives transactions. The element tags and attribute names and values defined in FinXML, as described below, correspond to the terms defined in the ISDA Definitions.

FinXML, as a type of XML vocabulary, is ideally suited to electronic transmission over corporate intranets, extranets, and the Internet (including the World Wide Web), using a transfer protocol such as HTTP/IP. HTTP/IP is intended to transmit text documents such as the HyperText Markup Language ("HTML") documents used to describe the pages to be displayed in a Web browser. XML documents--and, thus, FinXML documents--are similar to HTML documents in that both types of documents are text-based, both consist of a mixture of element tags and data content, and both may include references to other external material.

In a basic financial transaction between two organizations, a financial transaction encoded in XML is sent using a transfer protocol such as HTTP/IP from a client application of one organization to a server of the other organization. The server, in turn, sends back a response that is also encoded in XML.

As will be describe below, the present embodiment of this invention includes a novel method of encoding/decoding financial objects to/from FinXML (or other XML) documents using the automated processor 20 (also known as "Connect Processor") and automated messaging server 90 (also known as "Connect Messaging Server"). In a financial transaction between two organizations, one organization (e.g., a Member) submits a Java object to automated processor 20 which, as will be described below, uses a XML mapping and FinScript.TM.--proprietary stylesheets created in Extensible Stylesheet Language ("XSL")--to create a FinXML (or other XML) document that can be sent using a transfer protocol such as HTTP/IP to the automated messaging server 90 for conversion to an object and processing on the server side. Following processing, the automated messaging server 90 converts objects to a FinXML (or other XML) document and sends the document to the automated processor 20 which, as will be described below, uses FinScript to create a JavaScript program from the FinXML (or other XML) document. In turn, Java objects are created from the JavaScript program and sent to the other organization (e.g., a Provider). XSL, which serves as the foundation for FinScript, is described in the Extensible Stylesheet Language (XSL) Version 1.0 (Mar. 27, 2000), World Wide Web Consortium (Massachusetts Institute of Technology, Institut National de Recherche en Informatique et en Automatique, Keio University) <http://www.w3.org/TR/xsl>.

1. FinXML

In the present embodiment of this invention, FinXML documents are distributed between servers in order to communicate the details of financial transactions and related data. The FinXML syntax provides a general structure for all financial transactions. The financial transactions, in turn, consist of underlying elements, each of which contains attributes and/or other elements.

a. Trade Structure

The basic financial transaction element of the FinXML syntax is a "Trade", of which there are multiple types (described below). The Trade element is the root element for the description of each financial transaction object. The Trade element is contained within the Connect message "payload" component (described below).

FIG. 3 illustrates the structure of a Trade element. Trade element 500 contains at least one pair of "Counterparty" elements 510, which are the parties engaged in the transaction. Each Counterparty element 510 can be an "Internal Party" element 515 or an "External Party" element 520 (described below). Trade element 500 also contains a "Trade Type" element 530, which contains one of the following Trade Type sub-elements:

(1) Foreign Exchange ("FX") Spot

(2) FX Forward

(3) Interest Rate Fixed Float Swap

(4) Interest Rate Float Float Swap

(5) Cap

(6) Floor

(7) Fixed Deposit

(8) Fixed Loan

(9) Float Deposit

(10) Float Loan

(11) FX Option

(12) FX Swap

(13) Cross Currency Fixed Fixed Swap

(14) Cross Currency Fixed Float Swap

(15) Cross Currency Float Float Swap

(16) Forward Rate Agreement

(17) Customized Trade

Each Trade Type element represents a different type of financial transaction, which will be described separately below.

In the present embodiment of this invention, Trade element 500 has the following XML definition:

    <!ELEMENT trade (%parties; , (fxSpot .vertline. fxForward .vertline.
    interestRateFixedFloatSwap .vertline.
    interestRateFloatFloatSwap .vertline. cap .vertline. floor .vertline.
     fixedDeposit .vertline.
    fixedLoan .vertline. floatDeposit .vertline. floatLoan .vertline. fxOption
     .vertline. fxSwap
    .vertline. crossCurrencyFixedFixedSwap .vertline.
     crossCurrencyFixedFloatSwap .vertline.
    crossCurrencyFloatFloatSwap .vertline.
    forwardRateAgreement .vertline. customizedTrade ) )>
    <!ATTLIST trade tradeId CDATA #REQUIRED isBuiltFromParameters
    CDATA #IMPLIED>

          <!ENTITY % counterParty "internalParty .vertline.
     externalParty">
          <!ENTITY % parties "(%counterParty;), (%counterParty;)">

    <!ELEMENT externalParty ((disclosedParty .vertline.undisclosedParty))
     >
    <!ATTLIST externalParty id ID #IMPLIED type CDATA #IMPLIED >

    <!ELEMENT disclosedParty (organization, contactInformation*, address,
    creditRating+ )>

              <!ELEMENT undisclosedParty (creditRating+ )>

    <!ELEMENT internalParty (legalEntity? , book? )>
    <!ATTLIST internalParty id ID #IMPLIED type CDATA #IMPLIED >

          <!-- Foreign Exchange Trades - FXSPOT -->
          <!ENTITY % fxTradeSpec "%trade.elements;
                    , dealtAmount
                    , settledAmount">
          <!ELEMENT fxSpot (%fxTradeSpec; )>
          <!ELEMENT dealtAmount (currency, amount )>
          <!ATTLIST dealtAmount %payReceiver;>
          <!ELEMENT settledAmount (currency, (fxRate .vertline. amount )
     )>
          <!ATTLIST settledAmount %payReceiver;>
          <!ELEMENT fxRate (baseCurrency, baseUnits, quoteCurrency,
          quoteUnits, rate )>
          <!ELEMENT baseCurrency (#PCDATA )>
          <!ELEMENT baseUnits (#PCDATA )>
          <!ELEMENT quoteCurrency (#PCDATA )>
          <!ELEMENT quoteUnits (#PCDATA )>
          <!ENTITY % trade.elements "tradeDate
                    , settlementDate?
                    , valueDate?
                    , externalID?">

        <!-- Foreign Exchange Trades - FORWARD -->
        <!ENTITY % fxTradeSpec "%trade.elements;
                  , dealtAmount
                  , settledAmount">
        <!ELEMENT fxForward (%fxTradeSpec; )>
        <!ELEMENT dealtAmount (currency, amount )>
        <!ATTLIST dealtAmount %payReceiver;>
        <!ELEMENT settledAmount (currency, (fxRate .vertline. amount ) )>
        <!ATTLIST settledAmount %payReceiver;>
        <!ELEMENT fxRate (baseCurrency, baseUnits, quoteCurrency,
        quoteUnits, rate )>
        <!ELEMENT baseCurrency (#PCDATA )>
        <!ELEMENT baseUnits (#PCDATA )>
        <!ELEMENT quoteCurrency (#PCDATA )>
        <!ELEMENT quoteUnits (#PCDATA )>
        <!ENTITY % trade.elements "tradeDate
                  , settlementDate?
                  , valueDate?
                  , externalID?">

    <!-- Interest Rate Fixed Float Swap -->
    <!ELEMENT interestRateFixedFloatSwap (tradeDate, startDate, endDate,
    externalID?, fixedLegDetails, floatLegDetails, events?)>

    <!-- Interest Rate Float Float Swap -->
    <!ELEMENT interestRateFloatFloatSwap (tradeDate, startDate, endDate,
    externalId?, floatLegDetails, floatLegDetails, events?)>

    <!-- Cap -->
    <!ENTITY % capFloorSpec "premium details
              , strikeRate
              , volatilitySpread
              , discountCurve?
              , forecastCurve?">
    <!ELEMENT cap (tradeDate, settlementDate?, startDate, endDate,
    externalID?,
        %genericSpecDetails; , %floatRateDetails; , %capFloorSpec; ,
        events? )>
    <!ATTLIST cap buyer IDREF #REQUIRED writer IDREF #REQUIRED>
    <!ELEMENT premiumDetails ( (premiumPercentage .vertline. premiumAmount )
     ,
    premiumDate )>
    <!ELEMENT premiumAmount (%currencyAmount; )>
    <!ATTLIST premiumAmount %payReceiverAmount;>
    <!ELEMENT premiumPercentage (#PCDATA )*>
    <!ATTLIST premiumPercentage %payReceiverAmount;>
    <!ELEMENT volatilitySpread (#PCDATA )>
    <!ELEMENT discountCurve (#PCDATA )>
    <!ELEMENT forecastCurve (#PCDATA )>

    <!-- Floor -->
    <!ENTITY % capFloorSpec "premium details
              , strikeRate
              , volatilitySpread
              , discountCurve?
              , forecastCurve?">
    <!ELEMENT floor (tradeDate, settlementDate?, startDate, endDate,
    externalID?,
        %genericSpecDetails; , %floatRateDetails; , %capFloorSpec; ,
        events? )>
    <!ATTLIST floor buyer IDREF #REQUIRED writer IDREF
    #REQUIRED>
    <!ELEMENT premiumDetails ( (premiumPercentage .vertline. premiumAmount)
     ,
    premiumDate)>
    <!ELEMENT premiumAmount (%currencyAmount; )>
    <!ATTLIST premiumAmount %payReceiverAmount;>
    <!ELEMENT premiumPercentage (#PCDATA )*>
    <!ATTLIST premiumPercentage %payReceiverAmount;>
    <!ELEMENT volatilitySpread (#PCDATA )>
    <!ELEMENT discountCurve (#PCDATA )>
    <!ELEMENT forecastCurve (#PCDATA )>

    <!-- Loan and Deposit -->
    <!ELEMENT fixedLoan (tradeDate, startDate, endDate, externalId?,
    %genericSpecDetails;
              , %fixedRateDetails; , events? )>
    <!ATTLIST fixedLoan lender IDREF #REQUIRED
              borrower IDREF #REQUIRED>
    <!ELEMENT fixedDeposit (tradeDate, startDate, endDate, externalId?,
    %genericSpecDetails;
              , %fixedRateDetails; , events? )>
    <!ATTLIST fixedDeposit lender IDREF #REQUIRED
              borrower IDREF #REQUIRED>
    <!ENTITY % genericSpecDetails "notionalAmount
                , dayCount
                , paymentFrequency
                , rollDate
                , anchorDate?
                , paymentCalendar
                , dateStub
                , amortizationDetails?
                , compoundingDetails?">
    <!ENTITY % fixedRateDetails " (fixedInterestRate
                .vertline. fxRate)">

    <!-- Loan and Deposit -->
    <!ELEMENT floatLoan (tradeDate, startDate, endDate, externalId?,
    %genericSpecDetails; ,
              %floatRateDetails; , events? )>
    <!ATTLIST floatLoan lender IDREF #REQUIRED
              borrower IDREF #REQUIRED>
    <!ELEMENT floatDeposit (tradeDate, startDate, endDate, externalId?,
    %genericSpecDetails;
              , %floatRateDetails; , events? )>
    <!ATTLIST floatDeposit lender IDREF #REQUIRED
              borrower IDREF #REQUIRED>
    <!ENTITY % genericSpecDetails "notionalAmount
                , dayCount
                , paymentFrequency
                , rollDate
                , anchorDate?
                , paymentCalendar
                , dateStub
                , amortizationDetails?
                , compoundingDetails?">
    <!ENTITY % floatRateDetails "floatingInterestRate
                , firstFixingRate?
                , rateResetCalendar">

        <!-- FX Option -->
        <!ENTITY % fxOptionSpec "tradeDate
                  , settlementDate
                  , externalId?
                  , premiumDetails
                  , expirationDate
                  , deliveryDate
                  , optionType
                  , dealtAmount
                  , strikeRate?
                  , settledAmount
                  , deliveryMode
                  , volatility?">
        <!ELEMENT fxOption (%fxOptionSpec; )>
        <!ATTLIST fxOption buyer IDREF #REQUIRED writer IDREF
        #REQUIRED>
        <!ELEMENT optionType (call .vertline. put )>
        <!ELEMENT deliveryMode (physical .vertline. cash )>
        <!ELEMENT volatility (#PCDATA )>
        <!ELEMENT call (#PCDATA )>
        <!ELEMENT put (#PCDATA )>
        <!ELEMENT physical EMPTY>
        <!ELEMENT cash EMPTY>

          <!-- FX Swap -->
          <!ENTITY % fxSwapSpec "tradeDate
                    , externalId?
                    , nearLegValueDate
                    , farLegValueDate
                    , notionalAmount
                    , (nearLegFxRate .vertline. nearLegSettledAmount )
                    , (farLegFXRate .vertline.farLegSettledAmount )">
          <!ELEMENT FXSwap (%fxSwapSpec; )>
          <!ELEMENT nearLegValueDate (#PCDATA )>
          <!ELEMENT farLegValueDate (#PCDATA )>
          <!ELEMENT nearLegFXRate (fxRate )>
          <!ELEMENT farLegFXRate ( fxRate )>
          <!ELEMENT nearLegSettledAmount (%currencyAmount; )>
          <!ATTLIST nearLegSettledAmount %payReceiver;>
          <!ELEMENT farLegSettledAmount (%currencyAmount; )>
          <!ATTLIST farLegSettledAmount %payReceiver;>

    <!-- Cross Currency Fixed Fixed Swap -->
    <!ELEMENT crossCurrencyFixedFixedSwap (%tenor.elements; ,
    fixedLegDetails , fixedLegDetails , events?)>
    <!ATTLIST crossCurrencyFixedFixedSwap notionalAmount (Yes .vertline. No
     )
    #REQUIRED>

    <!-- Cross Currency Float Float Swap -->
    <!ELEMENT crossCurrencyFloatFloatSwap (%tenor.elements; ,
    floatLegDetails , floatLegDetails , events?)>
    <!ATTLIST crossCurrencyFloatFloatSwap notionalAmount (Yes .vertline. No
     )
    #REQUIRED>

    <!-- Cross Currency Fixed Float Swap -->
    <!ELEMENT CrossCurrencyFixedFloatSwap (%tenor.elements; ,
    fixedLegDetails, floatLegDetails, events?)>
    <!ATTLIST crossCurrencyFixedFloatSwap notionalAmount (Yes .vertline. No
     )
    #REQUIRED>

        <!-- Forward Rate Agreement -->
        <!ELEMENT forwardRateAgreement (tradeDate, settlementDate?,
        startDate, endDate,
                    externalId?, adjustedStartDate, adjustedEndDate ,
                    notionalAmount, dayCount, rollConvention, rollDate,
                    holidayCalendar, fixedInterestRate, interestIndex,
                    fixingDate, rateResetCalendar, premiumDetails? )>
        <!ATTLIST forwardRateAgreement buyer IDREF #REQUIRED>
        <!ATTLIST forwardRateAgreement seller IDREF #REQUIRED>
        <!ELEMENT adjustedStartDate (#PCDATA )>
        <!ELEMENT adjustedEndDate (#PCDATA )>
        <!ELEMENT fixingDate (#PCDATA )>

          <!-- Customized Trade -->
          <!ELEMENT customizedTrade ( (fieldName, fieldValue ) * )>
          <!ATTLIST customizedTrade buyer IDREF #REQUIRED>
          <!ATTLIST customizedTrade seller IDREF #REQUIRED>
          <!ELEMENT fieldName (#PCDATA )>
          <!ELEMENT fieldValue (#PCDATA )>

              <!ENTITY % genericSpecDetails "notionalAmount
                         , dayCount
                         , paymentFrequency
                         , rollDate
                         , anchorDate?
                         , paymentCalendar
                         , dateStub
                         , amortizationDetails?
                         , compoundingDetails?">

          <!ENTITY % fixedSpecDetails "fixedInterestRate .vertline.
     fxRate">

    <!ENTITY % floatingSpecDetails "floatingInterestRate, firstFixingRate?,
    rateResetCalendar">

          <!ELEMENT fixedLegDetails (%genericSpecDetails; ,
          %fixedRateDetails; , events? )>
          <!ATTLIST fixedLegDetails legID ID #REQUIRED >
          <!ATTLIST fixedLegDetails payer IDREF #REQUIRED >
          <!ATTLIST fixedLegDetails receiver IDREF #REQUIRED >

    <!ELEMENT floatLegDetails (GenericSpecDetails; , %floatRateDetails; ,
    event ,>
    <!ATTLIST floatLegDetails legID ID #REQUIRED >
    <!ATTLIST floatLegDetails payer IDREF #REQUIRED >
    <!ATTLIST floatLegDetails receiver IDREF #REQUIRED >

    <!ELEMENT events ((cashPayment .vertline. principalPayment .vertline.
     interestPayment .vertline.
    contingentPayment .vertline. interestCalculation .vertline.
    compoundInterestCalculation )+ )>
    <!ATTLIST events id ID #IMPLIED >

        <!ELEMENT cashPayment (currency, amount, paymentDate )>
        <!ATTLIST cashPayment id ID #REQUIRED
                  type ( Premium .vertline. Fees ) #REQUIRED
                  payer IDREF #REQUIRED
                  receiver IDREF #REQUIRED >

        <!ELEMENT principalPaymentcurrency, amount, paymentDate )>
        <!ATTLIST principalPayment id ID #REQUIRED
                  payer IDREF #REQUIRED
                  receiver IDREF #REQUIRED >

        <!ELEMENT interestPayment (currency, paymentDate, startDate,
        endDate )>
        <!ATTLIST interestPayment id ID #REQUIRED
                  payer IDREF #REQUIRED
                  receiver IDREF #REQUIRED
                  interestType (Coupon .vertline. Swap .vertline. Loan
     .vertline. Deposit .vertline. Other)
                  #IMPLIED
                  calculations IDREFS #REQUIRED >

    <!ELEMENT contingentPayment (underlyingAmount, settlementAmount,
    expirationDate, exerciseBeginDate,
    exerciseEndDate, exerciseRule, exerciseCondition, volatility)>
    <!ATTLIST contingentPayment id ID #REQUIRED
              payer IDREF #REQUIRED
              receiver IDREF #REQUIRED
              optionType (call .vertline. put)#REQUIRED
              deliveryType (deliverable .vertline. non-deliverable)
     #REQUIRED>
    <!ELEMENT underlyingAmount (currency, amount)>
    <!ELEMENT settlementAmount (currency, amount)>
    <!ELEMENT exerciseBeginDate (#PCDATA)>
    <!ELEMENT exerciseEndDate (#PCDATA)>
    <!ELEMENT exerciseRule (#PCDATA)>
    <!ELEMENT exerciseCondition (#PCDATA)>
    <!ELEMENT volatility (#PCDATA)>

        <!ELEMENT interestCalculation ((%interestRate.elements; )?,
        notionalAmount, calculationDate, startDate, endDate, amount?,
        dayCount )>
        <!ATTLIST interestCalculation id ID #REQUIRED
                    resets IDREFS #IMPLIED >

        <!ELEMENT compoundInterestCalculation ((fixedInterestRate .vertline.
        floatingInterestRate)?,
                  calculationDate, startDate, endDate, amount)>
        <!ATTLIST compoundInterestCalculation id ID #REQUIRED
                  resets IDREF #REQUIRED
                  rate IDREF #IMPLIED>

          <!ELEMENT compoundingDetails (calculationFrequency)>

    <!ELEMENT amortizationDetails (amortizationFrequency )>
    <!ATTLIST amortizationDetails amortizationMethod %amortMethod;
    #REQUIRED>

    <!ELEMENT calculationFrequency (term )>
    <!ATTLIST calculationFrequency convention (IMM .vertline. FRN .vertline.
     Eurodollar .vertline.
    Normal ) `Normal`
              endOfMonth (Yes .vertline. No) #REQUIRED >

    <!ELEMENT paymentFrequency (term )>
    <!ATTLIST paymentFrequency convention (IMM .vertline. FRN .vertline.
     Eurodollar .vertline.
    Normal ) `Normal`
              endOfMonth (Yes .vertline. No ) #REQUIRED >

    <!ELEMENT paymentFrequency (term )>
    <!ATTLIST paymentFrequency convention (IMM .vertline. FRN .vertline.
     Eurodollar .vertline.
    Normal ) `Normal`
              endOfMonth (Yes .vertline. No) #REQUIRED >

    <!ELEMENT organization (organizationShortName, organizationName,
    address )>
    <!ELEMENT organizationShortName (#PCDATA )>
    <!ELEMENT organizationName (#PCDATA )>

    <!ELEMENT contactInformation (contactName, (telephone .vertline. fax
     .vertline. telex .vertline.
    email .vertline. url)* )>
    <!ATTLIST contactInformation contactID #REQUIRED
                default (Y .vertline. N ) #REQUIRED >
    <!ELEMENT contactName (#PCDATA )>
    <!ELEMENT telex (#PCDATA )>
    <!ELEMENT telephone (#PCDATA )>
    <!ELEMENT fax (#PCDATA )>
    <!ELEMENT email (#PCDATA )>
    <!ELEMENT URL (#PCDATA )>

    <!ELEMENT address (address1, address2, city, stateProvinceCounty,
    zipPostalCode, country, swiftAddress?)>
    <!ELEMENT address1 (#PCDATA )>
    <!ELEMENT address2 (#PCDATA )>
    <!ELEMENT city (#PCDATA )>
    <!ELEMENT stateProvinceCounty (#PCDATA )>
    <!ELEMENT zipPostalCode (#PCDATA )>
    <!ELEMENT country (#PCDATA )>
    <!ELEMENT swiftAddress (#PCDATA )>

        <!ELEMENT creditRating (agency, rating, country, industryGroup,
        industry )>
        <!ELEMENT agency (#PCDATA )>
        <!ELEMENT rating (#PCDATA )>
        <!ELEMENT name (#PCDATA )>
        <!ELEMENT industryGroup (#PCDATA )>
        <!ELEMENT industry (#PCDATA )>

          <!ELEMENT legalEntity (shortName, description, parent)>
          <!ATTLIST legalEntity id ID #IMPLIED>

    <!ELEMENT book (shortName, name, description, reportingCurrency )>
    <!ATTLIST book id ID #REQUIRED
              type CDATA #IMPLIED >

          <!ELEMENT floatingInterestRate (interestIndex, spread )>
          <!ATTLIST floatingInterestRate id ID #IMPLIED >

          <!ELEMENT interestIndex (currency, term, indexName )>
          <!ATTLIST interestIndex id ID #IMPLIED >
          <!ELEMENT indexName (#PCDATA)>

        <!ELEMENT Message (header, (workflowMsg .vertline. controlMsg )
     )>
        <!ATTLIST Message systemName CDATA #REQUIRED
                  systemId CDATA #REQUIRED
                  version CDATA #FIXED `1.0`
                  test (Y .vertline. N ) #REQUIRED >

          <!ELEMENT header (routing )>
          <!ATTLIST header conversationId CDATA #REQUIRED
                    sequenceId CDATA #REQUIRED
                    sentTime CDATA #REQUIRED >