GB2403311A - System for securities borrowing and lending - Google Patents

Abstract

An electronic system for equities securities lending and financing 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.

Description

240331 1 System and Method for Securities Borrowing and Lending TECHNICAL

[GELD OF TlIE INVENTION [0001] The present invention relates to an electronic system 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.

BACKGROUND OF THE INVENTION

[00021 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 generically described as "securities lending".

100031 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.

10004] Participants in securities borrowing and lending transactions can be further sub- classified into: Beneficial Owners; Agent Lenders; Broker/Dealers; and External Customers.

I O 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 I 5 open 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.

5] 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 À 25 same securities at a fixture 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 tams 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.

6] 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.

100071 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 counterparts 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! perfonning 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.

10008] 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," represents the profit in the transaction. In a nonash collateralized lending transaction, the borrower and lender negotiate a premium (or a flat fee) to be paid in place of the rebate. I 1 9] Currently, there are two primary ways in which the securities lending operations are I 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 ernail. This process is inherently ineffective and prone to human and other errors which 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 counterparts 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.

100l0l 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 Pawnee system, as is described in U.S. Pat. No. 3,573,747. The Instinet system includes a series ofterminals, 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.

100ll] 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, due to time-zone differences. It would, therefore, be advantageous to provide a system that allows parties to broadcast availability messages in realtime, to facilitate the identification of suitable counterparties.

[00121 Unlike traditional securities transaction such as Me sale/purchase of stocks, bonds, etc., stock loan transactions remain "open" after the initial transaction is completed, i.e., We loan of stock for use as collateral in a financial transaction. It is, therefore, desireable 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.

100131 Further, it is desirable to have a system in which availability broadcasts could include the available party's desired transaction criteria. The system would, optimally, permit the available party to tailor the broadcast to include specific, desired transaction terms and enable the irntiation of orders that targets all available counterparties using a single messaging protocol.

10014] Moreover, as previously mentioned, prior art 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 (in the novel system described hereinafter, it is accomplished through contract compare, mark-to-market and billing compare).

Accordingly, it is desirable to have system that facilitates securities lending that provides the 'recall' feature to the lenders to recall securities that they have lent and 'return' feature to it's borrowers to return the securities recalled.

BRIEF SUMMARY OF THE INVENTION

100151 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 fums, brokers, and other participants in a process for lending securities.

100161 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.

7] As well, although many protocols for message transmission can be adapted for use with the present invention, the requests may be formatted in the extended markup language (X=) or the securities lending markup language (SLML).

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

00181 Figure I shows an illustrative embodiment of the hub of the present invention.

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

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

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

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

10023] Figure 6 shows an illustrative embodiment of the contract comparison feature of the present invention.

100241 Figure 7 shows an illustrative embodiment of mark to market comparison feature of the present invention.

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

[00261 Figure 9 shows an illustrative embodiment of the Retum/Recall feature of the present invention.

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

100281 Figure I I shows an illustrative embodiment of the autoborrow feature of the present invention.

100291 Figure 12 shows an illustrative embodiment ofthe initiation ofthe autoborrow feature of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

100301 The present system and method 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. Specifically the proposed hub/platform model would provide the following business-related benefits: 1) automation of trading related operations that are traditionally done manually; 2) creation and implementation of specific methods of conducting those business processes that provide value (Chaining Rules etc.) and eliminate errors (Shared Trade Ticket, Uniform Ids across counterparties for a transaction) ; 3) reconciliation of the metrics associated with a transaction at periodic intervals with the proprietary systems of the parties; 4) the opportunity to increase transaction volume; S) reduction, quick notification and resolution of errors; and 6) Standardization of pricing feeds and timing of trades.

100311 Further, the present system allows for the elimination of redundant IT infrastructure, a uniform protocol (such as an XML-based protocol, called SLML which is herein) 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.

100321 Other benefits to using the present system may include increased liquidity The single most important property of a successful securities market is the promotion of liquidity, i.e., the ability to trade investment positions quickly, efficiently, and with minimal market impact.

