Systems and methods for electronically initiating and executing securities lending transactions

Systems and methods are provided for conducting securities lending transactions using an electronic trading platform. In accordance with an implementation, the electronic trading platform receives, from a trader, information identifying initial terms of a transaction to lend or borrow shares of a security. The electronic trading platform may generate an instruction to broadcast the initial terms to one or more counterparties, and may subsequently facilitate negotiations between the trader and the one or more counterparties for terms of the transaction. The electronic trading platform may execute the transaction in accordance with the negotiated terms.

BACKGROUND

1. Technical Field

The present disclosure generally relates to systems and methods for electronically trading securities. More particularly, and without limitation, the present disclosure relates to systems and methods that facilitate electronic negotiation of terms for securities lending transactions between a trader and one or more counterparties, that execute the securities lending transactions in accordance with the negotiation terms, and that submit the executed transactions to central clearing counterparties.

2. Background Information

Today, securities lending and borrowing are common practices among financial institutions, hedge funds, and investment banks due to increasing demand from the securities industry to cover settlement failures and support investment strategies involving short selling. Despite advances in high-speed algorithmic trading processes, transactions involving securities lending and borrowing are generally initiated and negotiated based on personal relationships between professionals working at financial institutions.

The reliance on bilateral agreements leveraging interpersonal relationships between contracting parties results in a lack of transparency in the securities lending market that affects all participants. In particular, the lack of market transparency may result in inefficient pricing strategies that reflect not only the value of the underlying securities, but also relatively high intermediate costs associated with the maintenance of bilateral counterparty credit agreements.

Further, the lack of a central clearing facility in the securities lending market increases capital costs for both prime brokers and agent lenders. Such capital costs, and the resulting balance sheet management issues, may become more onerous for market participants as regulators continue to strengthen the capital reserve requirements for major market participants.

In view of the foregoing, there is a need for improved systems and methods that negotiate terms for securities lending transactions between a trader and one or more counterparties and that execute the securities lending transactions in accordance with the negotiation terms. Moreover, there is a need for improved systems and methods to submit the executed securities lending transactions to central clearing counterparties. There is also a need for such systems and methods that can be implemented in a computer-based environment.

SUMMARY

Consistent with an embodiment of the present disclosure, a computer-implemented method receives, from a trader, information identifying initial terms of a transaction to lend or borrow shares of a security. The method generates an electronic instruction to provide the initial terms to a counterparty, and facilitates, using at least one processor, negotiations between the trader and the counterparty for final terms of the transaction. The step of facilitating may include, during the negotiations, at least one of (i) revealing information identifying the trader to the counterparty and (ii) revealing information identifying the counterparty to the trader. The method executes, using the at least one processor, the transaction in accordance with the negotiated final terms.

Consistent with a further embodiment of the present disclosure, a computer-implemented method receives, from a trader, information identifying initial terms of a transaction to lend or borrow shares of a security. The initial terms may include an identifier of the security and a quantity of the shares. The method generates an electronic instruction to provide the initial terms to a trading partner having a relationship with the trader through mutual agreement, and facilitates, using at least one processor, negotiations between the trader and the trading partner for final terms of the transaction. The method executes, using the at least one processor, the transaction in accordance with the final terms.

Consistent with another embodiment of the present disclosure, a computer implemented method receives, from a trader, information identifying an order to borrow or lend a security. The order may be posted to an electronic trading platform by a counterparty. The method modifies a status of the identified order, the modified status preventing additional traders from negotiating with the counterparty based on the posted order for a predetermined time period. The method generates an electronic instruction to broadcast, to the counterparty, initial terms of a transaction to lend or borrow shares of the security, and facilitates, using at least one processor, negotiations between the trader and the counterparty for one or more final terms of the transaction. The method executes, using the at least one processor, the transaction in accordance with the final terms.

Consistent with an additional embodiment of the present disclosure, a computer-implemented method receives, from a trader, information identifying initial terms of a transaction to lend or borrow shares of a security, and generates an electronic instruction to provide the initial terms to one or more counterparties. The method facilitates, using at least one processor, negotiations between the trader and the one or more counterparties for final terms of the transaction, and executes, using the at least one processor, the transaction in accordance with the final terms.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only, and are not restrictive of the invention as claimed. Further, the accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the present disclosure and together with the description, serve to explain principles of the invention as set forth in the accompanying claims.

DESCRIPTION OF THE EMBODIMENTS

Reference will now be made in detail to embodiments of the present disclosure, examples of which are illustrated in the accompanying drawings. The same reference numbers will be used throughout the drawings to refer to the same or like parts.

In this application, the use of the singular includes the plural unless specifically stated otherwise. In this application, the use of “or” means “and/or” unless stated otherwise. Furthermore, the use of the term “including,” as well as other forms such as “includes” and “included,” is not limiting. In addition, terms such as “element” or “component” encompass both elements and components comprising one unit, and elements and components that comprise more than one subunit, unless specifically stated otherwise. Additionally, the section headings used herein are for organizational purposes only, and are not to be construed as limiting the subject matter described.

FIG. 1illustrates an exemplary computing environment100within which embodiments consistent with the present disclosure may be practiced. InFIG. 1, client systems102and104may be connected with an electronic trading platform110via a communications network120. Further, inFIG. 1, electronic trading platform110may be connected with a central clearing counterparty130via a communications link122, and central clearing counterparty (CCP)130may be connected with a settlement agent140via a communication link124. As further disclosed herein, electronic trading platform110may facilitate direct negotiations between traders at client systems102and104to negotiate terms of transactions to lend or borrow shares of securities, which may be submitted to CCP130and settlement agent140for subsequent clearing, settlement, and novation.

In an embodiment, client systems102and104may include corresponding devices that facilitate interaction with trading platform110over network120, and additionally or alternatively, CCP130and settlement agent140. For example, devices associated with client systems102and104may include, but are not limited to, personal computers, laptop computers, notebook computers, hand-held computers, personal digital assistants, mobile phones, smart phones, and any additional or alternate computing device operable to interact and communicate with trading platform110over network120.

Communications network120may represent any form or medium of digital data communication. Examples of communication network120include a local area network (“LAN”), a wireless LAN, e.g., a “WiFi” network, a wireless Metropolitan Area Network (MAN) that connects multiple wireless LANs, and a wide area network (“WAN”), e.g., the Internet. Consistent with embodiments of the present disclosure, network120may comprise the Internet and include any publicly-accessible network or networks connected via one or more communication protocols, including, but not limited to, file transfer protocol (FTP), hypertext transfer protocol (HTTP) and transmission control protocol/internet protocol (TCP/IP). Moreover, communications network120may also include one or more mobile device networks, such as a GSM network or a PCS network, that allow user devices associated with system users, such as client system102, to send and receive data via applicable communications protocols, including those described above.

Trading platform110includes a web server112, a file transfer server114, and a data repository116, which may each be disposed in communication with an application server118. In an embodiment, application server118, in conjunction with data repository116, may be configured to facilitate negotiation and subsequent execution of transactions between traders at client systems102and104to lend or borrow shares of securities or other financial instruments.

In such an embodiment, traders at client systems102and104may access trading platform110by initiating communications sessions with web server112, which may be configured to perform communications protocol processing with client systems102and104, and any additional or alternate device, across network120using the communications protocols described above. Further, in such embodiments, file transfer server116may be configured to perform web-based and network-based file transfers with system users102and104and trading platform110, and between trading platform110and CCP130, and settlement agent140, as described below.

In an embodiment, data repository116may include one or more application programs that, upon execution by application server118, enable application server118to provide electronic negotiation and execution functions to traders disposed at client systems102and104. Data repository116may also store information leveraged by application server118to provide traders with access to trading platform110, to facilitate the negotiation of transactions terms, and to subsequently execute and submit for settlement these transactions in accordance with the negotiated terms. For example, and as described below, data repository116may include data identifying the traders (e.g., one or more authentication credentials), license information identifying client systems102and104, information identifying one or more trading partners and trading groups associated with the traders, information identifying a status of one or more negotiations involving the traders, information identifying prior executed transactions that involve, and order book data describing orders to lend or borrow securities posted to trading platform110.

In an additional embodiment, data repository116may store information identifying clearing instruments associated with CCP130(e.g., a universe of financial instruments that may be cleared by CCP130). For example, file transfer server114may receive the clearing instrument information from CCP130prior to the commencement of trading on a daily basis, at multiple times throughout the trading day, or at any additional or alternate interval apparent to one of skill in the art and consistent with the clearing processes of CCP130.

InFIG. 1, CCP130may include a file transfer server132and a data repository134, which are each in communication with an application server136. For example, and as described above, file transfer server132may be configured to perform web-based and network-based file transfers with electronic trading platform110and CCP130, and as such, may be configured to receive details of the executed transactions (e.g., transactions terms and corresponding counterparties) provided by trading platform110over communications link122.

Application server136, in conjunction with data repository134, may process the received transaction details to implement a clearing function, and further, implement one or more business functionalities that support transaction creation and lifecycle management. Application server136may also be configured to transmit information associated with the SBL transaction (e.g., terms of the executed transaction, and information identifying the negotiating parties) through file transfer server132across communications link124to settlement agent140.

In such embodiments, data repository134may include one or more application programs that, upon execution by application server136, cause application server136to perform the clearing process and one or more business functions. Furthermore, data repository134may also include information identifying one or more executed transactions at various stages of the clearing and settlement process, information identifying the traders associated with the transactions, and any additional or alternate clearing data apparent to one of skill in the art and necessary for the clearing process.

Referring back toFIG. 1, settlement agent140includes a file transfer server142and a data repository144, which are each in communication with an application server146. Similar to file transfer server132described above, file transfer server142may be configured to perform web-based and network-based file transfers with CCP130and additionally or alternatively, with one or more of client systems102and104. File transfer server142may receive information associated with cleared transactions from CCP130, and may also exchange settlement data directly with traders at client systems102and104. Such settlement data may include but is not limited to, information identifying the traders or various transactions details that facilitate booking and settlement of the executed transactions.

Application server146, in conjunction with data repository144, may process the cleared transaction to provide a settlement function. In such embodiments, data repository144may include one or more application programs that, upon execution may cause application server146to perform settlement functions for cleared transactions. Data repository144may also include information identifying the transactions in various stages of settlement, settlement data received from the traders at client systems102and104, settlement confirmations associated with previously-settled transactions, and any additional or alternate clearing data apparent to one of skill in the art and necessary for the settlement process.

In the embodiments described above, communication links122and124may represent any form or medium of digital data communication that facilitates real-time messaging and file transfer among trading platform110, CCP130, and settlement agent140. For example, communication links122and/or communications link124may represent one of the forms or mediums of digital data communication outlined above in reference to network120, e.g., a local area network (“LAN”), a wireless LAN, e.g., a “WiFi” network, a wireless Metropolitan Area Network (MAN) that connects multiple wireless LANs, and a wide area network (“WAN”), e.g., the Internet. In such an embodiment, file transfer servers114,132, and142may exchange information using any of the communications protocols outlined above, including but not limited file transfer protocol (FTP), hypertext transfer protocol (HTTP) and transmission control protocol/internet protocol (TCP/IP).

Communications links122and124may also represent a dedicated communications network associated with the financial services industry that facilitates both real-time messaging and secure file transfer. For example, such dedicated networks may include, but are not limited to, those networks provided by the Society for Worldwide Interbank Financial Telecommunication (i.e., “SWIFT”). In such embodiments, file transfer servers114,132, and142may exchange information using one or more customized protocols associated with the SWIFT network.

The disclosed embodiments are, however, not limited to such exemplary communications networks. In additional embodiments, communications links122and124may be representative of any additional or alternative communications network apparent to one or skill in that art that facilitates protocol processing, real-time messaging functionalities, and secure file transfer among file transfer servers114,132, and142.

Further, communication links122and124may function, respectively, as bi-directional reconciliation links between trading platform110and CCP130and between CCP130and settlement agent140. In such embodiments, communication links122and124may ensure that components of trading platform110, CCP130, and settlement agent140remain synchronized.

In the embodiment ofFIG. 1, the individual servers of trading platform110, CCP130, and settlement agent140may each represent a general purpose computer (e.g., a personal computer, network computer, server, or mainframe computer) having one or more processors that may be selectively activated or reconfigured by a computer program to perform corresponding functions. In additional embodiments, one or more of the individual servers may be combined into a single hardware unit. For example, web server112, file transfer server114, and application server118could be combined into a hardware unit, with the communications functions of web server112and file transfer server114being implemented within a software-based front end of the hardware unit, and the functionalities of application server118being implemented in a corresponding back-end of the single hardware unit. Furthermore, one or more of the individual servers may be incorporated as a node in a distributed network, e.g., application server118may communication via network120with one or more additional servers (not shown), which may application server118to distribute processes for parallel execution by a plurality of the additional servers.

Individual computing devices and servers associated with system users102and104, trading platform110, CCP130, and settlement agent140may represent any type of computer system capable of performing communication protocol processing.FIG. 2is an exemplary computer system200, according to an embodiment of the invention. Computer system200includes one or more processors, such as processor202. Processor202is connected to a communications infrastructure206, such as a bus or network, e.g., network120and communications links122and124ofFIG. 1.

Computer system200also includes a main memory208, for example, random access memory (RAM), and may include a secondary memory210. Secondary memory210may include, for example, a hard disk drive212and/or a removable storage drive214, representing a magnetic tape drive, an optical disk drive, CD/DVD drive, etc. The removable storage drive214reads from and/or writes to a removable storage unit218in a well-known manner. Removable storage unit218represents a magnetic tape, optical disk, or other computer-readable storage medium that is read by and written to by removable storage drive214. As will be appreciated, the removable storage unit218can represent a computer-readable medium having stored therein computer programs, sets of instructions, code, or data to be executed by processor202.

In alternate embodiments, secondary memory210may include other means for allowing computer programs or other program instructions to be loaded into computer system200. Such means may include, for example, a removable storage unit222and an interface220. An example of such means may include a removable memory chip (e.g., EPROM, RAM, ROM, DRAM, EEPROM, flash memory devices, or other volatile or non-volatile memory devices) and associated socket, or other removable storage units222and interfaces220, which allow instructions and data to be transferred from the removable storage unit222to computer system200.

Computer system200may also include one or more communications interfaces, such as communications interface224. Communications interface224allows software and data to be transferred between computer system200and external devices. Examples of communications interface224may include a modem, a network interface (e.g., an Ethernet card), a communications port, a PCMCIA slot and card, a wireless transmitter or card, etc. Software and data may be transferred via communications interface224in the form of signals226, which may be electronic, electromagnetic, optical or other signals capable of being received by communications interface224. These signals226are provided to communications interface224via a communications path (i.e., channel228). Channel228carries signals226and may be implemented using wire or cable, fiber optics, an RF link, wireless transmissions, and other communications channels. In an embodiment of the invention, signals226comprise data packets sent to processor202. Information representing processed packets can also be sent in the form of signals226from processor202through communications path228.

The terms “storage device” and “storage medium” may refer to particular devices including, but not limited to, main memory208, secondary memory210, a hard disk installed in hard disk drive212, and removable storage units218and222. Further, the term “computer-readable medium” may refer to devices including, but not limited to, a hard disk installed in hard disk drive212, any combination of main memory208and secondary memory210, and removable storage units218and222, which respectively provide computer programs and/or sets of instructions to processor202of computer system200. Such computer programs and sets of instructions can be stored within one or more computer readable media. Additionally or alternatively, computer programs and sets of instructions may also be received via communications interface224and stored on the one or more computer readable media.

Such computer programs and instructions, when executed by processor202, enable processor202to perform one or more of the computer-implemented methods described herein. Examples of program instructions include, for example, machine code, such as that code produced by a compiler, and files containing a high-level code that can be executed by processor202using an interpreter.

The computer-implemented methods described herein can also be implemented on a single processor of a computer system, such as processor202of system200. In another embodiment, computer-implemented methods consistent with embodiments of the invention may be implemented using one or more processors within a single computer system, and additionally or alternatively, these computer-implemented methods may be implemented on one or more processors within separate computer systems linked via a network.

As described above, computing environment100enables a trader associated with a client system (e.g., client system102) to access an electronic trading platform110to negotiate, execute, settle, and manage previously-settled securities lending transactions with one or more counterparties. For example, in such embodiments, the trader may access trading platform110, identify one or more counterparties based on posted order information and prior business or personal relationships, direct trades to one or more of the identified counterparties, and electronically negotiate terms of one of more stock lending transactions in a manner that optionally preserves an anonymity of the trader and/or one or more of the counterparties, as described below in reference toFIG. 3.

FIG. 3is a flowchart of an exemplary method300for electronically initiating and executing a securities lending transaction, according to disclosed embodiments. Method300may be implemented by a server of an electronic trading platform (e.g., application server118ofFIG. 1), which enables a trader at a client system (e.g., client system102) to negotiate terms of a securities lending transaction with one or more counterparties, to execute the securities lending transaction in accordance with the negotiated terms, and to submit the executed transactions to a clearinghouse (e.g., CCP130) for subsequent clearing and settlement. As will be apparent to one of skill in the art from the present disclosure, the steps and arrangement of the same inFIG. 3may be modified, as needed.

In step302, application server112may receive a request from the trader to access trading platform110and initiate a securities lending transaction. In such embodiments, the trader may be associated with a prime broker (e.g., an investment bank or other similar) that provides securities lending and borrowing services to hedge funds and other large investors. Alternatively, for example, the trader may be associated with an agent lender, who may hold securities for large individuals, corporations, and institutional investors and offer these held securities for lending. Further, in the embodiments described herein, the term “security” may refer to any stock, bond, derivative, or other financial instrument traded on any domestic, international, private, secondary, or over-the-counter exchange accessible to electronic trading platform110ofFIG. 1.

In an embodiment, the received request may include one or more login credentials of the trader, e.g., a user name and a corresponding password. For example, the trader may enter a URL into a web browser executing on client system102, and may subsequently provide the corresponding login credentials to request access to trading platform110.

Alternatively, trading platform110may be associated with an executable program installed locally on client system102. The trader may then execute the application program and provide the corresponding login credentials through a graphical user interface (GUI) associated with the application program. In such an embodiment, the received request may include not only the login credentials of the trader, but also information identifying a validity of a license associated with the application program (e.g., an alpha-numeric key or license number).

Referring back toFIG. 3, a web server associated with trading platform110(e.g., web server112ofFIG. 1) may receive the request from client system102over network120, and may provide the received request to application server118for authentication in step304. For example, application server118may subsequently obtain login credentials associated with the trader from a data repository (e.g., data repository116ofFIG. 1), and may compare the received and obtained login credentials to authenticate the trader in step304.

