WO2004019174A2

WO2004019174A2 - Systems for managing transactions in depositary receipts

Info

Publication number: WO2004019174A2
Application number: PCT/US2003/026357
Authority: WO
Inventors: Vincent J. Fitzpatrick; James Green
Original assignee: The Bank Of New York
Priority date: 2002-08-23
Filing date: 2003-08-22
Publication date: 2004-03-04
Also published as: WO2004019174A3; AU2003258328A8; AU2003258328A1

Abstract

The present invention provides systems and methods for facilitating the fair, efficient, and economical cross-border exchange of depositary receipts (DRs) (1) and their underlying ordinary shares without the need to withdraw existing DRs or issue new DRs. Clients enter exchange orders (7) in this invention's systems which implement methods for finding pairs of orders between which DRs and ordinary shares may be exchanged. Then share exchange transactions are created for two or more matching orders, and these transactions are further processed by this invention's system and methods so that local (15, 17, 19) and non-local depositories and custodians are properly instructed and monitored to perform the required share exchanges according to their local procedures.

Description

SYSTEMS AND METHODS FOR MANAGING TRANSACTIONS IN DEPOSITARY RECEIPTS AND THEIR UNDERLYING SECURITIES

[0001] This application claims benefit of and priority to United States provisional patent application serial no. 60/405,538 filed August 23, 2002. The entirety of the disclosure of this provisional application is incorporated herein by reference for all purposes.

1. FIELD OF THE INVENTION

[0002] The systems and methods of the present invention provide enhanced and economical services for the exchange of depositary receipts and their underlying shares; in particular the systems and methods provided are advantageous for depositary banks, broker/dealers, and similar agents and financial institutions.

2. BACKGROUND OF THE INVENTION

[0003] Depositary Receipts (referred to herein as "DRs") are financial instruments that are issued and negotiable in a particular financial market (referred to herein as the "DR home market " or the "DR market") and that represent the right to receive delivery of a specified number of the underlying securities of a specified issuer. The underlying securities are issued and negotiable in their own financial market or country (referred to herein as the "underlying securities home market (or country)" or the "underlying securities market (or country"), which is usually different from the DR market (that is, the underlying securities market is "foreign" to the DR market, and vice versa). Most often the underlying securities are publicly-traded securities issued by a corporation in a market "foreign" to the DR market; and they and their DRs are denominated in the currencies of their respective (different) markets. DRs play an important role in international finance. Corporations are provided convenient access to cross-border capital markets as well as broader shareholder bases by having their DRs issued, listed, or traded in markets other than the markets where their underlying securities are listed and traded. Further, investors are provided convenient and efficient international investment opportunities by easily acquiring DRs traded in familiar markets.

[0004] DRs may be more specifically known as American Depositary Receipts ("ADRs") and Global Depositary Receipts ("GDRs"). ADRs are securities that are issued in the United States in conformity with U.S. laws and that represent the right to receive shares of non-U.S. ("foreign") corporations. ADRs are often exchange-traded, and thus effectively provide for the trading of foreign shares on U.S. exchanges. Global Depositary Receipts ("GDRs") are like ADRs except that they are generally traded on non-U.S. exchanges and in multiple markets worldwide, commonly London. Other examples of DRs include Euro Depositary Receipts and New York Shares.

[0005] DRs are issued in their DR home market by financial institutions, normally banks, that provide services such as transfer agent, custodian, issuing agent, paying or corporate action agent, or the like. DRs issued by such depositary financial institutions represent the right to receive the underlying securities on deposit with that institution under specific deposit agreements. Most often, the DR home market and the underlying securities home market are different (referred to herein as being "foreign" to each other). The underlying securities are generally physically held in their home markets by sub-custodians for the depositary institution. Accordingly, a DR-issuing depositary institution may establish subcustodian relationships with financial institutions in those foreign markets or countries where the underlying securities of its issued DRs reside. Custodian financial institutions may be, for example, a foreign branch of the DR-issuing depositary, or an affiliated financial institution, or a correspondent financial institution, or the like.

[0006] Consider a hypothetical example of ADRs for ABCD Holdings pic ("ABC"), assumed to be a U.K. corporation, issued in the U.S. by an ADR-issuing bank. Generally, each ADR of a corporation represents the right to receive a fixed, proportional number (known as a "ratio") of that corporation's underlying shares. Assuming for this example that the ratio is five underlying ABC shares for each ABC ADR share, in order to issue, for example, one million (1M) shares of ABC's ADRs, five million (5M) of ABC's underlying U.K. shares must first be deposited with depositary or with its custodian agent in the U.K. Once the U.S. depositary receives confirmation of this share deposit, it will proceed to issue the additional ABC ADRs. On the other hand, in order to withdraw or cancel 1M of ABC's ADR shares from circulation, these ADRs must be returned to the ADR-issuing bank or depositary. Upon receipt of the ADRs, the U.S. depositary bank will forward 5M of its deposited ABC U.K. shares as directed, instructing its U.K. custodian to make the physical transfers. The ADR- issuing U.S. bank normally charges a per share DR fee (currently 5φ) for issuing or canceling the ADR shares.

[0007] DRs and their underlying securities are actively traded in their respective markets. Therefore, from time-to-time, a broker/dealer in these securities may find itself needing possession of DRs in one market but having possession of their underlying securities in a different market (a condition referred to herein as "short" in DRs and "long" in their underlying securities). This broker/dealer may resolve its situation by depositing its underlying securities with the custodian of the DR-issuer in the underlying security's home market, and receiving corresponding DRs from the DR-issuer in the DR's home market. Conversely, if the broker/dealer were "long" in DRs but "short" in their underlying securities, it could return the DRs to the DR-issuer in the DR's market and receive the corresponding underlying securities from the DR-issuer's custodian in the underlying securities market. In either case, the broker/dealer will pay the DR-issuer's DR issuance or cancellation fees.

[0008] Moreover, it also commonly happens that a first broker/dealer finds itself "short" in a particular DR and "long" in its underlying securities, while a second different broker/dealer finds itself "long" in these same DRs but "short" in their underlying securities. If both broker/dealers become aware of their respective situations, it can be advantageous for them to swap (or "cross") their positions without using the DR-issuer as an intermediary: the second broker/dealer sells its DRs to the first broker/dealer in the DR's market; and the first broker/dealer sells its underlying securities to the second broker/dealer in the underlying securities (different) market. Such a swap between the two broker/dealers can be advantageous in comparison to both broker/dealers engaging in separate transactions with the DR-issuer at least because it avoids the DR-issuer's fees for DR issuance and withdrawal. Further, it may have tax advantages in those jurisdictions that tax conversions between DRs and their underlying securities. For example, the U.K. has a stamp tax of 1.5% of the value of underlying U.K. securities converted into DRs.

[0009] However, such a swap has significant disadvantages. For each swap, broker/dealers must settle two transactions, a sale and a purchase of DRs in their market and a sale and a purchase of the underlying securities in their different market. Further, each swap requires a foreign exchange transaction, as the sale proceeds in one home country must be exchanged for the purchase funds in the other home country. Also, this swap takes at least 3 days to close because each trade must settle in accordance with normal conventions in the relevant home market. This delay increases the length of time that broker/dealer long/short positions need to be maintained, thereby adding to their carrying costs and fragmenting their liquidity.

[0010] And equally important, there is no efficient, confidential mechanism for a broker/dealer to become aware of the situations of other broker/dealers in order to arrange such a swap. Certain individuals, known as inter-dealer brokers ("IDBs") attempt to promote this process by continually polling broker/dealers during the business day for their DR transaction needs, and matching any corresponding needs. But the IDB process is cumbersome and inefficient. It relies on polling the active broker/dealers throughout the business day to determine their current DR transaction needs. This polling is often repetitive and distracting, because several IDBs are competing for the same business and seeking the same information. Further, because the LDBs do not maintain a central pool of available DR transaction information, client broker/dealers must maintain relationships with several IDBs and can never be sure that they are entering into the best swap transaction currently available.

[0011] Thus there is a need in the art for an efficient, low cost, rapid process by which broker/dealers can exchange DRs for their underlying securities.

[0012] Citation or identification of any reference in this section or any section of this application shall not be construed that such reference is available as prior art to the present invention.

3. SUMMARY OF THE INVENTION

[0013] Objects of the present invention include overcoming these deficiencies in the prior art by providing efficient, low cost, rapid processes by which broker/dealers can exchange DRs and their underlying securities.

