WO2003065256A1

WO2003065256A1 - Post-trade, pre-settlement information matching for securities transactions

Info

Publication number: WO2003065256A1
Application number: PCT/GB2002/000463
Authority: WO
Inventors: Steven Crosby; Edward R. Merchant
Original assignee: Global Straight Through Processing Association Ltd
Priority date: 2002-02-01
Filing date: 2002-02-01
Publication date: 2003-08-07

Abstract

Systems and methods for facilitating settlement of a securities transaction. A communications mechanism is adapted to accept incoming electronic messages related to the securities transaction. A processing mechanism, coupled to the communications mechanism, determines compatibility between any two or more incoming electronic messages. The processing mechanism transmits an indication message over the communications mechanism that specifies at least one of: (i) compatibility between any two or more incoming electronic messages; and (ii) incompatibility between any two or more incoming electronic messages.

Description

POST-TRADE, PRE-SETTLEMENT INFORMATION MATCHING FOR SECURITIES TRANSACTIONS

BACKGROUND OF THE INVENTION

1. Field of the Invention:

This invention relates generally to financial data processing and, more particularly, to systems and methods for facilitating settlement of securities transactions.

2. Background Art:

Securities transactions which transcend national boundaries are an important and increasing component of worldwide finance. Securities issuers, custodians, fiduciaries, buyers, sellers and their representatives, and others involved in any particular securities transaction can be located virtually anywhere.

International, cross-border securities trades fail and are not completed (i.e., do not "settle") far more frequently than trades taking place within a given country -- and far more often than is desirable to satisfy financial assurance and liquidity objectives. Causes of cross-border trade failure are varied, and include incompatible views of the parties as to bargain specifics, as well as incompatible assumptions and practices regarding settlement mechanics and timing. Beyond impeding investment liquidity, presently-utilized settlement procedures are burdensome and case-dependent, significantly adding to the expense and complexity of completing a trade.

International securities transactions typically involve institutional principals (mutual funds, banks, pension funds as representative) rather than retail (individual) participants. An agent, such as a Broker/Dealer (B/D) and/or an Investment Manager (IM), acts for the ultimate buying and selling entities. Securities holdings are most often identified as a book entry in the computer records of a custodian which either itself, or via a further custodian, holds the underlying securities in its own or a nominee's name. Settlement of an international security transaction typically requires "delivery" via appropriate book entry adjustments and physical delivery ofthe security involving at least one and typically often more than one Global Custodian (GC) or Sub- Custodian.

In some instances, cross-border trades may not involve an exchange (e.g., the New York Stock Exchange, the London Stock Exchange, the Paris Bourse), whereupon the accompanying exchange-mandated settlement procedures and member firm settlement assurances are no longer applicable. Cross-border trades which do not utilize an exchange are essentially bargains directly or indirectly negotiated between an IM (Investment Manager), B/D (Broker/Dealer), or the like, where each party to the trade issues the respective confirmatory notices and settlement instructions. In the United States, two centralized security settlement forums are the

Depository Trust Clearing Coφoration (DTCC) and the Government Securities Clearing Coφoration (GSCC). Specialized clearing agencies exist for international securities as, for example, the International Securities Clearing Coφoration (ISCC). The ISCC is a US-based international clearing agency registered with the Securities and Exchange Commission (SEC) to provide clearance, settlement, and information services to participants trading in overseas markets.

Cross-border securities transactions typically involve multiple tiers of intermediary parties, and many investors may be unaware ofthe existence of some or all of these intermediaries. Managing the inherent risks of a cross- border securities transaction becomes increasingly difficult as the number of tiers increases. As the security instrument is transferred from one intermediary to another, each intermediary in the chain effects the transfer in the form of a book-keeping entry. Typically, the investor does not receive any piece of paper evidencing ownership in such a security, and must rely upon a series of bookkeeping records to establish his interest in the security.

As noted above, much can (and too often does) go wrong during the post trade, pre-settlement phase of a securities transaction. Misunderstandings related to the terms ofthe bargain are overlooked (at least initially) in crossed messages. Parties can have different expectations as to applicable costs, taxes, risk apportionment, and the priority and sequence of performance. "Delivery" between GC's (Global Custodians) may not occur (or not be achievable in the requisite timing) for lack of needed information about the transaction and/or a lack of compatibility between the information exchanged between or among the parties.

As a consequence ofthe foregoing factors the costs and risks of successfully completing cross-border securities transactions is increased. Even if the deal is not successfully completed, the parties are typically burdened with various transactional expenses (e.g., repair costs and fail financing). Moreover, present cross-border trading is not readily amenable to next day settlement ("T-r-1"), _wnj_ch i_s the desideratum of all capital markets so as to promote liquidity and to reduce risk.

SUMMARY OF THE INVENTION:

One object ofthe invention is to accelerate the flow of information between parties participating in a cross-border securities transaction so as to decrease the length of a trade settlement cycle to as short as possible, preferably no greater than the next business day after trade (T+l).

A further object ofthe invention is to reduce cross-border trade failures by providing accurate, "just-in-time" information to all parties participating in a cross-border securities transaction.

Another object ofthe invention is to facilitate cross-border trades by providing the parties with the relevant parameters of the transaction, and/or information about these parameters, and providing data about these parameters as the data become available.

Yet another object of the invention is to provide a system for implementing, contemporaneously, a plurality of cross-border transactions and determining which incoming information pertains to which transaction.

In summary, a timely, efficient, cross-border securities transaction is facilitated by using a communications mechanism and a processing mechanism to assess the compatibility of incoming information related to a securities transaction, and to provide one or more notification messages indicative of information compatibility. More specifically, the communications mechanism receives incoming electronic messages setting forth one or more parameter values related to a securities transaction. These messages may be received in the form of Notices of Execution (NOE's) and/or Block Order Notifications (BON's). Incoming messages may also specify settlement instructions and/or settlement details. Messages are received from a plurality of parties to the transaction, including an Investment Manager (IM), a Broker/Dealer (B/D), and one or more global custodians (GC's). A processing mechanism, coupled to the communications mechanism, first determines which messages of a plurality of incoming messages pertains to a given securities transaction. After identifying two or more messages that pertain to a given securities transaction, the processing mechanism tests for matches between one or more parameter values of these two or more messages. The processing mechanism transmits a message over the communications mechanism specifying at least one of: (i) the existence of matches between one or more parameter values of any two or more incoming electronic messages; and (ii) the non-existence of matches between one or more parameter values of any two or more incoming electronic messages.

According to one preferred embodiment ofthe invention, received incoming messages specify any ofthe following exemplary parameters: (1) a total quantity and value allocation for the securities transaction; (2) a block trade amount for the securities transaction; (3) net proceeds expected by that party from the securities transaction; (4) maximum acceptable deviation from the net proceeds ofthe securities transaction that a party will accept; and (5) settlement location and/or venue. However, the maximum acceptable deviation need not be received in the form of an incoming message, and could be specified in the form of a profile that is pre-stored in electronic memory. The parameters may include one or more mandatory parameters and/or one or more tolerance-based parameters. If the securities transaction is to settle, the mandatory parameters of all messages pertaining to a given securities transaction should match identically. However, the tolerance-based parameters of all messages pertaining to a given securities transaction need only match within a prespecified tolerance in order to permit settlement of the securities transaction. Each of respective tolerance-based parameters may be assigned a corresponding prespecified acceptable tolerance limit. The incoming messages may include one or more NOE (Notice of Execution) messages received from one or more Broker/Dealers (B/D's), and/or one or more BON (Block Order Notification) messages received from one or more Investment Managers (IM's).

At a plurality of times during the post-trade, pre-settlement phase of a securities transaction, the processing mechanism determines whether two or more received messages pertain to a given securities transaction and, if so, the processing mechanism subjects this data to the above-described matching process. The processing mechanism may optionally be equipped with a translation mechanism by which a first security identification code specified according to a first security numbering agency is translated into a second security identification code for the same security, as specified according to a second security numbering agency. If the processing mechanism determines that all mandatory parameters for a given securities transaction match exactly, and that all tolerance-based parameters are within the corresponding prespecified acceptable tolerance limit, the transaction is considered to be matched. Once the transaction is matched, the processing mechanism forwards the transaction to the local market for settlement, and/or forwards the transaction to the B/D or GC for subsequent forwarding to the local market. The processing mechanism sends a message to all parties to the transaction notifying them of the final terms of the bargain.

The matching process is adapted to determine compatibility between two or more incoming messages. If these incoming messages are compatible, a securities transaction may be consummated, whereas if they are incompatible, a securities transaction may not be consummated. The notion of compatibility is dependent upon the parameter in question. Some messages include parameters which must exactly match corresponding parameters in other messages pertaining to the same transaction. For example, the identity ofthe security to be traded must match exactly; otherwise the transaction will not be consummated. However, other messages include parameters which need only fall within a specified tolerance of corresponding parameters in other messages, so as to enable consummation ofthe transaction. For example, a first message may indicate that net proceeds are $10,000, whereas a second message may indicate that net proceeds are $12,000. However, if the specified tolerance is $5,000, the messages are compatible, and the transaction may be consummated. By way of further variation, a first message may indicate that the transaction must be settled in Hamburg, whereas a second message may indicate that the transaction could be settled in Cannes, Hamburg, Cairo, or New Delhi. These messages are compatible, because the transaction could be consummated in Hamburg. Pursuant to a further embodiment ofthe invention, a "just-in-time" data enrichment process is utilized wherein the processing mechanism receives settlement details from one or more parties to the transaction at the time that these details are needed for matching puφoses. In contrast to existing processes that rely on standing, preloaded instruction databases, the "just-in- time" data enrichment process receives current and specific settlement details from the GC and the B/D. The "just-in-time" process obtains data from the source (the GC and/or the B/D), when this information is needed, so as to ensure that accurate, up-to-date, and relevant settlement details are exchanged between the GC and the BD. In this manner, the probability that a given securities transaction will be settled is greatly enhanced.

BRIEF DESCRIPTION OF THE DRAWINGS:

FIG. 1 is a hardware block diagram showing an illustrative operational environment for the present invention. FIGs. 2A-2F together comprise a flowchart setting forth an operational sequence performed by a preferred embodiment ofthe invention.

FIG. 3 is a table setting forth a list of abbreviations and/or acronyms which are used throughout the specification.

FIGs. 4A-4L are an illustrative data structure diagram that describes the informational content of messages received by the TFM processor of FIG. 1. FIGs. 5A and 5B together comprise a data structure diagram setting forth data fields that are used by the TFM for matching puφoses

FIG. 6 is an information flow diagram for a Fund-to-Fund trade. FIG. 7 is an information flow diagram for a first illustrative Allocations Matching Process. FIG. 8 is an information flow diagram for a second illustrative Allocations Matching Process.

FIG. 9 is an information flow diagram showing illustrative message transfers for the Allocations Matching Process. FIGs. 10A-10F together comprise a data structure diagram setting forth information provided by the IM to the TFM processor as part of an Allocation Message.

FIG. 11 is a data structure diagram setting forth input and the output messages utilized during the Allocations Matching Process. FIG. 12 is an information flow diagram illustrating "step out" trades from the perspective of a "stepping-in" B/D.

FIG. 13 is a diagram illustrating the flow of information during the Allocations Matching Process.

FIG. 14 is a chart that provides a comparison between an Allocations Matching Process where the TFM processor has received all required information and an Allocations Matching Process where some information is incomplete.

FIG. 15 is an information flow diagram depicting the Allocations Matching Process for fund-to-fund trades. FIGs. 16A-16E together comprise a data structure diagram showing illustrative data fields utilized by the TFM processor during a Net Proceeds Matching Process.

FIG. 17 is a Prevailing User Tolerance Decision Table used by the TFM processor to determine the type of tolerance to be applied so as to match Net Proceeds within a user-specified tolerance.

FIG. 18 is a Prevailing Amount Decision Table used by the TFM processor to determine the prevailing amount ofthe trade and the match status for various user tolerance match results.

FIG. 19 is a flowchart setting forth an operational sequence for implementing the Net Proceeds Matching Process. FIGs. 20-39 are tables setting forth various illustrative results for the Net Proceeds matching process of FIG. 19.

FIG. 40 is a diagram illustrating information flow for a Settlement Channel Compatibility Determination Process. FIGs. 41 A-41E together comprise a data structure diagram setting forth various illustrative data fields used to implement the Settlement Channel Compatibility Determination Process.

FIGs. 42A-42E together comprise a data structure diagram setting forth various illustrative data fields used to implement a Foreign Exchange (Forex) Settlement Process.

FIGs. 43 and 44 illustrate information flow for a Trade Cancellation Process.

FIGs. 45 and 46 illustrate information flow for a Trade Cancellation Process where a received NOE or BON message contains an erroneous value. FIGs. 47 and 48 illustrate information flow for a Trade Details

Replacement Process wherein one or more new trade parameter values are substituted in place of previously submitted parameter values.

FIG. 49 is a Currency Code data structure for storing currency-related information. FIG. 50 is a Country Code data structure for storing information related to a proposed settlement location.

FIG. 51 is an Instrument Type data structure for maintaining numbering agency codes for securities according to instrument type and country of issue. FIG. 52 is a Settlement Location data structure for storing details related to each of a plurality of potential settlement locations.

FIG. 53 is a Settlement Bridges data structure for storing information related to the existence of "bridges" (preexisting settlement protocol arrangements) between two or more, potential settlement locations.

FIG. 54 is a BIC (Bank Identifier Code) data structure for storing information related to one or more financial institutions. FlG. 55 is a Roles Profile Table describing the functions to be performed by each of a plurality of entities such as B/Ds, IMs, and GCs.

FIG. 56 sets forth an illustrative data structure for a Participant Identification Table. FIG. 57. sets forth an illustrative data structure for a Participant Address

Table.

FIG. 58 sets forth an illustrative data structure for a Participant Roles Table.

FIG. 59 sets forth an illustrative data structure for a Participant Access Module Identification Table.

FIG. 60 is an information flow diagram illustrating the relationship between Participants, BICs, Participant Access Modules, the TFM processor and the Access Concentrators.

FIG. 61 is a Transaction Notification Table that stores details maintained by the participant.

FIGs. 62 and 63 are Substitution Profile Tables that store the identification of a substitute who will be submitting transaction parameters.

FIG. 64 is an IM Client Profile Table that illustrates the profiles maintained by the IM for its Clients. FIG. 65 comprises an Accounting Agent Profile

Table that illustrates the profiles maintained by the Accounting Agent for its Clients.

FIG. 66 is a Matching Tolerance Table that illustrates matching tolerance at a Block Gross Amount level. FIG. 67 sets forth the data structure of a Trade Statistics Table.

FIG. 68 sets forth the data structure of a Message Statistics Table. FIG. 69 sets forth the data structure of a Matching Efficiency Table. FIG. 70 sets forth the data structure of a Geographical Characteristics of Usage Table. FIG. 71 sets forth the data structure of an Instrument Type Table.

FIG. 72 sets forth the data structure of a Type of Service Table. FIG. 73 sets forth the data structure of a Standards Compliance Table. FIG. 74 sets forth the data structure of a Reference Number Table. FIG. 75 sets forth a data structure by which any of a plurality of

Message States may be specified in conjunction with the TFM processor.

FIG. 76 sets forth the data structure of Output Messages as utilized in conjunction with the TFM processor. FIG. • 77 sets forth the data structure of a Message Types

Table.

FIGs.78, 78A and B set forth the data structure for a Block Trade States Table.

FIGs. 79A- 79T together comprise a data structure diagram setting forth various data fields that are utilized by the TFM processor of FIG. 1.

FIGs. 80A-80G together comprise a data structure diagram that describes input message field elements.

FIGs. 81A-81I and 82A-82C are data struc ire diagrams that group field elements by input messages. FIGs. 83A and 83B together comprise a Block Trade Details data structure diagram.

FIG. 84 is a data structure diagram for output messages. FIG. 85 is a data structure diagram showing input messages for allocat ons. FIGs. 86A and B together comprise a data structure diagram showing output messages for the above-described allocations process.

FIG. 87 is a data structure diagram showing input messages for the above-described Net Proceeds process,

FIGs. 88A and B together comprise a data structure diagram showing output messages for the Net Proceeds process. FIG. 89 is a data structure diagram showing output messages related to Accounting Details.

FIG. 90 is a data structure diagram showing input messages involving Settlement Details.

FIGs. 91 A and 9 IB together comprise a data structure diagram showing output messages involving Settlement Details.

FIG. 92 is an information flow diagram for a Fund-to-Fund Trade.

FIG. 93 is an information flow diagram for Sell-Side and Buy-Side Allocations and Notifications.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Post-trade, pre-settlement information matching for a securities transaction is facilitated by providing multilateral communications between parties during the post-trade, pre-settlement phase ofthe transaction. Typically, the parties include an Investment Manager (IM), a Broker/Dealer (B/D), and one or more Global Custodian(s) (GCs). Although these terms are well-understood by those skilled in the art of electronically- facilitated securities transactions, they are briefly defined herein for the convenience of the reader. GCs are entities which hold the physical certificate(s) evidencing ownership of a security for the benefit of third parties; for puφoses of this invention, a GC holds the security ofthe selleτ(s) and, after the transaction is consummated, the buyer(s) may have a different custodian to which the physical security is transferred. IM's are charged with the responsibility of managing an investment portfolio which may include domestically-issued, as well as foreign-issued, security instruments. A B/D acts as an interface or liaison between entities that wish to buy and/or sell securities instruments. Depending upon the particular parties on a side of a given securities transaction, any party could be conceptualized as a "seller" of a securities instrument, with any one or more ofthe remaining "non-selling" parties functioning as a "buyer" ofthe securities instrument. While the present system can be used to match trading information for anything from stocks to stock cars, as used herein, the term "securities" includes any type of intangible asset, such as stocks, bonds, options, derivatives of any kind, dematerialized issues, and the like.

In the environment of a typical exchange, such as the New York Stock Exchange, NASDAQ, the London Stock Exchange, or the Paris Bourse, transactions are typically handled between B/Ds or specialists. For example, an institutional investor's IM at a brokerage desiring to purchase 10,000 shares of XYZ Company places an order for these shares. The order is received by a B/D who then finds another B/D who wishes to sell essentially the same quantity of shares. The two B/Ds then consummate the transaction. If there is a miscommunication between the B Ds as to price or quantity (for example), the buyer and seller are each insulated from this problem by the rules ofthe exchange; e.g., if the buyer only wanted to purchase 1,000 shares and the buying broker, as in this case, accidentally purchased 10,000, the broker (or the brokerage house) would be responsible for the remaining 9,000 shares. These safeguards are often lacking in cross-border transactions.

For the sake of simplicity, assume that two B/Ds are conducting a given securities transaction by representing, respectively, a buyer (B/broker) and a seller (S/broker). B/broker and S/broker communicate their desired transactions to each other using conventional communication techniques such as telephony, mail (including courier-delivered and facsimile-transmitted), electronic mail, electronic direct file transfer, and/or other means. Eventually, they will agree upon the parameters ofthe transaction. Typical parameter values for a securities transaction, and variable names for these parameters used herein, are: the identity ofthe security (SEID); the number of shares (SHRNO); and the share price (SHR$). In addition to these, because the present invention contemplates transactions across borders, additional variables may include transfer, excise, or other taxes the seller's (and/or buyer's) nation may impose on the transfer of a security (TRTX$). An additional optional parameter may specify variations in share price. Because S/broker and B/broker are in different countries, they can decide, during the course of negotiations, on the currency B/broker must deliver or tender (BTENDCUR); the seller can also specify a particular currency (STENDCUR). The currency requested by the seller may not be the currency ofthe seller's domicile, although the security typically will be quoted in the currency of the seller's domicile; for example, many financial markets use United States dollars because it is typically used as a standard currency value throughout the world. Thus, the buyer's currency type (BCUR), the currency in which the security is quoted (SECCUR), and the exchange rates between (i) the buyer's currency and that tendered (XBCUR) and (ii) the security currency and that tendered (XSECCUR) may all have to be specified so that the transaction intended is well-defined and understandable to all involved. Of course, the system must also identify B/broker (BBRID) and S/broker (SBRID) to track each ofthe foregoing parameters as defined or offered by each party. Clearly, other and/or additional parameters can be specified as well; for example, an alternative settlement forum.

In addition to items such as alternative settlement forums, currency and exchange rates, other issues may arise in cross-border securities transactions. Differences in exchange rates, expectations as to tax rates, transfer fees, and other factors may likely render an exact meeting of price and quantity impossible. Accordingly, in a preferred embodiment the parties specify respective tolerance limits for one or more corresponding tolerance-based parameters within which a matching parameter from the other will be accepted. As another example, a party may wish to buy or sell a large block of securities for which it may be difficult and/or time-consuming to secure counteφarties to the transaction. Accordingly, the transaction may have to be divided into a number of separate transactions; for example, a holder of 1,000,000 shares may have to sell ten blocks of 100,000 shares each because there is no ready buyer for all ofthe seller's shares.

In practice, this invention is a post-transaction, pre-settlement system that facilitates the information exchange to reach the agreement necessary to settle the transaction. Assume a buyer in the US desired to purchase 1000 shares of XYZ Co. traded in India; based on available information, the buyer is willing to purchase the shares at US$ 10.00 each. B/broker makes contact with and communicates (by voice, facsimile, and the like) this information to S/broker. Assume that S/broker agrees to these terms. The transaction is now specified, and the two brokers preferably (hopefully) will communicate at least these details ofthe trade to each other so that they have confirmation ofthe agreement. Now, in the post-trade, pre-settlement phase, each ofthe brokers communicates to the present system the parameter values mentioned above; e.g., SHRNO, SHR$, BBRID, SBRID, TENDCUR, and the like. One or more additional optional parameters may include, or take into consideration, variations in share price. Each or all of these parameters can be received by the system in the form of a Notice of Execution (NOE) message initiated by the buyer and/or the seller. Once the system receives an NOE, it identifies the particular transaction (such as by assigning a unique identifier). The system receives further parameter values, for example, from further NOE messages sent by B/Ds, and from BON (Block Order Notification) messages sent by IMs. Preferably, an identifier uniquely identifying a given securities transaction is communicated 10 the B/Ds and IMs so that future communications, such as the transmission of values for other parameters, can be accurately mapped to the information already stored in the system about the subject trade.

Further to the tolerance-based parameters mentioned above, each ofthe parties (i.e., B/Ds and/or IMs) can specify their own acceptable corresponding tolerance limits for certain parameters. For example, the buyer may be willing to purchase a given number of shares at US$ 9.90 to US$ 10.10; the seller may be willing to sell the given number of shares at a price not less than equivalent to US$ 9.95. The present system accepts each of the values transmitted and stores them to determine whether commensurate variables have been consistently specified by each B/D (and/or IM) and, if tolerances are identified for the total net proceeds and/or receipts ofthe deal, whether the values fall within the specified tolerances. Note that the concept of tolerances could arise, for example, in connection with monetary values, such as the total net proceeds due and/or received for a given securities transaction.

Because B/broker in the present example resides in the US, the system can be programmed to enter a default value for BTENDCUR of US dollars, and Rupees for STENDCUR. If S/broker specifies STENDCUR as US dollars and B/broker does not specify this parameter, the system then indicates to both brokers that the values they have indicated for TENDCUR are compatible between them, namely US dollars. When a tolerance is specified, the system will indicate to the brokers that the SHRNO and SHR$ are compatibly specified if, at least, the values specified by one fall within the other's tolerance. Here, SHR$ will be communicated to the brokers by the system as having a value of US$ 9.95 and SHRNO as having a value of 1050. The B/Ds (i.e., B/broker and S/broker) need not communicate all ofthe parameters to the system at once, but the system will store and track each ofthe brokers' communications as they are received until the information sufficient for settlement has been compatibly specified in the system. Preferably the system will update its communication to both brokers each time a new parameter or value is received by the system. Certain parameters, such as an expected return or payment, can be calculated by the system; such a calculation of expected return or payment can include taxes and fees.

Once all ofthe parameters have been specified in a compatible manner, the transaction is completed and agreed to by the parties. From a practical point, thereafter, the physical certificate underlying the security, or some other indicia of ownership, must be transferred to the buyer. Typically, an investor does not possess the certificate; it is held by a custodian (GC) for the beneficial holder, the brokerage. The brokerage where the broker trades has a book entry identifying the client, the number of shares owned, and the custodian holding the certificates for those shares. After a transaction is completed by this invention, the certificates should be transferred to the buyer.