If the authentication fails in step304, then application server118may deny the trader access to trading platform110in step306. In step308, application server118may generate a corresponding error message, and in step310, may provide the error message to the trader at client system102. In an embodiment, web server112may transmit the error message to client system102across network120using any of the communications protocols outlined above. Exemplary method300is then complete in step312.

Alternatively, however, if the trader is authenticated in step304, then application server118grants the trader access to trading platform110in step314. In step316, application server118generates an graphical user interface (GUI) to facilitate access of trading platform110by the trader.

For example, in step316, application server118may access data repository116to obtain layout information identifying a standard layout or template of the GUI, and further to obtain additional information that customizes the GUI to the trader. For example, such customized information may include, but is not limited to, statistics summarizing securities lending transactions executed by trading platform110, information that identifies one or more trading groups and trading partners associated with the trader, and information associated with pending and completed negotiations involving the trader. The disclosed embodiments are not limited to such exemplary information, and in further embodiments, application server118may obtain any additional or alternate information that customizes the GUI to the trader from data repository116, or from any other data repository accessible to trading platform110over network120.

Application server118may subsequently provide the layout and customized information to client system102in step316. For example, the layout and customized information may be transmitted by web server112to client system102across network120using any of the communications protocols outlined above. In such an embodiment, client system102may receive the transmitted information and render the information to generate and display the GUI to the trader, as described below in reference toFIG. 4.

FIG. 4illustrates an exemplary graphical user interface (GUI)400, which may be displayed to a trader, in accordance with disclosed embodiments. For example, and as described above, client system102may receive, from an electronic trading platform (e.g., trading platform110ofFIG. 1) layout information associated with a graphical user interface (GUI) and additional information that customizes the GUI to a trader. In such an embodiment, client system102may render the received layout information to generate the template of the GUI, and further process the additional information to populate individual fields of the template and customize the template to the trader.

For example. inFIG. 4, user interface400includes a home page portion402that includes a welcome message402A and information402B that describes current trading statistics associated with the electronic trading platform. For example, welcome message402A identifies the trader (e.g., “NGA Trader”) last accessed trading platform110on Apr. 20, 2012, at 11:33 a.m. Further, inFIG. 4, information402B may include a list of a predetermined number of the “top” stocks within trading platform110, as determined by volume and fee. In such embodiments, the predetermined number may include thirty stocks, fifty stocks, or any additional or alternate number of stocks, and the determination of the “top” stocks may be determined in accordance with any additional or alternate metric appropriate to trading platform110. Further, as described below, the content displayed within home page portion402may vary in accordance with one or more activities of the trader.

User interface400also includes a menu portion404that facilitates navigation within user interface400and access to the functionalities of trading platform110. InFIG. 4, menu portion404may include a plurality of actionable icons representative of trading platform110functions, which are responsive to actions by the trader (e.g., clicking or hovering using a mouse pointer, selection via a touch pad, or the entry of one or more keystrokes). For example, menu portion404may include a “Messages” icon404A that enables the trader to access messages concerning system activity, a “Transactions” icon404B that enables that trader to access information associated with transactions awaiting settlement, an “Orders” icon404C that enables the trader to access information associated with orders entered into trading platform110, by the trader or other members of a corresponding firm, a “Reports” icon404D that provides the trader with information on previously-executed and/or settled transactions, and an “Automation” icon404E that enables the trader to access one or more automation settings of trading platform110.

Main menu portion404may also include a region404F (e.g., a text box) that enables the trader to search for one or more securities tradable within trading platform110using, for example, a name of a security or a corresponding CUSIP code. In such embodiments, and in response to the search query, trading platform110may display an order book for the queried security within home page portion402of interface400. Further, main menu portion404may also include a region404G that displays, for example, a status of trading platform110, information identifying one or more helpdesk numbers, and that provides a user with an opportunity to logout of trading platform110(e.g., a “Log Out” icon).

User interface400may also include sidebars that display information related to trading groups and trading partners. In the embodiments ofFIG. 4, a “Trading Group” sidebar406may be disposed in an upper-left portion of user interface400, and a “Trading Partner” sidebar408may be disposed in a lower-left portion of user interface400. The disclosed embodiments are, however, not limited to such exemplary dispositions, and in additional embodiments, sidebars406and408may be disposed in any additional or alternate portion of the user interface.

In an embodiment, “Trading Group” sidebar406lists one or more existing trading groups to which the trader may broadcast messages and direct transactions. For example, sidebar406lists four existing trading groups406A associated with the trader, including “Lenders Group A,” “Lenders Group B,” “Best Dow Lenders,” and “Favourite Lenders.” The disclosed embodiments are not limited to such exemplary trading groups, and in additional embodiments, sidebar406may list any additional or alternate number of trading groups defined by the trader and further, that include any number of individual trading parties apparent to one of skill in the art and identified by the trader. Further, in such embodiments, a member of a trading group (e.g., “Lenders Group A”) may be unaware of other members of Lending Group A, of the existence of trading group Lenders Group A, or of any other trading group associated with the trader.

Further, sidebar406may also include icon406B, which upon selection by the trader, may provide the trader with an opportunity to define a new trading groups and include one or more corresponding parties. In such embodiments, the corresponding parties may be selected by the trader (e.g., based on one or more identifiers entered into user interface400), or alternatively, may be generated programmatically with or without user input.

For example, in response to the trader's selection of icon406B, application server118of trading platform110may identify a plurality of candidate members of the new trading group based on one or more inclusion rules, and may filter the candidate members in accordance with one or more exclusion rules to generate the members of the new trading group. The inclusion rules may, in such embodiments, identify a candidate trading group member based on a total number of and/or a total value of trades executed by the candidate trading group member, a number of and/or a value of trades executed by the candidate trading group member that involve the trader, a number of and/or a value of trades executed by the candidate trading group member that involve a specified financial instrument, and a social networking relationship between the candidate trading group member and one or more existing trading partners. Further, in such embodiments, the exclusion rules may disqualify a candidate trading group member based on a number of defaults within a predetermined time period or a system ranking assigned to the candidate trading group members.

The disclosed embodiments are not limited to such exemplary inclusion and exclusion rules, and in further embodiments, the inclusion and exclusion rules may include any additional or alternate user-defined or system-defined rule apparent to one of skill in the art and appropriate to the traders of trading platform110. Further, as described above, a member of the new trading group may be unaware of any other members of the new trading group, of the existence of trading group Lenders Group A, and further, of any other trading groups associated with the trader.

Referring back toFIG. 4, “Trading Partner” sidebar408may include a region408A that displays statistics regarding the trading partners associated with the trader. For example, as depicted inFIG. 4, such statistics may include, but are not limited to, a number of existing trading partners, a number of outstanding requests to establish new trading partners, and a number of existing trading partners that are currently online. Further, in an embodiment, while each of the trading partners may be known to the trader, trading platform110may maintain a level of confidentiality between trading partners such that no single trading partner has knowledge of an identify any other trading partner.

Further, “Trading Partner” sidebar may408also provide a text box408B that enables a trader to search for trading partners and images or avatars408C of one or more of the online trading partners. In such embodiments, each image or avatar may be associated with a border indicative of a level of activity of the corresponding trading partner, and a color of the border may be indicative of the status of that the trading partner associated with that avatar within trading platform110. For example, a green border surrounding an avatar of a trading partner may indicate that the trading partner is online and currently active, while an orange border may indicate that the trading partner is online, but inactive.

The disclosed embodiments are not limited to such exemplary indicia of trading partner availability. In additional embodiments, a weight and or style of the border surrounding an avatar may be indicative of the status of that the trading partner associated with that avatar within trading platform110. For example, a dashed border surrounding an avatar of a trading partner may indicate that the trading partner is online and currently active, while a solid border may indicate that the trading partner is online, but inactive. Thus, in sidebar408ofFIG. 4, the avatar for “ABN trader” is surrounded by dashed line, and as such, “ABN trader” is logged into and active within trading platform110. Similarly, a solid line surrounding “MS trader” in sidebar408indicates that “MS trader” may be logged into trading platform110, but is currently indicative. In additional embodiments, user interface400may indicate trading partner activity using any additional or alternate color, and further, using any additional or alternate technique to visually distinguish between active and inactive trading partner avatars displayed within sidebar408.

Further, inFIG. 4, user interface400may includes sidebars that display information related to pending and completed negotiations for transaction terms and executed transactions (e.g., through a ticker of executed trades). In the embodiment ofFIG. 4, a “Negotiations” sidebar410may be disposed in an upper-right portion of the user interface, and a “Ticker” sidebar412may be disposed in a lower-right portion of the user interface. The disclosed embodiments are, however, not limited to such exemplary dispositions, and in additional embodiments, the “Negotiations” and “Ticker” sidebars may be disposed in any additional or alternate portion of the user interface.

In an embodiment, “Negotiations” sidebar410may list one or more negotiations initiated by the trader and/or members of the trader's firm. For example, inFIG. 4, sidebar410may include a plurality of tabs410A that display information on all current negotiations (e.g., the “All” tab inFIG. 4), incomplete negotiations (e.g., the “Incomplete” tab inFIG. 4), negotiations associated with completed transactions (e.g., the “Traded” tab inFIG. 4), and negotiations terminated by the trader or a counterparty (e.g., the “Killed” tab inFIG. 4).

For example, under the “All” tab ofFIG. 4, sidebar410displays a list of all current negotiations that involve the trader. Further, for each listed transaction, sidebar410may display a ticker symbol associated with a corresponding financial instrument (e.g., in the “Symbol” column), a type of transaction associated with the negotiation (e.g., in the “Dir” column), a value of the negotiation (e.g., in the “Value” column), and a fee associated with the transaction (e.g., in the “Fee” column). Further, for each negotiation, sidebar410may also provide an indication as to whether an identity of the trader is revealed to the counterparty (e.g., in the “Rev” column), an identity of the counterparty, if revealed (e.g., in the “Cpty” column), and an indication of the status of the negotiation (e.g., in the “Status” column).

In such embodiments, depicted inFIG. 4, the trader may have previously conducted a negotiation to borrow shares of Symantec Corporation from Citibank. Upon completion of the negotiation process, application server118of trading platform110may update interface400to include information identify the completed negotiation under both the “All” tab of sidebar410and the “Traded” tab of sidebar410. For example, entry410B of sidebar410indicates the trader borrowed shares of Symantec (i.e., “SYMC”) valued at $199,870 at a fee of 0.25% from Citibank (i.e., “CITIB”). Further, entry410B also indicates that the trader revealed a corresponding identity to Citibank.

Further, inFIG. 4, “Ticker” sidebar412may provide information associated with a plurality of transactions executed by trading platform110. For example, the executed transactions may be filtered using icon412A in accordance with execution time, value, stock symbol, or transaction fee, and colors may be assigned to the executed transaction information to indicate the assigned fee. Further, in such embodiments, while sidebar412may display detail of executed transactions, sidebar412may maintain an anonymity of the negotiating parties associated with the executed transaction.

In such embodiments, a change in the transaction fees associated with the executed trades may be indicated by a color of the displayed information. For example, if the electronic trading platform executes a transaction for a particular stock at a fee higher than for previous transaction, information on the executed transaction may be displayed in green. Similarly, if the fee for the executed transaction were lower than that for previous transactions, then information on the executed transactions may be displayed in red. Further, for example, if the fee were to remain unchanged, then information on the executed transaction may be displayed in white. The disclosed embodiments are not limited to such exemplary colors, and in additional embodiments, sidebar412may indicate a change in transaction fee using any additional or alternate color, or using any additional or alternate visual indicator apparent to one of skill in the art.

Further, in an embodiment, information associated with a trade may be displayed in sidebar412immediately upon execution to preserve transparency. For example, trade412B, which involved 5,064 shares of Cisco Systems (“CSCO”) valued at $103,812 at a fee of 0.26%, was executed at 10:50:52 a.m. Thus, information associated with trade412B may be displayed within sidebar412at or immediately after the time of execution.

The disclosed embodiments are, however, not limited to interfaces that immediately display information associated with executed transaction. While an individual trader may be anonymous within sidebar412, information on transactions executed by that trader may be visible to other market participants and may influence transaction fees and prices for securities of interest to the trader. Thus, the trader may wish to delay the display of the transaction executed by the trader while the trader accumulates a desired position in the security of interest.

In such embodiments, application server118may implement a delay between a time of execution and a time at which details are displayed within sidebar412of interface400for transactions associated with specific counterparties, or alternatively, for transactions involving specific securities. For example, the delay may be five minutes, fifteen minutes, thirty minutes, or any additional or alternate time period apparent to one of skill in the art and appropriate to trading platform110. Further, in additional embodiments, application server118may determine that sidebar412may not display details associated with transactions involving certain securities and certain counterparties or traders. In such embodiments, details on such executed trades would be withheld from the broader market and the broker/dealer community to the extent allowable by regulatory authorities.

Further, in such embodiments, a trader or firm associated with the trader may submit a fee or surcharge to the entities that administer trading platform110to ensure that details of transactions that involve the trader are not published or displayed within user interface400. For example, such fees may be paid as a surcharge on each executed trade, or alternatively, may be paid daily, monthly, annually, or at any other interval apparent to one of skill in the art. Further, in an embodiment, application server118may prevent the display of transaction details upon agreement not of one party, but of both counterparties to the executed transaction.

Referring back toFIG. 3, client system102may display the GUI to the trader, and based on the displayed information, the trader may identify one or more potential counterparties and transmit a request to initiate negotiations with the one or more counterparties from client system102to application server118. Application server118may receive the request from client system102in step320, and may process the received requests in step322to facilitate a negotiation process between the trader and the identified counterparty or counterparties to determine mutually-agreeable terms for transactions to lend or borrow securities.

For example, the GUI may enable the trader to identify orders to lend or borrow a security (e.g., bids to borrow or offers to lend) posted to trading platform110by corresponding counterparties. In such embodiments, as described below, the GUI may display the posted orders within an order book associated with the security, which may be presented to the trader upon entry of a corresponding query. The order book may include, for each posted order, information identifying the corresponding financial instrument (e.g., a stock symbol), a corresponding counterparty, and one or more negotiable terms.

For example, such terms may include, but are not limited to, a type of collateral (e.g., cash or non-cash collateral), a term (e.g., fixed or indeterminate), a quantity of securities, a market value of the securities, and a type of transaction fee (e.g., percentage fee or rebate). Further, the order book may also include counterparty information for each of the posted orders that includes, but is not limited to, an identity of the counterparty (e.g., a firm), a type of firm with which the counterparty is associated, and ownership status of the subject securities (e.g., whether the counterparty is an owner, beneficial owner, or trader), a role of the counterparty in the transaction (e.g., a middleman), a location of the counterparty, a type of counterparty, social networking information associated with the counterparty (e.g., trading partners in common between the trader and the counterparty), a location of the counterparty, a trading history of the counterparty (e.g., a number and/or a value of prior trades and a number of defaults), a system rating assigned by application server118to the counterparty, and any additional or alternate information apparent to one of skill in the art and appropriate to trading platform110.

In such an embodiment, the trader may “lift” a posted order from the displayed order book (e.g., through clicking, tapping, or entering a predetermined sequence of keywords to select the posted order), and client system102may transmit information associated with the lifted order to application server118as a request to initiate negotiations with the one or more corresponding counterparties. As described above, application server118may receive the negotiation request from client system102in step320, and may process the received request in step322to facilitate negotiations between the trader and the identified counterparty or counterparties to determine mutually-agreeable terms for a transaction involving the security associated with the lifted order.

Additionally, as described above, the counterparty associated with the selected order may be a member of a trading group created by the trader and displayed within a corresponding sidebar of the displayed user interface (e.g., “Trading Group” sidebar406ofFIG. 4). In such an embodiment, the trader may identify the trading group associated with the counterparty (e.g., by hovering a mouse point over the displayed counterparty of the selected order, or by selecting the trading groups from the corresponding sidebar), and client system102may transmit information associated with the displayed order and the trading group to application server118as a request to initiate negotiations with each member of the trading group.

Application server118may receive the negotiation request from client system102in step320and process the received request in step322to facilitate negotiations between the trader and each of the members of the trading group for a transaction involving the security associated with the selected order. Further, in such embodiments, each of the negotiations between the trader and a corresponding one or the members of the trading group may be confidential, and application server118may ensure that one trading group member is unaware of negotiations conducted with other trading group members, absent explicit disclosure from the trader.

Further, in an additional embodiment, the trader may select an avatar associated with a online and active trading partner displayed within the trader interface (e.g., in “Trading Partners” sidebar408ofFIG. 4A). Client system102may then transmit information identifying the selected trading partner to application server118as a request to initiate negotiations with the selected trading partner for a transaction to lend or borrow shares of a security. In such an embodiment, the selected trading partner need not have evinced a desire to borrow or lend the security, and the selection of the trading partner by the trader may be based on, for example, a desire to obtain a “special” security or one that is in short supply within the order posted to trading platform110.

Further, and upon receipt of the request from the trader in step320, application server118may generate a corresponding interface (e.g., a negotiations window) within step322that enables the trader to enter a set of initial negotiation terms and counterparties for a corresponding transaction to borrow or lend shares of a security. In such embodiments, an identifier of the security and a quantity of the shares subject to the transaction may represent “essential” components of the initial terms, which may also include, but are not limited to, a type of collateral (e.g., cash or non-cash collateral), a term of the transaction (e.g., fixed or indeterminate), a market value of the securities, and a type of transaction fee (e.g., percentage fee or rebate). Further, although the initial transaction terms may include a value of the corresponding transaction fee, such a term is not essential and may excluded to enable the counterparty to provide a quote for the transaction fee.

In such embodiments, the negotiations window may be provided to client system102and displayed within the GUI provided to the trader (e.g., GUI400ofFIG. 4). The displayed negotiations window may further enable the trader to request a broadcast of the initial negotiation terms to the counterparties (e.g., the counterparty associated with the selected order, each of the trading group members, and the selected trading partner) to facilitate negotiations on the terms of the stock lending transaction.

The disclosed embodiments may also enable a potential counterparty to post an “anonymous” order to trading platform110. For example, a counterparty may accumulate a position in a security to hedge against a prior short or long position, and may thus wish to remain anonymous while posting an order to borrow a certain quantity of the security to hedge against the short position. In such embodiments, application server118of trading platform110may enable the counterparty to post an order to trading platform110while remaining completely anonymous, or alternatively, while revealing various levels of identifying information, including, but not limited to, the counterparty's name or user name, a firm associated with the counterparty, a role played by the counterparty in the transaction (e.g., a middleman), the counterparty's ownership stake in the security (e.g., an owner, beneficial owner, etc.), a location of the counterparty, social networking information associated with the counterparty (e.g., trading partners of the counterparty), and a trading history of the counterparty (e.g., a number and/or a value of prior trades and a number of defaults).