Definitions of liquidity range beyond the ability to deploy capital into and out of a market in an "efficient" way. Efficiency, in this context, generally refers to a transaction that is camed out without excessive transaction costs or impact on securities prices. In a broader sense, liquidity refers to the ability of market participants to make money by trading when a market is moving downward as well when the market is trending upwards. Liquidity also relies on efficient price information and settlement systems, low transactions pricing and spreads, and low infrastructure and tax costs.

I 5 10033] Certain securities lending activities provide a significant source of liquidity to a well developed capital market. By using the securities already outstanding in a market, securities lending has the effect of increasing the total supply of available assets. The trading and settlement; features of the present invention facilitate the use of stock assets, in effect, to do "double duty" in the i service of market liquidity by converting otherwise sterile holdings into a dynamic, internally generated source of finance that can support higher trading volumes and more sophisticated trading strategies. By turning existing stocks and bonds into financing sources for further transactions, a welldeveloped securities lending business can rnirumize trading friction, improve efficiency, reduce settlement fails and lower transaction costs across an entire capital market. Thus securities lending I plays an important role in ensuring liquidity in a capital market.

100341 The present system permits many parties in this business to be brought together onto I an trading hub that provides the functionality to successfully lend, borrow securities and conduct other back office operations, all in real-time and with increased reliability. Members have access to a large pool of available securities and efficient means of lending and borrowing them. Further, the: collection of various metrics in a data repository, and the generation of benchmarks and statistics: related to the securities lending industry, and the realignment and streamlining of trading and back office processes to avail the methodologies available on the platform.

[00351 The system is characterized, at least in one embodiment, as a hubbased 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.

[00361 A preferred embodiment of the invention uses the Securities Lending Markup Language (SLML) to serve as the uniform protocol used to exchange messages between participant fimns. SLML is based on XML (extended markup language), the popular open-standards language for complex data sharing between disparate applications. XML allows users to orgaruze 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 ful! flexibility.

100371 SLML, like XML, is interoperable across platfonns. 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 finn and throughout the industry.

100381 Furler, 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 which will specify the recipient/s to which the message is intended to. The Hub application processes the message and sends one or more messages to the specified recipient and a conflation message, if requested, is sent to the member who initiated the transaction.

100391 The important thing to note is that 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 fimns. A high-level overview illustrating one embodiment of the function of the hub and the communication which is handled by the hub is shown in Fig. 1.

10o4o] Such a system can be best described as adhering to an "n-tiei' 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.

100411 The 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.

10042] The system also includes an Application Tier which 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 which will result in the creationJupdate 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.

10043] 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 fimction. These messages are sent to and received by entities known as 'queues'. Simply described, queues are objects that hold messages. queue that is local to the program that is sending a message is known as a local queue and a remote queue is one which 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 mecharusm by which these queues need to be configured. In a simple configuration, there will be one queue per member per business function. For example for a given member orgPntion there will be 'n' number of queues, where 'n' is the number of business functions that the system supports.

Hence if a member 13 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.

100441 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 teir 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.

1451 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.

100461 A typical scenario will help illustrate the interaction between the tiers and clarify the division of responsibilities between these tierstlayers. 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 (usernametpassword 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. Ike messaging layer then deter nines 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 counterpanes A similar sequence of actions takes place when the initial request originates from a useraction 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 H11P 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.

100471 The presentation tier is the layer which deals with the user interaction portion of the application. The system's user interface is aneasy 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 H11P 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.

100481 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.

100491 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 (untie 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 fimns 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.

10050] The present system provides means for servicing XML requests received from I member funs. These means, such as an MQ handler application (such as the MQ Series Middleware Application sold by IBM Corporation of Armonk, NY), process accepted AIL I 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 film 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.

100511 The message queue design of the present system supports the transmission different types of messages using a two-channel transmission Mom 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.

100521 The messages sent between the member firms and the system hub permit potential I 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 Weir 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 commuTucation 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.

10053] 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 counterparts. 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. In a preferred embodiment of the invention, text messaging is supported between all parties, although the system is equally we11-implemented when text messaging is available between limited parties (i.e., those accessing the system via a browser interface).

10054] With the Total Quantity Management feature of the invention, the system marriages 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.

10055J 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 Me same Simultaneous Negotiation by sorting by the Simul Negot ID.

10056] 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 counterparts 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 counterparts 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.

