as United States
`a2) Patent Application Publication co) Pub. No.: US 2003/0009408 A1
`Jan. 9, 2003
`Korin
`(43) Pub. Date:
`
`US 20030009408A1
`
`(54) PROVIDING FINANCIAL PORTFOLIO RISK
`MEASUREMENT AND ANALYSIS TO
`REMOTE CLIENT SERVICES VIAA
`NETWORK-BASED APPLICATION
`PROGRAMMING INTERFACE
`
`(76)
`
`Inventor:
`
`Ittai Korin, New York, NY (US)
`
`Correspondence Address:
`Paul D. Greeley, Esq.
`Ohlandt, Greeley, Ruggiero & Perle, L.L.P.
`10th Floor
`
`One Landmark Square
`Stamford, CT 06901-2682 (US)
`
`(21) Appl. No.:
`
`10/132,867
`
`(22)
`
`Filed:
`
`Apr. 25, 2002
`
`300
`
`oe,
`
`Related U.S. Application Data
`
`(60)
`
`Provisional application No. 60/286,791, filed on Apr.
`26, 2001.
`
`Publication Classification
`
`61)
`(52)
`
`(667)
`
`Tint, C07 nce eeecccceeeceeeeeeeececeeenecennnnneeees GO06F 17/60
`US. Cl. cece cesses neniesienessnsenessnsnnesnees 705/36
`
`ABSTRACT
`
`There is provided a computer system having a module for
`controlling a processor to receive a request via a network for
`a risk analysis of an investment, pass the request to a risk
`analysis engine, receive a result of the risk analysis from the
`risk analysis engine, and sendtheresult to a client device via
`the network.
`
`
`
`
`PROCESSING
`A REQUEST
`
`THE API
`RECEIVES A REQUEST
`
`API PASSES THE REQUEST
`
`ANALYTICAL ENGINE
`
`
`
`THE ANALYTICAL ENGINE
`DECODES THE REQUEST
`
`305
`
`310
`
`
`
`315
`
`
`
`
`
`320
`
`
`AGGREGATE
`INDIVIDUAL
`330
`325
`
`
`
`CALCULATE
`
`
`CALCULATE
`AGGREGATERISK
`INDIVIDUALRISK
`
`
`
`
`
`
`GENERATE
`HISTOGRAM
`
`Google Exhibit 1025
`Google v. VirtaMove
`
`Google Exhibit 1025
`Google v. VirtaMove
`
`

`

`Patent Application Publication
`
`Jan. 9, 2003 Sheet 1 of 3
`
`US 2003/0009408 Al
`
`Sil
`
`OcI
`
`scl
`
`WAAYAS
`
`udOsssAo0dd
`
`TIVOILATVNV
`
`HNIONA
`
`IdV
`
`TVOILATVNV
`
`ANIONA
`
`clI
`
`IVIONVNIA
`
`SDIAUHS
`
`UOSsSsAoodd
`
`SOVAAALINI
`
`ATNGOW
`
`SOT
`
`Oll
`
`ACISMAAS
`
`
`
`ACISLNAITOt99}
`
`vit
`
`oy,
`
`1Old
`
`FOVAAALNI
`
`ATAGOWN
`
`WAWOLSNO
`
`NOILVLSYYOM
`
`
`
`
`

`

`Patent Application Publication
`
`Jan. 9, 2003 Sheet 2 of 3
`
`US 2003/0009408 Al
`
`200
`
`_
`
`205
`
`210
`
`215
`
`220
`
`225
`
`ISSUE REQUEST
`
`EXTRACT
`CUSTOMERPROFILE
`
`SET
`DATA PARAMETERS
`
`SET
`OUTPUT PARAMETER
`
`SET
`FORMAT PARAMETER
`
`FIG, 2
`
`