[0014] The present invention provides many advantages including the following. Transaction risks and costs are reduced because the provided systems and methods can act as the central clearing party which substantially minimizes or eliminates fees for DR issuance and withdrawal. Further, in certain jurisdictions there may be tax advantages. Transaction settlement processes are improved because the central secure clearing party provided by the present invention can manage share delivery in a flexible timeframe and permits settlements free of cash payments because separate sale and purchase transactions are eliminated. Finally, especially when implemented by a depositary financial institution, such as a bank, this invention provides a global reach with a large number of participants in a large number of markets offering improved liquidity.

[0015] The systems and methods of this invention include many preferable features including the following. Concerning order processing, DR exchange orders (also referred to in the following simply as "client orders", "exchange orders", or "orders") are time stamped upon entry into the systems of the present invention and then stored in a database of open orders. Periodically, order matching methods examine open orders present in the system to find groups of "matching" orders, where two or more orders form a matching group if they all concern the same DR, if some orders seek DR shares, and if others seek shares of the underlying securities. Importantly, these matching methods implement the DR swap marketplace in a fair and efficient manner. In a preferred embodiment, fairness is achieved by selecting open orders for matching on a first-come-fist-served basis in the order of their time stamps. Efficiency is preferably achieved by reasonably and substantially minimizing the number of settlement transactions required by selecting groups with a reasonable and substantial maximum number of open orders. Efficiency is also achieved by processing open orders in minimum-sized increments as exchange opportunities become available. Further, most clients wish to perform exchanges anonymously to protect their business, it is also important that order processing and matching preserve client anonymity. This is achieved by implementing the methods of this invention in a central serves according to best security practices and by use of secure, encrypted communications. Optionally, open orders (or at least client identification) can be encrypted with keys and other decrypting information under strict procedural controls.

[0016] Also the systems and methods of the present invention preferably present a simple and flexible interface for client users. First, the system interface is preferably customizable at several levels, including customizations representing procedures that a particular client financial institution, such as a broker/dealer, requires of all its DR traders, and also customizations suiting individual users within client institutions. These customizations may include separating users into at least two authority classes: "traders" that enter and monitor orders; and "managers" that have approval and audit responsibilities. For example, the present invention can generate notices, for example, e-mail messages, to selected manager- class users when particular trader-class users perform some significant function, such as entering an order or an order in excess of certain amounts. Selected manager-class users may have privileged access to audit logs and trails. Further, the system may allow institutions or departments within institutions to customize their order terms according to their standard policies and procedures. Trader-class users may also customize their work by setting certain default preferences for their orders, which may of course be overridden order-by-order. The preferences include at least the ability to select lists of preferred DRs (for example, the particular DRs handled by the user), to set default order expiration periods (for example, keep each order open for three business days), to set exchange increments (for example, process this order for 1,000,000 shares in exchanges of no less than 100,000 shares), and the like.

[0017] Preferred embodiments are additionally simple and flexible by being implemented using standard Internet protocols, particularly HTTP and HTML (and extensions and follow- ons). Thus, users may access this invention using standard office computer and terminal having only a standard web browser installed. In these embodiments, there will be no software to install and maintain.

[0018] More specifically, in a first preferred embodiment the present invention comprises a system for managing security exchanges between clients, the securities exchanged being depositary receipts (DRs) and their underlying securities, wherein each DR share represents an ownership interest in a corresponding number of underlying securities of an issuer that are held in custodial institution, including: secondary memory having stored data representing client requests for share exchanges, a client request comprising a share-exchange offer to provide a specified number of DR shares and to accept a corresponding number of the underlying securities, or conversely; a processor operatively coupled to the secondary memory and configured to perform the steps of: searching the stored client requests for matching requests, wherein a first request matches a second request if (i) the first request offers to provide shares of DRs or of their underlying securities in a number and type that the second request offers to accept, and conversely, and (ii) the numbers of provided DR and underlying security shares are corresponding; and if matching client requests are found then further selecting some or all of the shares from clients with matched requests and offering to provide shares for transfer to clients with matched requests and offering to accept shares; generating instructions to the clients of the matched requests to have delivered their selected matched shares to specified system custodial accounts held in specified system custodial institutions; after receiving notification from the system custodial institutions of the receipt of the matched shares, generating first instructions to these custodial institutions to deliver the received matched shares to the clients with matched requests; after receiving notification from the specified system custodial institutions of the delivery of the matched shares, updating the matched client requests to reflect completion of the share exchange; and generating notifications to the clients of the matched requests confirming completion of the exchange of the matched shares. [0019] In aspects of the first embodiment, this invention further comprises a processor further configured to perform: generating individual share-transfer transactions for managing actual share transfers resulting from matched requests, a share-transfer transaction comprising the number and type of shares to be transferred and the status of the actual share transfer; storing the share-transfer transactions in the secondary storage; and during instruction generation and notification receipt, updating the status of the associated share- transfer transactions to reflect the status of the actual share transfer. Also in further aspects the system of the first embodiment comprises: communications facilities operatively coupling for message exchange the system processor with one of more external systems, wherein the coupled external systems are of one or more clients or system custodian institutions; and wherein the system processor is further configured to perform sending automatically generated instructions and notifications; and receiving automatically client requests and share-transfer notifications.

[0020] In a second embodiment, this invention comprises a method for managing security exchanges between clients, the securities exchanged being depositary receipts (DRs) and their underlying securities, wherein each DR share represents an ownership interest in a corresponding number of underlying securities of an issuer that are held in custodial institution, including: searching stored client requests for matching requests, wherein a client request comprises a share-exchange offer to provide a specified number of DR shares and to accept a corresponding number of the underlying securities, or conversely, and wherein a first request matches a second request if (i) the first request offers to provide shares of DRs or of their underlying securities in a number and type that the second request offers to accept, and conversely, and (ii) the numbers of provided DR and underlying security shares are corresponding; and if matching client requests are found then further selecting some or all of the shares from clients with matched requests and offering to provide shares for transfer to clients with matched requests and offering to accept shares; generating instructions to the clients of the matched requests to have delivered their selected matched shares to specified administrator custodial accounts held in specified administrator custodial institutions; after receiving notification from the administrator custodial institutions of the receipt of the matched shares, generating first instructions to these custodial institutions to deliver the received matched shares to the clients with matched requests; after receiving notification from the specified administrator custodial institutions of the delivery of the matched shares, updating the matched client requests to reflect completion of the share exchange; and generating notifications to the clients of the matched requests confirming completion of the exchange of the matched shares.

[0021] In aspects of the second embodiment, this invention further comprises: generating individual share-transfer transactions for managing actual share transfers resulting from matched requests, a share-transfer transaction comprising the number and type of shares to be transferred and the status of the actual share transfer; storing the share-transfer transactions in the secondary storage; and during instruction generation and notification receipt, updating the status of the associated share-transfer transactions to reflect the status of the actual share transfer; and where share delivery and receipt instructions are generated from information in share-transfer transactions. Further aspects of this embodiment comprise: sending automatically generated instructions and notifications to operatively coupling external systems of one or more clients or administrator custodian institutions; and receiving automatically client requests and share-transfer notifications from these external systems.

[0022] hi a third preferred embodiment, this invention comprises a system for managing security exchanges between clients, the securities exchanged being depositary receipts (DRs) and their underlying securities, wherein each DR share represents an ownership interest in a corresponding number of underlying securities of an issuer that are held in custodial institution, including: secondary memory having stored data representing client requests for share exchanges, a client request comprising a share-exchange offer to provide a specified number of DR shares and to accept a corresponding number of the underlying securities, or conversely; a processor operatively coupled to the secondary memory and configured to perform the steps of searching the stored client requests for matching requests, wherein a first request matches a second request if (i) the first request offers to provide shares of DRs or of their underlying securities in a number and type that the second request offers to accept, and conversely, and (ii) the numbers of provided DR and underlying security shares are corresponding; and if matching client requests are found, then generating instructions for causing transfer of selected numbers of shares among the clients in accordance with the offers to provide and to accept shares in the clients' matched requests; and updating the matched client requests to reflect of the share exchange.

[0023] In aspects of the third embodiment, the generated instructions cause transfer among the clients by (i) first having clients with matched requests offering shares transfer the offered shares to specified system custodial accounts held in specified system custodial institutions, and (ii) second having the system custodial institutions transfer received shares to clients with requests accepting offered shares; and the processor further performs checking that the instructed transfers have been successfully completed by receiving notifications of all share receipts and deliveries; and a client request further comprises a minimum settlement amount, and wherein a client request offers to accept or to provide shares only in a number equal to or exceeding the minimum settlement amount; and matched requests comprise a master request and at least one slave request, or a plurality of slave requests which matches the master request. Also, further aspects of the third embodiment comprises client request that include an open amount, so that the client request offers to accept or to provide shares only in a number equal to or less than the open amount, and where the processor further performs upon receipt of a client request, setting the open amount equal to the number of shares initially offered to be provided or accepted; upon updating matched client requests, subtracting from the open amount the number of shares transferred in the match.