In practice, the certificate is transferred from one GC to another, assuming the buyer's and seller's brokerages use different GCs. GCs may be affiliated with one or more settlement forums, such as Cedel, Euroclear, the ISCC, or another clearing organization. Certain settlement forums have agreements with other settlement forums (these agreements are typically referred to as links or bridges) to facilitate the settlement process after a trade. For example, there is a link between a settlement forum known as the Canadian Depository for Securities, Limited (CDS) and US-based DTC (Depository Trust Company). This link, operational for US and certain Canadian issues, provides CDS with full access to US clearance and settlement, including custody services. US-based ISCC (International Securities Clearing Coφoration) has a link with the London Stock Exchange (LSE) whereby automated checking comparisons, clearance and settlement services are provided for UK equities, and safe custody of securities is provided through the Citibank Coφoration. The Japanese Securities Clearing Coφoration has an ISCC-sponsored omnibus account at the DTC (Depository Trust Company) for receipt and delivery of US equity issues listed on the Tokyo and Osaka Stock Exchanges.

A link between ISSC and Cedel Bank of Luxembourg provides for the settlement of various eligible securities, including PORTAL 144 A issues, with multi-Λirrency capabilities among Cedel bank participants, other ISCC participants, as well as participants or members of any other national clearing and/or depository system having a link with Cedel Bank such as, for example, Euroclear. The Stock Exchange of Singapore has an omnibus account at the DTC for the receipt and delivery of US NASDAQ issues quoted in the Stock Exchange of Singapore's (SES's) Foreign Equities Market/SESDAQ system on behalf of SES.

Euroclear and ISCC are linked such that ISCC members have input capabilities for Euroclear instructions and cancellations. ISCC accepts instructions from users, reformats the instructions, and then submits them to Euroclear. Finally, a link between ISCC and SD INDENAL of Mexico provides for the automated communication of instructions to IΝDENAL's computer mainframe. This link also provides for clearance and settlement of transactions with Mexican equities, in Mexican Pesos or US Dollars. Settlement confirmations and end-of-day statements are also provided, as well as custody services for Mexican equities, collection of dividends, execution of rights offerings, and proxy voting.

According to one preferred embodiment ofthe invention, information pertaining to any ofthe aforementioned links is stored (e.g., in a look-up table, database, and/or data store) within a processing mechanism. Illustratively, this processing mechanism is provided in the form of a TFM (Transaction Flow Manager) processor, shown in FIG. 1 as reference numeral 10, to be described in greater detail hereinafter. After the present system notifies the B/Ds that the transaction has been fully specified and completed, the system references the stored custodian information and notifies all ofthe custodians about the details of the transaction so that the certificates can be transferred. The look-up table facilitates this communication by notifying GCs having agreements regarding these transfers. In a preferred embodiment, S/broker and/or B/broker also specify to the system a local market settlement time by which the settlement (transfer of assets) must occur. This can be implemented by requiring the seller's GC to notify the system (or the B/Ds) that the certificates have been transferred before the period specified, and if the system does not receive such a notification, then the system notifies the B/Ds and the GCs that the agreed upon period for settlement has passed and the transaction has failed to settle. Of course, the B/Ds (on behalf of the parties) still have an agreement and can consult their respective beneficiaries to inquire whether settlement should still be attempted in spite of the lapse of time.

The present system is also applicable to "electronic" or "dematerialized" securities. These are securities that are only issued in electronic form, and do not have any other physical indicia (such as a stock certificate) specifying the intangible property. Additionally, it may be the case that the security is identified with a certificate in the buyer's country but is a dematerialized security in the seller's country. In such a case, the present system provides instructions to the entity charged with keeping track of the dematerialized security, so that the respective interests ofthe buyer and the seller are accounted for.

The invention will now be described with reference to the figures. Fig. 1 is an illustrative view ofthe post-transaction, pre-settlement system according to the present invention. The system includes a transaction flow manager (TFM) processor 10 illustratively implemented using a processing mechanism 12 coupled to storage 14. It is to be understood that TFM processor 10 may be implemented using a mainframe computer, a personal computer (PC), a computer network, or any other type of centralized and/or distributed processing system. Storage 14 may be non-volatile, such as, for example, a data storage drive, and/or it may be implemented using random- access memory (RAM), read-only memory (ROM), and/or core memory. Storage 14 preferably may be arranged to store messages from the brokers in a message database (DB) 18, and may also be arranged to provide additional storage areas for participant profiles 1 (e.g., B/Ds) as well as look-up tables 23. Messages (such as an NOE message and/or a BON message) are received by the system, and transmitted from the system to the participants, via a communications pathway 40. Communications pathway 40 may represent any technique for conveying information from one place to another, including, for example, wireless communications, wired communications, and/or fiber optic links, to name a few. The information may be conveyed using any of a wide variety of transmission protocols, including digital and/or analog data signals (which could, but need not, be encrypted or otherwise securely transmitted), voice (which may also be encrypted), mail (including postal, facsimile, and electronic correspondence, the latter two of which can also be encrypted for security). Broker/Dealers (B/Ds) 50) through 50_n communicate with the system via the communications pathway 40, as do Global Custodians (GCs) 70₁ through 70_n, and Investment Managers (IMs) 60] through 60_n The typical securities transaction includes one IM, one B/D, and at least one GC. The communications pathway 40 may include one or more dedicated wired and/or wireless communication links between the present system and the B/Ds and/or GCs. It may also include a network by which B/Ds, GCs, and/or IMs can interface with the system. Such a network can have local areas (e.g., a LAN) and/or span a wider area (e.g., a WAN, optionally with satellite communication and or radio frequency communication). Another preferred network is the Internet, where secure communication can be conducted using secure hypertext transfer protocol (i.e., via a private network).

Refer now to FIGs. 2A, 2B, and 2C which together comprise a flowchart setting forth an operational sequence performed according to a preferred embodiment ofthe invention. The overall operational sequence describes the manner in which the system of FIG. 1 provides multilateral communications between a Broker/Dealer (B/D) 50 _b an Investment Manager (IMs) 60₁, and one or more Global Custodians (GCs) 70] through 70_n. More specifically, the system of FIG. 1 provides multilateral communications in response to the receipt of one or more messages from at least one ofthe B D 50), IM 60], and CC 70ι.

The program of FIGs. 2A-2F commences at block 101 where the TFM processor (FIG. 1, 10) receives an incoming message from any ofthe aforementioned parties (i.e., B/D, IM, and/or GC). In general, an incoming message may specify any ofthe following exemplary types of data: (1) a total quantity and value allocation for the securities transaction, (2) a block trade amount for the securities transaction, (3) net proceeds of the securities transaction, (4) maximum acceptable deviation from the net proceeds of the securities transaction, and (5) settlement location and/or venue. However, the maximum acceptable deviation need not be received in the form of an incoming message, and could be specified in the form of a profile that is pre- stored in electronic memory. The message may also includes a transaction ID (TRXID) uniquely identifying a given securities transaction. The messages submitted by parties such as B/Ds, IMs, and/or GCs may include any of Notice of Execution (NOE) messages, Block Order Notification (BON) messages, allocations messages, net proceeds messages, and settlement details messages. For puφoses of explanatory expediency, incoming messages may include some or all ofthe fields shown in the table immediately following, wherein the variables are those which were previously discussed in conjunction with the illustrative cross-border securities transaction. However, more detailed data structure tables will be described hereinafter with reference to FIGs. 4A-4L. Assume that a buyer's B/D initiates an illustrative message with the following values:

where TRXID is the transaction ID, BBRID is the identity of d e buyer's B/D, SEID is the identity ofthe security, SHRNO is the number of shares, SHRS is the share price, and SHR$TOT is the maximum deviation (plus and minus) from the share price that the buyer is willing to accept. This message does not have to include all of these fields. For example, the SHRSTOT field could be eliminated. The message could also include additional fields such as BTENDCUR, specifying the buyer's tender currency, and or TRTXS, specifying tax to be levied on the transaction.

Subsequent to issuance ofthe buyer's message, the seller's B/D will issue a message. Note that, alternatively, the seller could initiate a message first. An illustrative simplified message issued by a seller is as follows, although it should be noted that a more detailed message data structure is set forth in FIGs. 4A-4L.

At block 103, the program provides a confirmation prompt to the entity issuing the received message, which may be B/D 50 _ls IM 60₁, or GC 70^ acknowledging that the message has been received.

At block 105, the program checks to ascertain whether or not the received message conforms to a predefined format, examples of which are shown in the data structure tables above. Although any of various message formats may be used to implement the invention, on occasion, data transmission errors may occur, or unauthorized parties may attempt access, and it would be desirable to identify such errors at the present stage, before further processing takes place. If the message does not conform to a predefined format, the entity that issued the message is alerted (block 107), and the program loops back to block 101. If, on the other hand, the message conforms to a predefined format, the message is considered to be an NOE (notice of execution) message, and the program advances to block 109. At block 109, an optional confirmation message is sent to the entity that issued the message, conveying the notion that the message has been accepted for further processing. Note that this step is not required - i.e, the entity that issued the message need not be notified that the message has been accepted.

Next, at block 110, the program performs a translation of the received security ID (SEID) to a primary security identification code. This primary security identification code is fixed and determined by the market and/or the security itself, and could represent, for example, a standard ISIN or CUSIP security identification number. At block 1 1 1 , a test is performed to ascertain whether or not the incoming message includes a unique match reference number indicating that the incoming message relates to any previously- received incoming messages. If so, the program jumps to block 120, to be described hereinafter. If not, the program advances to block 1 12 where the data field(s) ofthe incoming message are compared with the data field(s) of previously received message(s) to identify any previously received message(s) having data field(s) similar and/or identical to that ofthe incoming message.

Next, at block 113, a test is performed to ascertain whether or not there is a previously-received message having some or all data field(s) with identical 5 and/or similar content to that ofthe incoming message. The affirmative branch from block 113 leads to block 115 (to be described hereinafter), and the negative branch from block 113 leads to block 114. At block 114, the program waits for additional incoming messages and, upon receipt of a new message, the program loops back to block 112.

10 The affirmative branch from block 113 leads to block 1 15 where a unique match reference number is assigned to the received messages having similar and/or identical content. The system sends notification to the senders of all incoming messages which were matched at block 1 13. The notification includes the unique match reference number assigned at block 115. The

L5 incoming message is then stored for matching to future incoming messages (block 119).

Block 120 is reached by an affirmative branch from block 1 1 1. At block 120, all stored message(s) with unique match reference numbers referring to the same transaction as the incoming message are retrieved. Next, (block 121),

!0 stored profile settings and/or retrieved message(s) and/or the incoming message is checked for any applicable specified tolerance parameter. Matching of all data sets among all messages retrieved at block 120 is performed, based upon tolerances as specified in the stored profile and/or the incoming message and/or the retrieved message(s).

\5 A test is performed (block 124) to determine whether or not there are any mismatches of mandatory parameters. If so, the program jumps to block 131, to be described hereinafter. If not, the program continues to block 125 where yet another test is performed to determine whether or not all messages for this transaction have been received and matched. This step could be

0 performed, for example, by examining data structure fields to see if a field is missing a value. If so, the program jumps to block 129 where all transaction details are routed to the local market and/or to the GC and/or to the B/D, based upon a profile stored in the TFM processor. The program then ends for puφoses of this transaction. The negative branch from block 125 leads to block 127 where the program waits for additional incoming messages. If an incoming message is received, the program loops back to block 112.

Block 131 is reached from the affirmative branch of block 124. An incompatibility message is sent to all parties identified in all messages retrieved at block 120. The parties are then provided with the option of cancelling, replacing, modifying, and/or deleting one or more messages. This functionality may be implemented, for example, by permitting one or more parties to issue new incoming message(s) which are then received by the TFM processor. At block 135, a test is performed to ascertain whether or not the parties modify, replace, delete, and/or cancel one or more messages. If so, the TFM processor performs matching of data based upon the replaced, cancelled, deleted, and/or modified message(s). The program loops back to block 124. The negative branch from block 135 leads to block 137 where an incompatibility message is sent to all parties, and the program ends for puφoses of this transaction. The flowchart of FIGs. 2A-2F describes the process whereby, at any time during the post-trade, pre-settlement process, a matching mechanism accessible from a communications pathway matches data entered into this pathway. The matching process matches any ofthe following types of data: (1) matching the total quantity and value allocation, as entered by a first party, to total quantity and value allocation as entered by a second party; (2) matching net proceeds, as entered by a first party, to net proceeds, as entered by a second party; (3) matching maximum acceptable deviation from net proceeds, as entered by a first party, to maximum acceptable deviation from net proceeds, as entered by a second party; and (4) matching the settlement locations and/or venues as entered by all ofthe parties. However, the maximum acceptable deviation need not be received in the form of an incoming message, and could be specified in the form of a profile that is pre-stored in electronic memory.

The communications pathway is coupled to an indication mechanism, responsive to the matching mechanism, for providing a first indication as to the existence of a data match and/or the non-existence of a data match. The indication mechanism may include a display for indicating matches and/or mismatches between any ofthe following: (1) the total quantity / value allocation and the block trade amount, (2) net proceeds, (3) maximum acceptable deviation from net proceeds; and (4) settlement locations and/or venues.

An optional timestamp can be applied to all incoming messages, enabling subsequent determination of settlement efficiencies and any possible settlement bottlenecks. Universal Coordinated Time (UTC), previously known as GMT (Greenwich Mean Time), can be used as the timestamp standard. Refer to FIG. 3 which is a table setting forth a list of abbreviations and/or acronyms which are used throughout the specification. Each abbreviation and/or acronym is associated with a corresponding definition.

FIGs. 4A-4P set forth an illustrative data structure diagram that describes the informational content of messages received by the TFM processor from IMs and B/Ds. An actual message could, but need not, employ all of the fields shown in FIGs. 4A-4P. This data structure diagram is presented for exemplary puφoses, to illustrate what such messages could contain. The data structure of FIGs. 4A-4P includes fields adapted to store information regarding the sender ofthe message, reference and trade identification details, details concerning the parties to the transaction, security identification details, additional information for fixed income instruments, trade details, links to another trade that was cancelled, links to another trade that was disputed, and additional optional details.

The TFM processor (10, FIG. 1) provides support for trades involving instruments such as equities, fixed and floating rate bonds, short-term instruments and simple asset and mortgage backed securities for cash settlement. The TFM processor is adapted to perform any of the following functions:

I . Block Trade Processing 2. Allocations Processing

3. Net Proceeds Processing

4. Accounting Details Processing

5. Settlement Details Processing

6. Free Flow Forex Processing 7. Cancel/Replace/Delete Processing

8. Alert and Deadline Processing

9. Master and Reference Data

10. Participant Profile Data

I I . Query Processing.

Each of these functions will now be considered in sequence, commencing with block trade processing.

1. Block Trade Processing

An institutional trade typically commences when an IM makes an investment decision to buy or sell securities on behalf of its institutional clients. 5 The IM places an order (block order) to buy or sell securities with a B/D. The B/D executes the block trade on behalf of the IM. Since the quantities involved in a block trade are usually very large, the B/D may execute the block trade in . smaller lots with different prices for each lot depending on liquidity conditions in the market. The B/D calculates the average price for the block trade once the

10 entire block trade quantity has been executed and communicates both the average price and the settlement date for the block trade to the IM via a notice of block trade execution to the IM. The B/D may also inform the IM about the partial executions of the block trade and the price for each partial execution depending upon the preference ofthe IM.

15 It is possible that a single block trade would not be fully executed within a single trading day. In such cases, the B/D and the IM may agree to truncate or warehouse the block trade up to the quantity executed at the end of the day. Trading activity may occur through the use of telephones, faxes, etc., or by using electronic networks leveraging protocols such as FIX. However, the

.0 involvement of the TFM processor (FIG. 1) in the post trade processing cycle starts with the receipt of a Notice of Execution (NOE) message.

TFM Processor Functionality

Once a block trade has been executed, the TFM processor (10, FIG. 1) '.5 receives a copy ofthe Notice of Execution (NOE) from the B/D. Normally, this is the starting point of the trade life cycle in the TFM processor. If the IM prefers to interact with the TFM processor in a "conversational" mode, on receipt of a pending NOE for a block trade from the TFM, the IM submits a Block Order Notification (BON) to the TFM processor. Alternatively, the IM 0 may submit a BON independently. The trade details provided by either the B/D or the IM to the TFM processor regarding the block trade are set forth in a message that utilizes some or all of the fields which were previously described in connection with FIGs. 4A-4P. The B/D submits a Notice of Execution and the IM submits a Block Order Notification. The TFM processor 10 (FIG. 1) timestamps the incoming block trade details on receipt and assigns a unique receipt reference number for the block trade details. The TFM processor also validates the message for syntax and performs the necessary edit checks. If there are any errors detected during the syntax or edit checks, the TFM processor sends an error message indicating the reasons for error to the sender ofthe message.

If both the syntax and edit checks are successful, the TFM processor attempts to match the received block trade details with the unmatched trades in the TFM processor 10 (FIG. 1). FIG. 5 is a data structure diagram setting forth data fields that are used by the TFM for matching puφoses. If the TFM does not find a match it stores the details of the block trade received with the status of "unmatched trade" in the trade database. If the TFM processor finds a match, it assigns a unique match reference number to the matching incoming messages. The previously mentioned "transaction ID", abbreviated "TRXID", could (but need not) be used for this puφose. The TFM processor then stores the details of both sides of the trade with a status of "Matched Trade" in the trade database. The status of the matching trade in the TFM trade database is also updated to "Matched Trade" along with the matching reference number in the trade database. All other fields, if specified by both the participants in the block trade details (FIGs. 41-40), are compared and a warning message is issued if they do not match.

The TFM processor (10, FIG. 1) provides a "just-in-time" functionality.

The TFM processor determines when a notice of pending transaction needs to be "pushed" to the counteφart. If there is no match available for the block trade details submitted by one party, the TFM processor sends a notice of pending transaction to the counteφart immediately, providing the counteφart has opted to operate in conversational mode. If the counteφart is in independent submission mode, the TFM processor checks the profile of the counteφart for the timing of the notice of pending transaction to be sent. If the 5 timing set is beyond the deadline for the NOE and BON match, then the notice of pending transaction is immediately sent. If no timing has been set in the participant profile, the TFM processor will push the notice of pending transaction after a system-specified duration (for example 15 minutes).

The TFM processor may. also be equipped with a translation mechanism by

LO which a first security identification code specified according to a first security numbering agency is translated into a second security identification code for the same security according to a second security numbering agency. The TFM processor uses the following logic for matching security identification if the primary numbering agency code is not specified as the numbering agency code:

.5 The TFM processor first translates the security identification in the numbering agency code specified by the participant to the primary numbering agency code. The primary numbering agency code will be determined based on the type and country of issue of the security. If participants have specified a mutually agreed upon identification, the TFM

:0 processor will not attempt any translation.

> The TFM processor attempts for a match on the translated primary numbering agency code. A security numbering scheme known as ISIN (refer to FIG. 3 for the meaning of the foregoing abbreviation) may be utilized as the primary numbering 5 agency code for most of the securities supported by the TFM processor. Example 1 : (Security Identification): Participant A (IM) specifies a security identification in CUSIP. The TFM processor translates the CUSIP identification to an ISIN, which is the primary numbering agency code for the security. Similarly when the counter participant 0 B (B/D) specifies a security identification in SEDOL, the TFM processor translates the identification to ISIN. The translated ISINs on both block trades are matched.

When the Allocations are submitted, the GC is informed of the block trade details and the Allocation details with the security identification code originally submitted by the IM (CUSIP) and the primary numbering agency code (ISIN). The same principle will be applicable for sending notice of pending transactions to counter parts as well as sending information to interested parties.

Tolerance Matches for Price

Matching of price within a tolerance is applicable if both the parties have indicated in their profiles that they do not require an exact match on price. Parties (i.e., participants) can also indicate in their profiles that they need an exact match on the External Reference Number for carrying out a tolerance match on the Block Gross Amount. This tolerance is a participant-defined tolerance based on settlement currency and type of instrument. These tolerances can be fixed as a % and/or an absolute amount. The following examples illustrate various scenarios.

Example 1:

Participant A (IM) and Participant B (B/D) want an exact match on price. Participant A submits a Block Notification for 100,000 IBM shares at an unit price of USD 78.50634. Participant B submits a Notice of Execution for 100,000 IBM shares at an unit price of US 78.5063. Since both participants want an exact match on price, the TFM processor creates two unmatched trades. Participant A and B will have to analyse their alleged trades against their unmatched trades to resolve the difference. One of the participants should effect a replacement to change the price so that the trades can match.

Example 2: Participant A (IM) and Participant B (B/D) have indicated that an exact match on price is not required. Both Participant A and Participant B wants a tolerance match only if the external reference #s match. Participant A submits a Block Notification for 100,000 IBM shares at an unit price of USD 78.50634 and a 5 block gross amount of USD 7,850,634. Participant B submits a Notice of Execution for 100,000 IBM shares at a unit price of US 78.5063 and a block gross amount of USD 7,850,630. Participant A has specified a tolerance of USD 10 for equities and participant B has specified a tolerance of USD 15 for equities. Participant A and B have carried out the trade using FIX and have 10 both supplied an external reference # FIX 123 for the trade. The TFM processor matches the trade as the difference in the block gross amount (USD 4) is within the lowest of the tolerances of the participants (USD 10) and assigns a TFM match reference # TFM 123 for the trade.

L5 Example 3:

Participant A (IM) and Participant B (B/D) have indicated that an exact match on price is not required. Participant A and B have indicated that an external reference # match is not required for a tolerance match. Participant A submits a Block Notification for 100,000 IBM shares at a unit price of USD 78.50634 20 and a block gross amount of USD 7,850,634. Participant B submits a Notice of Execution for 100,000 IBM shares at a unit price of US 78.50 and a block gross _* amount of USD 7,850,000. Participant A has specified a tolerance of USD 10 for equities and participant B has specified a tolerance of USD 15 for equities. The TFM processor does not match both the trades as the difference in the

>5 block gross amount (USD 634) is outside of the lowest of the tolerances of the participants (USD 10). Participants A and B will have to analyse their alleged trades against their unmatched trades to resolve the difference. One of the ^* participants should effect a replacement to change the price and the block gross amount so that the trades can match.

10 Correction of Mismatched Messages

If participants submit messages with details that do not match, the TFM processor will create two unmatched trades. For example, if the IM and B/D have wrongly specified the security identification, but rather specified a different valid code, the TFM processor will generate two unmatched trades, one for each side submitting the block trade details. The IM and the B/D will then have to investigate their unmatched trades against their alleged trades to determine possible matches. To indicate the differences to counteφarts (i.e. other parties to the transaction), participants can send a Dispute message against an alleged trade by indicating the reference # of their unmatched trade. (For further details please refer to the Cancel/Delete/Replace processing section.) After analysing the differences, the counteφart can send a replace message to their side of the block trade details, which will automatically result in a match ofthe trades in the TFM processor.

Example:

Participant A (B/D) sends a NOE message to the TFM processor for 100,000 IBM shares at a price of USD 78.50 against Participant B (IM) having reference # A 1234. Participant B sends a BON message to the TFM processor against Participant A for 100,000 IBM shares at a price of USD 78.00 having reference # B1234. The details do not match and the TFM processor creates two unmatched trades, one for each side. Participants A and B also get an alleged trade.

Participant A finds that the difference between the alleged trade and the unmatched trade is the price field (difference of USD .50) and sends a Dispute message against the alleged trade B1234 indicating that it should match with their trade reference # A 1234. Participant B sends a replacement for trade B1234 changing the price to USD 78.50. On effecting the replacement, the TFM processor matches trades A 1234 and B 1234 and assigns a TFM match reference # T 1234. Housekeeping of Trades

The TFM processor maintain in an active trade database all matched trade information for up to a predetermined amount of time (e.g., 90 days). This predetermined amount of time is a TFM processor system parameter termed "number of days for archiving". It may be calculated from the later of either the settlement date or the date on which details were matched. During this 90-day period participants will be allowed to query, cancel or replace their trade details. After the 90 days, the data will be archived and will be available only for queries.

The TFM processor cancels pending unmatched trades if either the entire block is unmatched or some of the Allocations pertaining to the block have not been enriched and matched after 30 days. This is a TFM processor system parameter called number of days for automatic cancellation of unmatched trades which starts at the date the block trade is input into the TFM processor.

TFM Processor Outputs: The TFM processor is adapted to generate any of the following outputs:

> Error Messages, indicating the reasons for failure, will be sent if there are any validation failures.

> A Trade acceptance notification is sent if the block trade is accepted by the TFM processor, based on the profile of the participant submitting the trade details.

> A notice of pending transaction may also be sent to the counteφart if an unmatched trade is accepted.

