WO2007033095A2 - Method and system for contract comparison in securities lending transactions - Google Patents

Abstract

Methods and systems for securities lending transactions are disclosed. The disclosed system provides a hub for electronic financial transactions, such as securities borrowing and lending, and facilitates the ability of borrowers and lenders to locate suitable counterparties and engage in direct negotiations in a securities lending transaction. The invention also includes processes that allow users to compare loan contracts for equities and fixed income securities, identify discrepancies in terms, and view and reconcile the discrepancies online. Contract comparison is a reconciliation process that allows two legal entities to compare loan contracts, return records, recall records and collateral records on predefined parameters on a regular basis. The process facilitates the daily mark-to-market process and month-end billing process by identifying and reconciling discrepancies early in the lifecycle of a trade.

Description

METHOD AND SYSTEM FOR CONTRACT COMPARISON IN SECURITIES

LENDING TRANSACTIONS

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Patent Application Serial No. 60/715,574, filed September 12, 2005, the disclosure of which is hereby incorporated by reference in its entirety. This application is a continuation-in-part of co-pending U.S. Patent Application Serial No. 10/461,866, filed June 16, 2003, the disclosure of which is hereby incorporated by reference in its entirety, and which claims priority to U.S. Provisional Patent Application Serial No. 60/389,556, filed June 17, 2002.

BACKGROUND OF THE INVENTION

Field of the Invention

The invention relates to methods and systems to facilitate securities lending transactions for borrowers, sellers and related parties. By providing a central hub through which interested parties can easily locate suitable counterparties and book transactions, this invention avoids the time-consuming and labor-intensive process of matching borrowers and lenders. The invention is characterized, at least in part, by the architecture and design of a standards-based, open, and secure global securities lending platform, or hub, and more particularly to the methodologies in the initiation, processing, settlement of transactions and related back-office operations that such a platform provides for its participants. The invention is further characterized by processes that allow users to compare loan contracts for equities and fixed income securities, identify discrepancies in terms, and view and reconcile the discrepancies online.

Description of Related Art

In today's capital markets, securities seldom lie idle. If not being bought and sold in outright market transactions, securities are frequently lent to parties wanting to borrow them, or used as collateral to raise short-term finance. These transactions include repurchase agreements, securities loans and sell-buyback agreements. While they differ in detail, they nonetheless have many similarities. This family of transactions is genetically described as "securities lending."

Securities lending transactions generally involve the simultaneous or near- simultaneous transfer of securities for collateral. Significant securities lenders include entities such as banks, investment managers, pension funds, mutual fund complexes, endowment funds and insurance companies. Lenders often lend securities to supplement or earn incremental income on their portfolio holdings. Borrowers are generally broker/dealers and banks. Borrowers often borrow securities to facilitate trade settlements, and to support both proprietary and customer trading strategies.

Participants in securities borrowing and lending transactions can be further sub-classified into: Beneficial Owners; Agent Lenders; Broker/Dealers; and External Customers. Beneficial Owners are the true owners of securities. Agent Lenders are often banks that custody the shares of the beneficial owners and represent the beneficial owners in securities lending transaction. Agent lenders often represent more than one beneficial owner, thus creating an aggregate pool of securities to lend.

Agent lenders generally provide administrative services to the beneficial owners such as reporting, corporate actions monitoring, collateral management and billing. Broker/Dealers often have securities borrowing and lending trading desks that coordinate the borrowing of securities from lenders to cover customer and proprietary trading needs such as arbitraging, hedging and short selling. Broker/dealers may also borrow securities to settle transactions that are failing, or to lend them to other broker/dealers.

Securities lending has become a central part of securities market activity in recent years, to a point where the daily volume of securities transactions for financing purposes considerably exceeds that of outright purchase and sale transactions. Securities lending involves the temporary exchange of securities, usually for other securities or cash of an equivalent value (or occasionally a mixture of cash and securities), with an obligation to redeliver a like quantity of the same securities at a future date. Most securities lending is structured to give the borrower legal title to the securities for the life of the transaction, even though, economically, the terms are more akin to a loan. The borrow fee is generally agreed in advance and the lender has contractual rights similar to beneficial ownership of the securities, with rights to receive the equivalent of all interest payments or dividends and to have equivalent securities returned. The importance of the transfer of legal title is twofold. First, it allows the borrower to deliver the securities onward, for example in another securities loan or to settle an outright trade. Second, it means that the lender usually receives value in exchange for the disposition of legal title (whether in cash or securities), which ensures that the loan is collateralized.

In a typical securities lending transaction, a stock or bond is exchanged for collateral between a lender and a borrower for temporary use. Generally, the lender through its lending agent delivers a security to an approved borrower in return for collateral, usually in the form of cash, U.S. Government securities, letters of credit, or other selective forms of non-cash collateral. In most instances, the borrower is a broker/dealer who uses the securities to meet an array of short-term needs, including: avoiding settlement failures, supporting hedging - short selling strategies, and to facilitate arbitrage opportunities.

Collateral is a key element in a securities lending transaction. For use of a security, a borrower provides collateral to the lending agent to secure the borrower's promise to return the security within an agreed upon timeframe. Generally, the collateral requirement for domestic loans is 102% and 105% for international loans. The excess collateral serves as a safeguard against counterparty credit risk in the event of a borrower default, which could necessitate the collateral being liquidated and repurchasing the loaned security. Monitoring the collateral adequacy, known as performing a "mark-to-market," occurs daily. Should the collateral fall below 100% of its market value, additional collateral is requested from the borrower to restore the value to its appropriate level.

The lending agent agrees to pay interest, known as the rebate, to the borrower for the use of the cash collateral. The amount of the rebate reflects the intrinsic value of the loaned security - keeping in mind that some securities are more highly sought after than others. The higher the demand is for the security, the lower the rebate that will need to be paid. The cash collateral is then invested by the lending agent in accordance with the lender's investment guidelines. The goal is to earn a higher yield on the reinvestment of cash collateral than the rebate promised to the borrower. The earnings generated above and beyond the rebate amount, referred to as the "spread," represent the profit in the transaction. In a non-cash collateralized lending transaction, the borrower and lender negotiate a premium (or a flat fee) to be paid in place of the rebate. Currently, there are two primary ways in which the securities lending operations are transacted. First, manual transactions are done by traders and other personnel of lending and borrowing entities communicating by traditional avenues such as phone, fax or email. This process is inherently ineffective and prone to human and other errors that result in the creation of inconsistent data or other discrepancies or even in failed trades. Second, point-to-point connections permit an entity that intends to either borrow or lend securities to set up a connection with a counterparty and communicate with that party using a pre-determined protocol. This will result in a plethora of protocols and sometimes even technology platforms and infrastructures that a firm ends up building and supporting. This creates a technology environment that is very expensive and cumbersome to maintain, eventually working to the detriment of the organization in most cases.

Due to the aforementioned peculiarities of securities lending transactions, present electronic systems for carrying out securities and commodity trades have proven inadequate. One such system used, for example, for over-the-counter trades is the mstinet system, as described in U.S. Patent No. 3,573,747. The Instinet system includes a series of terminals, each accessible to a member and a central computer. Each member may submit for display a firm offer to buy or sell a given number of shares of a certain security at a stated price. The member may also submit bids or offers of a security without price. This information, minus the submitter's identity, is displayed to all members, in a price sequence. Any member may respond to an offer through the negotiating option of a counteroffer and the system will allow private communications between the two members until and if an agreed upon price is reached. Alternatively, a member may submit an acceptance of any offer displayed to all members. In either option, the system executes orders when a buyer and seller have agreed upon a price. The parties to an executed trade deliver the shares of stock and purchase price to a designated bank for a conventional clearing operation. If a bid and an ask are submitted at the same price, the system will consummate the trade.

The Instinet system is not designed to address the unique aspects of securities lending. The Instinet system does not provide potential borrowers or lenders the ability to transmit, in real-time, their availability and parameters for a desired transaction, making the process of matching amenable counterparties time-consuming and labor-intensive, especially when the parties reside in disparate geographic locations and time zones.

Unlike traditional securities transactions, such as the sale or purchase of stocks, bonds, etc., stock loan transactions remain "open" after the initial transaction is completed, i.e., the loan of stock for use as collateral in a financial transaction.. It is, therefore, desirable to have a system that would allow the users to program business rules into their own proprietary system to trigger the generation of autoborrow and availability messages, based on a set of parameters such as the positions or requirements of specific securities, to allow for the recall and return of loaned securities, mark-to-market comparisons, and other features specific to the field of stock loan (i.e., securities lending) transactions. As well, it would be desirable to have a system that operates using an open protocol, to allow system users to integrate their systems, whether proprietary or otherwise, into the system in real-time.

Moreover, as previously mentioned, existing systems cannot adequately address the needs of those engaged in securities lending transactions. As opposed to outright sale and purchase of securities, a securities lending contract remains open for a significant period of time. Hence, a system that intends to facilitate securities lending should store these transactions for a much longer period, than that is required for the regular trading of equities. The metrics associated with the loan contracts need to be periodically compared and reconciled.

SUMMARY OF THE INVENTION

The invention relates to a system and method for facilitating securities lending transactions, comprising at least an application tier, a messaging tier and presentation tier. These tiers form a hub that may be in electronic communication with a public or proprietary distributed network and provide a centralized system for communication between securities trading firms, brokers, and other participants in a process for lending securities.

A member firm wishing to engage in a securities lending transaction may initiate a "firm request" indicating a desire to loan or borrow securities. The request is transmitted via the distributed network, via the hub, and is intercepted by the messaging tier. The messaging tier forwards the request to an application tier to validate the syntax of the message and/or process the request. Provided that the request includes a parameter for engaging in a securities lending transaction, the application tier may transmit the request back to the messaging tier for distribution to suitable counterparties.

Although many protocols for message transmission can be adapted for use with the invention, the requests may be formatted in the Extensible Markup Language (XML) or the Securities Lending Markup Language (SLML). Other embodiments of the invention relate to methods and systems for comparing loan contracts for equities and fixed income securities, identifying discrepancies in terms, and viewing and reconciling the discrepancies online.

As will be realized, this invention is capable of other and different embodiments, and its details are capable of modification in various obvious respects, all without departing from this invention. Accordingly, the drawings and descriptions are to be regarded as illustrative in nature and not as restrictive.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an illustrative embodiment of the hub of the present invention.

FIG. 2 shows an illustrative embodiment of message flow using two-channel transmission.

FIG. 3 shows an illustrative embodiment of a participating lender making an availability broadcast.

FIG. 4 shows an illustrative embodiment of parties engaging in one-to-one negotiations.

FIG. 5 shows an illustrative embodiment of the autoborrow feature of the present invention.

FIG. 6 shows an illustrative embodiment of the contract comparison feature of the present invention. FIG. 7 shows an illustrative embodiment of mark-to-market comparison feature of the present invention.

FIG. 8 shows an illustrative embodiment of the billing comparison feature of the present invention.

FIG. 9 shows an illustrative embodiment of the Return/Recall feature of the present invention.