[0024] In a fourth preferred embodiment, this invention comprises a method for managing security exchanges between clients, the securities exchanged being depositary receipts (DRs) and their underlying securities, wherein each DR share represents an ownership interest in a corresponding number of underlying securities of an issuer that are held in custodial institution, including searching stored client requests for matching requests, wherein a client request comprising a share-exchange offer to provide a specified number of DR shares and to accept a corresponding number of the underlying securities, or conversely, and wherein a first request matches a second request if (i) the first request offers to provide shares of DRs or of their underlying securities in a number and type that the second request offers to accept, and conversely, and (ii) the numbers of provided DR and underlying security shares are corresponding; and if matching client requests are found then generating instructions for causing transfer of selected nmnbers of shares among the clients in accordance with the offers to provide and to accept shares in the clients' matched requests; and updating the matched client requests to reflect of the share exchange.

[0025] In aspects of the fourth embodiment, this invention comprises generating instructions cause transfer among the clients by (i) first having clients with matched requests offering shares transfer the offered shares to specified administrative custodial accounts held in specified administrative custodial institutions, and (ii) second having the administrative custodial institutions transfer received shares to clients with requests accepting offered shares, and checking that the instructed transfers have been successfully completed by receiving notifications of all share receipts and deliveries; and client requests that further comprises a minimum settlement amount, and wherein a client request offers to accept or to provide shares only in a number equal to or exceeding the minimum settlement amount; and matched requests that include a master request and at least one, or a plurality of, slave request which matches the master request, such that among the matched requests, the master request is the earliest-received request, or a slave request is the earliest-received request and the master request is the next earliest received request. Also, further aspects of the fourth embodiment comprise client requests that further include an open amount, such that client requests offer to accept or to provide shares only in a number equal to or less than the open amounts, and including the steps of upon receipt of a client request, setting the open amount equal to the number of shares initially offered to be provided or accepted; and upon updating matched client requests, subtracting from the open amount the number of shares transferred in the match.

4. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] The present invention may be understood more fully by reference to the following detailed description of the preferred embodiment of the present invention, illustrative examples of specific embodiments of the invention and the appended figures in which:

Fig. 1 illustrates the process of exchanging DRs and their underlying securities;

Fig. 2 illustrates an exemplary system for practicing this invention;

Figs. 3A-C illustrate various exemplary user-interface screen images;

Fig. 4 illustrates the DR manager process of this invention;

Figs. 5 A-C illustrate the order manager process;

Fig. 6 illustrates the order expiration process; and

Fig. 7 illustrates the transaction expiration process.

5. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0027] In the following, preferred embodiments are described with reference to and in terms of the appended figures. Although these figures of necessity may illustrate particular embodiments and examples, such particular embodiments and examples as illustrated are for clarity and concreteness only and are not meant to be limit this invention to just these particular embodiments and examples, or in any other way. For but one example, Fig. 1 illustrates an exchange of this invention in terms of DRs issued in the U.S. and ordinary shares issued in a foreign country. One of ordinary skill in the art, would immediately understand that similar processes apply to exchanges of DRs and ordinary shares in many countries worldwide, such as the U.K. and others. Therefore, without further discussion, the following description and appended figures are to be understood as non-limiting in this manner.

[0028] Also in the following certain terms will be used with the following meanings. The systems and methods of this invention, which are embodied in computer hardware and software, respectively, are often referred to as the "DR manager systems and methods" or more simply as the "DR systems and methods". It is anticipated that the DR systems and methods will be implemented by financial institutions, such as depositary banks, and such institutions are referred to in their legal and institutional capacities as a "system administrator" or more simply as an "administrator".

5.2 SHARE EXCHANGE PROCEEDURES [0029] Fig. 1 illustrates the processes of exchanging DRs and their underlying securities and the role played by DR manager system 1, a system implementing the methods of this invention, in terms of an exemplary exchange company 1 DRs ("DRls") and the underlying securities of company 2 DRs, namely company 2 ordinary shares ("Ord2s"). For purposes of illustration, the DRls are assumed to be issued in the U.S., while the Ord2s are issued in a foreign country. Institution A 3, which may be a broker/dealer, a prime broker, a fund including a hedge fund, or other market participant, has (is "long") DRls and seeks (is "short") Ord2s and has entered an order for exchanging DRls with Ord2s into the DR manager system of this invention. Conversely, institution B 5 and possibly other institutions 5' have entered order(s) seeking DRls in exchange for Ord2s. These orders include the type and number of which particular shares are available for exchange, and preferably, also a minimum number of shares to exchange in each transaction, an expiration date, and the like.

[0030] The DR manager system accepts all entered orders, time stamps them for processing priority, and stores them in order database 7 (also referred to herein as the "order book"). From time-to-time, for example periodically (such as every half-hour, or every quarter hour, or other time interval) during business days, DR manager 1 performs an order processing procedure which includes an order matching step. Order matching is performed on a first- come-first-served basis based on the order's time stamp (determined on order entry), and is described in full detail below. Here only a brief summary is provided: first, order matching selects the oldest not yet satisfied (also referred to as "open") order; second, order matching further selects the oldest open orders, if any, that match the selected oldest order; and third, it generates messages to the clients who have entered the matching orders that confirm the match and provide full settlement instructions. An order is not yet satisfied if the remaining number of shares available or sought exceeds the specified minimum transaction amount (and if it has not expired). For two orders to match, each order must provide the shares sought by the other order; other requirements for matching are described in full detail below. If no matching orders of any age are found, order processing is complete for the moment.

[0031] Fig. 1 illustrates the further steps of order processing if matching orders have been found. First, the DR manager sends the match confirm and proceed instructions to the appropriate clients, hi some cases only a pair of orders will be found to match, and if this is the case for the example illustrated in Fig. 1, confirm & proceed messages are sent to institutions 3 and 5 only. However in other cases, two or more orders may be found that match a single selected order, and in this case, confirm & proceed messages will be sent to institutions 3, 5, and 5' of Fig. 1 (and in other examples to additional institutions). The recipient institutions then carry out the received settlement instructions by first causing the shares to be exchanged - DRls in the case of institution A and Ord2s in the case of institution B - to be delivered to the system administrator.

[0032] It is expected that these deliveries, and other share deliveries occurring during order processing, are carried out by the use of intermediary custodial institutions according to known share-handling procedures. Fig. 1 illustrates exemplary share-handling procedures for DR1 shares in the U.S. and for Ord2 shares in a foreign country. Concerning DR1 handling, it is common in the U.S. for security shares, such as DR shares, to be held by the Depositary Trust & Clearing Corporation ("DTC") as a custodian for the shares' nominee or owner. Share transfers can then be simply carried out by instructing, often by electronic means, the DTC to transfer shares from the account of the transferor to that of the transferee. Accordingly, institution A orders the DTC to transfer shares of DR1 from its DTC account 9 to DTC account 11 of the Administrator. Later, the Administrator order the DTC to transfer these shares on to DTC account 13 of recipient institution B. It should be noted that this procedure assumes all institutions A and B and the Administrator have direct access to the DTC. If this is not the case, then share transfer may need to be arranged though one or more individual custodians for these entities separately in a manner similar to that for Ord2 shares.

[0033] Now concerning Ord2 handling, it is also common in foreign countries for shares of local securities, especially shares owned by non-local entities, to be held by a local custodian, such as a local depositary bank, either directly or through a local share clearing corporation. Generally, it may turn out that institutions A and B and the Administrator may use different local custodians, for example, local custodians A 15, B 17, and C 19. Here, it is necessary that each entity order its own local custodian to transfer shares on to the local custodian of the next entity: institution B orders its local custodian A to transfer Ord2 shares to local custodian B of the Administrator, who in turn orders local custodian B to transfer share on to local custodian C of institution A. These local custodians carry out actual share transfer according to local customs and procedures.

[0034] Fig. 1 further illustrates that share handling for order processing performed by DR manager 1 centrally coordinates these transfers. After the DR system has instructed the participating institutions to deliver their offered shares and to expect receipt of their sought shares (and other settlement instructions), the clients instruct their custodians, the DTC in the U.S. and the local custodian A in the foreign country, to deliver shares to the respective accounts of the system administrator. The DR system has also instructed (via messages 21) its custodians, the DTC and local custodian B to expect delivery of these shares, and is notified upon the receipt of the DR1 and Ord2 shares. Once the DR system receives notification that both DR1 and Ord2 shares have been received into the system administrator accounts, it then instructs (again via messages 21) these custodians to transfer these shares on to their final recipient custodial accounts at the DTC and local custodian C. Finally, upon confirmation of these last deliveries, the DR system considers match processing complete.