> If there is a match, a match notification message is sent to both the buyer and the seller indicating the match reference number. > Any required match warnings are also notified along with the match notification message. There are variations to this function for different types of transactions and processes. The following are the possible variations for different transaction types:

Broker-to-Broker Trades

B/Ds can also report and match their Broker-to-Broker trades using the TFM processor. In this case one of the B/Ds (called the executing broker) will provide the NOE and the counteφart broker will provide the BON. The transaction type will be set as "Broker-to-Broker" by both sides. The TFM processor will not have any allocation process for Broker-to-Broker trades. Participants can also submit all the necessary details including net proceeds and settlement details, along with their NOE/BON for a Broker-to-Broker trade using a multi-part message. The TFM processor will carry out the net proceeds match and the channel compatibility match, as explained in subsequent sections, for the Broker-to-Broker trades. B/Ds can indicate in their profiles, if they will use the TFM processor for matching Broker-to-Broker trades. If one of the B/Ds in the Broker-to-Broker trade indicates that they do not want to use the TFM processor for Broker-to-Broker trades, the TFM processor will not accept the Broker-to-Broker trade.

Fund-to-Fund Trades

Refer to FIG. 6 which sets forth information flow for a Fund-to-Fund trade. Fund-to-Fund trades are submitted either by a single IM (to handle internal crossings between funds), or by two different IMs (if they have traded using electronic networks such as Instinet or E-crossnet). Fund-to-Fund trades are handled by the TFM processor as two institutional trades. Both sides of the Fund-to-Fund trade will be reported as institutional trades against a virtual broker, which is either a clearing account providing internal crossings or an institution providing the fund-to-fund crossing services (such as E-crossnet). FIG. 6 explains the handling of a Fund-to-Fund trade. All of the inputs are indicated as Fund-to-Fund trade in the Trade Transaction Type. The common virtual broker can link the two sides of the fund-to-fund trade using a link reference number.

Basket/Portfolio or Program Trading

Participants (parties) report and match basket/portfolio or program trades as individual institutional trades relating to each underlying security of the basket/portfolio or program. Participants specify a common basket/portfolio or program reference number, and will designate the trade transaction type as "Basket/Portfolio or Program" trade A typical basket/portfolio or program trade will be a pre-allocated trade where the B/D will specify the allocations for the underlying institutional trades. The TFM processor will support queries to participants based on the basket/portfolio or program trade reference number.

2. Allocation Processing

IMs buy and sell securities on behalf of their institutional clients (pension funds, mutual funds, insurance funds, etc.) The IM who has placed a Block Order identifies the clients on whose behalf the buy or the sell decision has been made. The IM allocates the quantity of securities bought or sold among its various clients and informs the TFM processor through one or more Allocation messages. Allocation messages are sent to the TFM processor at the same time or after the BON is submitted.

TFM Processor Functionality

IMs submit allocation messages to the TFM processor in accordance with one of the following procedures: (A): The IM allocates the trade as soon as the Block Order is submitted to the TFM processor. The Allocation message may be sent to the TFM processor along with the BON in a multi-part message or the Allocation may be sent to the TFM processor after the BON is submitted as a separate message. In both cases, the TFM processor may receive the Allocations before or after the BON is matched with the NOE. The TFM processor matches the Allocation quantity with the BON quantity. Information flow for this allocation process is shown in FIG. 7.

(B): The IM, upon receipt of communication from the TFM processor of Pending Notice of Execution, may affirm the trade by submitting the BON in conversational mode and subsequently submitting the Allocations. In this case, the TFM processor first matches the trade (BON with NOE), and then the TFM processor matches the Allocation quantity with the trade quantity. Information flow for this allocation process is shown in FIG. 8.

Partial Allocations

IMs may not have the complete client information for all of the Allocations. In cases where the IM has incomplete information regarding a particular Allocation, the IM can submit Allocations whose details are complete to the TFM processor. The Allocations for the entire trade quantity can be provided as part of a single message or through multiple messages, as is shown in the information flow diagram of FIG. 9.

When the IM sends Allocations for a trade in more than one message, these Allocations are called Partial Allocations. Partial Allocation messages can be submitted when the IM identifies the client(s) for the Allocation. The IM gives an unique sequence number for every Allocation 5 contained in the messages submitted. Each ofthe Allocation messages will specify the quantity allocated in that message. The TFM processor will compare for each partial Allocation message, the total quantity of Allocations in the message with the unallocated quantity for the trade.

0 Input Information

Refer to FIG. 10, which is a data structure diagram describing information provided by the IM to the TFM processor as part of an Allocation message. The TFM processor timestamps the incoming Allocation message upon receipt and assigns it a unique receipt reference number. The TFM

15 processor also validates the message for syntax and performs the necessary edit checks. The TFM processor validates the Trade Reference number given in the Allocation message that is submitted by the participant. There should be an existing trade within the system with the same reference number and the same counteφart. When all Allocations are part of a single message, the TFM

:0 processor matches the total quantity ofthe Allocations to the trade quantity.

When Partial Allocations are received by the TFM processor, the TFM processor keeps track of the Allocations received for the total trade. When the total quantity of Allocations received matches the total trade quantity, the Allocation process is completed and the trade status is updated as "Matched

5 Allocated Trade" or "Unmatched Allocated Trade" depending on whether the trade is matched or not. If the quantity allocated in the message is more than the unallocated quantity for the trade before the arrival of the message, the message being processed is treated as "In Error." Once the Allocation message has passed the total quantity check, each allocation within the message is

) validated for content. Only the allocations failing the validations will be rejected by the TFM processor. The remaining allocations will be processed normally by the TFM processor.

Example 1:

The IM has placed a block order for 100,000 shares for which partial Allocations are being submitted. The first Allocation message is submitted with the following control fields: Quantity allocated in this message: 25,000 (Reference number 1 & 2)

LO

The TFM processor verifies that the quantity allocated is not more than the unallocated quantity. The second Allocation message is submitted with the following control fields: Quantity allocated in this message: 25,000 L5 (Reference number 3 & 4)

The TFM processor verifies that the quantity allocated is not more than the unallocated quantity. Another Allocation message is submitted with the following control fields: '.0 Quantity allocated in this message: 40,000. (Reference number 6 & 7)

The TFM processor verifies that the quantity allocated is not more than the unallocated quantity. TFM processor finds that the trade is not fully allocated.. '.5 Another Allocation message is submitted with the following control fields: Quantity allocated in this message: 10,000 (Reference number 5)

The TFM processor verifies that the quantity allocated is not more than the 0 unallocated quantity. When the quantity allocated equals the unallocated Trade" or "Unmatched Allocated Trade" depending on whether or not the BON/NOE match has taken place.

Example 2:

The IM has placed a block order for 100,000 shares for which partial Allocations are being submitted. The first Allocation message is submitted with the following control fields:

Quantity allocated in this message: 25,000

(Reference number 1 & 2)

The TFM processor verifies that the quantity allocated is not more than the unallocated quantity. The second Allocation message is submitted with the following control fields:

Quantity allocated in this message: 25,000

(Reference number 3 & 4)

The TFM processor verifies that the quantity allocated is not more than the unallocated quantity. Another Allocation message is submitted with the following control fields:

Quantity allocated in this message: 40,000

(Reference number 5 & 6)

Quantity allocated in this message: 20.000

(Reference number 7)

TFM processor verifies that the quantity allocated (20,000) is more than the unallocated quantity (10,000). TFM processor marks the Allocation Message as "In Error."

Example 3: The IM has placed a block order for 100,000 shares for which partial

Allocations are being submitted. The first Allocation message is submitted with the following control fields:

Quantity allocated in this message: 25,000

(Reference number 1 & 2)

Quantity allocated in this message: 25,000 (Reference number 3 & 4)

The TFM processor verifies that the quantity allocated is not more than the unallocated quantity. Another Allocation message is submitted with the following control fields: Quantity allocated in this message: 40,000 (Reference number 5 & 6)

Quantity allocated in this message: 10,000 (Reference number 8)

The TFM processor verifies that the trade is fully allocated, but finds that sequence number 7 is missing. TFM processor sends a warning to the IM informing about out-of-sequence Allocations.

Account Number Cross-Referencing

An allocation message that the TFM processor receives from an IM may provide the Account Number of the client as per the IMs internal records, and/or pursuant to the GCs client account number. The TFM processor could, but need not, perform any cross-referencing of the IM's account number to the B/D's internal account numbers. To enable the B/D to cross-reference between the IM's number and the B/D's internal reference number, the IM can also provide in the Allocation message the access code relating to the vendor's system where the account number is registered, if it is indeed registered (e.g., in Alert, SID, etc.) The TFM processor will send this information to the B/D as part of the Allocation Notification. The B/D will interface with the vendor system for internal account set-up and cross-referencing puφoses. The GC will receive the IM's and its own account numbers, as provided by the IM on the allocation.

It is possible to utilize a new standard numbering scheme to identify accounts/portfolios. This would involve the creation of an "Account/Portfolio Registering Agency" that would allocate unique account numbers for each account/portfolio that an institutional investor (e.g., a mutual fund, a pension fund) would want to register. This registering agency would collect the minimum amount of information about the account/portfolio that is needed for IMs, B/Ds, and GC to recognize this entity. The IM and the GC would use the unique number (directly or by cross-reference). The association of this unique number with the IM BIC code would uniquely define the account for a B/D. As per the proposed scheme, the IM will identify their client account numbers as "Portfolio X," the GC will identify their client account as "Portfolio X" and the B/D will identify their client account as "Portfolio X at IM Y." There are several potential consequences related to this proposal. The design of the TMF described herein will allow for such a possible development in the future. The transition from the current situation to a new account numbering system could proceed as follows:

In the early phase of the proposed scheme, the IM will submit its account number, the GCs account number and a GSTPA (Global Straight Through

Processing Association) account number, if available. The B/D will receive from the TFM processor, the IM's account number and the GSTPA account number, if provided by the IM. The GC will receive from the TFM processor, the IM's account number, the GCs account number and the GSTPA account number, if provided by the IM.

As the proposed scheme develops, the IM submits the GSTPA account number only as part of the Allocation message. The B/D and the GC will receive the GSTPA account number from the TFM processor as part of the Allocation Notification and will do the required cross-referencing internally in their own applications.

Security Identification

The TFM processor provides one or more security identification messages to the GCs. These messages include a security identification number in the numbering agency code supplied by the IM, and/or in the primary numbering agency code translated by the TFM processor. Translated codes are provided in the event that the number received from the IM is not a prespecified primary code to be utilized by the TFM processor, such as, for example, ISIN.

Example 1: The IM and the B/D have submitted the trade details in ISIN, which is prespecified as the primary numbering agency code for the security. The TFM processor will notify the Allocations with the details of the security in ISIN, which was used by the IM to report the trade. Example 2: The IM submits the security details in CUSIP. The B/D submits the security details in SEDOL. As the TFM processor has already translated the CUSIP and SEDOL to ISIN (which is the primary numbering agency code) before the trade match is done it will notify the GC of the security details in ISIN and CUSIP, which was the code supplied by the IM.

Settlement Location

The B/D provides an NOE message to the TFM processor specifying the settlement location that was explicitly or implicitly included in the trade agreement. This information will be relayed with each Allocation as it is sent to the GC.

Outputs The following are output messages generated by the TFM processor for the aforementioned allocations process. The TFM processor sends one or more notification messages to the B/D regarding the Allocations received from the IM. The notifications are sent for every Allocation accepted by the TFM processor. The notifications to the B/D will include the particulars of each Allocation. This enables the

B/D to submit the Net Proceeds and Settlement Details for each Allocation. This message is sent to the B/D only after the trade is matched.

The TFM processor sends one or more notification messages to the relevant GC on acceptance of every Allocation. The notification to the GC will include all the particulars of the trade except the trade quantity (as per the BON or the matched trade, if the trade is matched) and the Allocation details as per the Allocation message. This enables the GC to prepare for the settlement very early. As the settlement location information from the NOE is vital information for the GC, it would be better to send the Allocation when the NOE and BON have matched. If the trade is not yet matched and the GC had indicated a desire to receive Allocations right away in its profile, the notification will indicate that the trade is in unmatched status and will have to be sent again with the settlement location as soon as it is available (i.e., after the NOE/BON match occurs).

> If the IM or the B/D has appointed a third party to submit net proceeds, the TFM processor sends a message specifying the details of the trade and the Allocation details to this third party. This enables the substituting party to compute the net proceeds and submit them to the TFM processor.

> If the B D or the GC has appointed a third party to submit settlement details, the TFM processor sends a message specifying the details of the trade and the Allocation details to this third party. This enables the substituting party to submit the settlement details to the TFM processor.

> Error messages indicating the reasons for failure will be sent if there are any validations failures. An enor message can be at the level of the entire allocation message submitted by the IM if the message fails the total allocation quantity check. Error messages can also be at the level of an individual Allocation if they fail any content check (e.g., invalid GC identification, etc.)

Allocation acceptance success messages will be sent when Allocations are successfully accepted by the TFM processor. The acceptance success messages are at the level of each individual allocation submitted.

> When the block trade is fully allocated a Status Change message, indicating that the trade is fully allocated is sent to both the IM and the B/D. This message to the B/D is sent only after the trade is matched. The data structure diagram of FIG. 11 summarises the input and the output messages utilized throughout the above-described Allocations process.

Step Out Trades

A trade where the IM instructs the executing B/D (step out broker) to allot a portion of the trade to another B/D (step in broker) is called a "step out trade." The IM generally allots these trades to satisfy soft dollar arrangements it has with the step in brokers. The executing B/D who receives (buy trade) or delivers (sell trade) all the quantity of the trade and breaks out the trade according to the direction of the IM is called "step out broker." A non- executing B D indicated by the IM on one or more Allocations who is responsible for the delivery of the quantity allotted in the Allocation is called a "step in broker. " As part of an Allocation message, the IM will indicate whether a particular Allocation has to be stepped out. If the Allocation has to be stepped out, the message indicates the identification of the step in broker. Upon receipt of the stepped out Allocation, the TFM processor will update the current trade quantity by the stepped out quantity and create new alleged trade details for the stepped out quantity. The trade details for the new alleged trade (BON) and the Allocation details will be sent to the step in broker. The step in broker will submit the trade details (NOE) to affirm that the trade stepped out in its favour. The TFM processor will mark the Allocation sequence number of the original block trade as stepped out. Any deletions or replacements of the original trade will not impact the new trade created for the step out Allocation. The alleged new trade created by the step out Allocation will have a TFM processor-generated trade reference number (starting with "T"). This will be treated as a completely new trade and any deletions or replacements will be independently applicable to this trade. The link between the original block - trade and the new trade, arising out of step out, will be maintained at the Allocation level ofthe original trade.

The step out/in brokers can specify in their profiles as to whether the Broker-to-Broker transaction relating to the step out trade should be handled by the TFM processor. Based on the profiles of the step out/in brokers, the TFM processor will also create new (if both step out/in B Ds indicate that they want to handle the broker-to-broker leg using the TFM processor) Broker-to-Broker trade details for the step out trade between the stepped out broker and the step in broker. The TFM processor will send these details on behalf of the stepped out broker to the step in broker. The step in broker in turn will submit the trade details to affirm the trade. This Broker-to-Broker trade will be treated as a completely new trade and all processes will be independently applicable to this trade. The information flow diagram of FIG. 12 explains "step out" trades from the perspective of a "stepping-in" B/D.

Example:

> IM, ABC places a buy order with broker XYZ for 100,000 VOD.L.

> The Allocation details are as follows:

Quantity Account Name Step out indicator

10,000 A 123 None

30,000 B 456 None

10,000 C 789 Step out to B/D 1

30,000 D 012 None

20,000 E 345 Step out to B/D 2

> Upon receiving the Allocations, the TFM processor changes the quantity of the trade between ABC (IM) and XYZ (B/D) to 70,000 (trade quantity 100,000 - step out quantity 30,000) > The TFM processor informs the stepped out broker of all the Allocations including the Allocations that were stepped out. The TFM processor creates a Notice of Pending transaction against B/D 1 (Step in broker 1) for 10,000 shares of NOD.L at the executing price with ABC (IM). The TFM processor creates a Notice of Pending transaction against B/D 2 (Step in broker 2) for 20,000 shares of NOD.L at the executing price with ABC (IM).

> Both the steps of brokers B/D 1 and B/D 2 should submit Notices of Execution (sell) messages with ABC as a counteφart for the trades stepped out in their favour and for which the TFM processor has sent out a notification message (a Notice of Pending Transaction).

> The TFM processor will also create the following Broker-to-Broker transactions: > Seller XYZ Buyer B/D 1 10,000 VOD.L

> Seller XYZ Buyer B/D 2 20,000 VOD.L

> Both the transactions will be at the executed price of XYZ. Execution of the original block trade and a notice of pending transaction are sent to B/D 1 and B/D 2. > Both the step in brokers B/D 1 and B/D 2 should submit the Notice of Execution (buy) with XYZ for the trades stepped out in their favour and for which the TFM processor has sent a Notice of pending transaction.

> B/D 1 will submit the Net Proceeds details for 10,000 shares, B/D 2 will submit the Net Proceeds details for 20,000 shares and XYZ will submit the Net Proceeds for the remaining Allocations of 70,000 shares. They will also submit the settlement details for these Allocations respectively.

> ABC (IM) will submit the Net Proceeds details for all the Allocations and the GCs for the allocated client will submit the settlement details.

> The Broker-to-Broker deal between B/D 1, B/D 2 and XYZ will be treated like any other Broker-to-Broker deal. The TFM processor will create this Broker-to-Broker deal based on the profile settings of Broker XYZ, B/Dl and B/D2.

Percentage Allocations The TFM processor need not support percentage Allocations.

Allocations may be received as an absolute quantity.

Variations

The impact of various transaction types during the Allocation process are as follows:

Pre-Allocated Trades

The IM and the B/D will indicate in their respective BON and NOE messages that the trade is a pre-allocated trade and then the Allocations will be submitted by the B/D. The B/D will submit the list of Allocations to the TFM processor on behalf of the IM, if the B/D has an agreement to do so with the IM. If the B/D submits Allocations on a trade that has not been indicated as pre-allocated, the allocation message will be rejected by the TFM processor. Typically for basket/portfolio or program trades, the B/D will submit the Allocations. The B/D submits the Allocations to the TFM processor for the trades for which it has received Allocations outside the TFM processor environment from the IM.

The B/D can submit the Allocations to the TFM processor either with the Notice of Execution as a multi-part message or by a separate message. The B/D can also submit Net Proceeds along with these Allocations. For a given trade, the Allocations can come from either the IM or the B/D. However, there will be no possibility of allocations coming from both the IM and the B/D (i.e., some of the Allocations coming from the B/D and remaining coming from the IM). If the IM submits Allocations for a trade that has been identified as pre- allocated, the Allocation message will be rejected by the TFM processor. Similarly, if the B/D submits If the TFM processor receives Allocations for a trade that has not been identified as a pre-allocated trade, the TFM processor will reject the Allocations.

The Allocation details coming from the B/D will have the details of the IM Client Account, but the B/D may or may not provide some details of Allocations (i.e., the GC Id, the GC Client Account Number, commission type,. Broker of Credit, etc). The TFM processor, on receipt of Allocation details from the B/D, will forward the incomplete Allocations to the IM. The IM will complete and enrich the Allocations by submitting a new Allocation message with the particulars of the GC Id, the GC Client Account Number, FX-related instructions, Commission type, etc. This will complete the Allocation process. The IM cannot change the quantity ofthe Allocations submitted by the B/D.

The B/D can also submit a complete Allocation message. If the B/D has submitted the Allocations, complete with the GC particulars, the TFM processor will send a Notification of Allocations to the IM. With reference to FIGs. 13 and 14, the B/D can replace the Allocation particulars it has submitted. However, the IM cannot replace the quantity of the Allocations submitted by the B/D.

Broker-to-Broker Trades The aforementioned allocation process need not be utilized for Broker- to-Broker Trades. Instead, the TFM processor proceeds directly to the net proceeds and settlement details matching processes for Broker-to-Broker trades.

Fund-to-Fund Trades A Fund-to-Fund trade is reported to the TFM processor as two independent trades with a common link reference number and a common B/D. The TFM processor will receive Allocations from the IM and process them like any other institutional cross-border trade. No process change is envisaged for Allocation processing for fund-to-fund trades. This information flow process (refer to FIG. 15) enables Allocations on the buy side of the fund-to-fund trade, and Allocations on the sell side of the fund-to-fund trade, to be cleared by an agent ofthe IM (common Virtual Broker).

Basket/Portfolio or Program Trades This trade type carries a unique basket reference number. The trade details relating to every security comprised in the basket will be linked with this basket reference number given by the B/D. The IM provides allocations on an absolute basis for each security contained in the basket. Each allocation message has the particulars ofthe separate securities contained in the basket.

3. Net Proceeds Processing

Subsequent to the submission of allocations, the IM and the B/D submit the net proceeds details to the TFM processor. There can be a third-party substitution on behalf of the IM or the B/D. The IM and the B/D calculate the net proceeds for each allocation to the block trade. The net proceeds are computed after adjusting for various charges such as commissions, fees, taxes, other, etc., from the gross proceeds. The net proceeds from the IM and the B/D are matched either exactly or within tolerances before they are released to the local market. The approach to tolerances respects the operational preferences of as many parties as possible while at the same time enabling the maximum number of transactions to flow through the system without intervention. The optimal approach also limits the number of required adjustments to internal records, particularly if such adjustments are not material in nature.

TFM processor Functionality

The TFM processor accepts and matches the net proceeds submitted by both the IM and the B/D. The net amounts can match within market and user tolerances set by the participants. If a user tolerance match is outside the market tolerance, then the non-prevailing party will be informed of the prevailing amount and one net amount figure is released to the local market. This will ensure that the trade matches in the local market. The TFM processor will not change the underlying details such as commissions, fees, taxes, or the like. The TFM processor notifies the affected party ofthe net amount change so that they can adjust their internal records accordingly. In such cases, the TFM processor will populate a field indicating the amount of the net amount difference. This will provide the participant with the discretion to adjust elements of its internal records (commissions, fees, taxes, etc.) as is appropriate.

Input Information

The information flow diagram of FIG. 16 sets forth illustrative information received by the TFM processor from the IM and the B/D pursuant to the Net Proceeds Matching Process. This information informs the TFM processor ofthe net proceeds details. The B/D and the IM can submit net proceeds details for some or all of the Allocations as part of a single message or through multiple messages.

Net Proceeds Message Acceptance The TFM processor timestamps the incoming Net Proceeds details on receipt and assigns a unique receipt reference number for the message. The TFM processor also validates the message for syntax and performs the necessary edit checks. If there are any errors detected during the syntax or edit checks, the TFM processor sends an error message indicating the reasons for error to the sender of the message. The TFM processor also performs the necessary mathematical checks to ensure the accuracy of the information submitted by the participants (i.e., Net proceeds equals gross proceeds plus or minus all charges such as commissions, fees, etc., depending on the whether the IM is buying or selling.) The TFM processor also computes the gross proceeds for the allocation based on the price for the block trade and the allocated quantity. The TFM processor will validate if the computed gross proceeds amount is the same as the one specified by the participant. Since the price can be quoted with a precision of 10 decimal places and the gross proceeds can only be specified with a precision that is the maximum allowed for the settlement currency, due to rounding errors the comparison may not be exact. The TFM processor will compare the gross proceeds computed and the one supplied by the participant within a tolerance value that will address this rounding issue. If the comparison within the tolerance value fails the TFM processor will reject the net proceeds.

Net Proceeds Match

If both the syntax and edit checks are successful, the TFM processor attempts to match the net proceeds amounts submitted by each party at the allocation level. The following fields are used by the TFM processor to compare the net proceeds details at the allocation level:

> TFM processor Match Reference Number

> Allocation Sequence Number

> IM Client Account Number or GSTPA Account Number > Allocation Quantity

The above comparisons look for exact matches. In addition, the following field is matched, either exactly or within tolerance, at the allocation level:

> Net amount For puφoses ofthe match, the net amount in settlement currency is used.

The charge types (i.e., Commissions, Taxes, Fees, Stamp Duty and other charges) are not matched but are available to assist with repairs in the event of a mismatch ofthe net amounts.

Tolerance Match Tolerance matches are performed at two levels:

• Market (Maintained by a TFM processor administrator, for every settlement location/settlement currency combination)

• Participant /User - Bilateral (Maintained by a participant for specific counteφarts)

- Unilateral (Maintained by a participant for all counteφarts)

