WO2007033095A2 - Procede et systeme de comparaison de contrats dans des transactions de pret de titres - Google Patents

Procede et systeme de comparaison de contrats dans des transactions de pret de titres Download PDF

Info

Publication number
WO2007033095A2
WO2007033095A2 PCT/US2006/035349 US2006035349W WO2007033095A2 WO 2007033095 A2 WO2007033095 A2 WO 2007033095A2 US 2006035349 W US2006035349 W US 2006035349W WO 2007033095 A2 WO2007033095 A2 WO 2007033095A2
Authority
WO
WIPO (PCT)
Prior art keywords
communication
securities
records
hub
party
Prior art date
Application number
PCT/US2006/035349
Other languages
English (en)
Other versions
WO2007033095A3 (fr
Inventor
Melissa Hodson
Original Assignee
Equilend Holdings Llc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Equilend Holdings Llc filed Critical Equilend Holdings Llc
Publication of WO2007033095A2 publication Critical patent/WO2007033095A2/fr
Publication of WO2007033095A3 publication Critical patent/WO2007033095A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange

Definitions

  • the invention relates to methods and systems to facilitate securities lending transactions for borrowers, sellers and related parties. By providing a central hub through which interested parties can easily locate suitable counterparties and book transactions, this invention avoids the time-consuming and labor-intensive process of matching borrowers and lenders.
  • the invention is characterized, at least in part, by the architecture and design of a standards-based, open, and secure global securities lending platform, or hub, and more particularly to the methodologies in the initiation, processing, settlement of transactions and related back-office operations that such a platform provides for its participants.
  • the invention is further characterized by processes that allow users to compare loan contracts for equities and fixed income securities, identify discrepancies in terms, and view and reconcile the discrepancies online.
  • Securities lending transactions generally involve the simultaneous or near- simultaneous transfer of securities for collateral.
  • Significant securities lenders include entities such as banks, investment managers, pension funds, mutual fund complexes, endowment funds and insurance companies. Lenders often lend securities to supplement or earn incremental income on their portfolio holdings. Borrowers are generally broker/dealers and banks. Borrowers often borrow securities to facilitate trade settlements, and to support both proprietary and customer trading strategies.
  • Participants in securities borrowing and lending transactions can be further sub-classified into: Beneficial Owners; Agent Lenders; Broker/Dealers; and External Customers.
  • Beneficial Owners are the true owners of securities.
  • Agent Lenders are often banks that custody the shares of the beneficial owners and represent the beneficial owners in securities lending transaction.
  • Agent lenders often represent more than one beneficial owner, thus creating an aggregate pool of securities to lend.
  • Agent lenders generally provide administrative services to the beneficial owners such as reporting, corporate actions monitoring, collateral management and billing.
  • Broker/Dealers often have securities borrowing and lending trading desks that coordinate the borrowing of securities from lenders to cover customer and proprietary trading needs such as arbitraging, hedging and short selling.
  • Broker/dealers may also borrow securities to settle transactions that are failing, or to lend them to other broker/dealers.
  • Securities lending has become a central part of securities market activity in recent years, to a point where the daily volume of securities transactions for financing purposes considerably exceeds that of outright purchase and sale transactions.
  • Securities lending involves the temporary exchange of securities, usually for other securities or cash of an equivalent value (or occasionally a mixture of cash and securities), with an obligation to redeliver a like quantity of the same securities at a future date.
  • Most securities lending is structured to give the borrower legal title to the securities for the life of the transaction, even though, economically, the terms are more akin to a loan.
  • the borrow fee is generally agreed in advance and the lender has contractual rights similar to beneficial ownership of the securities, with rights to receive the equivalent of all interest payments or dividends and to have equivalent securities returned. The importance of the transfer of legal title is twofold.
  • a stock or bond is exchanged for collateral between a lender and a borrower for temporary use.
  • the lender through its lending agent delivers a security to an approved borrower in return for collateral, usually in the form of cash, U.S. Government securities, letters of credit, or other selective forms of non-cash collateral.
  • the borrower is a broker/dealer who uses the securities to meet an array of short-term needs, including: avoiding settlement failures, supporting hedging - short selling strategies, and to facilitate arbitrage opportunities.
  • Collateral is a key element in a securities lending transaction.
  • a borrower provides collateral to the lending agent to secure the borrower's promise to return the security within an agreed upon timeframe.
  • the collateral requirement for domestic loans is 102% and 105% for international loans.
  • the excess collateral serves as a safeguard against counterparty credit risk in the event of a borrower default, which could necessitate the collateral being liquidated and repurchasing the loaned security.
  • Monitoring the collateral adequacy known as performing a "mark-to-market," occurs daily. Should the collateral fall below 100% of its market value, additional collateral is requested from the borrower to restore the value to its appropriate level.
  • the lending agent agrees to pay interest, known as the rebate, to the borrower for the use of the cash collateral.
  • the amount of the rebate reflects the intrinsic value of the loaned security - keeping in mind that some securities are more highly sought after than others. The higher the demand is for the security, the lower the rebate that will need to be paid.
  • the cash collateral is then invested by the lending agent in accordance with the lender's investment guidelines. The goal is to earn a higher yield on the reinvestment of cash collateral than the rebate promised to the borrower.
  • the earnings generated above and beyond the rebate amount referred to as the "spread," represent the profit in the transaction.
  • the borrower and lender negotiate a premium (or a flat fee) to be paid in place of the rebate.
  • the Instinet system includes a series of terminals, each accessible to a member and a central computer. Each member may submit for display a firm offer to buy or sell a given number of shares of a certain security at a stated price. The member may also submit bids or offers of a security without price. This information, minus the submitter's identity, is displayed to all members, in a price sequence.
  • Any member may respond to an offer through the negotiating option of a counteroffer and the system will allow private communications between the two members until and if an agreed upon price is reached.
  • a member may submit an acceptance of any offer displayed to all members.
  • the system executes orders when a buyer and seller have agreed upon a price.
  • the parties to an executed trade deliver the shares of stock and purchase price to a designated bank for a conventional clearing operation. If a bid and an ask are submitted at the same price, the system will consummate the trade.
  • the Instinet system is not designed to address the unique aspects of securities lending.
  • the Instinet system does not provide potential borrowers or lenders the ability to transmit, in real-time, their availability and parameters for a desired transaction, making the process of matching amenable counterparties time-consuming and labor-intensive, especially when the parties reside in disparate geographic locations and time zones.
  • the invention relates to a system and method for facilitating securities lending transactions, comprising at least an application tier, a messaging tier and presentation tier. These tiers form a hub that may be in electronic communication with a public or proprietary distributed network and provide a centralized system for communication between securities trading firms, brokers, and other participants in a process for lending securities.
  • a member firm wishing to engage in a securities lending transaction may initiate a "firm request" indicating a desire to loan or borrow securities.
  • the request is transmitted via the distributed network, via the hub, and is intercepted by the messaging tier.
  • the messaging tier forwards the request to an application tier to validate the syntax of the message and/or process the request.
  • the application tier may transmit the request back to the messaging tier for distribution to suitable counterparties.
  • the requests may be formatted in the Extensible Markup Language (XML) or the Securities Lending Markup Language (SLML).
  • XML Extensible Markup Language
  • SLML Securities Lending Markup Language
  • Other embodiments of the invention relate to methods and systems for comparing loan contracts for equities and fixed income securities, identifying discrepancies in terms, and viewing and reconciling the discrepancies online.
  • FIG. 1 shows an illustrative embodiment of the hub of the present invention.
  • FIG. 2 shows an illustrative embodiment of message flow using two-channel transmission.
  • FIG. 3 shows an illustrative embodiment of a participating lender making an availability broadcast.
  • FIG. 4 shows an illustrative embodiment of parties engaging in one-to-one negotiations.
  • FIG. 5 shows an illustrative embodiment of the autoborrow feature of the present invention.
  • FIG. 6 shows an illustrative embodiment of the contract comparison feature of the present invention.
  • FIG. 7 shows an illustrative embodiment of mark-to-market comparison feature of the present invention.
  • FIG. 8 shows an illustrative embodiment of the billing comparison feature of the present invention.
  • FIG. 9 shows an illustrative embodiment of the Return/Recall feature of the present invention.
  • FIG. 10 shows an illustrative embodiment of the trading feature of the present invention.
  • FIG. 11 shows an illustrative embodiment of the autoborrow feature of the present invention.
  • FIG. 12 shows an illustrative embodiment of the initiation of the autoborrow feature of the present invention.
  • FIG. 13 is a block diagram of the contract comparison process from a file input and output perspective in one embodiment of the invention.
  • FIG. 14 is a block diagram showing how the system attempts to match up data in the counterparty files based on six different levels of information ("steps") in one embodiment of the invention.
  • steps levels of information
  • contract comparison may be run as a service module that is integrated into a larger securities lending system.
  • a larger securities lending system is the EQUILEND system ("System” or “Platform”) by EquiLend Holdings, LLC of New York, NY.
  • the System provides a global securities lending hub/platform to eliminate the inefficiencies associated with the current approach and to create and implement specific methodologies for the benefit of its participants.
  • the System allows for the elimination of redundant IT infrastructure, a uniform protocol (such as an XML-based protocol called SLML) to communicate with all trading partners, a single open standards-based infrastructure to transact with all trading partners, ease of integration of their proprietary systems with the hub in real-time, the ability to define business rules which operate on the data in their proprietary systems and automatically initiate trades through the hub/platform, reduction of IT complexity and associated costs, and increased throughput with regard to the number of transactions in a given time period.
  • SLML XML-based protocol
  • the System is characterized, at least in one embodiment, as a hub-based platform that provides a browser-based user interface.
  • a hub-based platform that provides a browser-based user interface.
  • the system can be used over any local-area or distributed network, the Internet can be used to avoid the expense of a proprietary transport network.
  • This standards-based platform may use an XML-based protocol, such as SLML, to provide a symmetrical, non-biased system with equal capabilities for borrowers and lenders participating in securities lending transactions.
  • SLML Securities Lending Markup Language
  • XML Extensible Markup Language
  • XML Extensible Markup Language
  • XML allows users to organize document elements (words, pictures, etc.) based on a structural hierarchy that can be easily exchanged over the World Wide Web. It is independent of any underlying programming language, transport mechanism or messaging protocol and allows foil flexibility.
  • SLML like XML
  • SLML is interoperable across platforms.
  • SLML supports the seamless exchange of electronic data between and within institutions using diverse technology platforms.
  • securities lending data can be exchanged between applications within an individual firm and throughout the industry.
  • SLML is STP-Oriented.
  • Firms can benefit by improving the overall efficiency of the securities lending process as they seek to implement straight-through processing (STP) in order to reduce trade failures and shorten transaction processing cycles.
  • STP straight-through processing
  • the Hub application processes the message and sends one or more messages to the specified recipient and a confirmation message, if requested, is sent to the member who initiated the transaction.
  • participant firms may send messages to the hub/platform and/or their trading partners. All operations including the initiation, negotiation, confirmation and rejection of trades, posting of available securities and the back- office comparison operations involve the exchange of messages between the platform and the member firms.
  • FIG. 1 A high-level overview illustrating one embodiment of the function of the hub and the communication that is handled by the hub is shown in FIG. 1.
  • a tier is a collection of one or more software components that provide a high-level technical function or feature (e.g. a database tier providing the ability to store, update and retrieve data).
  • a database tier providing the ability to store, update and retrieve data.
  • Another commonly used term to describe a set of components is a 'layer' and hence these two terms ('tier' and 'layer') are used interchangeably in this document.
  • the overall system includes a database tier that acts as the storage for all data, both static and dynamic, that is essential for the functioning of the platform.
  • the data includes set-up data such as information about the members, their users, their relationships with other members and the agreements between them in relation to the various back office functions. It also includes highly dynamic data such as information about the various transactions, the parties, securities and other attributes of these transactions.
  • This tier can be implemented using any Relational Database Management System (RDBMS) such as Oracle, Sybase and MS SQL Server.
  • RDBMS Relational Database Management System
  • the overall system also includes an Application Tier that is the implementation of the business rules necessary for the initiation, validation and execution of the securities lending transactions between the members.
  • This tier consists of one or more modules that encapsulate the set of specific functions necessary to perform an action or satisfy a request related to each functional area (such as autoborrow or availability). Typically, these modules interpret a business request semantically to perform a series of steps that will result in the creation/update or retrieval of data from the database (by sending the appropriate requests to the database tier) and the creation of response messages that will be transmitted by the messaging tier. In that sense, this tier is the heart of the platform and acts as the interface to the business functionality to the other tiers. Both the presentation and messaging tiers use this tier to satisfy the requests originated by either the user actions in the browser or by an XML message sent by a member's proprietary system.
  • a messaging tier acts as the hub's interface to the member's proprietary systems. Members conduct transactions with their counterparties by exchanging messages with the system platform.
  • Each XML message has a type, subtype and data. The type and subtype indicate the business function (autoborrow, negotiation, contract-compare, login etc.) the message intends to perform and the data that is pertinent to that specific business function.
  • These messages are sent to and received by entities known as 'queues'. Simply described, queues are objects that hold messages.
  • a queue that is local to the program that is sending a message is known as a local queue and a remote queue is one that is located in a remote environment.
  • FIGS 11 and 12 illustrate examples of the use of the autoborrow feature of the present invention and the initiation of the process.
  • the messaging tier acts as the interface that provides core messaging, both of sending and receiving XML messages, to and from the other tiers.
  • the messaging tier receives XML messages, parses them and extracts valid values from various fields. It then determines the appropriate component in the application layer that handles this business process and interacts with that component to perform the necessary function.
  • the application tier uses the functionality provided by the messaging tier to construct valid XML messages and send them to the intended recipients.
  • the messaging layer determines the appropriate component in the application layer that can handle this request and hands the request over to that component.
  • the components in the application layer interpret the message functionally and thus determine the counterparties to whom this autoborrow request should be sent and calculates any other values that need to be filled in the response messages.
  • the application layer then invokes the messaging layer to send a request to the designated counterparties.
  • a similar sequence of actions takes place when the initial request originates from a user action through the browser, instead of a participating firm's proprietary system.
  • the presentation tier intercepts the HTTP request instead of the messaging layer. It should be noted that in a preferred embodiment of the system, most real-time messages that need to be sent in bulk will originate from a member's proprietary system and thus will be intercepted by the messaging layer.
  • the presentation tier is the layer that deals with the user interaction portion of the application.
  • the system's user interface is an easy to use web-based interface. Users can perform various business and related functions by navigating through the screens in their browser. Each such action results in one or more HTTP requests that are sent to the web server and eventually reach the presentation tier.
  • the presentation tier intercepts requests made by the user through the web-browser, parses and validates them and works with the application layer to perform the function desired by the user.
  • the present system supports browsers including Internet Explorer and Netscape. It is preferred that the most recent version of each browser is used. With Internet Explorer, it is preferred to use a version at least as recent as version 5.5.
  • the communication between the member firms and the hub are based on guidelines defining point-to-point interactions between member firms. Each member firm, however, can communicate with multiple member firms via the hub, and a member firm can receive and respond to multiple communication requests.
  • member firms can use various commercial software packages for creating and handling their XML messages and responses.
  • member firms are responsible for building the actual XML messages (with correct syntax and inputs) and then sending the message to the hub, to initial an XML request.
  • Member firms then use the XML response received from the hub in their interactions with their end-users.
  • the member firms then aggregates data received from multiple XML requests or, when communicating with multiple firms through the hub, aggregates the data received from all responses.
  • the member firm may then store the data for later use, such as for forwarding to an end- user.
  • the system provides means for servicing XML requests received from member firms. These means, such as an MQ handler application (such as the MQ Series Middleware Application sold by IBM Corporation of Armonk, NY), process accepted XML requests, construct appropriate XML responses, and send responses back to member firms. Incoming XML requests may also be validated by verifying the XML request syntax, input data and access permissions before processing the request. When a request is received from a member firm that requires aggregation of data, the system may aggregate data from multiple sources (which may be located locally or anywhere on a distributed network which is in communication with the system) to provide the appropriate response.
  • MQ handler application such as the MQ Series Middleware Application sold by IBM Corporation of Armonk, NY
  • Incoming XML requests may also be validated by verifying the XML request syntax, input data and access permissions before processing the request.
  • the system may aggregate data from multiple sources (which may be located locally or anywhere on a distributed network which is in communication with the system) to provide the appropriate response.
  • the message queue design of the present system supports the transmission different types of messages using a two-channel transmission from the member firm's queue manager to the system message queue manager and back. This type of system may separate high-priority messages from bulk data transmission and is illustrated in
  • the messages sent between the member firms and the system hub permit potential borrowers and lenders to communicate and identify one another, as part of the process of beginning a securities lending transaction, as shown in FIG. 3.
  • a lender may wish to locate suitable counterparties.
  • the lender sends an availability broadcast from their own proprietary system to the system hub or from a browser that includes software, applets, scripts, etc. for communicating with the system hub in an appropriate protocol.
  • the availability broadcast may be tailored to include particular criteria set by the lender, such as the security they wish to lend, number of shares, financial terms, etc.
  • the system hub can retransmit the availability broadcast to any or all member firms or browsers in communication with the hub.
  • Borrowers who agree to the terms set forth in the availability broadcast may then choose to enter into a securities lending transaction with the lender or enter into negotiations over the terms of the securities loan.
  • One aspect of the invention is the ability for users of the system to engage in one-to-one negotiations.
  • a trader can choose to send the order to a single counterparty or to multiple counterparties. If the trader chooses to send the order to multiple counterparties, the system automatically generates a unique order with its own ID for each counterparty. Because the initiating trader must negotiate each order separately, this is referred to as Simultaneous one-to-one Negotiation. Recipients cannot see the orders sent to the other counterparties.
  • the system manages the total quantity for all orders in the Simultaneous Negotiation.
  • Deal Disclosure feature is enabled, counterparties who meet or exceed the terms of the original order will receive Deal Disclosure information for each accepted order.
  • Total Quantity Management is a feature of Simultaneous one-to-one Negotiation that prevents traders from over-committing securities to multiple counterparties. If a trader creates a firm order for multiple counterparties and enters a Total Max Quantity value that is less than the sum of the Max Quantity values for all counterparties, then the system will manage the total quantity for all orders in the Simultaneous Negotiation.
  • Deal Disclosure is a feature of Simultaneous one-to-one Negotiation. Because the initiating trader negotiates each order in a Simultaneous Negotiation individually, the other counterparties do not know the terms of each other's offers during negotiation. However, if the initiator chooses to enable this feature, then counterparties who meet or exceed the terms of the original order will receive Deal Disclosure information for each accepted order when negotiation has ended for all of the orders. Deal disclosure details include the quantity, some price information (such as the dividend rate, rebate rate, fee, etc.), some collateral information and some date information. Deal disclosure does not reveal which counterparties were involved in the Simultaneous Negotiation. Deal disclosure can only be enabled if the order is initiated as a soft order.
  • the autoborrow feature of the system permits participants to initiate orders that target all of their counterparties using a single messaging protocol.
  • the present system manages creation of firm orders based on bilaterally agreed schedule information and use of chaining rules.
  • the lender may respond to orders (autoborrow requests) in several ways: the lender may accept, accept partially, reject with reason, etc., the order, based on loan availability and/or their desire to lend at the requested terms.
  • An embodiment of the autoborrow process is illustrated in FIG. 5.
  • Chaining Rules can be used by the initiator of an Autoborrow transaction to specify the sequence and timing for sending Autoborrow Orders to multiple counterparties. Chaining Rules also specify which Autoborrow Schedule to use when generating an Autoborrow Order. Only the initiator of an Autoborrow transaction can set up and maintain Chaining Rules. Counterparties receiving Autoborrow Orders cannot tell whether the orders use Chaining Rules. Chaining rules also allow the initiator to specify different legal entities from their organization as the initiator of the order. This allows a single Autoborrow Record to be directed to counterparties from different legal entities within the initiator's organization. AU Autoborrow Records in the same batch preferably use or not use Chaining Rules. When using Chaining Rules, each record can use a different Chaining Rule.
  • a unique feature of the system integrates the 'Autoborrow' and 'Negotiation' processes for the convenience of the participants. This feature allows the users to specify that certain Autoborrow Orders that are rejected be re-issued as One-to-One Orders with a different set of parameters than they had in the Autoborrow batch. These orders can be automatically generated and submitted by the system based on previously saved templates thus enabling the members to negotiate the terms on those rejected orders on a one-on-one basis with their counterparties.
  • the system may also be provided contract comparison functionality. This feature will be described in more detail below, but an exemplary illustration of the contract comparison process of the system is shown in FIG. 6.
  • This feature of the invention permits counterparties to bilaterally agree on comparison criteria and file submission time.
  • Each participant then files at the pre-determined time for comparison.
  • the system runs the comparison and each participant receives a comparison report that includes any discrepancies between the contracts (e.g., broken records, matched records, unmatched records, etc.)
  • the report may be sent to each participant in XML format that can be entered into their proprietary system, if desired.
  • Each participant can view and reconcile any discrepancies, or breaks, via a browser, as well.
  • FIG. 9 illustrates an exemplary embodiment of the return/recall aspect of the invention.
  • a Loan Recall is the process through which a lender requests the return of securities from the borrower.
  • the present system facilitates this process by providing several vehicles for a lender to recall stock from a borrower and tools for both lenders and borrowers to manage their recall flow until the process is complete.
  • this system provides lenders with the ability to communicate loan recalls more efficiently via online notifications, minimizing failure to receive notification. Additionally, this functionality provides the opportunity to communicate with counterparts both on and off the present hub-based system
  • Adopting the Securities Industry Association (“SIA”) Automated Recall Management System (“ARMS”) standard will benefit all parties in a transaction according to the present invention, by providing one mechanism for Recall management for all participants. Linking Returns to Recalls can help minimize discrepancies between counterparties. Further, offering a single platform for counterparties to review contracts, recalls and returns will provide a better audit trail that traces back throughout the lifecycle of a contract.
  • SIA Securities Industry Association
  • ARMS Automated Recall Management System
  • the present invention may handle Recalls both for transactions originated within the securities trading system of the present invention and for transaction originated outside of the system.
  • Recalls can be identified by a transaction identifier ("ID") when possible.
  • ID The system will link loan returns to trades, loan recalls to trades, and returns to recalls, through the ID.
  • An ID may be assigned to each transaction the system handles, not just those for which a recall/return is requested. In most instances, IDs will be generated for loans made outside of the system during the contract comparison process. This process is critical for most effective use of Recall and Return functionality. Since Recalls result in the return of securities by the borrower, these returns are implicitly "tied" to the recall process.
  • the present system need not provide negotiation functionality for Recalls. Modifications of a Recall may be restricted to the lender, and in this case, the lender might only reduce the quantity of securities being recalled. Negotiations related to the terms of the Recall and discrepancy resolution preferably are handled outside of system. Once resolved, the lender may choose to cancel the existing Recall and send a new Recall notice with new Recall terms. If the quantity needs to be increased (e.g. due to a corporate action), the Lender should cancel the original Recall and initiate a new one.
  • Recalls can be rejected by the Borrower for a variety of reasons.
  • Loan Recalls may not have expiration periods. The Recall will be considered outstanding until either it is satisfied by a return, cancelled by the lender, or a buy-in is issued against it.
  • the system may also support a holiday calendar for all markets where participants trade.
  • AU date calculations (including the Recall Effective Date and the Recall Due Date) may take holidays into considerations, and a date can be set for the next business day following a holiday.
  • the holiday calendar data will be supplied by a leading vendor and maintained by automated processes and, where necessary, manually by the system's operators or other parties. Weekends should also be accounted for.
  • the system may also provide the ability to indicate Recalls vs. Termination Notices by allowing the initiator of a Recall to specify whether the Recall terminates the contract. When a Buy-In execution notice is sent for a partial amount against the Recall, the original Recall quantity is decremented by this partial amount, and the Recall is still valid for the balance.
  • Recalls may utilize a set of "states" which will be used throughout the lifecycle of the recall, from initiation, through actual receipt of the securities via the Return. These states are defined below, and can be used as the cornerstone upon which key functionality will be based:
  • Rejected (with reason code): A Recall notification that has been rejected by the borrower for one of the pre-defined reasons that the SIA has outlined. Recalls can be rejected for one of these reasons, although the system operator may choose to define additional parameters for the system to recognize as acceptable reasons.
  • Pending Return A Recall against which a Return(s) has been setup for the entire Recall quantity.
  • Cancelled A Recall that is cancelled by the lender. Once a Recall is cancelled, it cannot be accepted, rejected or modified.
  • contract comparison is a reconciliation process that allows two legal entities to compare loan contracts, return records, recall records and collateral records on predefined parameters on a regular basis. The process facilitates the daily mark-to-market process and month-end billing process by identifying and reconciling discrepancies early in the lifecycle of a trade.
  • users may compare contracts, identify discrepancies ("breaks") in terms, and view and reconcile the discrepancies online.
  • the online contract comparison interface is a browser-based application that provides interactive reconciliation.
  • a user preferably accesses the system using Internet Explorer version 5.5 or greater on a remote terminal, such as a personal computer (PC) with an Internet connection.
  • PC personal computer
  • contract comparison is composed of two stages. First, the system associates records in one file with corresponding records in the counterparty file ("matching”). Second, the system compares the values in specific fields across the two users' corresponding records (“comparing").
  • the contract comparison process is a daily process that runs at a pre-determined time. Each day, as defined in the Timetable, the
  • the System locates the two Users' files and validates the records. Records that pass validation are matched with the corresponding records in the other file. Corresponding records are compared and discrepancies are identified. Data is then updated in the System transaction database, so that it reflects current and accurate data for the contracts.
  • the System creates and sends four XML messages to the two users with the results of the contract comparison.
  • the four messages contain the following: Records that matched and had no discrepancies (Matched); records that matched and had discrepancies, or had no matching records in the counterparty file (Broken); records that did not pass validation (Invalid); and records that had data errors that prevented the System from updating the database (Error).
  • users may have one or multiple contract comparison processes each day.
  • FIG. 13 illustrates the contract comparison process from a file input and output perspective in one embodiment.
  • both users will send the System the data related to contracts, collateral, recalls, or returns, as specified in the contract comparison protocol.
  • the System sends the results directly to the proprietary systems of the two users, in four XML messages containing the original data submitted to the System sorted by invalid, broken, matched, and error records. Additionally, at the end of the comparison process, a notification is sent to the Activity Monitor of both users to notify them that the contract comparison process has completed.
  • Matched Records The matched records go back to the sender of the record. These are records that matched with the counterparty's records and were compared successfully.
  • the broken records are records that matched with the counterparty records but did not compare successfully and therefore generated breaks. These can also include records that did not match with any record (orphan records). Each User receives back his or her own records and the counterparty's corresponding records.
  • Invalid Records The invalid records are returned to the sender. This includes records that were an invalid data type, or were missing required fields. Each User will receive back only his own records.
  • Error Records are records that had data problems after initial validation (the System was unable to insert them into the System database, such as a record with an invalid date). With the Error Record file, each party receives back only their own records. Error records never have a new unique identifier ("EquiLend ID").
  • Users Before the match and compare process can begin, Users preferably establish three pieces of static data: a Bilateral Relationship with the counterparty's Legal Entity; a Profile, and a Timetable.
  • the Bilateral Relationship is established between the two Users' Legal Entities, and enables the two parties to transact contract comparison with one another.
  • the Profile defines the fields which will be matched and compared, while the Timetable determines the time at which the match and compare process runs.
  • a Timetable may be associated to one Profile. Both Users preferably submit their contract comparison files via XML messaging to the System prior to the start time set in the Timetable.
  • the System When the System receives XML messages containing the contract comparison records from the two Users' proprietary systems, it extracts the fixed format text messages and stores them. At the time defined in the Timetable, the System looks in the directory for the files, and validates the data contained in the files.
  • the System stops the comparison process and sends an Activity Monitor message to inform both Users.
  • the Activity Monitor message will indicate that the comparison process has aborted due to an incorrect record length but it will not identify the specific record.
  • One record with an incorrect record length can prevent a run of thousands of valid records.
  • Invalid Records Message sent to the User. Invalid records are not processed, but they do not prevent a comparison run as an incorrect record length does. Records are invalid if any numeric fields contain alphabetical data. For example, a record will be invalid if: the EquiLend ID field contains any alpha characters (e.g., "a ⁇ l”); the Contract Price field contains any alpha characters (e.g., "3.99a”).
  • the System After validation of records, the System matches records in one file with the corresponding records in the other file, so that comparison occurs between records for the same contracts. In order to compare records, those records are preferably matched by the System. As described in the following section, there are six different levels whereby the System looks for matches.
  • the System attempts to match data in the counterparty files based on six different levels of information (“steps").
  • the goal is to link a User's record(s) with her counterparty's record(s).
  • Like records need to be associated (“matched") before the information within them can be compared to determine if there are any breaks. If the System cannot match records on Step 1, it will proceed to Step 2. If records do not match on Step 2, it will proceed to Step 3, and so on, through Step 6. If records remain that cannot be matched in Step 6, then such records are considered orphans.
  • the System may match records by one of two sets of criteria.
  • files submitted with older versions of an XML protocol may match only on EquiLend ID and Record Type.
  • For Users who wish to continue matching on these two criteria they may indicate they are working with older versions of a protocol on their records and their records will match in Step 1 based on EquiLend ID and Record type. These records can be matched with other Users who use later versions of a protocol.
  • the System can also identify recalls and returns with specific identifiers. Many Users will choose to match records on EquiLend ID, Recall ID and Return ID. These Users may identify they are matching with later version protocol criteria and their records will match up when IDs match. Users matching using an older protocol version versus a newer protocol version may submit a different standard record length. The Users' records may be co- mingled and matched up to each other's records. If the records matched in Step 1 break on Quantity, the existing EquiLend IDs may be removed and placed in the Previous EquiLend ID field and the records will continue onto Step 2.
  • Step 2 Any records that either did not match in Step 1, or matched in Step 1 but broke on Quantity, may proceed to Step 2. Records may be matched in Step 2 based on four criteria:
  • Rate Fee 4. Super-stringent criteria that have been bilaterally approved by both Users as compare fields in the profile. The purpose of this is to increase the number of matches by matching records in a more logical order (i.e., matching up records with like rates, dividend rates, etc.): Rate Fee
  • Step 3 Any records that did not match in Step 2 may proceed to Step 3. Records may be matched in Step 3 based on four criteria:
  • Rate Fee 4. Super-stringent criteria that have been bilaterally approved by both Users as compare fields in the profile. The purpose of this is to increase the number of matches by matching records in a more logical order (i.e., matching up records with like rates, dividend rates, etc.). Rate Fee
  • Step 4 Any records that did not match in Step 3 may proceed to Step 4. Records may be matched in Step 4 based on three criteria:
  • Step 5 Any records that did not match in Step 4 may proceed to Step 5. Records may be matched in Step 5 based on three criteria: 1. Aggregated unit quantity or the quantity on a combination of records the System logically grouped together based on the following match criteria.
  • Step 6 Any records that did not match in Step 5 will proceed to Step 6. Records are matched in Step 6 based on the least stringent criteria, as follows: Your Legal Entity
  • the Comparison process may begin. It may evaluate the data in the fields designated as "compare" fields in the bilaterally agreed upon comparison profile associated with the Timetable ID. If the data matches, it may be considered compared. If the data is different between counterparties, it may generate a break to be displayed on the Contract Compare front-end screens.
  • the file submissions for a given Timetable ID may preferably use the same match and Comparison parameters.
  • the System may assign IDs
  • the System uses the following logic: If a record with no ID matches a record that also has no ID, the System assigns a new ID (EquiLend, Recall, or Return) to those records; If a record without an ID matches a record that has an ID, the System assigns the ID from the record that has one to the other record; If a record with an ID matches a record with a different ID, the System assigns a new ID, which replaces the IDs in both records.
  • a new ID EquiLend, Recall, or Return
  • Steps 2 through 5 of the matching process when there are records with EquiLend, Recall, or Return IDs that have no corresponding record(s) in the counterparty's file, the System removes the ID and sends the record on to the next matching step.
  • the System sends both the current EquiLend ID and old EquiLend ID that was submitted on the record to the User's proprietary systems in the results files.
  • the System compares the values of each field of the matched records as defined in the Contract Comparison Profile. In cases where multiple records match, the System may calculate the totals for aggregating fields and compare them. Any values that do not agree with the values in the counterparty's corresponding records are flagged as breaks. Note that orphan records (or records that could not be matched with corresponding record(s) in the other User's file) may not be compared. Such records are identified as "orphan" records in the online reconciliation.
  • the System may flag a break if: one User's field's value is uppercase, the other User's is lowercase; the value for a field is different between Users, such as if the Rate field is 4.0 for one User and 2.0 for the other, provided the difference is larger than a pre-agreed tolerance.
  • the System calculates break aging, which means it calculates the number of consecutive calendar days that a field within a set of matched records "broke.” AU breaks will be aged individually at the break level. Specifically, the System: Determines whether the break occurred during the previous Contract Comparison run and whether the same field is still breaking; Marks the breaking field and starts the break aging for this field on this day if the break did not occur during the previous Contract Comparison run; Updates the break aging by adding an additional day if the break occurred during the previous Contract Comparison run.
  • break aging which means it calculates the number of consecutive calendar days that a field within a set of matched records "broke.” AU breaks will be aged individually at the break level. Specifically, the System: Determines whether the break occurred during the previous Contract Comparison run and whether the same field is still breaking; Marks the breaking field and starts the break aging for this field on this day if the break did not occur during the previous Contract Comparison run; Updates the break aging by adding an additional day if the break occurred during the previous Contract Comparison run.
  • the System will link comments, actions, and assignments made within previous runs to the current run. Additionally, comments related to orphan records in one run will be linked to the same orphan record in subsequent runs, until the orphan record is successfully matched.
  • a User's proprietary system e.g., EquiLend ID or Internal Reference ID
  • Contract Comparison allows actions and comments to be added to the record, assignment of breaks, internal indicators to identify records being worked on, and the generation of reports.
  • Contract Comparison may be a function in the System, with its own functional homepage. After a successful login, a User may select Contract Comparison from an Operations menu.
  • Each entitlement may have the following capabilities within the function.
  • AU permissions may be administered in the User Configuration screen, which preferably can only be accessed by Legal Entity Administrators.
  • Timetables screens (Create New Timetable, View Timetable,
  • the Overview tab may serve as the "landing page" within the Contract
  • Comparison function may be the first page to be displayed. You can navigate to other Contract Comparison screens by selecting the appropriate tab.
  • the information on the Overview tab may be updated during the course of the day as you and your counterparty reconcile breaks within the Contract Comparison function, hi one embodiment, clicking on a "Refresh” button will reload the Overview tab with the most current data. This is particularly useful if both you and your counterparty are resolving your breaks and saving your actions. If so, the count of Reconciled breaks will increase and the count of Unreconciled breaks will decrease. Additionally, the count in the "Selected Breaks" and "Break Type" columns that you have filtered into your Overview tab will decrease according to the breaks that have been reconciled (i.e., one counterparty has saved "Match Me” action and the second counterparty has saved "Match Ctpy” action).
  • the break counts that appear on the Overview screen may represent all breaks based on all the data submitted to the System. For instance, if you researched a break and marked it as "reconciled" within Contract Comparison yesterday, but forgot to update your proprietary system, the next day, the records will still break in Contract Comparison, and it will be included in the break count in the Overview tab.
  • Users may also be able to export the data on the Overview tab by clicking on a "Save to XLS" button. In one embodiment, this action may download the data as it appears on the Overview tab into a spreadsheet file, such as Microsoft Excel. This can provide a useful audit trail of the breaks reconciled on any given day if it is exported at the beginning and end of each workday.
  • the Overview tab contains a collapsible filter panel that enables you to filter and control the data that you see in the rest of the page. This allows you to quickly change the data and display only the information of interest to you.
  • the Your Legal Entity and Ctpy Legal Entity filters will control the runs that appear in the Overview tab since each run is based on a Your Legal Entity and Ctpy Legal Entity pair.
  • the Break Type Inclusion filter may control the number of columns that appear in the Overview tab. This allows you to customize the page with only the break types that are relevant to your daily work. In one embodiment, all the break types are organized so that the more commonly occurring breaks appear toward the left, and the less frequent ones towards the right.
  • the selected break type columns will control the number that is calculated in the Selected Breaks column. In one embodiment, the Selected Breaks column appears to the right of each break type you selected, and is the sum of all the breaks in your break type columns. For example, if you selected the Rate and Fee break types, which have three and four breaks, respectively, the Selected Breaks column will display seven (7).
  • the remainder of the filter drop downs will enable you to control the counts within the break types you have selected. For example, you may only be interested in the Rate breaks that have been assigned to you. If this is the case, you can select your User ID from the Assigned filter and select "Rate" in the Break Type Inclusion filter. If there were three Rate breaks, two assigned to you and one assigned to a colleague, the Overview screen would only show two Rate breaks.
  • the Overview tab will automatically apply your default filters.
  • to set a default filter on the Overview tab Select your filters and Click the Set Filter/Sort Defaults button.
  • the Reconciliation page is the core of the Contract Comparison function. This page may be accessed via the Overview tab and may be where you will reconcile your breaks with your counterparty for a particular Contract Comparison run.
  • the Reconciliation page can provide robust filtering, sorting and drill-down features that support the investigation and reconciliation of breaks. For Users with Reconcile Contract Compare and Transact Contract Compare permissions, the page may also enable Users to take actions, assign breaks and manage comments on individual breaks.
  • the Reconciliation page displays records with breaks. For each set of matched records, there is a side-by-side comparison of every field that "broke" during the comparison process. As you research and reconcile your breaks, you can update the Action field for each break in order to inform your Counterparty on how you intend to update data in your organization's proprietary system.
  • the Reconciliation page can be broken down into several components.
  • the page may be organized as follows:
  • the filter panel on the Reconciliation page controls which records are displayed in the main panel.
  • the Reconciliation page will inherit the filters that were set on the Overview tab. For example, if you had selected Rate, Dividend Rate, and Fee breaks from the Overview tab that were assigned to you, and you had clicked the link in the "Selected Breaks" column, the Reconciliation page will only display those three break types where you were assigned to the break.
  • the filter panel When the Reconciliation page initially loads, the filter panel may be collapsed in order to conserve space on the page. Once in the Reconciliation page, you are able to change the filters that were inherited from the Overview tab. In one embodiment, to select and apply filters on the Reconciliation page: Select your filters and click the Apply button.
  • the filter panel there may be three dropdown boxes where you can set the primary, secondary and tertiary sort orders for the records in the main panel. This functionality may sort across all the records returned by your filter criteria.
  • to select and apply priority sorts on the Reconciliation page Select your primary, secondary and tertiary sort orders and click a Sort button.
  • the Security panel provides a quick way to control which securities are displayed and filtered into the Main panel of the Reconciliation page. It may contain a table of records rolled-up by
  • a user selects the checkboxes next to each security that the user wants to display in the Main panel and clicks an Apply button.
  • the Break column in the Security panel displays the number of breaks for each of the securities based on the filter criteria that have been set. For example, if IBM had a total of three breaks - Rate, Billing Value, Billing Currency, and you filtered on Billing Value and Billing Currency breaks, you would see the number two in the Break column next to IBM.
  • the initial sort order for this panel is by Security Description in ascending alphabetical order.
  • the Main panel in the Reconciliation page contains information related to the breaks identified during the Contract Comparison match and comparison process. For each set of matched and broken records, up to four levels of information can be displayed. Record Row: Provides information related to the overall matched records
  • Break Row Identifies the breaks on the matched records
  • Lot Information If there are underlying lots that correspond to a set of matched records, the lot details can be displayed. A "See Details" link in the Int Ref
  • Subtotal Tables If there are multiple lots aggregated with different Rates, Fees, and/or Dividend Rates as a result of the Contract Comparison matching steps, separate tables can appear for each of those fields listing the quantity subtotals for each of the different values. The subtotal tables may only appear if you have filtered on those three break types.
  • to view comments related to a particular break Select the Break row that corresponds to the break you are interested in and look at the Comments panel; the latest public and/or private comment related to that particular break appears.
  • a Button panel at the bottom left of the Reconciliation page may provide several buttons that you will use as you work on and complete your reconciliation.
  • Save and Continue button clicking on the Save and Continue button saves all the information that you have made on your current screen (e.g., actions and assignments). This will allow you to retain the information that you have already entered as a result of your reconciliation and research if you need to shift your attention to another task at hand.
  • Reconciliation Complete button clicking the Reconciliation Complete button will update the run's status to Complete.
  • Download XLS button Clicking the Download XLS button will launch a system dialog box that will prompt you to select where you would like to save a Microsoft Excel file that contains all the underlying data that you have filtered into the Reconciliation page. Downloading this file is useful when working on reconciliation in your proprietary system.
  • Contract Break Details Page Contract Break Details is a read-only page that displays information related to all breaks on a particular set of matched records. This page does not take into account the filters that you have set on the Reconciliation page.
  • the layout of the Contract Break Details page may be similar to the layout of the Main Panel of the Reconciliation page.
  • the first row provides general identifying and summary information. Directly indented below is a row for each break. If there are breaks on Rate, Fee or Dividend Rate, a subtotal table may appear. Each value may appear as its own row in a Subtotal table. For instance, if you had submitted records with Rates of 3.5 and 3.6 that matched with records from your counterparty with Rates of 3.6 and 3.7, the Subtotal table may consist of three rows, each with one of the following Rates: 3.5, 3.6 and 3.7. Lot information can be displayed if there are underlying lots that correspond to a set of matched records.
  • the Contract Pair Details page is a read-only page that displays all the information that both you and your counterparty submitted. There can be one or multiple fields from either side that caused the break. All fields that are breaking are displayed in red and the word Break will be displayed after the field name in the left-most column.
  • the Criteria column displays the name of the field, while the My Legal Entity column displays the data values you submitted, and the Ctpy Legal Entity column displays the data values that your Counterparty submitted.
  • Rebate Receivable (Accrued Rebate Receivable) Amount Rebate Payable (Accrued Rebate Payable) Amount Fee Receivable Amount Fee Payable Amount
  • Reconciling Breaks when viewing the Reconciliation page for a particular run, you will be able to control the data displayed on the screen using the filters and sorts, expand the records on the page to view detailed subtotal and lot information, assign breaks to colleagues, and research and resolve your breaks. You will save Actions to indicate to your Counterparty how you plan to resolve a specific broken field.
  • Match Ctpy (I match you) — indicates that you plan to change the data in your proprietary system to match your counterparty's values.
  • Match Me (You match me) - indicates that you expect your counterparty to change the data in his/her proprietary system to match your values. Do Neither - indicates that you expect neither you nor your counterparty to change data in your proprietary systems.
  • the yellow highlight will disappear. If your counterparty has not re-saved their actions, they will still be able to see their Action highlighted in yellow. Once both Counterparties have re-saved their actions, all the yellow highlights will disappear and the Contract Comparison function will consider the break Reconciled. At this point, you will be able to retrieve the record if you set your Reconciliation State filter to Reconciled. Additionally, the Overview tab will reflect the break as Reconciled, and you will see the break count decrement accordingly.
  • the Matched Records page is accessible via the Overview tab, and is may only be available for the most current run of each Timetable. This page displays all the records that matched and compared (i.e., had no breaks) in the selected Contract Comparison run.
  • the screen may be organized to mimic the Reconciliation page with a Filter and Prioritized Sort panel at the top, a Security panel on the left, and a Main panel on the right. This page is for informational purposes only.
  • all the controls that relate to breaks may be removed. For example, there are no break-related filters (e.g., My Action, Ctpy Action, Reconciled State); you are not able to view or add comments; there are no Break rows or Subtotal tables in the Main panel; there is no break-related filters (e.g., My Action, Ctpy Action, Reconciled State); you are not able to view or add comments; there are no Break rows or Subtotal tables in the Main panel; there is no break-related filters (e.g., My Action, Ctpy Action, Reconciled State); you are not able to view or add comments; there are no Break rows or Subtotal tables in the Main panel; there is no
  • the Run Results tab allows you to view summary information related to the previous fifty-nine days of Contract Comparison runs. It also enables you to access the detailed information for each of these earlier runs by clicking on the View link within the Action column for a particular run. You may wish to review the information in the Run Results pages if you need to investigate actions that you had taken during a previous run. This applies to those Users that are not maintaining either the EquiLend ID or a unique and consistent Internal Reference
  • all Contract Comparison runs that appear in the Run Results pages have a status of frozen. This status indicates that a subsequent run has been processed for the same Timetable. As soon as the System processes a new run for a given Timetable, it freezes the prior run that was processed for that Timetable to prevent Users from changing data within an old run. Therefore, the information within the Run Results pages is informational only, and you will not be able to take any actions on any of your previous runs.
  • the Run Results page is organized to mimic the Reconciliation page with a Filter and Prioritized Sort panel at the top, a Security panel on the left, and a Main panel on the right, and a Comments panel at the bottom.
  • This page may be for informational purposes only. For example: you are able to view comments, but are unable to add any new comments; you are unable to assign a break; you are unable to take an Action on a break; the page-level actions and assignments functionality is not available and the Reconciliation Complete and Save and Continue buttons are not displayed on the page.
  • Timetables and Profiles create the foundation of information underlying all Contract Comparisons. Profiles and Timetables are preferably defined before the Contract Comparison process can run.
  • Contract Comparison Profiles define four things: The optional fields used to match records in Step 2, 3, 4 and 5 matching; The fields compared across matched records;
  • Profiles are preferably defined before a Contract Comparison process can run.
  • One Profile is preferably associated to one Timetable.
  • Certain fields on a Profile are not configurable, which means they are always used as matching criteria.
  • Configurable fields on the Profile can be marked as: Optional criteria for matching (M/C) Criteria for comparison only (C Only) Fields that will not be used for matching or comparison (Neither)
  • Contract Comparison Profiles are created and maintained online. Before Profiles can be created, there preferably is an active bilateral relationship defined in the System for the two Counterparties. Either Counterparty can create or maintain the profile(s), but the profile is preferably bilaterally approved before it can be used by the System for Contract Comparison. In order to implement better controls around the Profiles, preferably only Users with the appropriate permissions will be able to view and/or transact the Contract Comparison Profiles pages.
  • the list of Profiles preferably displays all Active Profile records. If there is not an Active record for a given Profile, the most recent profile (based on the last Update Date/Time) may display.
  • Tolerances can be applied during the comparison process when reconciling breaks. Tolerances may allow values between you and your Counterparty to be considered successfully compared (i.e., not breaking) if the difference between you and your Counterparty's data fall within the defined tolerance. Such rules can be helpful in accounting for differences between you and your Counterparty's proprietary systems (e.g., comparing values when each system carries different decimal lengths), as well as discounting minor differences between your values.
  • Users can define a tolerance as either a value or a percent. Users can also define more than one tolerance for a field, with each tolerance applying to a specific range of a field. Specifying ranges can assist with placing stricter controls around tolerances. For example, a tolerance of 1% for Billing Values between $0 and $10,000,000 may be acceptable, but for Billing Values above $10,000,000 a tolerance of .5% would apply. In one embodiment, note that if a range has been applied to a tolerance, the tolerance may only be applied if the values submitted by both Counterparties fall within the range.
  • Exception rules can be applied during the comparison process when reconciling breaks.
  • the following six rules can be applied prior to the match and comparison process. These business rules modify the Contract Comparison file sent from you and your Counterparty's proprietary systems. Ignore Pending Returns
  • More customized exception rules can be created by you and/or your Counterparty to apply to any compare field that you have specified in your Profile. These customized exception rules can be created to ignore the comparison of a particular field or to consider two different values equivalent.
  • the System may support two conditions that can trigger these types of exception rules, however, specifying conditions are optional and not needed as you build your rules:
  • Profiles define the business rules that are applied during the matching and comparison process. The two counterparties agree upon the fields that will be used as matching criteria, the fields that will be used only as comparison criteria and the tolerances and exception rules that will be applied during the comparison process.
  • Profiles with a status of Active, Inactive or Declined maybe edited. Once a Counterparty edits a Profile, the system sends a notification to the other Counterparty that a modified Profile is pending their approval to make it Active.
  • Profiles with a status of Inactive can be made active. Once a User reactivates a Profile, it is preferably approved by the Counterparty before it becomes Active. A notification is sent to the Counterparty letting them know the Profile is pending their approval to make Active.
  • Timetables are a bilaterally agreed upon time by which Contract Comparison files are submitted by Users, and the match and compare process is started.
  • available start times also known as cut-off times
  • start times are 3:00 GMT, 6:00 GMT, 9:00 GMT, 10:30 GMT,12:00 GMT, 17:00 GMT, 20:00 GMT or 23 :30 GMT.
  • Timetable Users preferably choose one of these times for the comparison to occur each day.
  • the Timetable start time is preferably in GMT, regardless of the User's personal system preferences.
  • Contract Comparisons may run based on the start time agreed to in the Timetable. If the two files have not been submitted to the System by one or both of the Users by the designated cut-off time, the System will await the receipt of the file or files for one hour past the start time. If one hour passes without both files being sent to EquiLend, the System will abort the comparison.
  • Timetable Before a Timetable can be created, there preferably is an active bilateral relationship defined in the System for the two Users. Additionally, Users preferably determine which records they will submit for a given Timetable (i.e., all U.S. equities are submitted in a given Contract Comparison run). When creating a Timetable, the File Description field may be used to note which records are included in the Contract Comparison run. Furthermore, before creating a Timetable, Counterparties need an active Contract Comparison Profile, which defines the matching and comparison criteria for all Contract Comparisons based on the Timetable. When creating the Timetable, the initiating User preferably associates the Profile to it. If the Profile associated with the Timetable becomes Inactive after the Timetable is created, the Contract Comparison run may abort and an activity monitor notification will be sent to both Users.
  • a Timetable i.e., all U.S. equities are submitted in a given Contract Comparison run.
  • the File Description field may be used to note which records are included in the Contract Comparison run.
  • Counterparties before creating a Timetable
  • Timetables are created and maintained online through the System browser.
  • a Timetable has a different status depending on where it is in the creation/maintenance process.
  • a Timetable can be created or maintained by either User, but because it is a bilateral agreement between two Users, it is preferably approved by the Counterparty to become Active and usable by the System.
  • both Users approve a Timetable, its status changes to Active, and it immediately becomes effective in the System. This means that at the next Start Time defined in the Timetable, the System expects to have received comparison files from both Users.
  • the System notifies the Counterparty that a Timetable is pending their approval to make active.
  • Timetables with a status of Active or Declined may be edited. Once a User edits a Timetable, the System sends a notification to the Counterparty that a modified
  • Timetable is pending their approval to make Active. Timetables with a status of Pend Your Appr to Make Active or Pend Your Appr to Make Inactive may be approved. Once you approve a Timetable that is Pend Your Appr to Make Active, it becomes immediately Active and in-us ⁇ by the System, which means the next time a Contract Comparison process runs, it will use this version of the Timetable. Notifications may not be sent when Timetables are approved.
  • Timetables with a status of Pend Your Appr to Make Active or Pend Your Appr to Make Inactive can be declined. Once you decline a Timetable, a notification may be sent to inform the other Counterparty that the proposed Timetable was declined.
  • Timetables with a status of Active can be made Inactive. Once a Counterparty makes a Timetable Inactive, it is preferably approved by the other Counterparty before it becomes Inactive. A notification may be sent to the other Counterparty to let them know the Timetable is pending their approval to make Inactive.
  • Timetables with a status of Inactive can be made Active. Once a Counterparty reactivates a Timetable, it is preferably approved by the other Counterparty before it becomes Active. A notification may be sent to inform the other Counterparty that the
  • Timetable is pending their approval to make Active.
  • Linked Securities In one embodiment, the purpose of the Linked Securities is to reduce the number of orphan records resulting from corporate actions processing. Corporate actions processing often necessitate the creation of proxy asset IDs, which differ between the borrower and the lender. During the match and compare process, the two proxy asset IDs mismatch and lead to orphan records.
  • Linked Securities may allow a User to link a proxy asset ID representing the corporate action to the underlying security that exists within the System's security master database. When a proxy asset ID is created, it may be associated with a User but can be re-used by any other User in that Legal Entity. In this way, Users do not need to create proxy asset ID links for every Counterparty. Proxy asset IDs do not need to be bilaterally agreed upon.
  • the Contract Comparison function may be able to match records if both Users submit proxy asset IDs. It may also be able to match records if one User is submitting a proxy asset ID and the Counterparty is still submitting the underlying security.
  • this function is preferably limited to Users with the appropriate permissions to view and/or transact the Linked Securities.
  • a standard header may be used on all messages.
  • the header is considered to be the envelope of the message, since it contains the entire message addressing information.
  • addressing is preferably done in a standard way and will be validated to adhere to the following rules:
  • a corporate identifier may be used to populate the sender section.
  • the Platform will preferably not be associated with a legal entity identifier, sub account identifier or trader id.
  • the User System may populate the relevant sender information with its own information.
  • the corporate identifier and a trader id are preferable.
  • the trader identifier element can be populated with either a trader or User id.
  • Trader ids are preferably used for order related transactions.
  • User ids or trader ids can be used for operational and administrative transactions.
  • the legal entity and sub account information can be added, if it is relevant.
  • the counterparty information will used to populate the recipients section. There are some exceptions to this rule.
  • the Platform When the Platform receives a message with multiple counterparties, it may forward the message to the counterparties, and it may maintain the original sender information.
  • the header may also contain the security token.
  • the token is preferable on all
  • Contract Comparison messages Messages that do not contain a valid security token will preferably be rejected.
  • the token for the User System may be in the header.
  • the Platform security token should preferably be in the header.
  • the header itself will preferably not modify or create any System identifiers.
  • the confirmRequest tag should preferably be inserted in the header. Some messages may have mandatory confirmations, in which case, the confirmRequest tag may be ignored regardless of setting.
  • Error Handling An error in the header may result in an error payload notification message (an "Error Payload message") from the Platform.
  • the error payload message may contain a portion of the original message, depending on the message type. Additionally, the error payload message may contain all of the errors that were found within the message.
  • the Comparison message may be used to submit and receive records for the Contract Comparison process. Users preferably send contract compare records using the contract compare upload message subtype, and should expect to receive results from the Platform in messages utilizing the other subtypes.
  • the Contract Compare message preferably contains a fixed format file structure, which differs depending on what activity (and corresponding message subtype) is being performed.
  • Records in error may be sent in this format. These are defined as records that produced an error when the Platform attempted to insert the record into the System database because it did not have the required information to create a record (certain fields are required to create a record in the Platform as defined in the message structure table). Note that such records may also appear on either the Matched or Breaks file as well since they would have gone through the matching and comparison process (unlike Invalid records) prior to producing the database error.
  • the Platform may use the Timetable ID sent in the upload message to determine which counterparty files should be compared and to pull the appropriate comparison profile. Users may receive the Timetable ID on the download files so they know which comparison run the file applies to.
  • the data within the 'file content' section may be validated for various conditions. Depending on the validations that fail, a record may be rejected to the
  • Invalid File or to the Error File do not go through the comparison process; Error records do go through the comparison process; they do not get updated or inserted into the System database.
  • the Invalid File contains records that: failed on data type, length or precision requirements; were missing required fields - secld, secIdType and borrowLoanlndicator; secld had an invalid format as defined by the secIdType; secIdType wasn't a valid value as defined in the master attributes list; proxy asset ID submitted did not exist in the System database.
  • the Error File contains records that: were missing required fields for insert to the database - recordType and orderState; contained an invalid EquiLendld; date fields compared correctly, but had invalid formats; stringent criteria fields matched correctly, but had invalid values (borrowLoanlndicator, rateType, feeType, collType, collateral currency, callablelndicator, recordType).
  • the text within the 'file content' element of the XML file is preferably enclosed in CDATA tags to prevent the parser from trying to validate the contents.
  • an error payload message may be sent to the User System in response.
  • This error payload message may contain one or more error codes and error descriptions, describing why the message was invalid.
  • the first 16K bytes of the original message will be stored in the msgdata element of the error payload message as CDATA. Due to the potential large size of this message type, this buffer size may not capture the whole message and also may not capture the portions of the message in error. However, having the header and a portion of the body should enable the recipient to identify the message.
  • the Platform and the User Systems can use the error payload message as a response to an invalid message.
  • a message can be considered invalid for different reasons.
  • the message can contain poorly formed XML or the content of the message itself can be invalid.
  • the first 16 kilobytes of the message maybe returned as CDATA in the error payload body. With smaller messages, this will most likely include the whole message. With large messages, such as availability post and compare, this will at least include the header and some of the body. This will help the recipient identify where the error is. With the header information, the recipient will be able to tie the errors back to the original message.
  • the error code and description may explain that the message is malformed.
  • the Compare message may have three major functional uses - Contract Compare, Billing Compare and Mark to Market processing. All three use a CDATA element within the body of the message to store the comparison file content. Since XML restricts the nesting of CDATA tags, we cannot directly nest the Compare message within the Error Payload CDATA element. To get around this problem, the Platform may Base-64 encode the complete Compare message, prior to inserting it in an Error Payload message. This processing may only be used for Compare messages. Likewise, if a User is returning an Error Payload message to the Platform for an errant Compare message, they should do the same.
  • the Platform may deliver Error Payload messages to Users on their Error
  • MQSeries provides support for message segmentation through the use of message groups.
  • Group This is the highest level in the hierarchy and is identified by a Groupld. It consists of one or more messages that contain the same Groupld.
  • the term "message” is used here to denote one item on a queue, such as would be returned by a single MQGET that does not specify MQGMO_COMPLETE_MSG.
  • Logical messages within a group may be identified by the Groupld and MsgSeqNumber fields. Logical messages within a group can be used to: Ensure ordering and allow applications to group together similar messages (for example, those that must all be processed by the same server instance).
  • Each message is logically a separate message, and the Groupld and MsgSeqNumber fields in the MQMD need bear any relationship to other messages in the group.
  • a logical message within a group may consist of more than one physical message.
  • Segments are used to facilitate the handling of large messages.
  • a combination of Groupld, MsgSeqNumber, and Offset fields may be used to uniquely identify a segment of a message.
  • the Offset field starts at zero for the first segment within a message.
  • Each segment consists of one physical message.
  • the Platform's Queue Manager and all its local queues may have the MAXMSGL (Maximum Message Length) parameter set to 250 KB. This forces the MAXMSGL (Maximum Message Length) parameter set to 250 KB. This forces the MAXMSGL (Maximum Message Length) parameter set to 250 KB. This forces the MAXMSGL (Maximum Message Length) parameter set to 250 KB. This forces the MAXMSGL (Maximum Message Length) parameter set to 250 KB. This forces the MAXMSGL (Maximum Message Length) parameter set to 250 KB. This forces the MAXMSGL (Maximum Message Length) parameter set to 250 KB. This forces the MAXMSGL (Maximum Message Length) parameter set to 250 KB. This forces the MAXMSGL (Maximum Message Length) parameter set to 250 KB. This forces the MAXMSGL (Maximum Message Length) parameter set to 250 KB.
  • a User Application can either: Send a message "as is” or have the application 'break' the large message in pieces of 250 KB (or less) by using a combination of application segmentation and MQ API to insure proper ordering and transmission of the segments.
  • the Contract Compare message type be sent to the Platform using application segmentation, regardless of the messages size.
  • the message still preferably needs to be segmented resulting in a group having a single segment.
  • the Platform may have four inbound message queues defined for each User: Queue 1, Queue 2, Queue 3 and the Reject Queue (for the messages rejected by the Users).
  • the Platform may have two transmission queues that may be mapped to four message queues on each User's side.
  • XmitQl sends messages to the User's application Queuel and
  • XmitQ2 sends messages to the User's application queues: Queue2, Queue3 and the Reject Queue. The messages are mapped to these queues at the message type and subtype level.
  • Each of the XML message types may be defined with its own corresponding
  • DTD document To be consistent across the messages, common elements and entities may be defined in the following files, EQLJBlements.DTD and EQLJBntities, respectively. These two files may be included in each of the message DTD files so that these elements and entities can be used without being defined again. Since all of the messages may share a common, standard header, the header was also defined in its own DTD, and is included in each of the individual message DTDs.
  • the Header may be defined in the EQL_Header.DTD file.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne des procédés et des systèmes destinés à des transactions de prêt de titres. Le système selon l'invention met en place une plate-forme destinée à des transactions financières électroniques, telles que l'emprunt et le prêt de titres, et facilite la capacité des emprunteurs et des prêteurs à situer des contreparties appropriées et à engager des négociations directes dans une transaction de prêt de titres. L'invention concerne également des procédés permettant à des utilisateurs de comparer des contrats de prêt pour des avoirs et des titres à revenu fixe, d'identifier des différences de termes et de les visualiser et d'effectuer un rapprochement en ligne. Une comparaison de contrats est un procédé de rapprochement permettant à deux entités légales de comparer des contrats de prêts, des dossiers de retour, des dossiers de rappel et des dossiers collatéraux sur des paramètres prédéfinis régulièrement. Le procédé permet de faciliter le procédé quotidien de l'évaluation à la valeur du marché et le procédé de facturation de fin de mois par identification et rapprochement des différences au début du cycle de vie d'une transaction.
PCT/US2006/035349 2005-09-12 2006-09-12 Procede et systeme de comparaison de contrats dans des transactions de pret de titres WO2007033095A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US71557405P 2005-09-12 2005-09-12
US60/715,574 2005-09-12

Publications (2)

Publication Number Publication Date
WO2007033095A2 true WO2007033095A2 (fr) 2007-03-22
WO2007033095A3 WO2007033095A3 (fr) 2009-05-28

Family

ID=37865493

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2006/035349 WO2007033095A2 (fr) 2005-09-12 2006-09-12 Procede et systeme de comparaison de contrats dans des transactions de pret de titres

Country Status (1)

Country Link
WO (1) WO2007033095A2 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020180783A1 (fr) * 2019-03-01 2020-09-10 Mehdi Zhiri Accords de services financiers à plusieurs parties
WO2021119484A1 (fr) * 2019-12-11 2021-06-17 Trumid Technologies, Llc Systèmes et procédés de mise en correspondance d'échanges électroniques automatisés prenant en charge un cadre de négociation
US11610271B1 (en) * 2020-12-23 2023-03-21 Xero Limited Transaction data processing systems and methods

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030009409A1 (en) * 2001-06-01 2003-01-09 Glenn Horner Systems and Methods for providing risk/return measures for securities lending programs

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030009409A1 (en) * 2001-06-01 2003-01-09 Glenn Horner Systems and Methods for providing risk/return measures for securities lending programs

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020180783A1 (fr) * 2019-03-01 2020-09-10 Mehdi Zhiri Accords de services financiers à plusieurs parties
WO2021119484A1 (fr) * 2019-12-11 2021-06-17 Trumid Technologies, Llc Systèmes et procédés de mise en correspondance d'échanges électroniques automatisés prenant en charge un cadre de négociation
US11610271B1 (en) * 2020-12-23 2023-03-21 Xero Limited Transaction data processing systems and methods

Also Published As

Publication number Publication date
WO2007033095A3 (fr) 2009-05-28

Similar Documents

Publication Publication Date Title
US8185466B2 (en) System and method for securities borrowing and lending
US7433842B2 (en) Method and system for effecting straight-through-processing of trades of various financial instruments
US7734518B2 (en) Method and system for effecting straight-through-processing of trades of various financial instruments
US7729972B2 (en) Methodologies and systems for trade execution and recordkeeping in a fund of hedge funds environment
US8005743B2 (en) Electronic trading confirmation system
US7881992B1 (en) Methods and systems for processing and managing corporate action information
US8160950B2 (en) Method and apparatus for trading assets
US20020007335A1 (en) Method and system for a network-based securities marketplace
US7756777B2 (en) Method and system for administering prime brokerage
US20020026401A1 (en) System and method for facilitating electronic bidding between buyers and sellers in financial industries
US7756778B1 (en) System and method for tracking and facilitating analysis of variance and recourse transactions
US20080097898A1 (en) Transaction management system
EP2068278A2 (fr) Stockage de données et processeur pour stocker et traiter des données associées aux contrats dérivés et marques associées aux contrats dérivés
US20120185373A1 (en) Registry of u3 identifiers
US20080319919A1 (en) Electronic inquiry lists for financial products
WO2009114511A2 (fr) Système et procédé destinés à des échanges de titres spécifiés
US20190066204A1 (en) System for issuing and managing exchange traded products as financial instruments and associated method
US20140114838A1 (en) Finance utility system and method
US20190066215A1 (en) System for controlling data and issuing client reports on exchange traded products and associated method
WO2007033095A2 (fr) Procede et systeme de comparaison de contrats dans des transactions de pret de titres
GB2403311A (en) System for securities borrowing and lending
EP1733354A2 (fr) Procede et systeme de realisation d'un traitement continu de negociations de divers instruments financiers
US20070255641A1 (en) Computer interface for trading bonds
EP2150935A1 (fr) Procédé et système d'administration de courtage

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase in:

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06814463

Country of ref document: EP

Kind code of ref document: A2