5.3 SYSTEMS AND INTERFACES SYSTEMS OF THE INVENTION

[0035] Fig. 2 illustrates an exemplary computer system suitable for performing the methods of this invention. One of ordinary skill in the art will appreciate that alternative system configurations known in the art also suitable for this invention and be able to routinely implement such alternative configurations. Computer 31 is a standard computer with processor, primary memory, controllers, and the like of adequate capability for processing the expected transaction loads generated by this invention's clients. Preferably, this computer has sufficient reliability and security for real-time financial processing. Order information and other databases are stored in secondary memory 33 that is linked to computer 31. This memory also stores programs that cause the computer to perform this invention's methods. Also linked to computer 31 are administrative/operations interfaces 35, which may be standard PCs or terminals, that permit operations personnel to monitor order and transaction processing, to handle exceptional conditions, to monitor the system itself, and the like. System elements 31, 33, and 35 are preferably physically configured to prevent unauthorized intrusions that might compromise the financial integrity of share exchange processing, the anonymity of clients, and the like.

[0036] Client users, traders, managers, and others, may access the DR system by means of terminals 37, which may be standard office PCs, trading workstations, or the like. In preferred embodiments, this system uses standard Internet protocols including HTTP/HTML and terminals 37 need only provide standard web browsers. No special software would then be needed. Communications links 39 between the user terminals and the DR system may be implemented in various ways, hi an Internet-based embodiment, these links may be the Internet or an intranet with a, preferably, encrypted transport protocol. Alternatively, these links may be dedicated lines or part of an existing financial network. In some embodiments, messages to users generated by the DR system may be sent as system generated E-mails using standard E-mail servers.

[0037] The DR system preferably communicates with systems at other financial institutions 41. As already discussed, the institutions preferably include client systems, DTC systems, systems at local and foreign custodians and sub-custodians, and the like. Communications links 43 are sufficiently secure and reliable for transmission of financial instructions. In one embodiment encrypted communications over the Internet or an intranet may be used, hi further embodiments, financial instructions may be transmitted as known in the art over a pre-existing public financial networks, such as Fed Wire, CHIPS, or SWIFT, or a private network. In alternative embodiments, the DR manager may interface directly with client "back office" systems in order to facilitate automatic settlement. Finally, in simple embodiments, financial instructions and the like may be sent to these other systems by E- mails in standard manners. INTERFACES OF THE INVENTION

[0038] The interfaces of this invention are preferably implemented with a graphical user interface presenting screens adapted to the moment-by-moment needs of the users. In one embodiment, screens are coded in HTML (or extensions and follow-ons) and presented by a standard web browser. An embodiment will typically present several types of screens directed to particular user functions, for example, a login screen, a home screen-order maintenance screen, an order entry screen, an order status screen, an alert history screen, a preferences screen, a market information screen, a contact screen, a billing screen, and a logout screen. A login screen may provide for entry of user identification and authentication to initiate a user session, and of course the logout screen ends the user session. The home screen-order maintenance screen is the first screen presented to the user upon session initiation and advantageously may present summary order and alert information that is presented in full by subsequent screen along with open order of interest to the user. The order entry screen facilitates order entry, and the order status screen present status of all orders, or of all order meeting certain criteria, or the like. This screen may illustrate the progress of order satisfaction. The alert history screen presents all alerts for this trader, such as alerts that orders have matched, that order are soon to expire, that order fulfillment and share delivery are expected, that orders have been cancelled, and so forth. The preferences screen allows the user to set defaults for common fields in order to simplify system use. The market information screen may provide market information, relevant news, and the like. The contact screen may direct users to contacts who can supply help and other general information as well as presenting general system information, Finally, the billing screen presents the current and past fees for matched transactions and other system services.

[0039] Figs. 3A-C illustrates the important exemplary screens, namely screens for preferences, order entry, and home-order maintenance, for an implementation directed to ADRs. A preferences screen, illustrated in Fig. 3A, includes standard features such as system logo 51, user identification 53, and addresses 55 accessing other screens for this user. A preferred embodiment includes three classes of user preferences, preferred DRs, order defaults, and an E-mail copy list, which may be set by activating button bar 57. Selection of a user's preferred DRs of interest is illustrated. These DRs may be selected by filtering and searching the entire universe of DRs exchangeable on a particular embodiment by means of search keys entered in one of more of the fields 59 for geographical region of incorporation, country of incorporation, type of industry, specific corporation name, CUSIP identification number, and ticker symbol. Alternatively, preferred DRs may be selected from pick-list 61. List 63 displays the current preferred DRs. Order defaults that may be set include expiration interval, for example, three to five business days, the minimum number of shares to exchange in a single transaction, and the like. Finally, each user has an E-mail copy list with addresses of other users, typically managerial or supervisory personnel, or auditing staff who monitor individual trader activity.

[0040] Fig. 3B illustrates an order entry screen which includes the previous standard elements as well as new fields defining a new order. A user must first select the order's requested DR (or underlying share) by either searching after entering search keys in one or more of fields 65 or by picking from pick-list 67 which has been set up as one of the user's preferences. Next, the user must select the order type from pull-down list 71 as either requesting DRs while providing ordinary (or underlying) shares ("Ordinary to ADR") or vice versa ("ADR to Ordinary"). The amount of DRs requested is entered in field 73, and then using the current DR/ordinary-share ratio, the system automatically provides the equivalent amount of underlying shares in field 75. Certain embodiments may establish a mimmum order size. The order's expiration is selected from pull-down list 77, which initially presents the user's pre-selected default expiration. Also, certain embodiments may limit the expiration period to, for example, five business days in order to prevent accumulation of stale order in the system that might give an unrealistic picture of the system's current share liquidity. Field 79 displays the user's pre-selected minimum transaction size, which may be altered order-by- order. Once these fields the user may submit the new order. Order submission may generate confirming alerts, E-mails, and print outputs.

[0041] Finally, Fig. 3C illustrates a home-order maintenance screen to which the user is first directed upon session initiation and which preferably presents useful summary information concerning the user's account status. In the illustrated embodiment, this screen is divided into three regions: an "order book" region, an account alert region, and a pending orders region. The order book region identifies all client orders pending in the system by DR name, ticker symbol, CUSIP identifier, and type ("Ordinary to DR" or "DR to Ordinary"). To preserve anonymity and fairness and prevent strategic behavior, the order book does not include the client originating the order nor the order amount. The account alert region includes recent important messages from the DR manager system to this user. Alerts may include, for example, that a user's order is about to expire, is expired, or has been canceled by the system, that a user's order has been partially or fully matched; that a user has not fulfilled an order's delivery obligations, and the like. Each alert may include links to full alert details; a listing of all alerts may be presented by the alert screen. The order status region include some or all of a user's pending orders. Order information includes a system generated order number, the ticker symbol of the DR with which the order is concerned, the order's type ("Ordinary to DR" or "DR to Ordinary"), the order's expiration date, and the quantity of shares as original entered. Order information also includes the open amount, which is the number of originally requested shares not yet made available by system matches. Pending orders may often have open amounts because the match methods try to satisfy an order incrementally if insufficient shares are available to completely satisfy the order. A completely satisfied order will have an open amount of 0 The pending order information may include links to full order details; a listing of all orders may be presented by the order status screen.

[0042] More complete order information available on order status screens may include order status (such as pending, share exchange in progress, completed, and the like), the status of a pending exchange (such as shared delivered but not yet received, and the like), billing data, and so forth. Also, order status screens may provide the ability, for pending orders only, to modify or cancel the order. Further screen may provide analytic market information.

[0043] In additional the user interfaces just described, this invention preferably provides screen-based administrative interfaces 35 (Fig. 2). i certain embodiments, certain portions of the invention's processing may require interfaces to other financial systems that require some degree of manual intervention. This may be likely in, for example, the processing of share transfer orders to non-local custodians and then receiving their transfer notifications. , may required manual intervention. Such manual steps can be accomplished using the administrative interfaces. Also, dual-control of important financial processing functions may be desirable and may be provided by these interfaces. Also, administrative system control function are desirable and may be provided. For example, from time-to-time the invention's processing of certain issues or markets may need to be suspended. Further preferably administrative functions include record keeping, accounting, auditing, and the like. Finally, handling special situations or exceptional conditions will typically require examination and update of system records by the operations staff. These can include resolving unauthorized or unaccounted for account balances, share positions, and the like. 5.4 METHODS OF THE INVENTION