The tolerances for the net proceeds match may be percentage based, absolute or a combination thereof. In a combination situation, tolerance is a percentage of the settlement amount subject to a limit in absolute value for the settlement currency. For example, the tolerance can be specified as follows: Percentage tolerance: 0.1% subject to an upper limit of 50 USD.

Market Tolerance Match A key feature of the TFM processor is that the net amount released to the local market will match within local market tolerances. Therefore, net amounts are first matched based on market tolerance. The market tolerance is maintained at the following level: • Settlement Location • Settlement Currency

If the net amounts match within the local market tolerance, the trade allocation flows through the system even if the net amounts and underlying details are slightly different. This will ensure that the trade allocation will match in the local market and will avoid a situation where one party will need to adjust its internal records for immaterial discrepancies. The TFM processor will use the settlement location specified on the NOE to determine which market tolerance to apply. However, during the settlement details enrichment process, a settlement location other than the one specified in the NOE may be agreed upon between the B/D and the GC or the GC could propose a bridge location that is compatible. If a settlement location is proposed by the GC which is different from the one specified in the NOE, and the net proceeds have matched within market tolerance, then the TFM processor will re-attempt a net proceeds match with the details of the GCs proposed different settlement location or with the details of the bridge between the GCs proposed location and the settlement location specified by the B/D in the NOE. The TFM processor will only re- attempt the Net Proceeds match if the market tolerance for the new settlement location is lower than the market tolerance for the previous settlement location.

Example 1

For a trade allocation,

Buyer Amount is 500

Seller Amount is 525 Market tolerance is 25

This is treated as a MATCH.

Example 2

For a trade allocation, Buyer Amount is 500

Seller Amount is 530

Market tolerance is 25

This is treated as a FAILED MATCH within market tolerance. However, they may match within user tolerance established in the participant profiles of the buyer and the seller.

User Tolerance Match

User tolerances are specified in participant profiles. Participants' tolerances will be the same or larger than market tolerances. If the net amounts are within user tolerances, the trade allocation flows through the system. FIG. 17 is a Prevailing User Tolerance Decision Table for determining the tolerance to be applied on the buyer's and the seller's side for the puφose of matching the net proceeds within a user-defined tolerance. The decision table of FIG. 17 should be utilized because none, one, or both of the following user tolerance values may be specified for the buyer and the seller:

• Bilateral tolerance

• Unilateral tolerance.

The following examples illustrate the manner in which the Prevailing User Tolerance Decision Table of FIG. 17 may be employed:

Example 1

Buyer A has set the following in the participant tolerance profile: Bilateral tolerance value for Seller Bfor the net proceeds: 50 USD Unilateral tolerance value for the net proceeds: 30 USD

Seller B has set the following in the participant tolerance profile: No bilateral tolerance value set for Buyer A for the net proceeds Unilateral tolerance value for the net proceeds: 25 USD

As per the above decision table, the following tolerance values are applicable: Buyer A: 50 USD Seller B: 25 USD

Example 2 Buyer X has set the following in the participant tolerance profile: No Bilateral tolerance value set for Seller Yfor the net proceeds Unilateral tolerance value for the net proceeds: 25 USD

Seller Yhas set the following in the participant tolerance profile: No Bilateral tolerance value set for Buyer Xfor the net proceeds No Unilateral tolerance value set for the net proceeds

As per the above decision table, the following tolerance values are applicable: Buyer X: 25 USD Seller Y: 0

If there is a match within user tolerance, the TFM processor will ensure that the same net amount will be released to the local market for both the IM and the B/D. If a match of the net amounts occurs within user tolerances, but not exactly, the TFM processor will indicate the net amount difference for the non- prevailing party. The non-prevailing party will be made aware of the discrepancy so that they can adjust their internal records. For this puφose, each participant will specify one of the following three preferences in their profiles: 1. Always use my amount in the event of a match within user tolerance (Mine)

2. Always use my counteφart's amount in the event of a match within user tolerance (Counteφart's).

3. I am neutral as to which amount prevails (Neutral).

(It is recommended that B/Ds set their preferences to Neutral.)

FIG. 18 is a decision table for determining the prevailing amount of the trade and the match status for each of various user tolerance match results. The various scenarios have been explained with examples, which are referenced in the table. FIG 19 is a flowchart that depicts the Net Proceeds Matching Process as implemented by the TFM processor.

FIGs. 20-39 set forth examples of various Net Proceeds Matching

Process results as determined by the process of FIG. 19. Basically, if the matching process "fails", the TFM processor stores the net proceeds details received and the allocation with a status of "Net Proceeds Match Fail." The TFM processor notifies both parties about the match failure and the need to correct the Net Amounts.

If the comparison succeeds, then the TFM processor stores the details ofthe net proceeds details received and the allocation with the status as "Net Proceeds Matched."

If there is no Net Proceeds message available for the trade allocation from the counteφart, depending on the processing preferences of the counteφart, the TFM processor may send a notice of pending transaction for Net Proceeds.

Outputs

The following are possible outputs generated by the TFM processor pursuant to the Net Proceeds Matching Process: Error Messages indicating the reasons for failure will be sent if there are any validation failures along with the net proceeds details received by the TFM processor. A notice of pending transaction for Net Proceeds will be sent to the counteφart if the counteφart has not submitted the net proceeds.

> A Net Proceeds acceptance message will be sent to the IM or the B/D when the Net Proceeds are accepted by the TFM processor along with the details of Net Proceeds message received.

> An Error message indicating reasons for error will be sent if there are any match errors and there will be a comparison of ail the components that constitute the net proceeds. A status change message will be sent to the IM and the B/D once all the Net Proceeds have matched.

If there is a match, the following notification is sent to the IM, the B/D and the GC: Trade Match Reference # > Trade Reference # > Trade Version #

> Allocation Sequence # Trade Allocation Version # Net Proceeds Version # > IM Client Account #

> GSTPA Account # Allocation Quantity Settlement Currency

> *Prevailing Party Identification > *Prevailing Net Amount for the Allocation

> *Prevailing Party's Gross Amount for the Allocation *Prevailing Party's Broker Commission *Prevailing Party's Accrued Interest *Prevailing Party's Local Taxes > *Prevailing Party's Stamp Duty

> *Prevailing Party's Registration Charge

> *Difference between the Prevailing Party's Net Amount and Party's Net Amount

*In the case of the exact match, the IM and the B/D will get their own amounts and the difference amount will be set to zero and the GC will get the IM's amounts. In the case of a match within market tolerance, the IM and the B/D will get their own amounts and their counteφarts amounts to facilitate reconciliation and the GC will get the IM's amounts.

Variations

There are variations inherent in the Net Proceeds Matching Process for different types of transactions. The following types of transactions illustrate some ofthe possible variations: Broker-to-Broker Trade

As there are no allocations in Broker-to-Broker trades, the TFM processor will create a dummy allocation. The B/Ds could have given the net proceeds details along with the block trade details as part of a multi-part message. In this case the TFM processor, after successful acceptance of the block trade details, will invoke the net proceeds process.

4. Accounting Information Processes

Many of the data elements used to effect the settlement of a trade are also used for accounting puφoses. In addition, there are a very small number of optional data elements that are specific to the accounting function. The IM supplies these data elements along with a Block Order Notification message.

The IM may also send an Allocations message and/or a Net Proceeds message to the TFM processor, and/or the IM may receive an Allocations message and/or a Net Proceeds message from the TFM processor. Using the information (BON, allocation, net proceeds, accounting details), the TFM processor creates an "accounting message" to route the accounting information to the Accounting Agent at, or before, the deadline. The Accounting Agent is an entity that provides accounting services to a Portfolio, a Fund or a Client that is served by the IM. There could be more than one Accounting Agent

(Interested Party) associated with an account. Accounting data may also be delivered to other interested parties, who are identified by the IM in its profile.

Accounting Deadline The IM and Accounting Agent maintain deadlines in their profiles for sending the accounting information to the Accounting Agents. Refer to the Profiles section and the Alert and Deadline Processing section for the details on deadlines for accounting information. Accounting Data

> Input Message

The IM will send the accounting data at the level of the BON, Allocations and Net Proceeds messages. The TFM processor does not perform a validation check on these accounting-specific fields, except for syntax. The input data for accounting is included with the BON, Allocations and Net Proceeds message inputs described in the earlier sections.

> Output Message

The TFM processor sends the accounting information to the Accounting Agent before or at the deadline set for the IM's client. The accounting information includes the accounting data that is sent by the IM as well as the TFM processor-enriched data for the trade, the allocation and the net amount details (quantity, price, gross amount, net amount, commission, fees, tax and interest, etc.) Please refer to Appendix C for the data elements that will be sent to the Accounting Agent.

The accounting data is sent to the Accounting Agent at or before the deadline in the following cases:

> The net proceeds have been matched in the TFM processor and the IM has provided the accounting information. This is referred to as the confirmed reporting to the accounting agent. (This information is sent immediately, prior to the deadline.)

The IM has submitted the allocations, the accounting information and the net proceeds. In this case, the Accounting information is released to the agent based on the IM's data. The message to the Accounting Agent will indicate that the net proceeds have not matched. This is known as unconfirmed (soft) reporting to the Accounting Agent. This information is sent at the deadline according to the IM's profile.

> The accounting information and the net proceeds details have been submitted, however, the net proceeds ofthe B/D and the IM do not match. In this case the TFM processor releases the accounting information based on the IM's net proceeds data, or the B/D's net proceeds data, depending on what the IM has set in the profile for that client and Accounting Agent. The TFM processor sends a warning message to the IM and the Accounting Agent that the net proceeds have not matched (This information is sent at the deadline according to the IM's and Accounting Agent's profiles.) This is also referred to as unconfirmed (soft) reporting to the Accounting Agent.

> In the case where the net proceeds have not yet matched, the TFM processor will send a confirmed reporting to the Accounting Agent once the net proceeds match. The Net Amounts could change the financial components of the settlement data and thus also impact the accounting data. When this occurs, the changed details are released to the Accounting Agent, and will be identified as a change to the previous unconfirmed reporting done by the TFM processor. (This will lead the Accounting Agent to reverse the trade in its records and to re-book it.)

> If there are any replacements or corrections to a trade, the allocation, or the net proceeds details, the changed details are notified to the Accounting Agent. The TFM processor will also clearly indicate if the change is on an unconfirmed (soft) reporting or a confirmed reporting done by the TFM processor. This may cause the Accounting Agent to reverse the trade in its records and to re-book it.

The IM can unilaterally replace the accounting-specific data. The TFM processor then releases the replaced message to the Accounting Agent. (This will lead the Accounting Agent to reverse the trade in its records and to re-book it.)

Identification of the Accounting Agent

Some of allocations will not require additional accounting data, nor will there be an Accounting Agent identified for them. For those allocations that require accounting data to flow to an Accounting Agent, it is necessary to identify the specific Accounting Agent related to the account in the allocation. There could be more than one Accounting Agent associated with an account. This can be done either by having the IM maintain such a list in the profile (account by account), or by asking the IM to provide the Accounting Agent's identifications and deadlines with the allocation.

The TFM processor timestamps the incoming settlement details message upon receipt and assign a unique receipt reference number for the settlement details. The TFM processor also validates the message for syntax and performs the necessary edit checks. If there are any errors detected during the syntax or edit checks or context validation, the TFM processor sends an error message indicating the reasons for error to the sender ofthe message. If the validation is successful, the settlement details are accepted and the TFM processor proceeds to match the settlement details if the corresponding settlement details have been provided by the counteφart.

Matching Process The matching block will be used to compare the settlement details at an allocation level; otherwise the following fields must be used for matching:

> Trade Match Reference Number Allocation Sequence Number > IM Client Account Number

> Allocation Quantity

> Security identification

> Settlement Date > Settlement Currency

> Method of settlement

If the above comparisons result in an exact match, then the TFM processor performs the comparison ofthe settlement location details provided by the B/D and the GC.

If the B/D and the GC have specified the same settlement location then the TFM processor sets the status of the allocation as settlement channel compatible, provided that the settlement details confirm to the settlement location characteristics (e.g., DVP in France against Euro is valid; not against USD). Further, if the Agents at the settlement locations are the same, the "SAME AGENT" flag is turned on. This informs the participants that the settlement may happen in the books of the same local agent at the settlement location.

> If the settlement location is not the same, the TFM processor performs a compatibility check for a possible Bridge Link between the locations for the settlement currency and security categories by referencing the TFM processor's settlement bridge table and the profiles of both the B/D and the

GC.

The following information is_. maintained for the Settlement Channel Compatibility in the TFM processor: > Settlement Location Identifier

> Other Compatible Settlement Locations (Settlement Bridges)

> For each bridge: > Supported settlement currencies

> Category ofthe securities supported

> Securities agent and account details

> Cash agent and account details Transaction type codes used for the Bridge. Settlement between the Settlement Locations

If the settlement channel compatibility is established through a Bridge Link, the allocation status is set to Settlement Channel Compatible.

The TFM processor modifies the settlement details as provided by the B/D and the GC to reflect the conditions of a particular Bridge Link. These include modification ofthe following details:

> Addition of Bridge Securities Agent details > Addition of Bridge Cash Agent Details

> Addition of Transaction Code for the Bridge settlement

If there is no bridge settlement channel compatibility between the settlement locations for the settlement currency and security category, then the allocation status is set as Settlement Channel Incompatible. The B/D and the GC may change the settlement location appropriately to make the settlement channel compatible.

In certain markets, the B/Ds may need the settlement details from the GC before they can submit their part of the settlement details. B/Ds in their profile will specify for each settlement location whether they need the settlement details ofthe GC before they can submit their settlement details.

If the B/Ds have set-up their profiles to indicate that the TFM processor need to send them the GC settlement details once the settlement details are received from the GC, the TFM processor will "push" a message to the B/D with the details of GC Settlement Details.

Example:

The B/D sells a French bond and wants to deliver from its Euroclear account

6789.

The Settlement Location is Euroclear.

The settlement details from the B/D will indicate:

DVP

Euroclear (location)

Euroclear (agent)

Account 6789

The GC wants to receive securities in its account ABCD at Paribas. The trade is for the benefit of client account 1234 at the GC indicated in the allocation.

The Settlement details from the GC will be: DVP France Paribas Account ABCD

The Bridge table confirms that this transaction in Euros can be conducted through the Bridge from Euroclear to France, using the Euroclear correspondent in France (Societe Generale).

Account XYZ of Euroclear at Societe Generale for cash and securities.

As a result of this, an instruction will have to be sent by the GC in the SWIFT format that includes the following information about Bridge details:

Receive

From Societe Generale Account XYZ

By order of 6789 at Euroclear French Bond Against XXXXEuros In favor of 1234 at GC

The B/D will send instructions to Euroclear as follows:

Deliver

To Paribas Account ABCD

In Favor of 1234 at GC

French Bond

Against xxx Euros

By order of 6789 at Euroclear

As can be seen, the settlement details of the B/Ds AND information from the bridge table were used to construct these messages.

In the case of DSP trades, the TFM processor will generate only the securities movement instructions and not the cash movement instructions. In the case of FOP trades, TFM processor will generate only securities movement instructions.

Output

The following are the outputs from this business function. The message is routed to the appropriate participant access module (participant AM) based on the routing profile set by the participant. If the substituting party has submitted the message, then the message is sent to the substituting party.

Success message: is sent, along with the settlement details received by the TFM processor, if the participant has specified in the profile that they wish to receive these messages.

An Error message: indicating the reasons for validation failure, is sent if there are any validation failures, along with the settlement details received by the TFM processor.

> GC Settlement Details: is sent to the B/D, if the B/D has indicated in its profile that it needs the GC Settlement details prior to submitting its settlement details.

> Settlement Match Notification: if settlement details match, a message is sent to both the GC and the B/D. Any match warnings and changes to the settlement details on account of bridge settlement are also notified to the participants along with the match notification message.

> Settlement Release Details: a notification message is sent to the B/D and the GC with settlement release details. > If all the allocations of the block trade settlement details have matched, the TFM processor sends a status change notification to the B/D and the IM stating that all the allocations settlement details have matched.

Settlement Match Notification

If settlement channel compatibility is achieved, the following notification message is sent to the GC and the B/D

> Trade Match Reference #

> Trade Reference # > Trade Version # Allocation Sequence # Allocation Version #

> Settlement Details Version #

> IM Client Account # > Allocation Quantity

> Settlement Details

> Identification ofthe clearing organisation

> Settlement Currency Settlement Location of GC > Settlement Location of B/D

> Settlement Type Flag (FOP or DVP)

> Same Agent Flag

> Local Agent Details ofthe B/D > Security Agent at Location > Local agent identification with the clearing organisation

> Securities Account at Agent

> Cash Agent at Location

> Cash Account at Agent

> Local Custodian details of the GC

> Security Agent at Location

> Local agent identification with the clearing organisation Securities Account at Agent

> Cash Agent at Location

> Cash Account at Agent

> Transaction Code to indicate Bridge Settlement > Warning Field

> Warning Code

Settlement Release Details

The TFM processor sends a notification message for the settlement release details at an allocation level to the GC and to the B/D. This message will be sent once the Allocation has been matched for both the settlement details and Net Proceeds Details.

The Settlement Release message provides the following details.

> Trade Match Reference #

> Trade Reference # Trade Version # > Allocation Sequence # > Allocation Version # Settlement Details Version #

> IM Client Account Number