FIG. 10 shows an illustrative embodiment of the trading feature of the present invention.

FIG. 11 shows an illustrative embodiment of the autoborrow feature of the present invention.

FIG. 12 shows an illustrative embodiment of the initiation of the autoborrow feature of the present invention.

FIG. 13 is a block diagram of the contract comparison process from a file input and output perspective in one embodiment of the invention.

FIG. 14 is a block diagram showing how the system attempts to match up data in the counterparty files based on six different levels of information ("steps") in one embodiment of the invention. For purposes of clarity and brevity, like elements and components will bear the same designations and numbering throughout the Figures.

DETAILED DESCRIPTION OF THE INVENTION

In one embodiment, contract comparison may be run as a service module that is integrated into a larger securities lending system. One operational example of a larger securities lending system is the EQUILEND system ("System" or "Platform") by EquiLend Holdings, LLC of New York, NY. The System provides a global securities lending hub/platform to eliminate the inefficiencies associated with the current approach and to create and implement specific methodologies for the benefit of its participants.

The System allows for the elimination of redundant IT infrastructure, a uniform protocol (such as an XML-based protocol called SLML) to communicate with all trading partners, a single open standards-based infrastructure to transact with all trading partners, ease of integration of their proprietary systems with the hub in real-time, the ability to define business rules which operate on the data in their proprietary systems and automatically initiate trades through the hub/platform, reduction of IT complexity and associated costs, and increased throughput with regard to the number of transactions in a given time period.

The System is characterized, at least in one embodiment, as a hub-based platform that provides a browser-based user interface. Although the system can be used over any local-area or distributed network, the Internet can be used to avoid the expense of a proprietary transport network. This standards-based platform may use an XML-based protocol, such as SLML, to provide a symmetrical, non-biased system with equal capabilities for borrowers and lenders participating in securities lending transactions.

A preferred embodiment of the overall system uses the Securities Lending Markup Language (SLML) to serve as the uniform protocol used to exchange messages between participant firms. SLML is based on XML (Extensible Markup Language), the popular open-standards language for complex data sharing between disparate applications. XML allows users to organize document elements (words, pictures, etc.) based on a structural hierarchy that can be easily exchanged over the World Wide Web. It is independent of any underlying programming language, transport mechanism or messaging protocol and allows foil flexibility.

SLML, like XML, is interoperable across platforms. SLML supports the seamless exchange of electronic data between and within institutions using diverse technology platforms. Using SLML and core XML-compatible technologies, securities lending data can be exchanged between applications within an individual firm and throughout the industry.

Further, SLML is STP-Oriented. Firms can benefit by improving the overall efficiency of the securities lending process as they seek to implement straight-through processing (STP) in order to reduce trade failures and shorten transaction processing cycles. With a standards-based architecture, the costs of implementation and upgrading to new technologies with SLML may be reduced. Each XML message is sent as asynchronously to perform a discrete operation, trading or otherwise, from the member to the Hub. The message will have a header section that will specify the recipient/s to which the message is intended. The Hub application processes the message and sends one or more messages to the specified recipient and a confirmation message, if requested, is sent to the member who initiated the transaction.

In this model, the participant firms may send messages to the hub/platform and/or their trading partners. All operations including the initiation, negotiation, confirmation and rejection of trades, posting of available securities and the back- office comparison operations involve the exchange of messages between the platform and the member firms. A high-level overview illustrating one embodiment of the function of the hub and the communication that is handled by the hub is shown in FIG. 1.

Such a system can be best described as adhering to an "n-tier" architecture and thus consisting of a set of tiers that work with each other to fulfill the responsibilities of the system. For the purposes described here, a tier is a collection of one or more software components that provide a high-level technical function or feature (e.g. a database tier providing the ability to store, update and retrieve data). Another commonly used term to describe a set of components is a 'layer' and hence these two terms ('tier' and 'layer') are used interchangeably in this document.

The overall system includes a database tier that acts as the storage for all data, both static and dynamic, that is essential for the functioning of the platform. The data includes set-up data such as information about the members, their users, their relationships with other members and the agreements between them in relation to the various back office functions. It also includes highly dynamic data such as information about the various transactions, the parties, securities and other attributes of these transactions. This tier can be implemented using any Relational Database Management System (RDBMS) such as Oracle, Sybase and MS SQL Server. The overall system also includes an Application Tier that is the implementation of the business rules necessary for the initiation, validation and execution of the securities lending transactions between the members. This tier consists of one or more modules that encapsulate the set of specific functions necessary to perform an action or satisfy a request related to each functional area (such as autoborrow or availability). Typically, these modules interpret a business request semantically to perform a series of steps that will result in the creation/update or retrieval of data from the database (by sending the appropriate requests to the database tier) and the creation of response messages that will be transmitted by the messaging tier. In that sense, this tier is the heart of the platform and acts as the interface to the business functionality to the other tiers. Both the presentation and messaging tiers use this tier to satisfy the requests originated by either the user actions in the browser or by an XML message sent by a member's proprietary system.

A messaging tier acts as the hub's interface to the member's proprietary systems. Members conduct transactions with their counterparties by exchanging messages with the system platform. Each XML message has a type, subtype and data. The type and subtype indicate the business function (autoborrow, negotiation, contract-compare, login etc.) the message intends to perform and the data that is pertinent to that specific business function. These messages are sent to and received by entities known as 'queues'. Simply described, queues are objects that hold messages. A queue that is local to the program that is sending a message is known as a local queue and a remote queue is one that is located in a remote environment. In the case of the present system, there are a number of local queues to receive messages from the members, and a number of remote queues that actually point to local queues in the member's environment and which are used to send messages. The system's infrastructure guidelines specify a number of queues and the mechanism by which these queues need to be configured, hi a simple configuration, there will be one queue per member per business function. For example, for a given member organization there will be 'n' number of queues, where 'n' is the number of business functions that the system supports. Hence, if a member B wants to send an autoborrow message to member A₅ the message would have to be sent to the queue that is designated to receive autoborrow messages for member A. If this message is sent to any other queue, it will be deemed an invalid message and sent back to the sender. In this case, the system would send a 'Reject' message to the queue. Figures 11 and 12 illustrate examples of the use of the autoborrow feature of the present invention and the initiation of the process.

The messaging tier acts as the interface that provides core messaging, both of sending and receiving XML messages, to and from the other tiers. The messaging tier receives XML messages, parses them and extracts valid values from various fields. It then determines the appropriate component in the application layer that handles this business process and interacts with that component to perform the necessary function. Conversely, the application tier uses the functionality provided by the messaging tier to construct valid XML messages and send them to the intended recipients.

Most business transactions supported by the system can potentially involve the retrieval and sending of multiple messages to and/or from multiple parties and, hence, this tier needs to be robust, reliable and scalable. Any messaging product that supports the fast, secure, guaranteed and asynchronous delivery of XML messages can be used to implement this tier. A typical scenario will help illustrate the interaction between the tiers and clarify the division of responsibilities between these tiers/layers. When a request for autoborrow is received from a member's proprietary system as a SLML document, the messaging layer retrieves the message from the queue, performs basic security checks on the message (username/password or a token associated with the message), determines whether the message originated from a valid member, and whether the message has been retrieved from the appropriate queue. The messaging layer then determines the appropriate component in the application layer that can handle this request and hands the request over to that component. The components in the application layer interpret the message functionally and thus determine the counterparties to whom this autoborrow request should be sent and calculates any other values that need to be filled in the response messages. The application layer then invokes the messaging layer to send a request to the designated counterparties. A similar sequence of actions takes place when the initial request originates from a user action through the browser, instead of a participating firm's proprietary system.

In that case, the only thing that differs is the fact that the presentation tier intercepts the HTTP request instead of the messaging layer. It should be noted that in a preferred embodiment of the system, most real-time messages that need to be sent in bulk will originate from a member's proprietary system and thus will be intercepted by the messaging layer.

The presentation tier is the layer that deals with the user interaction portion of the application. The system's user interface is an easy to use web-based interface. Users can perform various business and related functions by navigating through the screens in their browser. Each such action results in one or more HTTP requests that are sent to the web server and eventually reach the presentation tier. The presentation tier intercepts requests made by the user through the web-browser, parses and validates them and works with the application layer to perform the function desired by the user. The present system supports browsers including Internet Explorer and Netscape. It is preferred that the most recent version of each browser is used. With Internet Explorer, it is preferred to use a version at least as recent as version 5.5.

The communication between the member firms and the hub are based on guidelines defining point-to-point interactions between member firms. Each member firm, however, can communicate with multiple member firms via the hub, and a member firm can receive and respond to multiple communication requests.

Since the communications system of the present invention may be based on an open-standard protocol, such as XML, member firms can use various commercial software packages for creating and handling their XML messages and responses. In an embodiment of the invention, member firms are responsible for building the actual XML messages (with correct syntax and inputs) and then sending the message to the hub, to initial an XML request. Member firms then use the XML response received from the hub in their interactions with their end-users. The member firms then aggregates data received from multiple XML requests or, when communicating with multiple firms through the hub, aggregates the data received from all responses. The member firm may then store the data for later use, such as for forwarding to an end- user.

The system provides means for servicing XML requests received from member firms. These means, such as an MQ handler application (such as the MQ Series Middleware Application sold by IBM Corporation of Armonk, NY), process accepted XML requests, construct appropriate XML responses, and send responses back to member firms. Incoming XML requests may also be validated by verifying the XML request syntax, input data and access permissions before processing the request. When a request is received from a member firm that requires aggregation of data, the system may aggregate data from multiple sources (which may be located locally or anywhere on a distributed network which is in communication with the system) to provide the appropriate response.

The message queue design of the present system supports the transmission different types of messages using a two-channel transmission from the member firm's queue manager to the system message queue manager and back. This type of system may separate high-priority messages from bulk data transmission and is illustrated in

FIG. 2.

The messages sent between the member firms and the system hub permit potential borrowers and lenders to communicate and identify one another, as part of the process of beginning a securities lending transaction, as shown in FIG. 3. For example, a lender may wish to locate suitable counterparties. Using the present system, the lender sends an availability broadcast from their own proprietary system to the system hub or from a browser that includes software, applets, scripts, etc. for communicating with the system hub in an appropriate protocol. The availability broadcast may be tailored to include particular criteria set by the lender, such as the security they wish to lend, number of shares, financial terms, etc. The system hub can retransmit the availability broadcast to any or all member firms or browsers in communication with the hub. Borrowers who agree to the terms set forth in the availability broadcast may then choose to enter into a securities lending transaction with the lender or enter into negotiations over the terms of the securities loan. One aspect of the invention is the ability for users of the system to engage in one-to-one negotiations. When creating an order, a trader can choose to send the order to a single counterparty or to multiple counterparties. If the trader chooses to send the order to multiple counterparties, the system automatically generates a unique order with its own ID for each counterparty. Because the initiating trader must negotiate each order separately, this is referred to as Simultaneous one-to-one Negotiation. Recipients cannot see the orders sent to the other counterparties. However, if the initiator invokes Total Quality Management or enables Deal Disclosure when creating the order, then recipients can tell that an order is part of a Simultaneous one-to-one Negotiation from the following: 1) the system adds a message indicating a Simultaneous Negotiation to each recipient's Activity Monitor; and/or 2) on the Negotiation home page in the user's browser, the system adds a Simultaneous Negotiation icon to the row for the order. One to one negotiations are illustrated in FIG. 4. hi a preferred embodiment of the invention, text messaging is supported between all parties, although the system is equally well-implemented when text messaging is available between limited parties (i.e., those accessing the system via a browser interface).

