WO2001050390A1

WO2001050390A1 - A system and method for purchasing and managing securities expressed in dollar denominations

Info

Publication number: WO2001050390A1
Application number: PCT/US2000/035670
Authority: WO
Inventors: Kevin T. Carter
Original assignee: Canopy Acquisition Corp.
Priority date: 1999-12-30
Filing date: 2000-12-29
Publication date: 2001-07-12
Also published as: AU2610601A

Abstract

A system for processing security transactions that permits investors to trade, receive position reports, and manage securities in dollar-denominated and fractional amounts [see Fig. 1] is disclosed. In one embodiment, the invention includes three components: a Front End Order Processing System, a Back End Order Processing System [150], and a Position Maintenance and Reporting System [180]. The Front End Order Processing System receives dollar-denominated transaction requests and aggregates them and converts them into a unit-denominated format for execution. Upon conversion, the aggregated unit-denominated order is routed for execution. The Back End Order Processing System receives the execution, clearing and settlement information concerning the aggregated unit-denominated order. This information is used to allocate the p[roceeds from the aggregated transaction to the individual orders. The Back-End System routes the trade information to the Position Maintenance System which handles the record keeping and position reporting functions of the system.

Description

A SYSTEM AND METHOD FOR PURCHASING AND MANAGING SECURITIES EXPRESSED IN DOLLAR DENOMINATIONS

Field of Invention

The present invention is directed to a system that permits investors to trade, receive position reports, and manage securities in dollar-denominated and fractional amounts, as opposed to whole share, warrant or other unit-denominated amounts.

Background of Invention

Traditionally, investors place equity orders with brokers, dealers, banks, and other securities market participants (collectively, broker-dealers) by indicating the security to be purchased, the quantity to be purchased and the type of order. Conventional customer accounts with broker-dealers permit customers to enter orders to purchase equity securities in unit denominations (e.g., buy 100 shares, sell 500 warrants, buy 10 call options). Orders are promptly transmitted to an exchange, dealer or other market for execution. The exchanges and dealer markets themselves permit only executions and reporting of executions in whole-unit amounts. Once the whole-unit order is executed, the broker-dealer will clear and settle the trade in accordance with industry custom and the rules and regulations of various clearinghouses, e.g., the National Securities Clearing Corporation, Midwest Clearing Corporation, Boston Stock Exchange Clearing Corporation, Stock Clearing Corporation of Philadelphia (collectively, Clearinghouses), self-regulatory organizations, e.g., National Association of Securities Dealers, New York Stock Exchange, and the Securities & Exchange Commission. Recently, the Internet has become a popular medium for the acceptance of unit-denominated securities orders. Traditional brokerages offer this service in addition to their traditional offerings, and new firms have been created that use the Internet as their primary method of order acceptance.

One problem with the conventional method of trading and managing securities in unit denominations is that this format makes it difficult for some investors to create and maintain diversified equity holdings. Academic studies indicate that diversification is achieved when an investor holds approximately 20 stocks in equal proportions. To assemble a portfolio of 20 stocks, the investor would have to make 20 separate transactions, each incurring an average fee of $30.00. These fees undermine .any benefits that the investor would have achieved through diversification. Moreover, these transaction fees make it virtually impossible for an investor to make additional diversified security purchases without unbalancing the distribution of the investments within the portfolio, so that an average individual who wishes to invest his discretionary income on a regular basis into equity securities cannot obtain the full benefits of diversification.

Although many of the above obstacles can be overcome by investing in mutual funds, this option is not free from its own problems. First, mutual funds do not allow the investor any control over his specific security holdings, thereby limiting the investor from tailoring his holdings to his personal preferences. Second, because the fund manager decides when and what and how much securities are purchased or sold, the investor cannot control the timing of when he recognizes capital gains and losses from his holdings, leading to uncontrollable or undesirable tax consequences.

Objects and Summary of Invention

It is, therefore, an object of the present invention to provide an investment trading and management system that allows investors to place orders for securities expressed in dollar denominations and hold securities in fractional amounts, so that a small investor can cost-efficiently create, manage, and reinvest in a diversified investment portfolio.

Another object of the invention is to lower tønsaction costs so that small investors may assemble diversified portfolios in a cost-efficient manner. A further object of the invention is to allow small investors seeking diversified holdings to manage the tax consequences of their holdings by controlling the timing of when the investor will recognize gains or losses from his investment transactions.

The present invention is directed to processing security transactions to satisfy the aforementioned objectives and overcome the deficiencies of the prior .art. In one embodiment, the invention includes three components: a Front End Order Processing System for receiving dollar-denominated transaction requests and converting them into unit-denominated orders; a Back End Order Processing System for receiving trade execution, clearing and settlement information and allocating proceeds from aggregated security transactions to individual customer accounts; and a Position Maintenance and Reporting System for maintaining a history of all account activity and customer holdings. Front End Order Processing begins with the step of receiving a transaction request for an amount of securities denominated in dollars. This request, among other things, identifies at least one security to be traded (i.e. bought or sold) and a transaction account with the broker-dealer associated with the requesting party. Upon receipt of the transaction request, the Front End System assigns an identification to the transaction request. Next, it determines whether the requesting party's transaction account contains value (i.e. cash, securities, credit etc.) sufficient to complete the transaction request. If it does, then that value is reserved for completing the transaction request. It is electronically marked so that it can not be used in other transaction requests pending the execution of the transaction for which it is reserved. After the value is reserved, the Front End Order Processing System separates the components of the transaction request into individual buy or sell orders for each security. Thus, a single transaction request to sell $500 of MSFT and $500 of GM would be broken into two separate orders, one for each stock. Individual buy or sell orders for each security are aggregated with other individual buy or sell orders for the same security to produce a single aggregated order for a security.

One embodiment of the invention will net buy orders with sell orders for the same security when making an aggregated order. The orders that are set off against each other are held for internal execution. For example, an order to purchase $1000 of MSFT will be netted with an order to sell $600 of MSFT to produce a net aggregated order to purchase $400 of MSFT. The remaining net aggregated order is converted and routed for execution in the standard method described herein. After execution of the net aggregated order, the amount held for internal execution is executed at the actual price of execution of the net aggregated order (or alternatively the closing price or some point in between) and then routed for Back End Order Processing. The aggregated order is held and combined with other transaction requests received by the broker-dealer until the aggregated order (or net aggregated order) reaches either a threshold dollar amount or a preset transaction deadline for execution. When the order reaches the threshold or deadline, the Front End System converts the aggregated order into a unit-denominated format. The conversion typically includes determining an estimated optimal execution price for the security; dividing the dollar amount of the aggregated buy or sell order by the estimated optimal price to obtain a unit-denominated expression of the order; and removing any fractional amount from the unit-denominated expression.

In one embodiment, the fractional amount can be handled in one of two ways. If the fractional amount can be supplied from broker-dealer's proprietary account, the order is rounded down to the appropriate whole unit and the broker-dealer will satisfy the order with its own securities. If the fractional amount cannot be satisfied from the broker-dealer's proprietary account, then the aggregated unit order will be rounded up, with any excess retained by the broker-dealer. Optionally, the broker-dealer may also add or subtract additional share amounts to the aggregated order to protect the order from price fluctuations occurring before execution or to manage its inventory of securities. In such cases, the orders are also rounded to the appropriate whole unit before being executed.

After conversion, the value in the broker-dealer's proprietary account necessary to complete execution of the aggregated unit-denominated order is reserved and the final aggregated unit-denominated order is routed for execution.

The Back End Order Processing System processes data received by the broker-dealer concerning the execution, clearing and settlement of the aggregated unit- denominated order. After Back End System receives trade execution information concerning the aggregated unit-denominated order, it allocates the proceeds from the order pro rata among the individual buy or sell orders comprising the aggregated unit- denominated order. This allocation is done using the actual terms of execution rather than the estimated optimal price used in conversion. The Back End System also adjusts the amounts reserved in the requesting party's transaction account to reflect the actual terms of execution and routes the trade execution information for position maintenance and reporting. The system can be configured to send a confirmation containing the trade execution information of the transaction to the requesting party.

After the Back End System receives clearing and settlement information from the clearing parties, it debits and credits the transaction accounts to reflect the terms of final settlement of the transaction. At this time, any reservations of value associated with the transaction are removed from the transaction account. Finally, the Back End System routes the clearing and settlement information to the Position Maintenance System.

The Position Maintenance System handles the record keeping and position reporting functions of the system. It receives pending transaction, execution, clearing and settlement information concerning the individual buy or sell orders identified with the requesting party's transaction account. It- also receives information concerning the requesting party's transaction account, including the amount of current value in requesting party's account, the amount of value reserved for pending transactions in the account, any debits or credits made to the transaction account. The Position Maintenance System debits any transaction or service fees against the requesting party's account for use of the broker- dealer's services. One embodiment of the invention will credit to the requesting party any interest earned on the assets held in his account.

Position Maintenance System also maintains history of all activity associated with the requesting party, including, past and current transaction requests; any debits and credits to the transaction account; and the requesting party's holdings within the transaction account. In one embodiment, the Position Maintenance System makes information concerning the requesting party's transactions with the broker-dealer available to the requesting party. This includes the requesting party's security holdings in transaction accounts, expressed in both dollar and unit denominations; the requesting party's cash held in transaction accounts; the history of activity associated with the requesting party; any pending transaction requests; and any value contained in the transaction account reserved for completing pending transaction requests.

In accordance with the present invention, the above described data processing can be implemented by a person of ordinary skill in the art in the form of a computer based data processing system using conventional hardware and software code written to perform the functions, as described herein. The apparatus of the preferred embodiment is known by those skilled in the art and can be assembled from standard equipment sold by server manufacturers such as Dell Computers, IBM, Sun Micro Systems, Hewlett-Packard, Compaq, etc. It is believed to be within the abilities of a person of ordinary skill in the art to write suitable software code for execution on the hardware selected. Such code can be written within standard Java Server Applets and/or database specific stored procedures. Such code can be produced by application developers such as EDS, Andersen Consulting, Perot Systems, etc.

With respect to a preferred embodiment, transaction requests are transmitted by a requesting party to the broker-dealer through the Internet. The requesting party accesses the broker-dealer's Internet web site and pulls up a transaction request window or screen. After providing the necessary information, the requesting party electronically transmits the order to the broker-dealer's computer/server/mainframe ("computer system") via the Internet. The broker-dealer's computer system employs the above Front End Processing systems and functionality to process the order for execution and then either routes the transaction request to an appropriate third party for execution or executes the transaction internally. An internal transaction is one that matches a first customer of the broker-dealer who is selling a security with a second customer of the broker-dealer who is seeks to buy the same security. The broker-dealer is thus able to transfer the requested amount from the first customer to the second as well as transfer the value to be exchanged for the requested amount from the second customer to the first. Another type of internal transaction is when the broker-dealer satisfies an order with securities or value retained in its own proprietary account.

Upon execution of the transaction, trade execution information is electronically transferred back to the broker-dealer whose computer system then engages in Back End Processing of the order. Clearing and settlement information is also received electronically by the Back End System. Upon completion of Back End Processing, the transaction information, as well as the requesting party's account information and transaction history, is made available by the Position Maintenance and Reporting System to the requesting party. Preferably, this too is done over the Internet using a position reporting page for the requesting party.

Each of the above data processing functions and updating of accounts is handled electronically within a single broker-dealer computer system, although it should be understood that multiple systems and multiple broker-dealers each performing a part of the functionality of the entire system could be used.

With respect to any fractional interests held by the requesting party as result of the above transactions, the broker-dealer maintains electronic records of this interest and will honor this interest at the request of its customers.

Brief Description of the Drawings

Further features, advantages, and characteristics of the present invention will become apparent in view of the following detailed disclosure made with references to the accompanying drawings in which:

Fig. 1 is a flow chart illustrating the flow of data during a typical security transaction in accordance with a preferred embodiment of the present invention;

Fig. 2 illustrates the apparatus used with the preferred embodiment depicted in Fig. 1; Fig. 3 illustrates a layout of a position reporting page;

Fig. 4 illustrates a layout of a transaction request form;

Fig. 5 is a flow chart illustrating the flow of data during the Front End Processing of a transaction request in accordance with the preferred embodiment depicted in Fig. 1; Fig. 6 is a flow chart illustrating the flow of data during the Back End Order processing of a transaction request in accordance with the preferred embodiment depicted in Fig. 1 ; and

Fig. 7 is a flow chart illustrating the flow of data within the Position Maintenance System in accordance with the preferred embodiment depicted in Fig. 1.

Detailed Description of the Invention

The present invention is directed to a system and method for processing orders to buy and sell securities in dollar denominations and for allowing investors to buy, sell and hold individual securities in whole and fractional units. Fig. 1 is a flow chart of one embodiment in which an investor (requesting party 110) submits an order via communications network 112 to purchase or sell a specific dollar amount of securities, with the unit amount to be determined upon execution of the order. Transaction request 115 identifies the type of transaction, such as buy (long or cover) or sell (long or short), the security to be purchased or sold, and the dollar amount of that security to be purchased or sold. As an option, it may also include certain special order instructions known in the industry (e.g., limit price, stop instruction, not held, fill or kill, all or none, MOC, lock, alternative order, good to cancel, V-WAP, contingent order, DNR, DNI, buy minus, sell plus, percentage order, etc.). Fig. 4 depicts a transaction request form with a limit price option 430. This special instruction allows requesting party 110 to limit the highest share price that it will accept in a purchase transaction or the lowest price in a sale transaction. Fig. 4 also includes a time limit option 420 to execute the transaction. If the transaction cannot be made within the set price limits by the time specified, the transaction request is automatically cancelled.

Broker-dealer 113 has many options to accept transaction requests from requesting party 110. For example, the order format might require a customer to enter a dollar amount for each equity security (e.g., buy $ 1 ,000 of IBM, sell $500 of GM (Fig. 4; 440)); it might permit requesting party 110 to specify a dollar amount and then select the securities to be bought or sold in equal amounts (e.g., $1,000 order to buy equal amounts of IBM, GM, MSFT, and INTC to total $1,000); or it might permit requesting party 110 to specify a dollar amount to buy or sell a variable percentage of a list of equity securities (e.g., $1,000 order to buy 20% IBM, 50% MSFT, 15% INTC, and 15% GM (Fig. 4; 450)). Broker-dealer 113 may use any of these options alone or in combination to receive orders, but preferably the present invention should be able to accept orders in all of the above formats as well as conventional unit-denominated transaction requests.

The monetary denomination of orders accepted by the system does not necessarily have to be limited to U.S. dollars. Optionally, the system may be set up to accept orders in any currency or even give a choice of different currencies to express the order. Thus, references herein to "dollar denomination" should be understood to mean the use of any type of currency or monetary unit. Nor does the investment have to be limited to equity securities, but could include other financial instruments such as government bonds, corporate bonds, private equity, warrants, options, commercial paper, ADR's, REIT's, partnership interests, unit investment trusts, closed-end funds, Direct Participation Programs, swaps, swaptions, commodities, futures and other traded instruments.

Transaction request 115 may also be submitted to the broker-dealer in any of a number of ways. Fig. 2 depicts a preferred embodiment of the invention in which the transaction request 115 is submitted to broker-dealer 113 through the Internet 111 by the customer's personal computer 210. The term "personal computer" as used herein should be understood to include not only a PC but also a personal digital assistant (e.g., 3Com Palm ® brand computing device), web TV, cellular telephone, or other communications device having Internet communication functionality.

The customer accesses the broker-dealer's home page 221, then accesses his position reporting page 222 (an example of which is illustrated in Fig. 3), and pulls up a transaction request window or screen 223 (an example of which is illustrated in Fig. 4). After providing the requested information, the transaction request 115 is transmitted through web server 114 to the broker-dealer's server/mainframe/computer 230. Server/mainframe/computer 230 employs the data processing described herein and makes available the customer's transaction and account information through the Internet, by providing such information on the customer's position reporting page (Fig. 3). Server/mainframe/computer 230 has interface 240 to receive data from outside executing parties, clearing and settlement parties and best price information providers. It also provides access to the broker dealer's personnel 250 by making information available through personal computers. It is believed that a person of ordinary skill in the. art can assemble suitable hardware and write software code to perform the function of the invention, as described herein. The apparatus of the preferred embodiment is known by those skilled in the art and can be assembled from standard equipment sold by server manufacturers, such as Dell Computers, JJBM, Sun Micro Systems, Hewlett-Packard, Compaq, etc. It is believed to be within the abilities of a person of ordinary skill in the art to write suitable software code for execution on the hardware selected. Such code can be written within standard Java Server Applets and/or database specific stored procedures. Such code can be produced by application developers such as EDS, Andersen Consulting, Perot Systems, etc. Transaction request 115 could also be submitted by a direct communications link to the broker-dealer, such as a modem, or by a telephone, or by a written request delivered to the broker-dealer. Moreover, the transaction requests could be indirectly submitted to the broker-dealer by an agent or other representative of the investor/customer, such as a registered investment advisor or other financial advisor. Typically, financial advisors act on the behalf of their clients in buying and selling investment securities. Other parties that might submit orders include introducing broker-dealers, trust officers, accountants or other financial intermediaries.

Fig. 5 depicts the flow of data within the Front End Processing System. Once the order is received by broker-dealer 113 (step 510), it undergoes Front End Order Processing by the system. After transaction request 115 has been received, it is broken down by security, if necessary, and dollar amount, if necessary, resulting in individual transaction requests for each security that comprises the order (step 550). If transaction request 115 is expressed in a percentage of a total dollar transaction, then it must be converted into specific dollar value transactions before being broken down (step 552). In the last examples above, the broker-dealer would separate the tr.ansaction request into four orders: buy $200 of IBM, $500 of MSFT, $150 of INTC, and $150 of GM. Separation by security would be unnecessary if the order consisted of an order to buy or sell a single security. During Front End Processing, each component of the transaction request 115 is assigned a transaction identifier (step 513) that is matched to the customer's transaction account(s) 130 with the broker-dealer. The identifier may be comprised of numbers, letters or any other suitable character for identifying the transaction. The system then determines whether the component transactions meet certain trade prerequisites (step 530). One such prerequisite is whether the customer/investor's account contains sufficient value to complete the transaction. "Value" as used herein means cash, securities, credit or any other collateral or resource usable for completing the transaction. Another important prerequisite is that transaction request 115 is received before the transaction deadline for processing an order that day. The broker-dealer may also place restrictions on the type of security, number of securities or size of orders that can be traded in the account. If transaction request 115 fails to meet the trade prerequisites, a message is sent to the customer/purchaser indicating a failed transaction and reason for failure, and the transaction request is either cancelled or held for execution in the following day, depending on the arrangement the broker-dealer has with the requesting party (step 540).

Once each order consists of a dollar-denominated order to buy or sell a single security, the broker-dealer could choose to either aggregate each separated order with other orders from other customers in the same security or handle the order individually (i.e., the broker-dealer can elect to take an order to buy $500 of IBM and combine it with another customer's order to buy $300 of IBM to create a single order to buy $800 of IBM, or it can elect to handle two orders for $500 and $300, respectively) (step 560).

Once each order consists of a dollar-denominated order to buy or sell a single security, the broker-dealer could choose either to aggregate each separated order with other orders from other customers in the same security or handle the order individually (i.e., the broker-dealer can elect to take an order to buy $500 of IBM and combine it with another customer's order to buy $300 of IBM to create a single order to buy $800 of IBM, or it can elect to handle two orders for $500 and $300, respectively) (step 560).

In a preferred embodiment of the system, orders for the same security during the day are aggregated to lower the cost of executing the various requests. This is accomplished by first aggregating existing individual orders for the same type of transaction (i.e., buy orders with buy orders and sell orders with sell orders) and for the same security together to form one aggregated order for the security. When the dollar amount of the aggregated order meets a threshold dollar minimum for executing the transaction with a desired or an acceptable transaction cost (step 570), then it is immediately converted to a unit denomination, as described below. If the dollar amount of the aggregated order is below the threshold for a cost-efficient execution, the order is held and combined with additional orders of the same type and for the same security received during the day until the total aggregated order reaches the threshold minimum, at which time the order is then converted for immediate execution. An alternative method to aggregate orders is to net buy orders with sell orders for the same security when making an aggregated order. The orders that are set off against each other are held for internal execution. The remaining net aggregated order is converted and routed for execution in the standard method described herein (steps 590, 592, 594, 595, 596, 597). As part of Back End Processing, as described in more detail below, after execution of the net aggregated order, the amount held for internal execution is executed at the actual price of execution of the net aggregated order, or at the closing price,, or the mid point between the closing bid and closing offer of the closing national best bid or offer ("NBBO") (Fig. 6; step 628).

The threshold minimum preferably should be set by broker-dealer 113 to minimize transaction costs associated with the execution of the order, but remain consistent with the broker-dealer's best execution responsibilities. Various factors influence the optimal threshold minimum for execution, such as execution costs, clearing costs, availability of automated execution, current quote sizes, market volatility, and the availability of automated or V-WAP execution. One variant of the invention could give customers the option of immediate execution, whereby execution of the individual order will not be delayed for cost-minimizing so that the customer can take advantage of price fluctuations occurring during the day. In such cases, the customer may be charged an additional fee for this service.

A transaction deadline preferably must also be set for the order. This deadline represents a limit to how long the system will hold on to the order before routing it for further execution. It preferably should be set as late in the day as possible but reserving sufficient time to finish executing any pending orders. If the aggregated order fails to reach the cost-efficient threshold volume before the transaction deadline (step 574), at that time the order will be sent for immediate conversion .and execution. This allows broker-dealer 113 to guarantee execution within a certain time period, usually one day. An alternative to having just a single deadline in a day is setting a time period after the transaction is received during which the order is executed. Another variation is to allow the requesting party to set a time limit (Fig. 4; 420) for its transaction and then base the transaction deadline upon that limit. Still another option is to have multiple deadlines during the day so that orders will be routed for execution, for example, every hour. Any of these options can be used singularly or in combination to implement the invention.

Once an aggregated order is approved for conversion, the system will determine the estimated optimal price for converting the aggregated order into a unit- denominated order (step 580). This price in the case of a sale transaction is the highest price that can be obtained, and in the case of a purchase transaction the lowest. The estimated optimal price would usually be determined by the broker-dealer through use of contemporaneous quotations and last-sale prices (collectively, best price data 123) obtained directly or indirectly from facilities of the National Market System, broker-dealers, the exchanges, automated trading systems, and other market information providers 125. In the illustrated embodiment, the dollar denominated aggregated order is converted into unit- denominated format by using either last-sale price information and/or the NBBO or a foreign equivalent.

After Front End System 120 determines the estimated optimum price, it will carry out conversion by dividing the aggregated dollar amount of orders for a particular security by the price to obtain an order expressed in unit/share amounts (step 590). The system then checks the broker-dealer's inventory (proprietary account 160) to satisfy fractional orders (step 592). The fractional portion is either removed from the order, if it can be fulfilled with securities retained in the broker-dealer's proprietary account 160, or it is rounded up to an appropriate whole share amount (usually, but not necessarily, the next highest whole number). For example, if the national best offer price of IBM is 65 VΛ, an order to buy $700 of IBM would be converted to an order to buy 11 shares of IBM

(step 590). In the case of rounding up, the interest in the fractional amount added to the order to make up a whole unit order will be retained by broker-dealer 113.

Optionally, the system can be configured to add or subtract share amounts to the aggregated order (before or after the rounding of the aggregated order) to manage the broker-dealer's inventory of securities held in proprietary account(s) 160 (step 594). (For the prefeπed embodiment depicted in Fig. 5, the adding or subtracting of share amounts is done before the rounding of the aggregated order.) In case of a purchase order, the broker- dealer may subtract the amount of securities of the requested type held in its inventory (or a portion thereof) from the aggregated order and use these securities to satisfy the portion removed from the order. These securities are held for internal execution. The remaining net aggregated unit-denominated order is then rounded to an appropriate whole unit (step 595). After execution of the net aggregated order, the amount held for internal execution is executed at the actual price of execution of the net aggregated order (or alternatively the closing price or the mid point between the closing bid and closing offer that comprise the closing NBBO) and then routed for Back End Order Processing (Fig. 6; step 628). In case of sell transactions, the broker dealer may add the amount (or portion thereof) of securities held in its inventory of the type being sold to the aggregated order and round the order to the appropriate whole unit amount. These securities will be sold for the benefit of the broker-dealer and proceeds from their sale will be retained by the broker dealer.

The present invention may also be configured to add or subtract share amounts to the aggregated order to protect against deviations from the estimated optimal price and the actual price of execution (step 594). In this embodiment, Front End System 120 checks the inventory levels of the security being purchased or sold within proprietary account 160 to insure that the order can be filled in face of price fluctuations that may occur after conversion but prior to execution. If there is an insufficient amount of shares to act as a buffer, additional share amounts may be added or subtracted from the aggregated unit-denominated order to insure that the broker-dealer can fill the order. This could occur before or after the rounding of the order.

Another option to protect against price deviations is to place price-limited orders with executing parties. A price-limited order is an order that by its terms cannot be executed at a lower price (in case of a sale) or higher price (in case of a purchase) than indicated.

Broker-dealer 113 may use any of the foregoing options alone or in combination to produce a final aggregated order or net aggregated order for a security.

After determining the final aggregated unit-denominated order, Front End System 120 will, in one embodiment, route pending transaction information 170 to reserve any necessary cash or securities from proprietary account 160 that will be used in the transaction, so as to prevent double counting of that value when assessing other transaction requests by the customer (step 596). It also routes pending transaction information 170 to Position Maintenance System 180 for reporting. Alternatively, in the embodiment shown in Fig. 1, proprietary account 160 is internal to Position Maintenance System 180. Thus, pending transaction information 170, as well as any other information, routed to proprietary account 160 may be accessed internally by Position Maintenance System 180 for reporting.

The system would complete Front End Processing by transmitting the aggregated unit-denominated order 135 to either an exchange, another broker-dealer, an electronic communications network, its own trading desk or other execution facility (collectively, executing/clearing parties 140) for execution (step 597). Aggregated unit- denominated order 135 routed for execution typically will consist of the following information: (a) an instruction to purchase or sell, (b) the number of shares or units, (c) the security symbol, (d) any special order instructions, (e) identification of the order as being for the account of the broker-dealer, (f) clearing information, if necessary, (g) instructions on the market to which the order should be directed, if broker-dealer 113 chooses to designate the market, and (h) any additional information about the order or source of the order as may be required under applicable laws and regulations, the rules of various self-regulatory organizations, or by agreement between broker-dealer 113 and third party executing or clearing firms, if any.

Broker-dealer 113 can act either as an agent, representing the order on the market, as a principal, selling the customer securities from its own inventory or buying the customer's securities into its own inventory, or it can arrange to have another broker-dealer represent the order on a market as either a principal or an agent. Once executed, the transaction would be cleared and settled in the customary fashion, depending on the market where the order was executed. If executed on one of the primary securities exchanges or on the National Association of Securities Dealers Automated Quotation System ("NASDAQ"), information about the compared, or locked-in, trade, along with information about the clearing broker-dealers is sent to the National Securities Clearing Corporation ("NSCC"), a clearinghouse that settles transactions on behalf of and between member broker-dealers, members' correspondent broker-dealers, and customers of both such entities. Certain regional markets have other clearing houses and some transactions require no external settlement, such as where a broker-dealer acts as principal in executing the order in a dealer market. It also should be understood that exchanges include any exchange throughout the world and thus the invention is not limited to exchanges regulated by United States law.

Once the transaction is executed, Back End Order Processing System 150 receives trade execution information 155 of the transaction (step 600). Fig. 6 depicts the flow of data within Back End Order Processing System 150. The confirmation contains information concerning: (a) quantity of shares purchased or sold, (b) price executed,

(c) market of transaction, (d) date of transaction, and (e) the capacity in which the executing party acted (principal or agent).

As shown in Fig. 6, Back End System 150 will determine whether the transaction was completed (step 610). If the transaction is not executed, depending upon the reason for the failure, the aggregated order will be (1) routed back into Front End System 120 for resubmission, (2) sent to broker-dealer's personnel 250 for further instruction, or (3) cancelled (or suspended) with a message sent to requesting party 110 indicating a failed transaction and possibly requesting further instruction (step 615). If the transaction was executed, the amount held for internal execution is executed at the actual price of execution of the net aggregated order (step 628). Next, the funds (in case of a sale) or securities (in case of a purchase) that were received from execution of the aggregated order are broken down and pro rata allocated based on the terms of actual execution (rather than estimated optimal price) to each customer's individual order that was a part of the aggregated order (step 630). The system would then adjust amounts reserved in requesting party's transaction account 130 to reflect the actual terms of execution (step 640). Actual custody of the cash or securities may be maintained with depositories, custodians and banks in accounts for the benefit of the broker-dealer's customers. Broker-dealer 113 or its clearing firm would keep track of the funds and/or securities held by its customers. Because share amounts may be added to the aggregated orders (to round the order or to manage inventory or to protect against price fluctuations), the amount of securities being bought may exceed the total dollar amount of the customers' orders. In such cases, the pro-rata excess securities purchased will be retained in the broker-dealer's proprietary account 160 and will have been paid for out of the broker-dealer's proprietary funds. In the case of customer sell orders, broker-dealer 113 may have added or subtracted additional share amounts to the order. If amounts were added to the order, the pro-rata excess shares sold will be for the account of the broker-dealer, if amounts were subtracted, the broker-dealer will be deemed to have purchased the excess fractional share as principal from the customer at the same price as the executed price of the whole unit amount and will credit the proceeds of such purchase from the customer to the customer's account.

Because broker-dealer 113 will permit the purchase and sale of fractional units of equity securities, investors will be able to build or liquidate portfolios of securities in precise amounts. Since it is contemplated that the broker-dealer will charge customers an asset-based fee rather than a transaction-based fee, investors that seek to build or liquidate a diversified portfolio in either uniform, dollar amounts or in small, dollar amounts should find the ability to place dollar-denominated orders and hold fractional units of equity securities an attractive method to avoid the problems of creating and managing a diversified portfolio associated with conventional unit-based transactions.

Upon executing the transaction or receiving confirmation of execution by the executing broker-dealer, the system will send a confirmation containing trade execution information 155 and any necessary regulatory disclosures (step 650) to the requesting party. The confirmation may either be electronic or written or both. This information as well as trade execution information is routed to the Position Maintenance System (step 660). Back End System 150 also receives the clearing and settlement information 171 of the executed transaction (step 670). Upon final settlement, the requesting party's account 130 is debited .and credited to reflect the finalized transaction and the account is cleared from any reservations associated with the transaction (step 680). Finally, clearing and settlement information is forwarded to the Position Maintenance System for reporting (step 690).

As shown in Fig. 7, Position Maintenance System 180 fulfills the primary record keeping and reporting functions of the broker-dealer. It receives requesting party 110's account information (step 700), trade execution information (step 710), pending transaction information (step 720), and clearing and settlement information (step 725). It applies the appropriate debits and credits to the customer's account resulting from the customer's transactions (step 730). It also tracks any pending transactions within the system and ensures that the system does not double count assets used in transactions.

It further applies fee charges for the broker-dealer's transactions (step 740). These fees may be a percentage of assets that varies by total assets in account, transactional fees, or other fees for certain services. The pricing should be such that it does not undermine the invention's goal of allowing investors to create diversified portfolios.

One option of the system in accordance with the present invention will pay interest on the cash value stored in the customer accounts (step 750). This may be accomplished by sweeping cash held in customer accounts into money market funds at periodic intervals and selling those securities when the customer uses the cash. Position Maintenance System 180 can credit interest earned on this cash to the customer's account.

The system also stores data on all activity on the customer's account and maintains records of customer's current security holdings and cash assets (step 760). In a preferred embodiment of the invention, Position Maintenance

System 180 provides to the customer access to his account information over the Internet. The requesting party would visit the broker-dealer's web site and access his account through use of a customer identifier and password. After this information is provided, the customer accesses his account screen, which automatically displays: (a) customer's cash and equivalents, (b) customer's security holdings expressed both in dollar and units (including fractional amounts), (c) all past account activity, (d) all current or pending activity, (e) all interest and charges, and (f) any required regulatory disclosures (step 780). Alternatively, the system may require the customer to make an additional selection to view one or more of the above. In addition to providing the above information, the system may also provide options for additional services or information. For example, the system may also provide portfolio asset analysis, portfolio rebalancing information, investment and market research, corporate filings, analyst consensus estimates, etc.

Alternatively, instead of using the Internet 111, the Position Maintenance

System 180 may be accessed by a direct communications link such as modem. The customer may also use an agent, such a financial advisor or other financial intermediary, to acquire account information. The broker-dealer could also provide this information over telephone or through the mail with account statements.

One skilled in the art will appreciate that the present invention can be practiced in other ways than the described embodiments, which are presented for purposes of illustration and not of limitation.

Claims

We Claim:

1. A method for processing security transactions comprising:

(a) receiving a transaction request for an amount of securities denominated in dollars, said request including a data set identifying at least one security to be traded and a transaction account associated with the requesting party, said at least one security to be traded being one of a buy transaction and a sell transaction;

(b) assigning identification characters to said transaction request;

(c) determining whether said transaction account contains a first value sufficient to complete said transaction request; (d) segregating the transaction request into individual buy or sell orders for each security;

(e) aggregating said individual buy or sell orders for each security with other individual buy or sell orders for the same security, said aggregate order having a total dollar amount, said other individual buy and sell orders being associated with other transaction requests;

(f) holding said aggregated order for each security until said aggregated order reaches one of a minimum threshold dollar amount and a preset transaction deadline for execution;

(g) in response to reaching said threshold or deadline, converting said aggregated order into a unit-denominated order;

(h) reserving a second value in said proprietary account necessary to complete execution of said final aggregated unit-denominated order; and

(i) routing said final aggregated unit-denominated order for execution.

2. The method of claim 1, wherein segregating said orders further comprises excluding said orders identified with said transaction account not having sufficient value to complete said order.

3. The method of claim 2, further comprising reserving said first value pending execution of transaction request.

4. The method of claim 2, wherein said conversion comprises the steps of:

(a) determining an estimated optimal execution price for said security;

(b) dividing said dollar amount of said aggregated buy or sell order by said estimated optimal execution price to obtain a unit-denominated expression of said order; and (c) removing any fractional amount from said unit-denominated expression by one of either adding or subtracting an amount to produce a final aggregated unit- denominated buy or sell order for each security expressed in whole units.

5. The method of claim 4, wherein said removing any fractional amount from said unit-denominated expression comprises one of:

(a) subtracting an amount to produce a whole unit order if said fractional amount can be supplied from a proprietary account,

(b) adding an amount to produce a whole unit order if said fractional amount cannot be satisfied from said proprietary account.

6. The method of claim 4, further comprising at least one of:

(a) adding or subtracting an additional share amount to aggregated unit- denominated order to protect against price fluctuations occurring prior to execution; and (b) adding or subtracting an additional share amount to manage an inventory of securities.

7. The method of claim 4, further comprising providing said threshold minimum dollar volume to minimize transaction costs associated with trade execution.

8. The method of claim 1, further comprising providing said threshold minimum dollar volume to minimize transaction costs associated with trade execution.

9. The method of claim 1, wherein after said aggregated unit-denominated order is sent for execution, the method further comprises the steps of:

(a) receiving trade execution information of said unit-denominated aggregated order;

(b) in response to a completed execution of said aggregated order, allocating proceeds from said order pro rata among said individual buy or sell orders comprising said aggregated unit-denominated order, wherein said allocation is based upon actual terms of execution of said order;

(c) receiving clearing and settlement information of said aggregated unit- denominated order;

(d) debiting and crediting said transaction accounts to reflect clearing and settlement of said individual buy or sell orders; (e) providing trade execution information of said transaction request to said requesting party; and

(f) routing said trade execution information for position maintenance and reporting.

10. The method of claim 9, wherein pro rata interest allocated to individual buy and sell orders includes fractional unit amounts.

11. The method of claim 9, wherein after proceeds from completion of said aggregated unit-denominated order is allocated to individual buy or sell orders, the method further comprises the steps of:

(a) receiving trade execution information of said individual buy or sell orders;

(b) receiving information regarding any pending transaction requests identified with said transaction account;

(c) receiving transaction account information, including an amount of cuπent value in said account, an amount of value reserved for pending transactions in said account, and any debits or credits made to said transaction account;

(d) debiting any transaction or service fees against account; (e) maintaining a history of all activity associated with said requesting party, said activity including past and current transaction requests and past and current debits and credits to said transaction account;

(f) making available to the requesting party information, said information including the requesting party's security holdings in said transaction accounts expressed in at least one of a dollar denomination and a unit denomination, requesting party's cash held in transaction accounts, said history of activity associated with said requesting party, said pending transaction requests, and any value contained in said transaction account reserved for completing said pending transaction requests.

12. The method of claim 11 further comprising crediting interest earned, if any, to said transaction account.

13. An apparatus for processing security transactions comprising:

(a) means for receiving a transaction request for an amount of securities denominated in dollars, said request including a data set identifying at least one security to be traded and a transaction account associated with the requesting party, said at least one security to be traded being one of a buy transaction and a sell transaction;

(b) means for assigning identification characters to said transaction request;

(c) means for determining whether said transaction account contains a first value sufficient to complete said transaction request;

(d) means for reserving said first value for completing the transaction request;

(e) means for segregating the transaction request into individual buy or sell orders for each security; (f) means for aggregating said individual buy or sell orders for each security with other individual buy or sell orders for the same security, said aggregate order having a total dollar amount, said other individual buy and sell orders being associated with other transaction requests;

(g) means for holding said aggregated order for each security until said aggregated order reaches one of a minimum threshold dollar amount and a preset transaction deadline for execution;

(h) means for converting said aggregated order into a unit-denominated order;

(i) means for reserving a second value in said proprietary account necessary to complete execution of said final aggregated unit-denominated order; and

(j) means for routing said final aggregated unit-denominated order for execution.

14. The apparatus of claim 13, wherein the means for segregating said orders further comprises means for excluding said orders identified with said transaction account not having sufficient value to complete said order.

15. The apparatus of claim 13, wherein said conversion means comprises:

(a) means for determining an estimated optimal execution price for said security;

(b) means for dividing said dollar amount of said aggregated buy or sell order by said price to obtain a unit-denominated expression of said order; and

(c) means for removing any fractional amount from said unit-denominated expression by one of either adding or subtracting an amount to produce a final aggregated unit-denominated buy or sell order for each security expressed in whole units.

16. The apparatus of claim 15, wherein said means for removing any fractional amount from said unit-denominated expression comprises:

(a) means for subtracting an amount to produce a whole unit order if said fractional amount can be supplied from a proprietary account; and (b) means for adding an amount to produce a whole unit order if the fractional amount cannot be satisfied from said proprietary account.

17. The apparatus of claim 15, further comprising at least one of:

(a) means for adding or subtracting an additional share amount to said aggregated unit-denominated order to protect against price fluctuations occurring prior to execution; and

(b) means for adding or subtracting an additional share amount to said aggregated unit-denominated order to manage inventory of securities.

18. The apparatus of claim 17, further comprising means for providing said threshold minimum dollar volume to minimize transaction costs associated with trade execution.

19. The apparatus of claim 13, further comprising a means for providing said threshold minimum dollar volume to minimize transaction costs associated with trade execution.

20. The apparatus of claim 19, further comprising:

(a) means for receiving trade execution information of said unit- denominated aggregated order;

(b) means for allocating proceeds from said order pro rata among said individual buy or sell orders comprising said aggregated unit-denominated order, wherein said allocation is based upon actual terms of execution of said order;

(c) means for receiving clearing and settlement information of said aggregated unit-denominated order;

(d) means for debiting and crediting said transaction accounts to reflect clearing and settlement of said individual buy or sell orders,

(e) means for providing trade execution information of said transaction request to said requesting party; and (f) means for routing said trade execution information for position maintenance and reporting.

21. The apparatus of claim 20 further comprising:

(a) means for receiving trade execution information of said individual buy or sell orders;

(b) means for receiving information regarding any pending transaction requests identified with said transaction account;

(c) means for receiving transaction account information, including an amount of current value in said account, an amount of value reserved for pending transactions in said account, and any debits or credits made to said transaction account;

(d) means for debiting any transaction or service fees against account; (e) means for maintaining a history of all activity associated with said requesting party, said activity including past and current transaction requests and past and current debits and credits to said transaction account;

(f) means for making available to the requesting party information, said information including the requesting party's security holdings in said transaction accounts expressed in at least one of a dollar denomination and a unit denomination, requesting party's cash held in transaction accounts, said history of activity associated with said requesting party, said pending transaction requests, and any value contained in said transaction account reserved for completing said pending transaction requests.

22. The apparatus of claim 21 further comprising means for crediting interest earned, if any, to said transaction account.

23. A method for processing security transactions comprising:

(b) assigning identification characters to said transaction request;

(c) determining whether said transaction account contains a first value sufficient to complete said transaction request, said first value being reserved for completing of the transaction request;

(d) segregating the transaction request into individual buy or sell orders for each security;

(e) aggregating said individual buy orders or sell orders for each security with other individual buy or sell orders for the same security, said aggregate order having a total dollar amount, said other individual buy and sell orders being associated with other transaction requests, wherein said buy orders are set off against said sell orders with remaining amount constituting a net aggregated order;

(f) holding said orders that were set off for internal execution;

(g) holding said net aggregated order for each security until said net aggregated order reaches one of a minimum threshold dollar amount and a preset transaction deadline for execution;

(h) in response to reaching said threshold or deadline, converting said net aggregated order, into a unit-denominated order, wherein said conversion comprises the steps of (1) determining an estimated optimal execution price for said security;

(2) dividing said dollar amount of said aggregated buy or sell order by said estimated optimal execution price to obtain a unit-denominated expression of said order; and (3) removing any fractional amount from said unit-denominated expression to obtain a final aggregated unit-denominated buy or sell order for each security;

(i) reserving a second value in said proprietary account necessary to complete execution of said final aggregated unit-denominated order; 0) routing said final aggregated unit-denominated order for execution;

(k) receiving trade execution information of said unit-denominated aggregated order;

(1) executing any orders held for internal execution at the actual terms of execution of said unit-denominated aggregated order; (m) in response to a completed execution of said aggregated order, allocating proceeds from said order pro rata among said individual buy or sell orders comprising said aggregated unit-denominated order, wherein said allocation is based upon said actual terms of execution of said order;

(n) in response to execution of orders held for internal execution, allocating proceeds from said orders held for internal execution pro rata among said individual buy or sell orders comprising said orders, wherein said allocation is based upon said actual terms of execution of said aggregated order;

(o) receiving clearing and settlement information of said aggregated unit- denominated order; (p) debiting and crediting said transaction accounts to reflect clearing and settlement of said individual buy or sell orders, (q) providing trade execution information of said transaction request to said requesting party;

(r) routing said trade execution information for position maintenance and reporting; and (s) routing clearing and settlement information for position maintenance and reporting.