> Security Identification > Trade Price (Seller's Price)

> Allocated Quantity Trade Date

> Settlement Date

> Settlement Details Identification ofthe clearing organisation Settlement Currency Settlement Location ofthe GC

> Settlement Location of the B/D Physical Address

> Transaction code if there is a Bridge Settlement

> Settlement Type Flag ( FOP, DSP or DVP)

> SAME AGENT flag

> Free flow information

Prevailing party's Settlement Amount details (if net proceeds match within tolerance) or IM's Settlement Amount details

> Gross Amount Net Amount Components ofthe Net amounts

> Difference between the IM's amount and the B/D's amount

> Local Agent Details ofthe B/D _.

> Security Agent at Location Local Agent identification with the clearing organisation > Securities Account at Agent Cash Agent at Location

> Cash Account at Agent

> Local Custodian details ofthe GC Security Agent at Location Local Agent identification with the clearing organisation

> Securities Account at Agent

> Cash Agent at Location > Cash Account at Agent

Note - These outputs will be adapted to reflect the bridge information

Variations

Broker-to-Broker Trade

In Broker-to-Broker trades there will be no allocations. Both B/Ds can also provide the Settlement details as part of the NOE message or through a separate message. There is no specific process change.

Fund-to-Fund Trade

The Fund-to-Fund trade is reported to the TFM processor as two independent trades that can be linked with a common link number. Two legs of these trades are settled via the intermediate counteφart. No process change is envisaged for settlement details processing. 6. Forex Processing

IMs carry out Forex (Foreign Exchange) Processing on behalf of their clients to handle either the settlement required for the security trades or independent of any security trades. Even though the TFM processor will not support Forex trades for regular processing, like Block Trade, Allocations, etc., this information needs to flow to the GC and Accounting Agent for information and action.

TFM processor Functionality

The TFM processor will receive a free-flow Forex message from the IM. This • message will have the necessary details about the Forex carried out by the IM, the clients on whose behalf the Forex has been carried out and if necessary any • associated security transaction reference numbers. The information supplied by the IM will be similar to the MT 304 message format. The format has been adjusted for the TFM processor requirements.

IMs will be able to send the spot and the forward Forex contracts to the TFM processor. For the forward contracts participants will need to submit the opening, partial closing (if any) and final closing of the forward contracts as separate trades with unique Forex trade reference numbers. The IM must always provide complete information in the opening and closing of Forex contracts. The TFM processor will not carry out any validations between the opening and closing contracts and will not carry forward any information between the opening and the closing Forex trades. The information supplied by the IM will be sent to the GC and the

Accounting Agent associated with the Client.

Input Information

The following is the information provided by the IM to inform the TFM processor about Forex information.

The following table describes the information provided by the IM:

FIG. 42 The TFM processor will validate the input message for content and format. On successful acceptance of the Forex trade message, the TFM processor will send a similar Forex trade notification message to the GC and the Accounting Agent identified for each allocation in the message.

The outputs to the GC and the Accounting Agent will be at the level of each individual allocation ofthe Forex trade.

Outputs

The following are the outputs from this process:

A success message to the IM indicating that the Forex trade has been accepted by the TFM processor

> An Error message to the IM for each Forex trade allocation that fails validations

> A Forex notification message to the GC and the Accounting agent for each allocation associated with the Forex trade.

7. Cancellations. Replacement and Deletion Processing

Principles

• A transaction should only be cancelled as a last resort because:

— This will create extra work for everyone who has worked on the trade to re-instate their information on a new transaction

— Creating a new transaction with a new participant trade reference number would break the audit trail and limit the value of the MIS provided by the TFM processor (e.g., all timers would be reset). This is true even at the NOE / BON level where there may be price or commission changes which do not invalidate the entire ' transaction • The normal process for agreeing changes to matched trades will rest outside of the TFM processor with only the final results flowing through (i.e., in most cases telephone conversations are required to negotiate a change)

• Non-matching fields are as significant as matching fields since they are only included in the TFM processor so that they can be communicated between parties for subsequent action

• All changes to a message (replacement, deletion and cancellation) will be immediately communicated by the TFM processor to all parties who received the original message • The functionality of the TFM processor should not be driven or constrained by the systems capabilities or working practices of the participants

• Only the originating party of a message should be able to change it.

Options

The IM or B/D can cancel a trade, which terminates the transaction history in the TFM processor. Data is resubmitted with a new participant trade reference number. This function is used when a trade was created in error or when a trade has matched with the wrong counteφart and needs to be re- entered with the correct counteφart. However, all participants may not have the capability in their internal application systems to effect a replace when only some ofthe particulars ofthe trades need to be modified. Some participant may also use cancellation and resubmission to correct any mismatches. These participants' internal application systems will generate a cancellation and resubmission to effect the modification. In such cases, to support participants in tracking MIS, the TFM processor will allow the participants to link new trades to an existing cancelled trade. The TFM processor will inform counter parties and GC about the linked cancelled trade reference number. This will allow participants to keep track of the cancellation and the resubmission of the trades.

The IM, the B/D or the GC can delete a single message they have sent at the level of an individual allocation. This option applies to all allocation level messages (Allocations, Net Proceeds and Settlement Details) and removes the message leaving all others intact and maintains the audit trail in terms of the participant trade reference number. However, deletion of allocations will cascade to Net Proceeds and Settlement Details as well.

The IM, the B/D or the GC can replace a single message they have sent with an entire new message. This option applies to all messages (NOE, BON, Allocations, Net Proceeds, Settlement Details, etc.) and changes one message at the level of an individual allocation leaving all others intact and maintains the audit trail in terms of the participant trade reference number. In this case the entire message is replaced with a new one (This function will not support changing a single field within an allocation although clearly users will edit single fields on their workstation before resubmitting entire messages.) Finally, participants might need to revoke a requested cancellation when it has not taken effect and is awaiting a corresponding cancel from counteφart. This revoke can only be used when approval is pending from counteφart.

Approvals and Paired Vs. Matched The cancellation of a trade requires approval after the trade has been

"Matched." The submission of the cancellation request by the counteφart will be treated as the approval of the cancellation request. If participants mistakenly cancel the wrong trade, they will have the provision to revoke their cancellation.

For replacement or deletion, there will be no special approval messages supported by the TFM processor. The party making a change will submit the replacement message that the TFM processor will attempt to match with the existing counteφart's message. If a match does not occur, the TFM processor will move the trade or the allocation to a "paired" status. When "paired," if the counteφart submits a matching replace/delete message then the new values will be deemed to have been 'approved' and the new messages will update the TFM processor. The trade or the allocation will now change from "paired" status to "matched" status. All alert and deadline processing will continue to apply for a paired trade.

If the block trade is paired, subsequent matches will not be attempted by the TFM processor. For example, if the Block Trade is paired due to a price change, new net proceeds submitted by the participants on the paired trade will not be matched. This match will be triggered once the block trade becomes matched (i.e., due to a matching replace from the counteφart).

Cancellation of Trade The IM and the B/D can cancel the Trade at any time during the life cycle of the trade. However, a cancellation request needs an approval from the counteφart, if the trade has been matched.

• The format of the cancel message will have the complete format of the NOE or BON message with function of the message as "CANC" and will trigger a cancellation.

• The cancellation of an unmatched trade becomes effective immediately with no approval needed from the counteφart.

• In the Matched Trade Status, the cancellation submitted by one party needs to be approved by the counteφart. The intermediate status of the trade will be "Matched Cancellation Requested" and will be set to "Cancelled" only when approved. The second cancel trade message submitted by the counteφart is treated as an approval to the first cancel trade message and the trade status is set to "Cancelled." • The details of the trade submitted as part of the Cancel Trade will be compared with the existing trade details to validate the integrity of the Cancel.

• All GCs and the interested parties pertaining to the allocations of the trade are notified of both cancellations requested by IMs and the Cancellation of the trade by the TFM processor after approval by the B/D. The GC and the

Interested Parties will not be notified of any cancellations requested by the B/D. However, the GC and the Interested Parties will be notified of the cancellation ofthe trade after the IM approves the cancellation.

• The Cancellation status ofthe trade flows to the individual allocations.

Additional Features:

• Revoke a Cancellation: A cancellation submitted by a party can be revoked by the same party by using "REVC" in the function of the Trade Message (NOE or BON). The revoke will be effective only when the approval is pending (Trade status = "Matched Cancellation Requested") and not after actual cancellation has taken place. If a cancellation is revoked all the participants who have received prior information about the trade and its allocations will also be informed about the revocation of the cancellation request.

• Reject an unmatched alleged trade: Cancellation of Unmatched trades which are alleged against a participant can be done by using "REJM" in the function of the Trade Message. A Trade in this state is "Rejected." The final cancellation of the trade will be after an approval via a cancellation message from the participant alleging the trade. This will be used for the DKs. Similar to a revoke of a cancellation, the rejection of an alleged trade can also be revoked by the party submitting the rejection against the unmatched alleged trades.

• Dispute an unmatched alleged trade: Dispute of Unmatched trades which are alleged against a participant can be done by using "REJM" in the function of the Trade Message. In addition to this the disputing participant can provide a reference to one of their unmatched trades indicating that the alleged trade should match against this unmatched trade.

If the IM has requested cancellation, downstream processing of the TFM processor will be effected by way of output messages generated from the TFM processor. Accounting information and settlement release will NOT be sent once the IM has requested for cancellation. The remainder of the outbound messages will always contain the Trade/allocation status. The revoking of cancellation will resend the accounting information to the accounting agent.

The following diagrams explains the various cancellation possibilities and their associated message flows:

Case 1:

A B/D wants to cancel a trade that has not been matched. In this case the B/D has submitted an NOE to the TFM processor (1). The TFM processor has accepted the NOE and has created a trade in an "unmatched" status. (2). The TFM processor has also sent an Alleged NOE notification to the IM (3). Before the IM submits a BON, the B/D realises that the trade is a wrong trade and issues a cancellation (4). The TFM processor immediately cancels the trade as it is in "Unmatched" status and sends a cancelled notification to the B/D (5) and an alleged trade cancelled notification to the IM. FIG. 43 illustrates the flow of information for case 1. Case 2:

An IM wants to cancel a trade that is matched and for which allocations are complete. If the B/D were to initiate the cancellation, the GC will not be notified of the cancellation request. Similarly if any interested parties like accounting agents have received information prior to the cancellation, then the TFM processor will treat them similarly to the GC as illustrated in the diagram. FIG. 44 illustrates the flow of information for case 2.

Case 3:

The B/D has submitted an NOE against the wrong IM. The IM DKs the NOE. The B/D cancels the NOE. FIG. 45 illustrates the flow of information for case 3.

Case 4

The B/D has submitted an NOE with the wrong price. The IM submits a BON with the right price. The IM submits a dispute message against the NOE indicating the reference # of the BON. FIG. 46 illustrates the flow of information for case 4.

Replace Process

The replacement of an individual message will be effective immediately if the message has not been matched. A Replace of an NOE or a BON is possible on an unmatched trade. Similarly, Replace of Allocations is effective immediately if it has not matched on the Net Proceeds or the Settlement Details. A Replace on a matched trade will move the trade into "Paired" status if the replacement message does not match. A Replace on an allocation that is "NP Matched" will move the allocation into "NP Paired." A Replace on an allocation that is "Settlement Details Compatible" will move the allocation into "Settlement^* Details Paired" status. The principle of the replace on the matches at several levels is to retain their matched status or an intermediate status of "Paired. "

Replace NOE /BON A Replace on an unmatched trade will be effective immediately. If the

TFM processor has sent a notice of pending transaction for the unmatched trade the TFM processor will also send an alleged trade replace notification to the counteφart to indicate the replacement.

A Replace on a matched trade will move the trade into "Paired" status if the new message does not match, otherwise it will remain in matched status. The "Paired" status is indicative that a previously matched trade is now being replaced and should not be matched with a different trade (e.g., if the BON is replaced it should only be matched against the original NOE with which it was paired). Similarly the original NOE should not be paired with a different BON.

The following elements of a trade should not be replaced after a match:

• Physical Sender Identification

• Message Type

• Actual Sender Identification • Participant Trade Reference Number

• External Common Reference

• Function of Message

• Transaction Type

• Processing Type • Counteφart Identification

• Buy/Sell Indicator

If any of the above elements change after a match, the participant can cancel the trade and resubmit a new trade. The TFM processor implements procedures to ascertain the integrity of the information that it accepts. For example, Replacement of the Trade Quantity on an NOE or BON is always checked against the sum of the allocation quantity if the allocations have arrived. For a partially allocated trade, the sum of the allocated quantity so far is less than the replaced/revised block quantity. For a completely allocated trade, the sum of the allocated quantity should be equal to the replaced/revised block quantity. Similarly, the TFM processor also recalculates the deadlines if any of the parameters ' affecting the deadlines (e.g., preferred settlement location) is changed.

The TFM processor will notify all the participants who have received information about the BON or the NOE about any replacements. Normally the replacements made by only the IM will be sent to the GCs and the Interested parties. However, if the B/D replaces the settlement location in the NOE, then the GC will be notified of the new settlement location.

The following cases illustrate various replacement scenarios for NOE and BON messages.

Case 1:

The B/D submits an NOE with the wrong price. The trade has not been matched with a BON. The B/D submits a replace to correct the price. Information flow for this scenario is shown in FIG. 47.

Case 2:

In this case the B/D has submitted an NOE with price of USD 75.00. The IM has also submitted a BON with price of USD 75.00. After the NOE and the BON have matched, the IM wants to renegotiate the price as USD 74.00. Information flow for this scenario is shown in FIG. 48.

Replace Allocations The IM can replace the allocations. When the replace/delete is effective, deadlines at the allocation level are either reset in the case of a delete or recomputed in the case of a replace. If the deletion of Allocations changes the trade from fully allocated to partially allocated, then the deadlines at the level ofthe trade for the Allocation completion are re-instated.

If the allocation quantity has changed, the sum of the allocation quantity will need to be verified to determine if it is less than or equal to the block quantity. If net proceeds messages have already been received for any of the allocations the quantities and account numbers must be checked against the new allocation message to ensure that they are consistent. If not, the status on that allocation must be moved to paired. This indicates that although the net proceeds messages may agree with each other, they do not match the revised overall allocation from the IM.

If the GC is changed and a Settlement Details message has already been received from the original GC, the message will be deleted and the status ofthe allocation changed to "Settlement Details Unmatched."

Replacements of other fields in the allocation will only flow as notifications to the GC and the B/D or the IM and will not affect trade status. Notification of Allocation Details replacement will flow to the B/D and the GC. If the GC changes, the new GC is also notified.

Replace Net Proceeds/ Settlement Details

• The IM or the B/D can replace Net Proceeds.

• The B/D or the GC can replace Settlement Details. • Originating Party of the Net Proceeds/Settlement Details message can replace its part of the message and the replacement will be effective immediately, if Net Proceeds/Settlement Details have not yet matched with the counteφarts.

• The TFM processor will receive the first Replace Net Proceeds/Settlement Details message and store the replacement request of Net Proceeds/Settlement Details and will notify the counteφart.

• If the allocation message was matched, the allocation will be put to "Net Proceeds Paired" or "Settlement Details Paired" status if the new message does not result in a match. Otherwise it remains in matched status. The GC receives notification ofthe net proceeds status change.

• If the allocation status is paired, when the TFM processor receives the second Replace Net Proceeds/Settlement Details message it stores the replacement request of Net Proceeds/Settlement Details from this party and the TFM processor attempts a rematch on the replacement messages. • If rematch of both replacement messages is successful (exact match, no tolerances and no bridges), the TFM processor will notify both parties and set the allocation status to "Net Proceeds Matched" or "Settlement Details Compatible." If the Net Proceeds matched, the GC will also receive a notification message ofthe replacement. • No Settlement Release will happen on an allocation that is "Settlement Details Paired" or "Net Proceeds Paired."

• No confirmed accounting Information will be sent for an allocation that is "Net Proceeds Paired."

The Deleting Process

Deleting Allocations

Deletion of individual allocations by the allocating party is unilateral and requires no approval, irrespective ofthe status ofthe allocation. Deletion of an allocation deletes the corresponding Net Proceeds and Settlement Details. All parties are notified of the deletion. This option is to be used when the block trade quantity changes or an allocation is invalid and has to be removed. The approval process has been kept outside the TFM processor, as resubmission of net proceeds and settlement details is mandatory for further process flow. Deleting Net Proceeds/ Settlement Details

Deletion of a Net Proceeds or Settlement Details in an unmatched state is effective immediately. Deletion of a Net Proceeds/Settlement Details message that has matched moves the allocation to "Unmatched Net Proceeds/Settlement Details" status. The counteφart and the GC (in the case of NP) are notified of the change. Also, the settlement release and the accounting information will not be generated from the TFM processor.

Messaging impacts due to cancellation/deletion/replacement process

The following are the general principles followed within the TFM processor to notify the counteφarts, the GCs and the interested parties about any cancellations, deletions and replacements.

> For unmatched alleged trades (after the TFM processor has sent out the Notice of Pending Transaction), counteφarts will receive all the cancellations, the deletions and the replacements. For matched trades, counter parties will receive all the cancellations, the deletions and the replacements so that they can provide the necessary approval. > Counteφarts will receive the cancelled, the deleted, the replaced (via a match) notifications once the TFM processor has accepted and processed the necessary approval.

> The GCs and the Interested Parties (Accounting Agents) who have been notified of the trade and allocation information will receive the cancellations, the deletions and the replacements carried out by the IM.

They will not receive the notification pertaining to the cancellation, deletions and replacements carried out by the B/D. They will receive two when the IM initiates the cancellation or replacement and when the B/D approves the cancellation or the replacement. They will also receive a revoke notification, if the IM decides to revoke their cancellation. GCs who have been notified of settlement instructions in the 52x, 53x or 54x SWIFT message formats may be sent a cancellation message in the form of MT592 if either the trade is cancelled, (i.e., cancellation initiated by IM or B/D and approved by the counteφart), or when the allocations are deleted by the IM. If there is a replacement of any details pertaining to settlement details such as Net Proceeds, the TFM processor will generate a cancellation in the MT592 SWIFT message format followed by a settlemenjt instruction with the changed details in the 52x, 53x or 54x SWIFT message formats.

Alert and Deadline Processing

Alert and Deadline processing in the TFM processor occurs with respect to two distinct processes: • Settlement

• Accounting The alert and deadline process responds (and also escalates, if necessary) to meet the earliest timing requirements of both the settlement and the accounting processes. This is true in cases where the information is required for both processes. If information is required for one of the processes only (e.g., net proceeds are required for both settlement and accounting, settlement details are required for settlement only), then the related deadline applies. In this manner, the alert and deadline process establishes the critical path for the submission of all data in the TFM processor.

Settlement

Alert and deadline processing related to settlement must meet the requirements of the GC and the B/D (or B/D's Agent) in the context of the settlement location involved. Therefore, settlement date and deadline time established by settlement location will serve as the foundation for the alert and deadline process in terms of settlement.

The Deadlines and the associated alerts should be based on settlement date/deadline time minus an amount of time specified by the GC and the B/D in their profiles. The GCs and the B/Ds will also maintain deadlines for cash settlement if the trades are to be settled separately for cash and securities (DSP method of settlement). The deadlines for the cash settlement will be based on settlement date/deadline time minus an amount of time specified by the GC and the B/D in their profiles.

The larger of the amounts of time (i.e., earliest time computed after reducing the amounts of time specified by the B/D and the GC from the settlement date/deadline time) specified by the GC and the B/D (for both cash and securities) will be used. If this profile information is not available for the GC and the B/D, the system default for the given market will be applied. The deadline for the settlement related information could be expressed by the following formula:

Deadline = Market Settlement Date/Deadline Time - GC or B/D or Generic Specified Amount of Time (for cash and securities settlement)

Market settlement Date/Deadline Time will be based on the settlement currency, instrument type and method of settlement. For example, the Great Britain Market could have different deadlines for settlement currency GBP and USD, different deadlines for equities and fixed income instruments and different deadlines for delivery versus payment and delivery free of payment method of settlement. The deadline in the Great Britain Market for GBP settlement for equities and for delivery versus payment can be 2:00 PM local time on every settlement date.

The amount of time specified by the GC and the B/D in their profiles will initially be based on settlement location. The TFM processor will be designed with the flexibility to specify the amount of time prior to the settlement date/time by settlement currency, instrument type and method of payment.

Even though the alert processing within the TFM processor is based on the earlier of the deadlines set by the B/D or the GC, the TFM processor for MIS reporting to the IM will also track the GC deadlines (i.e., whether the IM has missed the GCs deadline or not). It is logical that the alerts for settlement related processes follow the most likely sequence of participant message submission. For example, alerts regarding net proceeds should be triggered prior to alerts relating to settlement details for a given trade.

Participants may specify the deadline timings in UTC (formerly GMT). Accounting

The deadline for the submission of the information required for accounting puφoses will be based on trade date/time or Allocation Date/Time plus an amount of time specified by the Accounting Agent in its profile. The deadline for accounting puφoses can be expressed by the following formula:

Deadline = Trade Date/Time or Allocation Date/Time + amount of time specified by Accounting Agent

The deadline specified by the Accounting Agent will be used by the TFM processor to carry out any unconfirmed (soft) reporting, if required, for the Trades and Allocations. Confirmed reporting by the TFM processor will be initiated once all the information required for Accounting has been submitted and matched. Confirmed reporting will not be based on any deadline processing. Confirmed reporting will be done by the TFM processor as soon all the accounting details are available and the Net Proceeds are matched. It is not envisaged at this point to have the need for two separate deadlines for unconfirmed reporting and confirmed reporting. It is likely that Accounting Agents will specify different amounts of time for different categories of accounts. For example, the amount of time specified for a mutual fund that requires a daily net asset value (NAV) calculation will likely be shorter than that specified for a pension fund with monthly valuation.

Accounting deadlines can also be specified at time of the trade date, time of the trade date plus a number of days, time of the week and time of the month for unconfirmed reporting. Accounting Agents will also specify the reporting period required in the case of non-standard reporting such as time of the week, etc. For example, an Accounting Agent can specify for an insurance fund registered in Australia a weekly reporting at 5:00 PM Australian Time on Friday for all trades submitted from the last Friday to the previous Thursday.

Participants will specify the deadline timings in UTC (formerly GMT).

IMs should understand the accounting implications for the different account categories associated with their clients. IMs will need to specify the Class of Account for each of their clients either at the level of the trade or at the level of account in their profiles.

The location of the Accounting Agent will also be taken into consideration. The system will perform escalations based on the time zone of the Accounting Agent. If an Accounting Agent has operations in multiple time zones, the identification of the accounting agent will have to recognize that fact through the use of an 11- character BIC. It is possible that in some cases, Trade and Allocation details will be sent to the Accounting Agent prior to the completion ofthe matching process (Soft Reporting).

Alert and Deadline Processing

Trades are monitored throughout the states of the trade life cycle from the input of the first information typically an NOE or BON, through to the Settlement Channel match. Completion of the following different events are monitored: • NOE BON Match

• Completion of Allocation

• Net Proceeds Match for each Allocation

• Submission of Accounting Information for each Allocation (Accounting Information will be submitted along with regular messages such as BON, NOE, Allocations and Net Proceeds).

• Settlement Channel Match for each Allocation

When deadlines are established in the TFM processor, the trade record will be updated with the deadlines. The trade will have a timer field, which contains the deadlines for each event. These deadlines will be visible to the user in the any ofthe following ways:

• Whenever trade details are queried

• Available in any message/pending transactions sent by he TFM processor

Warnings will be flagged against the trade if any of the deadlines are missed for the trade.

Individual deadlines are explained below:

NOE BON Match If the trade is input on Trade date, the deadline for the feON/NOE match will be XXX minutes (XXX is a system parameter which is ^pendent on the type of instrument) from the time of the first transaction input '.(ji.fi., NOE or BON). A warning will be sent to both parties of the trade if a match .does not take place within XXX minutes before the deadline. This warning will be based on a system parameter as opposed to the profiles of the participants involved. If the trade is input after the trade date, the wattling will κ sent immediately upon successful validation.

Completion of Allocations The deadline for completion of allocations will be XXX minutes ^' {where

XXX is a system parameter depending on the type of instrument) a,fter the NOE BON match. A warning will be recorded in the trade for any incomplete or missing allocations not presented by the IM's within the deadline.

Net Proceeds Match The deadline for Net Proceeds match will be based on tø)e Profile of the

GC, the Accounting Agent and the B/D. The deadline for the net proceeds match and the associated alerts should be based on the earlier of the accounting and the settlement deadline as expressed above. The settlement location is based on the following information:

• Settlement Location specified by the B/D in the NOE

• Instrument Code data (country of issue) in the absence of any settlement location information • Settlement Location, if and when specified by the GC

In the absence of deadlines based on the information in the profile of the GC, the Accounting Agent and the B/D, the generic TFM processor deadlines, as given below will be applied. The deadline for Net Proceeds match will be defined as XX hours/minutes prior to the Settlement Date/Deadline Time. The parameters, XX hours/minutes will be based on the deadlines for the settlement location and could be different for different types of instruments. A warning will be sent to both parties of the trade if a match does not take place within XXX minutes before the deadline. This warning will be based on a system parameter as opposed to the profiles ofthe participants involved.

Submission of Accounting Information

The deadline for the submission of infonv.ation required for additional accounting puφoses will be based on trade date/time or Allocation Date/Time plus an amount of time specified by the Accounting Agent in its profile.

Warnings will be sent "pushed" to the IM and the B/D if the requirements for accounting are not completed by XX hours/minutes before the accounting deadline where XX is a parameter maintained by the IM in the profile. This explained below:

• The IM will receive notifications that allocations relating to a block trade have not been received by the TFM processor. This notification process will be based on a default amount of time, for example at the end ofthe day, unless a specific parameter is established in the IM's profile.

• The IM will receive a warning if the accounting information is not input XX hours prior to accounting deadline

• Warnings will need to be sent to the Accounting Agent in cases where the accounting information is released prior to the completion of the net proceeds matching process clearly indicating that the reporting is a unconfirmed reporting.

Settlement Channel Match

The deadline for settlement channel match will be based on the profile of the GC and the B/D. The deadline for the settlement channel match and the associated alerts should be based on the settlement date/Deadline time in the relevant settlement location minus the larger ofthe amount of time specified by the GC and the B/D in their profiles.

The settlement location is based on the following information:

• Settlement Location is specified by the B/D in the NOE

• Instrument Code data (country of issue) in the absence of any settlement location information

• Settlement Location if and when specified by the GC

In the absence of deadlines based on information in the profile of the GC and the B/D, generic TFM processor deadlines, as given below, will be applied.

The deadline for the settlement channel match will be defined as XX hours/minutes prior to the Settlement Date/Deadline Time. The parameter XX hours/minutes will be based on the deadlines for the settlement location and could be different for different types of Instruments. A warning will be sent to both parties of the trade if a match does not take place within XXX minutes before the deadline. This warning will be based on a system parameter as opposed to the profiles ofthe participants involved.

Setting of Deadlines

All of the above deadlines will be calculated and the earliest of the deadlines will be set. For example, if a trade is input on settlement date (i.e., trade date is the same as settlement date) at 13:00 UTC, then the deadline for NOE-BON match is calculated by the TFM processor as 15:00 UTC (+2 hours from trade input). The TFM processor also finds that settlement deadline for the trade is 14:00 UTC. Since the settlement deadline is earlier than the NOE- BON match deadline as calculated by the TFM processor, The TFM processor sets the NOE-BON match deadline as 14:00 UTC.

Master and Reference Data

All generic and specific processes of the TFM processor make use of data in one form or another. The data can be grouped under two broad categories - generic data and process data. Process data is used, manipulated and updated by all or specific processes (e.g., Trade Details, Allocation Details, Settlement Details, etc.) Generic data is used by most of the processes for validation or reference puφoses. Generic data in the TFM processor has been further subdivided into MASTER data, PROFILE data and REFERENCE data. Since participants maintain most of the profile data in the TFM processor, it has been separately dealt with under Profile Maintenance. The data classified under Master data and Reference data are explained in this section.

Master Data

All data that is administered and maintained by the TFM processor for generic processes has been grouped under MASTER data. All processes in the TFM processor use this data to validate the inputs and to decide on the flow of the respective processes. This data is further subdivided according to usage and the level at which it is stored and maintained. The tables under which Master data is stored are given below.

> Currency

> Country

> Primary Numbering Agency Code Identification > Settlement Location > Settlement Bridge

The individual tables and their contents are explained below.

Currency

The various currencies used in cross-border trades and related information are maintained by the TFM processor in the Currency Code Table of FIG. 49. All currency-related details are validated against this data.

Country

Country codes are used to identify the proposed settlement location except in the case of ICSDs where a BIC is used. The various countries involved in cross border trades and the associated default settlement locations are maintained by the TFM processor in the Country Code Table of FIG. 50.

The proposed settlement location indicated in the Notice of Execution by the B/D is the location of their local settlement agent. If such a location is the country, then the TFM processor Administrator has to determine to maintain for every country the default settlement location (i.e., the default settlement organisation for the particular Instrument Type) to apply both for the tolerance for net proceeds and for the related settlement deadlines of the location.

Tolerances Tolerance for the Net Proceeds matching can be broadly classified as

Participant and Market. Participant maintained tolerances are detailed under Profiles. Market tolerance for the Net Proceeds match will be maintained in the TFM processor at the system level by Settlement Location, Settlement Currency and Instrument type. This field is also included in the Settlement Location table explained below.

Primary Numbering Agency Code

The TFM processor maintains the primary numbering agency codes for securities by instrument type and country of issue in the Instrument Type Table of FIG. 51.

Settlement Location The TFM processor maintains the details of all valid settlement locations in the Settlement Location Table of FIG. 52. Settlement currencies supported at each settlement location will be referenced to validate the settlement currency mentioned for the settlement location in the settlement details. The method of settlement will also be validated by the TFM processor by referencing this table.

Based on the generic deadlines to be followed in the TFM processor for the Net Proceeds match and the Settlement Details match, warnings will be attached by the TFM processor to the subsequent notification messages or query replies to the parties involved.

Settlement Bridges

An authority (such as the GSTPA) can approve the settlement bridge channels that support the DVP. The TFM processor maintains necessary details of all GSTPA approved settlement Bridges between the ICSDs and between the ICSDs and the CSDs to facilitate the exchange of relevant information to the local agents for effecting proper settlement. The Settlement Bridge Channels Table of FIG. 53 details the information the TFM processor will maintain with respect to settlement bridges. New bridges may be formed from time to time. The TFM processor Administrator will update the above table with the details of such new bridges as and when an authority such as GSTPA approves them for support within the TFM processor environment. In addition, the Participants can maintain in their profiles the settlement bridges they would like to support as well as the currencies they will support in these bridges. Reference Data

Data administered and maintained by third-party vendors that the TFM processor will reference for validations has been grouped under REFERENCE data. Such data can be referenced by the TFM processor from the third party database for generic validation or can be referenced from the earlier referenced data held by the TFM processor as Cache in its own database. Data stored in the TFM processor database will be continuously refreshed. The TFM processor validates a financial instrument by accessing a third party vendor database as and when a transaction is reported. To maximise performance on such validations, it reuses the cache data when the same instrument has to be validated again. Similarly, the TFM processor updates the BIC database at frequent intervals depending upon the frequency of updates of the BICs directory by SWIFT. The sets of data that will be referenced by the TFM processor will be BICs and Security Identification related data. Security Identification Financial Institution Identification (BIC) Account Identification is referenced by the participants directly. In the current phase, the TFM processor does not support account identification cross-referencing.

Security Identification