With the Total Quantity Management feature of the invention, the system manages the total quantity for all orders in the Simultaneous Negotiation. When the

Deal Disclosure feature is enabled, counterparties who meet or exceed the terms of the original order will receive Deal Disclosure information for each accepted order.

Although all orders in a Simultaneous one-to-one Negotiation are unique, they will have the same "Simul Negot" ID. Thus, when viewing the Negotiation home page in the user's browser, the initiator can group orders in the same Simultaneous Negotiation by sorting by the Simul Negot ID. Total Quantity Management is a feature of Simultaneous one-to-one Negotiation that prevents traders from over-committing securities to multiple counterparties. If a trader creates a firm order for multiple counterparties and enters a Total Max Quantity value that is less than the sum of the Max Quantity values for all counterparties, then the system will manage the total quantity for all orders in the Simultaneous Negotiation. This means that if one counterparty accepts an order that is part of the Simultaneous Negotiation, the system will automatically update the Max Quantity values in all remaining orders (as long as the total quantity being managed falls within the range defined by the original order). The system will only manage the total quantity if counterparties accept their orders directly after receiving them. If a counterparty negotiates or declines the order instead of accepting it, their quantity is no longer managed. Once the total quantity of accepted orders reaches Total Max Quantity, the system automatically cancels all remaining orders.

For example, suppose a trader wants to lend a maximum of 10,000 shares of a particular security. The trader creates a firm order for three counterparties, setting Total Max Quantity to 10,000 and setting Max Quantity to 10,000 for each of the three counterparties. If one counterparty accepts the order with a quantity of 4,000 shares, then the system automatically updates the other counterparties' orders, setting

Max Quantity to 6,000. If a second counterparty accepts an order with a quantity of 6,000 shares, then the system automatically cancels the third counterparty's order.

Deal Disclosure is a feature of Simultaneous one-to-one Negotiation. Because the initiating trader negotiates each order in a Simultaneous Negotiation individually, the other counterparties do not know the terms of each other's offers during negotiation. However, if the initiator chooses to enable this feature, then counterparties who meet or exceed the terms of the original order will receive Deal Disclosure information for each accepted order when negotiation has ended for all of the orders. Deal disclosure details include the quantity, some price information (such as the dividend rate, rebate rate, fee, etc.), some collateral information and some date information. Deal disclosure does not reveal which counterparties were involved in the Simultaneous Negotiation. Deal disclosure can only be enabled if the order is initiated as a soft order.

The autoborrow feature of the system permits participants to initiate orders that target all of their counterparties using a single messaging protocol. When a participant's internal system initiates an autoborrow request, the present system manages creation of firm orders based on bilaterally agreed schedule information and use of chaining rules. The lender may respond to orders (autoborrow requests) in several ways: the lender may accept, accept partially, reject with reason, etc., the order, based on loan availability and/or their desire to lend at the requested terms. An embodiment of the autoborrow process is illustrated in FIG. 5.

Chaining Rules can be used by the initiator of an Autoborrow transaction to specify the sequence and timing for sending Autoborrow Orders to multiple counterparties. Chaining Rules also specify which Autoborrow Schedule to use when generating an Autoborrow Order. Only the initiator of an Autoborrow transaction can set up and maintain Chaining Rules. Counterparties receiving Autoborrow Orders cannot tell whether the orders use Chaining Rules. Chaining rules also allow the initiator to specify different legal entities from their organization as the initiator of the order. This allows a single Autoborrow Record to be directed to counterparties from different legal entities within the initiator's organization. AU Autoborrow Records in the same batch preferably use or not use Chaining Rules. When using Chaining Rules, each record can use a different Chaining Rule.

A unique feature of the system integrates the 'Autoborrow' and 'Negotiation' processes for the convenience of the participants. This feature allows the users to specify that certain Autoborrow Orders that are rejected be re-issued as One-to-One Orders with a different set of parameters than they had in the Autoborrow batch. These orders can be automatically generated and submitted by the system based on previously saved templates thus enabling the members to negotiate the terms on those rejected orders on a one-on-one basis with their counterparties.

The system may also be provided contract comparison functionality. This feature will be described in more detail below, but an exemplary illustration of the contract comparison process of the system is shown in FIG. 6. This feature of the invention permits counterparties to bilaterally agree on comparison criteria and file submission time. Each participant then files at the pre-determined time for comparison. The system runs the comparison and each participant receives a comparison report that includes any discrepancies between the contracts (e.g., broken records, matched records, unmatched records, etc.) The report may be sent to each participant in XML format that can be entered into their proprietary system, if desired.

Each participant can view and reconcile any discrepancies, or breaks, via a browser, as well.

The system may also provide mark-to-market comparisons, as illustrated in FIG. 7, and billing comparisons as illustrated in FIG. 8. FIG. 9 illustrates an exemplary embodiment of the return/recall aspect of the invention. A Loan Recall is the process through which a lender requests the return of securities from the borrower. The present system facilitates this process by providing several vehicles for a lender to recall stock from a borrower and tools for both lenders and borrowers to manage their recall flow until the process is complete.

For example, this system provides lenders with the ability to communicate loan recalls more efficiently via online notifications, minimizing failure to receive notification. Additionally, this functionality provides the opportunity to communicate with counterparts both on and off the present hub-based system

Adopting the Securities Industry Association ("SIA") Automated Recall Management System ("ARMS") standard, which is employed in a preferred embodiment of the invention, will benefit all parties in a transaction according to the present invention, by providing one mechanism for Recall management for all participants. Linking Returns to Recalls can help minimize discrepancies between counterparties. Further, offering a single platform for counterparties to review contracts, recalls and returns will provide a better audit trail that traces back throughout the lifecycle of a contract.

By way of illustration, the present invention may handle Recalls both for transactions originated within the securities trading system of the present invention and for transaction originated outside of the system. Recalls can be identified by a transaction identifier ("ID") when possible. The system will link loan returns to trades, loan recalls to trades, and returns to recalls, through the ID. An ID may be assigned to each transaction the system handles, not just those for which a recall/return is requested. In most instances, IDs will be generated for loans made outside of the system during the contract comparison process. This process is critical for most effective use of Recall and Return functionality. Since Recalls result in the return of securities by the borrower, these returns are implicitly "tied" to the recall process. Functionality may exist for a borrower to Return against a specified Recall, and in this situation, the Return is tied to the Recall through a system-issued Recall ID. Returns that are not initiated as a result of Recall will not generally be tied to any Recall ID.

It is assumed that a specific reason code will be allocated by the DTC for inclusion on return settlement for Returns that are the result of Recalls. The present system need not provide negotiation functionality for Recalls. Modifications of a Recall may be restricted to the lender, and in this case, the lender might only reduce the quantity of securities being recalled. Negotiations related to the terms of the Recall and discrepancy resolution preferably are handled outside of system. Once resolved, the lender may choose to cancel the existing Recall and send a new Recall notice with new Recall terms. If the quantity needs to be increased (e.g. due to a corporate action), the Lender should cancel the original Recall and initiate a new one.

Recalls can be rejected by the Borrower for a variety of reasons. Loan Recalls may not have expiration periods. The Recall will be considered outstanding until either it is satisfied by a return, cancelled by the lender, or a buy-in is issued against it.

The system may also support a holiday calendar for all markets where participants trade. AU date calculations (including the Recall Effective Date and the Recall Due Date) may take holidays into considerations, and a date can be set for the next business day following a holiday. The holiday calendar data will be supplied by a leading vendor and maintained by automated processes and, where necessary, manually by the system's operators or other parties. Weekends should also be accounted for.

The system may also provide the ability to indicate Recalls vs. Termination Notices by allowing the initiator of a Recall to specify whether the Recall terminates the contract. When a Buy-In execution notice is sent for a partial amount against the Recall, the original Recall quantity is decremented by this partial amount, and the Recall is still valid for the balance.

Recalls may utilize a set of "states" which will be used throughout the lifecycle of the recall, from initiation, through actual receipt of the securities via the Return. These states are defined below, and can be used as the cornerstone upon which key functionality will be based:

Sent: Recall notification has been issued by the lender, but has not been acknowledged by the borrower, and does require an Active acknowledgement by the borrower.

Only applicable in cases where active acknowledgement is being used. Recalls that are using the Passive acknowledgement model will not use this state.

Accepted: A Recall notification that has been accepted by the borrower, indicating that they have received the Recall.

Recall notifications that use the passive acknowledgement model will move immediately into the Accepted state. Recall notifications that use the active acknowledgement model require an Active acceptance to move into the Accepted state.

Rejected (with reason code): A Recall notification that has been rejected by the borrower for one of the pre-defined reasons that the SIA has outlined. Recalls can be rejected for one of these reasons, although the system operator may choose to define additional parameters for the system to recognize as acceptable reasons.

Pending Return: A Recall against which a Return(s) has been setup for the entire Recall quantity.

Closed: A Recall that has had the requested securities returned using the system's Return functionality or another vehicle to initiate a return. The approach and methods that the system will use to determine when to close a Recall are outlined, as follows:

Cancelled: A Recall that is cancelled by the lender. Once a Recall is cancelled, it cannot be accepted, rejected or modified.

Bought-In: If the lender does a buy-in for the securities, then the Recall will move to a state of bought-in.

For system participants using the Recall functionality, participants should compare Recall records nightly. This ensures that both counterparties have the same information regarding outstanding Recalls.

Contract Comparison Module As briefly described above, contract comparison is a reconciliation process that allows two legal entities to compare loan contracts, return records, recall records and collateral records on predefined parameters on a regular basis. The process facilitates the daily mark-to-market process and month-end billing process by identifying and reconciling discrepancies early in the lifecycle of a trade.

In one embodiment, users may compare contracts, identify discrepancies ("breaks") in terms, and view and reconcile the discrepancies online. Preferably, the online contract comparison interface is a browser-based application that provides interactive reconciliation. As previously discussed, a user preferably accesses the system using Internet Explorer version 5.5 or greater on a remote terminal, such as a personal computer (PC) with an Internet connection.

In a preferred embodiment, contract comparison is composed of two stages. First, the system associates records in one file with corresponding records in the counterparty file ("matching"). Second, the system compares the values in specific fields across the two users' corresponding records ("comparing").

In one exemplary embodiment, the contract comparison process is a daily process that runs at a pre-determined time. Each day, as defined in the Timetable, the