`

`Patent Application Publication
`
`Jan. 9, 2003 Sheet 3 of 3
`
`US 2003/0009408 Al
`
`300
`
`~~,
`
`PROCESSING
`A REQUEST
`
`THE API
`
`API PASSES THE REQUEST
`TO THE
`
`RECEIVES A REQUEST
`ANALYTICAL ENGINE
`DECODES THE REQUEST
`
`305
`
`310
`
`315
`
`THE ANALYTICAL ENGINE
`
`325
`
`
`
`INDIVIDUAL
`AGGREGATE
`330
`
`
`
`CALCULATE
`CALCULATE
`
`AGGREGATERISK
`
`INDIVIDUAL RISK
`
`
`
`335
`
`N
`
`345
`
`GENERATE
`HISTOGRAM
`
`RETURN
`
`FIG. 3
`
`

`

`US 2003/0009408 A1
`
`Jan. 9, 2003
`
`PROVIDING FINANCIAL PORTFOLIO RISK
`MEASUREMENT AND ANALYSIS TO REMOTE
`CLIENT SERVICES VIA A NETWORK-BASED
`APPLICATION PROGRAMMING INTERFACE
`
`CROSS REFERENCE TO RELATED
`APPLICATIONS
`
`[0001] The present application is claiming priority of U.S.
`Provisional Patent Application Serial No. 60/286,791, which
`wasfiled on Apr. 26, 2001.
`
`BACKGROUND OF THE INVENTION
`
`[0002]
`
`1. Field of the Invention
`
`[0003] The present inventionrelates to a computer module
`risk analysis of an investment, and more particularly,
`to
`application program interface (API) that provides an inter-
`face for a risk analysis engine.
`
`[0004]
`
`2. Description of the Prior Art
`
`[0005] A financial service entity, such as a securities
`brokerage, investment advisor, or bank, can provide a vari-
`ety of investment services to a customer who maintains an
`investment portfolio within an electronic data processing
`system. Such investment services include, for example,
`online trading, reporting current value of a portfolio, and
`reporting historical performance.
`
`In the interest of offering timely service, as well as
`[0006]
`to avoid the complexity of development, hardware, soft-
`ware, and data management, the financial service entity may
`wish to dynamically access and embeda setofrisk analysis
`functions provided by a third party Application Service
`Provider (ASP). This embedding would result in the addition
`and close integrationof these third party functions within the
`financial service entity’s application. As such,
`the risk
`management functions would reside on a server processor
`affiliated with the ASP.
`
`[0007] Lxisting risk management systems have been cre-
`ated to reside on the same processors and servers used bythe
`financial service entity. This means that the financial service
`entity must undergo the time and labor expense of locally
`installing risk management software as well as supplying
`additional hardware forit to run on. Additional hardware is
`often necessary due to processor-intensive calculations,
`which may not execute in a timely or feasible manner on
`machines currently used by the financial service entity. In
`addition to hardware and software, risk management appli-
`cations require market data inputs,i.e., current and historical
`security prices. This meansthat in addition to more software
`and computers, existing risk managementsystems require a
`financial service entity to incur the cost and labor of main-
`taining and updating a market database.
`
`[0008] There is a need for an improved method for finan-
`cial portfolio risk measurement and analysis that accesses
`portfolio risk analysis features, at runtime, in a networked
`and distributed manner.
`
`SUMMARY OF THE INVENTION
`
`[0009] The present invention enables a financial service
`entity to provide portfolio risk analysis functions to a
`customer. The customer, as a result, would then be able to
`
`access a range of risk measurementfunctions, and apply the
`functions to his or her own electronically stored investment
`portfolio.
`
`[0010] The primary components of a system in accordance
`with the present invention include a customer workstation,
`a financial service processor and a server processor. The
`server processor includes an analytical engine for perform-
`ing a risk analysis, and an application program interface
`(API)that allows a device external to the server processor to
`access the analytical engine.
`
`In one embodiment of the present invention, the
`[0011]
`customer uses the customer workstation to access the finan-
`
`cial service processor, which in turn sends a request to the
`server processor for a risk analysis. The server processor
`performsthe risk analysis and returns a result to the financial
`processor, and the financial processor sendsthe result to the
`customer workstation. In an alternative embodiment of the
`
`invention, the customer workstation sends a request to the
`server processorfor a risk analysis, and the server processor
`returns the result tot the customer workstation. Regardless of
`whether the request is sent bythe financial service processor
`or the customer workstation, the request is embedded in an
`application program interface (API) call to the API on the
`server processor.
`
`[0012] An embodimentof the present invention is a com-
`puter system having a module for controlling a processor to
`receive a request via a network for a risk analysis of an
`investment, pass the request
`to a risk analysis engine,
`receive a result of the risk analysis from the risk analysis
`engine, and send the result to a client device via the network.
`
`{0013] Another embodiment of the invention is a com-
`puter system having (i) a processor, (ii) a risk analysis
`engine for controlling the processor to perform a risk
`analysis of an investment; and (iii) an application program
`interface (API) for controlling the processorto:
`
`(a) receive an API call via a network, where
`[0014]
`the API call includes a request for the risk analysis;
`
`[0015]
`
`(b) pass the requestto the risk analysis engine;
`
`(c) receive a result of the risk analysis from
`[0016]
`the risk analysis engine; and
`
`(d) send the result to a client device via the
`[0017]
`network.
`
`[0018] The request includes data describing the invest-
`ment. The risk analysis engine includes a plurality of risk
`analysis functions, and the request includes data that selects
`a memberofthe plurality of risk analysis functions.
`
`[0019] The present invention also includes an embodiment
`in a storage media containing instructions for controlling a
`processor. The storage media includes instructions for con-
`trolling the processor to receive a request for a risk analysis
`of an investment, pass the request to a risk analysis engine,
`receive a result of the risk analysis from the risk analysis
`engine, and sendthe result to a client device via the network.
`
`[0020] Another embodiment of the invention is an appli-
`cation program interface (API) for controlling a pracessar to
`(a) reccive a an API call via a network, where the APTI call
`includes a request for a risk analysis of an investment, (b)
`passthe request to a risk analysis engine, (c) receive a result
`of the risk analysis from the risk analysis cnginc, and (d)
`
`