[0044] For orderly description, this invention's methods may be divided into operations methods, order matching methods, and special-situation handling methods. Briefly, operations methods, illustrated in Fig. 4, receive and store order, search for matching orders, and supervise in detail the processes of cross-border share exchange already summarized with respect to Fig. 1. Order matching methods, illustrated in Figs. 5 A, 5B, and 5C1-3, generate matches of order in the order database. Finally, special-situation handling methods, illustrated in Figs. 6 and 7, perform generally cancellation, expiration, and exception processing tasks.

OPERATIONS METHODS

[0045] Fig. 4 illustrates in detail preferred operations methods of this invention. As can be immediately appreciated, these methods send and received instruction and status messages from numerous entities, including for example, client users and local and foreign depositary, trust, and custodian institutions. In preferred embodiments, the operations methods process these messages in a largely (e.g., messages occurring during normal processing) or substantially completely (e.g., also message occurring during special-situation handling) electronic and automatic manner. (Those messages not automatically processed will require a greater or lesser degree of manual processing.) In these embodiments, automatically- processed messages are exchanged across national and international financial networks, such as Fed Wire, CHIPS, or SWIFT (or a private network accessible to the DR manager systems), with the operations methods automatically generating most outgoing messages, and automatically recognizing and interpreting most incoming messages ("straight-through processing"). Fig. 2 illustrates an exemplary system suitable for automatic message processing embodiments. There the DR manager systems are directly and electronically connected both to client users and to the depositary, trust, and custodian institutions that hold the client shares to be exchanged. Further, in cases of foreign countries with sufficient local financial infrastructure, it may be possible to complete an order match without any exchange at all of physical share certificates.

[0046] However, this invention also includes alternative embodiments where message require more or less manual processing. For example, a person may need to recognize and translate certain incoming messages so that they may then be entered into the DR manager systems for processing. Similarly, a person may need to format certain outgoing messages from information presented by this invention's systems. Also, in many foreign countries it may be necessary to transfer by messenger physical share certificates in order to complete order- mach processing.

[0047] Returning to Fig. 4, the operations methods illustrated therein will be described largely in terms of automatic processes with the understanding that a greater or lesser number of these processes may involve manual elements in various embodiments. The methods of Fig. 4 are periodically entered 91, for example, daily at the close of business, twice during the business day, hourly, quarter-hourly, or on an as-needed schedule. After entry, these methods first perform order-match processing 93 with reference to database 95 of orders, into which new order have been stored since the last execution of these methods. As described subsequently, match processing, first, identifies two or more orders among which a share exchange is possible, and then second, creates share-exchange "transactions", which preferably are data structures used to manage each share exchanges for the matched orders. For example, transaction data includes a unique identifier (TRN field), an identification of the associated order (Ordld field), the name (DR field) and amount (TA field) of shares to exchange, a status (ST field), and so forth. During operational processing, the transaction status, ST, is updated to reflect to progress of causing TA number of DR shares to be transferred as specified in order Ordld. The unique identifier TRN can be used during processing to link actions taken by local and foreign institutions to the transaction for which they have been ordered. At least two functionally distinct transactions may be associated with each order participating in a match: one transaction describing shares to be received by the Administrator from the client who submitted the order; and a further transaction describing shares to be delivered by the Administrator to the client. This latter delivery transaction may also be viewed as the onward delivery of shares received by the Administrator for another participant in the match. In preferred embodiments, a separate transaction data structure is generated for each of these two transactions; in other embodiments, the data defining the two share exchange may be packaged in a single data structure, such as for example, a linking a receive transaction with the transaction representing the received shares onward delivery.

[0048] Matches or current orders may or may not be possible 97. If no matches are possible 97, left branch is taken and performs special-handling processing, primarily order-expiration processing 101 and transaction expiration processing 103 (both described subsequently). Next DR manager system liquidity information, which includes primarily the total amount of each type of DR or ordinary currently offered in the system, is updated 105. Clients may be attracted to an exchange system offering significant liquidity in a wide range of shares, because it suggests they will be more likely to achieve the share exchange goals here than elsewhere in systems with more limited liquidity. Then current round of operation processing exits 107 to begin again as scheduled.

[0049] If matches are possible 97, the right branch is taken in order to supervise processing steps 109, 111, and 113 for the new share-exchange transactions generated for the matches just found. First, at least one message is generated and sent 109 to each client who entered an order participating in the match. A message to a client includes, at least, the following information: identification and number of the shares and DRs to be delivered to the Administrator of the DR system; delivery instructions including identification of the Administrator's custodian, sub-custodian, or DTC (in the U.S.) accounts to receive the shares; the unique TRN identifying the transaction (and indirectly the order) originating these share deliveries; match date and required settlement/delivery date; and so forth. The client is instructed to have his depositories and custodians include the TRN on all share transfer to the administrator. Share identification here, and throughout this invention, is assumed to utilize art-recognized standards, such as CUSLP number (for U.S. shares) and CSIN or IS IN number (for non-U.S. shares). Settlement is required a few business days, typically two, after the match date. These messages may be sent by e-mail, by (automatically-generated) phone mail, by instant messages, by private inter-institutional message services, and the like. Finally, processing 109 will update the ST field of the transaction to "Receive Open".

[0050] Next, system liquidity will be updated 111 (similarly to 105) to reflect the shares committed by the new match. Using transaction data, the last new-transaction step 113 generates and sends instructions (in the alternative manners already described above) to the institutions holding the Administrator's custodian, sub-custodian, or DTC accounts, to which client shares are to be delivered, to expect delivery of these shares by the settlement date. To the extent possible, automatically generated instructions are preferably based on standard settlement instructions stored in system databases. Receipt, delivery, and other instructions may be generated by inserting values (such as share identification and numbers) for variables in order formats appropriate to particular institutions or countries. The processing methods will now update the transaction ST field to "Receive Pending". [0051] The next processing step 115, which processes notifications of client-share delivery into the DTC and custodian accounts (from the institutions holding these accounts), may not occur for some time, at least hours and up to one to a few days, after the prior step 113, which sent the receive instructions. This time delay until the receipt notifications for this new transaction are received is indicated by flex-arrow 114. Also, since transaction-processing events for already-in-process transactions may occur and be received by the DR manager system at any time, transaction processing may also be entered to process just-received transaction events and notifications. Accordingly, when a transaction event is received 99, processing may be entered to handle it, at 115 if the event is a receipt notification and at 123 if the event is a delivery notification. (Although not illustrated, transaction-event processing may exit without causing a new match to be performed.)

[0052] Turning to step 115, once a share receipt notification is received, it is checked and matched with pending transactions. To fully match a pending transaction, the received shares preferably will have the same share identification and share number as specified in the transaction and the TRN accompanying the received shares must match the TRN of the transaction. Further, the pending transaction preferably will have a "Receive Pending" status. In preferred embodiments, this matching may be done automatically. In order embodiments, operations staff, upon receipt of shares, may access the DR manager system, and match the received shares with their transaction number and mark the specific the shares as received by use of the administrative interface. The status of the fully matching transaction is then updated to "Receive Complete". If the receipt notification does not fully match any pending transaction 117, or describes entirely unexpected shares, exception processing 119 commences. Such processing is largely manual and may involve tracking down the source of the received shares, conferring with their originator, returning of otherwise disposing of the shares, and so forth.

[0053] Once, correct receipt notifications are received for all the transactions associated with a match, the operational methods proceed to generate 120 delivery instructions according to the previously generated transactions describing the onward delivery of the received shares. These instructions include identification of the Administrator's custodian, sub-custodian, or DTC (in the U.S.) accounts from which the shares are to be sent; the client's depositary or custodian accounts to which the share are to be delivered; the identification and number of shares to be delivered; the unique TRN identifying the transaction originating these share deliveries; and so forth. The Administrator also instructs its depositories and custodians to include the TRN on these all share transfers. These messages may be sent 120 as previously described, for example, by means of the SWIFT network, the transaction ST field will be updated to "Deliver Pending". Next, expect-delivery instructions are generated and sent 121 to each client having orders participating in the match These messages include, at least, the following information: identification and number of the shares and DRs to be delivered by the Administrator of the DR system to the client; delivery instructions including identification of the Administrator's custodian, sub-custodian, or DTC (in the U.S.) accounts from which the share will be delivered; the unique TRN identifying the transaction originating these share deliveries; match date and delivery date; and so forth. These messages may be sent as previously by e-mail, by (automatically-generated) phone mail, by instant messages, by private inter-institutional message services, and the like. Finally, the transaction ST field will be updated to "Deliver Open".