The TFM processor may adopt, for example, ISIN as the preferred securities identification code. The TFM processor will then maintain ISIN numbers for all types of financial instruments as the Primary Identification code. The primary identification code will be identified for the Instrument Type and country of issue. This is to support such cases where an ISIN is not issued (i.e., US dealt MBS, ABS). As it is appropriate to consider the use of other well-accepted identification codes as an alternative when ISIN are not readily available, the following Numbering Agencies codes will be supported. > SEDOL

> CUSIP

> QUIK.

The TFM processor may be configured to support the aforementioned Primary identification codes.

If incoming data contains the identification in the primary numbering agency code as the source of the financial instrument code, the TFM processor will proceed directly with the validation process by obtaining the related information from the third party vendor database and performing the necessary validations. If the primary numbering agency code is not used, the TFM processor will carry out the following translation process.

a. The Translation process may be performed through the use of a third party providing a cross-reference database for the source and the instrument category. The cross-reference will generate the corresponding Primary identification code or ISIN code whenever possible for use in the validation processes. b. Matching/validation will take place based on the primary identification codes provided by the B/D and the IM, if they use the same Numbering Agencies code (i.e., both use ISIN, CUSIP, etc.) For example: If both sides want to match on CUSIP and CUSIP happens to be primary identification code for the instrument type, then the matching will be done on CUSIP. No translation is done in this case. c. Matching/validation will take place based on the translated primary identification codes or ISIN codes if both parties used different numbering agency codes. d. The original numbering agency and identification code will always be provided together with the translated code that resulted in the match.

To avoid the need to access the external database every time for validation and translation, the TFM processor will maintain the most recent version of the ISIN related information in its internal cache. The internal cache will be refreshed every day to ensure that it is current.

An indicative lists of elements to be maintained is given below. Primary Numbering Agency Code

> Identification in Primary Number Agency code > Other Numbering Agency code (repeated for each code for which translation is available) Identification in the other Numbering Agency Code (repeated for each code for which translation is available)

> End/Maturity Date The information relating to end/maturity date is used for validation puφoses. The trade date should be earlier than or the same as the end/maturity date.

Financial Institution Identification (BIC)

A unique ISO Bank Identifier Code (BIC) will identify financial Institutions. BICs are an internationally standardised method for identifying financial institutions. The BIC is designed to facilitate automatic processing of telecommunication messages in banking and related financial environments. A BIC is either a:

> SWIFT BIC - a registered BIC of a financial institution connected to SWIFT or Non-SWIFT BIC - a BIC of a financial institution that is not connected to SWIFT (it is denoted by the digit in the eighth position)

The ISO Bank Identifier Code (BIC) consists of 1 1 characters, including the following four components explained in the Bank Code Table of FIG. 54. The first three components; The Bank Code, the Country Code and the Location Code are mandatory components of a BIC.

Parties interacting with the TFM processor will identify themselves with their 8-character or 11 -character BIC. The GSTPA recommends use of separate BICs for every role performed by a participating legal entity. The validation of this BIC will be done by the TFM processor by referencing the BIC table maintained by the TFM processor. The TFM processor will make use of only the first 8 characters of the BIC for the puφose of matching the counteφart of the trade.

The BIC table of FIG. 54 contains all generic information related to the financial institutions. The TFM processor validates the following input fields with the BIC table and process these detail only if the BIC is found to be valid.

> IM > B/D

> Settlement Location for ICSDs

> GC for the allocation

> Broker of Credit Securities Agent at Location > Cash Agent at Location

> Substituting Party

> Accounting Agent Reference Data Provider Lending Agent > Concentrator participant AM Domestic/Cross-Border TFM processor.

The account of the participant at the settlement location is not identified by using BICs. SWIFT may assign and administer BICs for all GSTPA Participants. Account Identification

The IM provides in the Allocation message the Account number of the client as per its internal records and the GCs client account number. The TFM processor does not perform any cross-referencing of the IM's account number to the B/D's internal account numbers. To enable the B/D to cross-reference between the IM's number and the B/D's internal reference number, the IM will also provide in the Allocation message the Access code relating to the vendor's system where the account number is registered, if it is indeed registered (e.g., in Alert, SID, etc.) The TFM processor will send this information to the B/D as part of the Allocation Notification. The B/D will interface with the vendor system for internal account set-up and cross-referencing puφoses. The GC will receive the IM's account number and the GCs account number as provided by the IM on the allocations.

A process can be implemented to create a new, standard numbering scheme to identify accounts/portfolios. This involves the creation of a "Fund Registering Agency" that would allocate unique fund numbers for each account/portfolio that an institutional investor (e.g., a mutual fund, a pension fund) would want to register. This registering agency would collect at that time the minimum amount of information about the account/portfolio that is needed for the IMs, the B/Ds, and the GCs to recognize this entity (e.g., tax domicile). The IM and the GC would use the unique number either directly or by cross- referencing. The association of this unique number with the IM BIC code would uniquely define the account for a B/D. The IM will identify their client account numbers as "Portfolio X," the GC will identify their client account as "Portfolio X" and the B/D will identify their client account as "Portfolio X at IM Y."

The transition from the current situation to this new account numbering would be implemented as follows. In the early phase of the proposed scheme, the IM will submit its Account number, the GCs account number, and the Vendor Access Code and the GSTPA account number, if available. The B/D will receive from the TFM processor, the IM's account number, the Access Code and the GSTPA account number, if provided by the IM. The GC will receive from the TFM processor, the IM's account number, the GCs account number and the GSTPA account number, if provided by the IM. In the long term, the IM will submit the GSTPA account number only as part of the Allocation message. The B/D and the GC will receive the GSTPA account number from the TFM processor as part of the Allocation Notification and do the cross-referencing internally in their own applications.

Participant Profile Data

The Transaction Flow Manager (TFM processor) maintains a profile for each Participant of the GSTPA. The TFM processor Administrator does the initial set up of the primary details of the participant. Thereafter, the participants, using the profile message, will maintain the profiles. The Participant Profile contains information on the operating preferences of the Participants with respect to the TFM processor based on their internal operating procedures.

A Participant Profile contains the information and the rules relating to the following: Participant Details

• Participant Roles

• Participant AM Details

• Routing Details

• Message Submission Modes • Substitution

• Timing Rules

• Matching Tolerance

• Aggregation

• Settlement Release • Profile for Broker-to-Broker Trades. Profile Details - From the Role Perspective

The Role Profile Table of FIG. 55 summarises the various profile categories applicable for specific roles. The Participant, using the messages defined for profile maintenance, can administer the Profile. The following information in the TFM processor can be maintained by axion4gstp as TFM processor System Administrator:

• Participant Primary details

• Substitution • A Substituting Party for the specific role that is being substituted will maintain profiles. That is, if a substituting GC is submitting Settlement Details for a non-participating GC, the substituting GC can maintain GC- specific details such as Net proceeds & Settlement match deadlines, supported settlement bridges and so on, that are applicable for the specific role. Before an Accounting Agent starts maintaining its Profiles, TFM processor will validate whether an accounting agent has been appointed by the IM in its profile for the particular account.

Profile Administration The Profile for a Participant is created when the TFM processor System

Administrator defines the Participant in TFM processor. This will consist of certain basic mandatory information such as participant details, roles, and the default PAMs etc. that are required by the Participant to interact with the TFM processor. Any overriding values and operating preferences will need to be subsequently maintained by the Participant.

Participants can maintain the following profile details in the TFM processor:

• Gross amount match tolerance (IM, B/D)

• Net proceeds match tolerance (IM,B/D) • Match of brokerage commission at block trade level (IM. B/D) • Use of external common reference number match for applying tolerance on match of gross amount (IM, B/D) Client Profiles (IM)

Accounting deadlines (Accounting Agent) Routing details (IM,B/D, GC, Interested Parties) Indicator for supported transaction type (B/D) Notice of pending transactions (IM,B/D) Settlement deadlines (B/D, GC) Supported settlement bridges (B/D, GC)

Participants may add/replace/delete individual detail in the Profile using "Maintain Profile" messages. Each add/replace/delete can be done in the Profile specifying the date that the values will become effective. The effective date along with the added/replaced/deleted profile detail can either be an immediate or a "future" date. The future date refers to a future system date except for routing details where the date specified refers to the future trade date. When an update to a Profile is effective immediately, the updated values will apply to all open transactions.

• Any net proceeds that have failed match will be taken up for matching again if a Participant modifies the matching tolerance. However, any matched net proceeds will not be taken up for re-matching based on the new profile value.

• If changes are made to deadline details in the Profile to be effective immediately, the new deadlines will be re-applied to all relevant open transactions, which have pending deadlines against them.

All other profile updates will take effect only for new transactions submitted to the TFM processor. The TFM processor will maintain the log of all profile changes. The Participants can query their Profile details and log of changes. Participant Details

The basic information pertaining to a Participant in the TFM processor is set forth in the Participant Table of FIG. 56. Participant Identification:

A Participant of the GSTPA is identified and represented in the TFM processor in the ISO standard Bank Identifier Code (BIC) format. The BIC is a unique address that, in telecommunication messages, identifies precisely the financial institutions involved in financial transactions. The BICs are administered by S.W.I.F.T and are meant for universal usage and not just on the S.W.I.F.T. network.

Participant Address Details

Participants may need to maintain one or more physical addresses with the TFM processor for the puφose of correspondence. A Participant can have one or more addresses representing the financial institution, various departments or transaction types. A particular address of the participant maintained in the TFM processor is stored in the Participant Address Table of FIG. 57.

Participant Roles A Participant can assume one or more roles in its interaction with the

TFM processor. One or more of the following roles can be defined for a Participant, as shown in the Participant Roles Table of FIG. 58. Information based on a Participant-Role relationship consists ofthe following:

• Status of a Participant for the role. • TFMs and/or Concentrators to which a Participant is connected for a role if applicable. • The messages that the Participant is authorised to send when acting in the given role. For example, with a role as GC, a Participant is only authorised to send the Settlement Details.

Participant Access Modules (AMs)

Participant Access Modules (Participant AMs) provide a means of access to the TFM processor for Participants. The related information maintained in the TFM processor is stored in the Participant AM Identification Table of FIG. 59.

Relationship between Participants' Roles, BICs, TFM processor, Participant AMs and Concentrators

The information flow diagram of FIG. 60 illustrates the relationship between the Participants, BICs, Participant AMs, the TFM processor and the Access Concentrators. Observe the following points with reference to FIG. 60:

1. A Participant (8-Character BIC) can be associated with one or more roles

2. A Participant can be associated with one or more 11 -character BICs. However, the first 8-characters of the BICs will always be the same and correspond to the BIC Identification ofthe Participant.

3. A Concentrator can be associated with one or more Participants. These Participants can use a Participant AM owned by the Concentrator to access the TFM processor. 4. A TFM processor can be associated with one or more Participants and a

Participant can be connected to more than one TFM processor.

5. An 8-character BIC of a Participant can be associated with one or more

Participant AMs owned by the Participant. Participants can assign optionally one of the Participant AMs to an 1 1 -character BIC. Each 1 1- character BIC can have a profile of its own, if the participant so desires. For example, the 8-character BIC can have a routing profile that is different from that ofthe 11 -character BIC. 6. A TFM processor can be associated with none, one, or several Concentrators. A Concentrator may be connected to one or more TFMs. 7. A TFM processor can be associated with one or more Participant AMs, which it uses for its communication with the Participants. 8. A Concentrator can own one or more Participant AMs.

Routing Information Participants maintain routing information in their Profile to specify the

Participant AM(s) at which different messages from the TFM processor will be received. By default, all messages are routed to the default participant AM associated with the applicable role of the Participant. The routing information can be set for the various categories of messages as explained below:

Error Messages

Error messages are sent in the event of edit check failures and match failures. Error messages are always "pushed" to the Participants. If the Participant chooses to receive all error messages at a Participant AM that is different from the default Participant AM, this information will be specified in the Routing Profile. It is also possible to maintain different Participant AM(s) for enor messages received at different stages of a trade. For example, the NOE acceptance error messages could be routed to a Participant AM that is different than the Participant AM to which net proceeds match failure messages are routed.

Warning Messages

Warning messages are sent in the event of non-critical errors during edit checks and matches. If there are warnings during an edit check or a match process, these will be sent to the Participant. The Routing details for warning messages will specify the Participant AM(s) to which the warning messages are to be routed.

Success Messages Success messages are sent for successful acceptance and matches. A success message will be sent to the Participant only if the Participant opts to receive it. Hence, Participants could opt for success messages for matches alone, but not for acceptanceof messages. The routing information for success messages will specify whether the Participant opts to receive the success messages and the Participant AM(s) to which the messages are to be routed if different than the default Participant AM.

Pending Processing Messages Pending messages are sent when messages are received out of sequence by the TFM processor due to network related problems (e.g., an Allocations message received by the TFM processor before the BON message from the IM). A Pending Processing message will be sent to the Participant only if the Participant opts to receive it. The routing information for the pending processing messages will specify whether the Participant opts to receive the pending processing messages and the Participant AM(s) to which the messages are to be routed if different than the default Participant AM.

Warning for Pending Processing Messages Before discarding the messages received out of sequence by the TFM processor, it will generate a warning to the participant. This message will indicate that the TFM processor is likely to Discard Pending Processing Messages, if the earlier message on which this message is dependent is not received within xx minutes. This is an alert message and is not profile driven. Discard Pending Processing Messages

Messages received out of sequence by the TFM processor due to network related problems (e.g., an Allocations message received by the TFM processor before the BON message from the IM) will be discarded by the TFM processor after a TFM processor defined wait period. The routing information for the discard pending processing messages will specify the Participant AM(s) to which the messages are to be routed if different than the default Participant AM.

Notification Messages

Notification messages are sent to the Participants to notify them of crucial information such as the Match Reference Number, Match of Net Proceeds, Match of Settlement Details, Allocations to the B/D and GC, Pending Cancellations, and changed deadlines. Notification messages are always "pushed" to the Participants. If the Participant chooses to receive all notification messages at a participant AM other than the default participant AM , this information could be specified in the Routing Profile. It is also possible to maintain different participant AM (s) for notification messages received at different stages of a trade. For example, the Allocation notifications could be routed to a Participant AM other than the one used for all other notifications. The GC will receive Allocation notification messages prior to the matching of the trade, if they have specifically indicated such preference in their profile. In this case a normal Allocation notification message will be sent to the GC once the trade is matched and the Allocations are accepted from the IM. The GC who also acts as an accounting agent will receive separate messages for each of these two functions.

Conversational Messages (Notice of Pending Transaction Messages)

Conversational messages are sent to inform Participants of any Pending NOE, BON or Net Proceeds. The Participant will maintain in the Routing Profile if any or all Conversational messages will need to be routed to a Participant AM other than the default Participant AM.

Alert Messages (Time Expiry warning messages) The TFM processor will alert participants, if any of their trades or allocations is in jeopardy of missing a significant event like a settlement deadline or an accounting deadline. The routing information for alert messages will specify the Participant AM(s) to which the messages are to be routed if different than the default Participant AM.

Status Change Notification Messages

Status Change Notification Messages are sent to the participant to indicate significant status changes for the trade. For example, when a block trade progresses from partially allocated to fully allocated, when all Net Proceeds for a block trade are matched or all settlement details for a block trade are matched. When a block trade is completed in all respects, a status change notification message will be sent to the Participant only if the Participant opts to receive it. The routing information for status change notification messages will specify whether the Participant opts to receive the status change notification messages and the Participant AM(s) to which the messages are to be routed if different than the default Participant AM.

Notice of Pending Transactions

A Participant will choose to submit messages to the TFM processor either in independent mode or in conversational mode. In independent submission mode, Participants submit messages without being prompted by the TFM processor. In conversational submission mode, the Participant will respond to notice of pending transactions received from the TFM processor. However, the participants can submit a message in independent mode even if they have opted for conversational mode of data submission in their profiles. .. The TFM processor will not validate an incoming message for the data^' submission mode ofthe participant.

The TFM processor sends notifications for any of the following transactions pending from a Participant - NOE, BON or Net Proceeds. Each Participant will specify in their Profile whether and when it wants to receive notification of pending transactions. If participants do not specify this information, the notification of alleged trade will be sent to the participants at the system default timing. The details maintained by the participant are summarized in the Transaction Notification Table of FIG. 61. The timing of the notice of pending transactions will also be based on the deadlines (i.e., end of the day for the market) even if the time specified for such notice has not elapsed. For example, if the participant has specified two hours for reporting the notice of pending NOE, but if the settlement deadline is earlier than this, then the timing of the notice of pending transaction will be at the time the warning for the settlement deadline is expected to be sent.

Substitutions

A Participant may be substituted for in terms of the submission of the Net Proceeds or the Settlement Details. The TFM processor administrator will maintain such substitution relationships in the TFM processor.

Net Proceeds Substitution

A B/D or an IM may outsource the Net Proceeds calculation and submission to a Third Party. The profile of the B/D or the IM will contain details of the Substituting Party who is expected to submit the net proceeds. If substitution is defined for a B/D and the B/D itself submits Net Proceeds instead of the Substituting Party, the message will be rejected by the TFM processor. The Net proceeds substitution details maintained in the TFM processor consist of the details set forth in the Proceeds Substitution Table of FIG. 62. In addition, IMs and B/Ds will be able to set up substitution for either a specific settlement location or a specific instrument type. For example Participant A can specify for settlement location "Thailand" participant B will provide the net proceeds.

Settlement Details Substitution

A non-participating B/D or GC can be substituted by a Participant of the TFM processor to submit the Settlement Details. The Substitution Profile Table of FIG. 63 stores the identification of the substitute who will be submitting the Settlement Details and the message type for which it is being substituted. The concerned B/D or the GC may appoint this substituting party. The IM can also appoint a substitute for non-participating B/Ds and GCs. When the non- participant GC does not appoint a substituting party, multiple parties can substitute. Therefore, the substituting party is identified by the combination of the identification of the IM and the GC. The Substituting Parties can maintain appropriate profiles for non-Participants. For example, if a non-participating GC is being substituted for Settlement Details, then the profile details such as settlement deadlines and so on can be maintained by the Substituting Party on behalf of the non-Participating GC. In addition, even participating GCs and B Ds can set up substitution for either a specific settlement location or a specific instrument type. For example Participant A can specify for instrument type "Fixed Income" participant B will provide the settlement details.

Client/Portfolio Details The Investment Manger maintains information regarding client accounts/portfolios in the TFM processor to enable processing based on this information. The following information will be maintained in the Profile of the IM/Accounting Agents for client accounts/portfolios: • The IM specifies the client accounts/portfolios and other details of the client account/portfolio, such as class or category of the account/portfolio etc. (e.g., US Insurance fund, UK mutual fund, etc.) The Standards Committee of GSTPA will standardise the class of accounts for use within the TFM processor environment.

• The IM maintains the information about all the Accounting Agents associated with each ofthe client/portfolios.

• Accounting Agents maintain the information of their Participant AMs for receiving accounting information from the TFM processor. Before an Accounting Agent starts maintaining its Profiles, TFM processor will validate whether an accounting agent has been appointed by the IM in it profile for the particular account.

• The Accounting Agents will also specify the accounting deadlines with respect to the client accounts/portfolios. The Accounting Agent can specify accounting deadlines based on the class of client accounts/portfolios. The deadline is expressed as a time at which the TFM processor will report the accounting information, for all the confirmed and the unconfirmed trades belonging to that particular class of accounts, to the respective accounting agents. The Accounting Agent can also maintain, if required, stricter deadlines at the client account level. If more than one accounting agent is appointed for an account, the stricter of the deadlines among the deadlines ofthe accounting agents for that particular account will apply.

• For each client account/portfolio, the IM will also specify whether its net amount or the B/D's net amount will be sent to the Accounting Agent, if the net amounts have not matched at the time of reporting.

• In addition, the IM will maintain the time with respect to the deadline at which it and the B/D should receive an alert if the transaction remains unconfirmed. The accounting information sent by the TFM processor to the Accounting Agents will consist of the accounting data sent by the IM as well as selected trade and settlement details. The IM Client Profile Table of FIG. 64 illustrates the profiles maintained by the IM for its Clients.

The Accounting Agent Profile Table of FIG. 65 illustrates the profiles maintained by the Accounting Agent for its Clients.

Examples of Deadline Setting for Accounting Agents: Example 1:

Accounting Agent A for class of accounts "Mutual Funds Registered in Hong Kong" specifies a daily reporting based on the Allocation Time. The deadline is 5:00 PM Hong Kong time and the reporting duration is all the Allocations done from previous day 4:01 PM (-1 Days 4:01 PM) to 4:00 PM on the same day (0 Days 4:00 PM).

A UK IM carries out two Allocations for a Mutual Fund registered in Hong Kong - one at 7:00 AM GMT and another at 9:00 AM GMT on 12^th June 2000 for Clients who are accounted for by Accounting Agent A. The Time Difference between UK and Hong Kong is 8:00 hours. At 9:00 AM GMT and 5:00 PM Hong Kong Time on the 26^th June 2000, both the Allocations have not been matched for Net Proceeds. TFM processor only reports the first Allocation as an unconfirmed (soft) accounting report to the Accounting Agent A.

Example 2:

Accounting Agent A for class of accounts "Mutual Funds Registered in Hong Kong" specifies a daily reporting based on the Allocation Time. The Accounting Agent indicates that all Allocations should be reported 5 hours from the Allocation Time. In this case all Allocations will be reported 5 hours from the submission time if they remain unconfirmed.

Note: Confirmed reporting is not deadline based. Once the Allocation is matched for Net Proceeds, if there is any reporting requirement for the Client. The TFM processor will automatically carry out the reporting. The MIS will keep track of confirmed reporting with respect to the deadlines established by the Accounting Agent.

Settlement Deadlines Please refer to the Alert and Deadlines processing for the profiles related to settlement deadlines.

Matching Tolerances

The following details on matching tolerance will be specified by a Participant in the Profile:

(a): Matching of Trade Price/Gross Amount

Participants can maintain in their profiles whether they want an exact match on the trade price at the block level or not. If neither party requires an exact match on the average price in the block trade, a unilateral tolerance maintained by the participants at the settlement currency level by instrument type will be applied to the gross amount. The Participants can define the unilateral tolerance amount for each currency by instrument type, which they would like to use for the gross amount match. Participants can define in their profile whether they would like to use an external common reference number match for applying the tolerance for matching ofthe gross amounts or not.

The Matching Tolerance Table of FIG. 66 explains the matching tolerance at the level of the Block Gross Amount.

(b): Matching of Brokerage Commission

Participants can specify whether they would like to match the brokerage commission at the block trade level exactly or not. If the participant has specified that exact match of commission is required, the trade will not be matched if the commissions do not match. If the Participant has indicated that exact match of commission is not. required, the trade will be matched if the commissions do not match, but a warning will be issued indicating the commissions do not match. Matching of Net proceeds

Participants can specify the following details relating to tolerance values for net proceeds match: • Each Participant will maintain a unilateral preference with respect to prevailing amount if the net proceeds match within participant tolerance. The possible values for this preference will be:

• "Use my amount," "Use Counteφart's amount" or "Neutral."

• Unilateral Tolerance: The matching tolerance for a Participant will be specified as a % value. This is applicable for all currencies. In addition, the

Participant can also specify a limiting amount at each currency level, which is the maximum amount up to which the % tolerance value will apply.

• Bilateral Tolerance: Participants can also maintain different limiting amounts for different counteφarts for a specified currency. This tolerance value will be applied if the net proceeds do not match within the market tolerance, which is maintained at the level of settlement location and settlement currency combination.

Supported Transaction Types

B/Ds can maintain in their profiles any requirements or preferences with respect to different product types. For example, a B/D will indicate in its profile whether Broker-to-Broker trades are to be processed by the TFM processor or not.

Supported Settlement Bridges

Participants (B/Ds and GCs) can maintain in their profiles the Settlement Bridge channels, which they would like to make use of through the TFM processor. They can also maintain the details of the currency of settlement and the type of instrument, which they would like to make use in each bridge channel. The TFM processor will make use of this information while performing the match of settlement channel compatibility.

Queries The Transaction Flow Manager (TFM processor) supports several types of queries by the participants. The basic principle of supporting queries is to enable participant's search the data for quick decisions. This enables the participants to achieve higher straight through processing rate in case of enors (data and match). The TFM processor provides unrestricted search/access to query data relating to own trades and profiles. The access to data of the other participants are restricted depending upon the sensitivity of the data. For the sensitivity/secrecy reasons, the data will be classified as Public domain information and Private domain information. While the public domain information can be queried by all participants, the private domain information can not be queried by other participants.

