EP0765503A1 - Systeme oriente objets servant a creer, a structurer, a manipuler et a evaluer un instrument financier - Google Patents

Systeme oriente objets servant a creer, a structurer, a manipuler et a evaluer un instrument financier

Info

Publication number
EP0765503A1
EP0765503A1 EP94911492A EP94911492A EP0765503A1 EP 0765503 A1 EP0765503 A1 EP 0765503A1 EP 94911492 A EP94911492 A EP 94911492A EP 94911492 A EP94911492 A EP 94911492A EP 0765503 A1 EP0765503 A1 EP 0765503A1
Authority
EP
European Patent Office
Prior art keywords
term
financial
terms
definition
instrument
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.)
Withdrawn
Application number
EP94911492A
Other languages
German (de)
English (en)
Inventor
James E. Kleckner
Rod A. Beckstrom
Raymund P. Galvin
Sandy L. Ogden
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
C ats Software Inc
Original Assignee
C ats Software Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by C ats Software Inc filed Critical C ats Software Inc
Publication of EP0765503A1 publication Critical patent/EP0765503A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance

Definitions

  • the present invention relates to the field of finance, and within this field, more specifically to computer-implemented financial instrument and transaction structuring and management systems.
  • a "financial instrument” shall refer to the underlying structure of any financial transaction, such as a sale of goods or services, an investment device such as a bond, equity, foreign exchange contract or commodity, a currency, an index, derivatives of other instniments, such as swaps and options, etc.
  • financial transaction such as a sale of goods or services, an investment device such as a bond, equity, foreign exchange contract or commodity, a currency, an index, derivatives of other instniments, such as swaps and options, etc.
  • a financial instrument represents a structured transaction, which may involve foreign currency exchanges, rate indices, contingent events, etc., and which may depend on the performance of one or a portfolio of other instruments.
  • a financial instrument can be used to "manage" aspects of the financial transaction it represents. Examples of such management include pricing, tracking performance, hedging, and monitoring related obligations such as coupon payments, etc.
  • spreadsheets are practicable only for a reasonable number of underlying instruments. For example, some banking institutions have a rule that spreadsheets can only be used for up to five transactions simultaneously. For more than this number of transactions, a custom software system must be used. However, an instrument may have any number of underlying instruments, and further those underlying instniments may themselves be comprised of other instruments. Thus, daily processing of portfolios, which may have hundreds or even thousands of underlying spreadsheets that may need to be aggregated to manage the portfolios, is essentially precluded.
  • SwapWareTM for structuring and modeling interest rate and currency swap transactions, borrowings, and foreign exchange contracts
  • CapWareTM for pricing and modeling caps, floors, collars, and forward rate agreements
  • Equity DerivativesTM for structuring and modeling equity swap transactions
  • StrikeTM for structuring and modeling swaptions and over the counter bond options
  • Elements of a portfolio such as futures contracts associated with a portfolio, may be managed by FuturesTM, and reevaluation, accruals, cash management, duration, convexity, gap analysis, hedging, sensitivity and other analysis may be performed across the various specific products by Risk ManagerTM, also from C «ATS Software, Inc.
  • the present invention is a system for structuring and managing financial instruments.
  • the invention includes a financial framework comprised of a library of functions and data types to support financial applications. It provides components from which processing capabilities can be built.
  • the system is extensible, in that it can accommodate new and arbitrarily complex types of instruments, and tightly integrated, in that it can perform a variety of tasks with regard to the instrument in an integrated fashion.
  • the system enables a user to unambiguously define, price, and revalue any arbitrarily complex instrument and manage the instrument together with other instruments in portfolios to evaluate accounting profit or loss, capital requirements and costs, credit exposure, and to handle reporting requirements, manage risk, assist in meeting regulatory requirements, and produce all documentation relating to the instrument and transactions involving the instrument in a secure environment.
  • the instrument structuring and management system is extensible from one consistent framework, so that new instruments may be defined with established procedures and new procedures can be integrated with existing instruments.
  • the financial framework insulates all software tools from the particular computing environment and globally gathers basic functionality used in all tools. This means that implementation of the present invention is computer platform independent.
  • the database manage- ment service includes a data model, an Application Programming Interface (API), and data persistence, commonly referred to as data save-and-restore.
  • the data model is organized hierarchically into four levels: Libraries, Definitions, Views, and Objects. Through these levels, the data model uniquely identifies each object in the system, allowing objects to be reused as needed.
  • the API provides programmatic interfaces corresponding to each object and its relationships to the other objects in the data model, and allows new terms to be dynamically added to the system at run time.
  • the API further allows external applications to be integrated with the present invention's financial framework so that existing applications and systems can work in concert with the present invention.
  • the API also provides the ability to query the definition or composition of any data type at run time.
  • Data persistence provides the ability to store and retrieve data in a database independent manner.
  • the update management service provides "links" between terms, enabling all data in the system to be updated.
  • An object whose value depends on the value of other objects may be linked to the other objects so that when one of the other objects is modified, the linked object will be notified of the change so that its value may be appropriately modified (e.g., either dynamically or upon user request).
  • the term evaluation engine is a mechanism for evaluating a network of inter ⁇ connected terms. All required term inputs must be evaluated before a term's outputs became valid (i.e., before its outputs can be computed).
  • the evaluation is order independent for inputs, which means that evaluation may be apportioned. Each portion of the evaluation may be performed independently, for example using multiple processors (multiple processes), enabling significantly larger amounts of data and analysis to be handled than heretofore possible for financial instruments.
  • an instrument is comprised of a plurality of interconnected terms.
  • Terms are discrete objects which include at least a storage location, means for putting a value into the storage location, and an output function, and may further include other functions, one or more inputs, private data, etc.
  • terms are encapsulated methods (i.e. , in an embodiment realized in an object oriented programming language environment). Terms may themselves be made up of other terms. The terms are connected together in a network such that appropriate output values from one term may be passed to another term as input values.
  • the terms which comprise an instrument are able to provide, together, sufficient data to allow the system to determine at least the Net Present Value (NPV) of the instrument with regard to a single currency, and may further provide data allowing the system to produce: NPV for any defined currency; partial derivatives such as delta (the first derivative with respect to price of a specified significant variable), gamma (the second derivative with respect to price of a specified significant variable), theta (the first derivative of price with respect to time), and vega (the first derivative with respect to volatility); a listing of payments; profit and loss information; mark-to-market accounting value; etc.
  • NPV Net Present Value
  • the system For each term which receives an input value from a term connected to it, the system automatically checks the type of input value to determine the permissibility of such a connection. The system alerts the user if an attempt is made to connect two terms where the required input value type is incompatible with the supplied output value type. For example, if a term which provides a date data-type output is connected to a mathematical term, such as a square root term that expects as an input a floating point number data-type, the system will alert the user that such a connection is impermissible, since the types are incompatible. Type checking of this sort is done only when a connection is established. Type checking of this sort is referred to herein as strong type checking.
  • an "If-Then-Else” term may test the "if 1 condition to provide any data type as an output.
  • the "if” condition input must evaluate to a Boolean, i.e., "true” or "false”.
  • the output of the If-Then-Else term may be of any type specified by the "then” and "else” inputs, both of which must be of the same or compatible type. The system will alert the user if an attempt is made to connect an input value to the term which is incompatible with the required value type. Establishing the type of input and/or output values from a term as described above is referred to herein as inferred type checking.
  • an instrument may be structured using graphical entry tools provided by a graphical user interface system, using a special Instrument Definition Language, using a spreadsheet system, using a parameter form entry system, etc.
  • a display window in which a graphical representation of an instrument may be constructed.
  • Another window which contains a list of term definitions (referred to herein as a "term list"), provides a number of such term definitions from which users select.
  • a term graphic which is composed of an icon and a graphic display objects, such as a text field, etc.
  • a term editor which may be composed of a member editor, connection editor, display editor, etc., is used to configure the appearance of a term, to make connections between terms, and to edit values of the terms.
  • the software creates actual connections between terms, such as for passing values between terms.
  • an instrument may be represented by a network of connected terms. Instruments constructed with the system may themselves by used as terms in the construction of other instruments.
  • FIG. 1 is an illustration of the general computer architecture of a system within which the present invention may operate;
  • Fig. 2 is an entity relationship diagram showing certain aspects of the architecture of a system according to an exemplary embodiment of the present invention;
  • Fig. 3 is an illustration of a number of user interface applications which may be used to compose definitions, and their relationship to the financial framework, according to one embodiment of the present invention
  • Fig. 4 is an illustration of a term, member, and data structures for input, output, and data storage according to one embodiment of the present invention
  • Fig. 5 is an illustration of the visual features and layout of a graphical user interface of an exemplary embodiment of the present invention.
  • Fig. 6 is an illustration of the relationship between the various instruments comprising one example of an embodiment of the present invention.
  • Fig. 7 is a table of price samples for past, present, and future performance of an equity forming a part of an example of an embodiment of the present invention
  • Fig. 8 is an illustration of the state of a portion of the graphical user interface after certain steps are performed to assemble an equity instrument in an example of an embodiment of the present invention
  • Fig. 9 is an illustration of a term graphic representing the equity instrument shown in Fig. 8.
  • Fig. 10 is an illustration of the state of a portion of the graphical user interface after certain steps are performed in the assembly of an equity spread instrument in an example of an embodiment of the present invention
  • Fig. 11 is an illustration of the state of a portion of the graphical user interface after certain steps are performed in the assembly of an equity spread NPV term definition in an example of an embodiment of the present invention
  • Fig. 12 is an illustration of a tei graphic representing the equity spread NPV term definition shown in Fig. 11;
  • Fig. 13 is an illustration of the state of a portion of the graphical user interface after certain steps are performed in the assembly of an equity spread volatility term definition in an example of an embodiment of the present invention
  • Fig. 14 is an illustration of a term graphic representing the equity spread volatility term definition shown in Fig. 13;
  • Fig. 15 is an illustration of a term graphic representing the equity spread instrument shown in Fig. 10;
  • Fig. 16 is an illustration of the state of a portion of the graphical user interface after certain steps are performed in the assembly of an equity spread call option instrument in an example of an embodiment of the present invention
  • Fig. 17 is an illustration of a term graphic representing the equity spread call option instrument shown in Fig. 16;
  • Fig. 18 is an illustration of the state of a portion of the graphical user interface after certain steps are performed in the assembly of an Ajax-Monolithic equity spread call option instrument in an example of an embodiment of the present invention.
  • Fig. 19 is an illustration of the method for accessing external terms according to one embodiment of the present invention.
  • Fig. 1 illustrates the general architecture 10 of a system of the type within which the present invention operates.
  • Architecture 10 comprises a main bus 12, which serves to interconnect various components, including at least some of the following: Central Processing Unit (CPU) 14, Floating Point Unit (FPU) 16, Integrated Circuit Processor (ICP) 18, Bus Controller 20, Video RAM 22, Dynamic RAM (DRAM) 24, Static RAM
  • CPU Central Processing Unit
  • FPU Floating Point Unit
  • ICP Integrated Circuit Processor
  • Bus Controller 20 Video RAM
  • DRAM Dynamic RAM
  • Static RAM Static RAM
  • SRAM Serial Bus RAM
  • DSP Digital Signal Processor
  • Internal Hard Disk External Memory Device 32
  • SRAM Serial Bus RAM
  • External Network Devices 36 communicate for example over an Ethernet Network 38, and connected via SCSI port 34
  • Display Device 40 such as a CRT
  • Printer 42 such as a PostScript device connected for example via a serial port 44
  • Keyboard 46 and Pointing Device 48 (such as a mouse, trackball, etc.)
  • Pointing Device 48 such as a mouse, trackball, etc.
  • GUI graphical user interface
  • a user interacts with the computer using a keyboard and pointer control mechanism such as a mouse.
  • pointer control mechanism such as a mouse.
  • the result of a user's interaction with a software application is displayed in a region of the screen referred to as a window.
  • Software application packages, documents, files and the like may be represented as icons, and launched or opened by aligning the pointer over the icon and double clicking a button on the mouse.
  • the NeXTStep element itself consists of four components: the Workspace Manager, the Interface Builder, the Applications Kit, and the Window Server.
  • the Workspace manager is the user interface component which displays files and directories, manages the icon dock (a region of the display screen in which icons representing application software are located), and launches applications.
  • the Interface Builder is the user interface component which allows an application designer to lay out the application's user interface.
  • the Application Kit is a software library of graphical objects such as windows and buttons.
  • the Window Server is the user interface component which manages the display screen, handling drawing requests for the various running programs, and determining which programs will be notified about events such as mouse clicks and key presses.
  • the Window Server in turn calls Display PostScript to perform any actual drawing required, either for the display or for printing.
  • Entity relationship diagram 500 showing a high-level view of the organization of data within one embodiment of a system according to the present invention.
  • Entity relationship diagrams are commonly associated with object oriented software systems, although the architecture represented by such a diagram may be applied to other systems.
  • the boxes shown in Fig. 2 correspond to entities.
  • An entity relationship diagram provides details about the high level data organization of the software system.
  • One implementation method is the use of classes of the C+ + programming language to represent entities and pointers or pointer-like data types to represent relationships.
  • programmer-defined classes provide data abstraction by allowing the representation details of objects to be hidden and accessed exclusively through a set of operations defined by the class.
  • Entity entity 502 may provide, for example, the methods for objects to be created, the strategy for dynamic memory allocation and deallocation, the storage and retrieval methods, etc.
  • the user interface according to the present embodiment may be event driven.
  • An event is a significant, asynchronous change in the system that requires processing.
  • An example of an event is the click of a button on a pointing device such as mouse (not shown).
  • the user interface is "driven" by events since user and the system interface via events.
  • the evaluation engine described below is, however, demand driven. That is, an event initiates a system action, and there are no further events until the system returns a value, which may be after significant processing activity by the system.
  • Entity entity 502 may provide, for example, the methods for event handling, and further that the interface need not be event driven.
  • the " " sign denotes an "is a” relationship.
  • An “is a” relationship means that the definition of an object of one class is a variation of the definition of objects of another class. (The “is a” relationship is similar to the concept of inheritance in languages such as C+ + , but implies less detail about the nature of the objects and relationships between classes.)
  • the Library entity 504 is an Entity entity 502. That is, all members of the Library class are also members of the Entity class. The same is true for the Definition entity 506, View entity 508, and Object entity 510. Each member of these classes is also a member of the Entity class.
  • An arrow with a single arrowhead shown in Fig. 2 denotes a singular relationship.
  • the single arrow pointing from the Entity entity 502 to the Definition entity 506 means that there is only one definition of the Entity entity 502 (i.e. , each entity is uniquely defined).
  • An arrow with a double arrowhead denotes a plural relationship.
  • the double arrowhead side of the arrow pointing between the Library entity 504 and the Definition entity 506 means that the Library entity may have multiple definitions.
  • a single or double arrow may have an optional "O” or "
  • the "O” (for optional) means that the relation may have zero entities and be empty.
  • the " I " implies that the relationship must have exactly one entity in the relationship.
  • the single arrowhead side of the arrow pointing between the Library entity 504 and the Definition entity 506 has a "
  • the system according to the present invention implements a run-time type system similar to that of Smalltalk (see, e.g., Goldberg, Adele SMALLTALK-80: THE
  • a run-time type system uses a special object to describe the types of data in the system and permits some common operations on the data such as create, delete, copy, etc. This special object is sometimes called a "metaclass” object. In this system it is called a "Definition" object.
  • the definition is also used to access type-specific information such as sub-types contained in the type, functions (or methods) that operate on the type, and input data needed by the functions.
  • a number of interface applications may be used to compose definitions.
  • Fig. 3 illustrates several such applications, including graphical editor 602, spreadsheet application 604, Instrument Definition Language (LDL) interface 606, and form entry interface 608.
  • Interface with a Framework Programming Interface (FPI) 610 of the financial framework is accomplished via an appropriate compiler 612, 614, 616, 618.
  • the financial framework interfaces to the database 620.
  • FPI Framework Programming Interface
  • API Application Programming Interface
  • Appendix A attached hereto.
  • Appendix B is a description of data structures suitable for implementing the mechanism according to one embodiment of the present invention.
  • Cats specifies the software package, and forms no other part of the code, instructions or data listed therein.
  • the prefix does not form a limitation of the API and structures.
  • Each definition contains a collection of "named" View entities (views) 508.
  • Names of objects are similar to path names, and follow the data organization model discussed above (Fig. 2).
  • the name Library_A: Definition First: View_Interface:Object_Payment_List refers to the object named "Object_Pay- ment List” in the view named "View_Interface” in the definition named "Defini- tion First" in the library named "Library_A".
  • the name of an entity uniquely defines it within its scope.
  • two libraries may not have the same name
  • two definitions within the same library may not have the same name
  • two views within the same definition may not have the same name
  • two objects within the same view may not have the same name.
  • Each view has a type, for example interface, model, icon or editor.
  • An interface view of a definition declares the definition's Application Programming Interface (API). Therefore, in this embodiment of the present invention, each definition is required to have an interface view, and there is permitted only one interface view for a definition. It is through the interface view that the input and output members of a definition can be accessed.
  • API Application Programming Interface
  • Each view consists of a collection of named Object entities (objects) 510.
  • Object names are unique within the scope of their containing view.
  • the primary building blocks for structuring an instrument are terms. Terms may include one or more data buffers that are declared by
  • Member entities members 522 in the definition of the term (as found by following the "is a" relation on the object base class).
  • an input or output is the combination of a term and a member, marked as input or output in the definition of the term.
  • a member may be used as an input, as an output, or as both input and output.
  • a member may be used as a storage location (or assigned a value).
  • Input and output members declare the public interface of a definition. When a definition is instantiated as a term, the public interface of that definition becomes the inputs and outputs of the term. All members marked as input and/or output of a single definition are contained in the interface view for that definition for convenience of access in the current embodiment.
  • Example:Interface 702. The term named "ToTerm” 706 has one input 710 that is connected to the term named "FromTerm” 704.
  • FromTerm 704 is an instance of the definition Library .FromTerm (not shown) that is created by the view Libra ⁇ ry: FromTerm: Interface 720.
  • Library:FromTerm:Interface 720 contains exactly one member 722 named "OutMember" that is marked as an output member by setting an
  • ToTerm 706 is an instance of the definition Library:ToTerm (not shown) that is created by the view Library:ToTerm:lnterface 730.
  • Library: ToTerm: Interface 730 contains exactly one member 732 named "InMember" marked as an input by setting an Islnput value for it to True.
  • Input data structure 710 is accessed from ToTerm 706 and contains pointers to FromTerm 704, OutMember 722, InMember 732, and a value buffer 712 for holding data of the type of the connection.
  • the evaluation of the present embodiment is demand driven, meaning that a term will only receive an input if and when it "demands" it from another term.
  • Term 706 demands a value from a term 704. Appropriate methods for this demand will be part of the Definition of view 720 from which Term 706 is instantiated.
  • Input data structure 710 contains the address of the "From" term 704.
  • Term 706 This is used by Term 706 to identify the term providing the demanded value.
  • Input data structure 710 contains a pointer to OutMember 722 of the From term that returns the demanded value. (Together, term 704 and Member 722 form an "input object" 710 containing all information needed to obtain data from another term.)
  • the manner in which the From term 704 provides the value to Term 706 is that as part of the demand for a value, Term 706 provides its own memory location into which the From term 704 will write the value. This memory location is identified by Value Buffer 712. The value of the FromTerm 704 is thus made available to ToTerm
  • GetFunc 742 by looking up the GetFunc 742 function and calling it with the arguments of FromTerm 704, OutMember 722, and value buffer 712.
  • the GetFunc 742 function proceeds to evaluate any inputs in a similar fashion (none in this example) and then stores the proper value into value buffer 712 and returns.
  • the "get function" stored in GetFunc 742 for a compiled term can be implemented as a member function of its associated class. As a result, the OutMember 722 argument need not be consulted since the proper offset into the term's data structure is provided by the C+ + compiler. For structurally composed terms, the OutMember 722 causes the FromTerm 704 value to be stored on the definition of FromTerm (not shown).
  • the Output data structure 708 may perform a substantial role in the update function.
  • Input data structure 710 may perform one other function, which is to serve simply as a data storage location for Term 706. In this case, the pointers other than the value buffer 712 are not used. In all three cases (input, output, and storage), the memory space of the unused components may be captured for other purposes, thereby reducing required memory space.
  • a network of interconnected terms forms an evaluation network.
  • An input of a term may be connected (via a "ConnectO" function) to the output of any term contained within any of the views of the same definition, provided that the "signature” or type of the input and output are "compatible. " The signatures are compatible if the type of the data on the input is equal to or is a subclass of the type of the data on the output. It is important to recognize that connections are not made between definitions. Rather, each definition can be instantiated (as a term) within a view (or views) of a new definition, and the connection is made between terms within the scope of the new definition.
  • connection represents a class that is used to simplify the specification of several complex relationships among members and terms.
  • the connection class is not an entity, and is not itself stored in the system's "persistent store.”
  • the graphical user interface 50 of this embodiment comprises a number of windows displayed in a workspace 52 on a display device such as the display device 40 discussed above.
  • the first window displayed in workspace 52 shown in Fig. 5 is the view window 54 in which term definitions and instruments are structured and displayed.
  • instruments are comprised of terms, and a term definition list containing a number of definitions of terms from which a user may select to build an instrument are displayed in the Term Defimtion List window 56.
  • a number of icons representing terms or instruments, either precompiled or created by the user, may also be provided to simplify the instrument structuring process. These icons are presented in a palette window 57.
  • a selection of tools are also provided for the construction, as well as the display of the visual aspects of an instrument, related text, and graphical objects, similar to well-known computer drawing programs. These tools are displayed in the tool window 58.
  • a user may view and edit a term during or after construction using various editors, such as a member editor, connection editor, and display editor. Selection of the editor is made in the Term Editor window 60.
  • selection of objects such as terms, tools, editor, etc. is accomplished by positioning the pointer 62, using a pointer device 48 (such as a mouse) and actuating (clicking) a button 64 located on the pointer device 48.
  • a pointer device 48 such as a mouse
  • actuating clicking
  • a button 64 located on the pointer device 48.
  • one or more pull down menus such as menu 66
  • keyboard “shortcuts” for certain selections such as “CMD S” (actuation of the "command” and “S” keys simultaneously) which performs the save command, are provided.
  • the instrument of this first example will be a particular type of option known as a spread option.
  • the instrument underlying this type of option is not a specific, single security, but rather the value of a relationship, for example between two different securities.
  • Spread options are often used for hedging; that is, for securing a backup position in the event that one investment fails to be profitable. For a more detailed discussion of spread options, see Marki, Susan Ross, DERIVATIVE
  • the particular option that shall be structured in this example is an equity spread option between the price of Ajax Corporation shares and Monolithic Corporation shares.
  • Ajax Corporation is primarily in the hardware business
  • Monolithic Corporation is primarily in the software business.
  • This spread option might then represent an investment based on the belief that hardware will be more profitable than software (or vice versa).
  • the option is a call option, meaning that it is an option to buy shares.
  • the option of this example shall be referred to as the "AMESCO" option, for Ajax-Monolithic Equity-Spread-Call- Option.
  • Fig. 6 illustrates the AMESCO option, with reference to other figures where appropriate.
  • the structure of instrument 550 of this example is an equity-spread-call- option trade definition 240, which contains instances Ajax 130 and Monolithic 131 of
  • the Equity Spread Instrument Defimtion 150 contains an instance Equity_Spread_Volatility 155 of the definition Equity Spread Volatility 154 and an instance Equity_Spread_NPV 180 of the defimtion Equity Spread
  • the Equity Spread Call Option Instrument definition 200 contains an instance 224 of the definition Black-Scholes 551.
  • the Ajax_equity_instrument term 130 and the Monolithic_equity_instrument term 131 will each provide: (1) their Net Present Value (NPV); (2) volatility; and (3) instrument name.
  • Volatility is the measure of the expected standard deviation of a price of an instrument in one year with respect to a significant variable, for example, the expected standard deviation of the price of an Ajax equity share one year from the present date, in U.S. dollars.
  • the equity instrument In order to determine the NPV, the equity instrument must obtain either a "fixed" price for a particular instrument on a particular date, or a calculated (or forecast) price of the instrument on a particular date. "Fixed" prices are provided if the date for which the NPV is to be obtained is a date for which the system has access to an actual closing price for the equity. Otherwise, calculated prices are provided.
  • Fig. 7 shows a table 700 of Ajax closing prices. The price of an Ajax share is fixed at the close of business each day. Prices in the table for past share closing- prices, or actual past performance, of Ajax shares are fixed prices shown in region 702 of table 700.
  • price samples in the table for dates prior to the present date generally return a fixed value as indicated by a "Y" (for yes) in the Fixed? column.
  • These fixed values may be entered manually, or may be acquired from a real time data feed service 704. It is also possible to associate an identification of the person fixing a price with each fixed value, such as the data of the Fixer column. Alternatively, a user may be provided with the ability to manually enter a price for the equity in order to simulate an event or model an instrument's performance for evaluation, etc.
  • the value of the equity is not yet fixed.
  • the value may be the actual present value, since the data may be returned from a real time data feed service or otherwise entered once acquired, or may be calculated if there is insufficient access to the actual value.
  • Price samples for dates other than those which the system has actual historical values for will return a calculated price. For example, future performance will be based on forecast prices as shown in region 708, and calculated past performance is shown in region 710. The actual manner in which the price sample is determined is beyond the scope of this disclosure. However, it is sufficient to note that the algorithm or other methodology for calculating the value may form a portion of the definition of the price sample term, so that the value may be calculated based on inputs from other terms, or the value may be predetermined and manually entered by the user either into a table such as that shown in Fig. 7 or entered directly as an input into the equity instrument 556 (Fig.
  • entry of the appropriate value into the price sample term may be handled by way of an interactive editor portion of the system.
  • FIG. 5 there is illustrated therein the initial state of the system for the structuring of the AMESCO option.
  • the view window 54 is initially blank, and the term list, palette, tools, and editor windows 56, 57, 58, and 60 are displayed.
  • FIG. 8 there is illustrated therein the state of the system after several steps in the process of structuring the AMESCO option have been performed.
  • the first step in structuring the option is to construct the two underlying equity instniments 556 and 558.
  • a view window 100 is created for the Ajax equity instrument. It is assigned the name Demo:Equity_Instrument:Interface according to the syntax discussed above.
  • a number of terms are then selected from either the term list window (not shown) or the palette (also not shown), and graphic display objects or icons representing those terms are located in the view window 100.
  • Fig. 8 shows a number of term graphics representing terms placed in view 100.
  • Curve import term 102 represents a Curve import term 102, a Volatility term 104, and a Curve rate term 106.
  • a term graphic is a rectangular region containing a text portion for displaying a term name, a display portion for displaying one or more of the term's values, and an interactive portion, such as a slider control, buttons or the like for modifying the term's values.
  • aspects of the creation of the interface of the system may be handled by an interactive display editor portion of the system, while the user's interaction with that interface is handled by the system itself (with certain exceptions such as text editing, which may be passed to a text editor).
  • the user is provided with the ability to control which values are displayed by a term graphic.
  • a "switch" may be provided in the members portion of the Term Editor window 60 (shown in Fig. 5) for selecting the individual values of a term, its inputs and outputs, etc., for display.
  • the user initially selects the connection view option from the Term Editor window 60 (shown in Fig. 5), for example by way of a pull down menu.
  • the user next selects a term or member which is to receive an input, for example by positioning the pointer over the term and clicking the mouse button.
  • the connections view in the Term Editor window is shown in Fig. 5
  • the user 60 will then provide a list of the possible inputs to that term or member from which the user may choose. Once the input is selected, the user selects the term or member for providing the output. While holding down an appropriate key or the mouse button, the user moves the mouse to position the pointer over the term or member providing the output to be connected to the selected input, then releases the button or key. This causes a graphical connection 118-128 to be established and displayed between the terms and/or members.
  • an underlying connection is established between the two terms in software.
  • This underlying connection can serve a number of purposes, but in its most basic form it is a call by one term to another term, for example to pass a value between the terms.
  • data is caused to be written to support an underlying physical interconnection (via software) between the terms.
  • Terms may also be connected by referencing the name of the term, for example by using the term's name in an equation. This type of connection is referred to as a connection by name, an example of which is provided below.
  • Curve import term 102 inputs a curve name and, based on the curve name, reads a file representing a curve.
  • the file may be the file illustrated in Fig. 7.
  • the data read into memory by the Curve_import term 102 is then made available to the
  • Curve Rate term 106 Although the file contains data representing actual closing prices of the equity, that data may be used by the Curve rate term 106 to calculate the values of the prices for dates other than those stored in the file. For example, interpolative algorithms (or other techniques) may be used to determine the closing price of the Ajax equity for dates earlier than the earliest available actual closing price, or to predict the closing price at some date in the future. Thus, the NPV may be determined by the appropriate method by the Curve rate term 106 by utilizing the data provided by the Curve import term 102 and the date provided by the Date member 110.
  • the volatility may be calculated by the Volatility term based on the data provided by the Curve import term 102.
  • Formula for calculating the volatility are well known in the art. See, for example, Figlewski, et al., FINANCIAL OPTIONS: FROM THEORY TO PRACTICE (Business One Irwin 1990), which is incorporated herein by reference.
  • a term's value for example volatility in the case of the Volatility term 104, that value may be entered manually, or imported from another system or routine. In the case where the value is entered manually, that entry may be by way of an input member, as previously discussed, or may be by way of private data as discussed in further detail below.
  • the equity instrument 556 may be instantiated as a term using a term graphic composed of an icon of the user's choosing, for example as stored in a TIFF file or the like, together with a graphic display object (such as a text field, slider control, etc.) (This graphic display object is one type of graphic entity 516 shown in Fig. 2.)
  • a graphic display object such as a text field, slider control, etc.
  • This graphic display object is one type of graphic entity 516 shown in Fig. 2.
  • the desired term graphic representation of the instrument is selected. This may be displayed as term graphic 130 shown in Fig. 9.
  • Term graphic 130 may be given a unique name 113, such as "Ajax", and certain of its values displayed as appropriate, for example the outputs volatility 114,
  • NPV 116 Instemper name (not shown), and "isa” 112 (which is the type of every entity and thus term as well).
  • the next instrument that is structured according to the present example is an Equity_spread instrument 150 shown in Fig. 10.
  • This instrument is itself composed of two terms, an Equity_spread_NPV 180, which is an instance of the Equity_spread_NPV definition 152 and Equity_spread_volatility 155, which is an instance of the Equity_spread_volatility definition 154.
  • Equity_spread term 150 also includes input members Equityl_NPV 156, Equity2_NPV 158, Equityl_ volatility 160, Equity2_volatility 162, and Covariance 164.
  • Equity_spread_instmment 150 includes output members Instrument_name 166, NPV 168, and Volatility 170.
  • Equity_spread_NPV term definition 152 consists of a DoubleMath21n term 172, input members Equity I NPV in 157 and Equity2_NPV_in 159, and output member NPV out 174.
  • Input member Equity I NPV in 157 is connected to the Equity 1
  • NPV input term 156 shown in Fig. 10, which in turn is connected to NPV output term
  • DoubleMath21n term 172 is an instantiation of a generic math term and the "subtract" output is connected to the NPV out output member 174. As its name implies, DoubleMath21n term performs its subtract function on 2 values, A and B, each value being a double precision floating point number.
  • NPV_out 174 which is also a double precision floating point number, and which is connected to NPV term 168 shown in Fig. 10.
  • DoubleMath21n term 172 displays the values of A, B and the result of the subtraction.
  • the Equity_spread_NPV term 152 is represented by a term graphic 180, displaying the instrument's name and the value of the NPV output member 174, as shown in Fig. 12.
  • the second term which comprises Equity Spread lnstrument 150 is Equity_Spread_Volatility 154. It is created in much the same fashion as Equity_spread_NPV term 152, but with one distinction worth mentioning. As shown in
  • the Equity_Spread_Volatility instrument 154 consists of Formula term 182, input members Equityl_volatility_in 161, Equity2_volatility_in 163, and Covariance in 166, and output member Volatility_out 169.
  • Equity l_volatility_in term 161 is connected to Equity l_volatility term 160, shown in Fig. 10
  • Equity2_volatility in term 163 is connected to Equity2_volatility term 162, shown in Fig. 10
  • Covariance in term 166 is connected to Covariance term 164, also shown in Fig. 10.
  • Volati ⁇ ty out term 169 is connected to Volatility term 170.
  • Formula term 182 is defined with reference to variable names, such as Equityl_volatility_in, Equity2_volatility_in, and Covariance in.
  • variables names such as Equityl_volatility_in, Equity2_volatility_in, and Covariance in.
  • connections are made between the input members and the terms by using text names. Graphical connections described above need not be made.
  • a graphical connection 184 is shown in Fig. 13 between formula term 182 and output member Volatility out 169.
  • this instrument may be represented by a icon 155, shown in Fig. 14.
  • member names alone do not imply a connection.
  • members with the same name such as NPV output term 168 of Fig. 10 and NPV input term 202 of Fig.
  • Equity_spread_NPV 152 represented by term graphic 180
  • Equity_spread_volatility 154 represented by term graphic 155.
  • Equity_spread instrument 150 may, itself, be represented as a term graphic 190 together with a display of desired values such as NPV 168 and Volatility 170, as shown in Fig. 15.
  • the final instrument which needs to be structured for the AMESCO example is the Equity_spread_call_option instrument 200, shown in Fig. 16.
  • the Equity- spread_call_option instrument 200 consists of input members Underlying_price 202, Strike_price 204, Volatility 206, Risk_free_rate 208, Value_date 210, and Expiration_date 212, and output members NPV 214, Delta 216, Gamma 218, Theta 220, and Vega 222. These output members correspond to the outputs of a term which implements the Black-Scholes option pricing model 551, the Black Scholes term 224.
  • selected values used by the Black_Scholes term 224 may be part of the definition of the term itself, as opposed to an input.
  • the user in the process of instantiating the defimtion as a term, the user is provided with the opportunity to enter values into the term via the members editor for the term. Data entered in this fashion is referred to as private data, since it is not readily apparent to the user. Private data may be "locked" into a term. Those with proper authority may be permitted to access and modify the data, while those without the proper authority may only view the term. This provides both a security function and data integrity.
  • the Equity_spread_call_option instrument 200 may be instantiated as a term and represented by a term graphic 230 together with selected values such as those of the output members, as shown in Fig. 17.
  • the completed AMESCO instrument 240 comprised of the underlying terms and instruments represented by their term graphics 130, 131, 190, and 230, is shown in Fig. 18. It will be appreciated that the AMESCO instrument 240 may itself be represented by a single term graphic (together with appropriate values) and used in the structuring of another instrument, for example representing an option on this option or the like (not shown).
  • Instruments structured by the above process and using the system of the present invention may be managed in a multitude of ways. For example, given a large number of instruments such as a portfolio of AMESCO instruments structured per the above discussion, it may be desirable to produce a list of obligations, resets, payments, risk measures or other attributes of the instruments. This would be facilitated by the present invention by building into the definition of each instrument Make list terms which produce lists of desired objects or attributes for that instrument. In turn, when defining the portfolio instrument, a user would employ a Make_list term to produce a "master" list of the desired objects or attributes from the lists produced by each instrument's Make_list. An additional term may then be used to "filter” or sort the master list to produce subsets of the attributes, for example all obligations due on or after a certain date, etc.
  • Another aspect of the present invention is the ability to export and import data from the system for structuring and management of a financial instrument (importing data has been addressed briefly above).
  • the Integrated ASCII import export mechanism allows data from the system's database to be imported and exported from/to an ASCII file. This allows the data to be employed in existing financial packages. For example, the profit or loss, capital requirements, credit exposure, etc. of individual instruments or portfolios of instruments may be managed by the aforementioned Risk ManagerTM from C «ATS Software, Inc.
  • the records are organized into logical groups.
  • the data within one group forms a unit within the system's database (e.g., a cashflow, a trade).
  • the groups are identified by a start and end label of the format BEGIN XXXX and END XXXX, where XXXX is the group identifier.
  • the group identifiers (and keys) are: Transactions: BEGIN TRANBASE
  • SQL I O Another example is the SQL I O, which allows a user to write data from the system to an SQL database. This is accomplished by writing an SQL statement from the system. Inputs
  • An SQL I/O which evaluates and prints each input as an SQL string to a file which may be sent to a database, such as a Sybase database.
  • a typical path name used by one embodiment of the present invention is: ProgName
  • VALUES valuel, value2, . . .
  • Figure 19 details the calling of external functions (e.g., main, executable) from an external source.
  • external functions e.g., main, executable
  • programs may be written in most modern programming languages such as C, C+ + , FORTRAN, as shell script programs, etc., which augment the capabilities of a system according to the present invention.
  • the method for accessing these external functions is as follows.
  • an instrument 300 has been partially created according to the above description.
  • Instrument 300 includes an external function call term 302, which includes an output 304 and an input member 308.
  • Term 302 further includes an identifier 312 of the external function to be called, such as the pathname of the routine.
  • the values are passed to the external program 314 as parameters, and the results from the external program 314 are returned to the external function call term 302.
  • the present invention enables a user to unambiguously define, price, and revalue any arbitrarily complex instrument and manage the instrument together with other instniments in portfolios to evaluate accounting profit or loss, capital requirements and costs, and credit exposure, and to handle reporting requirements, manage risk, assist in meeting regulatory requirements, and produce all documentation relating to the instrument and transactions involving the instrument in a secure environment.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Stored Programmes (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Système servant à structurer et à gérer un instrument financier. Il comprend un cadre financier composé d'une bibliothèque de fonctions et de types de données exploités par des applications financières. Le système permet à l'utilisateur de définir (60) un quelconque instrument financier à complexité arbitraire, d'en établir le prix (721) et de le réévaluer (60) sans ambiguïtés. Il permet également de gérer l'instrument conjointement avec d'autres instruments compris dans des portefeuilles (56), en vue d'évaluer les bénéfices et les pertes de compatibilité, les besoins en capitaux et les frais d'immobilisations, et le risque de crédit, et de gérer les exigences de déclaration, de gérer les risques, de faciliter le respect des exigences réglementaires, et de produire dans un environnement sûr toute la documentation associée à l'instrument et aux transactions impliquant celui-ci. Les instruments, composés de réseaux de termes interconnectés, peuvent faire partie d'autres instruments.
EP94911492A 1993-03-09 1994-03-04 Systeme oriente objets servant a creer, a structurer, a manipuler et a evaluer un instrument financier Withdrawn EP0765503A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US2836093A 1993-03-09 1993-03-09
US28360 1993-03-09
PCT/US1994/002468 WO1994020912A1 (fr) 1993-03-09 1994-03-04 Systeme oriente objets servant a creer, a structurer, a manipuler et a evaluer un instrument financier

Publications (1)

Publication Number Publication Date
EP0765503A1 true EP0765503A1 (fr) 1997-04-02

Family

ID=21843023

Family Applications (1)

Application Number Title Priority Date Filing Date
EP94911492A Withdrawn EP0765503A1 (fr) 1993-03-09 1994-03-04 Systeme oriente objets servant a creer, a structurer, a manipuler et a evaluer un instrument financier

Country Status (4)

Country Link
EP (1) EP0765503A1 (fr)
JP (1) JPH08507629A (fr)
AU (1) AU6398994A (fr)
WO (1) WO1994020912A1 (fr)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
US6134536A (en) 1992-05-29 2000-10-17 Swychco Infrastructure Services Pty Ltd. Methods and apparatus relating to the formulation and trading of risk management contracts
JP4795500B2 (ja) 1995-07-07 2011-10-19 スワイッコ インフラストラクチャー サービシーズ プロプライエタリー リミテッド 投資契約の定式化及び取引に関する方法及び装置
WO1997008634A1 (fr) * 1995-08-23 1997-03-06 International Business Machines Corporation Procede et systeme informatique servant a produire des programmes informatiques de gestion de processus, a partir de modeles de processus
US6119103A (en) 1997-05-27 2000-09-12 Visa International Service Association Financial risk prediction systems and methods therefor
US6018723A (en) 1997-05-27 2000-01-25 Visa International Service Association Method and apparatus for pattern generation
US7127420B1 (en) * 1997-08-01 2006-10-24 Financial Systems Technology (Intellectual Property) Pty. Ltd. Data processing system for complex pricing and transactional analysis
JP2000020618A (ja) * 1998-06-30 2000-01-21 Iq Financial Systems Japan Kk 統合金融リスク管理装置および金融取引モデル化装置
US7801782B2 (en) * 1998-07-31 2010-09-21 Jpmorgan Chase Bank, Na Object oriented system for managing complex financial instruments
FR2792746B1 (fr) * 1999-04-21 2003-10-17 Ingmar Adlerberg PROCEDE ET AUTOMATISME DE REGULATION D'UNE PRODUCTION INDUSTRIELLE ETAGEE AVEC MAITRISE D'UN STRESS ENCHAINE ALEATOIRE, APPLICATION AU CONTROLE DU BRUIT ET DU RISQUE VaR D'UNE CHAMBRE DE COMPENSATION
SG97839A1 (en) * 2000-01-28 2003-08-20 Pi Eta Consulting Company Pte Fully flexible financial instrument pricing system with intelligent user interfaces
US6999943B1 (en) 2000-03-10 2006-02-14 Doublecredit.Com, Inc. Routing methods and systems for increasing payment transaction volume and profitability
US7596523B2 (en) 2002-09-09 2009-09-29 Barra, Inc. Method and apparatus for network-based portfolio management and risk-analysis
US8239299B2 (en) 2007-02-26 2012-08-07 Microsoft Corporation Type-driven rules for financial intellegence

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4989141A (en) * 1987-06-01 1991-01-29 Corporate Class Software Computer system for financial analyses and reporting

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO9420912A1 *

Also Published As

Publication number Publication date
JPH08507629A (ja) 1996-08-13
WO1994020912A1 (fr) 1994-09-15
AU6398994A (en) 1994-09-26

Similar Documents

Publication Publication Date Title
US5220500A (en) Financial management system
US7693731B1 (en) Business process framework for reinsurance
US7359863B1 (en) Condition component framework for reinsurance
US8312416B2 (en) Software model business process variant types
US8099347B2 (en) Object oriented system for managing complex financial instruments
US7805497B2 (en) Method and product for calculating a net operating income audit and for enabling substantially identical audit practices among a plurality of audit firms
US20090138307A1 (en) Automated financial scenario modeling and analysis tool having an intelligent graphical user interface
US6985878B1 (en) Integrated finance risk manager and financial transaction modeling device
US20050182709A1 (en) Automated financial scenario modeling and analysis tool having an intelligent graphical user interface
US20070239581A1 (en) A data processing framework for financial services
US20040236673A1 (en) Collaborative risk transfer system
Birrer et al. Frameworks in the financial engineering domain an experience report
EP0765503A1 (fr) Systeme oriente objets servant a creer, a structurer, a manipuler et a evaluer un instrument financier
US20040181418A1 (en) Parameterized and reusable implementations of business logic patterns
Moulton et al. Context mediation on wall street
CA2361206C (fr) Outil de modelisation et d'analyse de scenario financier automatique a interface graphique d'utilisateur intelligente
US20230245245A1 (en) System and method for node presentation of financial data with multimode graphical views
US11682084B1 (en) System and method for node presentation of financial data with multimode graphical views
Wolf et al. CUBUS-An Assistant for Fundamental Corporate Analysis.
CA2380197C (fr) Cadres objets pour reassurance
EP1826719A1 (fr) Modélisation de scénario financier automatisée et outil d'analyse possédant une interface utilisateur graphique intelligente
Preuner et al. Static–Dynamic Integration of External Services into Generic Business Processes
Lin A unified accounting information framework to modeling bank accounting systems
Eggenschwiler Financial Engineering Domain An Experience Report
CA2891769A1 (fr) Cadres objets pour reassurance

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 19950911

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FR GB GR IE IT LI LU MC NL PT SE

17Q First examination report despatched

Effective date: 19980918

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 19990129