In such an embodiment, the negotiations window provided to the trader in step322may enable the trader, along with the other negotiable terms, to request that the counterparty, or alternatively, a subset of counterparties, reveal identifying information as a condition of continuing negotiations. Additionally or alternatively, the negotiations window may enable the counterparty or counterparties to provide, in response to the request, corresponding identities or types of identifying information described above.

Upon presentation of the negotiations window within the displayed GUI, the trader may further enter a personal message for broadcast to the counterparty or counterparties, and may subsequently enter the initial proposal for terms of the desired transaction. Client system102may subsequently transmit information associated with the initial transaction terms and the personal message to application server118via web server112, and application server118and web server112may coordinate to broadcast the received initial transaction terms and personal message to the counterparty (or counterparties) over communications network120. In such an embodiment, application server118may update portions of the trader interface displayed to the trader at client system102to indicate the ongoing negotiation with each of the counterparties and the corresponding terms of each step in the negotiation process (e.g., within “Negotiations” sidebar410ofFIG. 4).

Upon broadcast of the initial terms, application server118may facilitate negotiation processes in step322that enable each of the counterparties to respond to the initial terms with agreement, a request to terminate the negotiations, or alternatively, with a counter to the initial terms. Upon receipt of the response, application server118may update a portion of the displayed GUI (e.g., “Negotiations” sidebar410to reflect a current status and current terms of the negotiation with each of the counterparties. In the case of a counter to the initial transaction terms, application server118may provide the trader with an opportunity to agree to the terms of the counter, terminate the negotiation process, or alternatively, submit an additional counter using the displayed negotiations window. In such embodiment, when broadcasting to multiple counterparties, the negotiations between the trader and each of the counterparties may be confidential such that the terms offered to one counterparty and unknown to any of the other counterparties.

The negotiation process facilitated by application server118in step322may continue until either the trader or the counterparties agree to terms for a transaction or alternatively, elect to terminate the negotiation process. Further, during negotiation with multiple counterparties (e.g., from a single trading group), and upon identification of an agreement between the trader and a corresponding one of the counterparties, application server118may provide the trader with an option to kill ongoing negotiations with the other counterparties in view of the agreement with the corresponding counterparty. Upon completion of the negotiation process, application server118may receive information identifying a success or failure of the negotiations between the trader and the counterparty or multiple counterparties.

Further, in the negotiation process facilitated by application server in step322, the trader and the one or more counterparties may reach an agreement on each of the multiple terms or parameters that specify a transaction for lending or borrowing securities. For example, to successfully negotiate the transaction, the trader and counterparties must not only agree on a value for a fee associated with the transaction (e.g., a corresponding “price”), but also on other negotiable terms that include, but are not limited to, a type of collateral for the transaction (e.g., cash or non-cash), a fee arrangement for the transaction (e.g., a percentage fee of a value of the negotiated shares or a rebate), a duration of the transaction, a quantity of the shares of the security, and any additional or alternate parameter or transaction term appropriate to the transaction and negotiable using trading platform110.

Referring back toFIG. 3, in step324, application server118may update the displayed GUI to indicate a status of the completed negotiation process with the one or more counterparties. For example, if the negotiations with a particular counterparty were unsuccessful (e.g., the trader or one of the counterparties elected to end negotiations), application server118may update the displayed GUI to indicate a failure of the particular negotiation (e.g., through an entry under the “Killed” tab of sidebar410in GUI400). Alternatively, if the negotiations with a particular counterparty resulted in agreement, application server118may update the displayed GUI to indicate a success of the particular negotiation (e.g., through an entry under the “Completed” tab of sidebar410in GUI400).

In such embodiments, in step324, application server118may update a status of each of the pending negotiations (e.g., between the trader and each of the multiple counterparties) automatically, without trader input, and upon completion of the corresponding pending negotiations. Further, in such embodiments, application server118may generate an alert indicating a completion of the negotiations (e.g., success and agreed-upon terms, or failure) with a particular counterparty, which may be broadcast directly to the trader and the particular counterparty, and additionally or alternatively, provided to the trader and counterparty within portions of corresponding displayed GUIs (e.g., under “Messages” icon404A of GUI400).

Application server118may subsequently execute transactions for the successful negotiations in accordance with the agreed-upon terms in step326. For example, as described above, application server118may execute transactions not only on the basis of a mutually-acceptable price or transaction fee, but also on the basis of mutually-acceptable values for each of the negotiable terms or parameters that specify the transaction, as outlined above. In such embodiments, application server118may execute transaction to borrow and lend a security, or a basket of securities, based on a set of mutually-acceptable transaction terms that satisfy the requirements of the trader and each of the one or more counterparties.

Further, in step328, application server118may update a portion of the displayed GUIs (e.g., a corresponding entry under “Ticker” sidebar412within GUI400) to reflect terms of each executed transaction. As described above, the GUI may immediately display the updated entry upon execution, or may display information associated with the executed transactions subsequent to a predetermined delay.

Further, in step330, and for each successful negotiation between the trader and a corresponding counterparty, application server118may generate transaction receipts or “trade tickets” memorializing the agreed-upon terms for the transaction to lend or borrow the corresponding financial instrument. Application server118may then provide, for each executed transaction, the generated trade tickets to the trader and the corresponding counterparty. For example, the generated trade tickets may be transmitted, to the trader and the corresponding counterparties, over network120by a file transfer server associated with trading platform110(e.g., file transfer server110ofFIG. 1) using any of the file transfer protocols outlined above (e.g., FTP). Additionally or alternatively, application server122may provide the generated trade tickets in step330to the trader and counterparty within portions of corresponding displayed GUIs (e.g., under “Messages” icon404A of GUI400), or web server112may distribute the trade tickets across network120using any of the communications protocols outlined above.

In step332, application server118may submit the terms of the executed transactions to a central clearing counterparty (e.g., CCP130ofFIG. 1) over communications link122. In such embodiments, the terms of the executed transaction may be provided to CCP130using file transfer server114, and upon receipt of the terms of the executed transaction, CCP130performs the corresponding clearance functions for the trader and the corresponding counterparties based on clearance data and corresponding collateral deposits provided to CCP130, as described above.

CCP130may subsequently transmit information identifying the executed transactions to a settlement agent (e.g., settlement agent140ofFIG. 1) via a corresponding communications link (e.g., communications link124ofFIG. 1). Upon completion of settlement of the executed transaction, settlement agent130may transmit, over communication link124, confirmations of the settlement to CCP130, which may subsequently forward the settlement confirmations to trading platform110across communications link122.

In step334, application server118may distribute the received settlement confirmations to the trader and each of the corresponding counterparties across network120. For example, and as described above, application server118, in conjunction with web server112, may transmit the settlement confirmation to the trader and corresponding counterparties over network120using any of the communications protocols outlined above. Further, in step334, application server118may update corresponding portions of the GUI displayed to the trader and to the one or more counterparties to reflect the settled transactions (e.g., under “Orders” icon404C of GUI400).

Further, in an embodiment, application server118may also generate in step334a report for the settled transactions, and additionally or alternatively, the executed transactions. Such reports may include, but are not limited to, information identifying the terms of the corresponding transactions, information identifying the trader and the corresponding counterparties, and information identifying a status of the settlement of the transaction. Application server118may provide the generated reports directly to the trader and the corresponding counterparties over network120, or alternatively, application server118may update corresponding portions of the GUI displayed to the trader and to the one or more counterparties to include the generated reports (e.g., under “Reports” icon404D of GUI400).

Application server118may then determine in step336whether the trader is currently logged onto trading platform110. If the trader is currently online and active within trading platform110, method300passes back to step320, and application server118awaits an additional request from the trader to initiate a securities lending transaction with one or more counterparties. Alternatively, if application server118determines that the trader has logged out of trading platform110(e.g., the trader clicked the “Log Out” icon in region404G of GUI400), exemplary method300passes back to step312and is complete.

In the embodiments described above, trading platform110may transmit information associated with the executed trades to a single central clearing counterparty (e.g., CCP130ofFIG. 1). The disclosed embodiments are not limited to such a single central clearing counterparty, and in additional embodiments, trading platform110may leverage a plurality of geographically-dispersed central clearing counterparties to provide clearing functions to executed trades (e.g., based on trader locations, etc.).

As described above, trading platform110may enable potential counterparties to post orders to lend or borrow financial instruments to trading platform110. In such embodiments, a trader may view posted orders to borrow or lend for a particular security and, through trading platform110, negotiate with terms of a transaction to borrow or lend shares of the security with a corresponding counterparty, as described below in reference toFIG. 5.

FIG. 5is a flowchart of an exemplary method500for electronically negotiating terms of a securities lending transaction between a trader and a single counterparty, according to disclosed embodiments. Method500may provide functionality that enables a server of an electronic securities lending system (e.g., application server118of trading platform110inFIG. 1) to provide posted orders to lend or borrow a security to a trader, and to enable the trader to select a posted order and negotiate terms of a transaction involving that security with a corresponding counterparty. In such embodiments, method500may be incorporated into the exemplary processes of step322ofFIG. 3, which enables application server118to facilitate direct negotiations between the trader and the one or more counterparties. As will be apparent to one of skill in the art from the present disclosure, the steps and arrangement of the same inFIG. 5may be modified, as needed.

InFIG. 5, application server118may receive a request for information associated with posted orders to lend or borrow shares of a security (e.g., bids to borrow or offers to lend) in step502. As described above, trading platform110may enable various counterparties to post orders to lend or borrow one or more securities. In such embodiments, and in contrast to conventional techniques, the orders posted to trading platform110do not specify a firm price or establish a specified transaction fee and as such, represent “non-firm” orders to borrow or lend the corresponding security.

For example, as described above, a trader at a client system (e.g., client system102ofFIG. 1) may request access to an electronic trading platform (e.g., trading platform110ofFIG. 1), and upon authentication, application server118may provide to the trader a graphical user interface (e.g., GUI400ofFIG. 4). In such embodiments, the trader may access a search function of the graphical user interface (e.g., text box404F of GUI400) and may enter a search query to identify posted orders to lend or borrow shares of a security. For example, the search query may include, but is not limited to, a name of the security, and symbol associated with the security on exchange, or any additional or alternative information identifying the financial instrument as would be appropriate to trading platform110. Upon entry of the search query, client system102may transmit information associated with the search query as a request for posted orders, which may be received by application server118in step502.

Upon receipt of the request, application server118may access a corresponding data repository (e.g., data repository116ofFIG. 1), and obtain information associated with one or more posted orders to lend or borrow the security. For example, the obtained information may correspond to an order book for the security, which may include tabular data on posted bids and offers for the security and information identifying terms for the posted bids and offers. In such embodiments, as described above, the posted orders need not be associated with a price or transaction fee, and as such, these posted orders represent non-firm orders to lend and/or borrow the financial instrument.

Application server118may provide the obtained order book information to client system102in step506. In such embodiments, a web server associated with trading platform110and in communication with application server118(e.g., web server112ofFIG. 1) may transmit the order book information to client system102using the communications protocols outlined above. Upon receipt of the order book information, client system102may process the received information and display the order book for the requested financial instrument to the trader within a corresponding portion of the graphical user interface (e.g., within home page portion402of GUI400), as described below in reference toFIG. 6A.

FIG. 6Aillustrates an exemplary electronic (or online) order book600for a financial instrument, in accordance with disclosed embodiments. In an embodiment, order book600may be displayed to a trader within a corresponding portion of a graphical user interface (e.g., home page portion404of GUI400inFIG. 4). Order book600is not limited to such exemplary dispositions, and in additional embodiments, order book600may disposed within any additional or alternate portion of GUI400, or within any additional or alternate user interface, apparent to one of skill in the art appropriate to a client system of the trader.

InFIG. 6, region602includes information identifying the financial instrument associated with order book600. For example, region600may indicate that the security corresponds to shares of Tesla Motors Inc. (i.e., “TSLA”) having a CUSIP code “88160R101,” and that shares of TSLA last closed on the NASDAQ at $38.15. The information within region602is not limited to such exemplary identifiers and valuations, and in additional embodiments, region602may include any additional or alternate apparent to one of skill in the art and identifying the security.

Order book600also includes tabular data604associated with one or more orders to lend or borrow the security posted to trading platform110by corresponding counterparties. In the embodiment ofFIG. 6, tabular data604separates the posted orders into bids to borrow the security and offers to lend the security, and for each bid and offer, identifies a corresponding quantity of shares of the security, identifies the corresponding counterparty, and identifies one or more terms of the corresponding bid or offer.

The identified term of the posted orders may include, but is not limited to, a type of collateral (e.g., cash or non-cash), a type of transaction fee (e.g., fee or rebate), and a term (e.g., open-ended or fixed term). In such embodiments, however, values for the fees or rebates associated with the posted orders are not specified in order book600, as these posted orders represent non-firm orders to borrow or lend the security.

Further, in order book600, counterparties associated with the posted orders may be assigned a ranking by system118that indicates, for example, a quality of the corresponding counterparty (e.g., the firm and/or a specific trader). In such embodiments, the system ranking associated with a particular order may be indicated by a visual cue to assist traders in differentiating between orders on the platform that otherwise share the same or similar parameters. In an embodiment, the system ranking may be based on a ratio of a firm's trade quotes on the platform to executed transactions, and additionally or alternatively, the number of transactions a firm has executed on the platform.

The disclosed embodiments are not limited to such exemplary ranking techniques, and in additional embodiments, any of a number of different algorithms may be used to implement the ranking system based on the specific needs of traders using the system, which include but are not limited to input received from individual traders (e.g., personalized “likes” or “dislikes” of specific counterparties) and social networking information associated with the counterparties (e.g., presence of such counterparties in trading groups).

Further, in an embodiment, the visual cue associated with a posted order in order book600may depend on a value of the corresponding system ranking. For example, when a system ranking for a posted order exceeds a predetermined threshold value, a star may be provided next to the posted order in order book600. Additionally or alternatively, a color of a star associated with a posted order may vary depending on a value of the corresponding system ranking (e.g., a red star if the system ranking exceeds a predetermined threshold value, and a blue star if the system ranking fails to exceed the predetermined threshold value). The disclosed embodiments are not limited to such exemplary visual cues, and in additional embodiments, order book600may leverage any additional or alternate visual indicator to differentiate posted orders based on system ranking that would be apparent to one of skill in the art.

In the exemplary order book ofFIG. 6A, a single system ranking is generated for each of the posted orders. In additional embodiments, trading platform110may generate multiple rankings for each of the posted orders. For example, application server118may generate a first system ranking for each posted order that accounts for a trading history of the counterparty (e.g., numbers of trades and values of trades) and a second system ranking indicative of a number of defaults by the counterparty. Further, in such embodiments, an additional ranking may be assigned to each of the posted orders that accounts for input by traders associated with trading platform110, and additionally or alternatively, social networking information associated with a counterparty (e.g., a presence of the counterparty in trading groups or an establishment of individual trading partners associated with the counterparty).

Referring back toFIG. 6A, order604A indicates that counterparty JPMorgan Chase & Co. (“JPMC”) offers to lend 17,000 shares of TSLA stock for an indeterminate time period in exchange for cash collateral (e.g., “C” under the “Collat” column) and a transaction fee to be specified later (e.g., “F” under the “Type” column). Further, in order book600, counterparty JPMC is associated with a star under the “Rank” column, and as such, a system ranking for JPMC may exceed a threshold value, thus indicating that JPMC is a highly-rated counterparty. Further, order604B indicates that an anonymous counterparty (e.g., “anon”) bids to borrow 390,000 shares of TSLA stock for an indefinite time period in exchange for cash collateral (e.g., “C” under the “Collat” column) and a transaction fee to be specified later (e.g., “F” under the “Type” column).

As described above, trading platform110enables a counterparty to anonymously post an offer to borrow or lend a security, and further, facilitates a negotiation process conducted anonymously or with various levels of anonymity. For example, a counterparty may wish to remain anonymous in order to hide an accumulation of a specific financial instrument from the broader market, knowledge of which may influence prices on the market and motivate potential competitors to take similar positions. Further, in such embodiments, the counterparty associated with the posted order may remain completely anonymous to all other traders, or alternatively, the posted order may reveal information identifying the counterparty to a subset of the other traders (e.g., those traders that share a trading group with the counterparty, one or more trading partners of the counterparty, or any arbitrary subset of the other traders identified or approved by the counterparty).

InFIG. 6A, the anonymous counterparty in field604B is associated with a star under the “Rank” column, indicating that while anonymous, the counterparty is highly rated by the system and is likely to be a reliable trading partner. Further, while the counterparty of order604B may elect to remain completely anonymous, the disclosed embodiments may allow a counterparty to provide some degree of identifying information while withholding the name of the trader's firm.

For example, such identifying information may include, but is not limited to, a type of organization with which the counterparty is associated, an ownership status of the subject securities (e.g., whether the counterparty is an owner, beneficial owner, or trader), a role of the counterparty in the transaction (e.g., a middleman), a location of the counterparty, social networking information associated with the counterparty (e.g., trading partners in common between the trader and the counterparty), a location of the counterparty, a trading history of the counterparty (e.g., a number and/or a value of prior trades and a number of defaults), a system rating assigned by application server118to the counterparty, and any additional or alternate information apparent to one of skill in the art and appropriate to trading platform110.

Referring back toFIG. 5, in step508, application server118may receive from client system102information identifying a particular posted order within a displayed order book (e.g., order book600ofFIG. 6A). For example, client system102may display the order book to the trader within the corresponding portion of the graphical user interface, and a trader may select a corresponding order within the displayed order book (e.g., by clicking on the displayed order using a mouse or touch page, or by entering a corresponding set of keystrokes). Upon selection of the corresponding order, client system102may transmit information identifying the selected order, which may be received by application server118in step508.

For example, the selection of the posted order by the trader may be reflective of a desire by the trader to enter into negotiations with a counterparty for a transaction similar to the posted order and involving shares of the same security. In such an embodiment, application server118may “lock out” the posted order in step510and block other traders within the system from selecting the posted order. In such embodiments, application server118may modify a status associated with the posted order to prevent other traders from attempting negotiations based on the posted order. For example, the graphical user interface displayed to the trader may be updated to provide a visual indication of the locked-out status of the posted order, e.g., the posted order may be grayed-out or otherwise highlighted.

By locking out the posted order, application server118may provide a period of exclusivity within which the trader and a counterparty associated with the posted order may negotiate terms of a transaction based on the posted order. In such embodiments, the time period during which the posted order is locked out may correspond to a time period during which the negotiation between the trader and counterparty continue, or alternatively, the posted order may be locked out for a predetermined period of time (e.g., the trader may be granted a limited period of exclusivity within which negotiations must be completed).

In step512, application server118may provide an interface to the trader to facilitate direct negotiations with the counterparty associated with the posted order. For example, the interface may correspond to an instant messaging window, and web server112may coordinate with application server118to transmit information associated with the instant messaging window to client system102for display to the trader. For example, the instant messaging window may provide functionality that enables the trader to modify terms of the posted order, provide a personalized message to the counterparty, and optionally reveal an identity to the counterparty, as described below in reference toFIG. 6B.

FIG. 6Billustrates an exemplary negotiations window610that enables a trader to conduct direct negotiations with a counterparty, in accordance with disclosed embodiments. For example, as described above in reference toFIG. 6A, the trader may select order604A, thereby indicating a desire to borrow a portion of the shares of TSLA that JPMorgan Chase & Co. is willing to lend to potential counterparties. In response to this selection, application server118may automatically provide negotiations window610to client system102to enable the trader to directly negotiate with a counterparty at JPMorgan Chase & Co. In such embodiments, one or more fields within window610may be populated automatically by application server118to reflect information and terms associated with order604A.

For example, inFIG. 6B, window610identifies counterparty JPMorgan Chase & Co. within address field612. As described above, address field612may be automatically populated by application server118with the counterparty associated with the order. The disclosed embodiments are not limited to such exemplary techniques, and in additional embodiments, the trader may enter any additional or alternate address information within address field612, including but not limited to multiple recipients, as described below.

Window610may also enable the trader to direct a message to the counterparty identified within message field613. For example, inFIG. 6B, the trader may enter “Looking for Tesla” in message field613. The disclosed embodiments are not limited to such exemplary message text, and in additional embodiments, the trader may enter any additional or alternate message text appropriate to trading platform110(e.g., within specified character limits).

The trader may further provide an initial proposal for terms of a transaction involving the identified counterparty within fields614of window610. For example, fields614include a direction field (e.g., “Dir”) that enables the trader to specify a direction of the transaction (e.g., borrow “B” or lend “L”), a “Type” field that enables the trader to specify a transaction type (e.g., fee-based “F” or rebate-based “R”), a collateral field (e.g., “Coll”) that enables the trader to specify a type of collateral (e.g., cash “C” or non-cash “N”), and a “Term” field that enables the trader to specify a temporal term for the transaction. Further, fields614also includes a “Stock” field that enables the trader to identify the particular financial instrument of interest, a “Quantity” field that enables the trader to specify a desired quantity of the financial instrument, a “Value” field that automatically calculates a value of the proposed quantity of instruments (e.g., based on a prior closing value), and a “Fee” field that optionally allows the trader to specify a fee or rebate associated with the proposed transaction.

For example, inFIG. 6B, the trader selected JPMorgan Chase & Co. as a potential counterparty based on a order posted by JPMorgan Chase & Co. to lend shares of Tesla stock (e.g., by lifting order604A from order book600). In such embodiments, application server118may automatically populate one or more of fields614(e.g., the direction field, the Type field, the collateral field, and/or the Term field) with transaction terms associated with the posted order. Further, in an embodiment, application server118may prevent the trader from modifying one or more of the populated fields in a manner inconsistent with the posted order. For example, application server118may prevent the trader from modifying the direction field from borrow “B” to lend “L” when the selected order specifies the counterparty wishes to lend securities to other traders.

For example, referring back toFIG. 6B, the trader may propose within fields614to borrow 10,000 shares of Tesla (i.e., “TSLA”) having a value of $351,500 for an indeterminate time in exchange for a fee of 18% and cash collateral. In such embodiments, the value of the 10,000 shares of TSLA is computed based on the prior day's close of TSLA shares (e.g., $35.15 US). Further, while the trader proposes a fee of 18% for the transaction, the proposed fee is not an essential element in negotiation processes consistent with the disclosed embodiments. In additional embodiments, application server118may enable the trader to leave the Fee field blank, thereby enabling counterparty JPMC to quote a transaction fee necessary to execute the transaction for TSLA shares.

Further, window614also provides “Reveal Id” field616, which enables the trader to optionally provide identifying information to the counterparty. For example, by checking Reveal Id field616, the trader elects to provide such identifying information to counterparty JPMC as a part of the negotiating process. In such embodiments, the identifying information may include, but is not limited to, the trader's name, a name of the trader's firm, a type of organization with which the trader is associated, an ownership status of the subject securities (e.g., whether the trader is an owner and beneficial owner), a role of the trader in the transaction or a type associated with the trader (e.g., a middleman), a location of the trader, a trading history associated with the trader, social networking information of the trader (e.g., identifies or a number of trading partners), and any additional or alternate type of identifying information apparent to one of skill in the art and appropriate to trading platform110. For example, inFIG. 6B, the trader elects to reveal identifying information to counterparty JPMC, and as such, the trader is identified within the proposed terms.

Alternatively, the trader may elect not to check Reveal ID field616and to remain anonymous while proposing initial terms for the transaction to counterparty JPMC. For example, the trader may wish to mask his or her intentions to obtain a position in the financial instrument (i.e., Tesla stock), or further, the trader may believe that the revelation of his or her identity, or identifying information, at a later stage of the negotiation may result in more advantageous terms of the transaction. In such an embodiment, the trader's identity may not be included within the initial terms proposed to counterparty JPMorgan Chase & Co.

Upon entry of the initial terms for the negotiation within fields614, and a corresponding entry within Reveal ID field616, the trader may check or otherwise select a “Send” icon618. In response to the trader's selection of Send icon618, client system102may transmit the initial transaction terms, and additionally or alternatively, information identifying the trader, across network120to a web server of trading platform110(e.g., web server112).

Referring back toFIG. 5, application server118may receive the initial negotiation terms from client system102in step514, and may transmit the initial negotiation terms as a message to a corresponding counterparty, e.g., JPMorgan Chase & Co. in step516. For example, web server112may broadcast the initial terms, and additionally or alternatively, information identifying the trader, to the counterparty over network120using any of the communications protocols outlined above. In such embodiments, application server118may facilitate a messaging session through which the trader and the counterparty may directly communicate and negotiate terms for the transaction based on the posted order.

In step518, application server118may generate an update to the graphical user interface provided to the trader, which may subsequently be provided to client system102. For example, the update may include information identifying the newly-initiated negotiation and the initial transaction terms proposed by the trader. In such embodiments, and as described above, web server112may transmit the update over network120to client system102, which may display the update to the trader within a corresponding portion of the graphical user interface, as described below in reference toFIG. 6C.

FIG. 6Cillustrates an exemplary updated sidebar620of a graphical user interface, consistent with the disclosed embodiments. For example, updated sidebar620may correspond to a portion of a “Negotiations” sidebar (e.g., sidebar410ofFIG. 4) displayed to a trader logged onto a trading platform provided by an electronic securities lending system (e.g., trading platform110ofFIG. 1). In the embodiment ofFIG. 6C, updated sidebar620may list one or more negotiations that involve the trader and/or a firm associated with the trade, which may be organized in accordance with a plurality of tabs622. For example, tabs622may include, but are not limited to, an “All” tab that displays information on all current negotiation, an “Incomplete” tab that displays information on all incomplete negotiations, a “Traded” tab that displays information on all completed negotiations, and a “Killed” tab that displays information on all negotiations terminated by the trader or corresponding counterparties.

For example, in the embodiment ofFIG. 6C, updated sidebar620includes entry624corresponding to the initial negotiation terms transmitted to counterparty JPMorgan Chase & Co. in step516of method500. Entry624indicates that the trader proposes to borrow (e.g., “B” under the “DIR” column) shares of Tesla stock (i.e., “TSLA”) from counterparty JPMorgan Chase & Co. (i.e., “JPMC”) in exchange for a fee of 18% Further, icon624A within entry624(i.e., under the “Status” column) indicates that the initial negotiation terms have been transmitted to the counterparty and that the trader awaits a reply from the counterparty.

Referring back toFIG. 5, application server118may receive a response to the trader's initial negotiation terms from the counterparty in step520. For example, and as described above, web server112may have received the response from the counterparty across network120using any of the communications protocols outlined above. Based on the received response, application server118may determine in step522whether the counterparty ended the negotiation process in view of the trader's initial negotiation terms.

As described above, trading platform110may provide the counterparty, and additionally or alternatively, the trader, with an option to terminate negotiations at any point in the negotiation process with the trader. In such an embodiment, the counterparty response received by application server118in step520may indicate the counterparty's desire to terminate negotiations with the trader. For example, the counterparty may not desire to do business with the trader's firm, e.g., due to a conflict of interest, or alternatively, the initial negotiation terms provided by the trader may be wholly incompatible with the needs of the counterparty. Further, as described above, application server118may enable either the counterparty or the trader to terminate negotiations at any point within the negotiations process.

If application server118determines in step522that the counterparty terminates negotiations, then application server118may conclude the negotiation process between the trader and the counterparty in step524, and may subsequently unlock the selected order (e.g., order604B of order book600) in step526. Exemplary method500is then complete in step528, and an indication of the terminated negotiation may be passed back to step324of exemplary method300ofFIG. 3, which provides an update indicating a failure of the negotiation with the counterparty to the graphical user interface displayed to the trader at client system102, as depicted inFIG. 6D.

FIG. 6Dillustrates an exemplary updated sidebar620of a graphical user interface, consistent with the disclosed embodiments. As described above, counterparty JPMorgan Chase & Co. received the initial negotiation terms provided by the trader, and in response, elected to terminate negotiations with the trader. As such, entry624corresponding to the initial negotiation terms is updated to include icon624B, which is indicative of the failed negotiation. Further, entry624may be moved from the “Incomplete” tab of tabs622to the “Killed” tab due to the termination of negotiations.

Referring back toFIG. 5, if application server118determines that the counterparty has not terminated negotiations in step522, then application server118determines whether the counterparty has agreed to execute the transaction in accordance with the initial negotiation terms in step530. If application server118determines in step530that the counterparty agrees to the initial negotiation terms, then application server118may generate and output information identifying the agreed-upon transaction terms in step532. Exemplary method500then passes back to step528, and the negotiation process is complete.

In such an embodiment, the agreed-upon transaction terms may be passed back to step322of exemplary method300ofFIG. 3, which provides an update indicating a success of the negotiation with the counterparty to the graphical user interface displayed to the trader at client system102, and which subsequently executes the transaction in accordance with the negotiated terms, as depicted inFIGS. 6E-6F

FIG. 6Eillustrates an exemplary updated sidebar620of a graphical user interface, consistent with the disclosed embodiments. As described above, counterparty JPMorgan Chase & Co. received the initial negotiation terms provided by the trader, and in response, elected to terminate negotiations with the trader. As such, entry624corresponding to the initial negotiation terms is updated to include icon624C, which is indicative of the success of the negotiation. Further, entry624may be moved from the “Incomplete” tab of tabs622to the “Completed” tab due to the termination of negotiations.

Additionally, as depicted inFIG. 6F, application server118may also update a “Ticker” sidebar630displayed within a corresponding portion of the graphical user interface (e.g., sidebar412of GUI400inFIG. 4) to reflect a transaction executed in accordance with the agreed-upon terms. For example, entry632ofFIG. 6Findicates that a transaction involving 10,000 shares of Tesla stock having a value of $351,500 US at a fee of 18% was executed by platform trading platform110at 11:34:40.

Referring back toFIG. 5, if application server118determines in step530that the counterparty fails to agree to the initial negotiation terms, then application server118may determine that the received response corresponds to a counter of the initial negotiation terms in step533. For example, the counterparty may agree in principle to execute a transaction with the trader, but may wish to modify one or more of the material terms of the transaction. Such material terms may include, but are not limited to, a type of transaction, a value of a fee or rebate associated with the transaction, a number of shares subject to the transaction, a type of collateral associated with the transaction, and/or a temporal duration of the transaction.

In step534, application server118may also provide an update to the graphical user interface of the trader that reflects the revised terms provided by the counterparty. In such embodiments, and as described above, web server112may transmit the update over network120to client system102, which may display the update to the trader within a corresponding portion of the graphical user interface, and which may further provide the trader an opportunity to respond to the revised terms, as described below in reference toFIGS. 6G-6H.

FIG. 6Gillustrates an exemplary updated sidebar620of a graphical user interlace, consistent with the disclosed embodiments. For example, updated sidebar620may correspond to a portion of a “Negotiations” sidebar (e.g., sidebar410ofFIG. 4) displayed to a trader logged onto an electronic trading platform (e.g., trading platform110ofFIG. 1). In the embodiment ofFIG. 6G, entry624of updated sidebar620may include icon624D, which indicates that a counter has been provided by counterparty JPMorgan Chase & Co.

Further, sidebar620may highlight one or more negotiation terms modified by the received counter, for example, to increase a visibility. In an embodiment, a border associated with each of the modified terms may be dashed or may be thickened to indicate the corresponding modification, and additionally or alternatively, a color of a portion of updated sidebar620may be modified to highlight the presence of a revised term. For example, a thickened, dashed border about entry624E indicates that the counterparty proposes an increase in the transaction fee from 18% to 20%. The disclosed embodiments are, however, not limited to such exemplary techniques, and in further embodiments, a revised term within a corresponding entry of updated sidebar620may be highlighted using any of a number of additional or alternate visual cues.

Upon display of the revised terms within updated sidebar620, the trader may select entry624, or any term within entry624, to obtain access to a negotiations window640, which may enable the trader to respond to the counter provided by counterparty JPMorgan Chase & Co.FIG. 6Hillustrates an exemplary negotiations window640, in accordance with disclosed embodiments.

Similar to negotiations window610described above, negotiations window640ofFIG. 6Hincludes a region642that enables the trader to include a personalized message to counterparty JPMorgan Chase & Co., and fields614that outline the current terms of the negotiation, which include the terms of the received counter. For example, fields614indicate that the counter provided by counterparty JPMorgan Chase & Co. increases the transaction fee from 18% to 20%, while leaving all other transaction terms unchanged. Further, negotiation window640provides messages region645, which displays each direct communication exchanged between the trader and counterparty JPMorgan Chase & Co., and additionally or alternatively, may provide the trader with an opportunity to view a set of negotiation terms associated with each communication.

Negotiations window640may provide the trader with an opportunity to respond to the revised terms provided by counterparty JPMorgan Chase & Co. For example, the trader may be satisfied with the revised terms (e.g., the fee increase to 20%), and may signal acceptance of the revised terms by selecting an “Accept” icon646. Alternatively, the trader may find the revised terms unacceptable, or further, may determine that more advantageous terms may be obtained from an additional counterparty. In such an embodiment, the trader may terminate the negotiations by selecting a “Kill” icon648.

Further, the trader may be dissatisfied with the revised terms provided by counterparty JPMorgan Chase & Co., but may wish to continue negotiations. In such an embodiment, negotiations window640may enable the trader to modify one or more of the terms within fields614(e.g., reducing the transaction fee to 19%) and provide the modified terms in response to the counter. Upon entry of a counter or selection of icons646or648, client system102may transmit information associated with the trader's response across network120to web server112of trading platform110.

Referring back toFIG. 5, application server118may receive the trader's response to the counter in step536, and may subsequently determine in step538whether the trader agrees to the revised terms of the counter. If the trader agrees to the revised terms, exemplary method500may pass back to step532, and application server118may generate information identifying the agreed-upon transaction terms. As described above, the negotiation process is complete in step528, and the agreed-upon transaction terms may be passed back to step324of exemplary method300ofFIG. 3, which provides an update indicating a success of the negotiation to the graphical user interface displayed to the trader at client system102.

Alternatively, if application server118determines that the trader does not to agree to the revised terms, then application server118determines whether the trader terminates the negotiations in step540. If the trader terminates the negotiations with the counterparty in step540, then exemplary method500passes back to step524, in which application server118may generate an indication of the failed negotiations. Further, application server118may unlock the posted order in step526, and the negotiation process is completed in step528. In such embodiments, the generated indication may be passed back to step324of exemplary method300ofFIG. 3, which provides an update indicating a failure of the negotiations to the graphical user interface displayed to the trader by client system102.

If the trader does not terminate the negotiations in step540, application server118determines in step542that the trader has countered the revised terms. Method500then passes back to step516, and application server118broadcasts the terms of the trader's counter to the counterparty. In such embodiments, the exemplary negotiation processes described above may continue until either the trader or the counterparty agree to terms for the proposed transaction, or alternatively, one of the trader or the counterparty elects to terminate the negotiations.

Further, in an embodiment, trading platform110may impose a time limit on the negotiation process. For example, the time limit may be imposed directly, e.g., trading platform110terminates negotiations between the trader and counterparty after an expiration of a threshold time period, or indirectly, e.g., trading platform110unlocks the posted order corresponding to the negotiations after the expiration of the threshold time period to allow other parties to negotiate. In an embodiment, and in response to a direct or indirect termination, the trader and counterparty could optionally continue negotiations offline to obtain agreement, and the agreed-upon terms could be submitted to trading platform110for clearing, settlement, and novation through a “locked order” function outlined below in reference toFIG. 12.

In the embodiments described above, an individual trader may obtain information identifying an order book associated with a particular financial instrument (e.g., shares of Tesla stock), and may subsequently “lift” a posted order within the order book to initiate negotiations with a corresponding counterparty for a transaction involving Tesla stock. The disclosed embodiments are not, however, limited to negotiations between the trader and a single counterparty.

For example, as described above, a trader may be associated with one or more trading groups. In such embodiments, a trading group may include one or more counterparties with whom the trader often interacts and conducts business. As described above, the trader may manually generate a trading group by selecting the preferred counterparties for inclusion in the group, or alternatively, an application server associated with an electronic trading platform (e.g., application server118of trading platform110inFIG. 1) may generate a trading group programmatically by filtering a set of candidate counterparties in accordance with any arbitrary set of rules (e.g., that exclude counterparties disposed in certain geographic locations, e.g., Spain or Greece). In such embodiments, application server118may enable the trader to direct specific trades to a group of multiple counterparties, e.g., a trading group, as outlined below in reference toFIG. 7.

FIG. 7is a flowchart of an exemplary method700for electronically negotiating terms of a securities lending transaction between a trader and multiple potential counterparties, according to disclosed embodiments. Method700may provide functionality that enables a server of an electronic trading platform (e.g., application server118of trading platform110inFIG. 1) to receive information identifying multiple counterparties from a trader and to enable the trader to simultaneously and confidentially negotiate terms of a transaction with the corresponding counterparties. In such embodiments, method700may be incorporated into the exemplary processes of step322ofFIG. 3, which enable application server118to facilitate direct negotiations between the trader and the counterparties. As will be apparent to one of skill in the art from the present disclosure, the steps and arrangement of the same inFIG. 7may be modified, as needed.

In step702, application server118may receive information identifying a plurality of counterparties from a trader at a client system (e.g., client system102ofFIG. 1.). For example, the trader may provide information identifying the counterparties to client system102(e.g., using a displayed graphical interface, and as described above), and client system102may transmit the information to a web server of trading platform110(e.g., web server112ofFIG. 1) using the communications protocols outlined above.

In an embodiment, the counterparties may be members of a trading group associated with the trader (e.g., “Lenders Group A” of GUI400inFIG. 4), and the trader may hover over an icon representing “Trading Group A” within a corresponding graphical user interface to view the counterparties associated with “Lenders Group A.” For example, as depicted inFIG. 8A, the trader may hover over an icon802representing “Lenders Group A” in “Trading Groups” sidebar800to obtain a list804of the members of “Lenders Group A,” including counterparties “BNY Mellon,” “State Street,” and “Northern Trust.” The trader may subsequently click or otherwise select icon802, and client system102may transmit information associated with the members of “Lenders Group A” to trading platform110as a request to initiate simultaneous negotiations with the members of “Lenders Group A.”

Additionally or alternatively, as described above, the trader may access an order book associated with a corresponding security (e.g., order book600ofFIG. 6A). Upon hovering over a counterparty associated with a posted order within the order book (e.g., counterparty “JPMC” of order604A inFIG. 6A), the graphical user interface may display a trading group to which JPMorgan Chase & Co. belongs, and the trader may click or otherwise select the displayed trading group. In such embodiments, client system102may transmit information associated with the displayed trading group, and additionally or alternatively, its members, to trading platform110as a request to initiate simultaneous negotiations with the members.

Further, as also described above, the trader may access an interface (e.g., negotiations window610ofFIG. 6B) that enables the trader to initiate negotiations for a transaction involving a single counterparty. In such an embodiment, and prior to entering one or more initial terms, the trader may specify additional counterparties to whom the initial terms should be broadcast. Upon entry of these additional counterparties, which may form an “ad hoc” trading group, client system102may transmit information associated with the displayed trading group, and additionally or alternatively, its constituent members, to trading platform110as a request to initiate simultaneous negotiations with the members.

Further, in an embodiment, the interface may enable the trader to specify terms of a transaction to lend or borrow shares of a single security, or alternatively shares of multiple securities. For example, the interface may enable the trader to identify each of the multiple securities, specify a quantity of shares and corresponding share value for each of the multiple securities, and enter corresponding transaction terms for each of the multiple securities. In such embodiments, the interface may enable the trader to initiate negotiations with a single counterparty for a transaction to borrow or lend a “basket” of securities.

Upon receipt of the information identifying the multiple counterparties (e.g., the members of a corresponding trading group), application server118may subsequently provide an interface to the trader in step704to facilitate direct negotiations with the each of the multiple counterparties. For example, the interface may correspond to an instant messaging window, and web server112may coordinate with application server118to transmit information associated with the instant messaging window to client system102for display to the trader. In such embodiments, the instant messaging window may provide functionality that enables the trader to broadcast a personalized message, initial terms for the negotiation of the transaction, and optionally, an identity of the trader, to each of the multiple counterparties, as described below in reference toFIG. 8B.

FIG. 8Billustrates an exemplary negotiations window810that enables a trader to confidentially conduct direct negotiations with multiple counterparties, in accordance with disclosed embodiments. As depicted inFIG. 8B, negotiations window810includes a region812specifying the multiple counterparties to which the initial negotiation terms may be directed (e.g., “Lenders Group A” described above). In such embodiments, region812may also include a text box812A that enables the trader to enter one or more additional counterparties or groups of counterparties to generate an “ad hoc” trading group, as discussed above.

Negotiations window810may also include a text box813within which the trader may enter a personalized message that will be transmitted by application server118to each of the multiple counterparties specified in region812. For example, inFIG. 8B, the trader has entered the phrase “Looking for Tesla” within text box813.

Further, in an embodiment, negotiation window810may enable the trader to specify terms of a transaction to lend or borrow shares of a single security, or alternatively shares of multiple securities. For example, as described above, negotiation window810may enable the trader to identify each of the multiple securities (e.g., within the Stock field), specify a quantity of shares and corresponding share value for each of the multiple securities (e.g., within the Quantity and Value fields), and enter corresponding transaction terms for each of the multiple securities (e.g., within the Fee field). In such embodiments, the interface may enable the trader to initiate negotiations with multiple counterparties for a transaction to borrow or lend a “basket” of securities.

Negotiations window810also provides a “Reveal Id” field816, which enables the trader to optionally provide identifying information to each of the multiple counterparties. For example, by checking “Reveal Id” field816, the trader elects to provide identifying information within the initial negotiating terms broadcast to the multiple counterparties. In such embodiments, the identifying information may include, but is not limited to, the trader's name, a name of the trader's firm, a trading history of the trader, information identifying the trader's relationship to the security (e.g., ownership), information identifying the trader's role in the transaction (e.g., a middleman), social networking information of the trader (e.g., identifies or a number of trading partners), a geographic location of the trader, and any additional or alternate type of identifying information apparent to one of skill in the art and appropriate to trading platform110.

The disclosed embodiments are not limited to techniques that disclose information identifying the trader to each of the multiple counterparties. In additional embodiments, negotiations window810may afford the trader an opportunity to disclose identifying information to only a subset of the multiple trading parties. For example, the trader may desire to remain anonymous to a first subset of the multiple counterparties, who may represent competitors or unfriendly firms, and to disclose identifying information to a second subset of the multiple counterparties, which may represent friendly firms.

Additionally or alternatively, negotiations window810may provide the trader with an ability to disclose identifying information having various degrees of specificity. In such an embodiment, the trader may elect to remain completely anonymous to a first subset of the multiple counterparties, to be fully identified to a second subset of the multiple counterparties, and to disclose a portion of the identifying information to a third subset of the multiple counterparties in a manner that preserves the trader's strict anonymity. For example, the trader may withhold a firm name from the third subset of counterparties, while providing information identifying a trading history, a geographic location, or social networking information (e.g., common trading partners) to the third subset of counterparties.

Referring back toFIG. 8B, upon entry of data into fields814, the trader indicates a desire to initiate negotiations with each member of “Lenders Group A” to borrow a total of 100,000 shares of Tesla stock (i.e., TSLA) valued at $3,515,000 US for an indefinite term in exchange for a fixed fee of 18% and cash collateral. As described above, the value of the proposed quantity of TSLA stock is computed automatically based on the prior day's close of TSLA shares (e.g., $35.15 US). Further, while the trader proposes a fee of 18% for the transaction, the proposed fee is not an essential element in negotiation process, and in additional embodiments, the trader may request a quote for an appropriate fee from each of the members of Lenders Group A. Furthermore, by checking “Reveal ID” field816, the trader elects to transmit identifying information to the members of Lenders Group A as a part of the initial negotiation terms.

Once satisfied with the initial negotiation terms, the trader may subsequently click or otherwise select “Send” icon818in negotiations window810, and client system102may transmit the initial negotiation terms to trading platform110. In an embodiment, and as described above, client system102may establish communications with web server112of trading platform110and may transmit the initial negotiation terms to web server112using any of the communications protocols outlined above.

Referring back toFIG. 7, application server118may receive the information identifying the initial negotiation terms and the multiple counterparties in step706, and in step708, application server118may broadcast the initial negotiation terms to each of the multiple counterparties. For example, web server112, in conjunction with application server118, may transmit the initial negotiation terms to each of the members in Lenders Group A across network120using any of the communication protocols outlined above. In such embodiments, application server118, in conjunction with web server112, may serve as a conduit for negotiations between the trader and each of the multiple counterparties.

In step710, application server118may provide an update that reflects the initial transaction terms to a graphical user interface displayed to the trader (e.g., by client system102). For example, the update may identify the newly-initiated negotiations between the trader and the multiple counterparties, e.g., the members of “Lenders Group A,” and the terms of these initial negotiations. In such embodiments, and as described above, web server112may transmit the update over network120to client system102, which may display the update to the trader within a corresponding portion of the graphical user interface, as described below in reference toFIG. 8C.

FIG. 8Cillustrates an exemplary updated sidebar820of a graphical user interface, consistent with the disclosed embodiments. For example, updated sidebar820may correspond to a portion of a “Negotiations” sidebar (e.g., sidebar410ofFIG. 4) displayed to a trader by an electronic trading platform (e.g., trading platform110ofFIG. 1). Updated sidebar820may also list or more negotiations that involve the trader and/or a firm associated with the trader, which may be organized in accordance with a plurality of tabs822. For example, tabs822may include, but are not limited to, an “All” tab that displays information on all current negotiations, an “Incomplete” tab that that displays information on all incomplete negotiations, a “Traded” tab that displays information on all completed negotiations, and a “Killed” tab that displays information on all negotiations terminated by the trader or corresponding counterparties.

As described above, the trader has initiated negotiations for a stock lending transaction with the members of Trading Group A, which includes BNY Mellon (i.e., “BNYM”), State Street (i.e., “SS”), and Northern Trust (i.e., “NT”). In such an embodiment, updated “Negotiations” sidebar820may include entry824corresponding to counterparty BNY Mellon, entry825corresponding to counterparty State Street, and entry826corresponding to counterparty Northern Trust. As updated “Negotiations” sidebar820includes only the initial negotiation terms for negotiations with these three potential counterparties, the terms displayed within entries824,825, and826are identical. Further, as depicted inFIG. 8C, entries824,825, and826each includes a “clock” or “hourglass” icon indicative of an ongoing nature of the corresponding negotiations and a “link” icon indicative of a linkage between the corresponding negotiations.

Referring back toFIG. 7, in step712, application server118may facilitate an individual and confidential negotiation session between the trader and each of the multiple counterparties (e.g., BNY Mellon, State Street, and Northern Trust). Each of the negotiation sessions facilitated by application server118in step712may be comparable to those described above with respect to the individual counterparty ofFIG. 5(e.g., within steps512-542of method500inFIG. 5).

For example, and for each individual negotiation session, application server118may await a response to the broadcasted initial transaction terms from the corresponding counterparty. In such an embodiment, one of the counterparties, e.g., State Street, may provide a response to the initial transaction terms. As described above, trading platform110may enable State Street to accept the initial transaction terms, to terminate the negotiations with the trader, or alternatively, provide a counter to the initial transaction terms. For example, if State Street elects to terminate negotiations, application server118may provide an update a “Negotiations” sidebar provided to client system102that reflects the failed negotiations (e.g., by adding an appropriate icon to entry825of updated Negotiations sidebar820ofFIG. 8C). Further, if counterparty State Street agrees to the initial negotiation terms, application server118may identify a successful negotiation between State Street and the trader, as described below in reference to step714.

If, however, counterparty State Street provides a counter to the initial negotiation terms, application server118may update a graphical user interface displayed to the trader to reflect the terms of the counter. For example, as described above, the update may identify those terms modified by the counter within a corresponding entry in a Negotiations sidebar of the graphical user interface, may reorder the displayed entries to highlight the counter, and may provide the trader with an opportunity to respond to the counter, as described below in reference toFIGS. 8D and 8E.

FIG. 8Dillustrates an additional portion of an exemplary updated sidebar820of a graphical user interface, consistent with the disclosed embodiments. As described above, and in response to the counter provided by State Street, application server118may reorder the entries of sidebar820to position entry825, which is associated with counterparty State Street, at an initial position within the entries. Further, inFIG. 8D, re-ordered entry825of sidebar820may include an icon825A, which indicates a response to the initial transaction terms has been received from counterparty State Street.

Sidebar820may also highlight each transaction term modified by the received counter to increase a visibility of the modified term. As described above, a color of a portion of sidebar820may be varied to visually highlight the presence of the revised term or terms. For example, a color of portion of sidebar820corresponding to entry825B may be changed yellow to indicate that the State Street proposes an increase in the transaction fee from 18% to 20%. Additionally or alternatively, a border associated with each of the modified terms may be dashed or thickened to visually indicate the modification, e.g., a dashed border about entry825B indicates may indicate the modified term.

Upon display of the revised terms within updated sidebar820, the trader may select entry825, or any term within entry825, to obtain access to a negotiations window840, which enables the trader to respond to the counter provided by State Street, as described inFIG. 8E. Further, in an additional embodiment, the trader may select or click on a corresponding message within a messaging window or page of a displayed graphical user interface (e.g., associated with Messages icon404A ofFIG. 4) to obtain access to negotiations window840.

FIG. 8Eillustrates an exemplary negotiations window840of a graphical user interface, consistent with the disclosed embodiments. Negotiations window840ofFIG. 8Emay include a region842that enables the trader to include a personalized message to counterparty State Street and fields844that identify the current terms of the negotiation, including those modified by the counter. For example, fields844indicate that the counter provided by counterparty State Street increases the transaction fee from 18% to 20%, while leaving all other transaction terms unchanged. Further, negotiation window840provides a region845that displays each direct communication exchanged between the trader and counterparty State Street, and additionally or alternatively, may provide the trader with an opportunity to view a set of negotiation terms associated with each communication.

In an embodiment, negotiations window840may provide the trader with an opportunity to respond to the revised terms provided by counterparty State Street. For example, the trader may be satisfied with the revised terms (e.g., the fee increase to 20%), and may signal acceptance of the revised terms by selecting a “Accept” icon846, and may include a message of “Thanks!” within region842.

Alternatively, the trader may determine the revised terms are unacceptable, or alternatively, that more advantageous terms may be obtained from an additional counterparty. In such an embodiment, the trader may terminate the negotiations by selecting a “Kill” icon848.

Additionally, the trader may be dissatisfied with the revised terms provided by counterparty State Street, but may wish to continue negotiations. In such an embodiment, negotiations window840may enable the trader to modify one or more of the negotiation terms within fields844(e.g., reducing the transaction fee to 19%). Upon entry of a counter or the selection of icons846or848, client system102may transmit information associated with the trader's response across network120to web server112of trading platform110.

Within step712, application server118may receive the trader's response to the revised transaction terms provided by State Street. As described above, the trader may elect to terminate negotiations with State Street, agree to the revised transaction terms, or propose an additional counter to the revised terms. For example, if the trader elects to terminate negotiations, application server118may update a “Negotiations” sidebar provided to client system102to reflect the failed negotiations (e.g., by adding an appropriate icon to entry825of updated Negotiations sidebar820ofFIG. 8C). Alternatively, if the trader agrees to the revised transaction terms, application server118may identify a successful negotiation between State Street and the trader, as described below in reference to step714.

Furthermore, if the trader provides an additional counter, application server118may transmit information associated with the additional counter to State Street, update the Negotiations sidebar displayed to the trader (e.g., as described above in reference toFIG. 8C), and await an additional response from State Street. In such embodiments, the negotiation processes of step712may continue until either an agreement is reached between the trader and one or more of the counterparties (e.g., BNY Mellon, State Street, and Northern Trust) or alternatively, negotiations between the trader and each of the multiple counterparties are terminated. Furthermore, the negotiations between the trader and each of the multiple counterparties may be confidential, and no single counterparty may have knowledge of the terms of a pending negotiation with another counterparty.

Referring back toFIG. 7, in step714, application server118may identify a successful negotiation between the trader and at least one of the multiple counterparties (e.g., the members of Lenders Group A). For example, as described above, the negotiations between the trader and counterparty State Street may result in an agreement on terms for a transaction that enables the trader to borrow shares of Tesla from State Street. Application server118may then provide information in step716to client system102, which may update a Negotiations sidebar within a graphical user interface (e.g., Negotiations sidebar820ofFIG. 8C) to reflect a success of the negotiation between the trader and State Street and the final negotiated terms.

In step718, application server118may determine whether negotiations continue with any of the multiple counterparties subject to the broadcast in step708. For example, as described above, application server118may broadcast the initial negotiation terms in step708to each member of Lenders Group A (i.e., State Street, BNY Mellon, and Northern Trust). In such embodiments, the trader may reach an agreement with counterparty State Street to borrow shares of Tesla, while continuing to negotiate with BNY Mellon and/or Northern Trust to borrow additional shares of Tesla stock.

If application server118determines that no additional negotiations involving with the multiple counterparties are pending in step718, then application server generates information identifying the agreed-upon transaction terms in step720. For example, the trader may have come to an agreement with counterparty State Street to borrow shares of Tesla, and additionally, counterparties BNY Mellon and Northern trust may have previously terminated negotiations without agreement. In such embodiments, application server118may generate information identifying the agreed-upon transaction terms between the trader and counterparty State Street in step720. Exemplary method700is then complete in step722, and the generated information may be passed back to step324of exemplary method300ofFIG. 3, which provides an update indicating a success of the negotiation with the State Street to the graphical user interface displayed to the trader, as depicted inFIGS. 6E-6F

Alternatively, if application server118determines that negotiations are ongoing with other counterparties in step718, application server118may provide the trader with an opportunity to terminate all ongoing negotiations, or alternatively, a subset of the ongoing negotiations, in favor of the successful negotiation in step724. For example, as described above in reference toFIG. 8E, the trader may conclude negotiations with counterparty State Street to borrow the desired 100,000 shares of Tesla by clicking on “Accept” icon848ofFIG. 8E. In step720, application server118may provide an additional interface within which the trader may confirm an intention to execute the negotiated transaction with State Street, and terminate the additional negotiations initiated by the broadcast in step708.

If the trader elects to terminate the additional negotiations in step724, then application server may conclude negotiations with the remaining counterparties in step726. For example, the trader may have accumulated the desired position in Tesla stock through the transaction with State Street, and additional negotiations with counterparties BNY Mellon and Northern Trust may be unnecessary. In such embodiments, application server118may terminate the negotiations with counterparties BNY Mellon and Northern Trust in step726in favor of the concluded negotiation with counterparty State Street.

Method700then passes back to step720, in which application server118may generate and output information identifying the terms of the concluded negotiation with State Street, and information identifying the terminated negotiations with BNY Mellon and Northern Trust. Exemplary method700is then complete in step722, and the generated information may be passed back to step324of exemplary method300ofFIG. 3, which provides an update identifying the successful negotiation and the terminated negotiations to the graphical user interface displayed to the trader at client system102.

For example, the update may reorganize entries within a Negotiations sidebar of the graphical user interface (e.g., sidebar820ofFIG. 8C) such that an entry corresponding to the successful negotiation is identified and disposed under a tab corresponding to completed negotiations (e.g., the “Completed” tab within tabs822ofFIG. 8C), and entries corresponding to the unsuccessful negotiations are disposed under a tab corresponding to terminated negotiations (e.g., the “Killed” tab within tabs822ofFIG. 8C). Further, as described above, a “Ticker” sidebar within the graphical user interface (e.g., sidebar812of GUI400inFIG. 4) may be updated to reflect the terms of the executed transaction, either immediately upon execution by application server118or subsequent to a predetermined delay.

Referring back toFIG. 7, if the trader elects to continue the negotiations with the remaining counterparties in step724, then application server118may continue to facilitate negotiations between the trader and the remaining counterparties in step728. In such embodiments, the processes by which the trader and each of the multiple counterparties exchange corresponding offers and counters may continue, as described above, until the trader and corresponding counterparties come to an agreement on negotiated terms for a transaction, or alternatively, elect to terminate negotiations.

For example, as described above, the trader may conclude negotiations with counterparty State Street to borrow only a portion of the desired shares of Tesla stock. In such embodiments, the trader may elect to continue negotiations with counterparties Northern Trust and BNY Mellon in order to borrow additional shares of Tesla stock and accumulate the desired position.

In the embodiment ofFIG. 7, trading platform110enables a trader to simultaneously initiate, conduct, and conclude negotiations to lend or borrow quantities of financial instruments from multiple counterparties. As described above, the multiple counterparties may be members of a trading group associated with the trader, e.g., Lenders Group A of GUI400described above. The disclosed embodiments are not limited to such exemplary sets of multiple counterparties, and in additional embodiments, the multiple counterparties described reference toFIG. 7may include any arbitrary set of counterparties identified by the trader prior to initiation of negotiation (e.g., an “ad hoc” trading group), any set of multiple trading groups (e.g., a combination of the members of Lenders Group A and Lenders Group B of GUI400), or alternatively, any subset of those counterparties associated with trading platform110.

Further, the embodiments ofFIG. 7enable the trader to conduct simultaneous and confidential negotiations with each of the multiple counterparties. For example, the processes ofFIG. 7enable the trader to conduct three separate negotiations with corresponding members of Lenders Group A, as identified within GUI400ofFIG. 4. In such embodiments, although the trader is simultaneously conducting negotiating with counterparties State Street, Northern Trust, and BNY Mellon, none of the multiple counterparties are aware of the negotiation terms offered to any of the other counterparties. Thus, using the exemplary processes ofFIG. 7, counterparty BNY Mellon may be completely unaware during the negotiation process that counterparty State Street negotiated terms for a securities lending transaction that are more advantageous than terms for a similar transaction negotiated by BNY Mellon.

Additionally, and as described above, the exemplary processes ofFIGS. 5 and 7enable a trader to negotiate securities lending transaction with one or more counterparties in a manner that treats an identity of the trader, and additionally or alternatively, an identity of the one or more counterparties, as an essential term in the negotiation process. For example, the exemplary processes described above provide the trader with an ability to remain completely anonymous throughout a negotiation process with a counterparty, to provide identifying information at an initiation of a negotiation process with the counterparty, or alternatively, to selectively provide identifying information to the counterparty at various stages of the negotiation process.

For example, the information identifying the trader may include a name of the trader, a name of the trader's firm, or alternatively, a user name assigned to the trader by trading platform110. The information is not limited to such exemplary means of identification, and in additional embodiments, the information identifying the trader may include, but is not limited to, a type of organization with which the trader is associated, an ownership status of a subject security (e.g., whether the trader is an owner, beneficial owner, etc.), a role of the trader in the transaction (e.g., a middleman), a geographic location of the trader, a trading history of the trader (e.g., a number and/or value of trades involving the trader at trading platform110), a history of defaults by the trader or the trader's firm, and social networking information associated with the trader (e.g., a number of trading partners).

In such embodiments, the trader may provide the counterparty with identifying information having varying degrees of specificity at corresponding points within the negotiation process. For example, upon initiation of negotiations, the trader may elect to remain completely anonymous and provide no identifying information to the counterparty. If the trader is associated with a sufficiently high system ranking (e.g., a star in order book600ofFIG. 6A), then the counterparty may be willing to conduct negotiations with the anonymous trader.

However, absent such a high system ranking, the trader may be required at some point within the negotiation process to provide additional identifying information to the counterparty. For example, in response to a request from the counterparty to provide identifying information, the trader may initially provide information of limited specificity, including, but not limited to information identifying a trading history within trading platform110, and additionally or alternatively, a lack of defaults on trading platform110, in order to advance the negotiations. In such embodiments, the counterparty may continue to request additional identifying information of greater specificity, including, but not limited to, the name of the trader's firm or the name of the trader, as a price for continuing negotiations, or alternatively, agreeing to negotiated terms that are acceptable to the trader.

Further, as described above, the trading platform110may enable traders (e.g., prime brokers and agent lenders operating at one or more of client systems102and104) to post non-firm orders to borrow shares of a security from counterparties (i.e., bids to borrow) or to post non-firm orders to lend shares of a security to counterparties (i.e., offers to lend). Trading platform110may store information associated with the posted orders within a data repository (e.g., data repository116ofFIG. 1) to form an order book for the corresponding security, which may be provided to a trader upon demand through a graphical user interface.

In an embodiment, the disclosed trading platform may also enable the trader to post an order to an order book with varying levels of anonymity. For example, trading platform110may enable a trader associated with a particular posting in an order book to remain completely anonymous to all other traders (e.g., order604B within order book600ofFIG. 6), or alternatively, to reveal an identity of the trader's firm to all traders without restriction (e.g., order604A within order book600ofFIG. 6).

Further, in additional embodiments, trading platform110may enable the trader to selectively reveal identifying information when posting orders to an order book. For example, trading platform110may reveal an identity of a firm associated with a posted order to only those traders associated with a specified trading group, and additionally or alternatively, within a specific group of firms identified by the trader that posted the order. For example, a posted order may reveal an identity of a trader at State Street to not only other members of Lenders Group A (e.g., BNY Mellon and Northern Trust), but also to other trading firms, e.g., JPMorgan Chase & Co., with whom the trader is attempting to build a working relationship.

In such embodiments, the exemplary processes described above may be leveraged to conduct negotiations for a securities lending transaction in which a trader and/or a counterparty remain completely or partially anonymous to each other. In such an embodiment, a trader may lift an anonymous order from a displayed order book (e.g., order604B within order book600ofFIG. 6A) and provide initial negotiations terms to trading platform110that initiate negotiations with the anonymous counterparty. Within such initial negotiation terms, the trader may elect to remain anonymous (e.g., by not selecting “Reveal ID” icon616within negotiations window610ofFIG. 6B), or alternatively, the trader may elect to provide identifying information to the anonymous counterparty (e.g., by selecting “Reveal ID” icon616within negotiations window610ofFIG. 6B).

Further, in an embodiment, trading platform110may provide appropriate interfaces (e.g., negotiations window610ofFIG. 6B) to the trader and the anonymous counterparty to enable the trader and the anonymous counterparty to directly communicate and negotiate terms for a transaction to borrow or lend a particular security. Through such interfaces, trading platform110may enable the trader to request information identifying the anonymous counterparty, and additionally or alternatively, may enable the anonymous counterparty to request information identifying the trader, at any step within the negotiation process.

For example, an anonymous counterparty associated with a relatively low system ranking may post a bid to borrow securities to trading platform110, and an anonymous trader may lift the posted bid to initiate negotiations for the desired transaction through trading platform110. In such an embodiment, at an intermediate stage of the negotiation, the anonymous trader may request through trading platform110that the anonymous counterparty provide identifying information (e.g., a name of a corresponding firm) in order to obtain a reduced transaction fee or to establish a relationship with the counterparty.

As discussed above, trading platform110may enable the anonymous counterparty to agree to the anonymous trader's request to identify a firm, and to continue negotiations with the now-identified counterparty (e.g., through a one-way reveal). Further, as discussed above, the anonymous counterparty may elect to terminate negotiations upon receipt of the request for identification, or alternatively, submit a counteroffer to trading platform110that provides an alternate form of identification (e.g., a trading history), or provides additional transaction terms in an attempt to advance negotiations without revealing the counterparty's identity.

Trading platform110may also enable a trader to conduct simultaneous confidential negotiations with multiple counterparties. For example, the electronic trading platform may facilitate a separate negotiation with each of the multiple counterparties, and as such, the trader may elect to conduct negotiations with a subset of the multiple counterparties anonymously. For example, in such embodiments, trading platform110may enable the trader to conduct anonymous negotiations with one member of a trading group, while simultaneously and confidentially revealing identifying information during negotiations with the remaining members of the trading group.

In such embodiments, trading platform110may facilitate negotiations which an identity of the trader, and additionally or alternatively, an identity of a counterparty, may be revealed at any stage of the negotiation process. Thus, trading platform110may facilitate the negotiation of wholly anonymous transactions in which both the trader and the counterparty remain anonymous, or alternatively, the negotiation of one-way transactions in which either the trader or the counterparty reveal identifying information in order to advance negotiations or obtain more favorable terms for a resulting transaction.

In the embodiments described above, an electronic trading platform may enable a trader to initiate negotiations for a securities lending transaction with a counterparty, e.g., a trading firm, by lifting a posted order displayed in corresponding order book for a financial instrument, or alternatively, by directing a trade to a multiple counterparty firms associated with the trader, e.g., a trading group. The disclosed embodiments are not limited to such exemplary counterparties, and in additional embodiments, the electronic trading platform may enable a trader to directly negotiate terms of a securities lending transaction with an individual counterparty, e.g., a trading partner, with whom the trader has established a personal or professional relationship through mutual agreement.

As described above, an availability of a stock or security may depend on a number of factors, such as a “special” status of the stock or an especially high demand for that stock (e.g., subsequent to an initial public offering (IPO)). For example, a trader may search for an order book of stock of Sears Holding Corp. and may subsequently determine that a supply of Sears stock within the system is especially low due to its “special” status. In such embodiments, the trader may leverage an electronic trading platform (e.g., trading platform110ofFIG. 1) to negotiate with an established trading partner to obtain the needed securities, as described below in reference toFIG. 9.

FIG. 9is a flowchart of an exemplary method900for electronically negotiating terms of a securities lending transaction between a trader and an established trading partner, according to disclosed embodiments. Method900may provide functionality that enables a server of an electronic trading platform (e.g., application server118of trading platform110inFIG. 1) to facilitate direct negotiations between a trader and an established trading partner for a transaction to lend or borrow shares of a security. In such embodiments, method900may be incorporated into the exemplary processes of step322ofFIG. 3, which enable application server118to facilitate direct negotiations between the trader and the one or more counterparties. Further, as will be apparent to one of skill in the art from the present disclosure, the steps and arrangement of the same inFIG. 9may be modified, as needed.

For example, application server118may provide a graphical user interface to a client system associated with a trader (e.g., client system102ofFIG. 1), and client system102may process the received information to display the graphical user interface to the trader. As described above, the graphical user interface may include a sidebar that displays information identifying existing trading partners associated with the trader and information on pending requests to establish counterparties as trading partners, as described below in reference toFIG. 10A.

FIG. 10Aillustrates an exemplary sidebar1000that displays information associated with trading partners of a trader, in accordance with disclosed embodiments. As described above, sidebar100may be incorporated within a portion of a graphical user interface (e.g., “Trading Partner” sidebar408within GUI400ofFIG. 4).

Sidebar1000includes a region1002that displays statistics regarding the trading partners associated with the trader. For example, as depicted inFIG. 10A, such statistics may include, but are not limited to, a number of existing trading partners, a number of outstanding requests to establish new trading partners, and a subset of the existing trading partners that are currently online and available for negotiations. In the embodiment ofFIG. 10A, the trader is associated with eleven trading partners, eight of which are currently online and available for negotiations.

Further, in the embodiment ofFIG. 10A, sidebar1000may provide a text box1004that enables the trader to enter a query and identify existing trading partners, and additionally or alternatively, potential trading partners. Sidebar100may include information1006identifying at least a subset of the existing trader partners. For example, information1006may be include, but not limited to, avatars or images of the trading partners that indicate a level of activity and availability of the corresponding trading partner to negotiate within trading platform110. In such embodiments, a green border surrounding an avatar of a trading partner may indicate that the trading partner is online and currently active, while an orange border may indicate that the trading partner is online, but inactive. Thus, in sidebar1000, the avatar for “DB trader” may be surrounded by a green border, and as such, “DB trader” is logged into and active within trading platform110. Similarly, an orange border may surround “MS trader” in sidebar1000indicates that “MS trader” may be logged into trading platform110, but is currently inactive.

The disclosed embodiments are, however, not limited to such indicia of trading partner activity and in further embodiments, a thickness of a border, a style of the border (e.g., dashed or broken), and any additional or alternate visual indicator may identify a level of activity of the corresponding trading partner. For example, a dashed border surrounding an avatar of a trading partner may indicate that the trading partner is online and currently active (e.g., “DB Trader”), while an solid border may indicate that the trading partner is online, but inactive (e.g., “MS trader”). Further, in additional embodiments, the level of activity and the availability of a trading partner may be indicated by a colored circle surrounding the corresponding avatar displayed in sidebar1000(e.g., a green circle indicates the trading partner is online and currently active, and an orange circle indicates the trading partner is online, but inactive).

In such embodiments, the trader may click on or otherwise select an avatar associated with an online and available trading partner1008, e.g., “DBTrader,” and client system102may transmit a request to initiate negotiations with “DBTrader” across network120to trading platform110. As discussed above, client system102may request may include information identifying the selected trading partner (i.e., DBTrader), and the request may be transmitted to a web server associated with trading platform110(e.g., web server112ofFIG. 1) using any of the communications protocols outlined above.

Furthermore, while the trader may receive a timely response from an online and available trading partner, the disclosed embodiments may enable the trader to click on an avatar of an online, but inactive, trading partner in order to transmit a request to initiate negotiations with the inactive trading partner. In such embodiments, the request may be stored with an inbox or message queue associated with the inactive trading partner (e.g., within a messaging page associated with Messaging icon404A of GUI400) for subsequent retrieval and action.

Referring back toFIG. 9, application server118may receive the information identifying the selected trading partner in step902, and may subsequently initiate negotiations between the trader and the selected trading partner in step904by providing a corresponding interface, e.g., a negotiations window, to client system102over network120. In such embodiments, client system102may display the negotiations window to the trader within a corresponding portion of a graphical user interface, as described below in reference toFIG. 10B.

FIG. 10Billustrates an exemplary negotiations window1010that enables a trader to conduct direct negotiations with a trading partner, in accordance with disclosed embodiments. For example, as described above in reference toFIG. 10A, the trader may select existing trading partner1008, e.g., “DBTrader,” as a counterparty for negotiations for shares of a special stock, e.g., Sears Holdings Corp., and application server118provides negotiations window1010to facilitate the trader's entry of an initial set of terms for the negotiation with DBTrader.

InFIG. 10B, negotiations window1010includes an address region1012, which application server118may automatically populate with DBTrader's address information. In additional embodiments, the trader may be able to add additional counterparties within address region1012, and the initial negotiation terms may be broadcast to each of the counterparties identified in address region1012. Application server118may then establish separate and confidential negotiations with each party, as described above in reference toFIG. 7.

Negotiations window1010may also enable the trader to provide a message to DBTrader within message field1013. For example, as a personal or business relationship may exist between the trader and trading partner DBTrader, the trader may enter a personalized, informal text message to DBTrader in message field1013(e.g., “Hi Jim, looking for Sears, can u help?”). The disclosed embodiments are not limited to such exemplary messages, and in further embodiments, the trader may enter any additional or alternate message appropriate to trading platform110(e.g., within specified character limits).

The trader may specify initial terms for a transaction involving the trading partner “DBTrader” within fields1014of window1010. For example, fields1014includes a direction field (e.g., “Dir”) that enables the trader to specify a direction of the transaction (e.g., borrow “B” or lend “L”), a “Type” field that enables the trader to specify a type of transaction fee (e.g., fee-based “F” or rebate-based “R”), a collateral field (e.g., “Coll”) that enables the trader to specify a type of collateral (e.g., cash “C” or non-cash “N”), and a “Term” field that enables the trader to specify a temporal term for the transaction. Further, fields1014also include a “Stock” field that enables the trader to identify a particular security of interest, a “Quantity” field that enables the trader to specify a desired quantity of the security, a “Value” field that automatically calculates a value of the proposed quantity of the security (e.g., based on a prior day's closing value), and a “Fee” field that optionally allows the trader to specify a fee or rebate associated with the proposed transaction. Further, and as described above, a “Reveal Id” field1016in negotiations window1010confirms the trader's intention to disclose identifying information to trading partner “DBTrader.”

For example, inFIG. 10B, the trader requests assistance from “DBTrader” in borrowing 150,000 shares of Sears Holding Corp. (“SHLD”) having a value of $11,503,500 US for an indefinite term in exchange for a fee of 18% and cash collateral. In such embodiments, the value of the 150,000 shares of Sears Holding Corp. may be computed based on the prior day's close, and further, while the trader proposes a fee of 18% for the transaction, the proposed fee is not an essential element in negotiation processes. In additional embodiments, application server118may allow the trader to leave the “Fee” field blank, thereby enabling counterparty “DBTrader” to quote a transaction fee at which he is willing to execute the transaction.

Upon entry of the initial terms for the negotiation within fields1014, the trader may click or otherwise select a “Send” icon1018. In response to the trader's selection of “Send” icon1018, client system102may transmit the initial transaction terms and information identifying the trader across network120to a web server of trading platform110(e.g., web server112ofFIG. 1).

Referring back toFIG. 9, in step906, application server118may receive the initial negotiation terms and the personalized message from the trader, and application server118may then broadcast the initial negotiation terms and the personalized message to the identified trading partner, e.g., “DBTrader,” in step908. Application server118may then generate information updating the graphical user interface displayed to the trader to reflect the pending negotiations with “DBTrader,” and the information may be provided to client system102in step910. For example, as described above, web server112may transmit the information across network120to client system102, which subsequently renders and displays the updated graphical user interface to the trader, as described below in reference toFIG. 10C.

FIG. 10Cillustrates an exemplary portion of an updated graphical user interface1020, which may be displayed to a trader in accordance with disclosed embodiments. For example, interface1020may represent an update to a graphical user interface initially displayed to the trader by trading platform110(e.g., GUI400ofFIG. 4) and may include additional information identifying the pending negotiations for shares of Sears Holding Corp. between the trader and trading partner “DBTrader.”

For example, upon initiating negotiations with “DBTrader,” application server118may update a messaging page1022of interface1020(e.g., associated with Messages icon404A ofFIG. 4) to include information1024identifying the personal message transmitted to “DBTrader” and the initial negotiation parameters. For example, information1024may include an avatar or image associated with the trader, information identifying the sender and recipient of the message, a time of transmission, the personalized message to “DBTrader” (e.g., as specified within field1013of negotiations window1010), and information identifying elements of the initial negotiation parameters provided to “DBTrader.” The disclosed embodiments are, however, not limited to such descriptive information, and in additional embodiments, message information1024may include any additional or alternate information that would be apparent to one of skill in the art and of interest to the trader.

Further, application server may also update a sidebar1026to include information1028identifying the ongoing negotiation between the trader and trading partner “DBTrader.” For example, information1028may include, but is not limited to, information identifying a stock symbol of Sears Holding Corp. (“SHLD”), a direction of the associated negotiation (e.g., borrow “B”), a value of the requested shares, a fee associated with the transaction, information (“Rev”) indicating whether the trader revealed an identity, information identifying the counterparty (e.g., “DBTrader”), and a status icon indicating an ongoing nature of the negotiation.

In such embodiments, application server118may continuously provide updates to interface1020in response to a change in status in the negotiation between the trader and trading partner “DBTrader.” For example, as described below, application server may provide an additional update to interface1020when “DBTrader” provides a response to the initial negotiation terms, when the trader provides a response to a counteroffer of “DBTrader,” or when the trader and trading partner “DBTrader” agree on a set of terms.

Referring back toFIG. 9, application server118may receive a response to the initial negotiation terms from the identified trading partner (i.e., “DBTrader”) in step912. Application server118may generate information updating the graphical user interface to reflect the response received from “DBTrader,” and the update may be provided to client system102in step914. For example, as described above, web server112, the trader, and “DBTrader” may exchange responses and updates across network120to web server112using any of the communications protocols outlined above.

The response provided by “DBTrader” may indicate an agreement with the initial negotiation terms specified by the trader, a decision to terminate negotiation with the trader, or alternatively, a counter that modifies one or more of the initial negotiation terms. In such embodiments, application server118may determine in step916whether “DBTrader” agrees to the initial negotiation terms provided by the trader.

If application server118determines in step916that “DBTrader” agrees to the initial negotiation terms, then application server118may generate and output information identifying the agreed-upon transaction terms in step918. Exemplary method900then passes to step920, and the negotiation process is complete between the trader and trading partner “DBTrader.” In such an embodiment, the agreed-upon transaction terms may be passed back to step324of exemplary method300ofFIG. 3, which provides an update indicating a success of the negotiation with the “DBTrader” to the graphical user interface displayed to the trader at client system102, as depicted inFIG. 10D.

FIG. 10Dillustrates an additional portion of an updated graphical user interface1020, which may be displayed to a trader in accordance with disclosed embodiments. For example, interface1020may include an update that reflects the response received from trading partner “DBTrader” to the initial negotiation terms, and upon agreement with the initial transaction terms, the execution of the transaction to borrow shares of Sears Holding Corp. in accordance with the initial negotiation parameters.

For example, application server118may update a messaging page1022of interface1020(e.g., associated with Messages icon404A ofFIG. 4) to include information1042identifying the personal message transmitted from “DBTrader” to the trader in response to the initial negotiation terms. For example, information1042may include an avatar or image associated with “DBTrader,” information identifying the sender and recipient of the message, a time of transmission, the personalized message from “DBTrader” indicating agreement with the initial negotiation parameters (e.g., “Sure, thanks for the business”), and information identifying elements of the agree-upon negotiation terms. The disclosed embodiments are, however, not limited to such descriptive information, and in additional embodiments, message information1042may include any additional or alternate information that would be apparent to one of skill in the art and of interest to the trader.

Further, application server may also update entry1028within sidebar1026to indicate a successful completion of the negotiation between the trader and trading partner “DBTrader.” For example, updated information1028may include, but is not limited to, information identifying a stock symbol of Search Holding Corp. (“SHLD”), a direction of the associated negotiation (e.g., borrow “B”), a value of the requested shares, the agree-upon fee associated with the transaction, information (“Rev”) indicating whether the trader revealed an identity, information identifying the counterparty (e.g., “DBTrader”), and an updated status icon indicating the successful completion of the negotiation. Further, in an embodiment, sidebar1026may be reorganized such that entry1028is placed under a “Completed” tab indicative of the successful negotiation.

Further, as described above, application server118may execute the transaction to borrow shares of Sears Holding Corp. in accordance with the agreed-upon terms of the negotiation, i.e., the initial negotiation terms. In such an embodiment, updated interface1020may also include an updated Ticker sidebar1044, which includes an entry1046associated with the executed transaction. In such an embodiment, entry1046may include, but is not limited to, a time of execution, information identifying a stock symbol of Search Holding Corp. (“SHLD”), a number of shares subject to the executed transaction, a value of the shares, the fee associated with the executed transaction. Further, as described above, Ticker sidebar1044may be updated to include entry1046immediately upon execution, or after a predetermined delay subsequent the execution of the trade.

Referring back toFIG. 9, if the trading partner (i.e., “DBTrader”) fails to agree to the initial negotiation parameters in step916, then application server118determines in step922whether the response provided by “DBTrader” includes a counter that modifies one or more of the initial transaction terms. If application server118determines in step922that the response does not include a counter, then “DBTrader” elected to terminate negotiations, application server118concludes negotiations between the trader and “DBTrader” in step924. Method900then passes back to step920, and the negotiation process between the trader and trading partner “DBTrader” are complete. In an embodiment, the generated indication may be passed back to step324of exemplary method300ofFIG. 3, which provides an update indicating a failure of the negotiations with “DBTrader” to the graphical user interface displayed to the trader by client system102.

For example, a message associated with a decision by the trading partner to terminate negotiations may be displayed to the trader within a corresponding Messaging page of the graphical user interface (e.g., Messaging page1022within interface1020ofFIG. 10D). Further, within a Negotiations sidebar (e.g., sidebar1026ofFIG. 10D), an entry associated with the failed negotiation (e.g., entry1028) may be updated to include a status icon indicative of the failed negotiation, and the corresponding entry may be placed under a “Killed” tab indicative of the failed negotiation.

If, however, application server118determines in step922that the response from “DBTrader” includes a counter, application server118may provide an update to the graphical user interlace that reflects the revised transaction terms of the counter in step926. Application server118may then await a response from the trader to the counter, which may be received by application server118in step928.

For example, application server118may have updated a graphical user interface displayed to the trader (e.g., within Messaging page1022and Negotiations sidebar1026, as described above), and the trader may have selected a corresponding message within Messaging page1002to view and provide a response to the counter. In such embodiments, the trader may either accept the revised terms associated with the counter, elect to terminate negotiations with “DBTrader” in response to the counter, or alternatively, provide an additional counter to the revised terms provided by “DBTrader” (e.g., using negotiations window1010, as described above).

Upon receipt of the trader's response to the counter in step928, application server118may update portions of a graphical user interface (e.g., messaging page1022and sidebar1026of interface1020) in step930to reflect the trader's response. Application server118may then determine, based on the response received from the trader, whether the trader agrees to counter in step932.

If the trader agrees to the counter, then application server118may generate and output information identifying the agreed-upon transaction terms (i.e., the terms specified in the counter provided by “DBTrader”) in step934. Exemplary method900then passes back to step920, and the negotiation process between the trader and trading partner “DBTrader” is complete. In such embodiments, the agreed-upon transaction terms may be passed back to step324of exemplary method300ofFIG. 3, which provides an update indicating a success of the negotiation with DBTrader to the graphical user interface displayed by client system102(e.g., within Negotiations sidebar1026and Ticker sidebar1044ofFIG. 10D, as described above).

If, however, the trader does not agree to the terms set forth in the counter, then application server118determines in step936whether the trader's response indicates a termination of negotiations with “DBTrader.” If the trader elects to terminate negotiations in step936, then application server118may conclude negotiation between the trader and “DBTrader” in step938. Method900then passes back to step920, and the negotiation process between the trader and trading partner “DBTrader” is complete. In an embodiment, an indication of the terminated negotiations may be passed back to step324of exemplary method300ofFIG. 3, which provides an update indicating a failure of the negotiation with the counterparty to the graphical user interface displayed by client system102(e.g., within messaging page1022and negotiations sidebar1026of updated interface1020, as described above).

Alternatively, if the trader elects to continue negotiations in step936, the response received from the trader in step928includes a modification to one or more of the terms set forth in the counter (i.e., the trader responded with an additional counter). Application server118then broadcasts the revised negotiation terms to trading partner “DBTrader” in step940. For example, the revised terms may be provided to trading partner “DBTrader” within a message transmitted across network120by web server112using any of the communications protocols outlined above.

Method900then passes back to step912, and application server118awaits a response from the trading partner to the counter provided by the trader in step928, and application server118may continue to facilitate negotiations between the trader and the trading partner, as described above. In such embodiments, the negotiations between the trader and trading partner “DBTrader” may continue with a series of proposals and counterproposals until agreement is reached, or alternatively, until either the trader or trading partner “DBTrader” elects to terminate the negotiation process.

In the embodiments described above, a trader is able to select a single trading partner and conduct negotiations with that trading partner to lend or borrow securities without any reference to a posted order within a corresponding order book for the financial instruments. The disclosed embodiments are, however, not limited to negotiations with a single trading partner. In an additional embodiments, the trader may leverage a negotiations window (e.g., negotiations window1010ofFIG. 10B) to identify additional trading partners, additional counterparties, and further, additional trading groups or subsets thereof, to which application server118broadcasts the initial negotiation terms. In such embodiments, trading platform110may enable the trader to participate in multiple confidential negotiation sessions with each of the identified counterparties, as described above.

FIG. 11is a flowchart of an exemplary method1100for electronically establishing a trading partnership between two counterparties, according to disclosed embodiments. Method1100may provide functionality that enables a server of an electronic trading platform (e.g., application server118of trading platform110inFIG. 1) to receive a request to establish a trading partnership between a trader and a counterparty, to forward the request to the counterparty, and upon acceptance of the request, establish the counterparty as a trading partner.

InFIG. 11, application server118may receive a request from a trader to establish an identified counterparty as a trading partner in step1102. For example, the counterparty may represent a colleague at a friendly firm with whom the trader has established a professional or personal relationship. Further, the trader may have knowledge of and confidence in the counterparty sufficient to regularly conduct securities lending borrowing transactions with counterparty.

In an embodiment, application server118may receive the request from a client system associated with the trader (e.g., client system102ofFIG. 1), which may display a graphical user interface to the trader. For example, the trader may search for the counterparty (e.g., within text box408B of a “Trading Partners” sidebar408inFIG. 4), and may initiate a transmission of the request through the displayed graphical user interface. In response to the initiation, client system102may transmit the request and information to application server118of trading platform110across network120using any of the communications protocols outlined above.

Upon receipt of the request, application server118may provide the received request to the counterparty in step1104. In an embodiment, application server118may provide the request through a messaging functionality provided by a graphical user interface of trading platform110(e.g., through an interface associated with Messaging icon404A of GUI400). Additionally or alternatively, application server118may provide the request to the counterparty via email, text mail, or using any additional or alternate techniques apparent to one of skill in the art.

Application server118may subsequently receive a response from the counterparty in step1106. In an embodiment, the received response may include information indicating the counterparty's agreement to the proposed trading partnership, or alternatively, information indicating the counterparty's determination to decline the trading partnership. In additional embodiments, the counterparty's response may include a personalized message for the trader, which may be provided to the trader by application server118.

In step1108, application server118may determine whether the counterparty accepts the trader's offer of a trading partnership. If the counterparty declines to become a trading partner, then application server118may generate a message indicating the counterparty's decision, which may be provided to the trader in step1110. In an embodiment, the message may be provided to the trader through a messaging functionality provided by a graphical user interface (e.g., through a messaging page associated with Messaging icon404A of GUI400). Additionally or alternatively, application server118may provide the information to the trader via email, text mail, or using any additional or alternate techniques apparent to one of skill in the art. Exemplary method1100is then complete in step1112.

If application server118determines in step1108that the counterparty accepted the trader's invitation to become a trading partner, then in step1114, application server118may add the counterparty and information identifying the counterparty (e.g., an image or avatar and a corresponding name) to the a corresponding portion of the graphical user interface (e.g., within “Trading Partners” sidebar408within GUI400ofFIG. 4), which may be provided to client system102for display to the trader. Further, in an embodiment, while the new trading partner may be known to the trader, application server118may maintain a level of confidentiality so that the new trading partner has no knowledge of any other established trading partner associated with the trader. Application server118may also store the information identifying the new trading partner within a corresponding portion of a data repository (e.g., data repository116ofFIG. 1). Exemplary method1100is complete in step1112.

In the embodiments described above, an electronic trading platform (e.g., trading platform110ofFIG. 1) facilitates an online negotiation process in which a trader and one or more counterparties agree to terms for a transaction to lend or borrow one or more securities, which may be executed and subsequently submitted to a central clearing party (e.g., CCP130ofFIG. 1) for clearing and settlement. The trader and the counterparty may, however, discuss and subsequently agree upon terms for a transaction to lend or borrow the securities outside of the electronic environment of trading platform110. In such embodiments, the trader and the counterparty may access trading platform110to execute such transactions, i.e., “locked trades,” in accordance with the prior agreed-upon terms, which may be fed into CCP130for clearing and settlement, as described below in reference toFIG. 12.

FIG. 12is a flowchart of an exemplary method1200for electronically executing and settling a locked transaction, according to disclosed embodiments. Method1200may provide functionality that enables a server of an electronic trading platform (e.g., application server118of trading platform110inFIG. 1) to receive a set of terms to which a trader and counterparty previously agreed, and subsequently execute a locked transaction in accordance with the agreed-upon terms. As will be apparent to one of skill in the art from the present disclosure, the steps and arrangement of the same inFIG. 12may be modified, as needed.

In step1202, application server118may receive a request from a trader to confirm and execute a locked transaction with a counterparty. A “locked transaction” or “locked trade” refers to a transaction whose terms are established offline and away from trading platform110in accordance with an agreement between the trader and the counterparty. In such an embodiment, the trader and counterparties may wish to access the clearing and settlement functionalities available to trading platform110, without accessing the negotiation functions described above. In contrast to the embodiments outlined above, the confirmation and subsequent execution of the “locked trade” enables the trader and counterparty to merely assent to the fixed terms without any substantive negotiation.

For example, in an embodiment, the trader may access trading platform110using the processes described above, and upon authentication, may be provided a graphical user interface (e.g., graphical user interface400ofFIG. 4). In such embodiments, the trader may access a portion of a messaging page associated with the graphical user interface (e.g., messaging page1022ofFIG. 10C), and may click or otherwise select a corresponding icon to request confirmation and execution of a locked transaction with a counterparty, which may be transmitted from a corresponding client system (e.g., client system102of FIG.) to application server118. The disclosed embodiments are, however, not limited to such exemplary techniques, and in additional embodiments, the trader may request confirmation and execution of the locked transaction using any other functionality of the graphical user interface, or any additional or alternate techniques apparent to one of skill in the art, including but not limited to email or text messaging a request to trading platform110.

Upon receipt of the request in step1202, application server118may initiate processing of the locked transaction by providing a corresponding interface, e.g., a locked trade window, to client system102over network120in step1204. In such embodiments, client system102may display the locked trade window to the trader within a corresponding portion of a graphical user interface to facilitate entry of the fixed terms associated with the transaction.

For example, as depicted inFIG. 13A, a locked trade window1300includes an address field1302, within which the trader may enter information identifying the counterparty (e.g., “nttrader”), and fields1304that enable the trader to enter the fixed terms of the locked transaction. For example, fields1304includes a direction field (e.g., “Dir”) that enables the trader to specify a direction of the transaction (e.g., borrow “B” or lend “L”), a “Type” field that enables the trader to specify a type of transaction fee (e.g., fee-based “F” or rebate-based “R”), a collateral field (e.g., “Coll”) that enables the trader to specify a type of collateral (e.g., cash “C” or non-cash “N”), and a “Term” field that enables the trader to specify a temporal term for the transaction. Further, fields1304also include a “Stock” field that enables the trader to identify the particular security of interest, a “Quantity” field that enables the trader to specify a desired quantity of shares of the security, a “Value” field that automatically calculates a value of the desired shares (e.g., based on a prior day's closing value), and a “Fee” field that allows the trader to specify a fee or rebate associated with the transaction.

For example, inFIG. 13A, the trader may enter terms identifying a locked transaction to borrow 1,000,000 shares of Zagg Inc., having a value of $10,660,000 US from counterparty “nttrader” in exchange for cash collateral and a transaction fee of 25%. In contrast to the negotiation processes described above, the transaction fee for the locked transaction is an essential term, as trading platform110may only provide counterparty “nttrader” with an opportunity to accept or reject the fixed terms.

The disclosed embodiments are not limited to locked transactions involving shares of a single security, and in additional embodiments, locked trade window1300may enable the trader to specify terms of a locked transaction to lend or borrow shares of multiple securities. For example, locked trade window1300may enable the trader to specify each of the multiple securities within a Stock field, specify a quantity of shares (e.g., within the Quantity field) and corresponding share value (within a Value field) for each of the multiple securities, and enter corresponding transaction terms for each of the multiple securities with the Fee field. In such embodiments, locked trade window1300may enable the trader to confirm and execute terms for a locked transaction to borrow or lend a “basket” of securities.

Upon entry of the fixed terms for the negotiation within fields1304, the trader may check of otherwise select a “Send” icon1306. In response to the trader's selection of Send icon1306, client system102may transmit the fixed transaction terms and information identifying the counterparty and trader across network120to a web server of trading platform110(e.g., web server112).

Referring back toFIG. 12, application server118may receive the terms of the locked transaction and the information identifying the trader and counterparty in step1206, and application server118may provide the fixed terms of the locked transaction to the counterparty (i.e., “nttrader”) in step1208. Application server118may then generate information updating the graphical user interface displayed to the trader to reflect the outstanding locked transaction with “nttrader,” and the information may be provided to client system102in step1210. For example, as described above, web server112may transmit the information across network120to client system102, which subsequently render and display the updated graphical user interface to the trader, as described below in reference toFIG. 13B.

FIG. 13Billustrates an exemplary portion of an updated graphical user interface1320, which may be displayed to a trader in accordance with disclosed embodiments. For example, interface1320may represent an update to the graphical user interface initially displayed to the trader (e.g., GUI400ofFIG. 4), and may include additional information identifying the pending locked transaction for shares of Zagg, Inc., between the trader and counterparty “nttrader.”

For example, upon initiating confirmation of a locked transaction with “nttrader,” application server118may update a messaging page1322of interface1320(e.g., associated with Messages icon404A ofFIG. 4) to include information1324identifying the terms of the fixed transaction provided to counterparty “nttrader.” For example, information1024may include an avatar or image associated with the trader, information identifying the sender and recipient of the message, a time of transmission, and information identifying elements of the fixed transaction terms provided to “nttrader.” In contrast to the negotiation processes described above between, for example, established trading partners, the confirmation of the terms of the locked transaction does not enable the trader to provide a personalized message to “nttrader.”

Further, application server118may also update a sidebar1326to include information1328identifying the locked transaction between the trader and counterparty “nttrader.” For example, information1328may include, but is not limited to, information identifying a stock symbol of Zagg Inc. (“ZAGG”), a direction of the locked transaction (e.g., borrow “B”), a value of the requested shares, a fee associated with the locked transaction, information (“Rev”) indicating whether the trader revealed an identity, information identifying the counterparty (e.g., “nttrader”), and a status icon indicating an pending nature of the locked transaction.

In such embodiments, application server118may continuously provide updates to interface1320in response to a change in status in the locked transaction between the trader and counterparty “nttrader.” For example, as described below, application server may provide an additional update to interface1020when “nttrader” provides a response that accepts or rejects to the fixed transaction terms.

Referring back toFIG. 12, application server118may receive a response from the counterparty (i.e., “nttrader”) to the fixed terms of the locked transaction in step1212. In step1214, application server118may subsequently generate information updating the graphical user interface displayed to the trader to reflect the response received from counterparty “nttrader,” which may be provided to client system102.

In contrast to the negotiation processes outlined above, the response to the locked transaction terms provided by “nttrader” includes either a confirmation of the terms or a rejection of the terms. In such embodiments, application server118may determine in step1216whether the response from “nttrader” indicates confirmation of the fixed terms of the locked transaction.

If application server118determines in step1216that “nttrader” rejects the terms of the locked transaction, then application server118may conclude the confirmation processes in step1218and update the graphical user interface displayed to the trader in step1220to reflect the rejection of the fixed terms. For example, a message associated with decision by “nttrader” to terminate negotiations may be displayed to the trader within a corresponding “Messaging” page of the graphical user interface (e.g., Messaging page1322within interface1320ofFIG. 13B). Further, within a Negotiations sidebar (e.g., sidebar1326ofFIG. 13B), a status icon within an entry corresponding to the failed negotiation (e.g., entry1328) may be updated to reflect the failed negotiation, and the corresponding entry may be placed under a “Killed” tab indicative of the failed negotiation. The processes ofFIG. 13are then complete in step1222.

Alternatively, if application server118determines in step1216that the response of “nttrader” confirms the terms of the locked transaction, then application server118may execute the locked transaction in step1224in accordance with the confirmed terms, and generate transaction receipts or “trade tickets” memorializing the terms for the locked transaction in which the trader borrowed the 1,000,000 shares of Zagg Inc. from counterparty “nttrader.” In step1226, application server118may then distribute the generated trade tickets for the executed locked transaction to the trader and counterparty “nttrader.” For example, the generated trade tickets may be transmitted by web server112to the trader and the corresponding counterparties over network120using one or more of the communications protocols outlined above. Additionally or alternatively, application server122may provide the generated trade tickets to the trader and counterparty within portions of corresponding displayed graphical user interfaces (e.g., under “Messages” icon404A of GUI400).

In step1228, application server118may update the graphical user interface displayed to the trader to reflect the execution of the locked transaction according to the fixed terms. For example, as depicted inFIG. 13C, a message1342associated with the decision by “nttrader” to confirm the terms of the locked transaction may be displayed to the trader within a corresponding Messaging page1322of graphical user interface1320. As depicted within Negotiations sidebar1326ofFIG. 13C, a status icon within entry1328may be updated to reflect the confirmation by “nttrader,” and the corresponding entry may be placed under a “Completed” tab indicative of the confirmation.

Further, application server118may also update an entry1346within Ticker sidebar1344to reflect the execution of the locked transaction between the trader and counterparty “nttrader.” In such an embodiment, entry1346may include, but is not limited to, information indicating a time of execution, information identifying a stock symbol of Zagg Inc. (“ZAGG”), a number of shares subject to the executed transaction, a value of the shares, and the fee associated with the executed transaction. Further, as described above, Ticker sidebar1344may be updated to include entry1346immediately upon execution, or after a predetermined delay subsequent the execution of the locked transaction.

Referring backFIG. 12, in step1230, application server118may submit the terms of the locked transaction to a central clearing counterparty (e.g., CCP130ofFIG. 1) over communications link122for clearance and settlement. In such embodiments, the terms of the executed transaction may be provided to CCP130using file transfer server114, and upon receipt of the terms of the executed transaction, CCP130performs the corresponding clearance functions for the trader and the counterparties based on clearance data and corresponding collateral deposits provided to CCP130, as described above.

CCP130may subsequently transmit information identifying the executed transactions to a settlement agent (e.g., settlement agent140ofFIG. 1) via a corresponding communications link (e.g., communications link124ofFIG. 1). Upon completion of settlement of the executed transaction, settlement agent130may transmit, over communication link124, confirmations of the settlement to CCP130, which may subsequently forward the settlement confirmations to trading platform110across communications link122.

In step1232, application server118may distribute the received settlement confirmations to the trader and counterparty “nttrader” across network120. For example, and as described above, application server118, in conjunction with web server112, may transmit the settlement confirmation to the trader and counterparty “nttrader” over network120using any of the communications protocols outlined above. Further, in step1234, application server118may update corresponding portions of the GUI displayed to the trader and to the one or more counterparties to reflect the settled transactions (e.g., under “Orders” icon404C of GUI400). Method1200then passes back to back to step1222, and the confirmation and execution process is complete.

In the embodiments described above, an electronic trading platform (e.g., trading platform110ofFIG. 1) enables a trader to manually negotiate securities lending transactions involving a single financial instrument and a single counterparty, or alternatively, multiple counterparties, which may be subsequently submitted for clearing and settlement. The disclosed embodiments are, however, not limited to manual processes that enable a trader to directly communicate and negotiate transaction terms with a corresponding counterparty or counterparties. In a further embodiments, trading platform110may facilitate an automated process by which a trader executes multiple securities lending transactions involving corresponding securities with predetermined counterparties and at agreed-upon fees, as described below in reference toFIG. 14.

FIG. 14is a flowchart of an exemplary method1400for automatically executing multiple securities lending transactions, according to disclosed embodiments. Method1400may provide functionality that enables a server of an electronic trading platform (e.g., application server118of trading platform110inFIG. 1) to obtain information specifying terms for a plurality of transactions to lend or borrow securities, and to execute the plurality of transactions with corresponding pre-determined counterparties at fixed, pre-agreed transaction fees or ranges of transaction fees. As will be apparent to one of skill in the art from the present disclosure, the steps and arrangement of the same inFIG. 14may be modified, as needed.

In step1402, application server118may identify one or more automation settings associated with the trader. For example, the automation settings may include, but are not limited to, a prioritized list of counterparties (e.g., lenders in a borrowing transaction and borrowers within a lending transaction) that will trade securities at fixed, pre-agreed fees or ranges of fees. In such embodiments, the prioritized list of borrowers or lenders may be drawn from trading groups associated with the trader and additionally or alternatively, from trading partners associated with the trader.

The automation settings may also include information identifying one or more securities excluded from automated lending and borrowing transactions. For example, the excluded securities may include, but are not limited to, stocks having “special” status and stocks experiencing an especially high demand (e.g., subsequent to an initial public offering (IPO)).

In an embodiment, the automation settings may be stored within a data repository associated with application server118(e.g., data repository116ofFIG. 1), and may be accessed by the trader through an appropriate automation page of a displayed graphical user interface (e.g., through “Automation” icon404E within GUI400ofFIG. 4). For example,FIG. 15Aillustrates an exemplary automation page1500that includes a prioritized list of lenders1502for a borrowing transaction, and a corresponding set of securities1510excluded from the automated borrowing transactions. Further, in the embodiments ofFIG. 15A, the automation settings include selectable icons that enable the trader to disable trading at fixed fees or ranges of fees (e.g., “Disable” icon1504), modify the rank of lenders within list1502(e.g., a “Modify Rank” icon1506), add new lenders to list1502(e.g., a “New Automation” icon1508), disable the exclusion of transactions involving excluded securities1510, and add new stocks or securities to excluded securities1510. Further, although not depicted inFIG. 15A, prioritized lenders list1502may include, for one or more of the lenders, a user-specified or predetermined trading limit that limits an ability of the one or more lenders to automatically execute transaction. In such embodiments, the trading limit may be expressed in terms of a number of executed transactions, a number of shares within such executed transactions, or a value of such executed transactions in an appropriate currency, including, but not limited to, U.S. dollars, British pounds sterling, Euros, Swiss francs, Japanese yen, and any additional or alternate currency appropriate to an exchange associated with trading platform110.

Referring back toFIG. 14, application server118may obtain information identifying a plurality of transactions and corresponding securities in step1404. The obtained information may include, for each transaction, an identifier of the particular security (e.g., a CUSIP code for a shares of a stock) and a quantity of the desired security. Further, in an embodiment, the obtained information may further include, for each transaction, an acceptable type of collateral (e.g., cash or non-cash), a type fee arrangement (e.g., as a percentage of a value of the transaction or a rebate), a duration of the transaction, and any additional or alternate term or parameter appropriate to the transaction.

For example, the trader may navigate to an order management page associated with the graphical user interface (e.g., associated with “Orders” icon404C within GUI400ofFIG. 4). In such an embodiment, as depicted inFIG. 15B, the trader may specify a type of automated transaction by clicking either a “Borrow” icon1522or a “Loan” icon1524within an exemplary order management page1520, and by subsequently selecting “Browse” icon1526, the trader may identify a file that includes the information identifying a particular security and a desired quantity of that security for each of a number of multiple transactions.

For example, as depicted inFIG. 15C, the identified file1530may be a comma-delimited file that includes, for each transaction, an identifier of a security (e.g., a corresponding CUSIP) followed by a desired quantity of shares of that security. The disclosed embodiments are not limited to such exemplary file formats, and in additional embodiments, the identified file may be tab delimited, space delimited, unstructured, or may have any additional or alternate format apparent to one of skill in the art, capable of identifying the stocks and desired quantities, and compatible with application server118and client system102.

In such embodiments, the file including the transaction details may be locally stored within a client system associated with the trader (e.g., client system102ofFIG. 2), or alternatively, within a location accessible to client system102across network120. The trader may subsequently select “Upload” icon1528ofFIG. 15B, and in response to the selection, client system102may transmit the identified file to application server118. As described above, client system102may transmit the identified file to a file transfer server associated with trading platform110(e.g., file transfer server114ofFIG. 1) using any appropriate file transfer protocol (e.g., FTP) or equivalent API interface. Further in additional embodiments, client device102may also transmit the identified file to a web server associated with trading platform110(e.g., web server112ofFIG. 1) using any of the communications protocols outlined above.

Referring back toFIG. 14, in step1406, application server118may coordinate with the counterparties identified in step402to automatically execute the transactions to lend or borrow the specified shares of securities at the fixed, fees or ranges of fixed fees. Further, in such embodiments, and in additional to values of the transaction fees and the share quantities, each of the counterparties may be associated with a set of transaction term values (e.g., types of collateral, transaction fee arrangements, durations) upon which an executed transaction between the trader and the corresponding counterparty may be based.

For example, in step406, application server118may initially filter the information identifying the securities lending transactions to discard those transactions associated with stocks or securities present within the list of excluded stocks or securities identified in step1402. Further, in step1406, application server118may distribute the filtered transactions to the counterparties within the prioritized list for execution. In such embodiments, the counterparties within the prioritized list (e.g., prioritized lenders list1502ofFIG. 15A) may automatically execute the filtered transactions based on a match between the terms of the filtered transactions specified by the trader and corresponding sets of transaction term values associated with the counterparties (e.g., a match between types of collateral, types of transaction fees, durations, and additionally or alternatively, transaction fees).

In an embodiment, the transactions may be distributed to the counterparties in round-robin fashion according to corresponding ranks within the prioritized list. Further, a counterparty may continue to receive distributed transactions for execution until a corresponding user-specified trading limit is reached, or alternatively, a cumulative value of the transactions executed that counterparty exceeds a threshold value, which may be based on, for example, a rank assigned to the counterparty within the prioritized list. The disclosed embodiments are, however, not limited to such exemplary distributions, and in further embodiments, application server118may distribute the transactions to the counterparties for automated execution using any additional or alternate algorithm apparent to one of skill in the art.

In an embodiment, application server118may provide an updated graphical user interface to the trader in step1408that reflects the outcome of the automated execution processes of step1406, as described in reference to an updated graphical user interface1540ofFIG. 15D. For example, in the embodiment ofFIG. 15D, application server118attempted to automatically execute twenty-five securities lending transactions with corresponding counterparties, and successfully executed thirteen of the transactions. In such exemplary embodiments, application server118was unable to execute the remaining twelve transactions (e.g., the prioritized counterparties were unable to provide the desired quantity of securities), and application server118may provide information identifying these residual transactions within portion1542of interface1540.

Application server118may also update a “Negotiations” sidebar1544to include entries1545indicative of the thirteen successfully-executed transactions. In such embodiments, entries1545may include, but are not limited to, information identifying a stock symbol associated with each transaction, a direction of the associated negotiation for each transaction, a value of the requested shares for each transaction, the fixed fee associated with each transaction, information (“Rev”) indicating whether the trader revealed an identity to a counterparty associated with each transaction, information identifying the counterparty for each transaction, and an updated status icon indicating the successful execution of each transaction. Further, in an embodiment, sidebar1544may be reorganized such that entries1545is placed under a “Completed” tab indicative of the successful negotiation. Additionally, entries corresponding to the residual transactions may be disposed under an “Incomplete” tab indicative of the incomplete status of the residual transactions.

Interface1540may also include an updated “Ticker” sidebar1546having entries1547associated with the thirteen executed transaction. In such an embodiment, entries1547may include, but is not limited to, a time of execution, information identifying a stock symbol for each executed transaction, a number of shares subject to each executed transaction, a value of the shares in each executed transaction, and the fixed fee associated with the executed transaction. Further, as described above, “Ticker” sidebar1546may be updated to include entries1547immediately upon execution, or after a predetermined delay subsequent the execution of the trade.

Referring back toFIG. 14, application server118may then generate an output file (e.g., a STP file) that includes a detailed log of the executed transactions in step1410. In an embodiment, the system-generated file, which may be in spreadsheet or any other appropriate format, may include detailed information associated with one or more of the executed transactions. For example, the system-generated file may include, but is not limited to, an identifier of the counterparty, a counterparty name, a CUSIP associated with the security, a name and ticker symbol of the security, a quantity of the security, a transaction fee, a transaction type, and a collateral type associated with each of the executed transactions.

In step1412, application server118may transmit messages to each of the counterparties and to the trader that describe the terms of the executed transactions, which may be accessible within a messaging page of the graphical user interface (e.g., using “Messaging” icon404A of GUI400ofFIG. 4). Further, in step1414, application server118may submit the terms of the executed transactions to a central clearing counterparty (e.g., CCP130ofFIG. 1) over communications link122for clearance and settlement. In such embodiments, the terms of the executed transaction may be provided to CCP130using file transfer server114, and upon receipt of the terms, CCP130performs the clearance functions for the trader and the counterparties based on clearance data and corresponding collateral deposits provided to CCP130, as described above.

CCP130may subsequently transmit information identifying the executed transactions to a settlement agent (e.g., settlement agent140ofFIG. 1) via a corresponding communications link (e.g., communications link124ofFIG. 1). Upon completion of settlement of the executed transaction, settlement agent130may transmit, over communication link124, confirmations of the settlement to CCP130, which may subsequently forward the settlement confirmations to trading platform110across communications link122.

In step1416, application server118may distribute the received settlement confirmations to the trader and counterparties across network120. For example, and as described above, application server118, in conjunction with web server112, may transmit the settlement confirmation to the trader and counterparties over network120using any of the communications protocols outlined above. Further, in step1418, application server118may update corresponding portions of the GUI displayed to the trader and to the one or more counterparties to reflect the settled transactions (e.g., under “Orders” icon404C of GUI400). Method1400then passes to step1420, and the automated transaction process is complete.

In additional embodiments, a trader may access a graphical user interface (e.g., GUI400ofFIG. 4) associated with an electronic trading platform (e.g. trading platform110ofFIG. 1) to manage one or more previously-executed transactions. For example, the trader may access a corresponding icon within a menu of a graphical user interface (e.g., “Transaction” icon404B within GUI400ofFIG. 4) to access a transaction page, a portion of which is depicted inFIG. 16A.

InFIG. 16A, an exemplary transactions page1600includes a list of transactions involving the trader, executed by the electronic trading system, and awaiting confirmation of an initial leg of settlement (e.g., via settlement confirmation from settlement agent140). For example, such a list may provide, among other things, an intended settlement date (i.e., “ISD” within “Initial Leg” column1604), a symbol, a transaction type, a transaction fee, a quantity, a value, a counterparty, and details on the initial leg of settlement for each transaction.

Upon completion of the initial leg of settlement, application server118may update transactions page1600to include a time stamp associated with the completion of the initial leg (i.e., an actual settlement date (“ASD”) within “Initial Leg” column1604) and a status of the transaction (e.g., within “Txn Status” column1608). The trader may then select a transaction1602that requires a return of security to a counterparty, and upon selection, a corresponding “Stock Return” window1610may be displayed to the trader within the graphical user interface, as described inFIG. 16B. InFIG. 16B, “Stock Return” window1610provides details on a security corresponding to the selected transaction, such as a CCP reference number, a symbol of the security, a number of units, a value of the security, and a corresponding, negotiable transaction fee.

Upon activating the “Return” button within “Stock Return” window1610, application server118books an intended settlement date (“ISD”) associated with the return leg, and updates transactions page1600to reflect the ISD of the return leg (e.g., within “Return Leg” column1606) and additionally or alternatively, a status of the transaction (e.g., within “Txn Status” column1608). The corresponding quantity of stocks or securities associated with the selected transaction may be returned to the counterparty, and the return leg of the settlement process for transaction1602may be completed. Application server118may provide an additional update to “Transactions” page1600to indicate a time stamp associated with the completed return leg (e.g., an actual settlement date (“ASD”) within “Return leg” column1606) and information identifying a transaction status (e.g., within “Txn Status” column1608).

In the embodiments described above reference is made to shares of securities denominated in U.S. dollars, and to transactions and trades valued in U.S. dollars. Such valuations and denominations are not, however, limited to a specific currency, e.g., U.S. dollars. In additional embodiments, any denomination of shares of securities, and any valuation of a trade or transactions, may be expressed in any of a number of currencies appropriate to an exchange or business model of trading platform110, including but not limited to, U.S. dollars, British pounds sterling, Euros, Swiss francs, and Japanese yen.

Various embodiments have been described herein with reference to the accompanying drawings. It will, however, be evident that various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope of the invention as set forth in the claims that follow.

Further, other embodiments will be apparent to those skilled in the art from consideration of the specification and practice of one or more embodiments of the present disclosure. It is intended, therefore, that this disclosure and the examples herein be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following listing of exemplary claims.