System locates the two Users' files and validates the records. Records that pass validation are matched with the corresponding records in the other file. Corresponding records are compared and discrepancies are identified. Data is then updated in the System transaction database, so that it reflects current and accurate data for the contracts. At the end of the comparison process in one exemplary embodiment, the System creates and sends four XML messages to the two users with the results of the contract comparison. The four messages contain the following: Records that matched and had no discrepancies (Matched); records that matched and had discrepancies, or had no matching records in the counterparty file (Broken); records that did not pass validation (Invalid); and records that had data errors that prevented the System from updating the database (Error).

hi one embodiment, users may have one or multiple contract comparison processes each day.

FIG. 13 illustrates the contract comparison process from a file input and output perspective in one embodiment. To begin the contract comparison process, both users will send the System the data related to contracts, collateral, recalls, or returns, as specified in the contract comparison protocol. At the end of a contract comparison run, the System sends the results directly to the proprietary systems of the two users, in four XML messages containing the original data submitted to the System sorted by invalid, broken, matched, and error records. Additionally, at the end of the comparison process, a notification is sent to the Activity Monitor of both users to notify them that the contract comparison process has completed.

Matched Records. The matched records go back to the sender of the record. These are records that matched with the counterparty's records and were compared successfully.

Broken Records. The broken records are records that matched with the counterparty records but did not compare successfully and therefore generated breaks. These can also include records that did not match with any record (orphan records). Each User receives back his or her own records and the counterparty's corresponding records.

Invalid Records. The invalid records are returned to the sender. This includes records that were an invalid data type, or were missing required fields. Each User will receive back only his own records.

Error Records. Error records are records that had data problems after initial validation (the System was unable to insert them into the System database, such as a record with an invalid date). With the Error Record file, each party receives back only their own records. Error records never have a new unique identifier ("EquiLend ID").

Before the match and compare process can begin, Users preferably establish three pieces of static data: a Bilateral Relationship with the counterparty's Legal Entity; a Profile, and a Timetable. The Bilateral Relationship is established between the two Users' Legal Entities, and enables the two parties to transact contract comparison with one another. The Profile defines the fields which will be matched and compared, while the Timetable determines the time at which the match and compare process runs. A Timetable may be associated to one Profile. Both Users preferably submit their contract comparison files via XML messaging to the System prior to the start time set in the Timetable.

When the System receives XML messages containing the contract comparison records from the two Users' proprietary systems, it extracts the fixed format text messages and stores them. At the time defined in the Timetable, the System looks in the directory for the files, and validates the data contained in the files.

If any record in the file has an incorrect record length, the System stops the comparison process and sends an Activity Monitor message to inform both Users.

The Activity Monitor message will indicate that the comparison process has aborted due to an incorrect record length but it will not identify the specific record. One record with an incorrect record length can prevent a run of thousands of valid records.

Records that fail data-type validation may be stripped out and put in the

Invalid Records Message sent to the User. Invalid records are not processed, but they do not prevent a comparison run as an incorrect record length does. Records are invalid if any numeric fields contain alphabetical data. For example, a record will be invalid if: the EquiLend ID field contains any alpha characters (e.g., "aθl"); the Contract Price field contains any alpha characters (e.g., "3.99a").

After validation of records, the System matches records in one file with the corresponding records in the other file, so that comparison occurs between records for the same contracts. In order to compare records, those records are preferably matched by the System. As described in the following section, there are six different levels whereby the System looks for matches.

Once records have been matched, and are undergoing the comparison process, if records fail to update the database, they may be stripped out of the comparison process and put in the Error Records Message. Examples include: a record contains an invalid EquiLend, Recall, or Return ID (i.e., the ID on the record does not appear in the System database); matching records contain the same invalid data for a date or numeric field that is compared; and matching records contain no data for one of the following fields — Record Type, Borrow/Loan Indicator, Trade State - these fields are preferably not allowed to be 'null' or empty in the System database.

Turning to FIG. 14, the System attempts to match data in the counterparty files based on six different levels of information ("steps"). The goal is to link a User's record(s) with her counterparty's record(s). Like records need to be associated ("matched") before the information within them can be compared to determine if there are any breaks. If the System cannot match records on Step 1, it will proceed to Step 2. If records do not match on Step 2, it will proceed to Step 3, and so on, through Step 6. If records remain that cannot be matched in Step 6, then such records are considered orphans.

In Step 1, the System may match records by one of two sets of criteria. In one embodiment, files submitted with older versions of an XML protocol may match only on EquiLend ID and Record Type. For Users who wish to continue matching on these two criteria, they may indicate they are working with older versions of a protocol on their records and their records will match in Step 1 based on EquiLend ID and Record type. These records can be matched with other Users who use later versions of a protocol.

In one embodiment of the protocol, the System can also identify recalls and returns with specific identifiers. Many Users will choose to match records on EquiLend ID, Recall ID and Return ID. These Users may identify they are matching with later version protocol criteria and their records will match up when IDs match. Users matching using an older protocol version versus a newer protocol version may submit a different standard record length. The Users' records may be co- mingled and matched up to each other's records. If the records matched in Step 1 break on Quantity, the existing EquiLend IDs may be removed and placed in the Previous EquiLend ID field and the records will continue onto Step 2.

Any records that either did not match in Step 1, or matched in Step 1 but broke on Quantity, may proceed to Step 2. Records may be matched in Step 2 based on four criteria:

1. Non-aggregated unit quantity or the quantity on the individual records

2. Stringent Criteria or those fields on the profile that preferably match:

Your Legal Entity Counterparty Legal Entity Borrow/Loan Indicator Security ID Security ID Type Collateral Type Collateral Currency Record Type

3. Optional match criteria that has been bilaterally approved by both Users in the profile

4. Super-stringent criteria that have been bilaterally approved by both Users as compare fields in the profile. The purpose of this is to increase the number of matches by matching records in a more logical order (i.e., matching up records with like rates, dividend rates, etc.): Rate Fee

Dividend Rate

Rebate Payable or Receivable If records match on Step 2, they may be given an EquiLend ID.

Any records that did not match in Step 2 may proceed to Step 3. Records may be matched in Step 3 based on four criteria:

1. Aggregated unit quantity or the quantity on a combination of records the System logically grouped together based on the following match criteria.

2. Stringent criteria or those fields on the profile that preferably always match:

Your Legal Entity

Counterparty Legal Entity Borrow/Loan Indicator

Security ID

Security ID Type

Collateral Type

Collateral Currency Record Type

3. Optional match criteria that has been bilaterally approved by both Users in the profile.

4. Super-stringent criteria that have been bilaterally approved by both Users as compare fields in the profile. The purpose of this is to increase the number of matches by matching records in a more logical order (i.e., matching up records with like rates, dividend rates, etc.). Rate Fee

Dividend Rate

Rebate Payable or Receivable If records match on Step 3, they will be given an EquiLend ID.

Any records that did not match in Step 3 may proceed to Step 4. Records may be matched in Step 4 based on three criteria:

1. Non-aggregated unit quantity or the quantity on the individual records.

2. Stringent criteria or those fields on the profile that preferably always match:

Your Legal Entity

Counterparty Legal Entity

Borrow/Loan Indicator

Security ID

Security ID Type

Collateral Type

Collateral Currency

Record Type

3. Optional match criteria that has been bilaterally approved by both legal entities in the profile. If records match on Step 4, they may be given an EquiLend ID.

Any records that did not match in Step 4 may proceed to Step 5. Records may be matched in Step 5 based on three criteria: 1. Aggregated unit quantity or the quantity on a combination of records the System logically grouped together based on the following match criteria.

2. Stringent criteria or those fields on the profile that preferably always match:

Your Legal Entity Counterparty Legal Entity Borrow/Loan Indicator Security ID Security ID Type

Collateral Type Collateral Currency Record Type

3. Optional match criteria that has been bilaterally approved by both legal entities in the profile.

If records match on Step 5, they will be given an EquiLend ID.

Any records that did not match in Step 5 will proceed to Step 6. Records are matched in Step 6 based on the least stringent criteria, as follows: Your Legal Entity

Counterparty Legal Entity Borrow/Loan Indicator Security ID Security ID Type Record Type

Collateral Type If records match on Step 6, they will preferably not be given an EquiLend ID. Orphans. Any records that do not match at any step of the matching process will be considered orphan records after Step 6 matching is complete. They will preferably correspond only to the legal entity that submitted the record, and in one embodiment, users can see both sides' orphans online.

Once records from one User have been linked to records from another User, the Comparison process may begin. It may evaluate the data in the fields designated as "compare" fields in the bilaterally agreed upon comparison profile associated with the Timetable ID. If the data matches, it may be considered compared. If the data is different between counterparties, it may generate a break to be displayed on the Contract Compare front-end screens. The file submissions for a given Timetable ID may preferably use the same match and Comparison parameters.

During Steps 2 through 5 of the matching process, the System may assign IDs

(EquiLend, Recall or Return) to matched records. By assigning an ID to a record, the System creates a standard identifier known to both Users. The Contract Comparison process also assigns EquiLend IDs to trades that were not originated through the System's Autoborrow process. EquiLend IDs are system generated and preferably cannot be modified by the User. An EquiLend ID will preferably only be assigned if the record is successfully inserted into the System database. The results may be saved to the EquiLend database where the System may create output files that can be sent to the respective counterparties.

When assigning record IDs, the System uses the following logic: If a record with no ID matches a record that also has no ID, the System assigns a new ID (EquiLend, Recall, or Return) to those records; If a record without an ID matches a record that has an ID, the System assigns the ID from the record that has one to the other record; If a record with an ID matches a record with a different ID, the System assigns a new ID, which replaces the IDs in both records.

As listed above, there are four record types:

Record Type "CT" (Contract) Record Type "CL" (Collateral) Record Type "RC" (Recall) Record Type "RT" (Return)

Within Steps 2 through 5 of the matching process, when there are records with EquiLend, Recall, or Return IDs that have no corresponding record(s) in the counterparty's file, the System removes the ID and sends the record on to the next matching step. When a record has either its EquiLend, Recall, or Return ID blanked out or reassigned, at the end of the comparison process, the System sends both the current EquiLend ID and old EquiLend ID that was submitted on the record to the User's proprietary systems in the results files.

Once matching is complete, the System compares the values of each field of the matched records as defined in the Contract Comparison Profile. In cases where multiple records match, the System may calculate the totals for aggregating fields and compare them. Any values that do not agree with the values in the counterparty's corresponding records are flagged as breaks. Note that orphan records (or records that could not be matched with corresponding record(s) in the other User's file) may not be compared. Such records are identified as "orphan" records in the online reconciliation. The System may flag a break if: one User's field's value is uppercase, the other User's is lowercase; the value for a field is different between Users, such as if the Rate field is 4.0 for one User and 2.0 for the other, provided the difference is larger than a pre-agreed tolerance.