[0054] Similarly to processing steps 113 and 115, the next processing step 123, which processes notifications of Administrator-share delivery into the client depositary and custodian accounts, may not occur for some time, at least hours and up to one to a few days, after the prior step 121, which sent the receive instructions. This time delay until the receipt of delivery notifications is indicated by flex-arrow 122. Also, since such transaction- processing events may occur and be received by the DR manager system at any time, transaction processing may also be entered to process just-received transaction events and notifications. Accordingly, when delivery notification is received 99, processing may be entered to handle it at 123.

[0055] Steps 123 and 124 are similarly to previous steps 115 and 117. Once share delivery notification is received, it is checked to determine if it fully matches a pending transaction by preferably having the same share identification and share number as specified in the transaction and a matching TRN. Further, the pending transaction preferably will have a "Deliver Open" status. In preferred embodiments, this matching may be done automatically; in order embodiments, it may require manual actions by operations staff. Status of the fully matching transaction is then updated to "Deliver Complete". If the receipt notification does not fully match any pending transaction 124, or describes entirely unexpected shares, exception processing 119 commences. Such processing as before may be largely manual and may involve tracking down the source of the received shares, conferring with their originator, returning of otherwise disposing of the shares, and so forth.

[0056] An ultimate step in normal operations processing concerns determining and updating client charges and fees 127 in view of the characteristics of the just completed match and associated share transfers. Basic fees may be simply a flat per-share rate, for example, 1-2 , for all transactions above the minimum accepted. Alternatively a sliding fee scale may be imposed. Also, fees rebates, discounts, surcharges, and the like may be imposed in manners known in the art to encourage particular client behavior. For example, certain discounts may be provided new clients. Similarly, sliding fees may be imposed to encourage increased or decreased trading in particular shares. The user and client interfaces may be designed to highlight the availability of incentive offers. For example, the system may send incentive messages, highlight certain fields or shares, provide links to offer details, and the like.

ORDER MATCHING METHODS

[0057] The operations methods described with respect to Fig. 4 make use of certain component methods, including order matching methods 93 and special-handling methods 101 and 102. Considering first order matching methods, the steps and step order of a particular (but not unique) and preferred implementation are illustrated in Figs. 5B-C. Description of this exemplary, preferred implementation is facilitated by consideration of general preliminary details illustrated in Figs. 5A1 (exemplary data areas), 5A2 (exemplary test for order matching), and Fig. 5 A3 (exemplary arrangement of matched orders).

[0058] Generally order matching methods search for and match not yet fully satisfied orders in the order database and then create transactions representing the share transfers and exchanges needed to perform the match found. These transactions may be stored in the order database and are then performed by the above-described operations methods. Both orders and transactions are represented by defining parameters among which are those illustrated in Fig. 5A1 grouped into their respective data areas 177 for orders and 179 for transactions. As known in the art, the structures holding these parameters may be implemented as structured data, as database records, as objects, and so forth. Order parameters 177 preferably include a system-generated identifier (Ordld), a system-generated date and time when the order was entered in the system (Odate/time). The remaining are client entered or derived from client entries(see, for example, the fields illustrated in Fig. 3B). The expiry date/time is the date and time of client-requested order expiration. The order type (TY) is either an exchange of ordinary shares for DRs (Ord-> DR) or vice versa (DR->Ord). The shares to be exchanged are identified by their DR name (DR). Next of initial number of shares the client wished to exchange is the amount field (A). Since an order may be matched several times, each match exchanging an incremental number of shares, the open amount (OA) specifies the number of shares of the original amount remaining to be satisfied. The minimum settlement amount (MSA) is the smallest number of shares the client (or the system) with exchange in one settlement transaction. These parameters are not exhaustive or limiting, and additional parameters, such as administrative parameters identifying the client, the client user, and so forth, may be advantageous in various implementations.

[0059] Next, transaction parameters 179 are generated by the order matching methods. These may include, but are not limited to, a unique system-generated identifier (TRN) and the identifier (Tordld) of the order from which the transaction was generated. Next, the shares to be exchanged are identified (Tshare) by name and type (ordinary or DR), and the number of shares to transfer by amount (TA). The source and destination addresses provide information, perhaps in association with other system databases, indicating the source and destination account numbers, custodian or sub-custodian or depositary mstitution, standard settlement instructions and means, and so forth. Finally, the expiry date/time is a system- generated date and time within which the client must complete the transfer.

[0060] Fig. 5A2 lists important tests 181 used to identify matching orders, namely whether order X matched order Y. These tests are easily expressed in terms of the parameters illustrated in Fig. 5A1, where individual parameters of orders X and Y are denoted by the standard notation X.Parm or Y.Parm, respectively. First, both order must refer to the same shares, or have equal (=) DR fields. Also, if one order requests Ords for DRs, then the other order must request DRs for Ords, and vice versa. Thus the two order TY fields must be opposite (<>). Having met these tests, an exchange may only occur if each order still seeks a number of shares greater than the other orders minimum settlement amount. Thus, order X's OA must be equal to or greater than (=>) order Y's MSA; and order Y's OA must also be equal to or greater than order X's MSA. Finally, if at least these criteria are met, then a number of shares may be exchanged between the orders that equals the minimum of both order's open amounts.

[0061] Finally, Fig. 5 A3 illustrates preferred output of the order matching process. This process has goals of fairness and efficiency. In one preferred embodiment, an important aspect of fairness has been found to order processing on a first-come-first-served basis. First- come-first-served processing without discretion is known in the art to limit or eliminate favoritism to particular client or shares, and thereby provides confidence to clients that they will be equally treated. In other embodiments, other aspects and modifiers of fairness may be important and incorporated in selection of orders for processing. Further, in another preferred embodiment, it has been found that efficiency is promoted by minimizing the number of share exchange transactions, which in turn occurs if the matching methods construct matches that link one order with as many other order as possible. Again, in other embodiments, other aspects and modifiers of efficiency may be important in match construction. In the following, a single embodiment is described that implements both the preferred fairness and the preferred efficiency, although other embodiments may implement one goal, or the other goal, or neither goal, or other approaches to these goals, and so forth.

[0062] Accordingly, Fig. 5 A3 illustrates that a match always links for share exchanges single "master order" 183 with single "first matching order" 184. However, a preferred match efficiently links for share exchanges "master order" 183 with a plurality of additional matching orders 185, if such additional matching orders can be found in the order database. The illustrated match is fair because the master and first orders are the "oldest" (meaning first entered in the DR manager system) orders in the system the match for an exchange of their particular shares. Note that in the case of a master order linked to a plurality of slave orders, it may be advantageous to create a single share-transfer transaction from the master order to the several destinations of the several slave orders, instead of multiple master transfer transaction, each to one of the slave orders.

[0063] Now, Figs. 5B-C illustrate an exemplary matching process in terms of the background presented in Figs. 5A1-3. Order matching processing enters 131, retrieves the oldest order 133 (referred to herein as orderl) in order database 135, and exits 137 if all orders have been examined, hi this embodiment, the order matching process is called from operations processing (93 in Fig. 2). Next, steps 139, 141, 143, 145, and 147 perform certain validity testing on orderl. If the open amount of orderl is less than its minimum settlement amount 139, then this order cannot be further matched, and messages are generated and sent to the client 141 indicating that this order cannot be further satisfied and is being cancelled. Since orderl cannot be further processed 143, the matching method seeks the next oldest order in the order database. Also, the number of ordinary shares represented by a single DR share may change from time-to-time 145. If this has happened since orderl was entered in the database, the order may have an unexpected outcome for the client. Accordingly, it is marked cancelled 147, appropriate messages and generated and sent to the client 141, and matching processing seeks the next oldest order 143 since orderl cannot be further processed.

[0064] Next, the order database is searched for the oldest order matching orderl (referred to herein as order2) using tests described with respect to Fig. 5A2. Again, if no matching order2 is found, orderl cannot be further processed 143, and the matching method seeks the next oldest order in the order database. If a matching order2 is found, it will be readily apparent that steps 153, 155, and 157 perform a conventional process of setting the master order to either orderl or order2, whichever has the larger open amount. An temporary order, orderX, used to facilitate subsequent description of searching for additional matching orders, is then set to either orderl or order2, whichever has the smaller open amount. With reference to Fig. 5A3, this new master order is "master order" 183; and "first matching order" 184 is the order that is set to temporary orderX. Subsequent steps of the matching method then search for "additional matching orders" 185. In the following the orders matching the master order may be referred to as "slave orders".

