US20030023539A1 - Systems and methods for facilitating agreement definition via an agreement modeling system - Google Patents
Systems and methods for facilitating agreement definition via an agreement modeling system Download PDFInfo
- Publication number
- US20030023539A1 US20030023539A1 US09/916,881 US91688101A US2003023539A1 US 20030023539 A1 US20030023539 A1 US 20030023539A1 US 91688101 A US91688101 A US 91688101A US 2003023539 A1 US2003023539 A1 US 2003023539A1
- Authority
- US
- United States
- Prior art keywords
- agreement
- term
- party
- information
- transaction
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
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/02—Banking, e.g. interest calculation or account maintenance
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/10—Text processing
- G06F40/166—Editing, e.g. inserting or deleting
-
- 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
-
- 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/03—Credit; Loans; Processing thereof
-
- 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
-
- 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
- G06Q50/00—Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
- G06Q50/10—Services
- G06Q50/18—Legal services; Handling legal documents
- G06Q50/188—Electronic negotiation
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99933—Query processing, i.e. searching
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99933—Query processing, i.e. searching
- Y10S707/99934—Query formulation, input preparation, or translation
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99933—Query processing, i.e. searching
- Y10S707/99935—Query augmenting and refining, e.g. inexact access
Definitions
- the present invention relates to agreements between parties.
- the present invention relates to systems and methods for facilitating definition of an agreement between a party and a counter-party via an agreement modeling system.
- an agreement between a party and a counter-party is manually defined by the parties. That is, one or both of the parties manually select a type of document that appropriately reflects the substance of the agreement (e.g., a particular type of contract) and/or agreement terms to be included in the document (e.g., contract clauses).
- a type of document that appropriately reflects the substance of the agreement (e.g., a particular type of contract) and/or agreement terms to be included in the document (e.g., contract clauses).
- the manual definition of an agreement can be a time consuming and error-prone process, especially when a large number of potential document types and/or potential agreement terms can be associated with the agreement.
- particular parties or localities may require different document types and/or agreement terms.
- the parties must carefully consider the substance of the agreement in order to select the appropriate document type and/or agreement terms.
- the present invention introduces systems and methods for facilitating definition of an agreement between a party and a counter-party via an agreement modeling system.
- an agreement type is determined based on (i) a plurality of product types associated with a transaction agreement and (ii) a covered products matrix. An agreement term between a party and a counter-party is then determined in accordance with the agreement type.
- an agreement type is determined along with an agreement term.
- An indication is then generated based on an evaluation of the agreement type and the agreement term.
- a contract type is determined.
- a contract term between a party and a counter-party is then determined in accordance with the contract type.
- an agreement term is determined along with a term date associated with the agreement term.
- An indication of the agreement term is then stored in association with an indication of the term date, wherein an applicability of the agreement term can be automatically determined based at least in part on the term date.
- Another embodiment is directed to facilitating definition of an agreement between a party (including a first party entity and a second party entity) and a counter-party.
- a first agreement term is determined via the first party entity.
- a second agreement term is then determined via the second party based at least in part on the first agreement term.
- an agreement term is determined.
- a value associated with the agreement term is then stored along with an indication of a right associated with the agreement term.
- Yet another embodiment is directed to a computer-implemented method for facilitating definition of a transaction agreement between a party and a counter-party.
- at least one agreement document template associated with a transaction agreement type is created.
- a plurality of agreement facts are determined, at least one of the agreement facts being associated with the party and/or the counter-party.
- An agreement document instance associated with the transaction agreement is then defined, the agreement document instance being based on the agreement document template and the plurality of agreement facts.
- One embodiment of the present invention comprises: means for automatically determining an agreement type based on a plurality of product types and a covered products matrix; and means for determining, in accordance with the agreement type, an agreement term between a party and a counter-party.
- Another embodiment comprises: means for determining an agreement type; means for determining an agreement term; and means for generating an indication based on an evaluation of the agreement type and the agreement term.
- Another embodiment comprises: means for determining a contract type; and means for determining, in accordance with the contract type, a contract term between a party and a counter-party.
- Another embodiment comprises: means for determining an agreement term; means for determining a term date associated with the agreement term; and means for storing an indication of the agreement term in association with an indication of the term date, wherein an applicability of the agreement term can be automatically determined based at least in part on the term date.
- Another embodiment comprises: means for determining a first agreement term via a first party entity; and means for determining a second agreement term via a second party entity based at least in part on the first agreement term.
- Still another embodiment comprises: means for determining an agreement term; and means for storing a value associated with the agreement term along with an indication of a right associated with the agreement term.
- Yet another embodiment comprises: means for creating at least one agreement document template associated with a transaction agreement type; means for determining a plurality of agreement facts, at least one of the agreement facts being associated with a party and/or a counter-party; and means for defining an agreement document instance associated with the transaction agreement, the agreement document instance being based on the agreement document template and the plurality of agreement facts.
- FIG. 1 is a block diagram overview of an agreement modeling system according to an embodiment of the present invention.
- FIG. 2 is a flow chart of a method according to some embodiments of the present invention.
- FIG. 3 is a block diagram overview of an agreement modeling system according to another embodiment of the present invention.
- FIG. 4 is a client-server diagram overview of an agreement modeling system according to some embodiments of the present invention.
- FIG. 5 is a more detailed diagram of an agreement modeling system according to an embodiment of the present invention.
- FIG. 6 is an information architecture overview associated with an agreement modeling system according to some embodiments of the present invention.
- FIG. 7 is a flow chart of a method for storing information associated with an agreement modeling system according to some embodiments of the present invention.
- FIG. 8 illustrates various representations of agreement modeling system information according to an embodiment of the present invention.
- FIG. 9 is a flow chart of an agreement modeling system method according to some embodiments of the present invention.
- FIG. 10 is a block diagram of an agreement modeling system controller according to an embodiment of the present invention.
- FIG. 11 is a tabular representation of a portion of an agreement information database according to an embodiment of the present invention.
- FIG. 12 is a flow chart of a method for establishing a time perspective via an agreement modeling system according to some embodiments of the present invention.
- FIG. 13 illustrates agreement time perspective according to one embodiment of the present invention.
- FIG. 14 is a flow chart of a method associated with a covered products matrix according to some embodiments of the present invention.
- FIG. 15 illustrates an example of a covered products matrix according to an embodiment of the present invention.
- FIG. 16 illustrates another example of a covered products matrix according to an embodiment of the present invention.
- FIG. 17 is a flow chart of another method associated with a covered products matrix according to some embodiments of the present invention.
- FIG. 18 is a flow chart of a method for facilitating definition of a transaction agreement between a party and a counter-party according some embodiments of the present invention.
- FIGS. 19A and 19B are block diagrams of agreement modeling system functions, applications, and interactions according to some embodiments of the present invention.
- FIG. 20 is a block diagram of agreement creation interactions according to some embodiments of the present invention.
- FIG. 21 is a block diagram of document creation interactions according to some embodiments of the present invention.
- FIGS. 22 through 24 illustrate client displays associated with an agreement according to an embodiment of the present invention.
- FIG. 25 is a flow chart of a method for facilitating definition of an agreement between a party (including a first party entity and a second party entity) and a counter-party according some embodiments of the present invention.
- FIGS. 26A and 26B are a flow chart of another method for facilitating definition of an agreement according to some embodiments of the present invention.
- FIG. 27 illustrates some examples of agreement definition via multiple entities according to an embodiment of the present invention.
- Embodiments of the present invention are associated with systems and methods for facilitating definition of an “agreement” between a party and a counter-party via an agreement modeling system.
- the term “agreement” may refer to any arrangement between the parties.
- An agreement may be, for example, a legal contract defining a set of rights that exist between the parties, such as an INTERNATIONAL SWAP DEALERS ASSOCIATION® (ISDA®) master agreement associated with financial instruments and products.
- ISDA® INTERNATIONAL SWAP DEALERS ASSOCIATION®
- a single agreement may be associated with more than two parties (e.g., three parties may enter into a legal contract).
- an agreement may or may not be legally binding (e.g., an agreement may simply reflect an informal understanding between parties).
- party and “counter-party” can refer to any entity associated with an agreement.
- a party may be, for example, a business, a business entity (e.g., a department within a business), or a person.
- FIG. 1 is a block diagram of an agreement modeling system 100 according to an embodiment of the present invention.
- an agreement modeling system controller 1000 may interact with a client device 10 .
- a user may input information associated with a transaction agreement via the client device 10 .
- the client device 10 may then transmit appropriate information to the agreement modeling system controller 1000 , which in turn may store and/or interpret the information.
- a user may request information about an agreement via the client device 10 (e.g., by performing a query associated with a transaction agreement).
- FIG. 2 is a flow chart of a method according to some embodiments of the present invention.
- the flow charts in FIG. 2 and the other figures described herein do not imply a fixed order to the steps, and embodiments of the present invention can be practiced in any order that is practicable.
- the method shown in FIG. 2 may be performed, for example, by the agreement modeling system controller 1000 .
- a contract type is determined. For example, a user may input information via the client device 10 indicating one or more financial products that will be associated with the contract. The agreement modeling system controller 1000 may then determine an appropriate contract type based on those financial products.
- a contract term between a party and a counter-party is determined in accordance with the contract type. For example, based on the contract type determined at 202 , the agreement modeling system controller 1000 may determine one or more appropriate contract terms (e.g., a contract clause or a credit limit to be associated with a particular financial product).
- the agreement modeling system controller 1000 may determine one or more appropriate contract terms (e.g., a contract clause or a credit limit to be associated with a particular financial product).
- FIG. 3 is a block diagram overview of an agreement modeling system 300 according to another embodiment of the present invention.
- the agreement modeling system controller 1000 communicates with the client device 10 .
- devices such as the agreement modeling system controller 1000 and the client device 10
- may communicate via a communication network 20 such as a Local Area Network (LAN), a Metropolitan Area Network (MAN), a Wide Area Network (WAN), a proprietary network, a Public Switched Telephone Network (PSTN), a Wireless Application Protocol (WAP) network, a wireless LAN (e.g., in accordance with the Institute of Electrical and Electronics Engineers 802.11 standard), a Bluetooth network, an Infrared Radiation (IR) network, and/or an IP network such as the Internet, an intranet or an extranet.
- LAN Local Area Network
- MAN Metropolitan Area Network
- WAN Wide Area Network
- PSTN Public Switched Telephone Network
- WAP Wireless Application Protocol
- wireless LAN e.g., in accordance with the Institute of Electrical and Electronics Engineers 802.11 standard
- the term “communications” can refer to wired and/or wireless communications as appropriate. Note that the devices shown in FIG. 3 need not be in constant communication. For example, the agreement modeling system controller 1000 may communicate with a client device 10 on an as-needed or periodic basis.
- agreement modeling system controller 1000 may be included in the agreement modeling system 300 .
- client devices 10 may be included in the agreement modeling system 300 according to embodiments of the present invention.
- the agreement modeling system controller 1000 and the client devices 10 may be any devices capable of performing the various functions described herein.
- a client device 10 may be, for example: a Personal Computer (PC), a portable computing device (e.g., a laptop computer), a Personal Digital Assistant (PDA), or a dedicated agreement modeling system 300 terminal.
- the client device 10 may be associated with a full-blown workstation application or a thin-client browser-based application.
- a user enters information associated with an agreement via the client device 10 .
- the agreement may be, for example, associated with financial transactions between a party and a counter-party.
- the user may enter information about the party, the counter-party, and/or the financial transactions via the client device 10 (e.g., by selecting a number of different financial instruments that will be involved in transactions between the parties).
- Information associated with the agreement may then be transmitted from the client device 10 to the agreement modeling system controller 1000 via the communication network 20 , and the agreement modeling system controller 1000 may process the information to facilitate definition of the agreement.
- the agreement modeling system 1000 also communicates with one or more satellite systems, such as a business system 30 , a legal system 40 , a compliance system 50 , a credit system 60 , a treasury system 70 , and/or an operations system 80 to facilitate definition of the agreement.
- the agreement modeling system controller 1000 may review information provided by the user and determine that the agreement requires approval via a credit system 60 .
- the agreement modeling system controller 1000 may communicate with the client device 10 and one or more satellite systems via a single communication network or via different communication networks.
- FIG. 4 is a client-server diagram overview of an agreement modeling system 400 according to some embodiments of the present invention.
- a database server 1002 communicates with a number of middle-tier servers 1004 .
- each middle-tier server 1004 communicates with one or more client devices 12 .
- the database server 1002 may include (or communicate with) an agreement modeling system database, such as a database that stores agreement information.
- the database server 1002 may also include Java and Structured Query Language (SQL) stored procedures along with User Defined Functions (UDFs).
- SQL Structured Query Language
- UDFs User Defined Functions
- the database server 1002 can act as a “back-end” to the agreement modeling system 400 and manage user connections (e.g., by invoking stored procedures in and out, validating client logons, establishing client access rights, and/or maintaining a list of connected clients).
- the database server 1002 may also perform concurrency management (e.g., by responding to client timeout or disconnect notifications from middle-tier servers 1004 , releasing check-out locks, updating access modes, and managing access modes and check-out locks on agreements, facts, or fact sets as described, for example, with respect to FIG. 6).
- the database server 1002 may manage Extensible Markup Language (XML) and Application Program Interface (API) information (e.g., by managing special Java XML API entry point stored procedures, interpreting incoming XML streams, performing appropriate XML operations, returning appropriate response XML packets, and/or retrieving agreement information using XML streams).
- XML Extensible Markup Language
- API Application Program Interface
- the middle-tier servers 1004 may comprise, for example, SILVERSTREAM® or WEBLOGIC® servers that manage user connections (e.g., via special login and logout servlet interfaces and/or by establishing logins and logouts with the database server 1002 ).
- the middle-tier servers 1004 may also perform session management (e.g., by handling timeouts and disconnects and notifying the database server 1002 when a client device 12 has timed-out or disconnects) and/or manage database connections (e.g., by optimizing and pooling database connections and providing XML user and session identification packets associated with XML packets sent to the database server 1002 ).
- the middle-tier servers 1004 may also perform XML API management (e.g., using a special XML API servlet interface that serves as a pass-through for XML packets sent to the database server 1002 via calls to a Java stored procedure).
- a client device 12 may, for example, control user functionality (e.g., by supporting applicable user interactions).
- the client device 12 may also perform session management (e.g., by providing user login and logout capability, managing a physical connection including a connection status notification to a user, and issuing a logout when appropriate) and manage XML API interactions (e.g., by interacting with an XML API back-end via correctly formed XML packets, and/or managing incoming XML API response packets returned from XML API calls).
- session management e.g., by providing user login and logout capability, managing a physical connection including a connection status notification to a user, and issuing a logout when appropriate
- manage XML API interactions e.g., by interacting with an XML API back-end via correctly formed XML packets, and/or managing incoming XML API response packets returned from XML API calls).
- This hierarchical arrangement (e.g., having a client tier, a middle tier, and a database tier) may let a significant number of client devices 12 access and utilize the database server 1002 .
- FIG. 5 is a more detailed diagram of an agreement modeling system 500 according to one embodiment of the present invention.
- a database server 1006 communicates with a middle-tier server 1008 .
- the middle-tier server 1008 communicates with a client device 14 .
- the database server 1006 may, for example, provide support for an API via stored procedures and UDFs.
- the database server 1006 may also manage persistence of agreement information and API states for the agreement modeling system 500 in a database.
- the middle-tier server 1008 may communicate with the database server 1006 via a number of server-side language managers, such as an agreement and/or a utility language manager.
- the server-side language managers may, for example, implement interfaces similar to those provided on the client side to provide specific API functionality. These managers may be registered with an execution manager indicating supported interfaces. Instances of the server-side language managers may be instantiated to service incoming API method calls. The managers may also provide implementation of the API method calls by interacting directly with the agreement database via stored procedure calls.
- the server-side language managers may communicate with the execution manager via a server-side base language manager that routes method calls and provides implementation of common API methods.
- the execution manager may exchange information with a communication manager associated with the client device 14 via a Hyper-Text Transfer Protocol (HTTP) connection.
- HTTP Hyper-Text Transfer Protocol
- the execution manager may be delegated to by middle-tier servlets that process HTTP requests and responses.
- the execution manager may also handle all incoming API “method calls” and interact with the service-side base language manager to service those calls.
- the execution manager may be responsible for the registration of server-side language managers, “de-serializing” XML method call packets, routing methods to the appropriate registered server-side language manager, “serializing” return values or errors into XML packets, and/or forwarding return values or errors back to the client device via an HTTP response.
- the communication manager in the client device 14 interacts with a client-side base language manager and the middle-tier servlets.
- the communication manager is responsible for managing the connection with the server, the invocation of method calls by passing a stream to the server, the receiving return values or errors back as a stream, and/or propagating up return values or errors to the language manager layer. Both synchronous and asynchronous method calls may be supported at this layer.
- the client-side base language manager may define a base class from which extended client-side language managers are derived. Common functionality may be implemented in the base class, including a standard set of API method calls. The client-side base language manager may also be responsible for interacting with the communication manager to process method calls forwarded by derived client-side language managers.
- the client side base language manager communicates with a number of client-side language managers, such as an agreement and/or a utility language manager.
- the client-side language managers may implement interfaces providing specific API functionality to the client device 14 .
- the API methods in the client application may be called like any other local method.
- the derived client-side language managers may be responsible for serializing method calls into XML packets and/or interacting with the client-side base language manager to process the call.
- FIG. 6 is an information architecture overview associated with one such embodiment of the present invention.
- the information architecture is associated with a hierarchical view of agreement information.
- an agreement 602 is viewed as a set of related documents 604 .
- Each document 604 comprises one or more fact sets 606 , and each fact set 606 includes a number of related facts 608 (e.g., single pieces of information).
- the information architecture may apply structure to information through the constructive use of well-known fact sets 606 and data definitions that are applied to facts 608 , and taken together, data context may be maintained.
- the agreement 602 is associated with an “original” document instance containing facts 608 that define the agreement 602 upon creation. As additional information is created (e.g., the original agreement 602 is amended), additional documents 604 may be added to define the facts 608 that apply at particular points in time.
- a document 604 may be created that “overrides” existing facts 608 in an agreement 602 for a specified period of time and/or that adds new facts 608 that extend existing facts 608 . In either case, the added document 604 may now be considered to determine a complete set of agreement facts 608 (e.g., via an agreement modeling system query).
- documents 604 may be categorized according to a single document type name and any number of document type facts that further refine the documents classification.
- the document type name may indicate a basic category of agreement types (e.g., a financial instrument swap agreement or an over-the-counter financial instrument agreement) and the document type fact (or facts) may further categorize a document's relationship to an agreement (e.g., a credit support annex or an amendment to an existing agreement 602 ).
- a document 604 contains instances of fact sets 606 , and a fact 608 may belong to an instance of a fact set 606 .
- Fact set definitions (in addition to document definitions) may exist outside of any agreement, and their definition and fact content may be described via an agreement modeling language.
- a fact 608 may be associated with a party name, a party address, a term date, a country of origin, an indication of governing law (e.g., “Delaware law applies to all transactions associated with this agreement”), or any other information associated with an agreement.
- a fact set 606 may comprise, for example, a counter-party fact set including a counter-party name and address.
- fact sets 606 can be single-instance or multi-instance. In either case, a fact 608 belonging to a fact set 606 may be related to the other facts 608 in that fact set 606 .
- a multi-instance fact set 606 enables the repeated instantiation of the same set of facts 608 , typically with different values being associated with the different instantiated facts 608 .
- An instance of a multi-instance fact 606 set is analogous to a row of data in a conventional database table, and the facts 608 are analogous to columns. Note, however, that the table is not statically defined—rather it is dynamically defined via the agreement modeling language.
- a fact 608 in the agreement modeling system may have pre-defined attributes that describe the fact's nature and meaning.
- each fact 608 may have an associated data type that defines a set of potential values and/or data input behavior.
- a fact 608 may be considered “internal” or “external,” and external facts may map to information in other databases (i.e. external databases).
- other attributes may be applied to facts 608 to help to define context.
- FIG. 7 is a flow chart of a method for storing agreement information according to some embodiments of the present invention.
- an agreement term is determined.
- the agreement modeling system controller 1000 may determine one or more facts associated with an agreement (i.e., facts indicating an agreement term) based on information provided via a client device 10 .
- the agreement modeling system controller 1000 determines the agreement term by accessing other information (e.g., via a covered products matrix as described with respect to FIGS. 14 through 16).
- a value associated with the agreement term is stored along with an indication of a right associated with the agreement term.
- the value may be stored via an extensible agreement modeling system language.
- an XML or Standard Generalized Markup Language (SGML) data format may be used to store information as follows: ⁇ Agreement> ⁇ Document> ⁇ FactSet> ⁇ Fact> ⁇ /Fact> . . . ⁇ /FactSet> . . . ⁇ /Document> . . . ⁇ /Agreement>
- Such an approach may let the system model dynamic information (e.g., document and fact set information) and facilitate communication of dynamic agreement information between a client and a server.
- the implementation may be technology neutral (e.g., the information may be provided to or accessed by a number of different technologies).
- facts may be associated with attribute information, such as a data name, a data prompt, a data type, a security attribute, and/or a display attribute.
- FIG. 8 illustrates various representations of agreement modeling system information according to an embodiment of the present invention.
- the relationships between an information architecture 802 , an XML representation 804 , and a display 806 are illustrated.
- MASTER” id “2” . . . >, which in turn may be rendered by an agreement application display engine (e.g., via a document list pane and/or an active document information pane).
- FIG. 9 is a flow chart of a method according to some embodiments of the present invention.
- the agreement modeling system controller 1000 may gather information associated with a financial transaction agreement between a party and a counter-party via one or more client devices 10 and/or satellite systems.
- a request for a new agreement may be generated by a satellite system, such as the business system 30 , the credit system 60 , and/or the treasury system 70 .
- a user associated with the business system 30 may populate a new agreement request form via a Web-based interface provided by the agreement modeling system 1000 .
- the new agreement request form may include, for example, a set of “required” information, such as: a name of a sales person covering an account, a selected entity master (e.g., via a drop-down list of party entities that the counter-party is contemplating doing business with), a business desk (e.g., an indication of “Fixed Income,” “Equity,” or “Commodities” which may be automatically generated based on a user identifier), a counter-party legal name (e.g., selected from a drop-down list), contact information of a person with whom documentation will be exchanged (e.g., a name, a phone number, and/or a facsimile number), one or more products to be traded (e.g., associated with a covered products matrix), an indication of whether or not the agreement is bilateral (e.g., a name of
- the new agreement request form may also include information that will be required when appropriate (e.g., based on the particular agreement being requested), such as a type of agreement (e.g., selected from a drop-down list) and/or an investment advisor.
- the new agreement request form may also include optional information, such as an electronic mail address associated with the counter-party.
- some information may be selected by a user via a drop-down list (e.g., a counter-party name or identifier).
- the desired information may not be present in the drop-down list (e.g., when a new counter-party is desired).
- a user may be asked to complete another form (e.g., a new counter-party request form) or he or she may simply enter the information manually (e.g., via free form text).
- one or more satellite systems may be involved in this process (e.g., the compliance system 50 may approve new counter-parties).
- the agreement modeling system controller 1000 determines if a new agreement is actually required at 904 .
- the agreement modeling system controller 1000 may execute a query to ensure that there are no other existing agreements in place and return the results of the query to the user (e.g., by indicating that “there are existing agreements that cover this request”). If no new agreement is required at 904 (e.g., an appropriate existing agreement is found by the agreement modeling system controller 1000 ), one or more amendments to the existing agreement may be facilitated at 906 .
- the agreement modeling system controller 1000 or the compliance system 50 may determine that an existing agreement can be used to cover a transaction by broadening a compliance covered products scope term in the existing agreement.
- an electronic mail message may be transmitted to the legal system 40 asking if the agreement scope can be broadened accordingly.
- the legal system 40 may then indicate to the business system 30 that the transaction can be covered under the existing agreement.
- the legal system 40 may instead indicate that a new agreement is required.
- the new agreement request form is processed by the agreement modeling system controller 1000 .
- the processing of the new agreement request form also involves one or more satellite systems.
- the compliance system 50 may receive the request via an automated workflow and provide information as required. In this case, the compliance system 50 may advise the legal system 40 as to the types of products the counter-party is authorized to trade, and with which party entity the counter-party may trade these products.
- the compliance system 50 may need to access information about the agreement, such as the counter-party name or identifier, a master agreement type, a current status of the master agreement type, a date of agreement, a document identifier, an investment advisor, and/or a security agreement type.
- information about the agreement such as the counter-party name or identifier, a master agreement type, a current status of the master agreement type, a date of agreement, a document identifier, an investment advisor, and/or a security agreement type.
- the compliance system 50 may define facts for the agreement, such as: a compliance officer name responsible for the account, a party entity approved for the business, a covered products matrix indicating the authorized products the counter-party can or can't trade, and/or one or more supporting authority documents.
- the form may be forwarded to the credit system 60 (e.g., if the agreement is associated with a risk transaction) to provide still more information.
- information may include, for example, collateral terms such as: a credit officer name responsible for the account, terms of a collateral agreement (e.g., bilateral, party post, or counter-party post), an independent amount (e.g., an initial margin percentage or dollar amount associated with notional amount), a threshold amount (e.g., a trigger value associated with a specified dollar amount or a ratings table), a minimum transfer amount, a rounding amount, and/or a base currency.
- collateral terms such as: a credit officer name responsible for the account, terms of a collateral agreement (e.g., bilateral, party post, or counter-party post), an independent amount (e.g., an initial margin percentage or dollar amount associated with notional amount), a threshold amount (e.g., a trigger value associated with a specified dollar amount or a ratings table), a minimum transfer amount, a rounding amount, and/
- the credit system 60 may also provide non-collateral terms, such as: default information (e.g., bankruptcy information or credit event upon merger information), a cross acceleration threshold amount for the counter-party, and/or one or more credit-related additional termination events (e.g., adequate assurance, amendment of constituent documents, break clause, credit rating downgrade, decline in partners capital, governmental moratorium on debt declared, investment advisor event, material adverse change, modification to guaranty, net asset value information, ownership maintenance, redemption of notes, termination of trust under trust agreement, termination rights linked to separate agreement, transactions not covered by guaranty and/or guarantor, or withdrawal of general partners or key employees).
- default information e.g., bankruptcy information or credit event upon merger information
- a cross acceleration threshold amount for the counter-party e.g., a cross acceleration threshold amount for the counter-party
- one or more credit-related additional termination events e.g., adequate assurance, amendment of constituent documents, break clause, credit rating downgrade, decline in partners capital, governmental moratorium on debt declared
- the credit system 60 may also indicate one or more credit support documents referenced under the agreement, such as: a comfort letter, a deed poll guarantee, an indemnity agreement, a Keepwell agreement, a letter of commitment, a letter of credit, a security trust deed, a senior facility agreement, a supplemental trust deed, a support agreement, and/or a swap surety bond/insurance policy.
- a comfort letter such as: a comfort letter, a deed poll guarantee, an indemnity agreement, a Keepwell agreement, a letter of commitment, a letter of credit, a security trust deed, a senior facility agreement, a supplemental trust deed, a support agreement, and/or a swap surety bond/insurance policy.
- the treasury system 70 may provide information associated with bilateral agreements, such as an indication of approval, a threshold amount, a notional amount, eligible collateral types (e.g., United States Treasury bills, highly liquid pools, AAA bonds, residuals, commercial paper, investment grade corporate instruments, preferred stock, municipals, emerging market debt, Brady bonds, high yields, non-distressed issues, distressed issues, bank debt, par, whole loans, residential, commercial, and/or short-term mortgage backed bank notes), equities (e.g., United States or United Kingdom listed equities, foreign convertibles-investment grade, foreign convertibles-high yield, listed mutual funds, rights and warrants, or options), commodities (e.g., metals or energy), interest paid on cash collateral, base currency on cash, tri-party custodial relationships, notification time, amendments to transfer provision (e.g., after approval by the legal system 40 ).
- eligible collateral types e.g., United States Treasury bills, highly liquid pools, AAA bonds, residuals, commercial paper, investment grade corporate
- the processing of multiple new agreement request forms may be prioritized (e.g., based on a date on which a request was made, a date associated with a pending trade, or a number of requests in a queue for a given business area).
- an agreement is drafted by the agreement modeling system controller 1000 at 908 .
- the agreement modeling system controller 1000 may use a rule set to route the new agreement request form to an appropriate functional group within the legal system 40 based on a product type and/or a party entity.
- an agreement type e.g., an ISDA® master agreement schedule, a club letter, or a credit support annex in accordance with New York law
- a user has the ability to override an agreement type chosen by the system.
- the legal system 40 can access the generated agreement on-line to review the agreement's structure and to make revisions, if required.
- the legal system 40 may also prepare the agreement for transmission. If desired, the legal system 40 may be prevented from changing or over-riding data that was originally provided via the new agreement request form.
- the agreement modeling system controller 1000 may then automatically generate the agreement and, according to one embodiment, any supporting documents that accompany the agreement (e.g., a power of attorney, a legal opinion, a pre-executed request guarantee, and/or a cover letter).
- any supporting documents that accompany the agreement e.g., a power of attorney, a legal opinion, a pre-executed request guarantee, and/or a cover letter.
- the user or the agreement modeling system controller 1000 then forwards the agreement to the counter-party at 910 .
- a user may manually print hard copies of the agreement to send via a delivery service (e.g., FED EX®).
- the agreement modeling system controller 1000 sends a facsimile or an electronic message attachment of the agreement in an unalterable format (e.g., a “pdf” file) to the counter-party.
- the system may also provide the user with an automated notification that the document has been successfully transmitted.
- the agreement is published via a Uniform Resource Locator (URL) address that enables the counter-party to securely view the agreement.
- URL Uniform Resource Locator
- the agreement modeling system controller 1000 instead determines that an agreement will not be automatically generated. This may be the case, for example, when a data field in the new agreement request form requires a change (e.g., a name change or a policy change). Similarly, it may be determined that a counter-party form of the agreement will be used, that supervisory review is required (e.g., based on a functional group associated with the agreement), or that the business system 30 has asked that the generation or transmission be postponed.
- a change e.g., a name change or a policy change.
- the counter-party may the respond to the draft agreement (e.g., by proposing changes to the draft agreement). For example, the counter-party may return a hard copy of an altered agreement. In this case, the hard copy may be scanned and stored via an Optical Character Recognition (OCR) application. The counter-party may instead contact the party via telephone to verbally confirm the terms of the agreement or advise of any discrepancies between the counter-party's view and party's view of the agreement. In this case, the agreement modeling system controller 1000 may store the name of the person who called and the time, date, and substance of the conversation.
- OCR Optical Character Recognition
- Any changes proposed by the counter-party are then reviewed at 912 .
- discrepancies may be determined and routed to the appropriate party entities for reconciliation (e.g., by routing the information to an appropriate information owner based on a functional group or a document type).
- a final execution document is prepared at 920 and sent to the appropriate parties for execution at 922 .
- a fully negotiated ISDA® schedule and boiler-plate may be printed and forwarded to the counter-party for signature.
- a cover letter with instructions to the counter-party may be automatically generated along with any required tax documents.
- the counter-party can then return the signed agreement via hard copy, electronic mail, facsimile, or a URL, together with any supporting documentation (e.g., a power of attorney).
- the date that the agreement was executed may be recorded by the agreement modeling system controller 1000 along with, for example, a date on which the agreement is effective (which may or may not be the same as the execution date). Any subsequent amendments to the agreement may then be made at 906 .
- FIG. 10 illustrates an agreement modeling system controller 1000 that is descriptive of the devices shown, for example, in FIGS. 1 and 3 according to some embodiments of the present invention.
- the agreement modeling system controller 1000 comprises a processor 1010 , such as one or more INTEL® Pentium® processors, coupled to a communication device 1020 configured to communicate via a communication network (not shown in FIG. 10).
- the communication device 1020 may be used to communicate, for example, with one or more client devices 10 and/or satellite devices.
- the processor 1010 is also in communication with an input device 1040 .
- the input device 1040 may comprise, for example, a keyboard, a mouse or other pointing device, a microphone, knob or a switch, an IR port, a docking station, and/or a touch screen. Such an input device 1040 may be used, for example, to enter information (e.g., agreement information).
- the processor 1010 is also in communication with an output device 1050 .
- the output device 1050 may comprise, for example, a display (e.g., a display screen), a speaker, and/or a printer.
- the output device 1050 may be used, for example, output agreement information (e.g., a final version of an agreement to be executed or a date on which a particular agreement became effective).
- the processor 1010 is also in communication with a storage device 1030 .
- the storage device 1030 may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., magnetic tape and hard disk drives), optical storage devices, and/or semiconductor memory devices such as Random Access Memory (RAM) devices and Read Only Memory (ROM) devices.
- RAM Random Access Memory
- ROM Read Only Memory
- the storage device 1030 stores a program 1015 for controlling the processor 1010 .
- the processor 1010 performs instructions of the program 1015 , and thereby operates in accordance with the present invention.
- the processor 1010 may receive agreement information, process agreement information (e.g., in accordance with one or more rules), and/or output agreement information.
- the processor 1010 automatically determines an agreement type based on a plurality of product types and a covered products matrix. The processor 1010 then determines, in accordance with the agreement type, an agreement term between a party and a counter-party.
- the processor 1010 determines an agreement type and an agreement term. The processor 1010 then generates an indication based on an evaluation of the agreement type and the agreement term.
- the processor 1010 determines a contract type.
- the processor 1015 determines, in accordance with the contract type, a contract term between a party and a counter-party.
- the processor 1010 determines an agreement term and a term date associated with the agreement term.
- the processor 1010 then stores an indication of the agreement term in association with an indication of the term date, wherein an applicability of the agreement term can be automatically determined based at least in part on the term date.
- the processor 1010 determines a first agreement term via a first party entity and, based at least in part on the first agreement term, determines a second agreement term via a second party entity.
- the processor 1010 determines an agreement term stores a value associated with the agreement term along with an indication of a right associated with the agreement term.
- the processor 1010 creates at least one agreement document template associated with a transaction agreement type.
- the processor 1010 determines a plurality of agreement facts, at least one of the agreement facts being associated with a party and/or a counter-party.
- An agreement document instance associated with the transaction agreement is then defined by the processor 1010 , the agreement document instance being based on the agreement document template and the plurality of agreement facts.
- the storage device 1030 also stores an agreement information database 1100 .
- the illustration and accompanying description of this database is exemplary, and any number of other database arrangements could be employed besides those suggested by the figure.
- a table represents the agreement information database 1100 according to one embodiment of the present invention.
- the table includes entries identifying agreement information.
- the table also defines 1102 , 1104 , 1106 , 1108 , 1110 for each of the entries.
- the table defines an agreement information identifier 1102 , an information type 1104 , an entry date 1106 , an effective date 1108 , and an expiration date 1110 .
- the information in the agreement information database 1100 may be created and updated, for example, by the agreement modeling system controller 1000 , a client device 10 , and/or a satellite device.
- the agreement information identifier 1102 may be, for example, an alphanumeric code associated with an agreement term (e.g., an agreement, a document, a fact set, or a fact).
- the information type 1104 describes the agreement information.
- the agreement information may comprise an original master agreement or an amendment to an existing master agreement.
- the agreement information database 1100 also stores one or more term dates associated with the agreement information.
- the entry date 1106 indicates when the agreement information was stored in the database.
- Other term dates indicate a period during which a particular agreement term applies.
- an agreement term may apply from the effective date 1108 to the expiration date 1110 .
- the effective date 1108 may be prior to (or after) the entry date 1106 associated with an agreement term.
- FIG. 12 is a flow chart of a method for establishing a time perspective according to some embodiments of the present invention.
- an agreement term is determined.
- the agreement modeling system controller 1000 may determine an agreement type, document, fact set, and/or fact based on information received via a client device 10 .
- a term date associated with the agreement term is determined.
- the agreement modeling system controller 1000 may determine the term date based on information received via a client device 10 .
- the term date may be associated with a term period during which the agreement term is applicable.
- the term date may be, for example, an effective date after which the agreement term is applicable or an expiration date after which the agreement term is not applicable.
- the term date may also be a term period (e.g., indicating that the agreement term is to be applicable for one year from a date on which an agreement document was signed).
- the term date may also be an entry date (e.g., a date on which information about the agreement term was entered into the agreement modeling system 100 ).
- an indication of the agreement term is stored in association with an indication of the term date so that an applicability of the agreement term can be automatically determined based at least in part on the term date.
- the agreement modeling system controller 1000 stores the appropriate information in the agreement information database 1100 .
- the agreement modeling system controller 1000 may also store, in association with the agreement term, an indication of at least one supporting agreement document (e.g., a pointer, a word processing file, or an electronic image file associated with a supporting agreement document).
- a document identifier may be stored to let a user quickly access an agreement document that defines the agreement term and/or the term date.
- agreement modeling system controller 1000 may store the amount of credit along with an expiration date (e.g., a date after which credit will not be extended to the counter-party).
- an agreement term may be entered into the agreement modeling system 100 (i.e., on the entry date) after the agreement term has expired (i.e., the expiration date).
- an entry date may be prior to the effective date of the agreement term.
- the entry date may also fall between the effective date and the expiration date.
- a user at a client device can query the agreement modeling system controller 1000 to determine if an agreement term is applicable on a particular date (e.g., the current date or any other “query” date of interest to the user).
- FIG. 14 is a flow chart of a method associated with a covered products matrix according to some embodiments of the present invention.
- the method may be performed, for example, by the agreement modeling system controller 1000 and may be associated with a transaction agreement defining a plurality of product types (e.g., a number of different financial products) and instruments (e.g., a number of different financial instruments).
- product types e.g., a number of different financial products
- instruments e.g., a number of different financial instruments
- an agreement type is automatically determined based on the plurality of product types (or instruments) and a “covered products matrix.”
- the phrase “covered products matrix” may refer to, for example, any stored indication of transaction instruments (e.g., swaps, options, and forwards) and product types (e.g., stocks, bonds, and credit derivatives) in connection with a particular agreement. Note that the stored information does not necessarily need to be in the form of a matrix or an array.
- the agreement type determined at 1402 may be associated with, for example, a set of rights between the party and the counter-party, a legal contract, a product type, a monetary amount, and/or a transaction instrument.
- the agreement type comprises a document type name (e.g., an ISDA® master agreement type) and one or more document type facts (e.g., further characterizing the document type).
- an agreement may be associated with a number of different financial products.
- an agreement may be associated with an equity instrument (e.g., a stock or index instrument), a fixed income instrument (e.g., a bond, a bank loan, or a credit derivative), and/or a commodity instrument (e.g., a precious metals instrument or a wheat commodity instrument).
- an equity instrument e.g., a stock or index instrument
- a fixed income instrument e.g., a bond, a bank loan, or a credit derivative
- a commodity instrument e.g., a precious metals instrument or a wheat commodity instrument.
- the agreement may further be associated with one or more financial instruments (e.g., a warrant or a buy-call option).
- a user may indicate that a particular agreement is going to be associated with (i) buy and sell options for gold commodities and (ii) swaps for silver commodities (i.e., as indicated as “Y” in FIG. 15). Based on this information, an appropriate agreement type may be determined by the agreement modeling system controller 1000 .
- an agreement term between the party and the counter-party is determined in accordance with the agreement type.
- the agreement modeling system controller 1000 may determine a number of default agreement terms (e.g., default credit limits) associated with a particular agreement type.
- the agreement term may be associated with, for example, a right between the party and the counter-party, a legal contract term, a product type, a monetary amount, and/or a transaction instrument.
- agreement modeling system controller 1000 may determine an appropriate agreement type and populate a document with appropriate terms and parameters for these types of transactions.
- the covered product matrix may be associated with any number of product types, such as equity products, stock products, index products, fixed income products, bond products, bank loan products, whole loan products, interest rate products, credit derivative products, commodity products, metal products, energy products, agriculture products, and/or any other type of product.
- the covered product matrix may be associated with any number of transaction instruments, such as swap instruments, option instruments, buy instruments, sell instruments, call instruments, put instruments, forward instruments, pre-paid forward instruments, spot instruments, repurchase agreement instruments, loan instruments, warrant instruments, a contract for differences instrument, and/or any other type of instrument.
- the covered products matrix may indicate when a particular financial instrument is approved (or disapproved) with respect to an agreement between a party and a counter-party. Also note that the covered products matrix may indicate if either of these items are “under investigation” (e.g., approval or disapproval is pending) or “not contemplated” (e.g., by the party or the counter-party). Similarly, the covered products matrix may indicate compliance authorization information, default information, party or counter-party information, legal information, and/or master agreement information.
- the agreement term may be automatically determined at 1404 by defining the agreement term based on a pre-stored default transaction term (e.g., a “best practices” transaction term).
- the agreement term may also be automatically determined by defining the agreement term based on information receive from a user (e.g., via a client device 10 ) or a legacy agreement system.
- the agreement term is also based on information receive from a satellite system.
- the agreement term may be based on input received from a business system 30 , a legal system 40 , a compliance system 50 , a credit system 60 , a treasury system 70 , and/or an operations system 80 .
- the covered products matrix may set the scope of a particular agreement between a party and a counter-party. From a compliance system 50 perspective, an individual covered products matrix may exist for each “entity pair” (i.e., a party-counter-party pair). From a legal system 40 perspective, a covered products matrix may exist for each agreement, and there may be multiple covered product matrices for a single entity pair. In this case, the agreement modeling system controller 1000 may ensure that this does not result in over-lapping coverage.
- the agreement modeling system controller 1000 defaults certain products to “no” based on a pre-defined rule. For example, if a new authorized scope entry is created for a particular counter-party, the agreement modeling system controller 1000 may default all foreign exchange products to “no” since the compliance system 50 does not typically approve foreign exchange products with that particular counter-party. According to one embodiment, an operator may override these defaults determinations.
- the compliance system 50 may mark appropriate products with a “yes,” indicating that those products may be traded with the counter-party.
- the compliance system 50 may also have the ability to mark products with a “no” (indicating disapproval) or “in progress” indicating that the product is in the process of being considered. All other boxes may remain blank indicating that the product has not been (and is not being) considered.
- the agreement modeling system controller 1000 use a default document scope if the agreement type in question is always limited to a certain subset of products. A user may also over-ride these default values.
- an “approved scope” layer that captures the products for which legal system 40 would like to use a given master agreement.
- the legal system 40 may define for each master agreement a set of trades for which that master agreement should be used. This set of trades may be a subset of the document scope, and the document scope may therefore be defined before the approved scope. According to one embodiment, the approved scope is limited to a subset of the authorized scope.
- FIG. 17 is a flow chart of another method associated with a covered products matrix according to some embodiments of the present invention.
- an agreement type is determined.
- an agreement term is determined. The agreement type and agreement term may be determined via any of the methods described herein (e.g., user input, default values, or satellite systems).
- the agreement type and the agreement term are then evaluated, resulting in an indication being generated at 1706 .
- the transaction agreement may associated with a plurality of financial product types.
- the evaluation may comprise evaluating the agreement type and the agreement term based on the plurality of financial product types and a covered products matrix.
- the indication that is generated at 1706 (e.g., indicating whether or not the agreement type and term are appropriate based on the financial product types) may be provided, for example, to a user of an agreement modeling system and/or a satellite system.
- the indication comprises a “warning flag” indicating that the details of the agreement need to be carefully reviewed.
- FIG. 18 is a flow chart of a method for facilitating definition of a transaction agreement between a party and a counter-party according some embodiments of the present invention.
- an agreement document template is created in association with a transaction agreement type.
- a plurality of agreement facts are determined.
- the agreement facts may be associated with, for example, the party and/or the counter-party.
- an agreement document instance associated with the transaction agreement is defined.
- the agreement document instance may be based on, for example, the agreement document template and the plurality of agreement facts.
- FIGS. 19A and 19B are block diagrams of agreement modeling system functions, applications, and interactions according to some embodiments of the present invention.
- FIG. 19A presents an engine-level overview of the client device 10 and the agreement modeling system controller 1000 according to one embodiment.
- the client device 10 includes a display engine 1902 that may be used to exchange information with a user (e.g., by receiving information from and displaying information to the user).
- the display engine 1920 may comprise, for example, a typical WINDOWS® style Multi-Document Interface (MDI) application. Such an application may simultaneously display one or more agreements.
- MDI WINDOWS® style Multi-Document Interface
- the agreement modeling system controller 1000 includes an administrator 1910 and an agreement engine 1920 described in detail with respect to FIG. 19B.
- the agreement modeling system controller 1000 also includes an evaluation engine 2040 and a creation engine 2030 described in detail with respect to FIGS. 20 and 21.
- the agreement modeling system controller 1000 may include a fact engine 1904 that may, for example, be used to process facts and fact sets as required.
- FIG. 19B illustrates the operation of the administrator 1910 and the agreement editor 1920 .
- the administrator 1910 may be used to create an agreement template, including templates for various documents associated with that type of agreement.
- the agreement template may include an original document template, a schedule document template, a CSA document template, and/or an amendment document template.
- the agreement editor 1920 may be used to create an agreement instance based on the agreement template.
- the agreement instance may, for example, include instances of one or more document templates (e.g., an original document instance, a schedule document instance, a CSA document instance, and/or an amendment document instance).
- Both the agreement template and the agreement instance may be stored in the agreement modeling system database 1930 for future use.
- FIG. 20 is a block diagram of agreement creation interactions according to some embodiments of the present invention.
- the creation engine 2030 may manufacture new agreements and documents.
- the creation engine 2030 may exist in the database/backend 2020 and may comprise a creation processor 2050 and an instance of the evaluation engine 2040 (e.g., that extends from the evaluation engine 2040 object in the Java/object sense).
- the creation engine 2030 may service two types of create operations: a create agreement operation and a create document operation.
- a successful create agreement operation results in a new agreement including one or more associated required documents.
- a successful create document(s) operation results in the creation of one (or more) new documents associated with an existing agreement.
- An instance of the creation engine 2030 is manufactured to service each create operation (note that the create functionality may be exposed via Java Stored Procedures).
- the create agreement operation may be invoked from the agreement editor 1920 upon a completion of an agreement wizard as follows.
- the agreement wizard may be selected via a “file—new” menu item, followed by selection of sub-menu items that allow selection of a specific agreement wizard.
- the content of each agreement wizard may be defined by one or more agreement wizard fact sets.
- the agreement wizard is completed by activating a “finish” button on one of the wizard pages. When the “finish” button is activated, all of the combined agreement wizard fact sets are communicated to the database backed 2020 , in the form of an XML document describing the fact set content, via a middle-tier 2010 .
- the middle-tier 2010 simply passes the stream through to the database/backend 2020 .
- an instance of the creation engine 2030 is instantiated.
- an instance of the evaluation engine 2040 is created and initialized with an agreement scope that contains all of the facts defined in the wizard fact sets passed from the agreement editor 1920 .
- the creation processor 2050 determines the appropriate agreement to be created (via “applies rules”). If an appropriate agreement is found, it is determined if the user has the appropriate rights to create all required documents associated with the agreement (via “security rules”). If the user has appropriate rights, then the agreement is created by systematically creating the required documents associated with the agreement, conditionally populating each document's content with the fact sets and facts that are included through the applies rules analysis. In addition, default values and attributes may be assigned to facts populated into documents.
- the creation processor 2050 may use a series of stored procedure calls that operate directly on the agreement, document, and fact set or fact instance tables populating instance data into the tables as the intermediate result of rules and expression evaluations.
- a set of well-defined stored procedures may accommodate the entire agreement creation process.
- the immediate return value for the create agreement operation from the database/backend 2020 to the middle-tier 2010 may simply comprise signal of success or failure. If the creation of the agreement failed, then the middle-tier 2010 returns an appropriate Java exception to the agreement editor 1920 .
- the middle-tier 2010 may orchestrate call(s) back to the database/backend 2020 to make it appear as if the agreement editor 1920 had called an “open agreement” operation. That is, an entire XML stream representing the opening of the newly created agreement may be returned.
- FIG. 21 is a block diagram of document creation interactions according to some embodiments of the present invention.
- the create documents operation may be invoked from the agreement editor 1920 when an “add” button is activated via a multi-document tab and one of the listed document types are selected.
- Such a multi-document tab approach enables the management of more than one document (and document type) via a single tab.
- a multi-document list box may display all instances of existing documents that are associated with that tab (e.g., documents may be associated with a tab based on a document type's document group membership).
- the agreement editor 1920 may first call a method that returns an array of (partially loaded) objects that are used to populate an “add document” selection dialog associated with the “add” button.
- a corresponding stored procedure may form the list of document types based an a specific user and/or agreement.
- the agreement editor 1920 Upon the selection of a document type from the “add document” list, the agreement editor 1920 sends the selected document type information to the database backed 2020 via a middle-tier 2010 API call.
- An instance of the creation engine 2030 is then instantiated by the database/backend 2020 .
- an instance of the evaluation engine 2040 is created and initialized with the agreement scope that is applicable for the active agreement.
- the agreement scope is passed as an XML stream by the agreement editor 1920 which has the scope loaded for the active agreement.
- the scope is instead loaded from a database 2060 .
- the creation processor 2050 conditionally populates the document's content with the fact sets and facts that are included through an “applies rules” analysis. In addition, default values and attributes are assigned to each fact based upon “value and attribute expressions.”
- the instance of the creation engine 2030 may be associated with a create agreement operation or a create document operation. In either case, the appropriate agreement scope may be initialized on the associated evaluation engine 2040 .
- a series of stored procedure calls by the creation processor 2050 may operate directly on the document and fact set—fact instance tables populating instance data into the tables as the result of the rules and expressions evaluations.
- a set of well-defined stored procedures may accommodate the entire agreement, document, fact set, and/or fact creation process.
- security tables and views may be calculated.
- the intermediate return value from the create document operation from the database/backend 2020 to the middle-tier 2010 may simply be a signal of success or failure. If the creation of the document failed, then the middle-tier 2010 returns an appropriate Java exception to the agreement editor 1920 .
- the middle-tier 2010 may orchestrates call(s) back to the database/backend 2020 to make it appear as if the agreement editor 1920 had called an update document operation. That is, an entire XML stream representing the newly created document may be returned.
- FIGS. 22 through 24 illustrate client displays associated with an agreement according to an embodiment of the present invention.
- the system may be document-centric in the display of agreement information, and that a new agreement may be created via a special wizard “fact set” that asks questions and receives answers (fact values) that are used by the fact engine's rules-based wizard to determine the agreement type, documents, fact sets, and facts that are populated in the agreement.
- FIG. 22 illustrates a display 2200 when no agreement is loaded into the application.
- a user selects an existing agreement from a search dialog that is associated with the “file . . . open agreement” menu item.
- FIG. 23 illustrates a display 2300 after an agreement has been loaded.
- Each agreement instance in the MDI display frame contains a set of display tabs that are dynamically generated according to a set of document groups that are defined for the agreement.
- Each document group has one or more documents that are members of the group and whose contents will be displayed on the relative document group tab.
- FIG. 23 illustrates the layout of a general “agreement data” single-document group tab. Note that a consistent display space may be organized around the current document and active fact set. For example, a tab associated with a single-document display may divide the display 2300 into a left and right pane.
- the current document's name (“LCA Today”) is displayed at the top of the left-pane.
- the left-pane list box contains the set of fact sets that are defined for the current document (e.g., “agreement data,” “counter-party data,” “credit support,” and “cross acceleration”).
- the right-pane contains the contents for the actively selected fact set within the current document.
- the name of the active fact set (e.g., “agreement data”) may be displayed in the top of the right-pane.
- FIG. 24 illustrates a display 2400 when an agreement has been loaded, and the display 2400 is associated with a multi-instance fact set display (i.e., “counter-party data”).
- the right-pane is divided into two areas.
- the top area includes a list box of instances of the active fact set.
- the display entry in the list box is formed by an expression associated with the fact set.
- the bottom portion of the right-pane display area indicates the facts that comprise the fact set which may be displayed in linear order (as with the single-instance display space).
- FIG. 25 is a flow chart of a method for facilitating definition of an agreement between a party (including a first party entity and a second party entity) and a counter-party according some embodiments of the present invention.
- a first agreement term is determined via the first party entity.
- the first agreement term may be defined by a compliance entity.
- a second agreement term is determined via the second party entity (e.g., based at least in part on the first agreement term).
- a legal entity may define the second agreement term based on the first agreement term.
- a request for an agreement is received by the agreement modeling system controller 1000 (e.g., via a client device 10 ). If the agreement is associated with a marketing tool at 2604 (i.e., the request may need to be processed immediately), a pre-draft of the agreement is generated at 2606 .
- a priority is assigned to the request at 2608 (e.g., as compared to other requests received by the agreement modeling system controller 1000 ). Note that trade activity detected at 2610 and a subsequent post-trade notification report 2612 may also result in a priority being assigned at 2608 .
- the agreement modeling system controller 1000 triggers a compliance entity 2616 for data.
- the compliance entity 2616 may receive, review, and respond to information associated with the requested agreement (e.g., to ensure that the information complies with relevant compliance standards and procedures). If the compliance data is not complete at 2618 , a data gathering entity issues a report at 2620 (e.g., to arrange for more data to be collected).
- the agreement modeling system controller 1000 triggers a credit entity 2624 for data.
- the credit entity 2624 may receive, review, and respond to information associated with the requested agreement (e.g., to ensure that the information complies with relevant credit standards and procedures).
- the agreement modeling system controller 1000 triggers a treasure entity 2632 for data at 2630 (e.g., to ensure that the information complies with relevant treasury standards and procedures).
- the agreement modeling system controller 1000 determines if the agreement data is complete at 2628 . If the agreement data is not complete, the data gathering entity issues a report at 2620 (e.g., to arrange for more data to be collected). If the agreement data is complete, a pre-draft of the agreement is generated at 2606 .
- FIG. 27 illustrates some examples of agreement definition via multiple party entities according to an embodiment of the present invention.
- the first work flow 2710 is associated with agreement definition when a business entity initiates a request for a new agreement associated with a risk transaction.
- Information from the business entity is forwarded to a compliance entity for review (and/or for further information).
- the agreement information is then reviewed (and/or supplemented) by a credit entity and finally by a legal entity (e.g., for approval).
- the second work flow 2720 is associated with agreement definition when a business entity initiates a request for a new agreement associated with a non-risk transaction. This situation is similar to the first work flow 2710 , except that the credit entity is not involved (e.g., because it is a non-risk transaction).
- the third work flow 2730 is associated with agreement definition when the compliance entity initiates a request for a new agreement on behalf of a business entity. This situation is similar to the first work flow 2710 , but the business entity is not (directly) involved. Moreover, involvement of the credit entity in the work flow may not be required in the case of a non-risk transaction.
- the fourth work flow 2740 is associated with agreement definition when the credit entity initiates a request for a new agreement on behalf of a business entity. Again, the situation is similar to the first work flow 2710 , but the business entity is not (directly) involved. Also note that, in this case, the credit entity is involved before the compliance entity.
- the fifth work flow 2740 is associated with agreement definition when a treasury entity initiates a request for a new agreement on behalf of a business entity. This similar to the first work flow 2710 , but the business entity is not (directly) involved.
- agreement modeling system controller 1000 that facilitates definition of an agreement. According to other embodiments, however, some or all of these functions are instead performed by other devices. For example, multiple devices may communicate with each other to perform the functions described herein without the use of a “controller” (e.g., a peer-to-peer model may be used). Moreover, many of the devices illustrated in FIG. 3 (including some or all of the satellite systems) may be incorporated in a single device.
Abstract
Systems and methods are provided for facilitating definition of an agreement between a party and a counter-party via an agreement modeling system. According to some embodiments, an agreement type is automatically determined based on a covered products matrix and a plurality of product types associated with an agreement (e.g., financial products associated with a transaction agreement). In addition, an agreement term may be determined in accordance with the agreement type. According to other embodiments, an indication of an agreement term is stored in association with an indication of a term date such that an applicability of the agreement term can be automatically determined based at least in part on the term date. In still other embodiments, a value associated with an agreement term is stored along with an indication of a right associated with the agreement term (e.g., via an XML data format).
Description
- The present invention relates to agreements between parties. In particular, the present invention relates to systems and methods for facilitating definition of an agreement between a party and a counter-party via an agreement modeling system.
- Typically, an agreement between a party and a counter-party is manually defined by the parties. That is, one or both of the parties manually select a type of document that appropriately reflects the substance of the agreement (e.g., a particular type of contract) and/or agreement terms to be included in the document (e.g., contract clauses). Such a manual approach, however, has a number of disadvantages.
- For example, the manual definition of an agreement can be a time consuming and error-prone process, especially when a large number of potential document types and/or potential agreement terms can be associated with the agreement. Similarly, particular parties or localities may require different document types and/or agreement terms. As a result, the parties must carefully consider the substance of the agreement in order to select the appropriate document type and/or agreement terms.
- Consider, for example, a transaction agreement associated with a number of different financial instruments (e.g., swaps and options) and financial products (e.g., equities and commodities). In this case, different combinations of financial instruments and financial products may call for different document types and/or agreement terms. Moreover, several different entities within a party (e.g., a bank's taxation department and legal department) may need to provide input to the process.
- It is known that some elements of agreement definition may be automated. For example, U.S. Pat. No. 5,692,206 entitled “Method and Apparatus for Automating the Generation of a Legal Instrument” discloses a system that automates the generation of various legal documents related to a negotiated agreement. Even this approach, however, does not address the potentially dynamic relationships that may exist between a party and a counter-party. For example, an agreement may be frequently amended to reflect new financial products or credit limits, and these amendments may be inter-related or retroactive. Such amendments are typically created as separate documents, making it difficult to ascertain the current status of an agreement, let alone the status of the agreement on a particular date in the past.
- Moreover, known systems rely on hard-coded rules, programs, and architectures to facilitate definition of an agreement. Often, however, agreements are flexible (e.g., a new contract clause may suddenly become applicable to many different document types). In addition, the kinds of documents and contract terms that should be used for a particular agreement (or a way in which existing terms will be interpreted) can change over time. Because known systems are hard-coded, they may be unable to efficiently handle the fluid environments in which many agreements are made and changed. For example, a conventional database approach in which information is stored in pre-defined tables and columns may not be an effective, long-term approach to agreement definition.
- To alleviate problems inherent in the prior art, the present invention introduces systems and methods for facilitating definition of an agreement between a party and a counter-party via an agreement modeling system.
- According to one embodiment, an agreement type is determined based on (i) a plurality of product types associated with a transaction agreement and (ii) a covered products matrix. An agreement term between a party and a counter-party is then determined in accordance with the agreement type.
- According to another embodiment, an agreement type is determined along with an agreement term. An indication is then generated based on an evaluation of the agreement type and the agreement term.
- According to another embodiment, a contract type is determined. A contract term between a party and a counter-party is then determined in accordance with the contract type.
- According to another embodiment, an agreement term is determined along with a term date associated with the agreement term. An indication of the agreement term is then stored in association with an indication of the term date, wherein an applicability of the agreement term can be automatically determined based at least in part on the term date.
- Another embodiment is directed to facilitating definition of an agreement between a party (including a first party entity and a second party entity) and a counter-party. According to this embodiment, a first agreement term is determined via the first party entity. A second agreement term is then determined via the second party based at least in part on the first agreement term.
- According to still another embodiment, an agreement term is determined. A value associated with the agreement term is then stored along with an indication of a right associated with the agreement term.
- Yet another embodiment is directed to a computer-implemented method for facilitating definition of a transaction agreement between a party and a counter-party. According to this embodiment, at least one agreement document template associated with a transaction agreement type is created. A plurality of agreement facts are determined, at least one of the agreement facts being associated with the party and/or the counter-party. An agreement document instance associated with the transaction agreement is then defined, the agreement document instance being based on the agreement document template and the plurality of agreement facts.
- One embodiment of the present invention comprises: means for automatically determining an agreement type based on a plurality of product types and a covered products matrix; and means for determining, in accordance with the agreement type, an agreement term between a party and a counter-party.
- Another embodiment comprises: means for determining an agreement type; means for determining an agreement term; and means for generating an indication based on an evaluation of the agreement type and the agreement term.
- Another embodiment comprises: means for determining a contract type; and means for determining, in accordance with the contract type, a contract term between a party and a counter-party.
- Another embodiment comprises: means for determining an agreement term; means for determining a term date associated with the agreement term; and means for storing an indication of the agreement term in association with an indication of the term date, wherein an applicability of the agreement term can be automatically determined based at least in part on the term date.
- Another embodiment comprises: means for determining a first agreement term via a first party entity; and means for determining a second agreement term via a second party entity based at least in part on the first agreement term.
- Still another embodiment comprises: means for determining an agreement term; and means for storing a value associated with the agreement term along with an indication of a right associated with the agreement term.
- Yet another embodiment comprises: means for creating at least one agreement document template associated with a transaction agreement type; means for determining a plurality of agreement facts, at least one of the agreement facts being associated with a party and/or a counter-party; and means for defining an agreement document instance associated with the transaction agreement, the agreement document instance being based on the agreement document template and the plurality of agreement facts.
- With these and other advantages and features of the invention that will become hereinafter apparent, the invention may be more clearly understood by reference to the following detailed description of the invention, the appended claims, and the drawings attached herein.
- FIG. 1 is a block diagram overview of an agreement modeling system according to an embodiment of the present invention.
- FIG. 2 is a flow chart of a method according to some embodiments of the present invention.
- FIG. 3 is a block diagram overview of an agreement modeling system according to another embodiment of the present invention.
- FIG. 4 is a client-server diagram overview of an agreement modeling system according to some embodiments of the present invention.
- FIG. 5 is a more detailed diagram of an agreement modeling system according to an embodiment of the present invention.
- FIG. 6 is an information architecture overview associated with an agreement modeling system according to some embodiments of the present invention.
- FIG. 7 is a flow chart of a method for storing information associated with an agreement modeling system according to some embodiments of the present invention.
- FIG. 8 illustrates various representations of agreement modeling system information according to an embodiment of the present invention.
- FIG. 9 is a flow chart of an agreement modeling system method according to some embodiments of the present invention.
- FIG. 10 is a block diagram of an agreement modeling system controller according to an embodiment of the present invention.
- FIG. 11 is a tabular representation of a portion of an agreement information database according to an embodiment of the present invention.
- FIG. 12 is a flow chart of a method for establishing a time perspective via an agreement modeling system according to some embodiments of the present invention.
- FIG. 13 illustrates agreement time perspective according to one embodiment of the present invention.
- FIG. 14 is a flow chart of a method associated with a covered products matrix according to some embodiments of the present invention.
- FIG. 15 illustrates an example of a covered products matrix according to an embodiment of the present invention.
- FIG. 16 illustrates another example of a covered products matrix according to an embodiment of the present invention.
- FIG. 17 is a flow chart of another method associated with a covered products matrix according to some embodiments of the present invention.
- FIG. 18 is a flow chart of a method for facilitating definition of a transaction agreement between a party and a counter-party according some embodiments of the present invention.
- FIGS. 19A and 19B are block diagrams of agreement modeling system functions, applications, and interactions according to some embodiments of the present invention.
- FIG. 20 is a block diagram of agreement creation interactions according to some embodiments of the present invention.
- FIG. 21 is a block diagram of document creation interactions according to some embodiments of the present invention.
- FIGS. 22 through 24 illustrate client displays associated with an agreement according to an embodiment of the present invention.
- FIG. 25 is a flow chart of a method for facilitating definition of an agreement between a party (including a first party entity and a second party entity) and a counter-party according some embodiments of the present invention.
- FIGS. 26A and 26B are a flow chart of another method for facilitating definition of an agreement according to some embodiments of the present invention.
- FIG. 27 illustrates some examples of agreement definition via multiple entities according to an embodiment of the present invention.
- Embodiments of the present invention are associated with systems and methods for facilitating definition of an “agreement” between a party and a counter-party via an agreement modeling system. As used herein, the term “agreement” may refer to any arrangement between the parties. An agreement may be, for example, a legal contract defining a set of rights that exist between the parties, such as an INTERNATIONAL SWAP DEALERS ASSOCIATION® (ISDA®) master agreement associated with financial instruments and products. Note that a single agreement may be associated with more than two parties (e.g., three parties may enter into a legal contract). Also note that an agreement may or may not be legally binding (e.g., an agreement may simply reflect an informal understanding between parties).
- In addition, as used herein the terms “party” and “counter-party” can refer to any entity associated with an agreement. A party may be, for example, a business, a business entity (e.g., a department within a business), or a person.
- Agreement Modeling System Overview
- Turning now in detail to the drawings, FIG. 1 is a block diagram of an
agreement modeling system 100 according to an embodiment of the present invention. As shown in FIG. 1, an agreementmodeling system controller 1000 may interact with aclient device 10. For example, a user may input information associated with a transaction agreement via theclient device 10. Theclient device 10 may then transmit appropriate information to the agreementmodeling system controller 1000, which in turn may store and/or interpret the information. Similarly, a user may request information about an agreement via the client device 10 (e.g., by performing a query associated with a transaction agreement). - FIG. 2 is a flow chart of a method according to some embodiments of the present invention. The flow charts in FIG. 2 and the other figures described herein do not imply a fixed order to the steps, and embodiments of the present invention can be practiced in any order that is practicable. The method shown in FIG. 2 may be performed, for example, by the agreement
modeling system controller 1000. - At202, a contract type is determined. For example, a user may input information via the
client device 10 indicating one or more financial products that will be associated with the contract. The agreementmodeling system controller 1000 may then determine an appropriate contract type based on those financial products. - At204, a contract term between a party and a counter-party is determined in accordance with the contract type. For example, based on the contract type determined at 202, the agreement
modeling system controller 1000 may determine one or more appropriate contract terms (e.g., a contract clause or a credit limit to be associated with a particular financial product). - Agreement Modeling System Architecture
- FIG. 3 is a block diagram overview of an
agreement modeling system 300 according to another embodiment of the present invention. As in FIG. 1, the agreementmodeling system controller 1000 communicates with theclient device 10. As used herein, devices (such as the agreementmodeling system controller 1000 and the client device 10) may communicate via acommunication network 20, such as a Local Area Network (LAN), a Metropolitan Area Network (MAN), a Wide Area Network (WAN), a proprietary network, a Public Switched Telephone Network (PSTN), a Wireless Application Protocol (WAP) network, a wireless LAN (e.g., in accordance with the Institute of Electrical and Electronics Engineers 802.11 standard), a Bluetooth network, an Infrared Radiation (IR) network, and/or an IP network such as the Internet, an intranet or an extranet. As used herein, the term “communications” can refer to wired and/or wireless communications as appropriate. Note that the devices shown in FIG. 3 need not be in constant communication. For example, the agreementmodeling system controller 1000 may communicate with aclient device 10 on an as-needed or periodic basis. - Although a single agreement
modeling system controller 1000 is shown in FIG. 3, any number of agreementmodeling system controllers 1000 may be included in theagreement modeling system 300. Similarly, any number ofclient devices 10, or any other device described herein, may be included in theagreement modeling system 300 according to embodiments of the present invention. - The agreement
modeling system controller 1000 and theclient devices 10 may be any devices capable of performing the various functions described herein. Aclient device 10 may be, for example: a Personal Computer (PC), a portable computing device (e.g., a laptop computer), a Personal Digital Assistant (PDA), or a dedicatedagreement modeling system 300 terminal. Note that theclient device 10 may be associated with a full-blown workstation application or a thin-client browser-based application. - According one embodiment, a user enters information associated with an agreement via the
client device 10. The agreement may be, for example, associated with financial transactions between a party and a counter-party. In this case, the user may enter information about the party, the counter-party, and/or the financial transactions via the client device 10 (e.g., by selecting a number of different financial instruments that will be involved in transactions between the parties). - Information associated with the agreement may then be transmitted from the
client device 10 to the agreementmodeling system controller 1000 via thecommunication network 20, and the agreementmodeling system controller 1000 may process the information to facilitate definition of the agreement. According to one embodiment, theagreement modeling system 1000 also communicates with one or more satellite systems, such as abusiness system 30, alegal system 40, acompliance system 50, acredit system 60, atreasury system 70, and/or anoperations system 80 to facilitate definition of the agreement. For example, the agreementmodeling system controller 1000 may review information provided by the user and determine that the agreement requires approval via acredit system 60. Note that the agreementmodeling system controller 1000 may communicate with theclient device 10 and one or more satellite systems via a single communication network or via different communication networks. - FIG. 4 is a client-server diagram overview of an
agreement modeling system 400 according to some embodiments of the present invention. As shown in FIG. 4, adatabase server 1002 communicates with a number of middle-tier servers 1004. In turn, each middle-tier server 1004 communicates with one ormore client devices 12. - The
database server 1002 may include (or communicate with) an agreement modeling system database, such as a database that stores agreement information. Thedatabase server 1002 may also include Java and Structured Query Language (SQL) stored procedures along with User Defined Functions (UDFs). Thedatabase server 1002 can act as a “back-end” to theagreement modeling system 400 and manage user connections (e.g., by invoking stored procedures in and out, validating client logons, establishing client access rights, and/or maintaining a list of connected clients). Thedatabase server 1002 may also perform concurrency management (e.g., by responding to client timeout or disconnect notifications from middle-tier servers 1004, releasing check-out locks, updating access modes, and managing access modes and check-out locks on agreements, facts, or fact sets as described, for example, with respect to FIG. 6). In addition, thedatabase server 1002 may manage Extensible Markup Language (XML) and Application Program Interface (API) information (e.g., by managing special Java XML API entry point stored procedures, interpreting incoming XML streams, performing appropriate XML operations, returning appropriate response XML packets, and/or retrieving agreement information using XML streams). - The middle-
tier servers 1004 may comprise, for example, SILVERSTREAM® or WEBLOGIC® servers that manage user connections (e.g., via special login and logout servlet interfaces and/or by establishing logins and logouts with the database server 1002). The middle-tier servers 1004 may also perform session management (e.g., by handling timeouts and disconnects and notifying thedatabase server 1002 when aclient device 12 has timed-out or disconnects) and/or manage database connections (e.g., by optimizing and pooling database connections and providing XML user and session identification packets associated with XML packets sent to the database server 1002). The middle-tier servers 1004 may also perform XML API management (e.g., using a special XML API servlet interface that serves as a pass-through for XML packets sent to thedatabase server 1002 via calls to a Java stored procedure). - A
client device 12 may, for example, control user functionality (e.g., by supporting applicable user interactions). Theclient device 12 may also perform session management (e.g., by providing user login and logout capability, managing a physical connection including a connection status notification to a user, and issuing a logout when appropriate) and manage XML API interactions (e.g., by interacting with an XML API back-end via correctly formed XML packets, and/or managing incoming XML API response packets returned from XML API calls). - This hierarchical arrangement (e.g., having a client tier, a middle tier, and a database tier) may let a significant number of
client devices 12 access and utilize thedatabase server 1002. - FIG. 5 is a more detailed diagram of an
agreement modeling system 500 according to one embodiment of the present invention. As shown in FIG. 5, adatabase server 1006 communicates with a middle-tier server 1008. In turn, the middle-tier server 1008 communicates with aclient device 14. - The
database server 1006 may, for example, provide support for an API via stored procedures and UDFs. Thedatabase server 1006 may also manage persistence of agreement information and API states for theagreement modeling system 500 in a database. - The middle-
tier server 1008 may communicate with thedatabase server 1006 via a number of server-side language managers, such as an agreement and/or a utility language manager. The server-side language managers may, for example, implement interfaces similar to those provided on the client side to provide specific API functionality. These managers may be registered with an execution manager indicating supported interfaces. Instances of the server-side language managers may be instantiated to service incoming API method calls. The managers may also provide implementation of the API method calls by interacting directly with the agreement database via stored procedure calls. - The server-side language managers may communicate with the execution manager via a server-side base language manager that routes method calls and provides implementation of common API methods.
- The execution manager may exchange information with a communication manager associated with the
client device 14 via a Hyper-Text Transfer Protocol (HTTP) connection. In addition, the execution manager may be delegated to by middle-tier servlets that process HTTP requests and responses. The execution manager may also handle all incoming API “method calls” and interact with the service-side base language manager to service those calls. Moreover, the execution manager may be responsible for the registration of server-side language managers, “de-serializing” XML method call packets, routing methods to the appropriate registered server-side language manager, “serializing” return values or errors into XML packets, and/or forwarding return values or errors back to the client device via an HTTP response. - The communication manager in the
client device 14 interacts with a client-side base language manager and the middle-tier servlets. The communication manager is responsible for managing the connection with the server, the invocation of method calls by passing a stream to the server, the receiving return values or errors back as a stream, and/or propagating up return values or errors to the language manager layer. Both synchronous and asynchronous method calls may be supported at this layer. - The client-side base language manager may define a base class from which extended client-side language managers are derived. Common functionality may be implemented in the base class, including a standard set of API method calls. The client-side base language manager may also be responsible for interacting with the communication manager to process method calls forwarded by derived client-side language managers.
- The client side base language manager communicates with a number of client-side language managers, such as an agreement and/or a utility language manager. The client-side language managers may implement interfaces providing specific API functionality to the
client device 14. The API methods in the client application may be called like any other local method. The derived client-side language managers may be responsible for serializing method calls into XML packets and/or interacting with the client-side base language manager to process the call. - Agreement Modeling System Information Architecture
- In order to define an agreement, the facts that are associated with the agreement need to be captured. However, different agreements may not be equal in terms of data content, and thus a flexible database design (e.g., capable of capturing a variety of data while maintaining relative data context) may be required to allow for effective and reliable agreement definition, generation, and/or utilization (e.g., via agreement information data queries).
- To achieve this end, the agreement modeling system may utilize a modeling language by which agreement content and context can be described without re-coding the database. FIG. 6 is an information architecture overview associated with one such embodiment of the present invention. As can been in FIG. 6, the information architecture is associated with a hierarchical view of agreement information. In particular, an
agreement 602 is viewed as a set ofrelated documents 604. Eachdocument 604 comprises one or more fact sets 606, and each fact set 606 includes a number of related facts 608 (e.g., single pieces of information). Thus, the information architecture may apply structure to information through the constructive use of well-known fact sets 606 and data definitions that are applied tofacts 608, and taken together, data context may be maintained. - According to one embodiment, the
agreement 602 is associated with an “original” documentinstance containing facts 608 that define theagreement 602 upon creation. As additional information is created (e.g., theoriginal agreement 602 is amended),additional documents 604 may be added to define thefacts 608 that apply at particular points in time. - For example, a
document 604 may be created that “overrides” existingfacts 608 in anagreement 602 for a specified period of time and/or that addsnew facts 608 that extend existingfacts 608. In either case, the addeddocument 604 may now be considered to determine a complete set of agreement facts 608 (e.g., via an agreement modeling system query). - According to one embodiment,
documents 604 may be categorized according to a single document type name and any number of document type facts that further refine the documents classification. By way of example, the document type name may indicate a basic category of agreement types (e.g., a financial instrument swap agreement or an over-the-counter financial instrument agreement) and the document type fact (or facts) may further categorize a document's relationship to an agreement (e.g., a credit support annex or an amendment to an existing agreement 602). - A
document 604 contains instances of fact sets 606, and afact 608 may belong to an instance of a fact set 606. Fact set definitions (in addition to document definitions) may exist outside of any agreement, and their definition and fact content may be described via an agreement modeling language. - By way of example, a
fact 608 may be associated with a party name, a party address, a term date, a country of origin, an indication of governing law (e.g., “Delaware law applies to all transactions associated with this agreement”), or any other information associated with an agreement. A fact set 606 may comprise, for example, a counter-party fact set including a counter-party name and address. - Note that fact sets606 can be single-instance or multi-instance. In either case, a
fact 608 belonging to a fact set 606 may be related to theother facts 608 in that fact set 606. A multi-instance fact set 606 enables the repeated instantiation of the same set offacts 608, typically with different values being associated with the different instantiatedfacts 608. An instance of amulti-instance fact 606 set is analogous to a row of data in a conventional database table, and thefacts 608 are analogous to columns. Note, however, that the table is not statically defined—rather it is dynamically defined via the agreement modeling language. - A
fact 608 in the agreement modeling system may have pre-defined attributes that describe the fact's nature and meaning. For example, eachfact 608 may have an associated data type that defines a set of potential values and/or data input behavior. Afact 608 may be considered “internal” or “external,” and external facts may map to information in other databases (i.e. external databases). In addition, other attributes may be applied tofacts 608 to help to define context. - FIG. 7 is a flow chart of a method for storing agreement information according to some embodiments of the present invention. At702, an agreement term is determined. For example, the agreement
modeling system controller 1000 may determine one or more facts associated with an agreement (i.e., facts indicating an agreement term) based on information provided via aclient device 10. According to another embodiment, the agreementmodeling system controller 1000 determines the agreement term by accessing other information (e.g., via a covered products matrix as described with respect to FIGS. 14 through 16). - At704, a value associated with the agreement term is stored along with an indication of a right associated with the agreement term. To provide flexibility, the value may be stored via an extensible agreement modeling system language. For example, an XML or Standard Generalized Markup Language (SGML) data format may be used to store information as follows:
<Agreement> <Document> <FactSet> <Fact> </Fact> . . . </FactSet> . . . </Document> . . . </Agreement> - Such an approach may let the system model dynamic information (e.g., document and fact set information) and facilitate communication of dynamic agreement information between a client and a server. In addition, the implementation may be technology neutral (e.g., the information may be provided to or accessed by a number of different technologies). Moreover, facts may be associated with attribute information, such as a data name, a data prompt, a data type, a security attribute, and/or a display attribute.
- FIG. 8 illustrates various representations of agreement modeling system information according to an embodiment of the present invention. In particular, the relationships between an
information architecture 802, anXML representation 804, and adisplay 806 are illustrated. For example, document level information may be mapped to a particular XML representation (e.g., <Document spec=“ORIGINAL|MASTER” id=“2” . . . >, which in turn may be rendered by an agreement application display engine (e.g., via a document list pane and/or an active document information pane). - Agreement Modeling System Operation
- FIG. 9 is a flow chart of a method according to some embodiments of the present invention. At902, information associated with an agreement is gathered. For example, the agreement
modeling system controller 1000 may gather information associated with a financial transaction agreement between a party and a counter-party via one ormore client devices 10 and/or satellite systems. - At904, it is determined if a new agreement is required. According to one embodiment, a request for a new agreement may be generated by a satellite system, such as the
business system 30, thecredit system 60, and/or thetreasury system 70. - By way of example, a user associated with the
business system 30 may populate a new agreement request form via a Web-based interface provided by theagreement modeling system 1000. The new agreement request form may include, for example, a set of “required” information, such as: a name of a sales person covering an account, a selected entity master (e.g., via a drop-down list of party entities that the counter-party is contemplating doing business with), a business desk (e.g., an indication of “Fixed Income,” “Equity,” or “Commodities” which may be automatically generated based on a user identifier), a counter-party legal name (e.g., selected from a drop-down list), contact information of a person with whom documentation will be exchanged (e.g., a name, a phone number, and/or a facsimile number), one or more products to be traded (e.g., associated with a covered products matrix), an indication of whether or not the agreement is bilateral (e.g., two-way agreements may require special processing via the treasury system 70), an anticipated trade date, an indication of whether or not the agreement will be used as a marketing tool. - The new agreement request form may also include information that will be required when appropriate (e.g., based on the particular agreement being requested), such as a type of agreement (e.g., selected from a drop-down list) and/or an investment advisor. The new agreement request form may also include optional information, such as an electronic mail address associated with the counter-party.
- As indicated above, some information may be selected by a user via a drop-down list (e.g., a counter-party name or identifier). In some cases, however, the desired information may not be present in the drop-down list (e.g., when a new counter-party is desired). In this case, a user may be asked to complete another form (e.g., a new counter-party request form) or he or she may simply enter the information manually (e.g., via free form text). Also note that one or more satellite systems may be involved in this process (e.g., the
compliance system 50 may approve new counter-parties). - After the new agreement request form is submitted by the user, the agreement
modeling system controller 1000 determines if a new agreement is actually required at 904. For example, the agreementmodeling system controller 1000 may execute a query to ensure that there are no other existing agreements in place and return the results of the query to the user (e.g., by indicating that “there are existing agreements that cover this request”). If no new agreement is required at 904 (e.g., an appropriate existing agreement is found by the agreement modeling system controller 1000), one or more amendments to the existing agreement may be facilitated at 906. For example, the agreementmodeling system controller 1000 or thecompliance system 50 may determine that an existing agreement can be used to cover a transaction by broadening a compliance covered products scope term in the existing agreement. In this case, an electronic mail message may be transmitted to thelegal system 40 asking if the agreement scope can be broadened accordingly. Thelegal system 40 may then indicate to thebusiness system 30 that the transaction can be covered under the existing agreement. On the other hand, thelegal system 40 may instead indicate that a new agreement is required. - If a new agreement is required at904 (e.g., no appropriate existing agreement is found by the agreement modeling system controller 1000), the new agreement request form is processed by the agreement
modeling system controller 1000. According to one embodiment, the processing of the new agreement request form also involves one or more satellite systems. For example, thecompliance system 50 may receive the request via an automated workflow and provide information as required. In this case, thecompliance system 50 may advise thelegal system 40 as to the types of products the counter-party is authorized to trade, and with which party entity the counter-party may trade these products. - To make such a decision, the
compliance system 50 may need to access information about the agreement, such as the counter-party name or identifier, a master agreement type, a current status of the master agreement type, a date of agreement, a document identifier, an investment advisor, and/or a security agreement type. - In addition to accessing information, the
compliance system 50 may define facts for the agreement, such as: a compliance officer name responsible for the account, a party entity approved for the business, a covered products matrix indicating the authorized products the counter-party can or can't trade, and/or one or more supporting authority documents. - When the
compliance system 50 finishes providing information, the form may be forwarded to the credit system 60 (e.g., if the agreement is associated with a risk transaction) to provide still more information. Such information may include, for example, collateral terms such as: a credit officer name responsible for the account, terms of a collateral agreement (e.g., bilateral, party post, or counter-party post), an independent amount (e.g., an initial margin percentage or dollar amount associated with notional amount), a threshold amount (e.g., a trigger value associated with a specified dollar amount or a ratings table), a minimum transfer amount, a rounding amount, and/or a base currency. - The
credit system 60 may also provide non-collateral terms, such as: default information (e.g., bankruptcy information or credit event upon merger information), a cross acceleration threshold amount for the counter-party, and/or one or more credit-related additional termination events (e.g., adequate assurance, amendment of constituent documents, break clause, credit rating downgrade, decline in partners capital, governmental moratorium on debt declared, investment advisor event, material adverse change, modification to guaranty, net asset value information, ownership maintenance, redemption of notes, termination of trust under trust agreement, termination rights linked to separate agreement, transactions not covered by guaranty and/or guarantor, or withdrawal of general partners or key employees). - The
credit system 60 may also indicate one or more credit support documents referenced under the agreement, such as: a comfort letter, a deed poll guarantee, an indemnity agreement, a Keepwell agreement, a letter of commitment, a letter of credit, a security trust deed, a senior facility agreement, a supplemental trust deed, a support agreement, and/or a swap surety bond/insurance policy. - In addition to the
credit system 60, thetreasury system 70 may provide information associated with bilateral agreements, such as an indication of approval, a threshold amount, a notional amount, eligible collateral types (e.g., United States Treasury bills, highly liquid pools, AAA bonds, residuals, commercial paper, investment grade corporate instruments, preferred stock, municipals, emerging market debt, Brady bonds, high yields, non-distressed issues, distressed issues, bank debt, par, whole loans, residential, commercial, and/or short-term mortgage backed bank notes), equities (e.g., United States or United Kingdom listed equities, foreign convertibles-investment grade, foreign convertibles-high yield, listed mutual funds, rights and warrants, or options), commodities (e.g., metals or energy), interest paid on cash collateral, base currency on cash, tri-party custodial relationships, notification time, amendments to transfer provision (e.g., after approval by the legal system 40). - According to one embodiment, the processing of multiple new agreement request forms may be prioritized (e.g., based on a date on which a request was made, a date associated with a pending trade, or a number of requests in a queue for a given business area).
- Referring again to FIG. 9, after it is determined at904 that a new agreement is needed, an agreement is drafted by the agreement
modeling system controller 1000 at 908. For example, the agreementmodeling system controller 1000 may use a rule set to route the new agreement request form to an appropriate functional group within thelegal system 40 based on a product type and/or a party entity. Moreover, an agreement type (e.g., an ISDA® master agreement schedule, a club letter, or a credit support annex in accordance with New York law) may be determined based on one or more rules by thelegal system 40 or thebusiness system 30. According to one embodiment, a user has the ability to override an agreement type chosen by the system. - According to some embodiments, the
legal system 40 can access the generated agreement on-line to review the agreement's structure and to make revisions, if required. Thelegal system 40 may also prepare the agreement for transmission. If desired, thelegal system 40 may be prevented from changing or over-riding data that was originally provided via the new agreement request form. - The agreement
modeling system controller 1000 may then automatically generate the agreement and, according to one embodiment, any supporting documents that accompany the agreement (e.g., a power of attorney, a legal opinion, a pre-executed request guarantee, and/or a cover letter). - The user or the agreement
modeling system controller 1000 then forwards the agreement to the counter-party at 910. For example, a user may manually print hard copies of the agreement to send via a delivery service (e.g., FED EX®). According to another embodiment, the agreementmodeling system controller 1000 sends a facsimile or an electronic message attachment of the agreement in an unalterable format (e.g., a “pdf” file) to the counter-party. In this case, the system may also provide the user with an automated notification that the document has been successfully transmitted. According to another embodiment, the agreement is published via a Uniform Resource Locator (URL) address that enables the counter-party to securely view the agreement. - According to one embodiment, the agreement
modeling system controller 1000 instead determines that an agreement will not be automatically generated. This may be the case, for example, when a data field in the new agreement request form requires a change (e.g., a name change or a policy change). Similarly, it may be determined that a counter-party form of the agreement will be used, that supervisory review is required (e.g., based on a functional group associated with the agreement), or that thebusiness system 30 has asked that the generation or transmission be postponed. - The counter-party may the respond to the draft agreement (e.g., by proposing changes to the draft agreement). For example, the counter-party may return a hard copy of an altered agreement. In this case, the hard copy may be scanned and stored via an Optical Character Recognition (OCR) application. The counter-party may instead contact the party via telephone to verbally confirm the terms of the agreement or advise of any discrepancies between the counter-party's view and party's view of the agreement. In this case, the agreement
modeling system controller 1000 may store the name of the person who called and the time, date, and substance of the conversation. - Any changes proposed by the counter-party are then reviewed at912. For example, discrepancies may be determined and routed to the appropriate party entities for reconciliation (e.g., by routing the information to an appropriate information owner based on a functional group or a document type).
- If the changes proposed by the counter-party do not require further negotiation at914 (or the counter-party has simply approved the draft agreement), the system waits for approval by the party at 916. If the changes proposed by the counter-party do require further negotiation at 914, negotiations continue until the differences are resolved at 918.
- When both the counter-party and the party (including any entities associated with the party) have approved the agreement, a final execution document is prepared at920 and sent to the appropriate parties for execution at 922. For example, two hard copies of a fully negotiated ISDA® schedule and boiler-plate may be printed and forwarded to the counter-party for signature. In addition, a cover letter with instructions to the counter-party may be automatically generated along with any required tax documents.
- The counter-party can then return the signed agreement via hard copy, electronic mail, facsimile, or a URL, together with any supporting documentation (e.g., a power of attorney). The date that the agreement was executed may be recorded by the agreement
modeling system controller 1000 along with, for example, a date on which the agreement is effective (which may or may not be the same as the execution date). Any subsequent amendments to the agreement may then be made at 906. - Agreement Modeling System Controller
- FIG. 10 illustrates an agreement
modeling system controller 1000 that is descriptive of the devices shown, for example, in FIGS. 1 and 3 according to some embodiments of the present invention. The agreementmodeling system controller 1000 comprises aprocessor 1010, such as one or more INTEL® Pentium® processors, coupled to acommunication device 1020 configured to communicate via a communication network (not shown in FIG. 10). Thecommunication device 1020 may be used to communicate, for example, with one ormore client devices 10 and/or satellite devices. - The
processor 1010 is also in communication with aninput device 1040. Theinput device 1040 may comprise, for example, a keyboard, a mouse or other pointing device, a microphone, knob or a switch, an IR port, a docking station, and/or a touch screen. Such aninput device 1040 may be used, for example, to enter information (e.g., agreement information). - The
processor 1010 is also in communication with anoutput device 1050. Theoutput device 1050 may comprise, for example, a display (e.g., a display screen), a speaker, and/or a printer. Theoutput device 1050 may be used, for example, output agreement information (e.g., a final version of an agreement to be executed or a date on which a particular agreement became effective). - The
processor 1010 is also in communication with astorage device 1030. Thestorage device 1030 may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., magnetic tape and hard disk drives), optical storage devices, and/or semiconductor memory devices such as Random Access Memory (RAM) devices and Read Only Memory (ROM) devices. - The
storage device 1030 stores aprogram 1015 for controlling theprocessor 1010. Theprocessor 1010 performs instructions of theprogram 1015, and thereby operates in accordance with the present invention. For example, theprocessor 1010 may receive agreement information, process agreement information (e.g., in accordance with one or more rules), and/or output agreement information. - According to one embodiment, the
processor 1010 automatically determines an agreement type based on a plurality of product types and a covered products matrix. Theprocessor 1010 then determines, in accordance with the agreement type, an agreement term between a party and a counter-party. - According another embodiment, the
processor 1010 determines an agreement type and an agreement term. Theprocessor 1010 then generates an indication based on an evaluation of the agreement type and the agreement term. - According another embodiment, the
processor 1010 determines a contract type. Theprocessor 1015 then determines, in accordance with the contract type, a contract term between a party and a counter-party. - According another embodiment, the
processor 1010 determines an agreement term and a term date associated with the agreement term. Theprocessor 1010 then stores an indication of the agreement term in association with an indication of the term date, wherein an applicability of the agreement term can be automatically determined based at least in part on the term date. - According another embodiment, the
processor 1010 determines a first agreement term via a first party entity and, based at least in part on the first agreement term, determines a second agreement term via a second party entity. - According still another embodiment, the
processor 1010 determines an agreement term stores a value associated with the agreement term along with an indication of a right associated with the agreement term. - According yet another embodiment, the
processor 1010 creates at least one agreement document template associated with a transaction agreement type. Theprocessor 1010 then determines a plurality of agreement facts, at least one of the agreement facts being associated with a party and/or a counter-party. An agreement document instance associated with the transaction agreement is then defined by theprocessor 1010, the agreement document instance being based on the agreement document template and the plurality of agreement facts. - The
storage device 1030 also stores anagreement information database 1100. The illustration and accompanying description of this database is exemplary, and any number of other database arrangements could be employed besides those suggested by the figure. - Referring to FIG. 11, a table represents the
agreement information database 1100 according to one embodiment of the present invention. The table includes entries identifying agreement information. The table also defines 1102, 1104, 1106, 1108, 1110 for each of the entries. In particular, the table defines anagreement information identifier 1102, aninformation type 1104, anentry date 1106, aneffective date 1108, and anexpiration date 1110. The information in theagreement information database 1100 may be created and updated, for example, by the agreementmodeling system controller 1000, aclient device 10, and/or a satellite device. - The
agreement information identifier 1102 may be, for example, an alphanumeric code associated with an agreement term (e.g., an agreement, a document, a fact set, or a fact). Theinformation type 1104 describes the agreement information. For example, the agreement information may comprise an original master agreement or an amendment to an existing master agreement. - The
agreement information database 1100 also stores one or more term dates associated with the agreement information. For example, theentry date 1106 indicates when the agreement information was stored in the database. Other term dates indicate a period during which a particular agreement term applies. For example, an agreement term may apply from theeffective date 1108 to theexpiration date 1110. Note that theeffective date 1108 may be prior to (or after) theentry date 1106 associated with an agreement term. - Agreement Modeling System Time Perspective
- FIG. 12 is a flow chart of a method for establishing a time perspective according to some embodiments of the present invention. At1202, an agreement term is determined. For example, the agreement
modeling system controller 1000 may determine an agreement type, document, fact set, and/or fact based on information received via aclient device 10. - At1204, a term date associated with the agreement term is determined. For example, the agreement
modeling system controller 1000 may determine the term date based on information received via aclient device 10. As illustrated in FIG. 13, the term date may be associated with a term period during which the agreement term is applicable. The term date may be, for example, an effective date after which the agreement term is applicable or an expiration date after which the agreement term is not applicable. The term date may also be a term period (e.g., indicating that the agreement term is to be applicable for one year from a date on which an agreement document was signed). The term date may also be an entry date (e.g., a date on which information about the agreement term was entered into the agreement modeling system 100). - At1206, an indication of the agreement term is stored in association with an indication of the term date so that an applicability of the agreement term can be automatically determined based at least in part on the term date. According to one embodiment, the agreement
modeling system controller 1000 stores the appropriate information in theagreement information database 1100. The agreementmodeling system controller 1000 may also store, in association with the agreement term, an indication of at least one supporting agreement document (e.g., a pointer, a word processing file, or an electronic image file associated with a supporting agreement document). For example, a document identifier may be stored to let a user quickly access an agreement document that defines the agreement term and/or the term date. - Consider, for example, an agreement that defines a maximum amount of credit that will be extended from a party to a counter-party. The agreement
modeling system controller 1000 may store the amount of credit along with an expiration date (e.g., a date after which credit will not be extended to the counter-party). - Referring again to FIG. 13, note that information about an agreement term may be entered into the agreement modeling system100 (i.e., on the entry date) after the agreement term has expired (i.e., the expiration date). Similarly, an entry date may be prior to the effective date of the agreement term. Of course, the entry date may also fall between the effective date and the expiration date. In any case, a user at a client device can query the agreement
modeling system controller 1000 to determine if an agreement term is applicable on a particular date (e.g., the current date or any other “query” date of interest to the user). - Agreement Modeling System Covered Products Matrix
- FIG. 14 is a flow chart of a method associated with a covered products matrix according to some embodiments of the present invention. The method may be performed, for example, by the agreement
modeling system controller 1000 and may be associated with a transaction agreement defining a plurality of product types (e.g., a number of different financial products) and instruments (e.g., a number of different financial instruments). - At1402, an agreement type is automatically determined based on the plurality of product types (or instruments) and a “covered products matrix.” As used herein, the phrase “covered products matrix” may refer to, for example, any stored indication of transaction instruments (e.g., swaps, options, and forwards) and product types (e.g., stocks, bonds, and credit derivatives) in connection with a particular agreement. Note that the stored information does not necessarily need to be in the form of a matrix or an array.
- The agreement type determined at1402 may be associated with, for example, a set of rights between the party and the counter-party, a legal contract, a product type, a monetary amount, and/or a transaction instrument. According to one embodiment, the agreement type comprises a document type name (e.g., an ISDA® master agreement type) and one or more document type facts (e.g., further characterizing the document type).
- One example of a covered products matrix is illustrated in FIG. 15. As shown in FIG. 15, an agreement may be associated with a number of different financial products. For example, an agreement may be associated with an equity instrument (e.g., a stock or index instrument), a fixed income instrument (e.g., a bond, a bank loan, or a credit derivative), and/or a commodity instrument (e.g., a precious metals instrument or a wheat commodity instrument). For each financial product, the agreement may further be associated with one or more financial instruments (e.g., a warrant or a buy-call option).
- By way of example, a user may indicate that a particular agreement is going to be associated with (i) buy and sell options for gold commodities and (ii) swaps for silver commodities (i.e., as indicated as “Y” in FIG. 15). Based on this information, an appropriate agreement type may be determined by the agreement
modeling system controller 1000. - At1404, an agreement term between the party and the counter-party is determined in accordance with the agreement type. For example, the agreement
modeling system controller 1000 may determine a number of default agreement terms (e.g., default credit limits) associated with a particular agreement type. In general, the agreement term may be associated with, for example, a right between the party and the counter-party, a legal contract term, a product type, a monetary amount, and/or a transaction instrument. - Consider the covered products matrix illustrated in FIG. 16. As can be seen, the agreement is associated with (i) swaps and options for metal commodities and (ii) options for energy commodities. Based on these parameters, the agreement
modeling system controller 1000 may determine an appropriate agreement type and populate a document with appropriate terms and parameters for these types of transactions. - In general, the covered product matrix may be associated with any number of product types, such as equity products, stock products, index products, fixed income products, bond products, bank loan products, whole loan products, interest rate products, credit derivative products, commodity products, metal products, energy products, agriculture products, and/or any other type of product. Similarly, the covered product matrix may be associated with any number of transaction instruments, such as swap instruments, option instruments, buy instruments, sell instruments, call instruments, put instruments, forward instruments, pre-paid forward instruments, spot instruments, repurchase agreement instruments, loan instruments, warrant instruments, a contract for differences instrument, and/or any other type of instrument.
- Moreover, the covered products matrix may indicate when a particular financial instrument is approved (or disapproved) with respect to an agreement between a party and a counter-party. Also note that the covered products matrix may indicate if either of these items are “under investigation” (e.g., approval or disapproval is pending) or “not contemplated” (e.g., by the party or the counter-party). Similarly, the covered products matrix may indicate compliance authorization information, default information, party or counter-party information, legal information, and/or master agreement information.
- The agreement term may be automatically determined at1404 by defining the agreement term based on a pre-stored default transaction term (e.g., a “best practices” transaction term). The agreement term may also be automatically determined by defining the agreement term based on information receive from a user (e.g., via a client device 10) or a legacy agreement system.
- According to another embodiment, the agreement term is also based on information receive from a satellite system. For example, the agreement term may be based on input received from a
business system 30, alegal system 40, acompliance system 50, acredit system 60, atreasury system 70, and/or anoperations system 80. - The covered products matrix may set the scope of a particular agreement between a party and a counter-party. From a
compliance system 50 perspective, an individual covered products matrix may exist for each “entity pair” (i.e., a party-counter-party pair). From alegal system 40 perspective, a covered products matrix may exist for each agreement, and there may be multiple covered product matrices for a single entity pair. In this case, the agreementmodeling system controller 1000 may ensure that this does not result in over-lapping coverage. - According to one embodiment, there are multiple layers of information associated with each intersection in the covered products matrix. For example, there may be an “authorized scope” layer that captures approval of the
compliance system 50 regarding which products a given counter-party is allowed to trade. According to one embodiment, when thecompliance system 50 indicates an authorized scope, the agreementmodeling system controller 1000 defaults certain products to “no” based on a pre-defined rule. For example, if a new authorized scope entry is created for a particular counter-party, the agreementmodeling system controller 1000 may default all foreign exchange products to “no” since thecompliance system 50 does not typically approve foreign exchange products with that particular counter-party. According to one embodiment, an operator may override these defaults determinations. - Based on authority documents and other relevant information, the
compliance system 50 may mark appropriate products with a “yes,” indicating that those products may be traded with the counter-party. Thecompliance system 50 may also have the ability to mark products with a “no” (indicating disapproval) or “in progress” indicating that the product is in the process of being considered. All other boxes may remain blank indicating that the product has not been (and is not being) considered. - With respect to the
legal system 40, there may also be a “document scope” layer that captures a range of products that could possibly be covered by a master agreement (e.g., according to a court of law). According to one embodiment, when a new master agreement is created, the agreementmodeling system controller 1000 use a default document scope if the agreement type in question is always limited to a certain subset of products. A user may also over-ride these default values. - There may also be an “approved scope” layer that captures the products for which
legal system 40 would like to use a given master agreement. For example, thelegal system 40 may define for each master agreement a set of trades for which that master agreement should be used. This set of trades may be a subset of the document scope, and the document scope may therefore be defined before the approved scope. According to one embodiment, the approved scope is limited to a subset of the authorized scope. - FIG. 17 is a flow chart of another method associated with a covered products matrix according to some embodiments of the present invention. At1702, an agreement type is determined. At 1704, an agreement term is determined. The agreement type and agreement term may be determined via any of the methods described herein (e.g., user input, default values, or satellite systems).
- The agreement type and the agreement term are then evaluated, resulting in an indication being generated at1706. For example, the transaction agreement may associated with a plurality of financial product types. In this case, the evaluation may comprise evaluating the agreement type and the agreement term based on the plurality of financial product types and a covered products matrix. The indication that is generated at 1706 (e.g., indicating whether or not the agreement type and term are appropriate based on the financial product types) may be provided, for example, to a user of an agreement modeling system and/or a satellite system. According to one embodiment, the indication comprises a “warning flag” indicating that the details of the agreement need to be carefully reviewed.
- Agreement Definition
- FIG. 18 is a flow chart of a method for facilitating definition of a transaction agreement between a party and a counter-party according some embodiments of the present invention. At1802, an agreement document template is created in association with a transaction agreement type. At 1804, a plurality of agreement facts are determined. The agreement facts may be associated with, for example, the party and/or the counter-party. At 1806, an agreement document instance associated with the transaction agreement is defined. The agreement document instance may be based on, for example, the agreement document template and the plurality of agreement facts. A more detailed description of agreement definition according to some embodiments of the present invention will now be provided with respect to FIGS. 19A through 27.
- FIGS. 19A and 19B are block diagrams of agreement modeling system functions, applications, and interactions according to some embodiments of the present invention. In particular, FIG. 19A presents an engine-level overview of the
client device 10 and the agreementmodeling system controller 1000 according to one embodiment. Theclient device 10 includes adisplay engine 1902 that may be used to exchange information with a user (e.g., by receiving information from and displaying information to the user). Thedisplay engine 1920 may comprise, for example, a typical WINDOWS® style Multi-Document Interface (MDI) application. Such an application may simultaneously display one or more agreements. Some examples of user displays that may be processed by thedisplay engine 1902 are described herein with respect to FIGS. 22 through 24. - The agreement
modeling system controller 1000 includes anadministrator 1910 and anagreement engine 1920 described in detail with respect to FIG. 19B. The agreementmodeling system controller 1000 also includes anevaluation engine 2040 and acreation engine 2030 described in detail with respect to FIGS. 20 and 21. In addition, the agreementmodeling system controller 1000 may include afact engine 1904 that may, for example, be used to process facts and fact sets as required. - FIG. 19B illustrates the operation of the
administrator 1910 and theagreement editor 1920. Theadministrator 1910 may be used to create an agreement template, including templates for various documents associated with that type of agreement. For example, the agreement template may include an original document template, a schedule document template, a CSA document template, and/or an amendment document template. - The
agreement editor 1920 may be used to create an agreement instance based on the agreement template. The agreement instance may, for example, include instances of one or more document templates (e.g., an original document instance, a schedule document instance, a CSA document instance, and/or an amendment document instance). - Both the agreement template and the agreement instance may be stored in the agreement
modeling system database 1930 for future use. - FIG. 20 is a block diagram of agreement creation interactions according to some embodiments of the present invention. In particular, the
creation engine 2030 may manufacture new agreements and documents. Thecreation engine 2030 may exist in the database/backend 2020 and may comprise acreation processor 2050 and an instance of the evaluation engine 2040 (e.g., that extends from theevaluation engine 2040 object in the Java/object sense). - The
creation engine 2030 may service two types of create operations: a create agreement operation and a create document operation. A successful create agreement operation results in a new agreement including one or more associated required documents. A successful create document(s) operation results in the creation of one (or more) new documents associated with an existing agreement. - An instance of the
creation engine 2030 is manufactured to service each create operation (note that the create functionality may be exposed via Java Stored Procedures). The create agreement operation may be invoked from theagreement editor 1920 upon a completion of an agreement wizard as follows. The agreement wizard may be selected via a “file—new” menu item, followed by selection of sub-menu items that allow selection of a specific agreement wizard. The content of each agreement wizard may be defined by one or more agreement wizard fact sets. The agreement wizard is completed by activating a “finish” button on one of the wizard pages. When the “finish” button is activated, all of the combined agreement wizard fact sets are communicated to the database backed 2020, in the form of an XML document describing the fact set content, via a middle-tier 2010. The middle-tier 2010 simply passes the stream through to the database/backend 2020. - Upon the invocation of a stored procedure, an instance of the
creation engine 2030 is instantiated. Within the instance of thecreation engine 2030, an instance of theevaluation engine 2040 is created and initialized with an agreement scope that contains all of the facts defined in the wizard fact sets passed from theagreement editor 1920. - Once the
creation engine 2030 and its embeddedevaluation engine 2040 are initialized, thecreation processor 2050 determines the appropriate agreement to be created (via “applies rules”). If an appropriate agreement is found, it is determined if the user has the appropriate rights to create all required documents associated with the agreement (via “security rules”). If the user has appropriate rights, then the agreement is created by systematically creating the required documents associated with the agreement, conditionally populating each document's content with the fact sets and facts that are included through the applies rules analysis. In addition, default values and attributes may be assigned to facts populated into documents. - The
creation processor 2050 may use a series of stored procedure calls that operate directly on the agreement, document, and fact set or fact instance tables populating instance data into the tables as the intermediate result of rules and expression evaluations. In general, a set of well-defined stored procedures may accommodate the entire agreement creation process. - After the agreement and all of its associated required documents have been created, updates to security access tables and views may be computed.
- The immediate return value for the create agreement operation from the database/
backend 2020 to the middle-tier 2010 may simply comprise signal of success or failure. If the creation of the agreement failed, then the middle-tier 2010 returns an appropriate Java exception to theagreement editor 1920. - Upon successful creation of an agreement, the middle-tier2010 (prior to returning information to the agreement editor 1920) may orchestrate call(s) back to the database/
backend 2020 to make it appear as if theagreement editor 1920 had called an “open agreement” operation. That is, an entire XML stream representing the opening of the newly created agreement may be returned. - FIG. 21 is a block diagram of document creation interactions according to some embodiments of the present invention. The create documents operation may be invoked from the
agreement editor 1920 when an “add” button is activated via a multi-document tab and one of the listed document types are selected. Such a multi-document tab approach enables the management of more than one document (and document type) via a single tab. A multi-document list box may display all instances of existing documents that are associated with that tab (e.g., documents may be associated with a tab based on a document type's document group membership). - When the “add” button is activated, the
agreement editor 1920 may first call a method that returns an array of (partially loaded) objects that are used to populate an “add document” selection dialog associated with the “add” button. A corresponding stored procedure may form the list of document types based an a specific user and/or agreement. - Upon the selection of a document type from the “add document” list, the
agreement editor 1920 sends the selected document type information to the database backed 2020 via a middle-tier 2010 API call. - An instance of the
creation engine 2030 is then instantiated by the database/backend 2020. Within the instance of thecreation engine 2030, an instance of theevaluation engine 2040 is created and initialized with the agreement scope that is applicable for the active agreement. According to one embodiment, the agreement scope is passed as an XML stream by theagreement editor 1920 which has the scope loaded for the active agreement. According to another embodiment, the scope is instead loaded from adatabase 2060. - Once the
creation engine 2030 and the embeddedevaluation engine 2040 are initialized, thecreation processor 2050 conditionally populates the document's content with the fact sets and facts that are included through an “applies rules” analysis. In addition, default values and attributes are assigned to each fact based upon “value and attribute expressions.” - Depending upon the context of the create document algorithm invocation, the instance of the
creation engine 2030 may be associated with a create agreement operation or a create document operation. In either case, the appropriate agreement scope may be initialized on the associatedevaluation engine 2040. - Note that a series of stored procedure calls by the
creation processor 2050 may operate directly on the document and fact set—fact instance tables populating instance data into the tables as the result of the rules and expressions evaluations. In general, a set of well-defined stored procedures may accommodate the entire agreement, document, fact set, and/or fact creation process. At the end of the create document algorithm, security tables and views may be calculated. - The availability of the document scope enables applies rules, value expressions, and attribute expressions to be written that are generally more localized to a document's context. With the document scope included, rules and expressions can be written that do not need to rely solely on agreement level attributes to drive the creation process.
- The intermediate return value from the create document operation from the database/
backend 2020 to the middle-tier 2010 may simply be a signal of success or failure. If the creation of the document failed, then the middle-tier 2010 returns an appropriate Java exception to theagreement editor 1920. - Upon successful creation of a document, the middle-tier2010 (prior to returning information to the agreement editor 1920) may orchestrates call(s) back to the database/
backend 2020 to make it appear as if theagreement editor 1920 had called an update document operation. That is, an entire XML stream representing the newly created document may be returned. - Agreement Modeling System Client Displays
- FIGS. 22 through 24 illustrate client displays associated with an agreement according to an embodiment of the present invention. Note that the system may be document-centric in the display of agreement information, and that a new agreement may be created via a special wizard “fact set” that asks questions and receives answers (fact values) that are used by the fact engine's rules-based wizard to determine the agreement type, documents, fact sets, and facts that are populated in the agreement.
- In particular, FIG. 22 illustrates a
display 2200 when no agreement is loaded into the application. A user selects an existing agreement from a search dialog that is associated with the “file . . . open agreement” menu item. - FIG. 23 illustrates a
display 2300 after an agreement has been loaded. Each agreement instance in the MDI display frame contains a set of display tabs that are dynamically generated according to a set of document groups that are defined for the agreement. Each document group has one or more documents that are members of the group and whose contents will be displayed on the relative document group tab. - As can be seen, FIG. 23 illustrates the layout of a general “agreement data” single-document group tab. Note that a consistent display space may be organized around the current document and active fact set. For example, a tab associated with a single-document display may divide the
display 2300 into a left and right pane. - The current document's name (“LCA Today”) is displayed at the top of the left-pane. The left-pane list box contains the set of fact sets that are defined for the current document (e.g., “agreement data,” “counter-party data,” “credit support,” and “cross acceleration”). The right-pane contains the contents for the actively selected fact set within the current document. The name of the active fact set (e.g., “agreement data”) may be displayed in the top of the right-pane.
- FIG. 24 illustrates a
display 2400 when an agreement has been loaded, and thedisplay 2400 is associated with a multi-instance fact set display (i.e., “counter-party data”). In this case, the right-pane is divided into two areas. The top area includes a list box of instances of the active fact set. The display entry in the list box is formed by an expression associated with the fact set. The bottom portion of the right-pane display area indicates the facts that comprise the fact set which may be displayed in linear order (as with the single-instance display space). - Agreement Modeling System Work Flows
- FIG. 25 is a flow chart of a method for facilitating definition of an agreement between a party (including a first party entity and a second party entity) and a counter-party according some embodiments of the present invention. At2502, a first agreement term is determined via the first party entity. For example, the first agreement term may be defined by a compliance entity. At 2504, a second agreement term is determined via the second party entity (e.g., based at least in part on the first agreement term). For example, a legal entity may define the second agreement term based on the first agreement term.
- A more detailed example of this process will now be provided with respect to FIGS. 26A and 26B. At2602, a request for an agreement is received by the agreement modeling system controller 1000 (e.g., via a client device 10). If the agreement is associated with a marketing tool at 2604 (i.e., the request may need to be processed immediately), a pre-draft of the agreement is generated at 2606.
- If the agreement is not associated with a marketing tool at2604, a priority is assigned to the request at 2608 (e.g., as compared to other requests received by the agreement modeling system controller 1000). Note that trade activity detected at 2610 and a subsequent
post-trade notification report 2612 may also result in a priority being assigned at 2608. - After a priority is assigned to the request, at2614 the agreement
modeling system controller 1000 triggers acompliance entity 2616 for data. For example, thecompliance entity 2616 may receive, review, and respond to information associated with the requested agreement (e.g., to ensure that the information complies with relevant compliance standards and procedures). If the compliance data is not complete at 2618, a data gathering entity issues a report at 2620 (e.g., to arrange for more data to be collected). - If the compliance data is complete, at2622 the agreement
modeling system controller 1000 triggers acredit entity 2624 for data. For example thecredit entity 2624 may receive, review, and respond to information associated with the requested agreement (e.g., to ensure that the information complies with relevant credit standards and procedures). Moreover, if it is determined that the agreement is bilateral at 2626, the agreementmodeling system controller 1000 triggers atreasure entity 2632 for data at 2630 (e.g., to ensure that the information complies with relevant treasury standards and procedures). - The agreement
modeling system controller 1000 then determines if the agreement data is complete at 2628. If the agreement data is not complete, the data gathering entity issues a report at 2620 (e.g., to arrange for more data to be collected). If the agreement data is complete, a pre-draft of the agreement is generated at 2606. - FIG. 27 illustrates some examples of agreement definition via multiple party entities according to an embodiment of the present invention. In particular, the
first work flow 2710 is associated with agreement definition when a business entity initiates a request for a new agreement associated with a risk transaction. Information from the business entity is forwarded to a compliance entity for review (and/or for further information). The agreement information is then reviewed (and/or supplemented) by a credit entity and finally by a legal entity (e.g., for approval). - The
second work flow 2720 is associated with agreement definition when a business entity initiates a request for a new agreement associated with a non-risk transaction. This situation is similar to thefirst work flow 2710, except that the credit entity is not involved (e.g., because it is a non-risk transaction). - The
third work flow 2730 is associated with agreement definition when the compliance entity initiates a request for a new agreement on behalf of a business entity. This situation is similar to thefirst work flow 2710, but the business entity is not (directly) involved. Moreover, involvement of the credit entity in the work flow may not be required in the case of a non-risk transaction. - The
fourth work flow 2740 is associated with agreement definition when the credit entity initiates a request for a new agreement on behalf of a business entity. Again, the situation is similar to thefirst work flow 2710, but the business entity is not (directly) involved. Also note that, in this case, the credit entity is involved before the compliance entity. - The
fifth work flow 2740 is associated with agreement definition when a treasury entity initiates a request for a new agreement on behalf of a business entity. This similar to thefirst work flow 2710, but the business entity is not (directly) involved. - Additional Embodiments
- The following illustrates various additional embodiments of the present invention. These do not constitute a definition of all possible embodiments, and those skilled in the art will understand that the present invention is applicable to many other embodiments. Further, although the following embodiments are briefly described for clarity, those skilled in the art will understand how to make any changes, if necessary, to the above-described apparatus and methods to accommodate these and other embodiments and applications.
- Many of the embodiments described herein include an agreement
modeling system controller 1000 that facilitates definition of an agreement. According to other embodiments, however, some or all of these functions are instead performed by other devices. For example, multiple devices may communicate with each other to perform the functions described herein without the use of a “controller” (e.g., a peer-to-peer model may be used). Moreover, many of the devices illustrated in FIG. 3 (including some or all of the satellite systems) may be incorporated in a single device. - In addition, many of the embodiments described herein are directed to financial transaction agreements. However, the present invention is applicable to may other types of agreements as well (e.g., contracts with a governmental authority).
- The present invention has been described in terms of several embodiments solely for the purpose of illustration. Persons skilled in the art will recognize from this description that the invention is not limited to the embodiments described, but may be practiced with modifications and alterations limited only by the spirit and scope of the appended claims.
Claims (45)
1. A method for facilitating definition of a transaction agreement associated with a plurality of product types, comprising:
automatically determining an agreement type based on the plurality of product types and a covered products matrix; and
determining, in accordance with the agreement type, an agreement term between a party and a counter-party.
2. The method of claim 1 , wherein the covered products matrix is associated with at least one of: (i) a plurality of covered product types, and (ii) a plurality of transaction instruments.
3. The method of claim 2 , wherein at least one covered product type comprises: (i) an equity product, (ii) a stock product, (iii) an index product, (iv) a fixed income product, (v) a bond product, (vi) a bank loan product, (vii) a whole loan product, (viii) an interest rate product, (ix) a credit derivative product, (x) a commodity product, (xi) a metal product, (xii) a energy product, and (xiii) an agriculture product.
4. The method of claim 2 , wherein at least one transaction instrument comprises: (i) a swap instrument, (ii) an option instrument, (iii) a buy instrument, (iv) a sell instrument, (v) a call instrument, (vi) a put instrument, (vii) a forward instrument, (viii) a pre-paid forward instrument, (ix) a spot instrument, (x) a repurchase agreement instrument, (xi) a loan instrument, (xii) a warrant instrument, and (xiii) a contract for differences instrument.
5. The method of claim 2 , wherein the covered products matrix further includes at least one of: (i) an indication of approval, (ii) an indication of disapproval, (iii) an indication of a pending status, (iv) compliance authorization information, (v) default information, (vi) party information, (vii) counter-party information, (viii) legal information, (ix) master agreement information, and (x) credit information.
6. The method of claim 1 , wherein the transaction agreement is associated with at least one of: (i) a set of rights between the party and the counter-party, and (ii) a legal contract.
7. The method of claim 1 , wherein the agreement type is associated with at least one of: (i) a set of rights between the party and the counter-party, (ii) a legal contract, (iii) a product type, (iv) a monetary amount, (v) a transaction instrument, (vi) the party, and (vii) the counter-party.
8. The method of claim 1 , wherein the agreement term is associated with at least one of: (i) a set of rights between the party and the counter-party, (ii) a legal contract, (iii) a product type, (iv) a monetary amount, (v) a transaction instrument, (vi) the party, and (vii) the counter-party.
9. The method of claim 1 , wherein said determining an agreement type comprises:
determining a general document type; and
determining a refinement to the general document type.
10. The method of claim 1 , wherein said automatically determining the agreement term comprises:
defining the agreement term based on a pre-stored default transaction term.
11. The method of claim 1 , wherein said automatically determining the agreement term comprises:
defining the agreement term based on information received from a user of an agreement modeling system.
12. The method of claim 1 , wherein said automatically determining the agreement term comprises:
defining the agreement term based on information received from a satellite system.
13. The method of claim 1 , wherein the satellite system comprises at least one of: (i) a business system, (ii) a legal system, (iii) a compliance system, (iv) a credit system, (v) a treasury system, and (vi) an operations system.
14. The method of claim 1 , wherein said automatically determining the agreement term comprises:
defining the agreement term based via a legacy agreement system.
15. The method of claim 1 , wherein said automatically determining the agreement term comprises:
automatically determining the agreement term based on the plurality of product types.
16. A method for facilitating definition of a transaction agreement, comprising:
determining an agreement type;
determining an agreement term; and
generating an indication based on an evaluation of the agreement type and the agreement term.
17. The method of claim 16 , wherein the transaction agreement is associated with a plurality of financial product types, and further comprising:
evaluating the agreement type and the agreement term based on the plurality of financial product types and a covered financial products matrix.
18. The method of claim 16 , wherein the indication is provided to at least one of: (i) a user of an agreement modeling system, and (ii) a satellite system.
19. A method for facilitating definition of a contract, comprising:
determining a contract type; and
determining, in accordance with the contract type, a contract term between a party and a counter-party.
20. The method of claim 19 , wherein the contract is associated with at least one financial product type, and at least one of the contract type and the contract term are automatically determined based at least in part on the financial product type.
21. The method of claim 19 , wherein said determining a contract type comprises:
providing to the user a list of potential contract groups;
receiving from the user an indication of a selected contract group;
based on the selected contract group, providing to the user a list of potential contract types; and
receiving from the user an indication of a selected contract type.
22. The method of claim 19 , wherein said determining the contract term is performed via at least one of: (i) an agreement rule, (ii) a document rule, (iii) a fact set rule, and (iv) a fact rule.
23. The method of claim 19 , wherein said determining the contract term is performed via an automated contract interface.
24. A method for facilitating agreement definition, comprising:
determining an agreement term;
determining a term date associated with the agreement term; and
storing an indication of the agreement term in association with an indication of the term date, wherein an applicability of the agreement term can be automatically determined based at least in part on the term date.
25. The method of claim 24 , wherein the term date comprises at least one of: (i) a term effective date, (ii) a term expiration date, (iii) a term period, and (iv) a term entry date.
26. The method of claim 24 , wherein the applicability of the agreement term can be automatically determined based further on at least one of: (i) a current date, (ii) a term entry date, and (iii) a query date.
27. The method of claim 24 , further comprising:
storing, in association with the agreement term, an indication of at least one supporting agreement document.
28. A method for facilitating definition of an agreement between a party and a counter-party, the party including a first party entity and a second party entity, comprising:
determining a first agreement term via the first party entity; and
based at least in part on the first agreement term, determining a second agreement term via the second party entity.
29. The method of claim 28 , wherein at least one of the first party entity and the second party entity comprises: (i) a business system, (ii) a legal system, (iii) a compliance system, (iv) a credit system, (v) a treasury system, and (vi) an operations system.
30. A method for facilitating agreement definition, comprising:
determining an agreement term; and
storing a value associated with the agreement term along with an indication of a right associated with the agreement term.
31. The method of claim 30 , wherein said storing is performed via an extensible agreement modeling system language.
32. A computer-implemented method for facilitating definition of a transaction agreement between a party and a counter-party, comprising:
creating at least one agreement document template associated with a transaction agreement type;
determining a plurality of agreement facts, at least one of the agreement facts being associated with at least one of the party and the counter-party; and
defining an agreement document instance associated with the transaction agreement, the agreement document instance being based on the agreement document template and the plurality of agreement facts.
33. The method of claim 32 , wherein the agreement document template includes a plurality of agreement fact sets, each agreement fact set comprising a number of agreement facts.
34. The method of claim 32 , wherein a plurality of agreement document templates are associated with the transaction agreement type.
35. The method of claim 32 , wherein a plurality of agreement document instances are defined in association with the transaction agreement.
36. The method of claim 32 , wherein an agreement fact is associated with a plurality of at least one of: (i) agreement document instances, and (ii) transaction agreement types.
37. The method of claim 32 , wherein the transaction agreement is associated with at least one of: (i) a risk management transaction, (ii) an over the counter product, (iii) an equity derivative, (iv) a commodity transaction, (v) an electricity transaction, (vi) a foreign exchange transaction, (vii) a currency option, (viii) a bond option, (ix) a synthetic agreement for forward exchange, (x) a reciprocal purchase agreement, (xi) an interest rate swap, (xii) an interest rate cap, (xiii) an interest rate collar, (xiv) an interest rate floor, (xv) a forward rate agreement, (xvi) a forward rate bill agreement, and (xvii) an option to enter into an underlying interest rate swap transaction.
38. The method of claim 32 , wherein the transaction agreement comprises at least one of: (i) an INTERNATIONAL SWAP DEALERS ASSOCIATION® agreement, (ii) a foreign exchange & options master agreement, (iii) an agreement associated with one or more currencies, and (iv) an agreement associated with one or more jurisdictions.
39. The method of claim 32 , wherein the transaction agreement includes at least one of: (i) date information, (ii) agreement interpretation information, (iii) obligation information, (iv) representation information, (v) sub-agreement information, (vi) default event information, (vii) termination event information, (viii) transfer information, (ix) expenses information, (x) notice information, (xi) governing law information, (xii) definition information, a master agreement, (xiii) a schedule to a master agreement, and (xiv) at least one addenda to a master agreement.
40. The method of claim 32 , wherein at least one agreement fact comprises at least one of: (i) a party identifier, (ii) a counter-party identifier, (iii) an agreement identifier, (iv) a name, (v) address information, (vi) contact information, (vii) an effective date, (viii) an expiration date, (ix) an area of origin, (x) an indication of governing law, (xi) an area of organization, (xii) a standard industrial classification code, (xiii) a functional business area, and (xiv) beneficial ownership information.
41. The method of claim 32 , wherein at least one agreement fact is associated with at least one of: (i) a data type, (ii) a data source, (iii) a security class, and (iv) an attribute.
42. An apparatus for facilitating definition of a transaction agreement associated with a plurality of product types, comprising:
a processor; and
a storage device in communication with said processor and storing instructions adapted to be executed by said processor to:
automatically determine an agreement type based on the plurality of product types and a covered products matrix; and
determine, in accordance with the agreement type, an agreement term between a party and a counter-party.
43. The apparatus of claim 42 , wherein said storage device further stores an agreement information database.
44. The apparatus of claim 42 , further comprising:
a communication device coupled to said processor and adapted to communicate with at least one of: (i) a client device, (ii) an agreement modeling system controller, and (iii) a satellite system.
45. A medium storing instructions adapted to be executed by a processor to perform a method of facilitating definition of a transaction agreement associated with a plurality of product types, said method comprising:
automatically determining an agreement type based on the plurality of product types and a covered products matrix; and
determining, in accordance with the agreement type, an agreement term between a party and a counter-party.
Priority Applications (10)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/916,881 US20030023539A1 (en) | 2001-07-27 | 2001-07-27 | Systems and methods for facilitating agreement definition via an agreement modeling system |
US09/929,184 US7720729B2 (en) | 2001-07-27 | 2001-08-14 | Systems and methods for facilitating agreement generation and negotiation via an agreement modeling system |
US09/939,911 US7231362B2 (en) | 2001-07-27 | 2001-08-27 | Systems and methods for facilitating use of agreement information via an agreement modeling system |
PCT/US2002/023896 WO2003012584A2 (en) | 2001-07-27 | 2002-07-29 | Systems and methods for facilitating use of agreement information via an agreement modeling system |
PCT/US2002/023897 WO2003012585A2 (en) | 2001-07-27 | 2002-07-29 | Systems and methods for facilitating agreement definition via an agreement modeling system |
AU2002322709A AU2002322709A1 (en) | 2001-07-27 | 2002-07-29 | Systems and methods for facilitating agreement generation and negotiation via an agreement modeling system |
AU2002329648A AU2002329648A1 (en) | 2001-07-27 | 2002-07-29 | Systems and methods for facilitating use of agreement information via an agreement modeling system |
AU2002329649A AU2002329649A1 (en) | 2001-07-27 | 2002-07-29 | Systems and methods for facilitating agreement definition via an agreement modeling system |
PCT/US2002/023898 WO2003012586A2 (en) | 2001-07-27 | 2002-07-29 | Systems and methods for facilitating agreement generation and negotiation via an agreement modeling system |
US12/748,534 US20100185548A1 (en) | 2001-07-27 | 2010-03-29 | Systems and Methods for Facilitating Agreement Generation and Negotiation via an Agreement Modeling System |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/916,881 US20030023539A1 (en) | 2001-07-27 | 2001-07-27 | Systems and methods for facilitating agreement definition via an agreement modeling system |
Related Child Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/929,184 Continuation-In-Part US7720729B2 (en) | 2001-07-27 | 2001-08-14 | Systems and methods for facilitating agreement generation and negotiation via an agreement modeling system |
US09/939,911 Continuation-In-Part US7231362B2 (en) | 2001-07-27 | 2001-08-27 | Systems and methods for facilitating use of agreement information via an agreement modeling system |
Publications (1)
Publication Number | Publication Date |
---|---|
US20030023539A1 true US20030023539A1 (en) | 2003-01-30 |
Family
ID=25437985
Family Applications (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/916,881 Abandoned US20030023539A1 (en) | 2001-07-27 | 2001-07-27 | Systems and methods for facilitating agreement definition via an agreement modeling system |
US09/929,184 Active 2029-08-26 US7720729B2 (en) | 2001-07-27 | 2001-08-14 | Systems and methods for facilitating agreement generation and negotiation via an agreement modeling system |
US09/939,911 Active 2024-05-24 US7231362B2 (en) | 2001-07-27 | 2001-08-27 | Systems and methods for facilitating use of agreement information via an agreement modeling system |
US12/748,534 Abandoned US20100185548A1 (en) | 2001-07-27 | 2010-03-29 | Systems and Methods for Facilitating Agreement Generation and Negotiation via an Agreement Modeling System |
Family Applications After (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/929,184 Active 2029-08-26 US7720729B2 (en) | 2001-07-27 | 2001-08-14 | Systems and methods for facilitating agreement generation and negotiation via an agreement modeling system |
US09/939,911 Active 2024-05-24 US7231362B2 (en) | 2001-07-27 | 2001-08-27 | Systems and methods for facilitating use of agreement information via an agreement modeling system |
US12/748,534 Abandoned US20100185548A1 (en) | 2001-07-27 | 2010-03-29 | Systems and Methods for Facilitating Agreement Generation and Negotiation via an Agreement Modeling System |
Country Status (3)
Country | Link |
---|---|
US (4) | US20030023539A1 (en) |
AU (3) | AU2002329648A1 (en) |
WO (1) | WO2003012585A2 (en) |
Cited By (34)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040117280A1 (en) * | 2002-12-12 | 2004-06-17 | Rosemary Klee | Financial document automation system and method |
US20040205590A1 (en) * | 2001-08-07 | 2004-10-14 | Ironspire, Inc. | Extensible object-oriented document system and method |
US20050010512A1 (en) * | 2001-11-16 | 2005-01-13 | Roger Gutbrod | Method and apparatus for computer-implemented generation and administration of contracts |
US20050033617A1 (en) * | 2003-08-07 | 2005-02-10 | Prather Joel Kim | Systems and methods for auditing auditable instruments |
WO2007059977A1 (en) * | 2005-11-23 | 2007-05-31 | Ubs Ag | Computer-implemented system for producing, processing and managing structured data sets |
WO2007059978A1 (en) * | 2005-11-23 | 2007-05-31 | Ubs Ag | Computer-implemented system for producing, processing and managing structured data sets |
EP1801744A1 (en) * | 2005-11-23 | 2007-06-27 | Ubs Ag | Computer implemented system for creating, processing and managing structured data sets |
US20070192225A1 (en) * | 2006-02-13 | 2007-08-16 | Michael Schroeder | Systems and methods for automated repurchase agreement matching |
US20070192373A1 (en) * | 2006-02-15 | 2007-08-16 | Microsoft Corporation | Recovery of logless components |
US20080010221A1 (en) * | 2006-09-29 | 2008-01-10 | Chicago Mercantile Exchange, Inc. | Derivative products |
US20080082437A1 (en) * | 2006-09-29 | 2008-04-03 | Richard Co | Derivative Products |
US7409367B2 (en) | 2001-05-04 | 2008-08-05 | Delta Rangers Inc. | Derivative securities and system for trading same |
US20080195542A1 (en) * | 2007-02-13 | 2008-08-14 | Al Zarawani Sohail Abdul-Rahim | System and method for just-in-time capital investment and controlled cost insurance |
US20080249956A1 (en) * | 2006-07-18 | 2008-10-09 | Clive Connors | Interest rate swap index |
US20090106072A1 (en) * | 2007-10-19 | 2009-04-23 | Oracle International Corporation | Associating Assets with Agreements |
US20090234662A1 (en) * | 2008-03-13 | 2009-09-17 | Oracle International Corporation | Unified Enterprise Contract Management Architecture |
US20100082474A1 (en) * | 2008-08-26 | 2010-04-01 | Perry Harley Beaumont | Computer method and apparatus that facilitates the trading of complex financial instruments on the internet within the context of a portal as defined by the United States Securities and Exchange Commission |
US8145552B2 (en) | 2010-07-08 | 2012-03-27 | The Bank Of New York Mellon | System and method for computer implemented collateral management |
US20120150715A1 (en) * | 2010-12-09 | 2012-06-14 | James Boudreault | Cross Margining of Tri-Party Repo Transactions |
US8781815B1 (en) | 2013-12-05 | 2014-07-15 | Seal Software Ltd. | Non-standard and standard clause detection |
US20140278814A1 (en) * | 2013-03-15 | 2014-09-18 | Sap Ag | Contract-based process integration |
US20150112877A1 (en) * | 2008-01-15 | 2015-04-23 | Frank Schilder | Systems, methods, and software for questionbased sentiment analysis and summarization |
US20160012031A1 (en) * | 2014-07-08 | 2016-01-14 | Bank Of America Corporation | Template-based message generation tool |
US9251139B2 (en) * | 2014-04-08 | 2016-02-02 | TitleFlow LLC | Natural language processing for extracting conveyance graphs |
US9710853B2 (en) | 2010-07-08 | 2017-07-18 | The Bank Of New York Mellon | System and method for computer implemented collateral management |
US9805025B2 (en) | 2015-07-13 | 2017-10-31 | Seal Software Limited | Standard exact clause detection |
US10311140B1 (en) * | 2018-10-25 | 2019-06-04 | BlackBoiler, LLC | Systems, methods, and computer program products for a clause library |
US20200007599A1 (en) * | 2018-06-01 | 2020-01-02 | Izettle Merchant Services Ab | Collaboration server and method |
US10713436B2 (en) | 2018-03-30 | 2020-07-14 | BlackBoiler, LLC | Method and system for suggesting revisions to an electronic document |
US10824797B2 (en) | 2015-08-03 | 2020-11-03 | Blackboiler, Inc. | Method and system for suggesting revisions to an electronic document |
WO2021154279A1 (en) * | 2020-01-31 | 2021-08-05 | Lit Ideas, Llc. | System and method for resolving conflicting inputs |
US11681864B2 (en) | 2021-01-04 | 2023-06-20 | Blackboiler, Inc. | Editing parameters |
CN116630050A (en) * | 2023-06-16 | 2023-08-22 | 深圳市弘裕金联科技有限公司 | Online gold transaction method, system, device and storage medium |
WO2024019755A1 (en) * | 2022-07-20 | 2024-01-25 | Innopeak Technology, Inc. | Support remote application extensions or plugins |
Families Citing this family (56)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
AU2001286456A1 (en) | 2000-08-11 | 2002-02-25 | Jens Erik Sorensen | Management of ideas accumulated in a computer database |
CA2454742C (en) * | 2001-07-26 | 2011-03-08 | Irise | System and process for gathering, recording and validating requirements for computer applications |
US20030023539A1 (en) * | 2001-07-27 | 2003-01-30 | Wilce Scot D. | Systems and methods for facilitating agreement definition via an agreement modeling system |
US10019683B1 (en) * | 2001-10-04 | 2018-07-10 | Jda Software Group, Inc. | Facilitating the negotiation of standards for inter-enterprise collaboration between trading partners |
US7130830B2 (en) * | 2001-10-09 | 2006-10-31 | Ogilvie John W L | Providing notice of patent rights |
US8239935B2 (en) | 2001-10-09 | 2012-08-07 | Lot 27 Acquisition Foundation Llc | Providing notice of patent and other legal rights |
US20040083119A1 (en) * | 2002-09-04 | 2004-04-29 | Schunder Lawrence V. | System and method for implementing a vendor contract management system |
US20040064404A1 (en) * | 2002-10-01 | 2004-04-01 | Menachem Cohen | Computer-based method for automatic remote coding of debtor credit databases with bankruptcy filing information |
US20040220819A1 (en) * | 2003-04-30 | 2004-11-04 | Sun Microsystems, Inc. | Automated web-based tool to manage legal agreements and projects |
WO2005010731A2 (en) * | 2003-07-31 | 2005-02-03 | Dealertrack, Inc. | Integrated electronic credit application, contracting and securitization system and method |
US7657831B2 (en) * | 2003-07-31 | 2010-02-02 | J.J. Donahue & Company | Creating and customizing a workflow process from a document |
JP4485293B2 (en) * | 2003-09-08 | 2010-06-16 | 株式会社リコー | Information processing apparatus, client terminal, image forming apparatus, data processing method, and program for causing computer to execute the method |
WO2005059690A2 (en) * | 2003-12-12 | 2005-06-30 | Michael Stockton | Method and system configured for facilitating management of international trade receivables transactions |
JP2005316714A (en) * | 2004-04-28 | 2005-11-10 | Fujitsu Ltd | Information retrieval method, information retrieval program and information retrieval device |
US7971068B2 (en) * | 2004-04-29 | 2011-06-28 | International Business Machines Corporation | Method, system and program product for protecting electronic contracts created within a secure computer infrastructure |
US7937413B2 (en) | 2004-05-04 | 2011-05-03 | International Business Machines Corporation | Self-adaptive prefix encoding for stable node identifiers |
US8108232B1 (en) * | 2005-05-26 | 2012-01-31 | Sprint Communications Company L.P. | System and method for project contract management |
US8332307B1 (en) * | 2005-05-31 | 2012-12-11 | Navigate Fund Solutions LLC | Variants of NAV-based trading for less closely-linked components of index arbitrage complexes |
US7783521B2 (en) * | 2005-05-31 | 2010-08-24 | International Business Machines Corporation | Electronic sales and contracting method, system and program product |
EP1732014A1 (en) * | 2005-06-08 | 2006-12-13 | Sap Ag | Calculation of specifed matrices |
US8543614B2 (en) | 2005-08-22 | 2013-09-24 | International Business Machines Corporation | Packing nodes into records to store XML XQuery data model and other hierarchically structured data |
US8572125B2 (en) | 2005-08-22 | 2013-10-29 | International Business Machines Corporation | Scalable storage schemes for native XML column data of relational tables |
US7529726B2 (en) * | 2005-08-22 | 2009-05-05 | International Business Machines Corporation | XML sub-document versioning method in XML databases using record storages |
US7865900B2 (en) * | 2005-12-20 | 2011-01-04 | Sap Ag | Systems and methods for providing mockup business objects |
US7996439B2 (en) * | 2006-01-18 | 2011-08-09 | Echosign, Inc. | Automatic document exchange and execution management |
US7895166B2 (en) * | 2006-01-18 | 2011-02-22 | Echosign, Inc. | Automatic document exchange with archiving capability |
US7996367B2 (en) | 2006-01-18 | 2011-08-09 | Echosign, Inc. | Automatic document exchange with document searching capability |
US8892467B1 (en) | 2006-01-27 | 2014-11-18 | Guardian Life Insurance Company Of America | Interactive systems and methods for supporting financial planning related activities |
US20100004957A1 (en) * | 2006-01-27 | 2010-01-07 | Robert Ball | Interactive system and methods for insurance-related activities |
US7565341B2 (en) * | 2006-05-10 | 2009-07-21 | Intuit Inc. | Automatically configuring a server to support different types of file accesses |
US20090254900A1 (en) * | 2006-07-13 | 2009-10-08 | Seiko Epson Corporation | Network system, computers, and method and program for providing and executing applications in network system |
US20080086400A1 (en) * | 2006-09-15 | 2008-04-10 | Carrie Ardelean | Computerized credit services information management system |
AU2007303117B2 (en) * | 2006-10-05 | 2011-02-24 | Infilco Degremont, Inc. | Systems and methods for contracting with multiple parties |
US20120265715A1 (en) * | 2006-12-21 | 2012-10-18 | Seth Silver | Facilitated method to improve professional relationships |
US8538795B2 (en) | 2007-02-12 | 2013-09-17 | Pricelock, Inc. | System and method of determining a retail commodity price within a geographic boundary |
US8156022B2 (en) | 2007-02-12 | 2012-04-10 | Pricelock, Inc. | Method and system for providing price protection for commodity purchasing through price protection contracts |
WO2008124719A1 (en) | 2007-04-09 | 2008-10-16 | Pricelock, Inc. | System and method for providing an insurance premium for price protection |
US7945501B2 (en) | 2007-04-09 | 2011-05-17 | Pricelock, Inc. | System and method for constraining depletion amount in a defined time frame |
US20090024513A1 (en) * | 2007-07-18 | 2009-01-22 | Ocean Tomo, Llc | Methods For Intellectual Property Transactions |
US8160952B1 (en) | 2008-02-12 | 2012-04-17 | Pricelock, Inc. | Method and system for providing price protection related to the purchase of a commodity |
US20090319312A1 (en) * | 2008-04-21 | 2009-12-24 | Computer Associates Think, Inc. | System and Method for Governance, Risk, and Compliance Management |
US8010450B2 (en) * | 2008-05-19 | 2011-08-30 | GE Corporate Finanical Services, Inc. | Systems and methods for processing commercial financial transactions |
US10453043B2 (en) * | 2008-06-25 | 2019-10-22 | Thomson Reuters Global Resources Unlimited Company | System and method for online bill payment |
US10304035B2 (en) * | 2009-06-10 | 2019-05-28 | Oracle International Corporation | Document management system |
WO2012048234A2 (en) | 2010-10-07 | 2012-04-12 | Morgan Stanley | System and method for risk monitoring of rated legal entities |
EP2625606A4 (en) | 2010-10-08 | 2014-11-26 | Irise | System and method for extending a visualization platform |
US20120136767A1 (en) * | 2010-10-15 | 2012-05-31 | Acadiasoft, Inc. | Electronic Centralized Margin Management System For Managing Actions Such As Substitution of Collateral Under Margin Agreements |
US8738406B1 (en) | 2011-05-12 | 2014-05-27 | Berkshire Life Insurance of America | Lump sum disability benefit rider |
WO2012159657A1 (en) * | 2011-05-20 | 2012-11-29 | Hewlett-Packard Development Company Lp | Data sharing agreements |
US20150169529A1 (en) * | 2013-12-16 | 2015-06-18 | Sap Ag | Mobile device data rendering |
US10028116B2 (en) * | 2015-02-10 | 2018-07-17 | Microsoft Technology Licensing, Llc | De-siloing applications for personalization and task completion services |
WO2017189027A1 (en) | 2016-04-29 | 2017-11-02 | Digital Asset Holdings | Digital asset modeling |
US10586210B2 (en) * | 2016-11-30 | 2020-03-10 | International Business Machines Corporation | Blockchain checkpoints and certified checkpoints |
US20190236124A1 (en) * | 2018-02-01 | 2019-08-01 | First Cut Technologies LLC | Systems and methods for creating a dynamically editable document template and for drafting, reviewing, negotiating, and finalizing a dynamically editable document |
US10897348B2 (en) * | 2019-06-17 | 2021-01-19 | Piamond Corp. | Method and system for managing consent and utilization of information using blockchain |
USD996462S1 (en) | 2020-04-15 | 2023-08-22 | Sublink, Llc | Display screen or portion thereof with animated graphical user interface |
Citations (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10463A (en) * | 1854-01-24 | Improvement in distilling apparatus | ||
US10686A (en) * | 1854-03-21 | Eotary smoothing-iron | ||
US23034A (en) * | 1859-02-22 | Xfiee-plug | ||
US38278A (en) * | 1863-04-28 | Improvement in sugar-evaporators | ||
US42782A (en) * | 1864-05-17 | Improved apparatus for bleaching | ||
US87534A (en) * | 1869-03-09 | Improvement in feather-renovators | ||
US95311A (en) * | 1869-09-28 | Improvement in thill-coupling | ||
US111922A (en) * | 1871-02-21 | Samuel english | ||
US198817A (en) * | 1878-01-01 | Improvement in stump-extractors | ||
US5826244A (en) * | 1995-08-23 | 1998-10-20 | Xerox Corporation | Method and system for providing a document service over a computer network using an automated brokered auction |
US5970479A (en) * | 1992-05-29 | 1999-10-19 | Swychco Infrastructure Services Pty. Ltd. | Methods and apparatus relating to the formulation and trading of risk management contracts |
US6125391A (en) * | 1998-10-16 | 2000-09-26 | Commerce One, Inc. | Market makers using documents for commerce in trading partner networks |
US20010049651A1 (en) * | 2000-04-28 | 2001-12-06 | Selleck Mark N. | Global trading system and method |
US20020069156A1 (en) * | 2000-09-01 | 2002-06-06 | Kerry Adam | Electronic trading platform for agricultural commodities |
US6421653B1 (en) * | 1997-10-14 | 2002-07-16 | Blackbird Holdings, Inc. | Systems, methods and computer program products for electronic trading of financial instruments |
US20020178120A1 (en) * | 2001-05-22 | 2002-11-28 | Reid Zachariah J. | Contract generation and administration system |
US20020188539A1 (en) * | 2001-06-08 | 2002-12-12 | Jonathan Axelrad | System and method for private equity fund formation |
US20020198833A1 (en) * | 2001-05-03 | 2002-12-26 | Jacob Wohlstadter | Method and system of exchanging and deriving economic benefit from exchanging securities |
US20030023527A1 (en) * | 2001-07-27 | 2003-01-30 | Wilce Scot D. | Systems and methods for facilitating agreement generation and negotiation via an agreement modeling system |
US20030172006A1 (en) * | 1995-02-13 | 2003-09-11 | Fino Timothy A. | System for facilitating home construction and sales |
US6778968B1 (en) * | 1999-03-17 | 2004-08-17 | Vialogy Corp. | Method and system for facilitating opportunistic transactions using auto-probes |
US6973640B2 (en) * | 2000-10-04 | 2005-12-06 | Bea Systems, Inc. | System and method for computer code generation |
Family Cites Families (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5692206A (en) | 1994-11-30 | 1997-11-25 | Taco Bell Corporation | Method and apparatus for automating the generation of a legal document |
US5704045A (en) | 1995-01-09 | 1997-12-30 | King; Douglas L. | System and method of risk transfer and risk diversification including means to assure with assurance of timely payment and segregation of the interests of capital |
US20040010463A1 (en) | 1996-11-12 | 2004-01-15 | Hahn-Carlson Dean W. | Automated transaction processing system and approach |
US6236984B1 (en) | 1997-11-26 | 2001-05-22 | Electronic Data Systems Corporation | Method and system of managing contract negotiation records |
US6067531A (en) | 1998-07-21 | 2000-05-23 | Mci Communications Corporation | Automated contract negotiator/generation system and method |
US7080050B1 (en) | 1999-08-05 | 2006-07-18 | Barter Securities | Electronic bartering system |
US20020023034A1 (en) | 2000-03-31 | 2002-02-21 | Brown Roger G. | Method and system for a digital automated exchange |
US7016859B2 (en) | 2000-04-04 | 2006-03-21 | Michael Whitesage | System and method for managing purchasing contracts |
AU2001257134A1 (en) * | 2000-04-20 | 2001-11-07 | Robert Sage Blackman | Agreement management system and method |
US7146343B2 (en) | 2000-07-05 | 2006-12-05 | J. J. Donahue & Company | Method and apparatus for negotiating a contract over a computer network |
US20040009764A1 (en) | 2000-07-28 | 2004-01-15 | Hazard James G | Telecommunication-based common contracting |
CA2322602A1 (en) | 2000-10-06 | 2002-04-06 | Ibm Canada Limited-Ibm Canada Limitee | System and method for generating a contract and conducting contractual activities under the contract |
US20020111922A1 (en) | 2000-11-06 | 2002-08-15 | Terry Bernard Young | Electronic markets business interchange system and method |
GB2371458A (en) * | 2001-01-17 | 2002-07-24 | Eastman Kodak Co | Method of enlargement of a digital image |
EP1384186A4 (en) | 2001-03-08 | 2006-08-02 | Morgan Stanley Dean Witter & C | Method and apparatus for trading assets, capital, and information |
US20050010463A1 (en) * | 2003-07-09 | 2005-01-13 | Joseph Du | Project management method and information integration system |
-
2001
- 2001-07-27 US US09/916,881 patent/US20030023539A1/en not_active Abandoned
- 2001-08-14 US US09/929,184 patent/US7720729B2/en active Active
- 2001-08-27 US US09/939,911 patent/US7231362B2/en active Active
-
2002
- 2002-07-29 AU AU2002329648A patent/AU2002329648A1/en not_active Abandoned
- 2002-07-29 WO PCT/US2002/023897 patent/WO2003012585A2/en not_active Application Discontinuation
- 2002-07-29 AU AU2002329649A patent/AU2002329649A1/en not_active Abandoned
- 2002-07-29 AU AU2002322709A patent/AU2002322709A1/en not_active Abandoned
-
2010
- 2010-03-29 US US12/748,534 patent/US20100185548A1/en not_active Abandoned
Patent Citations (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10463A (en) * | 1854-01-24 | Improvement in distilling apparatus | ||
US10686A (en) * | 1854-03-21 | Eotary smoothing-iron | ||
US23034A (en) * | 1859-02-22 | Xfiee-plug | ||
US38278A (en) * | 1863-04-28 | Improvement in sugar-evaporators | ||
US42782A (en) * | 1864-05-17 | Improved apparatus for bleaching | ||
US87534A (en) * | 1869-03-09 | Improvement in feather-renovators | ||
US95311A (en) * | 1869-09-28 | Improvement in thill-coupling | ||
US111922A (en) * | 1871-02-21 | Samuel english | ||
US198817A (en) * | 1878-01-01 | Improvement in stump-extractors | ||
US5970479A (en) * | 1992-05-29 | 1999-10-19 | Swychco Infrastructure Services Pty. Ltd. | Methods and apparatus relating to the formulation and trading of risk management contracts |
US20030172006A1 (en) * | 1995-02-13 | 2003-09-11 | Fino Timothy A. | System for facilitating home construction and sales |
US5826244A (en) * | 1995-08-23 | 1998-10-20 | Xerox Corporation | Method and system for providing a document service over a computer network using an automated brokered auction |
US6421653B1 (en) * | 1997-10-14 | 2002-07-16 | Blackbird Holdings, Inc. | Systems, methods and computer program products for electronic trading of financial instruments |
US6125391A (en) * | 1998-10-16 | 2000-09-26 | Commerce One, Inc. | Market makers using documents for commerce in trading partner networks |
US6778968B1 (en) * | 1999-03-17 | 2004-08-17 | Vialogy Corp. | Method and system for facilitating opportunistic transactions using auto-probes |
US20010049651A1 (en) * | 2000-04-28 | 2001-12-06 | Selleck Mark N. | Global trading system and method |
US20020069156A1 (en) * | 2000-09-01 | 2002-06-06 | Kerry Adam | Electronic trading platform for agricultural commodities |
US6973640B2 (en) * | 2000-10-04 | 2005-12-06 | Bea Systems, Inc. | System and method for computer code generation |
US20020198833A1 (en) * | 2001-05-03 | 2002-12-26 | Jacob Wohlstadter | Method and system of exchanging and deriving economic benefit from exchanging securities |
US20020178120A1 (en) * | 2001-05-22 | 2002-11-28 | Reid Zachariah J. | Contract generation and administration system |
US20020188539A1 (en) * | 2001-06-08 | 2002-12-12 | Jonathan Axelrad | System and method for private equity fund formation |
US20030023527A1 (en) * | 2001-07-27 | 2003-01-30 | Wilce Scot D. | Systems and methods for facilitating agreement generation and negotiation via an agreement modeling system |
Cited By (62)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7409367B2 (en) | 2001-05-04 | 2008-08-05 | Delta Rangers Inc. | Derivative securities and system for trading same |
US20040205590A1 (en) * | 2001-08-07 | 2004-10-14 | Ironspire, Inc. | Extensible object-oriented document system and method |
US20050010512A1 (en) * | 2001-11-16 | 2005-01-13 | Roger Gutbrod | Method and apparatus for computer-implemented generation and administration of contracts |
US20040117280A1 (en) * | 2002-12-12 | 2004-06-17 | Rosemary Klee | Financial document automation system and method |
US20050033617A1 (en) * | 2003-08-07 | 2005-02-10 | Prather Joel Kim | Systems and methods for auditing auditable instruments |
US8398406B2 (en) * | 2003-08-07 | 2013-03-19 | Swiss Reinsurance Company Ltd. | Systems and methods for auditing auditable instruments |
EP1798673A1 (en) * | 2005-11-23 | 2007-06-20 | Ubs Ag | Computer implemented system for creating, processing and managing structured data sets |
US20090171909A1 (en) * | 2005-11-23 | 2009-07-02 | Marcel Bank | Computer-Implemented System for Producing, Processing and Managing Structured Data Sets |
US8024373B2 (en) | 2005-11-23 | 2011-09-20 | Ubs Ag | Computer-implemented system for producing, processing and managing structured data sets |
WO2007059977A1 (en) * | 2005-11-23 | 2007-05-31 | Ubs Ag | Computer-implemented system for producing, processing and managing structured data sets |
US20100010842A1 (en) * | 2005-11-23 | 2010-01-14 | Marcel Bank | Computer-Implemented Systems and methods for Producing, Processing and Managing Structured Data Sets |
WO2007059978A1 (en) * | 2005-11-23 | 2007-05-31 | Ubs Ag | Computer-implemented system for producing, processing and managing structured data sets |
EP1801744A1 (en) * | 2005-11-23 | 2007-06-27 | Ubs Ag | Computer implemented system for creating, processing and managing structured data sets |
US20070192225A1 (en) * | 2006-02-13 | 2007-08-16 | Michael Schroeder | Systems and methods for automated repurchase agreement matching |
US8548893B2 (en) * | 2006-02-13 | 2013-10-01 | The Bank Of New York | Systems and methods for automated repurchase agreement matching |
US20070192373A1 (en) * | 2006-02-15 | 2007-08-16 | Microsoft Corporation | Recovery of logless components |
US20080249956A1 (en) * | 2006-07-18 | 2008-10-09 | Clive Connors | Interest rate swap index |
US7987126B2 (en) * | 2006-07-18 | 2011-07-26 | Pipeline Capital, Inc. | Interest rate swap index |
US8447679B2 (en) | 2006-09-29 | 2013-05-21 | Chicago Mercantile Exchange, Inc. | Derivative products |
US8423446B2 (en) | 2006-09-29 | 2013-04-16 | Chicago Mercantile Exchange, Inc. | Derivative products |
US8266026B2 (en) | 2006-09-29 | 2012-09-11 | Chicago Mercantile Exchange, Inc. | Derivative products |
US20080082437A1 (en) * | 2006-09-29 | 2008-04-03 | Richard Co | Derivative Products |
US8265965B2 (en) | 2006-09-29 | 2012-09-11 | Chicago Mercantile Exchange, Inc. | Derivative products |
US20080010221A1 (en) * | 2006-09-29 | 2008-01-10 | Chicago Mercantile Exchange, Inc. | Derivative products |
WO2008101004A1 (en) * | 2007-02-13 | 2008-08-21 | Sohail Jaffar Zarawani | System and method for just-in-time capital investment and controlled cost insurance |
US20100257123A1 (en) * | 2007-02-13 | 2010-10-07 | Sohail Abdul-Rahim Abdulla Jaffar Al Zarawani | System and method for just-in-time captial investment and controlled cost insurance |
US20080195542A1 (en) * | 2007-02-13 | 2008-08-14 | Al Zarawani Sohail Abdul-Rahim | System and method for just-in-time capital investment and controlled cost insurance |
US20090106072A1 (en) * | 2007-10-19 | 2009-04-23 | Oracle International Corporation | Associating Assets with Agreements |
US9811518B2 (en) * | 2008-01-15 | 2017-11-07 | Thomson Reuters Global Resources | Systems, methods, and software for questionbased sentiment analysis and summarization |
US20150112877A1 (en) * | 2008-01-15 | 2015-04-23 | Frank Schilder | Systems, methods, and software for questionbased sentiment analysis and summarization |
US20090234662A1 (en) * | 2008-03-13 | 2009-09-17 | Oracle International Corporation | Unified Enterprise Contract Management Architecture |
US20100082474A1 (en) * | 2008-08-26 | 2010-04-01 | Perry Harley Beaumont | Computer method and apparatus that facilitates the trading of complex financial instruments on the internet within the context of a portal as defined by the United States Securities and Exchange Commission |
US9710853B2 (en) | 2010-07-08 | 2017-07-18 | The Bank Of New York Mellon | System and method for computer implemented collateral management |
US8145552B2 (en) | 2010-07-08 | 2012-03-27 | The Bank Of New York Mellon | System and method for computer implemented collateral management |
US8315939B2 (en) | 2010-07-08 | 2012-11-20 | The Bank Of New York Mellon | System and method for computer implemented collateral management |
US8639609B2 (en) * | 2010-12-09 | 2014-01-28 | Chicago Mercantile Exchange Inc. | Cross margining of tri-party repo transactions |
US20120150715A1 (en) * | 2010-12-09 | 2012-06-14 | James Boudreault | Cross Margining of Tri-Party Repo Transactions |
US20140278814A1 (en) * | 2013-03-15 | 2014-09-18 | Sap Ag | Contract-based process integration |
US9299049B2 (en) * | 2013-03-15 | 2016-03-29 | Sap Se | Contract-based process integration |
US9268768B2 (en) | 2013-12-05 | 2016-02-23 | Seal Software Ltd. | Non-standard and standard clause detection |
US8781815B1 (en) | 2013-12-05 | 2014-07-15 | Seal Software Ltd. | Non-standard and standard clause detection |
US9251139B2 (en) * | 2014-04-08 | 2016-02-02 | TitleFlow LLC | Natural language processing for extracting conveyance graphs |
US20160117312A1 (en) * | 2014-04-08 | 2016-04-28 | TitleFlow LLC | Natural language processing for extracting conveyance graphs |
US10521508B2 (en) * | 2014-04-08 | 2019-12-31 | TitleFlow LLC | Natural language processing for extracting conveyance graphs |
US20160012031A1 (en) * | 2014-07-08 | 2016-01-14 | Bank Of America Corporation | Template-based message generation tool |
US9805025B2 (en) | 2015-07-13 | 2017-10-31 | Seal Software Limited | Standard exact clause detection |
USRE49576E1 (en) | 2015-07-13 | 2023-07-11 | Docusign International (Emea) Limited | Standard exact clause detection |
US10185712B2 (en) | 2015-07-13 | 2019-01-22 | Seal Software Ltd. | Standard exact clause detection |
US11093697B2 (en) | 2015-08-03 | 2021-08-17 | Blackboiler, Inc. | Method and system for suggesting revisions to an electronic document |
US10970475B2 (en) | 2015-08-03 | 2021-04-06 | Blackboiler, Inc. | Method and system for suggesting revisions to an electronic document |
US11630942B2 (en) | 2015-08-03 | 2023-04-18 | Blackboiler, Inc. | Method and system for suggesting revisions to an electronic document |
US10824797B2 (en) | 2015-08-03 | 2020-11-03 | Blackboiler, Inc. | Method and system for suggesting revisions to an electronic document |
US11244110B2 (en) | 2018-03-30 | 2022-02-08 | Blackboiler, Inc. | Method and system for suggesting revisions to an electronic document |
US10713436B2 (en) | 2018-03-30 | 2020-07-14 | BlackBoiler, LLC | Method and system for suggesting revisions to an electronic document |
US11709995B2 (en) | 2018-03-30 | 2023-07-25 | Blackboiler, Inc. | Method and system for suggesting revisions to an electronic document |
US20200007599A1 (en) * | 2018-06-01 | 2020-01-02 | Izettle Merchant Services Ab | Collaboration server and method |
US10311140B1 (en) * | 2018-10-25 | 2019-06-04 | BlackBoiler, LLC | Systems, methods, and computer program products for a clause library |
US10614157B1 (en) | 2018-10-25 | 2020-04-07 | BlackBoiler, LLC | Systems, methods, and computer program products for slot normalization of text data |
WO2021154279A1 (en) * | 2020-01-31 | 2021-08-05 | Lit Ideas, Llc. | System and method for resolving conflicting inputs |
US11681864B2 (en) | 2021-01-04 | 2023-06-20 | Blackboiler, Inc. | Editing parameters |
WO2024019755A1 (en) * | 2022-07-20 | 2024-01-25 | Innopeak Technology, Inc. | Support remote application extensions or plugins |
CN116630050A (en) * | 2023-06-16 | 2023-08-22 | 深圳市弘裕金联科技有限公司 | Online gold transaction method, system, device and storage medium |
Also Published As
Publication number | Publication date |
---|---|
US20030023528A1 (en) | 2003-01-30 |
US7720729B2 (en) | 2010-05-18 |
AU2002329648A1 (en) | 2003-02-17 |
AU2002329649A1 (en) | 2003-02-17 |
WO2003012585A2 (en) | 2003-02-13 |
WO2003012585A3 (en) | 2003-10-30 |
AU2002322709A1 (en) | 2003-02-17 |
US20100185548A1 (en) | 2010-07-22 |
US7231362B2 (en) | 2007-06-12 |
AU2002329648A8 (en) | 2009-07-30 |
US20030023527A1 (en) | 2003-01-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20030023539A1 (en) | Systems and methods for facilitating agreement definition via an agreement modeling system | |
US11568486B2 (en) | System and method for conducting web-based financial transactions in capital markets | |
US7392210B1 (en) | Workflow management system and method | |
US10387952B1 (en) | System and method for conducting web-based financial transactions in capital markets | |
US7165044B1 (en) | Investment portfolio tracking system and method | |
US8160950B2 (en) | Method and apparatus for trading assets | |
US7310615B2 (en) | Financial data reporting system with alert notification feature and free-form searching capability | |
US7734518B2 (en) | Method and system for effecting straight-through-processing of trades of various financial instruments | |
US7877320B1 (en) | System and method for tracking and facilitating analysis of variance and recourse transactions | |
US20080097898A1 (en) | Transaction management system | |
US20020007335A1 (en) | Method and system for a network-based securities marketplace | |
US20020138389A1 (en) | Browser interface and network based financial service system | |
US11526940B2 (en) | System and method for conducting web-based financial transactions in capital markets | |
US20020178099A1 (en) | Methods and systems for managing a portfolio of securities | |
US20040148248A1 (en) | Secondary transfers of restricted interests | |
US20020091628A1 (en) | Credit granting system and credit applying method using the system | |
US8682767B2 (en) | System and method for accessing and displaying data relating to financial securities | |
WO2003012584A2 (en) | Systems and methods for facilitating use of agreement information via an agreement modeling system | |
WO2003012586A2 (en) | Systems and methods for facilitating agreement generation and negotiation via an agreement modeling system | |
CA2478021A1 (en) | System and method for conducting web-based financial transactions in capital markets | |
AU780518B2 (en) | System and method for conducting web-based financial transactions in capital markets |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: GOLDMAN, SACHS & CO., NEW YORK Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:WILCE, SCOT D.;GEORGE, VINCENT A.;NGUYEN, HIEN Q.;AND OTHERS;REEL/FRAME:012512/0480;SIGNING DATES FROM 20011110 TO 20011119 |
|
AS | Assignment |
Owner name: GOLDMAN SACHS & CO. LLC, NEW YORK Free format text: CHANGE OF NAME;ASSIGNOR:GOLDMAN, SACHS & CO.;REEL/FRAME:043177/0001 Effective date: 20170428 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- AFTER EXAMINER'S ANSWER OR BOARD OF APPEALS DECISION |