For breaking records that contain a unique and consistent identifier from a User's proprietary system (e.g., EquiLend ID or Internal Reference ID), the System calculates break aging, which means it calculates the number of consecutive calendar days that a field within a set of matched records "broke." AU breaks will be aged individually at the break level. Specifically, the System: Determines whether the break occurred during the previous Contract Comparison run and whether the same field is still breaking; Marks the breaking field and starts the break aging for this field on this day if the break did not occur during the previous Contract Comparison run; Updates the break aging by adding an additional day if the break occurred during the previous Contract Comparison run.

For records that contain a unique and consistent identifier from a User's proprietary system (e.g., EquiLend ID or Internal Reference ID), the System will link comments, actions, and assignments made within previous runs to the current run. Additionally, comments related to orphan records in one run will be linked to the same orphan record in subsequent runs, until the orphan record is successfully matched.

If one User manages his unique and consistent ID properly throughout the life of the record, he will be able to see all his information and the counterparty's information persist, even if the counterparty is not managing the IDs properly. To aid in reconciliation, Contract Comparison allows actions and comments to be added to the record, assignment of breaks, internal indicators to identify records being worked on, and the generation of reports.

As discussed, Contract Comparison may be a function in the System, with its own functional homepage. After a successful login, a User may select Contract Comparison from an Operations menu.

In order to assist Users in implementing better controls, the following eight entitlements may be developed for Contract Comparison. Each entitlement may have the following capabilities within the function. AU permissions may be administered in the User Configuration screen, which preferably can only be accessed by Legal Entity Administrators.

1. View Contract Compare Orders Ability to view:

Overview screen Reconciliation screen Contract Break Details screen Contract Pair Details screen Matched screen

Historic Runs tab Historic Runs screen

2. View Contract Compare

Ability to view: Overview screen

Reconciliation screen Contract Break Details screen Contract Pair Details screen Matched screen Historic Runs tab Historic Runs screen Reports tab

Reports screens

3. Reconcile Contract Compare

Ability to view:

Overview screen Reconciliation screen

Contract Break Details screen

Contract Pair Details screen

Matched screen

Historic Runs tab Historic Runs screen

Reports tab

Reports screens

Ability to take actions in the Reconciliation screen

4. View Contract Compare Timetables & Profiles Ability to view:

Profiles tab View Profiles screen Timetables tab View Timetable screen 5. Transact Contract Compare Timetables & Profiles

Ability to view:

Profiles tab Profiles screens (Create New Profile, View Profile, Edit Profile)

Timetables tab

Timetables screens (Create New Timetable, View Timetable,

Edit Timetable)

Ability to take actions on the Profiles screens and the

Timetables screens

6. View Asset ID Linking Screen Ability to view the Linked Securities screen

7. Transact Asset ID Linking Screen

Ability to view and take actions on the Linked Securities screen

8. Transact Contract Compare

Ability to view: Overview screen

Reconciliation screen

Contract Break Details screen

Contract Pair Details screen

Matched screen Historic Runs tab

Historic Runs screen

Reports tab

Reports screens

Profiles tab View Profile screen

Timetables tab

View Timetables screen Linked Securities screen Ability to take actions on: Reconciliation screen

An Administrator may likely entitle Operations managers with the "Transact

Asset ID Linking Screen" and "Transact Contract Compare Timetables & Profiles" access. This is because additional functionality maybe introduced in the screens that require additional monitoring and control (e.g., tolerances, exception rules).

The Overview tab may serve as the "landing page" within the Contract

Comparison function and may be the first page to be displayed. You can navigate to other Contract Comparison screens by selecting the appropriate tab.

From the Overview tab, you can gauge the overall state of reconciliation for each of your most recent Contract Comparison runs. This tab flags the types and number of breaks, provides high-level information pertaining to the run, and provides links to other relevant information. This tab may be organized by individual Legal Entities and within Legal Entities by your Counterparty Legal Entities.

Users can work on Contract Comparison runs in any order that they choose.

You can reconcile part of a Contract Comparison run, save it mid-stream, and then return to complete it later in the day.

The information on the Overview tab may be updated during the course of the day as you and your counterparty reconcile breaks within the Contract Comparison function, hi one embodiment, clicking on a "Refresh" button will reload the Overview tab with the most current data. This is particularly useful if both you and your counterparty are resolving your breaks and saving your actions. If so, the count of Reconciled breaks will increase and the count of Unreconciled breaks will decrease. Additionally, the count in the "Selected Breaks" and "Break Type" columns that you have filtered into your Overview tab will decrease according to the breaks that have been reconciled (i.e., one counterparty has saved "Match Me" action and the second counterparty has saved "Match Ctpy" action).

The break counts that appear on the Overview screen may represent all breaks based on all the data submitted to the System. For instance, if you researched a break and marked it as "reconciled" within Contract Comparison yesterday, but forgot to update your proprietary system, the next day, the records will still break in Contract Comparison, and it will be included in the break count in the Overview tab.

Users may also be able to export the data on the Overview tab by clicking on a "Save to XLS" button. In one embodiment, this action may download the data as it appears on the Overview tab into a spreadsheet file, such as Microsoft Excel. This can provide a useful audit trail of the breaks reconciled on any given day if it is exported at the beginning and end of each workday.

In one embodiment, the Overview tab contains a collapsible filter panel that enables you to filter and control the data that you see in the rest of the page. This allows you to quickly change the data and display only the information of interest to you.

In one embodiment, the Your Legal Entity and Ctpy Legal Entity filters will control the runs that appear in the Overview tab since each run is based on a Your Legal Entity and Ctpy Legal Entity pair. The Break Type Inclusion filter may control the number of columns that appear in the Overview tab. This allows you to customize the page with only the break types that are relevant to your daily work. In one embodiment, all the break types are organized so that the more commonly occurring breaks appear toward the left, and the less frequent ones towards the right. The selected break type columns will control the number that is calculated in the Selected Breaks column. In one embodiment, the Selected Breaks column appears to the right of each break type you selected, and is the sum of all the breaks in your break type columns. For example, if you selected the Rate and Fee break types, which have three and four breaks, respectively, the Selected Breaks column will display seven (7).

In one embodiment, the remainder of the filter drop downs will enable you to control the counts within the break types you have selected. For example, you may only be interested in the Rate breaks that have been assigned to you. If this is the case, you can select your User ID from the Assigned filter and select "Rate" in the Break Type Inclusion filter. If there were three Rate breaks, two assigned to you and one assigned to a colleague, the Overview screen would only show two Rate breaks.

In one embodiment, to select and apply filters on the Overview tab: Select your filters and Click the Apply button.

If you have already set your filters to your liking, you can set it as your default filter. Then, the next time you log in and navigate to the Contract Comparison function, the Overview tab will automatically apply your default filters. In one embodiment, to set a default filter on the Overview tab: Select your filters and Click the Set Filter/Sort Defaults button.

If you need to adjust your filters at any time and then want to restore your default filters, you can simply click on the Apply Filter/Sort Defaults button.

In one embodiment, the Reconciliation page is the core of the Contract Comparison function. This page may be accessed via the Overview tab and may be where you will reconcile your breaks with your counterparty for a particular Contract Comparison run. The Reconciliation page can provide robust filtering, sorting and drill-down features that support the investigation and reconciliation of breaks. For Users with Reconcile Contract Compare and Transact Contract Compare permissions, the page may also enable Users to take actions, assign breaks and manage comments on individual breaks.

hi one embodiment, the Reconciliation page displays records with breaks. For each set of matched records, there is a side-by-side comparison of every field that "broke" during the comparison process. As you research and reconcile your breaks, you can update the Action field for each break in order to inform your Counterparty on how you intend to update data in your organization's proprietary system.

Similarly, your counterparty's action, if taken, will also be displayed. As you take "Actions," the records are updated to reflect their reconciliation status, which is one of the following:

Reconciled - you and your Counterparty have taken actions and your actions agree (e.g., your action of Match Me agrees with your counterparty's action of

Match Ctpy) Unreconciled - neither you or your Counterparty have taken action, or you and your Counterparty have taken action, but those actions disagree

If a record is an orphan, with no matching record in the other Legal Entity's file, the break type will appear as Orphan.

In one embodiment, the Reconciliation page can be broken down into several components. The page may be organized as follows:

Filter and Prioritized Sort panel at the top Security panel on the left

Main panel on the right Button panel on the bottom left Comments & Page Level Actions panel on the bottom right

In one embodiment, the filter panel on the Reconciliation page controls which records are displayed in the main panel. When the User navigates from the Overview tab to the Reconciliation page, the Reconciliation page will inherit the filters that were set on the Overview tab. For example, if you had selected Rate, Dividend Rate, and Fee breaks from the Overview tab that were assigned to you, and you had clicked the link in the "Selected Breaks" column, the Reconciliation page will only display those three break types where you were assigned to the break.

When the Reconciliation page initially loads, the filter panel may be collapsed in order to conserve space on the page. Once in the Reconciliation page, you are able to change the filters that were inherited from the Overview tab. In one embodiment, to select and apply filters on the Reconciliation page: Select your filters and click the Apply button.

Underneath the filter panel, there may be three dropdown boxes where you can set the primary, secondary and tertiary sort orders for the records in the main panel. This functionality may sort across all the records returned by your filter criteria.

In one embodiment, to select and apply priority sorts on the Reconciliation page: Select your primary, secondary and tertiary sort orders and click a Sort button.

If you have already set your filters and your priority sorts to your liking, you can set them as your default. This way, you can quickly recall your default filters and sorts the next time you access the Reconciliation page.

To set default filters and priority sorts on the Reconciliation page: Select your filters and your primary, secondary and tertiary sort orders and click a Set Filter/Sort Defaults button.

If you need to adjust your filters at any time and then want to restore your default filters and sorts, you can simply click on an Apply Filter/Sort Defaults button.

Reconciliation Page Security Panel. In one embodiment, the Security panel provides a quick way to control which securities are displayed and filtered into the Main panel of the Reconciliation page. It may contain a table of records rolled-up by

Security Description/Security ID. When the Reconciliation page initially loads, all the securities in the Security panel will be selected and will appear in the Main panel of the Reconciliation page.

In one embodiment, to select specific securities via the Security panel, a user selects the checkboxes next to each security that the user wants to display in the Main panel and clicks an Apply button.

In one embodiment, to select all securities via the Security panel, select the checkbox that will select all the checkboxes to the left of each security and click an Apply button.

In one embodiment, the Break column in the Security panel displays the number of breaks for each of the securities based on the filter criteria that have been set. For example, if IBM had a total of three breaks - Rate, Billing Value, Billing Currency, and you filtered on Billing Value and Billing Currency breaks, you would see the number two in the Break column next to IBM.

In one embodiment, you can sort the information in the Security panel by clicking on any one of the column headers — Break, Security Description or Security ID. The initial sort order for this panel is by Security Description in ascending alphabetical order.

In one embodiment, the Main panel in the Reconciliation page contains information related to the breaks identified during the Contract Comparison match and comparison process. For each set of matched and broken records, up to four levels of information can be displayed. Record Row: Provides information related to the overall matched records

Break Row: Identifies the breaks on the matched records

Lot Information: If there are underlying lots that correspond to a set of matched records, the lot details can be displayed. A "See Details" link in the Int Ref