[0065] Next. Fig. 5B illustrates the processes of creating share exchange transactions and of searching for additional matching orders. Initially, a temporary master transaction (TRN- TM) is created 159 in which to accumulate share transfer amounts from the master order. Steps 161, 163, and 165 then create and update transactions and update orders. Step 161 creates a share exchange transaction (TRNX) for transferring share from orderX (which may the first matching order or an additional matching order) to satisfy the master order. TRNX's open amount is set to the entire master order open amount if orderX's open amount is greater; otherwise it is set to orderX's open amount since it is less than the master order open amount. Other fields of TRNX are set according to their definitions. Step 163 then updates orderX by decreasing its open amount by the number of shares to be transferred by TRNX. Step 165 first updates TRN-TM with the number shares to be transferred to orderX, which of course equals the number of shares to be transferred from orderX by TRNX (or that number times or divided by the DR/ordinary ratio). It is also necessary to record orderX's destination address in a multiple-destination TRN-TM, or to create multiple TRN-TMs for each additional order. This step It also updates the master order by decreasing its open amount by the number of shares to be transferred from orderX by TRNX. [0066] The order matching processes now check whether the master order open amount is less than its MSA 167. If so, no more matches to this master order are possible. It not, the order database is searched for an additional matching order 169. If a new, matching orderX is found, then steps 161, 163, 165, and 167 are repeated to create and update the necessary transactions and orders as for the first orderX for the first matching order. If no more matching transactions are found, again no more matches to this master order are possible.

[0067] Finally, if no more matches to the current master order are possible, its processing is completed by creating a final master-order transaction 171 and sending the transactions created to the master order and all matching orders for operations processing 173. Where a plurality of matching transactions are found, the master transaction may be either a single multiple-destination or a plurality of single-destination transactions. The order matching process then returns 175 to Fig. 5B to see if there are more transactions that may be matched.

SPECIAL-SITUATION HANDLING METHODS

[0068] In addition to unexpected and exceptional events, two special-situations may occur during the processes of this invention: order expiration, and client failure to perform. Preferred handling of these special situation is illustrated in Fig. 6 and in Fig. 7, respectively. It is to be understood that in further embodiments additional procedures may be provided to handle additional types of special situations.

[0069] Fig. 6 illustrates a preferred order expiration process, which typically enters 191 from the operational methods (101 in Fig. 4) and exits 199 back to these methods upon completion. Expiration processing retrieves all orders 191 in order database 192 and tests their expiration date and time fields (Edate/time) against the current date and time. If a retrieved order will expire on the next business day 195, a warning message is sent to the client. This message may be sent as an alert message presented in the user interface screens, as an e-mail, or by other appropriate means. It a retrieved order has already expired 194, it is updated by setting the total share transfer for the order to be the original order amount minus the current open amount, and by then setting the current open amount to zero shares; the order is next marked as cancelled. The client is notified of the order cancellation and of its cancellation status in a message, such as an alert message or an e-mail as for warning messages.

[0070] Next, Fig. 7 illustrates the general nature of processing if one or more clients to a match fail to deliver shares as required by the methods of this invention. Here, the failure of one party to a match is illustrated and described; handling of situations where two or more parties fail will be readily appreciated from this basic description. In detail, orders from client A 207 and client B 209 have been matched by the above-described match process 205, which has resulted in the generation of at least two share transfer transactions, TRN-A directed to client A and TRN-B directed to client B. Initially, both the status of both these transactions is set 211 and 219 to "receive pending". It is then assumed that client A delivers the required shares, whereupon TRN-A is updated 215 in order database to a status of "receive complete".

[0071] However, client B is assumed not to have delivered the required shares in allowed time period, and TRN-B is therefore updated 221 in order database 223 to a status of "receive failed". Determination of transaction expiration is preferably an automatic process entered from the operations processing methods (103 in Fig. 4). Although not illustrated in detail, this transaction auto-expiration process like the order expiration process scans the order database for any transaction having an expiration date and time that is prior to the current date and time (its creation time plus the auto-expiration delay exceeds the current time). Such a transaction is updated to "receive failed", and any corresponding or counter transactions are updated to "on hold".

[0072] Preferably, further automatic processes (separate or sequential with the auto- expiration process) scan the order database for "on hold" transactions 225 or "receive failed" transactions 241. If a "receive failed" transaction is retrieved 241, its termination processing 243 sends the originating client a message (alert, e-mail, or other) informing of the delivery failure and indicating a failure fee, or "fine", will be applied to its account. The fee or fine preferably at least covers the expected costs to the system Administrator of responding to the client's failure. Often these costs will include the costs of issuing or withdrawing a number of DRs equivalent to the size of the client's failure. For most DR orders, this is currently -6 per share. Additionally, the fee or fine may include an appropriate punitive amount or an appropriate punitive action taken with respect to the client. Also, client B's order is updated to back out the effects of the failed transaction (this order had been updated upon transaction creation assuming the created transaction was successfully performed).

[0073] If an "on hold" transaction is retrieved 225, the methods first check 227 whether the Administrator is in a position to accept the shares already received from the client and to make good the corresponding return share exchange. This may happen in several situations and be offered only to favored clients. For example, the Administrator may be the depositary for the DRs involved in the match and may therefore simply withdraw or issue DRs are necessary to complete the transaction. Also, the Administrator may be or be associated with a broker so that it can request share dispositions and delivery on its own behalf. If delivery is possible and elected, these special-situation handling methods perform the acts necessary to complete the client transaction. A new transaction representing this supplementary delivery is created and processed 231 ; the "on hold" transaction is updated to a status of "receive complete" 229; and the client is sent a successful final settlement message 233.

[0074] On the other hand, if share delivery is not possible or elected, the method perform the corresponding acts. A new transaction representing return of the already delivered shares is created and processed 237; the "on hold" transaction is updated to a status of "receive expired" 235; and the client is sent an innocent-party settlement message 239 indicating that the match counter-party failed to perform. Lastly, client A's order is updated to back out the effects of the failed transaction.

[0075] Such other alternatives for organizing processing of the above-described steps, for representing the above-described data, for providing client and administrative interfaces, for communicating with other financial institutions, for organizing computer resources, and the like that will be apparent to one of average skill in the art are to be understood as being within the scope and spirit of the above-described invention and covered by the appended claims.

[0076] In this application, the term "conversely" is used in its well understood meaning of reversed as in position, order, or action, and especially a statement obtained by conversion. Particularly, in the appended claims what is often to be understood as reversed in position, order, or action is "DR shares" with "their underlying securities" (or the equivalent). For example, "a client request comprising an offer to provide a specified number of DR shares and to accept a corresponding number of their underlying securities, or conversely" is to be understood as "a client request comprising an offer to provide a specified number of DR shares and to accept a corresponding number of their underlying securities, or an offer to provide a specified number of underlying securities and to accept a corresponding number of their DR of shares". Similarly, "the first request can provide shares in a number and identity that the second request can accept, and conversely" is to be understood as "the first request can provide shares in a number and identity that the second request can accept, and the second request can provide shares in a number and identity that the first request can accept".

[0077] The invention described and claimed herein is not to be limited in scope by the preferred embodiments herein disclosed, since these embodiments are intended as illustrations of several aspects of the invention. Any equivalent embodiments are intended to be within the scope of this invention. Indeed, various modifications of the invention in addition to those shown and described herein will become apparent to those skilled in the art from the foregoing description. Such modifications are also intended to fall within the scope of the appended claims.

[0078] A number of references are cited herein, the entire disclosures of which are incorporated herein, in their entirety, by reference for all purposes. Further, none of these references, regardless of how characterized above, is admitted as prior to the invention of the subject matter claimed herein.

Claims

WHAT IS CLAIMED IS:

1. A system for managing security exchanges between clients, the securities exchanged being depositary receipts (DRs) and their underlying securities, wherein each DR share represents an ownership interest in a corresponding number of underlying securities of an issuer that are held in custodial institution, the system comprising: secondary memory having stored data representing client requests for share exchanges, a client request comprising a share-exchange offer to provide a specified number of DR shares and to accept a corresponding number of the underlying securities, or conversely; a processor operatively coupled to the secondary memory and configured to perform the steps of searching the stored client requests for matching requests, wherein a first request matches a second request if (i) the first request offers to provide shares of DRs or of their underlying securities in a number and type that the second request offers to accept, and conversely, and (ii) the numbers of provided DR and underlying security shares are corresponding; and if matching client requests are found then further selecting some or all of the shares from clients with matched requests and offering to provide shares for transfer to clients with matched requests and offering to accept shares; generating instructions to the clients of the matched requests to have delivered their selected matched shares to specified system custodial accounts held in specified system custodial institutions; after receiving notification from the system custodial institutions of the receipt of the matched shares, generating first instructions to these custodial institutions to deliver the received matched shares to the clients with matched requests; after receiving notification from the specified system custodial institutions of the delivery of the matched shares, updating the matched client requests to reflect completion of the share exchange; and generating notifications to the clients of the matched requests confirming completion of the exchange of the matched shares.