10057] 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 Q=T tity to 10,000 and setting Max Quantity to 10,000 for each of the three counterparties. If one counterparts 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.

10058] 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.

100591 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 Weir desire to lend at the requested terms. An embodiment of the autoborrow process is illustrated in Fig. 5.

100601 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 Coder. 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 the* organization as the initiator of the order. This allows a single Autoborrow Record to be directed to counterparties frown different legal entities within the initiator's organization. All Autoborrow Records in the same batch must use or not use Chaining Rules. When using Chaining Rules, each record can use a different Chaining Rule.

100611 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.

10062] The present invention may also be provide contract comparison functionality. 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 which can be entered into their proprietary system, if desired. Each participant can view and reconcile any discrepancies, or breaks, via a browser, as well.

10063] The present system may also provide mark-to-market comparisons, as illustrated in Fig. 7, and billing comparisons as illustrated in Fig. 8 100641 Figure 9 illustrates an exemplary embodiment of the retum/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 I S until the process is complete.

100651 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 100661 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 rrunimize 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.

7] 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.

10068] 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 an system-issued Recall i ID. Returns that are not initiated as a result of Recall Will not generally be tied to any Recall ID.

10069] It is assumed that a specific reason code will be allocated by the DTC for inclusion on return settlement for Returns which 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 l in this case, the lender night only reduce the quantity of securities being recalled. Negotiations related to the terms of the Recall and discrepancy resolution must be handled outside of system.

Once resolved, the lender may choose to cancel the existing Recall and send a new Recall notice I with new Recall teens. If the quantity needs to be increased (e.g. due to a corporate action), the i Lender should cancel the original Recall and initiate a new one.

10o7o] 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 it is either satisfied by a return, cancelled by the lender, or a buy-in is issued against it.

100711 The system may also support a holiday calendar for all markets where participants trade. All 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.

100721 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.

100731 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: 100741 Sent: to [00751 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.

100761 Only applicable in cases where active acknowledgement is being used. Recalls that are using the Passive acknowledgement model will not use this state. l 10077] Accepted: 10078) A Recall notification that has been accepted by the borrower, indicating that they l have received the Recall. i 100791 Recall notifications that use the passive acknowledgement model will move immediately into the Accepted state.

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

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

acceptable reasons.

3] Pendino Return: [oo84l A Recall against which a Return(s) has been setup for the entire Recall quantity.

100851 Closed: 100861 A Recall that has had the requested securities returned using the system's Return fimctionality 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: 100871 Cancelled: 100881 A Recall that is cancelled by the lender. Once a Recall is cancelled, it cannot be accepted, rejected, or modified.

100891 Bouht-In: 1 9 l If the lender does a buy-in for the securities, then the Recall will move to a state of 1 5 bought-in.

10091] 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.

Claims (22)

1. CLAIMS: 1. 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 Dom the first participating fimn, and an application tier for validating and processing the firm request, and the firm request includes at least a parameter associated win a stock loan transaction.
2. 2. The system of claim 1, wherein the user request and the firm request are in XML format.
3. 3. The system of claim 1, wherein the user request and the firm request are in SLML format.
4. 4. The system of any preceding claim, comprising at least a second participating firm in electronic communication with the hub via the distributed network.
5. 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. 6. The system of any preceding claim, comprising browser software operating on the remote user terminal.
7. 7. The system of any preceding claim, wherein the protocol tier composes an HTTP layer.
8. 8. A method for conducting securities transactions, comprising: I transmitting notification of a lender's availability, i 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. 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. 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. 11. lye method of claim 10, wherein the notification comprises trade tickets.
12. 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 I 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 teens 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. 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. 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. I S. 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 cormnunication 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. 16. The method of any one of claims 12 to 15, wherein the first communication is in XML format.
17. 17. The method of any one of claims 12 to 16, wherein the first securities transaction terms comprise at least one of securities borrowing transaction terms and securities lending transaction terms.
18. I 8. The method of claim 17 comprising loaning stock for use as collateral in a securities transaction.
19. 19. The method of claim 18 comprising conducting a billing comparison.
20. 20. The method of claim 18 comprising conducting a mark-to-market comparison.
21. 21. The method of claim 18 comprising issuing a recall.
22. 22. The method of claim 21 comprising returning stock in response to the recall.