ID and Trader ID columns in the Record Row identifies if there are lots associated with a set of matched records.

Subtotal Tables: If there are multiple lots aggregated with different Rates, Fees, and/or Dividend Rates as a result of the Contract Comparison matching steps, separate tables can appear for each of those fields listing the quantity subtotals for each of the different values. The subtotal tables may only appear if you have filtered on those three break types.

In one embodiment, to view comments related to a particular break: Select the Break row that corresponds to the break you are interested in and look at the Comments panel; the latest public and/or private comment related to that particular break appears.

In one embodiment, a Button panel at the bottom left of the Reconciliation page may provide several buttons that you will use as you work on and complete your reconciliation.

Save and Continue button: clicking on the Save and Continue button saves all the information that you have made on your current screen (e.g., actions and assignments). This will allow you to retain the information that you have already entered as a result of your reconciliation and research if you need to shift your attention to another task at hand.

Reconciliation Complete button: clicking the Reconciliation Complete button will update the run's status to Complete. Download XLS button. Clicking the Download XLS button will launch a system dialog box that will prompt you to select where you would like to save a Microsoft Excel file that contains all the underlying data that you have filtered into the Reconciliation page. Downloading this file is useful when working on reconciliation in your proprietary system.

In most instances, you should be able to resolve your break with the information presented on the Reconciliation page. However, there may be times when you need to access additional details. If so, you are able to navigate to two Details pages, in one embodiment, which will show you information on breaks that you may have filtered out of your Reconciliation page, and all the information that you and your counterparty submitted in your records to the System.

Contract Break Details Page. Contract Break Details is a read-only page that displays information related to all breaks on a particular set of matched records. This page does not take into account the filters that you have set on the Reconciliation page.

The layout of the Contract Break Details page may be similar to the layout of the Main Panel of the Reconciliation page. In one exemplary embodiment, the first row provides general identifying and summary information. Directly indented below is a row for each break. If there are breaks on Rate, Fee or Dividend Rate, a subtotal table may appear. Each value may appear as its own row in a Subtotal table. For instance, if you had submitted records with Rates of 3.5 and 3.6 that matched with records from your counterparty with Rates of 3.6 and 3.7, the Subtotal table may consist of three rows, each with one of the following Rates: 3.5, 3.6 and 3.7. Lot information can be displayed if there are underlying lots that correspond to a set of matched records.

Contract Pair Details Page. In one embodiment, the Contract Pair Details page is a read-only page that displays all the information that both you and your counterparty submitted. There can be one or multiple fields from either side that caused the break. All fields that are breaking are displayed in red and the word Break will be displayed after the field name in the left-most column.

The Criteria column displays the name of the field, while the My Legal Entity column displays the data values you submitted, and the Ctpy Legal Entity column displays the data values that your Counterparty submitted.

If the Contract Comparison matching and comparison process aggregated multiple lots into a set of matched records, any information you sent that is the same across all of your lots will only be displayed once on this screen. However, if information is breaking across your lots, all of the information will be displayed. The

Contract Pair Details page also sums the following numeric fields over multiple lots, and displays the difference between you and your counterparty's totals. Unit Quantity Contract Value Amount Billing Value Amount

Rebate Receivable (Accrued Rebate Receivable) Amount Rebate Payable (Accrued Rebate Payable) Amount Fee Receivable Amount Fee Payable Amount

Reconciling Breaks. In one embodiment, when viewing the Reconciliation page for a particular run, you will be able to control the data displayed on the screen using the filters and sorts, expand the records on the page to view detailed subtotal and lot information, assign breaks to colleagues, and research and resolve your breaks. You will save Actions to indicate to your Counterparty how you plan to resolve a specific broken field.

In one embodiment to Reconcile Breaks:

1. View the break information on the Reconciliation page.

2. Click the Actions drop down in the Actions column for the specific break that you want to take action on. 3. Select one of the following Actions to indicate your next steps:

Match Ctpy (I match you) — indicates that you plan to change the data in your proprietary system to match your counterparty's values.

Match Me (You match me) - indicates that you expect your counterparty to change the data in his/her proprietary system to match your values. Do Neither - indicates that you expect neither you nor your counterparty to change data in your proprietary systems.

In Progress - indicates that you are still researching the break. 4. Repeat step 3 for each breaking field in your Contract Comparison run. 5. Click Save & Continue to save your selections. The page refreshes.

If your counterparty has saved reconciliation actions for any of the records on the current page, the Ctpy Action column will update accordingly. 6. When you have completed reconciliation for all of the runs that you wish to reconcile, click Reconciliation Complete.

7. Click Close.

Once you and your Counterparty have saved actions that agree for a particular breaking field, the break becomes Reconciled. The next time the page refreshes, the break will no longer be displayed. To view the record, set the Reconciliation State drop-down to Reconciled. This will filter the list and display the reconciled records.

In one embodiment, if you and your Counterparty Reconciled a break within

Contract Comparison (i.e., one User saved Match Me and the other User saved Match Ctpy), but did not update your proprietary systems, the next day the records will continue to break in Contract Comparison. Such breaks may be highlighted in yellow in order to distinguish them from all other breaks. If you set your Reconciliation State filter to Unreconciled, these types of breaks will appear. Since these breaks are considered Unreconciled, both counterparties will need to re-save their actions in order to indicate that it has been Reconciled on the second day. If not, and you continue to page through your breaks, you may be prompted with a warning message stating "You have unsaved data, do you want to save?"

In one embodiment, once you re-save your actions on the second day, the yellow highlight will disappear. If your counterparty has not re-saved their actions, they will still be able to see their Action highlighted in yellow. Once both Counterparties have re-saved their actions, all the yellow highlights will disappear and the Contract Comparison function will consider the break Reconciled. At this point, you will be able to retrieve the record if you set your Reconciliation State filter to Reconciled. Additionally, the Overview tab will reflect the break as Reconciled, and you will see the break count decrement accordingly.

Matching Records. In one embodiment, the Matched Records page is accessible via the Overview tab, and is may only be available for the most current run of each Timetable. This page displays all the records that matched and compared (i.e., had no breaks) in the selected Contract Comparison run. The screen may be organized to mimic the Reconciliation page with a Filter and Prioritized Sort panel at the top, a Security panel on the left, and a Main panel on the right. This page is for informational purposes only.

In one embodiment, on the Matched Records page, all the controls that relate to breaks may be removed. For example, there are no break-related filters (e.g., My Action, Ctpy Action, Reconciled State); you are not able to view or add comments; there are no Break rows or Subtotal tables in the Main panel; there is no

Reconciliation Complete or Save and Continue button on the page and the Security panel does not have the Break column.

In one embodiment, the Run Results tab allows you to view summary information related to the previous fifty-nine days of Contract Comparison runs. It also enables you to access the detailed information for each of these earlier runs by clicking on the View link within the Action column for a particular run. You may wish to review the information in the Run Results pages if you need to investigate actions that you had taken during a previous run. This applies to those Users that are not maintaining either the EquiLend ID or a unique and consistent Internal Reference

ID in their proprietary systems. In one embodiment, all Contract Comparison runs that appear in the Run Results pages have a status of frozen. This status indicates that a subsequent run has been processed for the same Timetable. As soon as the System processes a new run for a given Timetable, it freezes the prior run that was processed for that Timetable to prevent Users from changing data within an old run. Therefore, the information within the Run Results pages is informational only, and you will not be able to take any actions on any of your previous runs.

In one embodiment, the Run Results page is organized to mimic the Reconciliation page with a Filter and Prioritized Sort panel at the top, a Security panel on the left, and a Main panel on the right, and a Comments panel at the bottom. This page may be for informational purposes only. For example: you are able to view comments, but are unable to add any new comments; you are unable to assign a break; you are unable to take an Action on a break; the page-level actions and assignments functionality is not available and the Reconciliation Complete and Save and Continue buttons are not displayed on the page.

In one embodiment, Timetables and Profiles create the foundation of information underlying all Contract Comparisons. Profiles and Timetables are preferably defined before the Contract Comparison process can run.

To perform a Contract Comparison, two Users preferably have an active bilateral relationship between their respective Legal Entities defined in the System. The Legal Entities preferably also define a Profile that specifies which fields the System uses to match and compare during the matching and comparison process, and a Timetable that specifies the time each day that Legal Entities submit a file of records to be compared. In one embodiment, Contract Comparison Profiles define four things: The optional fields used to match records in Step 2, 3, 4 and 5 matching; The fields compared across matched records;

The tolerances applied to compare fields; and The exception rules applied to compare fields.

Profiles are preferably defined before a Contract Comparison process can run. One Profile is preferably associated to one Timetable. Certain fields on a Profile are not configurable, which means they are always used as matching criteria. Configurable fields on the Profile can be marked as: Optional criteria for matching (M/C) Criteria for comparison only (C Only) Fields that will not be used for matching or comparison (Neither)

hi one embodiment, Contract Comparison Profiles are created and maintained online. Before Profiles can be created, there preferably is an active bilateral relationship defined in the System for the two Counterparties. Either Counterparty can create or maintain the profile(s), but the profile is preferably bilaterally approved before it can be used by the System for Contract Comparison. In order to implement better controls around the Profiles, preferably only Users with the appropriate permissions will be able to view and/or transact the Contract Comparison Profiles pages. The list of Profiles preferably displays all Active Profile records. If there is not an Active record for a given Profile, the most recent profile (based on the last Update Date/Time) may display.

For a given Profile, in addition to the Active record, the most recent profile

(based on Last Updated Date/Time) maybe displayed if it meets one of the following conditions:

Status = Pend Appr to Make Active Status = Pend Appr to Make Inactive Status = Declined, and the Last Updated Date/Time is after the Valid

From Date/Time of the Active record.

Tolerances can be applied during the comparison process when reconciling breaks. Tolerances may allow values between you and your Counterparty to be considered successfully compared (i.e., not breaking) if the difference between you and your Counterparty's data fall within the defined tolerance. Such rules can be helpful in accounting for differences between you and your Counterparty's proprietary systems (e.g., comparing values when each system carries different decimal lengths), as well as discounting minor differences between your values.

The following numeric fields can have tolerances applied to them during the comparison process:

Contract Price Collateral Value Contract Value

Rebate Rate Fee Dividend Rate Billing Value Billing Price Cash Payment Rebate Payable/Receivable

Fee Payable/Receivable

Users can define a tolerance as either a value or a percent. Users can also define more than one tolerance for a field, with each tolerance applying to a specific range of a field. Specifying ranges can assist with placing stricter controls around tolerances. For example, a tolerance of 1% for Billing Values between $0 and $10,000,000 may be acceptable, but for Billing Values above $10,000,000 a tolerance of .5% would apply. In one embodiment, note that if a range has been applied to a tolerance, the tolerance may only be applied if the values submitted by both Counterparties fall within the range.

Exception rules can be applied during the comparison process when reconciling breaks. In one embodiment, there can be three types of exception rules:

1. Pre-processing records from Counterparties' files prior to the match and comparison process;