`

`US 2003/0009408 A1
`
`Jan. 9, 2003
`
`“Dollar risk” is a calculated dollar amountthat can
`[0033]
`send the result to a client device via the network. The request
`includes data describing the investment, the risk analysis
`be gained orlost in an investment.
`engine includesaplurality of risk analysis functions, and the
`[0034]
`“Volatility” is a mathematical representation of a
`request includes data that selects a memberof the plurality
`size of an expected fluctuation in a price of an asset. More
`of risk analysis functions.
`technically, it is a standard deviation, which is an average
`size of a square of a deviation, of a price from its mean.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0035]
`“Historical volatility” is a measurement of price
`[0021] FIG.1is ablock diagram of a networked computer
`volatility taken over a set of prices occurring overa histori-
`system configured for employmentof the present invention.
`cal time period such as a week, a month, a year, or several
`years.
`
`[0022] FIG. 2 is a flowchart of a method for setting up a
`request for a risk analysis, using an API call.
`
`[0023] FIG. 3 is a flowchart of a method for processing a
`request for a risk analysis via an API.
`
`DESCRIPTION OF THE INVENTION
`
`[0024] Before proceeding with a description of the present
`invention, il is well to define several terms as used herein.
`
`[0025] A “financial service entity” is an entity, typically a
`corporation or company, that provides investment, money
`management, brokerage, or advice/planning for another
`entity, typically an individual or a corporate entity.
`
`[0026] An “application service provider (ASP)” is an
`entity, that provides a functionality of a software application
`via a remote interface or delivery method.
`
`[0027] An “asset” is anything considered as having a
`positive monetary value. Assets include holdings of obvious
`market value (cash, real estate, securities), harder-to-mea-
`sure value (inventory, aging equipment), and other quantities
`(pre-paid expenses, goodwill) considered assets by account-
`ing conventions but possibly having no market valueat all.
`
`[0028] A “financial instrument”is: (a) a debt security; (b)
`an equity security; (c) an insurance policy; (d) an interest in
`a partnership, a trust or the estate of a deceased individual,
`or any right in respect of such an interest; (e) a precious
`metal; (f) an option or a contract for the future supply of a
`commodity, where the option or contract is traded on a
`recognized commodity exchange; (g) a prescribed instru-
`ment; (h) a guarantee, an acceptance or an indemnity in
`respect of anything described in paragraphs(a), (b), (4), (e)
`or (g); or (4) an option or a contract for the future supply of
`moneyor anything described in any of paragraphs(a) to (h).
`
`[0029] A “portfolio” is a pluralityof financial instruments.
`
`[0030] An “asset class” is a logical grouping of assets into
`a category whose members share common traits. For
`example, all stock investments are grouped into an asset
`class know as equities, since they all commonly represent
`equity positions in various companies. All currency posi-
`tions in a portfolio are grouped into an asset class labeled
`foreign exchange.
`
`[0031] A “market sector’ is a logical grouping of assets
`into companiesthat belong to the sameclass of business. For
`example, all stocks of technology related companies are
`labeled technology sector stocks.
`
`“Risk” is a calculated currency amount represent-
`[0032]
`ing a potential gain or loss that a series of investments or
`investment portfolios could realize over a specified period of
`time.
`
`“Value at risk” is a measurement used to estimate
`[0036]
`a potential loss or gain in a given investment or set of
`investments. Historical value at risk (VAR) uses historical
`price volatility and a statistical distribution to approximate
`behavior of an asset’s, or group of assets’, future price
`behavior. The approximation is calculated within a given
`range of confidence. The result is an estimation of potential
`loss or gain with a 95% degree of confidence and a 5%
`degree of error. This 95% degree of confidence is a com-
`monly accepted industry standard whenreferring to Value at
`Risk. Of the methods used to calculate VaR, almost all
`existing industry standard manifestations commonly aim to
`provide a result with this 95% standard.
`
`“Return” is an absolute or percentage amount
`[0037]
`gained orlost in an investment over a given time period.
`
`“Distributed” is a description of a software system
`[0038]
`architecture that locates components of a software applica-
`tion on separate, but networked computers. This is in con-
`trast to having all the components of a software application
`residing on the same computer. A distributed software appli-
`cation is spread over several computers that are connected
`via a network.
`
`“Runtime”refers to a condition andstate that exists
`[0039]
`when a program is being executed. When something is
`accessed at runtime it is accessed dynamically, as opposed
`to being accessed off-line or before a program is executed.
`
`“Thread” is a single sequential flow of control
`[0040]
`within a program. A single thread also has a beginning, a
`sequence, and an end and at any given time during the
`runtime of the thread, there is a single point of execution.
`However, a thread itself is not a program; it cannot run on
`its own. Rather, it runs within a program.
`
`[0041] The present invention includes a system through
`which a client device can make a dynamic requestfor a risk
`analysis, via a network,
`to a server device, which then
`returns a result of the risk analysis to the client device. Risk
`analysis typically includes a risk calculation. The request
`contains composition details of a financial portfolio, such as
`an asset symbol, a quantity, and/or a purchase date. The
`result may contain a single or multiple set of calculation
`results, including graphical representations.
`
`[0042] The requests are made through a structured format,
`commonly referred to as an Application ProgrammingInter-
`face (API). An API is a method prescribed by a computer
`operating system or a first application program through
`which a programmer writing a second application program
`can make a request of the operating system or the first
`application program. This means that from within a given
`program, it is possible to make functional requests from
`another program that is currently running on a processor. For
`
`

`