2. The system of claim 1 wherein the processor is further configured to perform generating individual share-transfer transactions for managing actual share transfers resulting from matched requests, a share-transfer transaction comprising the number and type of shares to be transferred and the status of the actual share transfer; storing the share-transfer transactions in the secondary storage; and during instruction generation and notification receipt, updating the status of the associated share-transfer transactions to reflect the status of the actual share transfer.

3. The system of claim 2 wherein the processor is further configured to generate share delivery and receipt instructions from information in share-transfer transactions.

4. The system of claim 2 wherein a share-transfer transaction further comprises an expiration date, and wherein the processor is further configured to perform searching the stored share-transfer transactions for expired transactions, that is transactions having an expiration date prior to the current date, and for each expired transaction to further perform canceling the expired transaction; and for the client request associated with an expired transaction, canceling the request and notifying the client of a failure to perform the actual share-exchange specified by the transaction.

5. The system of claim 4 wherein a client that has failed to perform a share exchange is penalized.

6. The system of claim 4 wherein, for each match where a client has failed to perform, the processor is further configured to perform for all performing clients in that match generating notifications to the performing clients of the performance failure; and if completion of the match is not possible, returning the shares already delivered to the specified system accounts; or if the system has sufficient security resources to permit completion of the match, delivering matched shares to the performing clients.

7. The system of claim 1 wherein a client request further comprises an expiration date, and wherein the processor is further configured to search the stored client requests for expired requests, that is requests having an expiration date prior to the current date, and for each expired request found, to cancel the expired request and to generate a corresponding notification to the client.

8. The system of claim 1 further comprising communications facilities operatively coupling for message exchange the system processor with one of more external systems, wherein the coupled external systems are of one or more clients or system custodian institutions; and wherein the system processor is further configured to perform sending automatically generated instructions and notifications; and receiving automatically client requests and share-transfer notifications.

9. The system of claim 8 wherein the communications facilities comprise the Internet or the SWIFT network, or the CHIPS network, or the FedWire network.

10. A method for managing security exchanges between clients, the securities exchanged being depositary receipts (DRs) and their underlying securities, wherein each DR share represents an ownership interest in a corresponding number of underlying securities of an issuer that are held in custodial institution, the method comprising: searching stored client requests for matching requests, wherein a client request comprises a share-exchange offer to provide a specified number of DR shares and to accept a corresponding number of the underlying securities, or conversely, and wherein a first request matches a second request if (i) the first request offers to provide shares of DRs or of their underlying securities in a number and type that the second request offers to accept, and conversely, and (ii) the numbers of provided DR and underlying security shares are corresponding; and if matching client requests are found then further selecting some or all of the shares from clients with matched requests and offering to provide shares for transfer to clients with matched requests and offering to accept shares; generating instructions to the clients of the matched requests to have delivered their selected matched shares to specified administrator custodial accounts held in specified administrator custodial institutions; after receiving notification from the administrator custodial institutions of the receipt of the matched shares, generating first instructions to these custodial institutions to deliver the received matched shares to the clients with matched requests; after receiving notification from the specified administrator custodial institutions of the delivery of the matched shares, updating the matched client requests to reflect completion of the share exchange; and generating notifications to the clients of the matched requests confirming completion of the exchange of the matched shares.

11. The method of claim 10 further comprising: generating individual share-transfer transactions for managing actual share transfers resulting from matched requests, a share-transfer transaction comprising the number and type of shares to be transferred and the status of the actual share transfer; storing the share-transfer transactions in the secondary storage; and during instruction generation and notification receipt, updating the status of the associated share-transfer transactions to reflect the status of the actual share transfer.

12. The method of claim 10 further comprising generating share delivery and receipt instructions from information in share-transfer transactions.

13. The method of claim 10 further comprising sending automatically generated instructions and notifications to operatively coupling external systems of one or more clients or administrator custodian institutions; and receiving automatically client requests and share-transfer notifications from these external systems.

14. A system for managing security exchanges between clients, the securities exchanged being depositary receipts (DRs) and their underlying securities, wherein each DR share represents an ownership interest in a corresponding number of underlying securities of an issuer that are held in custodial institution, the system comprising: secondary memory having stored data representing client requests for share exchanges, a client request comprising a share-exchange offer to provide a specified number of DR shares and to accept a corresponding number of the underlying securities, or conversely; a processor operatively coupled to the secondary memory and configured to perform the steps of searching the stored client requests for matching requests, wherein a first request matches a second request if (i) the first request offers to provide shares of DRs or of their underlying securities in a number and type that the second request offers to accept, and conversely, and (ii) the numbers of provided DR and underlying security shares are corresponding; and if matching client requests are found, then generating instructions for causing transfer of selected numbers of shares among the clients in accordance with the offers to provide and to accept shares in the clients' matched requests; and updating the matched client requests to reflect of the share exchange.

15. The system of claim 14 wherein the generated instructions cause transfer among the clients by (i) first having clients with matched requests offering shares transfer the offered shares to specified system custodial accounts held in specified system custodial institutions, and (ii) second having the system custodial institutions transfer received shares to clients with requests accepting offered shares.

16. The system of claim 15 wherein the processor is further configured to perform the step of checking that the instructed transfers have been successfully completed by receiving notifications of all share receipts and deliveries.

17. The system of claim 14 wherein a client request further comprises a minimum settlement amount, and wherein a client request offers to accept or to provide shares only in a number equal to or exceeding the minimum settlement amount.

18. The system of claim 14 wherein a client request further comprises an open amount, and wherein a client request offers to accept or to provide shares only in a number equal to or less than the open amount, and where the processor is further configured to perform upon receipt of a client request, setting the open amount equal to the number of shares initially offered to be provided or accepted; upon updating matched client requests, subtracting from the open amount the number of shares transferred in the match.

19. The system of claim 14 wherein matched requests comprise a master request and at least one slave request which matches the master request.

20. The system of claim 19 where a plurality of slave requests match the master request.

21. The system of claim 19 wherein, among the matched requests, the master request is the earliest-received request, or a slave request is the earliest-received request and the master request is the next earliest received request.

22. The system of claim 14 wherein a client request further comprises the time when it was received by the system, and the stored client requests are searched in time order beginning with the earliest-received, current request.

23. A method for managing security exchanges between clients, the securities exchanged being depositary receipts (DRs) and their underlying securities, wherein each DR share represents an ownership interest in a corresponding number of underlying securities of an issuer that are held in custodial institution, the method comprising: searching stored client requests for matching requests, wherein a client request comprising a share-exchange offer to provide a specified number of DR shares and to accept a corresponding number of the underlying securities, or conversely, and wherein a first request matches a second request if (i) the first request offers to provide shares of DRs or of their underlying securities in a number and type that the second request offers to accept, and conversely, and (ii) the numbers of provided DR and underlying security shares are corresponding; and if matching client requests are found then generating instructions for causing transfer of selected numbers of shares among the clients in accordance with the offers to provide and to accept shares in the clients' matched requests; and updating the matched client requests to reflect of the share exchange.

24. The method of claim 23 wherein the generated instructions cause transfer among the clients by (i) first having clients with matched requests offering shares transfer the offered shares to specified administrative custodial accounts held in specified administrative custodial institutions, and (ii) second having the administrative custodial institutions transfer received shares to clients with requests accepting offered shares.

25. The method of claim 24 further comprising checking that the instructed transfers have been successfully completed by receiving notifications of all share receipts and deliveries.

26. The method of claim 23 wherein a client request further comprises a minimum settlement amount, and wherein a client request offers to accept or to provide shares only in a number equal to or exceeding the minimum settlement amount.

27. The method of claim 23 wherein a client request further comprises an open amount, and wherein a client request offers to accept or to provide shares only in a number equal to or less than the open amount, and further comprising upon receipt of a client request, setting the open amount equal to the number of shares initially offered to be provided or accepted; upon updating matched client requests, subtracting from the open amount the number of shares transferred in the match.

28. The method of claim 23 wherein matched requests comprise a master request and at least one slave request which matches the master request.

29. The method of claim 28 where a plurality of slave requests match the master request.

30. The method of claim 28 wherein, among the matched requests, the master request is the earliest-received request, or a slave request is the earliest-received request and the master request is the next earliest received request.

31. The method of claim 23 wherein a client request further comprises the time when it was received, and the stored client requests are searched in time order beginning with the earliest-received, current request.