The TFM processor supports various types of queries for different roles of the participants. In addition to supporting queries by the IMs, the B/Ds and the GCs, the TFM processor will also support queries by a Concentrator and the Accounting Agent. Certain category of participants will have the ability to use only certain types of queries. For example: Accounting Agents can query their own profiles only. Concentrator will be able to query only the trades submitted by a participant through them. The TFM processor provides for following types of queries by the participants.

Trade Queries Own Trades

> Alleged Trades

> Profile Queries > Own Profiles Counteφart profiles

> Market Profiles

> Reports

> Performance Score Card

Trade Queries:

Own Trades

Participants will be able to query the data relating to own trades. Participants will be able to query the data on the block trade level as well as data on the allocation level. The data on block trade level can be queried using the Physical sender, Actual sender and Trade reference number as the key. For querying the data on allocation level, in addition to the Physical sender, Actual sender and Trade reference number, the participants have to use the Allocation sequence number as the key. Alternatively, participants can also use the Match Reference number as the key instead of their trade reference number.

Participants can query both matched and unmatched trade records. Participants will be able to query the status of their trades. For example: Participants will be able to query all the trades, which are not fully allocated. In addition, they can query the status of an allocation.

Participants can also search based on the combination ofthe following attributes ofthe trade giving range of values: > Trade reference numbers Match reference numbers

> Block quantity trades Trade prices Block gross amounts > Trade dates > Settlement dates Allocation sequence numbers

> Allocated quantities

> Net Amounts

Participants can also query their trades with the following attributes: Counteφart

> Transaction type

> Instrument Type > Buy or sell trades Security Identification number Trade or Settlement Currency Settlement location

> Client Account number > GC or a Local Agent.

Alleged Trades

Participants can query the trades alleged against them, which are waiting for their response. They can query the unmatched trade data for the trades alleged against them by following attributes: Counteφart Class of financial instruments

> Transaction types

> Security identification numbers > Settlement locations Settlement currency

> Buy or sell trades

The queries can also have range of values for search criteria like block quantity, block gross amount, trade date and settlement date. Profile Queries

Own Profiles

Participants can query the profile data maintained by them in the TFM processor. Participants can query the various types of profile information like Matching tolerances for gross amount and net amounts (both unilateral and bilateral), class of accounts and related accounting deadlines, routing profiles, aggregation profiles, settlement deadlines etc. Participants will also be able query the log of changes done between a period on their profile information.

Counterparty Profiles

Participants can query the data relating to their counteφarts. Query of the counteφarty profiles will be role dependent. For example: An IM will be able to query the public domain profile of the counteφart B/D. However, an IM will not able to query the profiles of another IM. They will be able to query only the public domain profiles. The decision of whether a profile is public or private will be determined using the TFM processor system parameter for the profile. The GSTPA operations committee may decide which profiles will be public and which ones are private.

Market Profiles

Market Profiles are the information relating to various cmrencies, settlement locations etc maintained by the TFM processor Administrator for the functioning of the TFM processor. Participants will be able to query the information relating to Market tolerances, Deadlines for settlement locations and other system level parameters.

Performance Queries

The overall performance of the TFM processor and the participants in terms of statistics of its trade/message activities will be reported on a daily basis. The TFM processor will also maintain these statistics at the level of the following time frames:

> Monthly

> Quarterly > Yearly.

Trade Statistics

With reference to the Trade Statistics Table of FIG. 67, Trade statistics provide the following information regarding the submitted trades, successful trades, the cancelled trades by the TFM processor, and the cancelled trades by participants. The percentage is estimated based on its respective numbers corresponding to trades submitted. These statistics are broken down by:

> Participant > Market (Settlement Location) Instrument Type Settlement Currency.

Individual participants will be able to query these statistics pertaining to them.

Message Statistics

Message statistics provide the counts ofthe messages with respect to its functionality. Refer to the Message Statistics Table of FIG. 68 for further details.

These statistics are broken down by:

> Participant Market (Settlement Location) Instrument Type

> Settlement Currency. Individual participants will be able to query these statistics pertaining to them.

Matching Efficiency

Match statistics provides the counts of matched events (trade match, allocation completion, NP Match, and SD Match), missed deadlines, and matching efficiency. With reference to the Matching Efficiency Table of FIG. 69, matching efficiency is shown as the number and percentage of events completed in different time intervals. The percentage is estimated based on the corresponding number for trades and allocations submitted. For the puφoses of benchmarking the value of block trades reported in different currencies, the TFM processor will use a base cunency and an exchange rate between the base currency and the trade currency. These statistics are broken down by:

> Participant > Counter Participant

> Market (Settlement Location)

> Instrument Type

> Settlement cirrency.

Individual participants will be able to query these statistics pertaining to it and its counter participants.

Geographical characteristics of Usage

Statistics on completed trades with respect to geographical usage are provided in the Geography Table of FIG. 70.

Instrument Types of Usage

Statistics on completed trades with respect to the instrument types are stored in the Instrument Type Table of FIG. 71. Domestic or Cross-border Usage of Services

Statistics on completed trades with respect to the type of service are provided in the Type of Service Table of FIG. 72.

^* - A domestic trade is the one where all the participants to the trade are from the same country where the security is issued.

Standards Compliance

Statistics on completed trades with respect to securities identification code usage are provided in the Standards Compliance Table of FIG. 73. These statistics are broken down by: > Participant

> Market (Settlement Location)

> Instrument Type.

Mssage Handling and Trade Referencing

Reference Numbers

A trade is uniquely identified within the TFM processor as a combination of the following: • Actual Sender Identification: This is represented by the BIC of the actual sender.

• Physical Sender Identification: Participants can identify their trades submitted through concentrators by using the physical sender identification of the concentrator as part of the trade identification. This is represented by the BIC ofthe physical sender.

• Participant's Trade Reference number: This is a unique block trade reference number created by the participant for submission of trade details into the TFM processor.

Each participant (IM or B/D) will use their own trade identification number to submit messages relating to a given trade into the TFM processor. An allocation is uniquely identified within a trade using an Allocation Sequence number as supplied by the allocating party. The GC will use the IM's Trade and Allocation identification to submit the settlement details. The TFM processor Match Reference Number is a unique trade reference number generated by the TFM processor for every block trade match. This number will be sent to both the IM and the B/D after the BON/NOE match takes place.

In addition to these reference numbers, the TFM processor and the Participant AM will also issue a unique reference # to acknowledge every message received by the TFM processor and the Participant AM called, the Receipt Reference #.

Message Versions Every input message relating to a trade will be assigned a version number by the participant. The objective of the message versioning is to check if the participant is intending to use the version of currently stored details within the TFM processor. The other objective of the message version is to ensure that the right sequence of cancel/replace/delete messages is applied. The Message structure will accommodate a version number on the trade level messages and separate versions for individual allocations within the same message.

Allocation level messages will use the trade reference number and message version number of the BON/NOE to identify the trade. Allocation sequence numbers and their message version numbers will be used to identify allocations.

Each Net Proceeds and Settlement Details message will have its own version numbers for individual allocations, besides explicitly stating the trade version numbers and allocation version numbers. The Reference Numbers Table of FIG. 74 illustrates the reference numbers used during the trade life cycle by each participant to the trade. All cancellations and replacements will require a new version number higher than that of the version cunently stored in the TFM processor. If the TFM processor receives a replace and the corresponding new message with version 1 has not arrived, then the TFM processor will process it as a new message. If the TFM processor receives a cancellation or a deletion message and the corresponding new message with version 1 has not arrived, then TFM processor will validate the cancellation or deletion message and create a transaction in "Cancelled" or "Deleted" status. The TFM processor will validate the current version number stored with the version number indicated in the incoming messages. If the message fails the version number validation (i.e., the message version is not higher than the cunent version), it will be rejected. Example 1 :

Participant A sends a new block trade with trade reference # A 1234 and version 1. Participant A also immediately sends a replace message to the trade with reference # A 1234 with version 2. Due to network delays, the replace message arrives before the new message to the TFM processor. The TFM processor processes the replace message as though it is a new message. When # A 1234 version 1 arrives, the TFM processor ignores it as the TFM processor has already processed version 2 ofthe trade. Example 2:

Participant A sends a new block trade with trade reference # A 1234 and version 1. Participant A also immediately sends a cancel message to the trade with reference # A1234 with version 2. Due to network delays, the cancel message arrives before the new message to the TFM processor. The TFM processor processes the cancel message. If all the validations for the cancel message are successful, then the TFM processor creates a trade in cancelled state. Once the new trade arrives, TFM processor ignores the new block trade message as it has already processed version 2 ofthe trade. The following are the sequence of messages expected from the IM: 1. Block Trade Details (Block Order Notification)

2. Allocations

3. Net Proceeds and 4. Settlement Details.

The following are the sequence of messages expected from the B/D:

1. Block Trade Details (Notice of Execution)

2. Allocations (for pre-allocated trades)

3. Net Proceeds and 4. Settlement Details.

The following are the sequence of messages expected from the GC: 1. Settlement Details.

If the sequence of the arrival of the messages for a particular trade reference # and version # is not maintained by the network, then the TFM processor will keep the out-of-sequence message in pending processing state until the higher level messages arrive and is accepted by the TFM processor (Examples 1 and 2 below). Example 1 : Participant A sends a new block trade message with reference # A 1234 and Version 1. Participant A also sends immediately an Allocation Message with Allocation Sequence # 1 and version 1. The Allocation message arrives before the block trade messages. The TFM processor keeps the Allocation Message pending for acceptance until the new block trade message is accepted by the TFM processor. Once the new Block Trade is accepted by the TFM processor, the TFM processor processes the pending Allocation Message. Example 2:

In the TFM processor, there is already a trade with reference # A 1234 and version 1 and Allocation with sequence # 1 and version 1. Participant A sends a replace to the block trade with version 2 and increases the block quantity. Participant A also sends a replace message to the Allocation with version 2 and increases the Allocated quantity. The Allocation Message arrives before the Block Trade replace message. In this case, the processing in the TFM processor is exactly similar to the one mentioned in Example 3. The TFM processor will time-out and discard pending processing messages after a system-specified duration. TFM processor will also issue a warning message to the participant about the discard of pending processing messages. For example, if the Allocations message arrives prior to the Block Trade message from an IM, then the TFM processor will issue a warning to the participant after a system parameter (e.g., 2 minutes) of the arrival that it is still awaiting the Block Trade message. The TFM processor will issue a discard notification and discard the Allocations message, if after a system parameter (e.g., 5 minutes) from the arrival of the Allocations, the Block Trade message does not arrive.

New Message Acceptance Process

• Format Validation

• All messages are checked for adherence to a protocol as, for example, for XML compliance, DTD validity and format (datatype) and constraints (conditions). If the format validation fails, error messages are generated and sent to the sender of the message.

• Sequence Checks

• Participants may send their messages to the TFM processor in any sequence. The TFM processor will process the incoming messages in the required sequence.

• The Sequence check is performed on all input messages except NOE and BON. Sequence checks will check the existence of a trade and allocations as well as their versions and status. If the trade or allocation does not exist, messages are put in "Pending Processing" status.

• All messages in "Pending Processing" status will be processed after the corresponding trade or allocation details are subsequently processed by the TFM processor. If the corresponding trade or allocation details do not arrive within a specified time, the TFM processor will send an alert to the participant.

• If the corresponding trade or allocation details do not get accepted within a specified escalation time after alerts, this "Pending Processing" messages would be "Rejected," as part of the TFM processor housekeeping procedure.

• If the sequence context check fails for status (e.g., new allocations for a fully allocated trade with an existing allocation sequence and version), then messages are "Rejected."

• Content Validation

Content validation is performed on all input messages by the TFM processor against the reference data and existing details. It will generate enor and warning codes as applicable. If the validation has only warnings and no errors, acceptance messages are generated based on profile settings. If validation has failed with errors, error messages are sent to the sender.

If a participant operates in conversational mode and chooses to receive the notice of pending transaction immediately, the TFM processor will generate and send a notice of pending transaction. If the counteφart operates in independent submission mode and chooses to receive the notice of pending transaction after either a profile- based duration or a system-specified duration, the TFM processor will generate and send the notice of pending transaction after the lapse ofthe duration. The system-defined duration of time between the time that a trade is alleged and the time that the counteφart receives the notice of pending transaction will account for relevant deadlines. Some message acceptances will also generate notification messages (e.g., allocations acceptance will send allocation details to the B/D and the GC). Refer to the Message Status Table of FIG. 75 for further details.

Input Messages

Input Messages to the TFM processor include any ofthe following:

> Notice Of Execution

> Block Order Notification

> Allocations > Net Proceeds

> Settlement Details

> Accounting Information

> Participant Profile.

Input messages specify the function of the message, as shown in the Message Function Table of FIG. 76. Input messages include the senders' details, trade identification, allocation identification and version number details.

Multi-part Messages

Related messages to a trade from a participant can be submitted as a multi-part message. The message acceptance process of the TFM processor will split the multi-part message into single pieces and accept them individually.

Output Messages from the TFM processor Output messages generated from the TFM processor will fall into the following broad categories, with reference to the Message Types Table of FIG. 77.

Error and warning Message All eπor and warning messages will have trade identification, trade version numbers, allocation identification, allocation version numbers, and individual message versions. All eπor messages will have error codes and error field tags. Match error and warning messages will also have the party's value and counteφart's value. Warnings will be sent along with errors or acceptance messages.

Acceptance Message

The TFM processor generates acceptance messages for successful validations. This can be profile driven. The acceptance messages will also contain the status, the trade details and the allocation identification details.

Pending Processing Message

The TFM processor will generate a pending processing message for messages arriving out of sequence. This can be profile driven.

Discard Pending Processing Message

The TFM processor will generate a discard message for any pending processing message that has timed out. This can be profile driven.

Notice of Pending Transaction Message

In their profiles, participants will specify whether they will operate in conversational or independent submission mode with respect to alleged trades. Participants that operate in conversational mode will receive notification of pending transactions immediately after the trade has been alleged against them. Participants that operate in independent submission mode will receive notification of pending transactions either after a profile-based duration or a system -defined duration in the absence of any profile. The system-defined duration of time will need to account for relevant deadlines. Block Trade and Net Proceeds are the events for which the TFM processor will generate notice of pending transaction against the counteφart.

Match Notification Message

Match Notification Messages for all matches are pushed by the TFM processor as part ofthe basic functionality and are not profile driven.

Notification Message

Allocation details and accounting information are notification messages that are pushed by the TFM processor as part of the basic functionality. Settlement Release can be profile driven.

Status Change Notification Message

Status changes of a trade or trade allocations can be sent to the participant by trade identification, allocation identification and status of trade and allocation.

Alert Message

Alert messages are sent by the TFM processor to participants to warn them early about deadlines that are about to expire. For example, the TFM processor will send an Alert message to the B/D and GC one-hour (a system parameter) before the settlement deadlines if either party has failed to input the settlement details.

With reference to the Block Trade States Table of FIGS. 78, 78A and 78B the composite Block Trade State is a combination of the Block Trade State and Block Trade Allocation Sub-State. The composite Allocation State is a combination of the Allocation State and NP state and SD state. Input and Output fields

FIG. 79 describes the field elements defined for the TFM processor, along with the associated edit checks for the fields. This Appendix also contains the list of input and output messages and the mandatory, optionality, and conditionality of the field elements in the physical messages. A cross-reference to physical and logical messages has also been provided.

Input Messages

FIG. 80 describes input message field elements and describes which fields are needed in which messages, the mandatory or optionality of the fields in the message, whether the field is matched or not.

Output Messages

In the TFM processor, there are two types of output messages: (a) one to notify the participant about the details of the trade or allocations and the outcome of the matches like Block Trade match notification, Allocation Notification to the GC, Allocation Notification to the B/D, Net Proceeds Match Notification, Settlement Details match notification, Settlement Release Notifications, and (b) another to notify about an acceptance eπors, status changes.

Messages sent with Trade and Allocation details

The data structure diagram of FIG. 81 groups field elements by input messages and describes which fields are needed in which messages, the mandatory or optionality ofthe fields in the message, and whether or not the field is matched. Legend for Reading FIG. 81 (as well as other data structure diagrams presented herein):

M - Mandatory Field O - Optional Field C - Conditional Field. The presence of the field is dependent on the values specified in other fields. Please refer to Section 1.1 Field Elements for details ofthe conditional rules.

TFM processor - The sender identification ofthe TFM processor. BM, BO, BC - "B" indicates both sides values for settlement details. "M", "0", "C" Indicates mandatory, optionality and conditionality ofthe fields. G - Fields generated by the TFM processor CM - Fields sent only if the trade is matched

PM, PO, PC - "P" indicates either the prevailing side's net amount in case of Net Proceeds Match or the both sides net amounts in case of Net Proceeds match failure. "M", "O", "C" Indicates mandatory, optionality and conditionality of the fields. Global Custodian will only get the prevailing sides Net Proceeds details. Accounting Agents will be reported based on the profile (either Investment Manager's values or Broker/Dealers values) CK - Fields only used to carry out control checks against the referenced Block Trade or Allocations.

The following are the list of output messages with trade details that are sent by the TFM processor:

> Alleged NOE and BON to indicate to the counter party about the alleged trades Trade Match and Trade Pair notification (Trade Match + Pair) to indicate the matching of the trade or the pairing of the trade due to replace of trade details by one of the parties. The details will be similar to the NOE or BON and will contain the counter party's trade details.

> Allocation notifications to the Global Custodian (certain fields like settlement location etc., will be sent only if the trade has matched with the

NOE)

> Pending Net Proceeds (NP Pend) in case the participant is operating in a conversational mode Net Proceeds match and match failure notification (NP Match) indicating the prevailing amount or the counteφarts amount respectively > Settlement Details match and match failure notification (SD Match)

> Settlement Release details (SD Release)

> Accounting Details (Acct)

Messages sent with only reference and status details

These messages are used to send out successful acceptance of messages or a rejection of the messages due to validation failures. These messages are also used to send any alert notifications to participants to inform them about any deadlines that are going to expire and status changes to trades. Pending processing, alert for pending processing and discard message will be sent as an

Alert message with appropriate status in Status of the message field. Deadline change notification will be sent as success messages with the revised deadlines.

The data structure diagram of FIG. 82 groups the field elements by input messages and describes which fields are needed in which messages, the mandatory or optionality of the fields in the message, whether the field is matched or not etc.,. In addition to these fields, there will also control check fields to ensure that participants refer to the right details of the trade and Allocations. These control check fields are not added in the table.

Mapping of Logical Messages to Physical Messages

Block Trade Details are shown in the data structure diagram of FIG. 83 (for Input Messages) and the data structure diagram of FIG. 84 (for Output Messages). FIG. 85 is a data structure diagram showing input messages for allocations, and FIG. 86 is a data structure diagram showing output messages for the above-described allocations process. FIG. 87 is a data structure diagram showing input messages for the above-described Net Proceeds process, and FIG. 88 is a data structure diagram showing output messages for the Net Proceeds process.

FIG. 89 is a data structure diagram showing output messages related to Accounting Details, FIG. 90 is a data structure diagram showing input messages involving Settlement Details, and FIG. 91 is a data structure diagram showing output messages involving Settlement Details.

Process Variations

Broker-to-Broker Trade

B/Ds can report and match their broker to broker trades using the TFM processor. The decision to route broker-to-broker trades to the TFM processor will decided by the participant based on the underlying market infrastructures that already provide such matching facilities for broker-to-broker trades.

B/Ds can indicate in their profiles, whether they would be using the

TFM processor for matching broker-to-broker trades. If the one of the B/D in the broker-to-broker trades indicate that they do not want to use the TFM processor for Broker-to-Broker trades, TFM processor will not process the broker-to-broker trade. In this type of trade, one of the B/D (called as the executing broker) will provide the NOE and the counter party broker will specify the BON. The executing broker will provide all the details which in the normal institutional trade, a B/D will provide. This includes the proposed settlement location. The processing type will be set as "Broker-To-Broker trade" by both sides. On acceptance of the NOE and BON for a Broker to

Broker trade, TFM processor will verify the profile of the parties to the trade to find whether they would support the Broker to Broker trade within the TFM processor. If both the parties to the trade have indicated in their profile to support the Broker to Broker trade, TFM processor will further process the trade. Otherwise, the trade will be rejected and an eπor message will be sent to the Broker submitting the NOE/BON. There will not be any other processing variations in the Block trade processing for the Broker to Broker trades.

Broker to Broker trades will not have any allocation process, as these trades are not for identified underlying funds/portfolios. TFM processor will not have allocation process for Broker to Broker trades. Participants can submit all other details i.e. Net Proceeds and Settlement Details for a Broker-To-Broker trade using a multi-part message along with trade details. Alternatively, participants can also provide Net Proceeds and Settlement details message separately. TFM processor will carry out the net proceeds match and the settlement channel compatibility matches for the Broker-To-Broker Trades.

The TFM processor will match Net Proceeds provided by both the B/Ds after successful match of the trade. The proposed settlement location provided by the executing Broker will be used for the determination of applicable market tolerance. This process is same as the normal institutional trade. The TFM processor will also match Settlement Details provided by both the parties to the trade. In case of a normal institutional trade the GC of the underlying client provides the IM's side of the Settlement Details. But, in case of Broker to Broker trades, both the parties to the trade provide the settlement details. There is no processing variation for the matching of settlement details of Broker to Broker trade within the TFM processor.

It is expected that Broker to Broker trades will not be reported to the TFM processor, if the counteφart is not a TFM processor participant.

Fund to Fund Trade

Fund to Fund trades can be submitted by either the same IM to handle internal crossings between two funds or by two IMs if they have traded using electronic networks like Instinet or E-crossnet. Funds to Fund trades are treated as a separate processing type within the TFM processor. The parties to the trade while reporting the trades will identify the trade as "Fund to Fund trade" as the processing type.

Fund to Fund trades will have two legs of trade. Both the legs of the trade are treated as normal institutional trades within the TFM processor. The Investment Manager(s) will be able to link these two institutional trades by using a Fund-to-Fund link reference number. The virtual broker will act as a common broker for both legs of the trade and will provide the Fund-to Fund link reference number while submitting the NOE for both legs of the trade. A virtual broker is either a clearing account in case of internal crossings or an institution providing the fund to fund crossing services (like E-crossnet). The other side of the trade will submit a BON. The information flow diagram of FIG. 92 explains the handling of a Fund-to-Fund trade.

The common virtual broker submitting an NOE for a Fund to Fund trade could have a role of an IM or a B/D. There are no other process variations within the TFM processor for handling of block trade processing of Fund to Fund trade.

The TFM processor will receive the Allocations from the IM and process the Allocation like any other institutional trade. No process change is envisaged for Allocation processing for fund to fund trades. This process enables Allocations on the buy side of the fund to fund trade and Allocations on the sell side of the fund to fund trade, to flow the information to the GCs of the underlying Funds.

Refer to the information flow diagram of FIG. 93 wherein the IM can submit all Net Proceeds Details for a Fund to Fund trade using a multi-part message along with allocation details. Alternatively, IM can also provide Net Proceeds and Allocation details message separately. The common virtual broker can submit the Net Proceeds and Settlement details in a multi-part message or in a separate message. TFM processor will carry out the net proceeds match and the settlement channel compatibility matches for the Fund to Fund Trades. The TFM processor will match Net Proceeds provided by both the participants after successful match of the trade. The proposed settlement location provided by the common virtual Broker will be used for the determination of applicable market tolerance for the trade. This process is same as the normal institutional trade. The clearing agent of the common B/D will act as a link for settlement of these trades. The settlement is done between the custodians of the underlying funds and the settlement agent of the counteφart. Two legs of these trades are settled via the intermediate counteφart. No process change is envisaged for settlement details processing.

Basket/Program/Portfolio Trading

Participants report and match separately the trades as individual institutional trades for each underlying security of the basket/program/portfolio trade. The trade transaction type will be reported as "Basket/Program/Portfolio trade". Participants specify a common Basket reference number for the underlying institutional trades of a basket. The Trade details relating to every Security comprised in the basket will be linked with this Basket Reference number given by the B/D. TFM processor will support queries to participants based on the basket/program/portfolio trade reference number. A typical basket/program/portfolio trade will be a pre-allocated trade where the B/D will specify the allocations for the underlying institutional trades. The IM or the B/D providing the Allocations will provide allocation quantities on an absolute basis for each Security comprised in the basket for each allocated client. TFM processor will not support the percentage allocations. The percentage allocations will have to be internalized by the participants in their applications. Separate allocation message will be sent for various securities comprised in the basket. No Process change is envisaged in the processing of a Basket/Program/Portfolio trades.