`US 2003/0009408 A1
`
`Jan. 9, 2003
`
`example, a certain computer may contain a first program that
`calculates the average of a series of numbers. If this first
`program has an API that exposes this capability, it would
`then be possible to create a second program that uses the API
`to also calculate the average of a series of numbers. The API
`of the first program allowed the creator of the second
`program to avoid having to generate this feature from
`scratch.
`
`[0043] The API of the present invention allows the client
`to generate the request in an API call and display the result
`in a chosen formatin order to maintain interface consistency.
`Interface consistency is the presentation of results and
`information in a consistent look and feel. This means that
`
`even though new features are added to a financial service
`entity’s application, since the API allows full programmatic
`control, the results can be displayed in a manner familiar to
`the other features which may be currently supplied by the
`financial service entity.
`
`In addition, the request may be mixed and matched
`[0044]
`to create new and unique functionality combinations as
`desired by the client. An example of such a mix is one where
`a financial service entity uses an existing feature on its
`system to sort equity positions in a customer’s portfolio by
`geographic region. Lach of these geographic groups of
`stocks are then risk analyzed, using an API call. The result
`is a portfolio risk analysis based on geographicrisk. In this
`example, two disparate features arc combined to create a
`useful result.
`
`[0045] FIG. 1 is ablock diagram of a networked computer
`system 100 configured for employment of the present inven-
`tion. The principal components of system 100 are a financial
`service processor 105, a server processor 115 and a customer
`workstation 130. Processors 105 and 115, and customer
`workstation 130 are each coupled to a network (not shown),
`such as the Internet, through which they can communicate
`with one another. Conceptually, processor 105 and customer
`workstation 130 are located on a client side of the network,
`and processor 155 is on a server side of the network.
`
`In FIG. 1, communications between the principal
`[0046]
`components of system 100 are represented by block arrows.
`For example,
`there is bidirectional communication 127
`between workstation 130 and processor 105. Also, an API
`call 112 is sent from the client side of system 100 to
`processor 115, and processor 115 returns an APIresult 114
`to the clientside.
`
`In one embodiment of system 100, processor 105
`[0047]
`sends API call 112 and receives API result 114.
`In an
`alternative embodiment, workstation 130 sends APIcall 112
`and receives API result 114. In other words, the present
`invention contemplates communication between either of
`processor 105 or workstation 130, and processor 115.
`
`[0048] Server processor 115 is a conventional network
`server device that has an associated memory (not shown)
`that includes data and instructions for controlling processor
`115, and in particular an analytical engine 125 and an
`analytical engine API 120. Analytical engine 125 and API
`120 are software modules.
`
`[0049] Analytical cnginc 125 performsa risk analysis. The
`analytical engine is part of a collection of server-side soft-
`ware, hardware and stored data that make up the risk
`management application. The risk analysis can cncompass
`
`any conventional risk analysis function. Preferably, a user of
`the present invention is permitted to select from variety of
`such functions. By way of example, and not
`limitation,
`analysis engine 125 providesrisk analysis functions such as:
`
`1. Financial Instrument Risk Calculation—
`[0050]
`Computes a value at risk of a financial instrument.
`
`2. Financial Instrument Historical Risk Cal-
`{0051]
`culation—Computes a historical value at risk of a
`financial instrument.
`
`3. Financial Instrument Stress Test Risk Cal-
`[0052]
`culation—Computesa possible value fluctuation of a
`financial instrument, given a user-defined simulated
`market event.
`
`Index Comparison
`4. Financial Instrument
`[0053]
`Risk Caleulation—Computes a comparisonofrisk of
`a financial instrument versus risk of an equivalent
`market value invested in a market index.
`
`5. Financial Instrument Volatility Calcula-
`[0054]
`tion—Computesanhistorical volatility of a financial
`instrument.
`
`6. Financial Instrument Value Calculation—
`[0055]
`Computes a current market value of a financial
`instrument.
`
`7. Financial Instrument Profit Calculation—
`{0056]
`Computes a profit over a given period of time of a
`financial instrument.
`
`8. Financial Instrument Sector Sort Calcula-
`[0057]
`tion—Sorts a financial
`instrument
`into a market
`sector/industry grouping, e.g., a market sector/indus-
`try grouping found in an cquity and corporate bond
`market.
`
`9. Financial Instrument Asset Sort Calcula-
`[0058]
`tion—Sorts a financial instrument into an associated
`
`assct grouping, c.g., cquitics, bonds, commoditics,
`currencies.
`
`If desired, each of the aforementionedrisk analysis
`[0059]
`functions can operate on a plurality of financial instruments,
`rather than merely a single financial instrument. Also, these
`functions can be employed for either of an individual risk
`analysis or an aggregate risk analysis.
`
`Individualrisk analysis is an analysisof a risk of an
`[0060]
`individual position, such as 100 shares of XYZ,Inc. It also
`encompasses determining an individual risk for each of a
`plurality of companies, e.g., risk of XYZ, Inc., and sepa-
`rately, risk of POR,Inc.
`
`[0061] Aggregate risk analysis is an analysis of a collec-
`tive risk of a plurality of positions. [‘or example, collective
`risk of owning 100 shares of XYZ, Inc. and 100 shares of
`POR,Inc. XYZ,Inc. and POR,Inc could both be risky when
`each is considered as an individual, yet their collective risk
`might not be high. For example, under a particular market
`condition, XYZ,Inc. stock could have a tendencyto rise and
`POR,Inc. stock could have a tendency to fall, but their
`collective risk is relatively low as their opposite tendencies
`cancel one another.
`
`[0062] API call 112 includes data relating to an invest-
`ment, and scrves as a request for analytical engine 125 to
`
`

`

`US 2003/0009408 A1
`
`Jan. 9, 2003
`
`perform a risk analysis of the investment. API result 114
`includes a result of the risk analysis.
`
`[0063] API 120 exposes the functionality of analytical
`engine 125 to components outside of processor 115. Thatis,
`API 120 provides an interface between the outside compo-
`nents and analytical engine 125. API 120 receives API call
`112 from the client side of system 100, extracts data there-
`from, and passes the data to analytical engine 125. API 120
`receives a risk analysis result from analytical engine 125,
`and returns the result to the client side of system 100 via API
`result 114.
`
`[0064] Financial service processor 105 includes an asso-
`ciated memory (not shown) that includes data and instruc-
`tions for controlling processor 105, and in particular an
`interface module 110. Interface module 110 is a software
`
`module for issuing API call 112 and receiving API result
`114.
`
`[0065] Workstation 130 is a conventional computer. As
`such, it may be implemented as a general purpose micro-
`computer, such as one of the members of the Sun™ Micro-
`systems family of computer systems, one of the members of
`the IBM™ Personal Computer family, or any conventional
`portable or wireless computer device. Workstation 130
`includes a memory (not shown) that
`includes data and
`instructions for controlling workstation 130, and in particu-
`lar it may have installed therein an interface module 110A.
`Interface module 110A is a software module that has a
`functionality similar to that of interface module 110. Thatis,
`interface module 110A is for issuing API call 112 and
`receiving API result 114.
`
`Interface module 110 and interface module 110A
`[0066]
`are preferably structured as APIs, and each mirrors the
`functionality of API 120. This meansthat interface modules
`110 and 110A can contain a series of feature methodsthat are
`
`exposed and made available programmatically. The relation-
`ship between interface methods 110 and 110A and the
`functions of analytical engine 125 that reside and execute on
`the server side can be a one-to-one relationship. Interface
`modules 110 and 110A maycontain a method that generates
`a portfolio VaR calculation. However, this interface method
`does not actually calculate the VaR. Rather, this method only
`passes along the request to an associated server-side VaR
`method that
`then actually executes the calculation. This
`functional relationship between the interface method and the
`server-side method is an example of mirroring.
`
`Inone embodimentof system 100, workstation 130
`[0067]
`communicates with processor 105. Workstation 130 runs an
`application, such as a web browser, that uses the Internet or
`some network to access features provided by processor 105.
`Processor 105, in turn, employs interface module 110 to
`send a risk analysis request, via API 120,to analytical engine
`125. Thereafter, interface module 110 receives API result
`114. Processor 105 then presents the API result in a chosen
`format and uses the Internet or some network to send the
`
`result back to the application running on the workstation
`130.
`
`In analternative embodimentof system 100, work-
`[0068]
`station 130 employs interface module 110A to send a risk
`analysis request, via API 120,
`to analytical cngine 125.
`Thereafter, interface module LIOA receives API result 114.
`Note that
`this alternative embodiment does not
`involve
`
`processor 105.
`
`In another alternative embodiment, processor 105
`[0069]
`can be an originator of a request for a risk analysis, where
`the result is sent from processor 115 to workstation 130.
`Such an arrangement would be appropriate for example,
`where the customer wishes to periodically receive a risk
`report, automatically. As such, processor 105 runs a program
`(not shown)that periodically sends API call 112 to processor
`115, and processor 115 send the result to workstation 130 via
`email.
`
`[0070] Although system 100 is described hercin as having
`the instructions for the method of the present invention
`installed into memories of processor 105, processor 115 and
`workstation 130, the instructions can reside on an external
`storage media 135 for subsequent loading into the memories
`of processor 105, processor 115 and workstation 130. Stor-
`age media 135 can be any conventional storage media,
`including, but not limited to, a floppy disk, a compact disk,
`a magnetic tape, a read only memory, or an optical storage
`media. Storage media 135 could also be a random access
`memory, or other type of electronic storage, located on a
`remote storage system and coupled to the memories of
`processor 105, processor 115 and workstation 130.
`
`FIG.2 is a flowchart of a mcthod 200 for sctting
`{0071]
`up a request for a risk analysis, using API call 120 in
`accordance with the present
`invention. Method 200 is
`executed onthe client side of system 100 by either processor
`105 or workstation 130 under the control ofeither interface
`
`module 110 or 110A,respectively. For convenience, method
`200 is described herein from the perspective of processor
`105 and interface module 110. Method 200 commenceswith
`
`step 205.
`
`In step 205, a user portfolio is selected to be
`[0072]
`analyzed. This sclection may occur, for cxamplc, as a result
`of a financial service customer’s wish to generate a risk
`measurementofhis or her portfolio. The customer expresses
`this wish by sending a request for the measurement from
`workstation 130 to processor 105. Thereafter, processor 105
`extracts the customer’s portfolio parameters from a portfolio
`database (not shown), whichis a part of, or which is coupled
`to, processor 105. Method 200 then progresses to step 210.
`
`In a preferred embodiment of the invention, the
`(0073]
`financial service entity has used the functions available via
`the API to create a service that is accessible to a customer.
`
`This service may be in the form of a series of IITML web
`pages that allow a customer to choose from a number of
`available features. Therefore, in a preferred embodiment, a
`customer can choose a feature via a web page delivered by
`processor 105 to analyze the aggregate risk of a selected
`portfolio. This choice, made by the customer, 1.e., the end
`user, dictates which API calls processor 105 will make and
`which parameters it will use.
`
`In step 210, processor 105 sets data parameters,
`[0074]
`e.g., position details (symbol, quantity, etc.), of the portfolio
`contents for API call 112. That is the position details are
`input as data parameters into interface module 110. After
`step 210, method 200 optionally progresses to step 215, or
`otherwise progresses to step 220.
`
`Step 215 is an optional step in which processor 105
`[0075]
`can set an output parameter to specify a type of calculation
`to be performed, and a type of result to be returned, by
`analytical engine 125. Analytical engine 125 returns differ-
`
`

`

`US 2003/0009408 A1
`
`Jan. 9, 2003
`
`entresults for different values of the output parameter. Table
`1 showsseveral exemplaryuses of the output parameter and
`their corresponding results.
`
`described earlier, e.g., (1) Financial Instrument Risk Calcu-
`lation, (2) Financial Instrument Historical Risk Calculation,
`etc. Analytical engine 125 contains a set of existing capa-
`
`TABLE1
`
`OUTPUT
`PARAMETER RESULT
`
`1
`
`2
`
`3
`
`An aggregate risk measurement for a group of financial
`instruments.
`A comma delimited series containing individual position risk
`measurements for each position within a group of financial instruments.
`a histogram displaying a comparative graphical display of each
`instrument risk measurement.
`
`[0076] After step 215, method 200 progressesto step 220.
`
`In step 220, processor 105 sets a format parameter
`[0077]
`to define a format in which data is presented from processor
`115 to processor 105. Exemplary formats include (1) simple
`text, (2) a complex data structure such as anarray, a table,
`or an object-oriented programming (OOP)object, and (3) an
`image such as a picture, a chart, or a graph. Method 200
`progresses from step 220 to step 225.
`
`Instep 225, processor 105 transmits API call 112 to
`[0078]
`processor 115. In terms of software operation,
`interface
`module 110 sends API call 112 to API 120. API call 112 is
`
`also referred to herein as a request.
`
`FIG.3 is a flowchart of a method 300 for process-
`[0079]
`ing a request for a risk analysis via API 120 in accordance
`with the present invention. Method 300 is executed on the
`serverside of system 100 by processor 115 underthe control
`of API 120 and analytical engine 125. Method 300 com-
`mences with step 305.
`
`In step 305, processor 310 receives API call 112.
`[0080]
`Motespecifically, in terms of software operation, API 120
`receives API call 112. As mentioned earlier, API call 112 can
`be issued by either of processor 105 or workstation 130.
`After step 305, method 300 progresses to step 310.
`
`In step 310, API 120 passes the request to analyti-
`[0081]
`cal engine 125. By passing a request, API 120 examinesthe
`data delivered to it by API call 112 and extracts portfolio
`composition data and well as interprets API parameters in
`order to initiate a specific calculation by analytical engine
`125. A given API call 112 may contain data structures that
`include symbol and quantity information for a given port-
`folio. Also, this API call 112 may contain parameters that
`specify exactly which feature of analytical engine 125
`should be executed on the given portfolio. It is the job of the
`API 120 to decipher this information andarticulate it to
`analytical engine 125 based on these parameters. After step
`310, method 300 progresses to step 315.
`
`In step 315, analytical engine 125 decodes the
`[0082]
`request. A request may contain parameters that
`instruct
`analytical engine 125 to measure the risk of a portfolio.
`Therefore analytical engine 125 must read the parameters
`passed to it
`to determine what type of risk calculation is
`desired, and what data will be required to perform this
`calculation. It extracts parameters (see steps 210, 215 and
`220), and based on the parameters, determines which risk
`analysis function to execute. Several such functions were
`
`bilities. Based on parameters delivered to it by API 120,it
`determines which capability to execute. After step 315,
`method 300 progresses to step 320.
`[0083]
`In step 320, analytical engine 125 determines
`whether the requestis for an individual risk calculation or an
`aggregate risk calculation. Analytical engine 125 makesthis
`determination based on a parameter, i.e. the ‘output’ param-
`cter, which is passed via API call 112 to API 120. The
`‘output’ parameter can take on several predetermined values
`that represent different types of calculations.If the requestis
`for
`an individual
`risk calculation,
`then method 300
`progresses to step 325. If the request is for an aggregate risk
`calculation, then method 300 progresses to step 330.
`
`In step 325, analytical engine 125 calculates indi-
`[0084]
`vidual risk. Analytical engine 125 generates a VaR result for
`each position in the given portfolio. After step 325, method
`300 progresses to step 335.
`
`In step 330, analytical engine 1225 calculates
`[0085]
`aggregate risk. Analytical engine 125 performs a portfolio
`wide analysis that results in the overall VaR of the whole
`given portfolio. After step 325, method 300 progresses to
`step 335.
`
`In step 335, analytical engine 125 determines,
`[0086]
`based on the output parameter specified in step 220, whether
`to generate a histogram. If a histogram is to be generated,
`then method 300 progresses to step 340. If a histogramis not
`to be generated, then method 300 progresses to step 345.
`
`In step 340, analyt