CA2298432A1 - Market transparent electronic brokerage system - Google Patents
Market transparent electronic brokerage system Download PDFInfo
- Publication number
- CA2298432A1 CA2298432A1 CA 2298432 CA2298432A CA2298432A1 CA 2298432 A1 CA2298432 A1 CA 2298432A1 CA 2298432 CA2298432 CA 2298432 CA 2298432 A CA2298432 A CA 2298432A CA 2298432 A1 CA2298432 A1 CA 2298432A1
- Authority
- CA
- Canada
- Prior art keywords
- participant
- participants
- offers
- given
- offer
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
An electronic brokerage system in which users interact with a central server over a public communications network such as the Internet. The system permits an open market to be established where remote participants anonymously submit offers to buy and sell various financial instruments or commodities and electronically trade.
Participants may also elect not to trade with other participants based on flexible exclusionary criteria and offers to buy or sell which a given participant is ineligible to accept are visually differentiated on the given participating workstation. The system enables all offers to buy or sell to be displayed to market participants and observers, thereby promoting price and depth of market transparency.
Participants may also elect not to trade with other participants based on flexible exclusionary criteria and offers to buy or sell which a given participant is ineligible to accept are visually differentiated on the given participating workstation. The system enables all offers to buy or sell to be displayed to market participants and observers, thereby promoting price and depth of market transparency.
Description
MARKET TRANSPARENT ELECTRONIC BROKERAGE SYSTEM
FIELD OF INVENTION
The invention generally relates to the field of electronic brokerage or S transaction systems, and more particularly to systems which provide market transparency so as to enable buyer and seller to transact without the need for intermediaries such as brokers.
BACKGROUND OF INVENTION
In an open market, price is determined by demand and supply. For market participants, it is important to know all existing bids and offers in the market, along with bid and ask prices and associated quantities. They need this information to make trading decisions or to decide whether to participate in the market. Also crucial to many market participants trading in commodities with volatile prices are forward price curves for the commodities. This information may aid them in managing price risks in commodities.
Further, participants often wish to know the identity of their counter parties, their credit-worthiness, and possibly other information about them such as their geographic location or their contact information.
A variety of electronic brokerage systems have been proposed in prior art which allows users to electronically submit offers to buy or sell financial instruments or goods and electronically close transactions. The prior art systems typically identify and display on users' viewscreens the best bid and ask prices for a particular item. Some prior art systems will automatically match buyer and seller, while in other systems trades must be manually executed. In some systems, such as the currency transaction system in U. S.
Patent No. 5,375,055 issued December 20, 1994 to Togher et al, market participants may specify limitations on the amount of credit that they are willing to specify to counter parties, such that a participant may not be able to accept any offer to buy or sell. The 20719707.1 Togher et al system therefore discloses the best "dealable" price for currency transactions that a participant may accept.
Conventionally, however, in these systems the market is closed in the sense that participants may see only the offer with the best eligible price, not all available offers.
As indicated earlier, knowledge of market depth can be important to participants in making a trading decision or to observers in deciding to participate.
Furthermore, other then restricting trading on the basis of credit limitations, the prior art does not provide much flexibility in excluding counter parties based on other criteria, such as restricting trade between affiliated companies or competitors.
SUMMARY OF INVENTION
The present invention provides an electronic brokerage or trading system allowing anyone with communication capability such as Internet access to participate in market activities. The system enables an open market to be established where buyers and sellers communicate their intention to trade and transact with each other anonymously.
Each participant, whether a buyer or a seller, needs to be registered with the system first.
Once they are registered, participants can select their trading counter-parties, submit offers to buy or sell, view all offers submitted by other market participants, and trade with selected counter-parties. An unregistered user of the system can only view submitted offers.
A participant can select other participants whom they are unwilling to trade with based on pre-determined criteria. They can set up the exclusionary criteria separately for offers to buy, offers to sell, or any transactions. This information is maintained in a central database, and the system will block any ineligible transaction.
Participants electronically submit offers to buy or sell to the system. The offers include at least a quantity of a particular financial instrument or commodities and a bid or ask price therefor. Where the instrument relates to a futures-based commodity contract the offer may also include a period of supply and a delivery date.
The system 20719707.1 processes each submitted offer and stores it in the central database. All offers, whether eligible or not, are transmitted to the participants' workstations for viewing. Offers which a given participant is ineligible to accept are visually differentiated. The system does not reveal the identity of the offeror in order to retain anonymity although the offerors' credit rating may be displayed along with the details or attributes of the offer. If the offers include a future contract period and delivery date, the system preferably sorts the offers into categories based on these characteristics and ranks the offers by price within each category for viewing. Offers displayed in this fashion provide participants with an instant indication of the shape of forward price curves.
Each participant may decide whether to accept an offer featuring the best eligible price, or with some other offer which may be more advantageous, such as quantity. The system sends confirmation messages to both participants of a trade and reveals their identifies to each other after the trade has been executed. The system will block a participant from transacting with an offering participant in the event the contemplated transaction is ineligible for either party. In such an event, since the system enables any participant to access contact information of all counter-parties who are unwilling to trade with the participant, it is possible for a participant to negotiate outside the system in person with any one of unwilling counter-parties in order to arrange for a private transaction.
BRIEF DESCRIPTION OF DRAWINGS
These and other features, aspects, and advantages of the present invention will become better understood with regard to the following detailed description of a preferred embodiment and the accompanying drawings, therefor, wherein:
~ Fig. 1 is a schematic diagram of the architecture of the electronic transaction system in accordance with the preferred embodiment, showing market participants and public, non-participating observers interacting with a central host system;
~ Fig. 2 is a schematic diagram of data tables employed by the host system;
20719707.1 _4_ ~ Figs. 3 and 4 are diagrams of input screens for enabling a system administrator to register market participants;
~ Fig. 5 is a diagram of an input screen for enabling participants to select or exclude its trading counter-parties;
~ Fig. 6 is a diagram of a display screen enabling users to observe the state of the market in summary form;
~ Fig. 7 is a diagram of a display screen for viewing all offers related to a particular financial instrument;
~ Fig. 8 is a diagram of an input screen for allowing participants to submit or modify offers to buy or sell;
~ Fig. 9 is a flowchart showing the processing carned out by the host system when an offer is submitted by a participant;
~ Fig. 10 is a flowchart showing the processing carried out by the host system when an offer is accepted by a participant;
~ Fig. 11 is a diagram showing various windows providing information relating to the status of a transaction; and ~ Fig. 12 is a schematic diagram of the software architecture of the host system in accordance with the preferred embodiment.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
Referring to the drawings, the present invention provides an electronic brokerage system 10 for use in trading conventional financial instruments such as stocks, bonds and commodities. The system also enables participants to trade other types of intangibles including "quasi-commodities" such as electrical power or pollution rights which in some respects resemble the bulk-like nature of commodities and in other respects have personal attributes associated therewith as discussed in greater detail below.
20719707.1 _5_ Fig. 1 provides an organizational overview of the system 10 in accordance with the preferred embodiment. Structurally, the system 10 comprises a central host system 14 which includes a server 16 and a central database 18. Users of the system employ workstations 20 to communicate with the server 16 over a communications network 22. A variety of facilities may be used for the communications network as known in the art per se including the public telephone system or the Internet.
The system 10 has two types of users, namely market participants 24 and observers 26. Market participants are individuals or organizations which have officially registered with the host system 14 and are entitled to buy and sell financial instruments and other intangibles. (The term "commodity" will hereinafter be used to generically refer to any of these items). Through their workstations 20, market participants 24 can submit or review offers to buy and sell commodities and initiate the execution of transactions.
Observers 26 are individuals which have not registered with the host system 14 or otherwise cannot be validated thereby. These users cannot trade or otherwise participate 1 S in market activities but may view market action.
Referring additionally to Fig. 2, an overview of the core of the central database 18 is shown. This database preferably includes Participant table 30 which lists all of the registered market participants, their contact information and logon status. Table 30 also preferably includes, for a given registered participant, information specifying which of the other participants the given participant is permitted to trade with or otherwise is excluded from trading with. This is discussed in greater detail below.
Participant table 30 is relationally linked to one or more Offer tables 32 used to store all open offers to buy and sell different types of commodities and/or different categories of instruments within a particular type of commodity. The Offer tables 32 are relationally linked to the Transactional log tables 34 which log executed transactions. The Offer tables 32 are also relationally linked to a Market Summary table 36 which, as explained in greater detail below, provides a snapshot of the market as a whole for a group of commodities or a group of financial instruments within a particular type of commodity. The central 20719707.1 . , _6_ server 16 accepts buy and sell offers from the workstations 14 for storage in the central database 18 and continuously broadcasts the offers stored therein to various of the workstations 14. The server 16 also processes trades as described in greater detail below.
As mentioned, market participants must register with the host system 14 in order to trade. The registration process is preferably carned out by a system administrator. Figs. 3 and 4 show input screen forms 40 and 42 displayable on a workstation 20 for enabling the system administrator to enter a participant's registration information. As shown in Fig. 3, window 40A enables any previously input participant to be selected for editing, or alternatively a new participant may be edited through this screen form. The fill legal name of the particpant is entered into input field 40C. A
short name or abbreviation may also be entered, as shown at 40D. Input field 40F is used to collect the participant's telephone number. Once this information is submitted, or otherwise re-edited if previously submitted, the virtual save button 40G will cause the participant's registration information to be stored in the central database 18. If a new participant is submitted the system will thereafter generate a unique company ID for internal identification purposes. This ID is shown in display-only field 40A and cannot be changed.
In addition, the sytem administrator preferably assigns each market participant a credit rating which is entered in input field 40E. This credit rating may be the same as that assigned by credit rating agencies such as Standard & Poor's or Moody's Investors Service. Alternatively, the system administrator may use some other credit ratings developed solely for all participants utilizing the system 10. These credit ratings will enable other market participants to decide whether or not they wish to transact with the listed participant based on the credit-worthiness thereof.
A market participant may have one or more user accounts allowing one or more specific individuals to utilize system 10 concurrently. Fig. 4 shows input screen 42 for setting up a user account from the workstation 20, which may be established by the system administrator or by the participant itself. Windows 42A, 42B and 42C
enable 20719707.1 previously input users to be selected for editing or a new user may be entered by clearing all fields. Each user account is associated with a unique user ID 42D. The user's name and title are entered in input fields 42E and 42F respectively. Each user may be contacted in a variety of ways. List box 42I identifies the mode of communication such as telephone, e-mail, or facsimile, and field 42J enables the appropriate address or telephone number to be entered into the sytem. The virtual save buttons 42H and 42I
respectively enable the user and contact information to be saved when newly entered or otherwise edited. The user account is preferably activated by the system administrator (internal or system-wide) by actuating check-box 42G.
Once a given market participant 24 has been officially registered with the host system 14 the participant may select with whom it is willing to trade with (hereinafter referred to as a "counter-party"). Fig. 5 shows an input screen form 44 available at workstation 20 which enables market particpants to selectively exclude certain market participants as counter-parties, and conversely to select active counter-parties. List windows 46B and 46S list excluded counter-parties and list windows 48B and 48S
list active counter-parties. There may be a number of reasons why a market participant may not be able or willing to trade with every other market participant. For example, a participant may be unwilling to trade with its competitors or be unwilling to trade over an anonymous public market with its own subsidiaries or affiliated companies.
Similarly, a participant may have a preferential price for certain classes of counterparties but be unwilling to offer the same price to all market participants. In addition, a participant may be unwilling to trade or extend credit to participants having poor credit ratings. Similarly, a participant may wish to exclude other participants based on geographical factors. For instance, with a quasi-commodity such as electrical power there may not exist the necessary transmission lines to deliver power from one participant to another.
Similarly, with respect to pollution rights, regulatory rules may prevent the transfer of rights from one participant to another. In these respects quasi-commodities have personal, as opposed to bulk, attributes.
20719707.1 r -$-In the preferred embodiment shown in Fig. 5, all participants are by default deemed to be active counter-parties but this can be manually changed through the use of virtual Add and Exclude buttons 44A and 44B which enable participants to be moved between lists 46B and 48B or lists 46S and 48S. Note that in each list the credit rating of S other market participants is listed so as to permit the ready selection of participants based on credit-worthiness. In addition, through the use of a reverse colour scheme, a visual indication is preferably provided to the present participant as to those other market participants that have elected not to transact with the present participant.
This feature may foster private negotiation between parties for deals outside of the public market.
It should also be noted that in the preferred embodiment separate active and excluded counter-party lists 46B, 48B and 465, 48S are respectively maintained for buy and sell transactions. This allows a participant to select one set of counter-parties to sell to and another set of counter-parties to buy from. This feature provides a number of advantages. For example, with respect to the illustrated market for electrical power, a buyer may not care who supplies the electrical power due to the commodity-like characteristics of the power. However, as a seller, the participant may be much more concerned about a buyer's credit-worthiness. Thus a given participant may elect to buy power from a second participant but not to sell power thereto. This feature provides additional flexibility into the selection criteria. Those skilled in the art will understand that absolute transaction restrictions may be provided in alternative embodiments.
The Expression fields 50A and 50B provide a query language expression or phrase used by the server 16 to filter or select a subset of counter-parties that the present participant may trade with (or not) on a buy or sell transaction. In the preferred embodiment the manually selected counter-parties are expressed in the query language used by the system 10 in fields 50A and 50B - such as the well-known SQL
structured query language. However, these expressions may be edited so that each market participant can set up its own rules, i.e., selection and exclusionary criteria, to select its excluded counter-parties. The rules can be based on a number of variables made available by the host system 14 to market participants from which logical expressions can be 20719707.1 constructed. For instance, a participant may set up rules governing eligibility to transact based on counter-parties' credit ratings and monetary amounts of transactions.
A rule may be set up so that a potential counter-party has a credit rating of "A" for all transactions of $100,000 and under; a credit rating of "AA" for transactions of $1,000,000 and under; and a credit rating of "AAA" for transactions of $10,000,000 and under (and whereby no single transaction is permitted over $10,000,000). Once the expression is entered it is parsed by the server 16 to define excluded counter-parties or specific offers made thereby and the results are stored in the central database 18, preferably in the Participants file 30. Under this feature of excluding counter-parties, the identities of excluded or active counter-parties may not be immediately identifiable, however, other screens of the system as will be shortly described provide the participant with a visual indication as to whether or not the participant is eligible to transact on a given offer to buy or sell.
Fig. 6 shows an interactive "master blotter" screen 60 which is displayable on workstation 20 and which provides a concise overview of the current market for a group of commodities, or a group of financial instruments pertaining to a particular commodity as shown here. The example illustrated in Fig. 6 depicts a fixtures-based electric power market wherein an offer includes a bid or ask price per unit and the quantity of units (e.g., megawatts) being offered for sale or purchase. An offer may also include a contract delivery date, as shown. Offers are continually updated by host system 16 to all workstations 20 displaying the master blotter screen 60, based on the Market Summary table 36 of the central database 18. In addition, other useful information may be transmitted and displayed, such as the offering participants' credit rating, and/or its geographical location. However, the identity of the offering participant is concealed in order to maintain an anonymous trading system.
Offers are grouped into categories. In the illustrated futures-based example, categories are defined by the power delivery period and contract start date.
For instance, "Month ahead + 1" means power delivery for the entire next calendar month.
The master blotter screen 60 shows only the price and size of the last trade 62 and the best 20719707.1 bid and ask offers 64 and 66 respectively (based on price), for each category 68. However, by selecting or double clicking on a category 68 shown on the master blotter screen 60 all offers present in that category are displayable in an orders screen 70 (shown in Fig, 7).
The present participant is provided with a visual indication, such as through the use of a reverse colour scheme, as to whether it is eligible to accept any given offer 64 or 66 displayed on the master blotter screen 60. This ineligibility may arise due to the present participant's counter-party exclusionary selection or due to the exclusionary selection set up by the other market participants. The display also uses a particular colour to display the offers that the present participant has submitted.
Fig. 7 shows the orders display screen 70 where offers to buy 72 or sell 74 (i.e., bid and ask offers) in a particular category are grouped together and displayed in decreasing order from top to bottom based on price. Along with the prices are shown the quantity of units such as megawatts available for purchase or sale as well as the credit ratings of the offering participant. Again, through the use of a colour schemes, the display visually differentiates those offers which the present participant is ineligible to transact, and offers which have been tendered by the present participant. The identity of the other offering participants is not disclosed in order to retain anonymity. It should also be noted that all of the buy and sell offers in the selected category that collectively define the market therein are available for display through the order screen. This provides complete market transparency to the participant.
The participant can elect to accept any of the offers to buy 72 or sell 74 listed in the orders screen 70 by double clicking on the corresponding row.
This brings up an order entry screen 80 shown in Fig. 8 in which case fields 82 - 90 thereof which define the transaction are filled in. Alternatively, the participant can submit an entirely new offer to buy or sell (for the displayed category or for any other category) by clicking on virtual buttons 76 and 78 (Fig. 7). In this case, the workstation displays a blank order entry screen 80 (Fig. 8) so that input fields 30 through 38 may be filled in by the participant to define the new offer. The order entry screen 80 also allows participants to modify and/or cancel pre-existing offers submitted by that participant.
20719707.1 Referring now particularly to Fig. 8, input field 82 is designed as a list box wherein a participant may select one of a pre-determined number of categories such as the illustrated electricity supply period. Input field 84 is also a list box which enables the participant to select either a buy or sell offer. Input field 86 indicates the price per unit of the offer; input field 88 indicates the number of units being offered; and input field 88 specifies whether partial fills of the offer are acceptable. The screen 80 also comprises display-only fields including reference field 92 which represents a unique identification number for the order automatically assigned by the system; a user identification field 94 which specifies the user ID of the individual who submitted the order; and a modification field 96 representing the user ID of the individual that last modified the order, if applicable. Towards the bottom of the screen, a window 98 exists in which all of the market activity for the participant that day is displayed. This features aids in disseminating information with respect to the market activities of the participant amongst the various individual users trading on behalf of the participant. Additionally, another window 99 is provided to show the latest transactions for informational purposes. These windows are updated in real time.
Fig. 9 illustrates the processing carried out by the central host system 14 when a participant 24A submits (at 100) a new offer or modifies a pre-existing offer. At a first step 102 the offer is associated with one of the pre-established categories 68 and stored on the appropriate data table of the central database 18. As mentioned, these categories may be for different types of commodities or for different financial instruments in connection with a particular commodity. In a following step 104, all of the offers within the identified category, including the just-submitted offer, are ranked according to price.
At step 106, the system 14 performs a test to determine if the just-submitted offer is the best buy or sell price for the identified category. If so, then at step 108 cell in the Market Summary table 36 of the central database 18 is updated and the updated information is also broadcast over the communications network 22 to each workstation 20 displaying the master blotter screen 60 so that the appropriate cell, i.e., row and column is also updated.
If step 108 is unnecessary, then the master blotter screens 60 remain unchanged.
20719707.1 Nevertheless, the just-submitted offer is stored in the central database 18, and broadcast on demand to workstations 20 displaying orders screen 70.
Refernng now to Figs. 7, 8, 10, and 1 l, the processing that occurs when a participant desires to accept an offer is discussed in Beater detail. As previously mentioned, a given participant 24A selects an offer for acceptance by double clicking on any of the rows in the orders screen 70 (Fig. 7). This causes the offer to be displayed on the order entry screen 80 (Fig. 8) whereby the participant may accept the offer by clicking on the commit order button 93. This action corresponds to step 112 of the flowchart shown in Fig. 10 and causes a message to be transmitted over the communications network to the central server 16. At a first step 114, the server 16 sends a message back to the workstation of participant 24A which causes a window 140 (See Fig. 11) to open requesting the user to confirm the trade by clicking on virtual confirmation button. Once the user elects to proceed with the trade the server 16 at step 116 then queries the central database 18 to determine whether or not the participant has accepted an offer from an active or non-excluded counterparty. As previously mentioned, a participant may exclude other participants through manual selection or by setting up exclusionary rules. If the participant making the offer (the "offeror") 24B is an active counterparty to the accepting participant 24A then, at step 118 the server 16 queries the central database 18 to determine if the accepting participant 24A is an active counterparty with respect to the offeror 24B. If either of the conditions tested for at steps 116 and 118 are false, then at step 120, the server 16 transmits a message to the present participant 24A
indicating that the trade could not be executed. This causes a window 144 (Fig. 11) to open on the workstation associated with participant 24A informing it that the trade could not be executed. However, if both of the conditions at steps 116 and 118 are satisfied, then at step 122, the server 16 checks to see whether the contemplated transaction would result in a partially filled offer. If so, then at step 124, the server 16 checks to see whether or not the offeror has permitted partial fills. If not, control passes to step 120 wherein the trade failure message is transmitted to participant 24A. However, if partial fills are permitted then at step 126, the server 16 readjusts the offer by subtracting the number of units 20719707.1 (e.g. power) just contracted for from the original amount and re-submits the adjusted offer back to the appropriate offer table 32. At step 128, the server 16 sends a trade acknowledgment message to the offeror 24B and to the accepting participant 24A. This causes a window 142 (Fig. 11 ) to activate on the workstations of the offeror 24B and S accepting participant 24A acknowledging a successful trade to each participant thereof.
Note that at this time each participant is provided with the identity of its counterparty, as shown. At step 130, the Market Summary table 36 of the central database 18 is updated as required and the server 16 broadcasts an update message to workstations 20 which currently display the master blotter screen 60 and other system screens reflecting the change in the state of the market. At step 132 the server 16 updates the transaction log tables 34 of the central database 18.
In the preferred embodiment, the transactional log maintains a history of trades and can be downloaded by participants or other subscribers of the system. This ability can be quite advantageous for participants wishing to manage price risks. More particularly, some markets, such as the market for trading pollution rights, are quite new.
In such markets, it is difficult to determine how price varies with supply and demand, especially in a forward market. However, by downloading the historical trade information, participants can derive forward price curves to assist in managing price risk.
It should also be noted that the master blotter screen 60 provides an instantaneous forward price curve. This is because the offers are categorized and sorted by contract period and delivery date. A variant of the preferred embodiment may alternatively display on the master blotter the best prices associated with offers having a minimum threshold on the quantity of commodity offered for sale. This may assist in reducing any anomalies that may arise in best prices introduced by small quantities of commodities offered for purchase or sale.
One advantage provided by the preferred embodiment in comparison to other over the counter trading methods, e.g., bi-lateral telephone negotiation or trading through a broker, is that the present invention provides price transparency and 20719707.1 transparency with respect to the depth of market for any given financial instrument. This is because all of the offers of purchase and sale for any given future contract period are viewable by participants. This is in marked contrast to traditional financial exchanges which are implemented and controlled by intermediaries such as brokers. In contrast, the preferred embodiment substantially reduces transaction costs and enables the natural buyer and seller, as well as speculators willing to trade risk, to directly interact in a setting which provides a level playing field to all participants.
Fig. 12 shows the software architecture of the system 10, which resembles a client/server architecture. The primary software components of this system are a server feeder 150 and client software 154 and 156. System administrators use administration client software 154 to monitor the system and to perform administrative tasks.
This software runs on a workstation associated with the system administrator and enables the administrator to access administration screens 40 and 42 for registering participants with the system. User client 156 is a program which resides on the workstation of each market participant 24. This program preferably comprises a conventional Internet browser which enables market participants to view the various user screens shown in Figs. 5 -8. The browser is preferably supplied with an applet, which may be downloaded from the host system 16, which provides local intelligence for executing database queries and other local processing. All communications with the host system 16 are managed by the user client are managed by the user client software 156. Non-participating observers 26 will access the system and view the master blotter screen 60, but as previously mentioned observers cannot navigate from this screen to the other display screens of the system.
The server feeder 150 is responsible for managing all submitted offers, blocking ineligible transactions and executing eligible transactions requested by market participants, as discussed above. The server feeder 150 is also responsible for updating the central database 18 and sending update messages to all user clients 156.
In the preferred embodiment, the system employs software to update the screen displays on workstations 24 in substantially real time. This software organizes screen displays as spread sheets, wherein each cell represents an attribute such as price, quantity or delivery 20719707.1 date of an offer. When a new offer is submitted or an existing offer is modified, the server feeder 150 does not send an entirely new page display to user client software 156.
Instead, the software 152 only sends packets reflecting the incremental change to effect certain cells of the currently displayed screens and the user client software dynamically updates only the effected cells. Typical software that has been used as SLINGSHOTT"' available from CSK Software or software is also available for this function from Microsoft. Those skilled in the art will realize that a variety of alternative technologies may be used to provide a means for updating the display screens on workstations 24 in substantially real time.
The server feeder 150 sends database queries to an SQL server software 160 which processes such queries and interfaces with the central database 18.
Other software components of the system include an e-mail daemon 162 which is responsible for sending confirmatory e-mail messages to participants for a variety of purposes, including confirmation of trade execution. Fax daemon 166 provides a similar 1 S purpose. The end of day software component 164 generates daily reports from the market transaction logs of the central database 18. The end of month software component 168 is responsible for back office processing tasks such as sending out invoices to bill market participants for a subscription to the system and to realize any commissions arising out of the completion of transactions. This component is also responsible for monthly maintenance and mailing activities. Those skilled in the art will realize that these software components may run over a distributed computing platform or be executed by the same computer system that runs the server feeder 150.
20719707.1
FIELD OF INVENTION
The invention generally relates to the field of electronic brokerage or S transaction systems, and more particularly to systems which provide market transparency so as to enable buyer and seller to transact without the need for intermediaries such as brokers.
BACKGROUND OF INVENTION
In an open market, price is determined by demand and supply. For market participants, it is important to know all existing bids and offers in the market, along with bid and ask prices and associated quantities. They need this information to make trading decisions or to decide whether to participate in the market. Also crucial to many market participants trading in commodities with volatile prices are forward price curves for the commodities. This information may aid them in managing price risks in commodities.
Further, participants often wish to know the identity of their counter parties, their credit-worthiness, and possibly other information about them such as their geographic location or their contact information.
A variety of electronic brokerage systems have been proposed in prior art which allows users to electronically submit offers to buy or sell financial instruments or goods and electronically close transactions. The prior art systems typically identify and display on users' viewscreens the best bid and ask prices for a particular item. Some prior art systems will automatically match buyer and seller, while in other systems trades must be manually executed. In some systems, such as the currency transaction system in U. S.
Patent No. 5,375,055 issued December 20, 1994 to Togher et al, market participants may specify limitations on the amount of credit that they are willing to specify to counter parties, such that a participant may not be able to accept any offer to buy or sell. The 20719707.1 Togher et al system therefore discloses the best "dealable" price for currency transactions that a participant may accept.
Conventionally, however, in these systems the market is closed in the sense that participants may see only the offer with the best eligible price, not all available offers.
As indicated earlier, knowledge of market depth can be important to participants in making a trading decision or to observers in deciding to participate.
Furthermore, other then restricting trading on the basis of credit limitations, the prior art does not provide much flexibility in excluding counter parties based on other criteria, such as restricting trade between affiliated companies or competitors.
SUMMARY OF INVENTION
The present invention provides an electronic brokerage or trading system allowing anyone with communication capability such as Internet access to participate in market activities. The system enables an open market to be established where buyers and sellers communicate their intention to trade and transact with each other anonymously.
Each participant, whether a buyer or a seller, needs to be registered with the system first.
Once they are registered, participants can select their trading counter-parties, submit offers to buy or sell, view all offers submitted by other market participants, and trade with selected counter-parties. An unregistered user of the system can only view submitted offers.
A participant can select other participants whom they are unwilling to trade with based on pre-determined criteria. They can set up the exclusionary criteria separately for offers to buy, offers to sell, or any transactions. This information is maintained in a central database, and the system will block any ineligible transaction.
Participants electronically submit offers to buy or sell to the system. The offers include at least a quantity of a particular financial instrument or commodities and a bid or ask price therefor. Where the instrument relates to a futures-based commodity contract the offer may also include a period of supply and a delivery date.
The system 20719707.1 processes each submitted offer and stores it in the central database. All offers, whether eligible or not, are transmitted to the participants' workstations for viewing. Offers which a given participant is ineligible to accept are visually differentiated. The system does not reveal the identity of the offeror in order to retain anonymity although the offerors' credit rating may be displayed along with the details or attributes of the offer. If the offers include a future contract period and delivery date, the system preferably sorts the offers into categories based on these characteristics and ranks the offers by price within each category for viewing. Offers displayed in this fashion provide participants with an instant indication of the shape of forward price curves.
Each participant may decide whether to accept an offer featuring the best eligible price, or with some other offer which may be more advantageous, such as quantity. The system sends confirmation messages to both participants of a trade and reveals their identifies to each other after the trade has been executed. The system will block a participant from transacting with an offering participant in the event the contemplated transaction is ineligible for either party. In such an event, since the system enables any participant to access contact information of all counter-parties who are unwilling to trade with the participant, it is possible for a participant to negotiate outside the system in person with any one of unwilling counter-parties in order to arrange for a private transaction.
BRIEF DESCRIPTION OF DRAWINGS
These and other features, aspects, and advantages of the present invention will become better understood with regard to the following detailed description of a preferred embodiment and the accompanying drawings, therefor, wherein:
~ Fig. 1 is a schematic diagram of the architecture of the electronic transaction system in accordance with the preferred embodiment, showing market participants and public, non-participating observers interacting with a central host system;
~ Fig. 2 is a schematic diagram of data tables employed by the host system;
20719707.1 _4_ ~ Figs. 3 and 4 are diagrams of input screens for enabling a system administrator to register market participants;
~ Fig. 5 is a diagram of an input screen for enabling participants to select or exclude its trading counter-parties;
~ Fig. 6 is a diagram of a display screen enabling users to observe the state of the market in summary form;
~ Fig. 7 is a diagram of a display screen for viewing all offers related to a particular financial instrument;
~ Fig. 8 is a diagram of an input screen for allowing participants to submit or modify offers to buy or sell;
~ Fig. 9 is a flowchart showing the processing carned out by the host system when an offer is submitted by a participant;
~ Fig. 10 is a flowchart showing the processing carried out by the host system when an offer is accepted by a participant;
~ Fig. 11 is a diagram showing various windows providing information relating to the status of a transaction; and ~ Fig. 12 is a schematic diagram of the software architecture of the host system in accordance with the preferred embodiment.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
Referring to the drawings, the present invention provides an electronic brokerage system 10 for use in trading conventional financial instruments such as stocks, bonds and commodities. The system also enables participants to trade other types of intangibles including "quasi-commodities" such as electrical power or pollution rights which in some respects resemble the bulk-like nature of commodities and in other respects have personal attributes associated therewith as discussed in greater detail below.
20719707.1 _5_ Fig. 1 provides an organizational overview of the system 10 in accordance with the preferred embodiment. Structurally, the system 10 comprises a central host system 14 which includes a server 16 and a central database 18. Users of the system employ workstations 20 to communicate with the server 16 over a communications network 22. A variety of facilities may be used for the communications network as known in the art per se including the public telephone system or the Internet.
The system 10 has two types of users, namely market participants 24 and observers 26. Market participants are individuals or organizations which have officially registered with the host system 14 and are entitled to buy and sell financial instruments and other intangibles. (The term "commodity" will hereinafter be used to generically refer to any of these items). Through their workstations 20, market participants 24 can submit or review offers to buy and sell commodities and initiate the execution of transactions.
Observers 26 are individuals which have not registered with the host system 14 or otherwise cannot be validated thereby. These users cannot trade or otherwise participate 1 S in market activities but may view market action.
Referring additionally to Fig. 2, an overview of the core of the central database 18 is shown. This database preferably includes Participant table 30 which lists all of the registered market participants, their contact information and logon status. Table 30 also preferably includes, for a given registered participant, information specifying which of the other participants the given participant is permitted to trade with or otherwise is excluded from trading with. This is discussed in greater detail below.
Participant table 30 is relationally linked to one or more Offer tables 32 used to store all open offers to buy and sell different types of commodities and/or different categories of instruments within a particular type of commodity. The Offer tables 32 are relationally linked to the Transactional log tables 34 which log executed transactions. The Offer tables 32 are also relationally linked to a Market Summary table 36 which, as explained in greater detail below, provides a snapshot of the market as a whole for a group of commodities or a group of financial instruments within a particular type of commodity. The central 20719707.1 . , _6_ server 16 accepts buy and sell offers from the workstations 14 for storage in the central database 18 and continuously broadcasts the offers stored therein to various of the workstations 14. The server 16 also processes trades as described in greater detail below.
As mentioned, market participants must register with the host system 14 in order to trade. The registration process is preferably carned out by a system administrator. Figs. 3 and 4 show input screen forms 40 and 42 displayable on a workstation 20 for enabling the system administrator to enter a participant's registration information. As shown in Fig. 3, window 40A enables any previously input participant to be selected for editing, or alternatively a new participant may be edited through this screen form. The fill legal name of the particpant is entered into input field 40C. A
short name or abbreviation may also be entered, as shown at 40D. Input field 40F is used to collect the participant's telephone number. Once this information is submitted, or otherwise re-edited if previously submitted, the virtual save button 40G will cause the participant's registration information to be stored in the central database 18. If a new participant is submitted the system will thereafter generate a unique company ID for internal identification purposes. This ID is shown in display-only field 40A and cannot be changed.
In addition, the sytem administrator preferably assigns each market participant a credit rating which is entered in input field 40E. This credit rating may be the same as that assigned by credit rating agencies such as Standard & Poor's or Moody's Investors Service. Alternatively, the system administrator may use some other credit ratings developed solely for all participants utilizing the system 10. These credit ratings will enable other market participants to decide whether or not they wish to transact with the listed participant based on the credit-worthiness thereof.
A market participant may have one or more user accounts allowing one or more specific individuals to utilize system 10 concurrently. Fig. 4 shows input screen 42 for setting up a user account from the workstation 20, which may be established by the system administrator or by the participant itself. Windows 42A, 42B and 42C
enable 20719707.1 previously input users to be selected for editing or a new user may be entered by clearing all fields. Each user account is associated with a unique user ID 42D. The user's name and title are entered in input fields 42E and 42F respectively. Each user may be contacted in a variety of ways. List box 42I identifies the mode of communication such as telephone, e-mail, or facsimile, and field 42J enables the appropriate address or telephone number to be entered into the sytem. The virtual save buttons 42H and 42I
respectively enable the user and contact information to be saved when newly entered or otherwise edited. The user account is preferably activated by the system administrator (internal or system-wide) by actuating check-box 42G.
Once a given market participant 24 has been officially registered with the host system 14 the participant may select with whom it is willing to trade with (hereinafter referred to as a "counter-party"). Fig. 5 shows an input screen form 44 available at workstation 20 which enables market particpants to selectively exclude certain market participants as counter-parties, and conversely to select active counter-parties. List windows 46B and 46S list excluded counter-parties and list windows 48B and 48S
list active counter-parties. There may be a number of reasons why a market participant may not be able or willing to trade with every other market participant. For example, a participant may be unwilling to trade with its competitors or be unwilling to trade over an anonymous public market with its own subsidiaries or affiliated companies.
Similarly, a participant may have a preferential price for certain classes of counterparties but be unwilling to offer the same price to all market participants. In addition, a participant may be unwilling to trade or extend credit to participants having poor credit ratings. Similarly, a participant may wish to exclude other participants based on geographical factors. For instance, with a quasi-commodity such as electrical power there may not exist the necessary transmission lines to deliver power from one participant to another.
Similarly, with respect to pollution rights, regulatory rules may prevent the transfer of rights from one participant to another. In these respects quasi-commodities have personal, as opposed to bulk, attributes.
20719707.1 r -$-In the preferred embodiment shown in Fig. 5, all participants are by default deemed to be active counter-parties but this can be manually changed through the use of virtual Add and Exclude buttons 44A and 44B which enable participants to be moved between lists 46B and 48B or lists 46S and 48S. Note that in each list the credit rating of S other market participants is listed so as to permit the ready selection of participants based on credit-worthiness. In addition, through the use of a reverse colour scheme, a visual indication is preferably provided to the present participant as to those other market participants that have elected not to transact with the present participant.
This feature may foster private negotiation between parties for deals outside of the public market.
It should also be noted that in the preferred embodiment separate active and excluded counter-party lists 46B, 48B and 465, 48S are respectively maintained for buy and sell transactions. This allows a participant to select one set of counter-parties to sell to and another set of counter-parties to buy from. This feature provides a number of advantages. For example, with respect to the illustrated market for electrical power, a buyer may not care who supplies the electrical power due to the commodity-like characteristics of the power. However, as a seller, the participant may be much more concerned about a buyer's credit-worthiness. Thus a given participant may elect to buy power from a second participant but not to sell power thereto. This feature provides additional flexibility into the selection criteria. Those skilled in the art will understand that absolute transaction restrictions may be provided in alternative embodiments.
The Expression fields 50A and 50B provide a query language expression or phrase used by the server 16 to filter or select a subset of counter-parties that the present participant may trade with (or not) on a buy or sell transaction. In the preferred embodiment the manually selected counter-parties are expressed in the query language used by the system 10 in fields 50A and 50B - such as the well-known SQL
structured query language. However, these expressions may be edited so that each market participant can set up its own rules, i.e., selection and exclusionary criteria, to select its excluded counter-parties. The rules can be based on a number of variables made available by the host system 14 to market participants from which logical expressions can be 20719707.1 constructed. For instance, a participant may set up rules governing eligibility to transact based on counter-parties' credit ratings and monetary amounts of transactions.
A rule may be set up so that a potential counter-party has a credit rating of "A" for all transactions of $100,000 and under; a credit rating of "AA" for transactions of $1,000,000 and under; and a credit rating of "AAA" for transactions of $10,000,000 and under (and whereby no single transaction is permitted over $10,000,000). Once the expression is entered it is parsed by the server 16 to define excluded counter-parties or specific offers made thereby and the results are stored in the central database 18, preferably in the Participants file 30. Under this feature of excluding counter-parties, the identities of excluded or active counter-parties may not be immediately identifiable, however, other screens of the system as will be shortly described provide the participant with a visual indication as to whether or not the participant is eligible to transact on a given offer to buy or sell.
Fig. 6 shows an interactive "master blotter" screen 60 which is displayable on workstation 20 and which provides a concise overview of the current market for a group of commodities, or a group of financial instruments pertaining to a particular commodity as shown here. The example illustrated in Fig. 6 depicts a fixtures-based electric power market wherein an offer includes a bid or ask price per unit and the quantity of units (e.g., megawatts) being offered for sale or purchase. An offer may also include a contract delivery date, as shown. Offers are continually updated by host system 16 to all workstations 20 displaying the master blotter screen 60, based on the Market Summary table 36 of the central database 18. In addition, other useful information may be transmitted and displayed, such as the offering participants' credit rating, and/or its geographical location. However, the identity of the offering participant is concealed in order to maintain an anonymous trading system.
Offers are grouped into categories. In the illustrated futures-based example, categories are defined by the power delivery period and contract start date.
For instance, "Month ahead + 1" means power delivery for the entire next calendar month.
The master blotter screen 60 shows only the price and size of the last trade 62 and the best 20719707.1 bid and ask offers 64 and 66 respectively (based on price), for each category 68. However, by selecting or double clicking on a category 68 shown on the master blotter screen 60 all offers present in that category are displayable in an orders screen 70 (shown in Fig, 7).
The present participant is provided with a visual indication, such as through the use of a reverse colour scheme, as to whether it is eligible to accept any given offer 64 or 66 displayed on the master blotter screen 60. This ineligibility may arise due to the present participant's counter-party exclusionary selection or due to the exclusionary selection set up by the other market participants. The display also uses a particular colour to display the offers that the present participant has submitted.
Fig. 7 shows the orders display screen 70 where offers to buy 72 or sell 74 (i.e., bid and ask offers) in a particular category are grouped together and displayed in decreasing order from top to bottom based on price. Along with the prices are shown the quantity of units such as megawatts available for purchase or sale as well as the credit ratings of the offering participant. Again, through the use of a colour schemes, the display visually differentiates those offers which the present participant is ineligible to transact, and offers which have been tendered by the present participant. The identity of the other offering participants is not disclosed in order to retain anonymity. It should also be noted that all of the buy and sell offers in the selected category that collectively define the market therein are available for display through the order screen. This provides complete market transparency to the participant.
The participant can elect to accept any of the offers to buy 72 or sell 74 listed in the orders screen 70 by double clicking on the corresponding row.
This brings up an order entry screen 80 shown in Fig. 8 in which case fields 82 - 90 thereof which define the transaction are filled in. Alternatively, the participant can submit an entirely new offer to buy or sell (for the displayed category or for any other category) by clicking on virtual buttons 76 and 78 (Fig. 7). In this case, the workstation displays a blank order entry screen 80 (Fig. 8) so that input fields 30 through 38 may be filled in by the participant to define the new offer. The order entry screen 80 also allows participants to modify and/or cancel pre-existing offers submitted by that participant.
20719707.1 Referring now particularly to Fig. 8, input field 82 is designed as a list box wherein a participant may select one of a pre-determined number of categories such as the illustrated electricity supply period. Input field 84 is also a list box which enables the participant to select either a buy or sell offer. Input field 86 indicates the price per unit of the offer; input field 88 indicates the number of units being offered; and input field 88 specifies whether partial fills of the offer are acceptable. The screen 80 also comprises display-only fields including reference field 92 which represents a unique identification number for the order automatically assigned by the system; a user identification field 94 which specifies the user ID of the individual who submitted the order; and a modification field 96 representing the user ID of the individual that last modified the order, if applicable. Towards the bottom of the screen, a window 98 exists in which all of the market activity for the participant that day is displayed. This features aids in disseminating information with respect to the market activities of the participant amongst the various individual users trading on behalf of the participant. Additionally, another window 99 is provided to show the latest transactions for informational purposes. These windows are updated in real time.
Fig. 9 illustrates the processing carried out by the central host system 14 when a participant 24A submits (at 100) a new offer or modifies a pre-existing offer. At a first step 102 the offer is associated with one of the pre-established categories 68 and stored on the appropriate data table of the central database 18. As mentioned, these categories may be for different types of commodities or for different financial instruments in connection with a particular commodity. In a following step 104, all of the offers within the identified category, including the just-submitted offer, are ranked according to price.
At step 106, the system 14 performs a test to determine if the just-submitted offer is the best buy or sell price for the identified category. If so, then at step 108 cell in the Market Summary table 36 of the central database 18 is updated and the updated information is also broadcast over the communications network 22 to each workstation 20 displaying the master blotter screen 60 so that the appropriate cell, i.e., row and column is also updated.
If step 108 is unnecessary, then the master blotter screens 60 remain unchanged.
20719707.1 Nevertheless, the just-submitted offer is stored in the central database 18, and broadcast on demand to workstations 20 displaying orders screen 70.
Refernng now to Figs. 7, 8, 10, and 1 l, the processing that occurs when a participant desires to accept an offer is discussed in Beater detail. As previously mentioned, a given participant 24A selects an offer for acceptance by double clicking on any of the rows in the orders screen 70 (Fig. 7). This causes the offer to be displayed on the order entry screen 80 (Fig. 8) whereby the participant may accept the offer by clicking on the commit order button 93. This action corresponds to step 112 of the flowchart shown in Fig. 10 and causes a message to be transmitted over the communications network to the central server 16. At a first step 114, the server 16 sends a message back to the workstation of participant 24A which causes a window 140 (See Fig. 11) to open requesting the user to confirm the trade by clicking on virtual confirmation button. Once the user elects to proceed with the trade the server 16 at step 116 then queries the central database 18 to determine whether or not the participant has accepted an offer from an active or non-excluded counterparty. As previously mentioned, a participant may exclude other participants through manual selection or by setting up exclusionary rules. If the participant making the offer (the "offeror") 24B is an active counterparty to the accepting participant 24A then, at step 118 the server 16 queries the central database 18 to determine if the accepting participant 24A is an active counterparty with respect to the offeror 24B. If either of the conditions tested for at steps 116 and 118 are false, then at step 120, the server 16 transmits a message to the present participant 24A
indicating that the trade could not be executed. This causes a window 144 (Fig. 11) to open on the workstation associated with participant 24A informing it that the trade could not be executed. However, if both of the conditions at steps 116 and 118 are satisfied, then at step 122, the server 16 checks to see whether the contemplated transaction would result in a partially filled offer. If so, then at step 124, the server 16 checks to see whether or not the offeror has permitted partial fills. If not, control passes to step 120 wherein the trade failure message is transmitted to participant 24A. However, if partial fills are permitted then at step 126, the server 16 readjusts the offer by subtracting the number of units 20719707.1 (e.g. power) just contracted for from the original amount and re-submits the adjusted offer back to the appropriate offer table 32. At step 128, the server 16 sends a trade acknowledgment message to the offeror 24B and to the accepting participant 24A. This causes a window 142 (Fig. 11 ) to activate on the workstations of the offeror 24B and S accepting participant 24A acknowledging a successful trade to each participant thereof.
Note that at this time each participant is provided with the identity of its counterparty, as shown. At step 130, the Market Summary table 36 of the central database 18 is updated as required and the server 16 broadcasts an update message to workstations 20 which currently display the master blotter screen 60 and other system screens reflecting the change in the state of the market. At step 132 the server 16 updates the transaction log tables 34 of the central database 18.
In the preferred embodiment, the transactional log maintains a history of trades and can be downloaded by participants or other subscribers of the system. This ability can be quite advantageous for participants wishing to manage price risks. More particularly, some markets, such as the market for trading pollution rights, are quite new.
In such markets, it is difficult to determine how price varies with supply and demand, especially in a forward market. However, by downloading the historical trade information, participants can derive forward price curves to assist in managing price risk.
It should also be noted that the master blotter screen 60 provides an instantaneous forward price curve. This is because the offers are categorized and sorted by contract period and delivery date. A variant of the preferred embodiment may alternatively display on the master blotter the best prices associated with offers having a minimum threshold on the quantity of commodity offered for sale. This may assist in reducing any anomalies that may arise in best prices introduced by small quantities of commodities offered for purchase or sale.
One advantage provided by the preferred embodiment in comparison to other over the counter trading methods, e.g., bi-lateral telephone negotiation or trading through a broker, is that the present invention provides price transparency and 20719707.1 transparency with respect to the depth of market for any given financial instrument. This is because all of the offers of purchase and sale for any given future contract period are viewable by participants. This is in marked contrast to traditional financial exchanges which are implemented and controlled by intermediaries such as brokers. In contrast, the preferred embodiment substantially reduces transaction costs and enables the natural buyer and seller, as well as speculators willing to trade risk, to directly interact in a setting which provides a level playing field to all participants.
Fig. 12 shows the software architecture of the system 10, which resembles a client/server architecture. The primary software components of this system are a server feeder 150 and client software 154 and 156. System administrators use administration client software 154 to monitor the system and to perform administrative tasks.
This software runs on a workstation associated with the system administrator and enables the administrator to access administration screens 40 and 42 for registering participants with the system. User client 156 is a program which resides on the workstation of each market participant 24. This program preferably comprises a conventional Internet browser which enables market participants to view the various user screens shown in Figs. 5 -8. The browser is preferably supplied with an applet, which may be downloaded from the host system 16, which provides local intelligence for executing database queries and other local processing. All communications with the host system 16 are managed by the user client are managed by the user client software 156. Non-participating observers 26 will access the system and view the master blotter screen 60, but as previously mentioned observers cannot navigate from this screen to the other display screens of the system.
The server feeder 150 is responsible for managing all submitted offers, blocking ineligible transactions and executing eligible transactions requested by market participants, as discussed above. The server feeder 150 is also responsible for updating the central database 18 and sending update messages to all user clients 156.
In the preferred embodiment, the system employs software to update the screen displays on workstations 24 in substantially real time. This software organizes screen displays as spread sheets, wherein each cell represents an attribute such as price, quantity or delivery 20719707.1 date of an offer. When a new offer is submitted or an existing offer is modified, the server feeder 150 does not send an entirely new page display to user client software 156.
Instead, the software 152 only sends packets reflecting the incremental change to effect certain cells of the currently displayed screens and the user client software dynamically updates only the effected cells. Typical software that has been used as SLINGSHOTT"' available from CSK Software or software is also available for this function from Microsoft. Those skilled in the art will realize that a variety of alternative technologies may be used to provide a means for updating the display screens on workstations 24 in substantially real time.
The server feeder 150 sends database queries to an SQL server software 160 which processes such queries and interfaces with the central database 18.
Other software components of the system include an e-mail daemon 162 which is responsible for sending confirmatory e-mail messages to participants for a variety of purposes, including confirmation of trade execution. Fax daemon 166 provides a similar 1 S purpose. The end of day software component 164 generates daily reports from the market transaction logs of the central database 18. The end of month software component 168 is responsible for back office processing tasks such as sending out invoices to bill market participants for a subscription to the system and to realize any commissions arising out of the completion of transactions. This component is also responsible for monthly maintenance and mailing activities. Those skilled in the art will realize that these software components may run over a distributed computing platform or be executed by the same computer system that runs the server feeder 150.
20719707.1
Claims (17)
1. A process for effecting electronic transactions, comprising:
registering participants with a host computer system;
enabling any one participant to select other participants with whom said one participant is unwilling to transact with;
accepting offers to buy or sell from said participants and storing same on said host system, wherein each said offer indicates at least a quantity of a particular financial instrument, commodity or intangible and a bid or ask price therefor;
enabling all of said offers to be displayed on a workstation associated with any given participant to thereby enable participants to view the market depth for said financial instrument; commodity or intangible displaying any said offer on the workstation associated with the given participant so as to preserve the anonymity of the corresponding participant making said offer, yet visually indicating on said workstation whether said given participant and said offering participant are bilaterally eligible to transact with one another in respect of said displayed offer; and blocking said given participant from transacting with said offering participant in the event the contemplated transaction is ineligible for either party.
registering participants with a host computer system;
enabling any one participant to select other participants with whom said one participant is unwilling to transact with;
accepting offers to buy or sell from said participants and storing same on said host system, wherein each said offer indicates at least a quantity of a particular financial instrument, commodity or intangible and a bid or ask price therefor;
enabling all of said offers to be displayed on a workstation associated with any given participant to thereby enable participants to view the market depth for said financial instrument; commodity or intangible displaying any said offer on the workstation associated with the given participant so as to preserve the anonymity of the corresponding participant making said offer, yet visually indicating on said workstation whether said given participant and said offering participant are bilaterally eligible to transact with one another in respect of said displayed offer; and blocking said given participant from transacting with said offering participant in the event the contemplated transaction is ineligible for either party.
2. The process according to claim 1, wherein any given participant is able to separately select (a) other participants with whom said given participant is unwilling to sell to, and (b) other participants with whom said given participant is unwilling to buy from.
3. The process according to claim 2, wherein any given participant is able to enter a logical expression for excluding other participants from trading, wherein said logical expression is parsed by said host system.
4. The process according to claim 1, including, enabling the identification of other participants to be displayed on the workstation associated with any one participant and visually indicating on said workstation whether any of said other participants have elected not to transact with said one participants.
5. The process according to claim 1, wherein said financial instrument is a futures-based contract includes a contract period and a future delivery date.
6. The process according to claim 5, wherein said offers are sorted for display based on contract period and the best bid and ask prices therefor are displayed.
7. The process according to claim 1, including associating credit rating information for each participant and displaying the credit rating of each participant submitting an offer to buy or sell.
8. The process according to claim 1, wherein said visual indication includes displaying said offers in a pre-selected colour.
9. An electronic brokerage system, comprising:
a communications network;
a host computer system connected to said network;
at least one workstation communicating with said host system over said network;
said host system being programmed to (i) accept offers from any of said workstations, wherein each said offer to buy or sell indicates at least a quantity of a particular financial instrument, commodity or intangible and a bid or ask price therefor, (ii) determine whether any given pair of participants are bilaterally eligible to transact in respect of any given offer to buy or sell and prevent any such transaction from occurring in the event the transaction is ineligible;
each said workstation being programmed to said to display any and all offers so as to preserve the confidentiality of the participants making said offers yet visually indicate to a given participant whether said given participant and said offering participants are bilaterally eligible to transact with one another in respect of said offers.
a communications network;
a host computer system connected to said network;
at least one workstation communicating with said host system over said network;
said host system being programmed to (i) accept offers from any of said workstations, wherein each said offer to buy or sell indicates at least a quantity of a particular financial instrument, commodity or intangible and a bid or ask price therefor, (ii) determine whether any given pair of participants are bilaterally eligible to transact in respect of any given offer to buy or sell and prevent any such transaction from occurring in the event the transaction is ineligible;
each said workstation being programmed to said to display any and all offers so as to preserve the confidentiality of the participants making said offers yet visually indicate to a given participant whether said given participant and said offering participants are bilaterally eligible to transact with one another in respect of said offers.
10. The electronic brokerage system according to claim 9, further including a plurality of non-participant observer terminals communicating with said host system over said network, and wherein said host system is programmed to transmit offers of purchase and sale to said terminals for viewing purposes only.
11. The electronic brokerage system according to claim 9, wherein said host system is programmed to allow any given participant to separately select any other participant that said any given participant is unwilling to buy from or unwilling to sell to.
12. The electronic brokerage system according to claim 9, wherein said host system is programmed to allow any given participant to exclude other participants from a transaction by entering a logical expression at a given work station, wherein said logical expression is parsed by said host system.
13. The electronic brokerage system according to claim 9, wherein said host system is programmed to enable a given workstation of one participant to display identification information of other participants and visually indicate whether any of said other participants have elected not to transact with said one participant.
14. The electronic brokerage system according to claim 9, wherein said financial instrument comprises a futures-based contract, said futures-based contract having a contract period and a future delivery date.
15. The electronic brokerage system according to claim 13, wherein said host system is programmed to sort said offers for visual display based on a contract period, with best bid and ask prices therefor displayed.
16. The electronic brokerage system according to claim 9, wherein credit rating information is associated with each participant and said credit rating information is displayed for each participant submitting and offer to buy or sell.
17. The electronic brokerage system according to claim 9, wherein display of said any and all offers comprises displaying offers in a pre-selected colour.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US42042199A | 1999-10-19 | 1999-10-19 | |
| US09/420,421 | 1999-10-19 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2298432A1 true CA2298432A1 (en) | 2001-04-19 |
Family
ID=23666405
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA 2298432 Abandoned CA2298432A1 (en) | 1999-10-19 | 2000-02-11 | Market transparent electronic brokerage system |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2298432A1 (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7801794B2 (en) | 2001-09-21 | 2010-09-21 | Omx Technology Ab | Efficient electricity system |
-
2000
- 2000-02-11 CA CA 2298432 patent/CA2298432A1/en not_active Abandoned
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7801794B2 (en) | 2001-09-21 | 2010-09-21 | Omx Technology Ab | Efficient electricity system |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7231363B1 (en) | Method and system for rebrokering orders in a trading system | |
| US6647373B1 (en) | Method and system for processing and transmitting electronic reverse auction information | |
| US10269061B2 (en) | Anonymous block trade matching system | |
| CA2370789C (en) | A securities trading system for consolidation of trading on multiple ecns and electronic exchanges | |
| US20030018561A1 (en) | Single party buying and selling commodities with multiple counterparties | |
| US6408282B1 (en) | System and method for conducting securities transactions over a computer network | |
| US7720742B1 (en) | Computer trading system method and interface | |
| US6418419B1 (en) | Automated system for conditional order transactions in securities or other items in commerce | |
| US7499871B1 (en) | System and method for procurement of products | |
| KR100428887B1 (en) | Commerce information processor, commerce terminal, commerce information processing method, and recorded medium | |
| US20020007335A1 (en) | Method and system for a network-based securities marketplace | |
| US20150161729A1 (en) | System and method for physicals commodity trading | |
| US20020128945A1 (en) | Automated trading system | |
| US20070005481A1 (en) | Real time graphical user interface for on-line trading | |
| JP2003536146A (en) | System and method for reverse auction of financial instruments | |
| WO2000052619A1 (en) | A system and method for conducting securities transactions over a computer network | |
| US20110125628A1 (en) | Method and system for automated auction and tender of complex multi-variable commodities | |
| KR102035117B1 (en) | Anonymous block trade matching system | |
| CA2298432A1 (en) | Market transparent electronic brokerage system | |
| US20180068391A1 (en) | Method and system for facilitating rules-based communications between two external sources | |
| AU2018275000A1 (en) | Anonymous block trade matching system | |
| Lee | Design of capital market systems | |
| KR20020012464A (en) | Method for Operating Internet Site through the Intermediation of Web Site Makers and Someoan who wants to make Web Site | |
| AU2013273772A1 (en) | Anonymous block trade matching system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Dead |