It will be readily seen by one of ordinary skill in the art that the present invention fulfills all ofthe objects set forth above. After reading the foregoing specification, one of ordinary skill will be able to effect various changes, substitutions of equivalents and various other aspects ofthe invention as broadly disclosed herein. It is therefore intended that the protection granted hereon be limited only by the definition contained in the appended claims and equivalents thereof.

Claims

We Claim:

1. A system for matching post-trade, pre-settlement information for a

securities transaction, the system comprising:

(a) a communications mechanism adapted to transmit and receive

transaction parameter messages setting forth one or more parameter values

related to a securities transaction;

(b) a processing mechanism, coupled to the communications

mechanism, and adapted to determine matches between one or more parameter

values of any two or more transaction parameter messages;

wherein the processing mechanism is further adapted to transmit an

indication message over the communications mechanism, the indication

message specifying at least one of: (i) the existence of matches between one or

more parameter values of any two or more transaction parameter messages; and

(ii) the non-existence of matches between one or more parameter values of any

two or more transaction parameter messages.

2. The system of claim 1 wherein one or more respective parameter

values are associated with coπesponding tolerances setting forth a maximum

acceptable deviation for the respective parameter value, and the processing

mechanism is further adapted to identify matches between parameter values

within the maximum acceptable deviation.

3. The system of claim 1 wherein the communications mechanism is

further adapted to accept incoming transaction parameter messages related to a

first securities transaction and incoming transaction parameter messages related

to a second securities transaction; and

wherein the processing mechanism includes a discrimination mechanism

adapted to distinguish incoming transaction parameter messages related to the

first securities transaction from incoming transaction parameter messages

related to the second securities transaction; the processing mechanism adapted

to determine matching within a predetermined tolerance and/or compatibility

between two or more incoming transaction parameter messages related to the

first securities transaction, and the processing mechanism also adapted to

determine matching within a predetermined tolerance and/or compatibility

between two or more incoming transaction parameter messages related to the

second securities transaction.

4. The system of claim 1 wherein the incoming transaction parameter

messages include parameter values specifying at least one of: (a) block trade

details, (b) allocation details, (c) net proceeds details, and (d) settlement details

for the securities transaction.

5. The system of claim 1 wherein the incoming transaction parameter

messages include parameter values specifying at least one of:

(a) a first set of one or more block trade details, (b) a first set of one or

more allocation details, (c) a first set of one or more net proceeds details, and

(d) a first set of one or more settlement details; and parameter values specifying at least one of:

(e) a second set of one or more block trade details, (f) a second set of

one or more allocation details, (g) a second set of one or more net proceeds

details, and (h) a second set of one or more settlement details;

wherein the processing mechanism determines compatibility by

identifying any matches between (a) and (e), (b) and (f), (c) and (g), and/or (d)

and (h).

6. . A system for matching post-trade, pre-settlement information for a

cross-border securities transaction between a first party and a second party, the

first party being a seller or a seller's representative and the second party being a

buyer or a buyer's representative, the transaction being defined by a plurality of

parameters, the system comprising:

an input mechanism adapted for receiving a message from the seller or the seller's representative and a message from the buyer or the buyer's representative, said messages each setting forth at least one value for at least one parameter relating to the transaction; a processing mechanism comprising a data storage for parameter values and a processor for comparing parameter values for each of a plurality of parameters to identify at least one of compatible and incompatible parameter values; and a communications mechanism coupled to the processing system for providing an output message indicative of at least one of: (i) identification of compatible parameter values; and (ii) identification of incompatible parameter values.

7. The system of claim 6, wherein a parameter comprises a value and a tolerance for the value.

8. The system of claim 7, wherein the processing mechanism determines whether a parameter received from the first party is within the tolerance for the value received from the second party.

9. The system of claim 6, wherein a parameter has a default value.

10. The system of claim 6, wherein a parameter has a default tolerance.

1 1. The system of claim 6, wherein a parameter identifies the seller or the seller's representative and the buyer or the buyer's representative.

12. The system of claim 6, wherein the processing mechanism assigns a unique identifier to a particular transaction.

13. The system of claim 6, wherein a parameter identifies a custodian for the seller's transaction.

14. The system of claim 13, wherein a parameter further identifies a custodian for the buyer's transaction.

15. The system of claim 13, wherein the processing mechanism notifies at least one custodian of a consummated transaction.

16. A system for matching post-trade, pre-settlement information for a cross-border securities transaction between a seller's representative and a buyer's representative, the transaction being defined by a plurality of parameters, the security being held by a custodian, the system comprising: a communications mechanism for receiving messages from the seller's representative and the buyer's representative, said messages comprising values for the parameters relating to the transaction; a processing system comprising data storage for parameter values and notifying the seller's representative and the buyer's representative of the parameters for a securities transaction; and an indication mechanism for providing an indication to the

communications mechanism which is indicative of one or more parameters for

the securities transaction.

17. A method of matching post-trade, pre-settlement information for a

cross-border securities transaction, the method including the steps of:

(a) receiving transaction parameter messages setting forth one or more

parameter values related to a securities transaction;

(b) storing transaction parameter messages; (c) determining matches between one or more parameter values of any

two or more transaction parameter messages related to the securities

transaction;

(d) transmitting an indication message specifying at least one of: (i) the

existence of matches between one or more parameter values of the any two or

more transaction parameter messages; and (ii) the non-existence of matches

between one or more parameter values of any two or more transaction

parameter messages.

18. The method of claim 17 further including the steps of:

(a) accepting transaction parameter messages related to a first securities

transaction and transaction parameter messages related to a second securities

transaction;

(b) distinguishing incoming transaction parameter messages related to

the first securities transaction from incoming fransaction parameter messages

related to the second securities transaction; and

(c) determining compatibility between two or more incoming transaction

parameter messages related to the first securities fransaction.

19. The method of claim 18 further including the step of determining

compatibility between two or more incoming transaction parameter messages

related to the second securities transaction.

20. The method of claim 17 further including the steps of:

accepting incoming transaction parameter messages related to a first

securities fransaction and specifying at least one of: (a) a first set of one or

more block frade details, (b) a first set of one or more allocation details, (c) a

first set of one or more net proceeds details, and (d) a first set of one or more

settlement details;

and accepting incoming fransaction parameter messages specifying at least one

of:

(e) a second set of one or more block frade details, (f) a second set of

one or more allocation details, (g) a second set of one or more net proceeds

details, and (h) a second set of one or more settlement details; and

determining compatibility by identifying any matches between (a) and

(e), (b) and (f), (c) and (g), and or (d) and (h).

21. A post-trade, pre-settlement system for facilitating a securities

fransaction and comprising:

a. a computer processing mechanism;

b. an interfacing mechanism adapted for interfacing the computer

processing mechanism with at least two of the following entities: a seller of a

securities instrument, a buyer ofthe securities instrument, and a holder ofthe

securities instrument; wherein, in response to the issuance of a notification of execution

(NOE) message from the interfacing mechanism, the computer provides

multilateral data communications between the at least two entities.

22. The post-trade, pre-settlement system of claim 21 wherein the

multilateral data communications includes data specifying at least one of a

settlement location or venue; a source allocation for the securities fransaction;

and an amount of net proceeds for the securities fransaction.

23. The post-trade, pre-settlement system of claim 21 wherein, for a

first securities fransaction, data specifying at least one of:

(a) a first proposed settlement location,

(b) a first proposed source allocation, and

(c) a first proposed amount of net proceeds,

are entered into the interfacing mechanism, and, for the first securities

transaction, data specifying at least one of:

(d) a second proposed settlement location,

(e) a second proposed source allocation, and

(f) a second proposed amount of net proceeds,

are entered into the interfacing mechanism; the computer processing mechanism further including a matching

mechanism for identifying any matches between the first and second proposed

settlement locations, the first and second proposed source allocations, and the

first and second proposed amounts of net proceeds.

24. The post-trade, pre-settlement system of claim 21 wherein the

computer further includes a confirmation mechanism for sending a

confirmation message to the interfacing mechanism, the confirmation message

identifying matches, if any, between the first and second proposed settlement

locations, the first and second proposed source allocations, and the first and

second proposed amounts of net proceeds.

25. The post-trade, pre-settlement system of claim 24 wherein the

interfacing mechanism includes at least a first interface situated within a first

region defined with reference to geographic, economic, and/or political

boundaries, and a second interface not situated within the first region, so as to

facilitate a cross-border securities fransaction.

26. The post-trade, pre-settlement system of claim 24 wherein, for a

first securities fransaction, a first data set specifying at least one of:

(a) a first proposed settlement location,

(b) a first proposed source allocation, and

(c) a first proposed amount of net proceeds,

are entered into the interfacing mechanism, and, for the first securities

fransaction, a second data set specifying at least one of:

(d) a second proposed settlement location,

(e) a second proposed source allocation, and

(f) a second proposed amount of net proceeds,

are entered into the interfacing mechanism; and

for a second securities transaction, a third data set specifying at least one

of:

(a) a first proposed settlement location,

(b) a first proposed source allocation, and

(c) a first proposed amount of net proceeds,

are entered into the interfacing mechanism; and

for the second securities fransaction, a fourth data set specifying at least

one of:

(d) a second proposed settlement location,

(e) a second proposed source allocation, and

(f) a second proposed amount of net proceeds,

mechanism for matching the first data set to the second data set, for matching

the third data set to the fourth data set, and for identifying any matches, as

between the first and second data sets, for the first and second proposed

settlement locations, the first and second proposed source allocations, and the

first and second proposed amounts of net proceeds.

27. A method for facilitating settlement of a securities transaction

including the steps of:

(a) receiving transaction parameter messages setting forth one or more

parameter values related to a securities fransaction;

(b) a determining matches between one or more parameter values of any

two or more fransaction parameter messages; and

(c) transmitting an indication message specifying at least one of: (i) the

existence of matches between one or more parameter values of any two or

more transaction parameter messages; and (ii) the non-existence of matches

between one or more parameter values of any two or more transaction

parameter messages.

28. The method of claim 27 wherein one or more respective parameter values

are associated with coπesponding tolerances setting forth a maximum acceptable deviation for the respective parameter value,

and wherein the method further includes the step of identifying matches

between parameter values within the maximum acceptable deviation.

29. The method of claim 27 further including the steps of:

(a) accepting incoming fransaction parameter messages related to a first

securities transaction and incoming fransaction parameter messages related to a

second securities fransaction;

(b) distinguishing incoming fransaction parameter messages related to

the first securities fransaction from incoming fransaction parameter messages

related to the second securities fransaction;

(c) determining compatibility between two or more incoming fransaction

parameter messages related to the first securities fransaction; and

(d) determining compatibility between two or more incoming

fransaction parameter messages related to the second securities fransaction.

30. The method of claim 27 wherein the transaction parameter

messages include parameter values specifying at least one of a settlement

location or venue; a source allocation for the securities fransaction; and an

amount of net proceeds for the securities fransaction.

31. The method of claim 27 wherein the incoming fransaction

parameter messages include parameter values specifying at least one of:

(a) a first proposed settlement location,

(b) a first proposed source allocation, and

(c) a first proposed amount of net proceeds,

and parameter values specifying at least one of:

(d) a second proposed settlement location,

(e) a second proposed source allocation, and

(f) a second proposed amount of net proceeds,

the method further including the step of:

determining fransaction parameter message compatibility by identifying any

matches between the first and second proposed settlement locations, the first

and second proposed source allocations, and the first and second proposed

amounts of net proceeds.

32. A method for facilitating settlement of a cross-border securities fransaction between a first party and a second party, the first party being a seller or a seller's representative and the second party being a buyer or a buyer's representative, the fransaction being defined by a plurality of parameters, the method including the steps of:

(a) receiving a message from the seller or the seller's representative and a message from the buyer or the buyer's representative, said messages each setting forth at least one value for at least one parameter relating to the fransaction; (b) storing the received messages;

(c) comparing the parameter values of the received messages for each of a plurality of parameters to identify at least one of compatible and incompatible parameter values; and

(d) providing an output message indicative of at least one of: (i) identification of compatible parameter values; and (ii) identification of incompatible parameter values.

33. The method of claim 32, wherein a parameter comprises a value and a tolerance for the value.

34. The method of claim 33 further including the step of determining whether a parameter received from the first party is within the tolerance for the value received from the second party.

35. The method of claim 32, wherein a parameter has a default value.

36. The method of claim 32, wherein a parameter has a default tolerance.

37. The method of claim 32, wherein a parameter identifies the seller or the seller's representative and the buyer or the buyer's representative.

38. The method of claim 32, further including the step of assigning a unique identifier to a particular fransaction.

39. The method of claim 32, further including the step of utilizing a fransaction parameter to identify a custodian for the seller's security.

40. The method of claim 39, further including the step of utilizing a fransaction parameter to identify a custodian for receipt ofthe buyer's security.

41. The method of claim 39, further including the step of notifying the custodian for the seller's security and the custodian for receipt ofthe buyer's security of a consummated fransaction.

42. A method for facilitating settlement of a cross-border securities fransaction between a seller's representative and a buyer's representative, the securities transaction being defined by a plurality of parameters, the security being held by a custodian, the method including the steps of: receiving messages from the seller's representative and the buyer's representative, said messages including parameter values for at least one parameter relating to the securities fransaction; storing the parameter values; notifying the seller's representative and the buyer's representative ofthe parameters pertaining to the securities fransaction; and providing an indication to at least one of the seller's representative and

the buyer's representative of one or more parameter values for the securities

fransaction.

43. A method for facilitating settlement of a securities fransaction

including the steps of:

(a) receiving fransaction parameter messages setting forth one or more

parameter values related to a securities fransaction;

(b) storing transaction parameter messages;

(c) determining matches between one or more parameter values of any

two or more fransaction parameter messages related to the securities

fransaction;

(d) transmitting an indication message over the communications

mechanism, the indication message specifying at least one of: (i) the existence

of matches between one or more parameter values ofthe any two or more

fransaction parameter messages; and (ii) the non-existence of matches between

one or more parameter values of any two or more fransaction parameter

messages.

44. The method of claim 43 further including the steps of:

(a) receiving fransaction parameter messages related to a first securities

fransaction and transaction parameter messages related to a second securities

transaction;

(b) distinguishing incoming fransaction parameter messages related to

the first securities transaction from incoming fransaction parameter messages

related to the second securities fransaction; and (c) determining compatibility between two or more incoming fransaction

parameter messages related to the first securities fransaction.

45. The method of claim 44 further including the step of determining

compatibility between two or more incoming fransaction parameter messages

related to the second securities transaction.

46. The method of claim 43 further including the steps of:

(a) receiving incoming transaction parameter messages related to a first

securities fransaction and specifying at least one of:

(a) a first proposed settlement location,

(b) a first proposed source allocation, and

(c) a first proposed amount of net proceeds,

(b) receiving incoming transaction parameter messages related to the

first securities fransaction and specifying at least one of:

(d) a second proposed settlement location,

(e) a second proposed source allocation, and

(f) a second proposed amount of net proceeds,

(c) determining compatibility by identifying any matches between the

first and second proposed settlement locations, the first and second proposed

source allocations, and the first and second proposed amounts of net proceeds.

47. A post-trade, pre-settlement method for facilitating a securities

fransaction, the method for use with a system comprising: a computer

processing mechanism and an interfacing mechanism adapted for interfacing

the computer processing mechanism with at least two of the following entities:

a seller of a securities instrument, a buyer ofthe securities instrument, and a

holder ofthe securities instrument; the method comprising the steps of:

(a) the interfacing mechanism receiving at least one of a notification of

execution (NOE) message and/or a block order notification (BON) message;

and

(b) in response to receipt of the NOE and/or BON message from the

interfacing mechanism, the computer providing multilateral data

communications between the at least two entities.

48. The post-trade, pre-settlement method of claim 47 wherein the

multilateral data communications includes data specifying at least one of a

and an amount of net proceeds for the securities fransaction.

49. The post-trade, pre-settlement method of claim 47 wherein, for a first securities transaction, data specifying at least one of:

(a) a first proposed settlement location,

(b) a first proposed source allocation, and

(c) a first proposed amount of net proceeds,

are entered into the interfacing mechanism, and, for the first securities

fransaction, data specifying at least one of:

(d) a second proposed settlement location,

(e) a second proposed source allocation, and

(f) a second proposed amount of net proceeds,

are entered into the interfacing mechanism;

the computer processing mechanism further including a matching

mechanism for identifying any matches between the first and second proposed

settlement locations, the first and second proposed source allocations, and the

first and second proposed amounts of net proceeds.

50. The post-trade, pre-settlement method of claim 47 further including

the step ofthe computer sending a confirmation message to the interfacing

mechanism, the confirmation message identifying matches, if any, between the

first and second proposed settlement locations, the first and second proposed

source allocations, and the first and second proposed amounts of net proceeds.

51. The post-frade, pre-settlement method of claim 50 wherein the

region defined with reference to geographic, economic, and/or political

facilitate a cross-border securities fransaction.

52. The post-frade, pre-settlement method of claim 50 further including

the steps of:

(a) for a first securities fransaction, entering a first data set specifying at

least one of:

(i) a first proposed settlement location,

(ii) a first proposed source allocation, and

(iii) a first proposed amount of net proceeds,

into the interfacing mechanism,

(b) for the first securities fransaction, entering a second data set

specifying at least one of:

(iv) a second proposed settlement location,

(v) a second proposed source allocation, and

(vi) a second proposed amount of net proceeds,

are entered into the interfacing mechanism; (c) for a second securities fransaction, entering a third data set

specifying at least one of:

(i) a first proposed settlement location,

(ii) a first proposed source allocation, and

(iii) a first proposed amount of net proceeds,

into the interfacing mechanism;

(d) for the second securities fransaction, entering a fourth data set

specifying at least one of:

(iv) a second proposed settlement location,

(v) a second proposed source allocation, and

(vi) a second proposed amount of net proceeds,

into the interfacing mechanism; and

(e) matching the first data set to the second data set, matching the third

data set to the fourth data set, and for identifying any matches, as between the

first and second data sets, for the first and second proposed settlement

locations, the first and second proposed source allocations, and the first and

second propo ed amounts of net proceeds.

53. A method of facilitating settlement of a securities fransaction for

use with a system that is adapted to receive, store, and determine matches

between two or more transaction parameter messages each specifying one or more fransaction parameter values related to the securities transaction, the

method including the steps of:

(a) inputting data setting forth one or more parameter values related to

the securities fransaction; the data comprising a fransaction parameter message;

(b) receiving an indication message specifying at least one of: (i) the

existence of matches between one or more parameter values of the any two or

more fransaction parameter messages related to the securities transaction; and

(ii) the non-existence of matches between one or more parameter values of any

two or more transaction parameter messages related to the securities

fransaction.

54. The rnethod of claim 53 wherein the system is further adapted to

distinguish incoming fransaction parameter messages related to a first securities

transaction from incoming fransaction parameter messages related to a second

securities fransaction, and for determining compatibility between two or more

incoming transaction parameter messages related to the first securities

transaction; the method further including the step of:

inputting transaction parameter messages related to the first securities

fransaction and fransaction parameter messages related to the second securities

fransaction.

55. The method of claim 54 wherein the system is further adapted to

determine compatibility between two or more incoming transaction parameter

messages related to the second securities fransaction.

56. The method of claim 53 further including the steps of:

(a) inputting incoming transaction parameter messages related to a first

securities transaction and specifying at least one of:

(a) a first proposed settlement location,

(b) a first proposed source allocation, and

(c) a first proposed amount of net proceeds,

(b) inputting incoming transaction parameter messages related to the

first securities fransaction and specifying at least one of:

(d) a second proposed settlement location,

(e) a second proposed source allocation, and

(f) a second proposed amount of net proceeds,

the system determining compatibility by identifying any matches between the

first and second proposed settlement locations, the first and second proposed

source allocations, and the first and second proposed amounts of net proceeds.

57. A post-trade, pre-settlement method for facilitating a securities transaction,

the method for use with a system comprising: a computer processing

mechanism and an interfacing mechanism adapted for interfacing the computer

processing mechanism with at least two of the following entities: a seller of a

securities instrument, a buyer ofthe securities instrument, and a holder of the

securities instrument; the method comprising the steps of:

(a) inputting into the interfacing mechanism at least one of a notification

of execution (NOE) message and/or a block order notification (BON) message;

and

(b) in response to receipt ofthe NOE and/or BON message from the

interfacing mechanism, the computer providing multilateral data

communications between the at least two entities.

58. The post-frade, pre-settlement method of claim 57 wherein the

multilateral data communications includes data specifying at least one of a

and an amount of net proceeds for the securities fransaction.

59. The post-trade, pre-settlement method of claim 57 wherein, for a

first securities transaction, entering data specifying at least one of:

(a) a first proposed settlement location, (b) a first proposed source allocation, and

(c) a first proposed amount of net proceeds,

into the interfacing mechanism, and, for the first securities fransaction, entering

data specifying at least one of:

(d) a second proposed settlement location,

(e) a second proposed source allocation, and

(f) a second proposed amount of net proceeds,

into the interfacing mechanism;

receiving a notification from the computer processing mechanism that

identifies any matches between the first and second proposed settlement

locations, the first and second proposed source allocations, and the first and

second proposed amounts of net proceeds.

60. The post-frade, pre-settlement method of claim 57 further including

the step of receiving a confirmation message at the interfacing mechanism, the

confirmation message identifying matches, if any, between the first and second

proposed settlement locations, the first and second proposed source allocations,

and the first and second proposed amounts of net proceeds.

61. The post-frade, pre-settlement method of claim 60 wherein the interfacing mechanism includes at least a first interface situated within a first

region defined with reference to geographic, economic, and/or political

facilitate a cross-border securities fransaction.

62. The post-frade, pre-settlement method of claim 60 further including

the steps of:

(a) for a first securities fransaction, entering a first data set specifying at

least one of:

(i) a first proposed settlement location,

(ii) a first proposed source allocation, and

(iii) a first proposed amount of net proceeds,

into the interfacing mechanism,

(b) for the first securities fransaction, entering a second data set

specifying at least one of:

(iv) a second proposed settlement location,

(v) a second proposed source allocation, and

(vi) a second proposed amount of net proceeds,

are entered into the interfacing mechanism;

(c) for a second securities transaction, entering a third data set

specifying at least one of:

(i) a first proposed settlement location,

(ii) a first proposed source allocation, and

(iii) a first proposed amount of net proceeds,

into the interfacing mechanism;

(d) for the second securities transaction, entering a fourth data set

specifying at least one of:

(iv) a second proposed settlement location, (v) a second proposed source allocation, and

(vi) a second proposed amount of net proceeds,

into the interfacing mechanism; and

(e) matching the first data set to the second data set, matching the third data set to

the fourth data set, and for identifying any matches, as between the first and second data

sets, for the first and second proposed settlement locations, the first and second proposed

source allocations, and the first and second proposed amounts of net proceeds.

63. A system for facilitating settlement of a securities transaction between a buyer and a seller, comprising:

(a) a communications mechanism for transmitting and receiving messages from the buyer and the seller, the messages including one or more parameter values related to the transaction;

(b) a processing mechanism, coupled to the communications mechanism,

(i) for determining the compatibility of parameter values received in messages from the buyer and seller, and (ii) for transmitting, via the communications mechanism, to at least one of the buyer and the sell, the compatibility determination in part (i); wherein at least one of said messages is fransmitted across geographic, economic, and/or political boundaries.

64. The system of claim 63, wherein the processing mechanism further comprises translating a security identification into a different type of security identification.

65. The system of claim 64, wherein the processing mechanism translates CUSIF into ISIN.

66. The system of claim 64, wherein the processing mechanism translates ISIN into CUSIP.

67. The system of claim 63, further comprising an interfacing mechanism adaptec for interfacing the processing mechanism with at least two of the following six entities: a seller of a securities instrument, a representative ofthe seller of a securities instrument, a buyer ofthe securities instrument, a representative ofthe buyer of a securities instrument, a holder ofthe physical securities instrument, and a recipient of the physical securities instrument.

68. The system of claim 67, wherein the at least two entities are located in different geographic, economic, and/or political locations.

69. The system of claim 68, wherein at least one of the at least two entities is the seller or the buyer.

70. The system of claim 68, wherein at least one of the at least two entities is a representative ofthe seller or a representative ofthe buyer.

71. The system of claim 68, wherein at least one of the at least two entities is the holder ofthe physical securities instrument or the recipient ofthe physical securities instrument.

72. The system of claim 63, wherein said communications mechanism or said

73. The system of claim 72, wherein the seller, the buyer, and the processing mechanism are in three different international geographic, economic, and/or political locations.

74. The system of claim 72, wherein the representative ofthe seller, the representative ofthe buyer, and the processing mechanism are in three different international geographic, economic, and/or political locations.