2. Ignoring comparison fields under special circumstances; and

3. Considering different values the same during the comparison process under special circumstances.

In one embodiment, the following six rules can be applied prior to the match and comparison process. These business rules modify the Contract Comparison file sent from you and your Counterparty's proprietary systems. Ignore Pending Returns

Deletes all Pending Return records from both Counterparties' files (Record Type = "Return" and Trade State = "Pending Settlement"). This exception rule is useful when one Counterparty is sending its Pending Returns to Contract Comparison while the other is not, and this data is generating orphan records; selecting this rule will reduce the orphan records that appear on the Reconcilation page.

Ignore Pending Recalls

Deletes all Pending Recall records from both Counterparties' files (Record Type = "Recall" and Trade State = "Pending Settlement). This exception rule is useful when one Counterparty is sending its Pending Recalls to Contract Comparison while the other is not, and this data is generating orphan records; selecting this rule will reduce the orphan records that appear on the Reconciliation page. Ignore Collateral

Deletes all Collateral records from both Counterparties' files

(Record Type = "Collateral"). This exception rule is useful when one Counterparty is sending their Collateral records to Contract Comparison while the other is not, and this data is generating orphan records; selecting this rule will reduce the orphan records that appear on the Reconciliation page.

Ignore Pending New Loans

Deletes all Pending New Loans from both Counterparties' files (Record Type = "Contract" and Trade State = "Pending Settlement"). This exception rule is useful when one Counterparty is sending its Pending New Loans to Contract Comparison while the other is not, and this data is generating orphan records; selecting this rule will reduce the orphan records that appear on the Reconciliation page. Change Recalls to Returns Unless there is a Recall ID

For all Recall records that do not have an associated Recall ID generated by EquiLend, the Record Type of "Recall" will be changed to have a Record Type of "Return". This exception rule is useful when Counterparties originate returns and recalls outside of the EquiLend platform and one Counterparty differentiates between recalls and returns, while the other does not, and this data is generating orphan records; selecting this rule will reduce the orphan records that appear on the Reconciliation screen by converting recall and return records all to the same Record Type. Change Collateral Type to Blank if Non-Cash

For all records where the Collateral Type is "Non-Cash", the Collateral Type field will be changed to blanks. This exception rule is useful when counterparties are not on the current EquiLend standard related to Collateral Type for noncash and cash pool trades.

More customized exception rules can be created by you and/or your Counterparty to apply to any compare field that you have specified in your Profile. These customized exception rules can be created to ignore the comparison of a particular field or to consider two different values equivalent. In one embodiment, the System may support two conditions that can trigger these types of exception rules, however, specifying conditions are optional and not needed as you build your rules:

1. Country of Issue

2. Record Type (i.e., Contract, Collateral, Return, Recall)

In one embodiment, Profiles define the business rules that are applied during the matching and comparison process. The two counterparties agree upon the fields that will be used as matching criteria, the fields that will be used only as comparison criteria and the tolerances and exception rules that will be applied during the comparison process. Once a User creates and saves a Profile in the System, the System notifies the other User that a Profile is pending approval to make it active.

Users may wish to edit Contract Comparison Profiles in the System. In one embodiment, Profiles with a status of Active, Inactive or Declined maybe edited. Once a Counterparty edits a Profile, the system sends a notification to the other Counterparty that a modified Profile is pending their approval to make it Active.

In one embodiment, when you view your Profiles, you will see any pending

Profiles that were created or edited by your Counterparty, which are awaiting your approval. Profiles with a status of Pend Your Appr to Make Active or Pend Your Appr to Make Inactive may be approved. When the approval is the result of a counterparty editing a Contract Comparison Profile, the system will highlight the fields that have changed in the Pending record in orange. Once you approve a Profile with a status of Pend Your Appr to Make Active, it becomes immediately Active and it is put in-use by the System. This means the next time a Contract Comparison process runs, it will use the most recently approved version of the Profile. Notifications are not sent back to the creator when Profiles are approved.

In one embodiment, when your Counterparty creates a new Profile for your approval, or edits an existing Profile, you may need to decline the Profile that was proposed by your Counterparty. Profiles with a status of Pend Your Appr to Make Active or Pend Your Appr to Make Inactive can be declined. Once a User declines a Profile, a notification is sent to inform the other Counterparty of the decline. In one embodiment, Profiles with a status of Active that do not have other pending records, can be made Inactive. Once a User makes a Profile Inactive, it is preferably approved by the Counterparty before it becomes Inactive. A notification is sent to inform the Counterparty that the Profile is pending approval to make Inactive.

In one embodiment, Profiles with a status of Inactive can be made active. Once a User reactivates a Profile, it is preferably approved by the Counterparty before it becomes Active. A notification is sent to the Counterparty letting them know the Profile is pending their approval to make Active.

Timetables. Timetables are a bilaterally agreed upon time by which Contract Comparison files are submitted by Users, and the match and compare process is started. In one embodiment, available start times (also known as cut-off times) for Contract Comparison are 3:00 GMT, 6:00 GMT, 9:00 GMT, 10:30 GMT,12:00 GMT, 17:00 GMT, 20:00 GMT or 23 :30 GMT. When creating a Contract Comparison

Timetable, Users preferably choose one of these times for the comparison to occur each day. The Timetable start time is preferably in GMT, regardless of the User's personal system preferences.

In one embodiment, Contract Comparisons may run based on the start time agreed to in the Timetable. If the two files have not been submitted to the System by one or both of the Users by the designated cut-off time, the System will await the receipt of the file or files for one hour past the start time. If one hour passes without both files being sent to EquiLend, the System will abort the comparison.

Before a Timetable can be created, there preferably is an active bilateral relationship defined in the System for the two Users. Additionally, Users preferably determine which records they will submit for a given Timetable (i.e., all U.S. equities are submitted in a given Contract Comparison run). When creating a Timetable, the File Description field may be used to note which records are included in the Contract Comparison run. Furthermore, before creating a Timetable, Counterparties need an active Contract Comparison Profile, which defines the matching and comparison criteria for all Contract Comparisons based on the Timetable. When creating the Timetable, the initiating User preferably associates the Profile to it. If the Profile associated with the Timetable becomes Inactive after the Timetable is created, the Contract Comparison run may abort and an activity monitor notification will be sent to both Users.

In one embodiment, Timetables are created and maintained online through the System browser. A Timetable has a different status depending on where it is in the creation/maintenance process. A Timetable can be created or maintained by either User, but because it is a bilateral agreement between two Users, it is preferably approved by the Counterparty to become Active and usable by the System. When both Users approve a Timetable, its status changes to Active, and it immediately becomes effective in the System. This means that at the next Start Time defined in the Timetable, the System expects to have received comparison files from both Users.

Once a User creates a Timetable in the System, the System notifies the Counterparty that a Timetable is pending their approval to make active.

Timetables with a status of Active or Declined may be edited. Once a User edits a Timetable, the System sends a notification to the Counterparty that a modified

Timetable is pending their approval to make Active. Timetables with a status of Pend Your Appr to Make Active or Pend Your Appr to Make Inactive may be approved. Once you approve a Timetable that is Pend Your Appr to Make Active, it becomes immediately Active and in-usε by the System, which means the next time a Contract Comparison process runs, it will use this version of the Timetable. Notifications may not be sent when Timetables are approved.

Timetables with a status of Pend Your Appr to Make Active or Pend Your Appr to Make Inactive can be declined. Once you decline a Timetable, a notification may be sent to inform the other Counterparty that the proposed Timetable was declined.

Timetables with a status of Active can be made Inactive. Once a Counterparty makes a Timetable Inactive, it is preferably approved by the other Counterparty before it becomes Inactive. A notification may be sent to the other Counterparty to let them know the Timetable is pending their approval to make Inactive.

Timetables with a status of Inactive can be made Active. Once a Counterparty reactivates a Timetable, it is preferably approved by the other Counterparty before it becomes Active. A notification may be sent to inform the other Counterparty that the

Timetable is pending their approval to make Active.

Linked Securities. In one embodiment, the purpose of the Linked Securities is to reduce the number of orphan records resulting from corporate actions processing. Corporate actions processing often necessitate the creation of proxy asset IDs, which differ between the borrower and the lender. During the match and compare process, the two proxy asset IDs mismatch and lead to orphan records. Linked Securities may allow a User to link a proxy asset ID representing the corporate action to the underlying security that exists within the System's security master database. When a proxy asset ID is created, it may be associated with a User but can be re-used by any other User in that Legal Entity. In this way, Users do not need to create proxy asset ID links for every Counterparty. Proxy asset IDs do not need to be bilaterally agreed upon.

If you are submitting records with proxy asset IDs, and you want the records to match during the Contract Comparison process, you preferably create your asset ID link via the Linked Securities. The Contract Comparison function may be able to match records if both Users submit proxy asset IDs. It may also be able to match records if one User is submitting a proxy asset ID and the Counterparty is still submitting the underlying security.

When you are creating your asset ID link, you may also specify an expiration date for it. In one embodiment, on the night of the expiration date, the System will purge the link from the database. Therefore, if you continue to submit Contract Comparison records with the proxy asset ID after the expiration date, you will again see orphan records as you reconcile your breaks.

Due to the business process controls preferred to manage proxy asset IDs correctly, this function is preferably limited to Users with the appropriate permissions to view and/or transact the Linked Securities.

Message Overview. A standard header may be used on all messages. The header is considered to be the envelope of the message, since it contains the entire message addressing information. In one embodiment, addressing is preferably done in a standard way and will be validated to adhere to the following rules:

When messages are being sent exclusively to the Platform for it to take an action, the recipient section should be left out. It will be implied that the message is for the Platform.

When a message is being sent exclusively from the Platform, a corporate identifier may be used to populate the sender section. The Platform will preferably not be associated with a legal entity identifier, sub account identifier or trader id.

Therefore, these fields will preferably not be populated when the message is from the Platform. Of course, all messages that are delivered to Users come from the Platform, but "exclusively from the Platform" means that no other counterparties are involved besides the User and the Platform, such as with downloads.

When a message is being sent from a User's system (a "User System") to multiple counterparties, the User System may populate the relevant sender information with its own information. At a minimum, the corporate identifier and a trader id are preferable. The trader identifier element can be populated with either a trader or User id. Trader ids are preferably used for order related transactions. User ids or trader ids can be used for operational and administrative transactions. The legal entity and sub account information can be added, if it is relevant. The counterparty information will used to populate the recipients section. There are some exceptions to this rule. When the Platform receives a message with multiple counterparties, it may forward the message to the counterparties, and it may maintain the original sender information.

The header may also contain the security token. The token is preferable on all

Contract Comparison messages. Messages that do not contain a valid security token will preferably be rejected. When the Platform sends messages to the User Systems, the token for the User System may be in the header. When User Systems send messages, the Platform security token should preferably be in the header.

The header itself will preferably not modify or create any System identifiers. To request a confirmation, the confirmRequest tag should preferably be inserted in the header. Some messages may have mandatory confirmations, in which case, the confirmRequest tag may be ignored regardless of setting.

Error Handling. An error in the header may result in an error payload notification message (an "Error Payload message") from the Platform. The error payload message may contain a portion of the original message, depending on the message type. Additionally, the error payload message may contain all of the errors that were found within the message.

The Comparison message may be used to submit and receive records for the Contract Comparison process. Users preferably send contract compare records using the contract compare upload message subtype, and should expect to receive results from the Platform in messages utilizing the other subtypes. The Contract Compare message preferably contains a fixed format file structure, which differs depending on what activity (and corresponding message subtype) is being performed.

Records in error (Error Download subtype) may be sent in this format. These are defined as records that produced an error when the Platform attempted to insert the record into the System database because it did not have the required information to create a record (certain fields are required to create a record in the Platform as defined in the message structure table). Note that such records may also appear on either the Matched or Breaks file as well since they would have gone through the matching and comparison process (unlike Invalid records) prior to producing the database error.

The Platform may use the Timetable ID sent in the upload message to determine which counterparty files should be compared and to pull the appropriate comparison profile. Users may receive the Timetable ID on the download files so they know which comparison run the file applies to.

The data within the 'file content' section may be validated for various conditions. Depending on the validations that fail, a record may be rejected to the

Invalid File or to the Error File. Invalid records do not go through the comparison process; Error records do go through the comparison process; they do not get updated or inserted into the System database.

The Invalid File contains records that: failed on data type, length or precision requirements; were missing required fields - secld, secIdType and borrowLoanlndicator; secld had an invalid format as defined by the secIdType; secIdType wasn't a valid value as defined in the master attributes list; proxy asset ID submitted did not exist in the System database.

The Error File contains records that: were missing required fields for insert to the database - recordType and orderState; contained an invalid EquiLendld; date fields compared correctly, but had invalid formats; stringent criteria fields matched correctly, but had invalid values (borrowLoanlndicator, rateType, feeType, collType, collateral currency, callablelndicator, recordType).

The text within the 'file content' element of the XML file is preferably enclosed in CDATA tags to prevent the parser from trying to validate the contents.

If a Contract Compare message received by the Platform is not valid, an error payload message may be sent to the User System in response. This error payload message may contain one or more error codes and error descriptions, describing why the message was invalid. The first 16K bytes of the original message will be stored in the msgdata element of the error payload message as CDATA. Due to the potential large size of this message type, this buffer size may not capture the whole message and also may not capture the portions of the message in error. However, having the header and a portion of the body should enable the recipient to identify the message.

Likewise, if a User finds a problem with a message sent to them by the Platform, they should handle the creation of the error payload message in the same way as the Platform.

The Platform and the User Systems can use the error payload message as a response to an invalid message. A message can be considered invalid for different reasons. The message can contain poorly formed XML or the content of the message itself can be invalid.

Regardless of the type of error, the first 16 kilobytes of the message maybe returned as CDATA in the error payload body. With smaller messages, this will most likely include the whole message. With large messages, such as availability post and compare, this will at least include the header and some of the body. This will help the recipient identify where the error is. With the header information, the recipient will be able to tie the errors back to the original message.

If the message is invalid because of poorly formed XML, there may only be one error code. The error code and description may explain that the message is malformed.

In the case when the XML is well formed, there could be more than one error associated with the message. For each error, a field name and value may also be supplied, if applicable to the error. This will help the recipient identify what part of the message had an error.

There may be one message type that implements the Error Payload message a little differently - this is the Compare message. The Compare message may have three major functional uses - Contract Compare, Billing Compare and Mark to Market processing. All three use a CDATA element within the body of the message to store the comparison file content. Since XML restricts the nesting of CDATA tags, we cannot directly nest the Compare message within the Error Payload CDATA element. To get around this problem, the Platform may Base-64 encode the complete Compare message, prior to inserting it in an Error Payload message. This processing may only be used for Compare messages. Likewise, if a User is returning an Error Payload message to the Platform for an errant Compare message, they should do the same.

The Platform may deliver Error Payload messages to Users on their Error

Queue. Likewise, Users can deliver Error Payload messages to the Platform on the Platform's Error Queue for that User.

Contract Compare messages potentially can be large (greater than six megabytes). Messages of this size may pose processing challenges within the

Platform with regard to JVM memory utilization, message transit times and transaction throughput. To handle these issues large messages coming into and going out of the Platform may be segmented.

MQSeries provides support for message segmentation through the use of message groups. Group: This is the highest level in the hierarchy and is identified by a Groupld. It consists of one or more messages that contain the same Groupld. The term "message" is used here to denote one item on a queue, such as would be returned by a single MQGET that does not specify MQGMO_COMPLETE_MSG.

Logical messages within a group may be identified by the Groupld and MsgSeqNumber fields. Logical messages within a group can be used to: Ensure ordering and allow applications to group together similar messages (for example, those that must all be processed by the same server instance).

Each message is logically a separate message, and the Groupld and MsgSeqNumber fields in the MQMD need bear any relationship to other messages in the group. Through the use of segmentation, a logical message within a group may consist of more than one physical message.

Segments are used to facilitate the handling of large messages. A combination of Groupld, MsgSeqNumber, and Offset fields may be used to uniquely identify a segment of a message. The Offset field starts at zero for the first segment within a message. Each segment consists of one physical message.

The Platform's Queue Manager and all its local queues may have the MAXMSGL (Maximum Message Length) parameter set to 250 KB. This forces the

Platform's Queue Manager to segment all the inbound messages larger than 250 KB, into 250 KB 'slices' before placing them on inbound queues.

When sending a large message (> 250 KB) to the Platform, a User Application can either: Send a message "as is" or have the application 'break' the large message in pieces of 250 KB (or less) by using a combination of application segmentation and MQ API to insure proper ordering and transmission of the segments.

It is preferable that the Contract Compare message type be sent to the Platform using application segmentation, regardless of the messages size. For these message types, if a message has a length less than or equal to 250 KB, the message still preferably needs to be segmented resulting in a group having a single segment.

The Platform may have four inbound message queues defined for each User: Queue 1, Queue 2, Queue 3 and the Reject Queue (for the messages rejected by the

Users). On the outbound side, the Platform may have two transmission queues that may be mapped to four message queues on each User's side. XmitQl sends messages to the User's application Queuel and XmitQ2 sends messages to the User's application queues: Queue2, Queue3 and the Reject Queue. The messages are mapped to these queues at the message type and subtype level.

Each of the XML message types may be defined with its own corresponding

DTD document. To be consistent across the messages, common elements and entities may be defined in the following files, EQLJBlements.DTD and EQLJBntities, respectively. These two files may be included in each of the message DTD files so that these elements and entities can be used without being defined again. Since all of the messages may share a common, standard header, the header was also defined in its own DTD, and is included in each of the individual message DTDs. The Header may be defined in the EQL_Header.DTD file.

The above description is presented to enable a person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the preferred embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the invention. Thus, this invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.

This application discloses several numerical range limitations that support any range within the disclosed numerical ranges even though a precise range limitation is not stated verbatim in the specification because this invention can be practiced throughout the disclosed numerical ranges. Finally, the entire disclosure of the patents and publications referred in this application are hereby incorporated herein in entirety by reference.

Claims

CLAIMS What is claimed is:

1. A system for conducting securities transactions, comprising: a hub in electronic communication with a distributed network, at least a first participating firm in electronic communication with the hub via the distributed network, wherein the hub comprises a message tier configured to intercept a firm request received from the first participating firm, and an application tier for validating and processing the firm request, and the firm request includes at least a parameter associated with a stock loan transaction.

2. The system of claim 1, wherein the user request and the firm request are in XML format.

3. The system of claim 1 , wherein the user request and the firm request are in SLML format.

4. The system of claim 1, comprising at least a second participating firm in electronic communication with the hub via the distributed network.

5. The system of claim 4, wherein the application tier is configured to transmit a request from the second member firm to the first member firm, wherein the request from the second member firm includes proposed parameters for the loan of stock to be used as collateral in a subsequent securities transaction.

6. The system of claim 1 , comprising browser software operating on the remote user terminal.

7. The system of claim 1 , wherein the protocol tier comprises an HTTP layer.

8. A method for conducting securities transactions, comprising: transmitting notification of a lender's availability, receiving the notification at a hub, making the notification available to borrowers, identifying a borrower that wishes to engage in a securities lending transaction with the lender, wherein the borrower negotiates the loan of stock to be used as collateral in a securities transaction.

9. A method for automatically borrowing securities, based on need, comprising: determining a need exists to borrow securities, broadcasting a request to borrow securities from a borrower to a hub via a distributed network, the request comprising desired terms, processing the request by an application tier in electronic communication with the hub, creating an order in accordance with the need, broadcasting the order to participating member firms via a distributed network, and responding to the need by indicating a desire to loan securities in accordance with the desired terms of the request, by a lender.

10. The method of claim 9, comprising receiving a responsive communication to the need at the hub and transmitting notification to the borrower and the lender.

11. The method of claim 10, wherein the notification comprises trade tickets.

12. A method comprising: transmitting a first communication from a first party to a hub, the first communication comprising first securities transaction terms defined by the first party, the first communication having a syntax, receiving the first communication by a message queue layer in electronic communication with the hub, processing the first communication by an application layer in electronic communication with the hub, determining whether the syntax of the first communication corresponds to a defined syntax, transmitting the first communication from the hub to a second party, receiving, at the hub, a responsive communication from the second party, the responsive communication comprising securities transaction terms defined by the second party, the second communication having a syntax processing the responsive communication by an application tier in electronic communication with the hub, determining whether the syntax of the responsive communication corresponds to a defined syntax, and transmitting the responsive communication to the first party via a distributed network.

13. The method of claim 12, comprising: transmitting a second communication from the first party to the hub, the second communication indicating acceptance by the first party of the securities transaction terms defined by the second party, issuing a trade ticket from the hub to the first party, and issuing a trade ticket from the hub to the second party.

14. The method of claim 12, comprising: transmitting a second communication from the first party to the hub, the second communication indicating non-acceptance by the first party of the securities transaction terms defined by the second party.

15. The method of claim 14, comprising transmitting a third communication from the first party to the hub, the third communication comprising second securities transaction terms defined by the first party, the third communication having a syntax, receiving the third communication by a message tier in electronic communication with the hub, processing the third communication by an application tier in electronic communication with the hub, determining whether the syntax of the third communication corresponds to a defined syntax, and transmitting the third communication from the hub to the second party.

16. The method of claim 12, wherein the first communication is in XML format.

17. The method of claim 12, wherein the first securities transaction terms comprise at least one of securities horrowing transaction terms and securities lending transaction terms.

18. The method of claim 17 comprising loaning stock for use as collateral in a securities transaction.

19. The method of claim 18 comprising conducting a billing comparison.

20. The method of claim 18 comprising conducting a mark-to- market comparison.

21. The method of claim 18 comprising conducting a contract comparison.

22. The method of claim 18 comprising issuing a recall.

23. The method of claim 22 comprising returning stock in response to the recall.