SYSTEM AND METHOD FOR MULTI-LAYER RISK ANALYSIS

A risk analysis method uses a multi-dimensional risk representation that allows a standard OLAP engine to perform analysis on multi-dimensional data corresponding to a portfolio of financial positions. The analysis includes context-dependent, heterogeneous aggregation functions. The multi-dimensional data is represented as a multi-layered multi-dimensional cube (“outer” cube), which consists of dimensions and cells. Each cell includes a set of coordinates and an inner multi-dimensional cube (“inner” cube). Dimensions of the inner cube include all dimensions required for aggregations. Dimensions of the outer cube include only dimensions needed for context (or reporting). An aggregation is performed on the set of measures of the inner cube based on a context for the aggregation provided by the outer cube.

Skip to: Description  ·  Claims  · Patent History  ·  Patent History
Description
CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation application of U.S. patent application Ser. No. 11/100,841 filed on Apr. 7, 2005, which claims benefit of U.S. Provisional Application No. 60/600,653 filed Aug. 11, 2004 and is a continuation in part application of U.S. patent application Ser. No. 10/384,721 filed Mar. 11, 2003. U.S. patent application Ser. No. 10/384,721 claims benefit of U.S. Provisional Patent Application No. 60/363,641 filed Mar. 11, 2002. The entire disclosures of U.S. Provisional Patent Application Nos. 60/600,653 and 60/363,641, and U.S. patent application Ser. Nos. 10/384,721 and 11/100,841 are incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention generally relates to a method and a system for performing risk management analysis. More particularly, the present invention relates to a system with a scalable architecture for performing risk management analysis and a method of using On-Line Analytical Processing (OLAP) engines to perform multi-dimensional analysis with context-dependent, heterogeneous aggregation functions.

2. Related Art

Large financial institutions typically have a large portfolio of investment positions at any given point in time. Value-at-Risk (VaR) has become the standard manner by which risk associated with the portfolio is measured within these large financial institutions. VaR is used as a quantitative measure of risk for assessment and comparison purposes. VaR was first developed as a measure of market risk to describe the potential loss incurred by unfavorable market conditions.

As used in the present discussion, the term “risk” is defined as the uncertainty of profits or a possibility of losses in a portfolio of financial securities. Risk of a portfolio thus encompasses all possible values of losses (or results of underperformance compared to a benchmark) over a fixed period of time. Risk therefore is mathematically described as a random variable. VaR is a pre-defined quantile, usually 99%, of the probability distribution of this random variable.

The market risk associated with a portfolio can be separated into “continuous market risk,” stemming from continuous fluctuations in market prices of instruments in the portfolio, and “event and default risk,” which are due to possible abrupt jumps in the instruments' prices caused by events specific to individual issuers (e.g., events affecting actual or perceived creditworthiness or future profitability of the issuers). For debt instruments, possible credit events typically include changes of externally assigned credit ratings or default (insolvency) of the instrument's issuer.

Financial institutions commonly use internal models for portfolio risk analysis. A specific risk add-on for an internal model may be an “event risk” for individual equities and their derivatives. In the case of the broad market, the one-year history of the broad market is by regulatory fiat a sufficient measure of the historical risk of the broad market. Thus the event-risk add-on for equities must be some measure of historical events spanning “a full business cycle,” which are idiosyncratic to an individual equity and not captured in a one-year VaR. An equity event is defined as a jump discontinuity in price relative to the broad market, observed during an entire business cycle, which is a larger percent price change than any price changes that were observed over the previous year and thus already incorporated into the VaR estimate.

Generally, a portfolio contains linear and non-linear positions or holdings. For linear holdings (e.g., direct-ownership stock) the VaR of the market risk can be calculated analytically. For non-linear holdings (e.g., options and derivatives) a model incorporating historical daily rate changes typically is applied to the current portfolio, in order to generate a distribution for the value of the portfolio and, therefore, the risk associated with the future of the portfolio.

The output of a risk system is a database that is generated in conformance with the above described models. The database is re-generated at least on a daily basis, and typically is re-generated, at least in part, on an intra-day basis to accommodate intra-day changes in the positions held by financial institutions. The database is queried by the risk managers of a financial institution in order to generate risk reports. Usually, these reports are generated for two purposes: to comply with regulatory requirements; and to manage the risk associated with a portfolio.

Some databases of prior-art risk-management systems are structured in the form of a multi-dimensional cube of cells (nodes). The cells represent various positions contained in a portfolio. In the prior-art risk-management systems (also referred to herein as “risk engines”) in which a multi-dimensional model is used, each cell contains only a scalar measure representing one particular measure of a position of the portfolio. For more complex risk engines of the prior art, the cube of cells has no more than ten different dimensions, such as the currency of a position, the market in which the position exists, and so on.

The nature of a multi-dimensional cube is such that that reports may easily be generated that satisfy the needs of a particular user. For example, upper management may require reports that convey executive-level information, e.g., whether a portfolio satisfies federal regulations for capital requirements. Alternatively, reports from the cube may be “drilled down” or presented at a trading-desk level, such that a trader will know exactly the predicted short-term risk associated with a portfolio being traded.

FIG. 1 schematically illustrates a risk engine of the prior art. As previously described, the positions of a portfolio mist be evaluated at least on a daily basis, as the market for the investments is ever changing. Element 100 represents datastreams that supply the risk engine with raw data relative to the positions of the portfolio. The raw data to be processed is directed to one of a plurality of valuation-processing systems (pipes) 102, 104, 106, 108 in order to be valued. For example, positions that are comprised of U.S. equities are directed to a valuation processing system (pipe) 102; foreign bonds are processed by a pipe 104; options and derivatives are processed by a pipe 106, and so on. The positions, once valued by the pipes 102, 104, 106, 108, are used to populate the above-described multi-dimensional cube in a database 110.

In the prior-art system of FIG. 1, there essentially is no sharing of data and no sharing of resources. Each pipe 102, 104, 106, 108 has its own set of resources (e.g., processors) and exclusively operate on a particular type of data (e.g., U.S. equities). This architecture, although adequate for financial institutions within a certain size, is unable to keep up with increasing volumes of financial data for growing financial institutions. For example, if there is a merger of two mid-sized financial institutions into one larger institution, the risk engines of either of the institutions would not be able to accommodate the risk-management processing of the other institution. This typically leads to disparate risk engines within the combined (merged) financial institution, with potentially arbitrary assignment of data to be processed by one or the other of the risk engines.

The only way that the risk engines of either financial institution would be able to handle the increased volume would be to purchase more, larger, faster, and increasingly expensive processors and networks. But even this solution has its limits, as the architecture of the above-described prior-art risk engines can only be scaled up so much. One significant problem discovered by the present inventors is that the architecture of prior-art risk engines leads to uneven workload distribution, which in turn leads to unacceptable delays in valuation and reductions in the engines' throughput. The inventors of the present invention performed a benchmarking test of the prior-art risk engines on increasingly bigger machines and networks, and found that there is a clear limit to the extent to which a prior-art risk engine would no longer scale up.

The inventors of the present invention found that the prior-art risk engines are incapable of valuing a portfolio of one million positions for the simultaneous processing of a one-day VaR, ten-day VaR, corporate stress tests, and specific issuer risk processing in a timely manner.

OLAP engines have been used to perform portfolio risk analysis according to conventional techniques. Generally, as mentioned above, financial institutions use internal risk models for such analysis, which is inherently multi-dimensional. As such, OLAP engines provide a natural choice for performing portfolio risk analysis. However, aggregation functions used in most if not all internal risk models are context-dependent and heterogeneous. This significantly limits the ability to use the generic analysis mechanism provided by OLAP engines to perform analyses for specific conditions. That is, commonly used aggregation functions do not allow OLAP engines to be utilized to the fullest extent of their capabilities, because such aggregation functions are context-dependent and heterogeneous, and because the conventional representation of the information to be aggregated cannot be adapted to a generic analysis mechanism. Therefore, OLAP engines utilized to aggregate conventionally represented information are prevented from performing a generic risk analysis that is context-dependent and heterogeneous, and can easily be adapted to generate an analysis using desired parameters.

FIG. 8 shows an example of a data hierarchy with a tree structure, in which C0 represents a node. C1, C2, and C3 are intermediate nodes extending from C0, and C11 through C32 are leaves extending from C1, C2, or C3.

Instead of a tree structure, a data hierarchy may be represented by a cube of one or more dimensions. FIG. 9 shows a data hierarchy represented as a two-dimensional (2D) cube, in which the horizontal axis represents “Region” and the vertical axis represents “Currency.” For the multi-dimensional cube of FIG. 9, if an aggregation function f( . . . ) is a addition operation, which clearly is context-independent and homogeneous, then:


C1=f(C11, C13)


C2=f(C21, C22)


C3=f(C31, C33)


C4=f(C42, C43).

That is, in the 2D (Currency, Region) cube of FIG. 9, the node C0 represents the total for the Currency and Region dimensions. The intermediate node C1 represents the total for the region “NA” or North America, which has a leaf C11 corresponding to the Japanese yen (JPY) and a leaf C13 corresponding to the American dollar (USD). The intermediate node C2 represents the total for the region “EMEA” or Europe/Middle East/Africa, which has a leaf C21 corresponding to the Japanese yen and a leaf C22 corresponding to the British pound (GBP). The intermediate node C3 represents the total for the region “ASIA” or Asia, which has a leaf C31 corresponding to the Japanese yen and a leaf C33 corresponding to the American dollar. The intermediate node C4 represents the total for the region “LA” or Latin America, which has a leaf C42 corresponding to the British pound and a leaf C43 corresponding to the American dollar.

In risk management, however, most aggregation functions are context-dependent, as mentioned above. The following is an example of a context-dependent aggregation commonly performed in market and credit management.

Table 1 shows a portfolio of positions. The positions in Table 1 may be represented as a three-dimensional (3D) cube, with the dimensions “Legal Entity,” “Currency,” and “Issuer,” as schematically shown at reference numeral 100 in FIG. 10. At the vertices of the cube 100 are cells 110, each of which contain measures for the three dimensions of the cube 100. In the case of Table 1, each cell of the cube contains the measures “MTM” (market-to-market) and “Exposure.” That is, each cell corresponding to Table 1 has three dimensions (i.e., the three dimensions of the cube 100) and two measures.

TABLE 1 PORTFOLIO OF POSITIONS Legal Entity Currency Issuer MTM Exposure FSA GBP IBM 100 10 FRB USD GM −200 −20 FSA USD GM 450 30 FRB GBP GM 300 20 FRB GBP GM −300 −20 FSA USD IBM −500 −80 FSA JPY IBM 450 30 FRB JPY GM 600 −50 FSA USD GE 250 20 FSA GBP GE −300 −10 FRB USD GM 150 10

One of ordinary skill in the art will appreciate that although the cube 100 shown in FIG. 10 has three dimensions, the term “cube” as discussed herein is not limited to a 3D cube but instead may have more or fewer dimensions than three. Similarly, although each cell 110 in FIG. 10 is described as having three dimensions, the term “cell” as discussed herein may have more or fewer than three dimensions. Also, note that the dimension Legal Entity may be represented as a data hierarchy with a tree structure, as schematically shown in FIG. 11.

In the present example, the aggregation rules are as follows:

    • MTMs are netted at any level; and
    • Exposures are netter for an Issuer and grossed between Issuers.

For a query to calculate MTM and Exposure by Legal Entity, aggregation according to the above aggregation rules returns the results shown in Table 2.

TABLE 2 RESULTS OF LEGAL-ENTITY QUERY Legal Entity MTM Exposure FRB 550 60 FSA 450 80

The results shown in Table 2, are obtained according to the following operations.

First, the 3D cube containing the data of Table 1 is projected onto two dimensions, Legal Entity and Issuer, by algebraically summing the MTM and Exposure measures for each cell. That is, the 3D cube is projected onto a 2D cube. The results of this summing operation are given in Table 3.

TABLE 3 SUMMATION RESULTS Legal Entity Issuer MTM Exposure FRB GM −200 −20 FRB GM 300 20 FRB GM −300 −20 FRB GM 600 −50 FRB GM 150 10 FSA GE 250 20 FSA GE −300 −10 FSA GM 450 30 FSA IBM 100 10 FSA IBM −500 −80 FSA IBM 450 30

Next, netting by issuers is performed by consolidating the cells. That is, for each issuer, the MTM and the Exposure is algebraically added. Results of this netting operation are given in Table 4.

TABLE 4 RESULTS OF NETTING Legal Entity Issuer MTM Exposure FRB GM 550 −60 FSA GE −50 10 FSA GM 450 30 FSA IBM 50 −40

Finally, data from the 2D cube is projected onto one dimension, Legal Entity, by netting the MTMs and “grossing” or calculating the gross values for the Exposures. That is, the MTMs are summed algebraically and the absolute values of the Exposures are summed algebraically. The results of this projection are given in Table 5, which is the same as Table 2.

TABLE 5 RESULTS OF PROJECTION Legal Entity MTM Exposure FRB 550 60 FSA 450 80

The above example illustrates the conventional operations used to project a 3D cube onto a 1D cube (with the single dimension of Legal Entity, in the example). At this point, if it is desirable to further aggregate the 1D cube according to the data hierarchy of FIG. 11, an operation equivalent to summing the rows of Table 5 is performed. (A straight algebraic summation operation would yield erroneous results, because the 2D -to-1D projection resulted in the loss of information.) However, because such an aggregation is non-linear, it is necessary to go back to Table 4 and perform a netting operation by issuer. The results of this netting operation are given in Table 6.

TABLE 6 RESULTS OF NETTING BY ISSUER Issuer MTM Exposure GM 1000 −30 GE −50 10 IBM 50 −40

From the results in Table 6, a netting operation is performed on the MTM data, and a grossing operation is performed on the Exposure data to arrive at the final “Corp” aggregation results, which are given in Table 7.

TABLE 7 RESULTS FOR CORP Corp MTM = 1000 Exposure = 80

The results in Table 7 would not have been obtained by performing netting and grossing operations on the data in Table 5, which would have given the erroneous results of MTM=1000 and Exposure=140.

Similarly, for a query to calculate MTM and Exposure by Currency, aggregation according to the above aggregation rules returns the results shown in Table 8.

TABLE 8 RESULTS OF CURRENCY QUERY Currency MTM Exposure GBP −200 20 JPY 1050 80 USD 150 120

For a query to calculate the MTM and Exposure for the entire portfolio, simple netting and grossing operations on the data in Table 8 would produce the erroneous results of MTM=1000 and Exposure=220. Instead, the corrects results arc given in Table 9, which is the same as Table 7, and are obtained by going back to the 2D (Currency, Issuer) cube and performing a netting operation by issuer, analogous to the operation resulting in Table 6. Then, a netting operation is performed on the MTMs, and a grossing operation is performed on the Exposures.

TABLE 9 RESULTS FOR PORTFOLIO Portfolio MTM = 1000 Exposure = 80

As can been seen from the above examples, risk analysis using conventional multi-dimensional cubes cannot be reliably employed in a generic manner to produce results for queries involving context-dependent and heterogeneous aggregation functions. This is because, as dimensions of a cube are projected onto cubes of fewer and fewer dimensions, information is consolidated in the various operations performed for the projections and the original information is no longer preserved.

Referring to FIG. 8, aggregation up the data hierarchy for a context-dependent, homogeneous function is given by:


C1=g(C11, C12)


C2=g(C21, C22)


C3=g(C31, C32)


C0=g(C11, C12, C21, C22, C31, C32),

where g( . . . ) represents an aggregation function that is context-dependent and homogeneous. Note that g( . . . ) is the same aggregation function regardless of what node(s) it is operating on. However, for a heterogeneous aggregation function, μj, all leaf nodes Cjk are separated into homogeneous sets, and


C0=μ0(μ1({C1}), μ2({C2}), μ3({C3}), . . . μk({Ck})).

That is, the aggregation function μj is not the same for all nodes, and each aggregation function μj depends on the node that it is operating on as well as neighboring nodes, and also depends on where (what level or part of the data hierarchy) an aggregation is being performed. In this way, context is provided to an aggregation.

The above examples show that, with conventional models or algorithms for queries of information, a query may not contain a dimension that provides context for an aggregation, and also may not provide context for separating nodes into homogeneous sets (e.g., the issuer dimension in the above examples).

More specifically, the above examples show that, in the conventional uses of OLAP engines, if a second query is to be performed on original information from a first query, the second query must perform new operations on the original information and cannot use operations performed in the first query of the original information. This is due to the way the original information is represented in the conventional models. In other words, the route that is taken along a path of projections for a query determines the information represented by the lower-dimension cubes resulting from the projections, and the original information is irreversibly transformed.

As mentioned above, in the case of financial institutions, advances in market and credit-risk management has led to an increase in the use of internal risk models or algorithms for portfolio risk analysis. This type of risk analysis is inherently multi-dimensional, and OLAP engines are a natural choice for providing the analysis because OLAP engines provide a generic analysis of multi-dimensional data. However, aggregation functions used in most, if not all, conventional internal risk models are context-dependent and heterogeneous. This severely limits the applicability of the generic analysis provided by OLAP engines.

Conventional ways to solve this problem, i.e., to perform the different operations discussed above for the different queries, is to provide customized reports for certain types of aggregations. In other words, for the same set of original information, reports requiring different aggregation operations to be performed are run independently of each other. Such a solution is highly inefficient in terms of time and worker-hours. Clearly, there is a need in the art of data manipulation and processing in the field or risk management, especially manipulation and processing of financial data, for a context-independent and homogeneous method of representing multi-dimensional data, so that OLAP engines may be efficiently used to perform generic analyses.

SUMMARY OF INVENTION

The present invention provides a risk-management system and a data-analysis method for performing high-volume, large-scale risk analysis using a multi-dimensional risk representation. The present invention is applicable to financial analysis, engineering/scientific analysis, as well as other fields in which large numbers of multi-dimensional data are operated on in an analysis or query, and in which the risk representation allows the same multi-dimensional data to be operated in different analyses or queries in a generic manner.

According to an embodiment of the present invention, a database of the risk management system of the present invention preferably contains more than ten dimensions (e.g., 32) which make the database much more flexible than prior-art databases. The multi-dimensional risk representation of the present system is a cube having elements that need not be strictly numbers but instead may be objects that are used to generate different VaR vectors. For example, one such object may be a number of positions (e.g., 256) for a ten-day holding period, a one-day holding period, or any reasonable period specified by a user. Each cube is associated with cell whose entries are distributions of multiple random variables. The system is implemented as a set of collaborating sub-components, which uses partitioning, and pipeline parallelism, and which is heavily multi-threaded. Additionally, the system employs two basic types of elements in its architecture: controllers and brokers.

The controllers of the present invention are engines that perform actual processing of data. Preferably, the controllers have three main components: an input queue, a manager, and workers. Each controller retrieves units of work from the incoming queue, processes the units, and places results into an outgoing queue. The outgoing queue of a controller is shared with a next element in a processing chain.

The brokers of the present invention manage access to and from resources. That is, the brokers are responsible for maintaining a pool of common resources and providing access to those resources to a requestor (e.g., a controller). Preferably, the resources include a data source, such as a database containing market pricing data, for example. A broker accesses a data source though an adapter. Additionally, the brokers maintain a cache of cacheable elements.

Utilizing controllers and brokers as described above, the risk management system of the present invention functions as a risk engine that is scalable to virtually any size. As a processing load of the risk engine increases, additional workers may be added to increase its processing power.

According to another embodiment of the present invention, the data analysis method uses a multi-dimensional risk representation that allows a standard OLAP engine to perform analysis on multi-dimensional data, in which the analysis includes context-dependent, heterogeneous aggregation functions. The multi-dimensional data is represented as a multi-dimensional cube, which consists of dimensions and cells. Each cell includes a set of coordinates and either a scalar measure, a set of scalar and vector measures, or an object that implements calculation models. The set of coordinates contains all dimensions defined in the cube, and no more.

According to yet another embodiment of the present invention, multi-dimensional data is represented as a multi-layered multi-dimensional cube (referred to herein as an “outer” cube), which consists of dimensions and cells. Each cell includes a set of coordinates, an inner multi-dimensional cube (referred to herein as an “inner” cube), and may contain a set of scalar and vector measures. Dimensions of the inner cube include all dimensions required for aggregations. Dimensions of the outer cube include only dimensions needed for context (or reporting). The dimensions of the outer cube need not be the same as the dimensions of the inner cube. Each cell of the inner cube contains another cube (sub-inner multi-dimensional cube) or a set of scalar and vector measures. That is, the term “multi-layered” derives from the cube within a cube within a cube, etc., structure. The outer cube may have one or more inner-cube layers. Aggregation is performed on the set of measures of the inner cube based on a context for the aggregation provided by the outer cube.

According to the present invention, for the first example discussed above, the multi-dimensional data is represented as a 2D outer cube having the dimensions Legal Entity and Currency and a 1D inner cube having the dimension Issuer. The cells of the inner cube contain two measures: MTM and Exposure.

According to a further embodiment of the present invention, a programmable computer for use in performing risk analyses is provided. The programmable computer includes at least one memory including at least one region for storing computer-executable program code, and a processor for executing the program code stored in the memory. The program code implements a risk-analysis method using multi-layered multi-dimensional cubes to represent positions in a portfolio of an institution.

According to still another embodiment of the present invention, computer-executable code stored on a computer-readable medium is provided. The code operates to implement a risk-analysis method using multi-layered multi-dimensional cubes to represent positions in a portfolio of an institution.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be more readily understood from the detailed description of the invention presented below considered in conjunction with the attached drawings, of which:

FIG. 1 schematically illustrates a prior-art system for performing risk valuation;

FIG. 2 schematically depicts a risk-management system according to an embodiment of the present invention;

FIG. 3 schematically illustrates a risk engine according to an embodiment of the present invention;

FIG. 4 schematically illustrates a controller arrangement (pattern) according to an embodiment of the present invention;

FIG. 5 schematically depicts a broker arrangement (pattern) according to an embodiment of the present invention;

FIG. 6 schematically illustrates a query subsystem according to an embodiment of the present invention;

FIG. 7 schematically depicts a data hierarchy for a multi-dimensional cube;

FIG. 8 schematically depicts a data hierarchy with a tree structure;

FIG. 9 schematically depicts a data hierarchy as a multi-dimensional cube;

FIG. 10 schematically depicts a three-dimensional cube;

FIG. 11 schematically depicts a data hierarchy with a tree structure;

FIG. 12 schematically depicts a multi-layered multi-dimensional cube of three dimensions;

FIG. 13 schematically illustrates a transformation from a conventional multi-dimensional cube to a multi-layered multi-dimensional cube to a projected multi-dimensional cube;

FIG. 14 schematically depicts a structure of data hierarchies of a cube;

FIG. 15 schematically depicts a 2D multi-layered cube;

FIG. 16 schematically depicts the 2D multi-layered cube of FIG. 15 projected to a 1D multi-layered cube; and

FIG. 17 schematically depicts the 1D cube of FIG. 16 projected to a cube of 0th dimension.

It is to be understood that the attached drawings are intended to illustrate aspects of the present invention, but the present invention is not limited to the precise forms shown in the drawings.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 2 schematically illustrates a risk management system 200 according to an embodiment of the present invention. The system 200 is able to process at least 2,000,000 risk positions on a daily basis and is scalable to accommodate volume increases in excess of three-million positions. In a preferred embodiment, the system 200 is hosted on a SUN® F15K server.

The system 200 is able to run simultaneous calculations based on various methodologies. This means that the system 200 allows risk managers to value, within the same run, positions according to historical simulation methodology with a one-day holding period and a ten-day holding period using absolute and proportional shift types, for VaR, market stress, and specific-issuer risk. Additionally, the system 200 provides improved transparency, meaning that users (e.g., risk managers) are able to see what prices and shock factors were used for a valuation of any particular position.

As further described below, the system 200 is able to accommodate not only overnight position feeds, but also intra-day feeds and hypothetical positions. The system 200 provides a foundation for valuing hypothetical positions using real prices, real positions using hypothetical prices, and hypothetical positions using hypothetical prices. The system 200 also enables a risk manager to create a portfolio that includes both real and hypothetical positions in order to evaluate how additional trades, a change in price(s), and/or a change in shock factors may affect a risk profile of the portfolio.

The system 200 includes a positions database 210, which contains position data representing, for example, positions for a portfolio of a financial institution. The portfolio typically includes a large number of positions (e.g., several hundred thousand). Each position contains at least: identification information; booking-related information; non-statistical measures, such as quantity and net open position; asset related information such as product type, CUSIP or ticker, and credit rating; and issuer-related information such as ISIN and name, type. Instruments representing different positions may be associated with the same issuer.

Typically, a portfolio of an entire financial institution is divided into subportfolios. Preferably, the subportfolios are organized such that each subportfolio contains only positions that share a common issuer or are traded by the same desk, for example.

Raw position feeds 215 with changes in the financial institution's positions are processed on at least a daily basis. Typically, a bulk portion of the raw position feeds 215 is inputted to the system 200 during the night, as various systems supporting various divisions of the financial institution report changes in the financial institution's positions that occurred during the day (e.g., sold 10,000 shares of XYZ stock and bought $1,000,000 worth of bonds issued by company ABC). Furthermore, as positions change throughout the day, it may be desirable or even necessary to update the position data in the positions database 210 to reflect these changes. Intraday updates generally are expected if the system 200 is operated in the United States as foreign subsidiaries of the financial institution report their trading activities throughout the day.

As further described below, because the data in the raw position feeds 215 originates from a variety of different sources, the data must be converted into a common format before the position data in the positions database 210 can be updated. This conversion is performed by a conversion system 220. The system 200 functions to value a position itself or to process positions that have been valued externally according to scenarios specified by the system 200. Positions that are to be valued internally by the system 200 are inputted to the system 200 as Extended Position Format (XP) files. The positions are converted by the conversion system 220 and fed into the positions database 210 as XP position feeds 230. Positions that have been valued externally (although in accordance with scenarios specified by the system 200) arrive at the system 200 as prevalued position feeds 235. Each of the XP position feeds 230 and the prevalued position feeds 235 perform an enhancement function, such as filling in missing data, cleaning data, formatting and resolving conflicting data, etc.

The system 200 includes a valuation/risk engine 240. Although shown in FIG. 2 as a single engine, the valuation/risk engine 240, as further described in greater detail below, may be comprised of several engines, calculators, adapters, information brokers and other processing components. One of the important functions of the valuation/risk engine 240 is to calculate hypothetical market values. The valuation/risk engine 240 is implemented as a set of collaborating sub-components, which use partitioning, and pipeline parallelism, and which is heavily multi-threaded. As discussed above, the valuation/risk engine 240 preferably is implemented on an enterprise-class MPP server (such as an F15K server). The partition and pipeline parallelism of the sub-components makes the most efficient use the power of this server.

The valuation/risk engine 240 performs valuation processing, including valuing positions from the raw position feeds 215 and saving the valued positions in the positions database 210 for subsequent retrieval, analysis, and querying. More specifically, the valuation processing includes: retrieving positions from the raw position feeds 215; obtaining a proper calculator for a position depending on an instrument of the position; and retrieving necessary prices, performing valuation, and storing data corresponding to the valued positions in the positions database 210 for subsequent retrieval.

The positions database 210 contains position data as inputted via the raw position feeds 215. As described above, some of the position data correspond to positions that are pre-valued (inputted through the prevalued position feeds 235) and some of the position data correspond to positions that are not valued (inputted through the XP position feeds 230). A risk position database 260 stores valuation and classification results for each position. This database 260 is a physical storage unit for a compressed, virtual multi-dimensional cube, typically stored in the form of an interrelated set of tables.

Coupled to the valuation/risk engine 240 are several databases that are employed in valuation and risk determination processes performed by the system 200. An asset-data database 245 stores data related to assets represented in positions such as those corresponding to the position data in the positions database 210. For example, for equities, an asset may be identified by its industry-standard codes, such as ISIN (International Securities Identification Number) or CUSIP (Committee on Uniform Securities Identification Procedures). The asset-data database 245 stores static information about an asset, such as a coupon rate for a fixed-coupon bond, a reset schedule for a floating-coupon bond, expiration and strike data for an option, fixed-coupon information, spread data, and so on.

A rules database 250 stores various rules that govern processing of data by the valuation/risk engine 240. In a preferred embodiment, the rules stored in the rules database 250 are business rules stored in metadata format. The rules database 250 includes rules that, for each position, determine what valuation model to use and how to map input parameters of a model to attributes of a position. As further described below, the rules database 250 includes descriptions of libraries in the system 200 that are required to value each position.

A market-data database 260 stores market data related to the assets represented in the positions, such as the price of a stock, for example. Typically, market data is obtained from commercially available, real-time data streams of exchange market data, such as Bloomberg™ and Reuters™. Unlike the asset-data database 245, which stores static data about assets, the market-data database 255 stores dynamic information about assets, such as prices, durations, deltas, gammas, vegas, rates, yields, etc.

As further described below, the system includes a risk-position database 260, which stores calculated risk positions. As previously discussed, the preferred form of a risk positions is a multi-dimensional cube of cells (nodes). The risk-position database 260 is a compressed form of this cube, which is subsequently expanded by a query subsystem 270 when users perform actual queries of the system 200. A hypothetical-positions database 265 of the system 200 stores hypothetical positions that users wish to test. For example, a hypothetical position to be tested may relate to what would happen to a risk position if 10,000 shares of XYZ stock are sold from a portfolio.

The query subsystem 270 is coupled to the risk-position database 260. The query subsystem 270 is employed by various users (risk managers, traders, etc.) within the financial institution to access risk positions in a comprehensible and meaningful manner. Although illustrated in FIG. 2 as a database, the hypothetical positions “database” 265 optionally may be configured as an interface that accepts hypothetical positions that need not be stored in a formal database, e.g., real-time generated hypothetical positions.

FIG. 3 schematically illustrates the valuation/risk engine 240 according to an embodiment of the present invention. The valuation/risk engine 240 includes three or more input adapters, each of which are media-stream adapters: a database stream adapter 300; a file stream or network adapter 305; and at least one other adapter 310. The other adapter 310 may be an MQ Series stream adapter for interfacing with popular messaging MQ Series servers from IBM® Corporation or a Web-services adapter.

The database stream adapter 300 is coupled to the positions database 210. The network adapter 305 is coupled to a network 315. The other adapter(s) 310 is/are coupled to other position-data sources, such as the MQ series device described above. Each of the three media stream adapters 300, 305, 310 preferably functions to read at least the following formats: FIX messages; XML messages; and EDI messages.

“FIX” denotes a Financial Information eXchange protocol, which is a vendor-neutral standardized message format for describing real-time security transactions. FIX is a public-domain specification owned and maintained by FIX Protocol, Ltd. This protocol supports the following electronic conversations between brokers and other financial institutions: equity-order submissions, cancellations and replacements; equity-execution reporting; equity-order statusing; equity-trade allocation; indication-of-interest communications; completed-trade advertisements; and directed e-mail and news messages.

“XML” denotes eXtensible Markup Language, which is a specification designed especially for Web documents. XML allows for customized tags that enable the definition, transmission, validation, and interpretation of data between applications and between organizations.

“EDI” is an acronym for Electronic Data Interchange, which is a common standard for the transfer of data between different companies using networks, such as the Internet. As more and more companies connect to the Internet, EDI is becoming increasingly important as an easy mechanism for companies to buy, sell, and trade information. ANSI has approved a set of EDI standards known as the X12 standards.

The function of each of the adapters 300, 305, 310 is to control an input stream from a source to which a respective adapter is attached. For example, the database stream adapter 300 is coupled to the positions database 210, while the network adapter 305 is coupled to the network 315. Each adapter 300, 305, 310 efficiently retrieves an incoming message, construct a message object, and place the message object in an outgoing queue that is shared between the adapter 300, 305, 310 and a position receiver 320, which is the next element in the processing chain of the valuation/risk engine 240.

Controllers and brokers are other types of structures basic to the architecture of the system 200. As mentioned above, controllers are engines that perform actual processing of data, and brokers manage access to and from data resources.

An arrangement or pattern of a typical controller 400 is schematically illustrated in FIG. 4. A pattern is a generic solution to a common problem. In an object-oriented system, a pattern is realized as group of classes that serve as a foundation for specific customization.

As shown in FIG. 4, the controller 400 has four main components, an input queue 405, a manager 410, workers 415, 420, 425, 430 and an output queue 440. The controller 400 functions to retrieve a unit of work from the input queue 405, process the unit, and place a processing result into the outgoing queue 440. In a typical configuration, the output queue 440 is shared between the controller 400 and the next element in the processing chain. That is, the output queue 440 of a first controller 400 is the input queue 405 of the next controller 400 in the processing chain. A particular unit of work is processed by one of the workers 415, 420, 425, 430 in the context of separate threads. Each worker 415, 420, 425, 430 executes on its own thread and has its own resources.

One of the advantages of the architecture of the controller 400 (and in turn the system 200) is that the number of workers 415, 420, 425, 430 available to any given controller 400 is a tunable (adjustable) parameter that is auto-configurable and has an adjustable fan-out factor. The controller 400 schematically illustrated in FIG. 4 is shown as having a pool of four workers 415, 420, 425, 430. However, in a preferred embodiment, the controller 400 may be configured to have forty or more workers 415, 420, 425, 430.

In operation, when the controller 400 retrieves a unit of work from the input queue 405, the controller 400 selects a free worker 415, 420, 425, 430 and assigns the unit of work to the selected worker 415, 420, 425, 430. If more workers 415, 420, 425, 430 are required to perform the work units being processed by the controller 400, then more workers are configured for the controller 400. Each controller 400 contains configurable parameters with respect to workers: a minimum number of workers and a maximum number of workers. Preferably, a controller 400 never has fewer than the configured minimum number of workers, even if its input queue 405 is empty. Further, a controller 400 preferably never has more workers than the configured maximum number of workers, even if its input queue 405 is full. If the current number of workers is less than maximum number of workers, and there are elements (i.e., units of work) in its input queue 405 that are ready for processing, a controller 400 automatically creates another instance of a worker 415, 420, 425, 430 (i.e., a new worker) and assigns an element to the new worker 415, 420, 425, 430. The configurable parameters, i.e., the minimum and maximum number of workers for a controller 400, are specified in a configuration file for the system 200.

A broker arrangement or pattern 500 is schematically illustrated in FIG. 5. A broker 505 is responsible for maintaining a pool of common resources and providing access to those resources to a requestor. In a preferred embodiment, the resources include a data source 510, such as the market-data database 255 shown in FIG. 3. The broker 505 accesses the data source 510 though an adapter 515.

In addition to accessing data from the data source 510, the broker 505 maintains a cache 520 of cacheable elements 525. In operation, a controller 400 (see FIG. 4) makes a request for an element or data to a broker 505. Upon receiving this request, the broker 505 tries to find the requested element in the cache 520. If the broker 505 cannot find the requested element in the cache 520, the broker 505 creates a new element and tries to populate the new element. Sometimes, the attempted population of the new element does not work, e.g., if the requested element does not exist in the cache 520 or the in the data source 510 itself. If the population attempt is not successful, the existence of an empty element created by the broker 505 will prevent any further attempts to populate the empty element, thus saving computing time.

A broker 505 in accordance with the present invention supports three search policies: optimistic, pessimistic, and very pessimistic, depending on the nature of elements in the cache 520. An optimistic search policy is used when there is a high probability that a desired (requested) element is going to be found in the cache 520. According to the optimistic search policy, a search is first conducted on the open cache 520. If the element is not found in the cache 520, the cache 520 is locked down and the search is conducted again (because some other process might have created the element while the first search was going on). If the element is not found again, a new element is created and the cache 520 is unlocked.

A pessimistic search policy is used when there is a low probability of finding a requested element. According to the pessimistic search policy, the cache 520 is locked down before a search is conducted. A very pessimistic search policy is used when there is a virtually nonexistent probability of finding a requested element. According to the very pessimistic search policy, the cache 520 is locked down and then an empty element is created without searching for the element either in the cache 520 or the data source 510.

The optimistic search policy provides the best throughput and concurrency when elements are mostly in the cache 520. Conversely, when an optimistic search policy is used, it is very costly when elements are not stored in the cache 520.

Returning to FIG. 3, with the arrangements of a controller 400 and a broker 500 in mind, the following is a description of how controllers 400 and brokers 500 are employed in the system 200.

The function of the position receiver 320 is to act as an interface between various controllers of the system 200 and a input stream of data that requires valuation. The position receiver 230 is responsible for obtaining positions from the input adapters 300, 305, 310, converting the positions into a map (e.g., a set of name-value pairs), and placing the positions into an input queue of a position controller 325. The position controller 325 initiates a position-valuation process. As further described below, the position controller 325 also is responsible for placing a position into a cache of a load collector 355, which holds the position until its valuation is complete.

The position controller 325 receives, in its input queue, messages that contain position information in a raw format. These messages are received from the position receiver 325. The position controller 325 functions to construct a position object by retrieving asset information from the asset-data database 245 with help from an asset-data broker 345.

A position object includes a map (e.g., a set of name-value pairs) of position attributes, references to the asset information in the asset-data database 245 of the asset-data broker 345, references to market-data information in the market-data database 255 of the market-data broker 350, references to appropriate valuation models, and probability distributions created as a result of valuation. The position object itself is held in the cache of the load collector 355.

The position controller 325, a risk-exposure controller 330, and a valuation-range controller 335 (collectively referred to as “the controllers” with respect to FIG. 3) operate on references (tokens) to the position object and not on the position object itself. Only the references (tokens) are passed between the controllers 325, 330, 335. This process of passing tokens as opposed to the position objects themselves significantly reduces the overhead associated with the distributed nature of the valuation process, thus greatly improving the response time and throughput of the system 200.

The position controller 325 also functions to construct valuation adapters from rules contained in the rules database 250, with assistance from a product-information broker 340. A valuation adapter is an element primarily responsible for processing a valuation. A valuation adapter connects or links a position, its prices, its asset, and its valuation method with each other. The valuation method (model) for the position is contained in system libraries 370, which are referenced by the rules database 250 on a position-by-position basis. Each position has its own unique method of valuation, which is accomplished by retrieving appropriate combinations of routines from the system libraries 370. The valuation adapters control the execution of preparations for a valuation process as well as a valuation itself, by using a valuation method retrieved from the system libraries 370. The position controller 325 constructs market-data requests and populates prices for a position object from the market-data database 255, with assistance from the market-data broker 350.

A product-information broker 340 is responsible for producing a correct set of valuation adapters for a position based on the position's instrument and rules of a business unit holding the position. A model used for valuation of a particular position is dependent on the position's instrument, a business area or unit where the position originated, and a hypothetical scenario for which the position is to be valued. For example, the same bond can be valued using duration for one business area or unit, using duration and convexity for another business area or unit, and using full valuation if the scenario involves large moves in a yield curve. The product-information broker 340 uses a set of rules stored as metadata in the rules database 250 to analyze characteristics of a position and to correctly assign a proper valuation model and methodology for the position.

The asset broker 345 is responsible for providing asset information to the valuation adapters. The asset broker 345, is implemented in the broker pattern 500, as described above with respect to FIG. 5. The asset broker 345 serves as a repository of valuation-related data required during a valuation process. The valuation-related data required to perform valuation of a position differs from instrument to instrument. For a bond, valuation data normally includes of coupon, accretion, amortization, and reset schedules, if applicable. For an option, valuation data may include information about an underlying instrument, and so on. These data are used by a valuation-model implementation library in the system libraries 370 to produce a series of hypothetical profits and losses.

The position controller 325 is responsible for obtaining market data from the market-data database 255 and asset data from the asset-data database 245 required for valuation of a position, performing a preliminary valuation, such as computing sensitivities that are to be used in the valuation process, and obtaining from the product-information broker 340 nomenclature of risk exposures required for the position as well as valuation methodologies for each of the risk exposures. The position controller 325 creates risk-exposure objects, associates the risk-exposure objects with a position, and places each of the risk exposures into an input queue of the risk-exposure controller 330, thus initiating a valuation process of the risk exposure. It should be noted that there may be multiple risk exposures associated with a given position. For example, a convertible bond of a foreign corporation has equity, interest, foreign-exchange, and credit-risk exposures, as well as a full risk exposure. Each risk exposure may require its own valuation methodology and market data.

The risk-exposure controller 330 obtains a list or set of scenarios, according to which a risk exposure is to be valued. The set of scenarios is a configuration parameter of the valuation system 200. The risk-exposure controller 330 creates a set of hypothetical markets for each scenario, evaluates duration of valuation for each scenario, and breaks the set of scenarios into ranges in order to achieve a uniform elapsed valuation time per range. The particular valuation methodology employed depends on the scenario. For example, if a scenario involves large curve moves, full valuation may be required. If a scenario includes only small market moves, valuation using sensitivities may be sufficient. Therefore, valuation times for scenarios in the set may not be equal, and the number of scenarios in the ranges may be different.

The risk-exposure controller 330 is responsible for assigning a risk exposure to a cell in a multi-dimensional cube. The risk-exposure controller 330 also analyzes attributes of the risk exposure and assigns values for each of the cube's coordinates.

The valuation-range controller 335 is responsible for valuing a risk exposure according to scenarios contained in a range. As previously described, data for valuing a risk exposure in a range is passed to the valuation-range controller 335 from the risk-exposure controller 330. The valuation-range controller 335 forms an invocation sequence for an appropriate mathematical routine, and passes hypothetical market data and risk exposure parameters to the invocation sequence. The valuation-range controller 335 then obtains a market-value result and posts the result to a vector of profits and losses. When all scenarios in the range have been valued, the valuation-range controller 335 updates a counter of required valuations for a corresponding position object held in the load collector 355. When all the required valuations are completed for the risk exposure, the valuation-range controller 335 updates a counter of risk exposures (in the valuation-range collector 355). When all the risk exposures for a position have been valued, the valuation-range controller 335 marks the position as complete.

The market-data broker 350 is responsible for maintaining the market data in the market-data database 255. As described above with respect to the generic description of a broker pattern in connection with FIG. 5, if market data being requested is not found in the market-data database 255 of the market-data broker 350, the market-data broker 350 constructs the market data by executing a populate-member function of a price class, derived from a cacheable element. The price class knows how to retrieve raw market data from the market-data database 255, and how to construct required curves.

As briefly described above, the primary responsibility of the load collector 355 is to store (hold) positions while their risk exposures are being valued. The load collector 355 collects positions whose valuations have been completed, batches those positions together for better throughput, and loads the valued positions into the risk-positions database 260. Alternatively, the load collector 355 sends the valued positions into an output stream. Output adapters, such as a database adapter 360, serve as output-stream helpers. The database adapter 360 performs formatting functions to assist the load collector 355 in loading the valued positions into the risk-positions database 260. The load collector 355 also performs transaction management and database-error management. Other media adapters in addition to or instead of the database adapter 360 may be used. For example, a network adapter may be used if the output stream of valued positions is designated for other media, such as a network, instead of the risk-positions database 260.

As described above, the risk positions contained in the risk-positions database 260 is an external representation of a cell in a multi-dimensional cube. Each cell of the cube contains a set of coordinates, a set of hypothetical market values, and non-statistical attributes that are required in a subsequent risk analysis.

The follow describes, in general, an example of the system 200 in operation. The system 200 receives, for example, about 400 input streams per day. An input stream is either a file from a feeder system, or an XML message from front-end applications. The input streams contain positions that require valuation. The positions are loaded into the positions database 210 as a batch. Indicative information about the batch is sent to the valuation/risk engine 240. Upon receiving the batch, the position receiver 320 opens an input stream. In the case of a database, the input stream results from a set of SQL statements; in the case of a network, the input stream flows via a network connection. The position receiver 320 transforms a position into an internal form and sends the position to the position controller 325 for valuation. At the same time, the position receiver 320 sends the position to the load collector 355. The position is kept in a cache of the load collector 355 until the position is fully valued.

The position controller 325 obtains market data and asset data required for valuation of the position, as well as nomenclature of risk exposures for the position. The market data and the asset data are obtained by the position controller 325 with the assistance of the asset-data broker 345 and the market-data broker 350. The position controller 325 also identifies what methodologies should be used for valuation of the position with the assistance of the product-information broker 340. The position controller 325 then creates risk exposures and sends them to the risk-exposure controller 330, one by one.

The risk-exposure controller 330 identifies a set of scenarios for valuation. The set of scenarios is different from day to day, and from position to position within a day. The set of scenarios is dependent on market conditions and is created upon request from, for example, risk management staff. The risk-exposure controller 330 breaks the set of scenarios into subsets (e.g., ranges), based on an estimated valuation time and a ratio of valuation time to a dispatching time. Each range of scenarios is sent to the valuation-range controller 335. The valuation-range controller 335 functions to call valuation routines contained in the system libraries 370. The valuation-range controller 335 prepares call parameters from the market data and the asset data as well as position data for the position being valued. The market data for the position being valued is modified according to a definition of the scenario. At any given moment, there are multiple positions, risk exposures, and scenario ranges that are being processed by the system 200. When a position has been fully processed (all scenarios for each risk exposure have been valued), the position is removed from the cache of the load collector 355 and sent to the output stream. For better throughput, positions that have been valued are batched before being sent.

FIG. 6 schematically illustrates the query subsystem 270 of the system 200. The query subsystem 270 builds a multi-dimensional cube based on contents of a query request 600 submitted by a user, processed by a front-end unit, and passed the query subsystem 270 for processing. The organization and contents of the cube is based on criteria specified in the query request and data stored in the risk-positions database 260 or received from the hypothetical-positions database 265 through the valuation/risk engine 240 (see FIG. 2).

As previously described, the risk-positions database 260 represents a database implementation of a compressed cube. Only leaf-level nodes of data hierarchies of a multi-dimensional cube are stored in the risk-positions database 260. FIG. 7 schematically illustrates an example of a data hierarchy of a multi-dimensional cube. Preferably, there are twenty three (23) dimensions in the cube. Each dimension has multiple data hierarchies. Each data hierarchy has multiple levels. Circles (nodes) 700, 702, 704, 706, 708, 710, 712, 714, 716, 718 in FIG. 7 represent nodes of a data hierarchy, and horizontal lines L1, L2, L3 represent levels of the data hierarchy. The top node 700 in FIG. 7 is called the root node, and the nodes 706, 708, 710, 712, 714, 716, 718 are called leaf nodes. The top level L1 in FIG. 7 is called a root level, and the level L3 is called a leaf level.

According to the present invention, attributes of positions that may be used to select and aggregate data in a query are referred to as dimensions (as mentioned above, preferably there are twenty three (23) dimensions). Some common examples of attributes used in queries include business organization, currency, etc. The query engine or subsystem 270 uses one or more of the dimensions to classify positions.

The nodes 700, 702, 704, 706, 708, 710, 712, 714, 716, 718 represent a set of allowable values for a dimension. A node ID is a numeric representation of an allowable value for a given dimension. The nodes 700, 702, 704, 706, 708, 710, 712, 714, 716, 718 are unique within a dimension (i.e., that value can exist only once). However, the same node value may exist in different dimensions (e.g., United States Dollar (USD) has a value X in the currency dimension and Y in the instrument dimension). There is no connection between two different nodes having the same value, because they belong to two different dimensions. During loading of a position file, the loading process tries to match the value of each attribute to an existing node of a corresponding dimension.

Designating attributes of positions as nodes 700, 702, 704, 706, 708, 710, 712, 714, 716, 718 allows for building correspondence between the nodes 700, 702, 704, 706, 708, 710, 712, 714, 716, 718 and hence a correspondence between the attributes. As schematically illustrated in FIG. 7, the query subsystem 270 of the system 200 implements data hierarchies (trees) of nodes. A data hierarchy is specific to a dimension, just as a node is specific to a dimension. Some of the nodes 700, 702, 704, 706, 708, 710, 712, 714, 716, 718 may be created as part of a data hierarchy and may not directly represent an attribute of a position (e.g. “North America” could be a node in the currency dimension having child nodes corresponding to USD and Canadian Dollars (CAD)). In other cases, different positions. may map to different levels of a data hierarchy. For example, a New York/London trading location has two child nodes: New York and London. Some of the raw position feeds 215 have feeds in New York or London, and others may sit directly at the New York/London node.

A query or user request 600 (see FIG. 6) sent to the query engine or subsystem 270 includes three basic criteria: selection criteria; display criteria; and a set of characteristics. There also are optional criteria that may be specified by a user.

A selection criterion specifies what positions from the general universe will be included in the portfolio to be analyzed. A selection criterion includes node numbers, and an inclusion and/or exclusion clause. An example of a selection criterion is “INCLUDE:702:704:EXCLUDE:706:714.” For this example, all positions containing the nodes 702, 704, 708, 710, 712, 716, 718 must be included in the analyzed portfolio. Specifying a node means specifying all its descendants.

A display criterion specifies the dimensionality of a resulting portfolio and the level of aggregation. A display criterion includes display lines with the following structure: DIS:<hierarchy name>:<level name>. The number of display lines identifies the dimensionality of the portfolio. The level name identifies the level of aggregation. For example, if the level L1 from FIG. 7 is specified, positions referencing the nodes 702, 706, 708, 710 are aggregated and assigned to the node 702; positions referencing the nodes 704, 712, 714, 716, 718 are aggregated and assigned to the node 704; and positions referencing the node 700 are aggregated and assigned to a special unclassified node.

The set of characteristics specifies which statistical characteristics of every aggregated position (referred to as a cell) are to be calculated. Examples of characteristics include: mean; VaR at 99% confidence level; VaR at 97% confidence level; VaR at 95% confidence level; VaR at 1 standard deviation; standard deviation; marginal VaR at 99% confidence level in respect to the portfolio; incremental VaR at 99% confidence level in respect to the portfolio; skewness; kurtosis; outliers; fatness; trends at various lookback periods; idiosyncratic risk; and default/downgrade risk.

A query or user request 600 may specify multiple portfolios to be analyzed. In such a case, the selection criterion for each of the portfolios may be different, but the display criterion and the set of characteristics for each of the portfolios must be the same. The query subsystem 270 analyzes these portfolios and provides pair-wise comparisons for each of the specified characteristics.

The optional criteria is a clause utilized by a user to specify whether results of the query or user request 600 are to include total cells and/or corresponding information of additional detail data. If the user request 600 specifies that no total cells are to be calculated, then certain measures, which depend on calculated totals, will not be available. In a preferred embodiment, this clause is optional. By default, (i.e. if the clause is not specified) the results of the query or user request 600 will include calculated totals, but will not include the detail data.

Returning to FIG. 6, the following is a description of elements and an operation of the system 270. The system 270 uses the same controller and broker architecture as described above with respect to the valuation/risk engine 240. A request parser 605 parses the query or user request 600, identifies what portfolios need to be constructed, and passes a description of each portfolio to the a portfolio controller 610. The portfolio controller 610 builds a selection statement that corresponds to a selection criterion of the portfolio contained in the user request 600 and initiates execution of the user request 600. Resultant streams of risk positions are transformed into risk-position objects in a database adapter 625 or a network adapter 630, depending on a stream's source. Risk positions from the positions database 260 enter the query sub system 270 though the database adaptor 625. Hypothetical risk positions from the hypothetical positions database 265 (through the valuation/risk engine 240) enter the query sub system 270 through the network adapter 630. Risk-position objects from both sources are stored in a risk-positions broker 620.

A cube controller 615 requests risk-positions objects from the risk-positions broker 620 as they arrive. The cube controller 615 aggregates the risk positions to a requested aggregation level, as described above, and stores resulting risk cells into a risk-cells broker 635. After all risk positions are thus processed, the cube controller 615 passes control to an expansion controller 640.

The expansion controller 640 is responsible for building total cells. A total cell is a risk cell that contains an aggregation of other risk cells along one or more dimensions. For example, if a portfolio is a two-dimensional cube with the following risk cells: (n1,n3), (n1,n4), (n2,n3), and (n2,n4), then the two-dimensional cube has 5 total cells as follows:


(t,n3) contains an aggregate of (n1,n3) and (n2,n3);


(t,n4) contains an aggregate of (n1,n4) and (n2,n4);


(n1,t) contains an aggregate of (n1,n3) and (n1,n4);


(n2,t) contains an aggregate of (n2,n3) and (n2,n4); and


(t,t) contains an aggregate of all four of the above risk cells.

After the expansion controller 640 builds the total cells, it passes control to an analytical controller 645. The analytical controller 645 is responsible for calculating requested characteristics for each of the risk and total cells using a probability distribution of each cell, and passes the characteristics to an output controller 650. The output controller 650 uses an output-media adapter 655 to serialize-out cell objects according to requirements of each respective media, such as database, flat file, Excel, XML, etc.

According to another embodiment of the present invention, a data analysis method for analyzing risk positions uses a multi-dimensional risk representation that allows a standard OLAP engine to perform analysis on multi-dimensional data, in which the analysis includes context-dependent, heterogeneous aggregation functions. As schematically shown in FIG. 12, the multi-dimensional data is represented as a multi-dimensional cube 120, which consists of dimensions and cells 122. Each cell 122 includes a set of coordinates and either a scalar measure, a set of scalar and vector measures, or an object that implements calculation models. The set of coordinates contains all dimensions defined in the cube 120, and no more.

According to a preferred embodiment of the present invention, the multi-dimensional risk representation utilizes multi-dimensional data is represented as a multi-layered multi-dimensional cube (referred to herein as an “outer” cube), which consists of dimensions and cells. Each cell includes a set of coordinates and an inner multi-dimensional cube (referred to herein as an “inner” cube). Dimensions of the inner cube include all dimensions required for performing aggregations. Dimensions of the outer cube include only dimensions needed for context (or reporting). The dimensions of the outer cube need not be the same as the dimensions of the inner cube. Each cell of the inner cube contains another cube (sub-inner multi-dimensional cube) and/or a set of scalar and vector measures. That is, the term “multi-layered” derives from the cube within a cube within a cube, etc., structure. The outer cube may have one or more inner-cube layers. Aggregation is performed on the set of measures of the inner cube based on a context for the aggregation provided by the outer cube. In this way, unlike in conventional schemes for representing multi-dimensional data, context information is preserved even when multi-dimensional cubes undergo projection operations resulting in multi-dimensional cubes of fewer dimensions.

FIG. 13 schematically depicts a transformation from a conventional multi-dimensional (3D) cube 130 consisting solely of cells, to a multi-dimensional (2D) cube 120 consisting of dimensions and cells 122, to a one-dimensional (1D) cube 132 consisting of dimensions and cells 134.

Inner-Cube Structure

The term “position” (P) refers to an object consisting of a measure object (M) and a set of coordinates (S). That is P={S, M}. P corresponds to original information (“position information”) from which a cell is constructed at a leaf level of a data hierarchy. Position information is added (mapped) to each cell of a multi-dimensional cube. According to a preferred embodiment, P represents information of a risk position of a portfolio of a financial institution.

For an n-dimensional cube, S is given by S={v, v2, v3, . . . , vn}. For all k where k is an element of a set that includes 1 through n (i.e., ∀k, k∈[1, n]), vk is a value from a data hierarchy for the kth dimension. M refers to a set of desired measures and defines a summation operator.

The term “cell” (C) refers to an object consisting of a measure object (M) and a set of coordinates (S). That is, C={S, M}. For a n-dimensional cube, S is given by S={v1, v2, v3, . . . , vn}. M refers to a set of desired measures and defines a summation operator.

If, for all k where k is an element of a set that includes 1 through n (i.e., ∀k, k∈[1, n]), vk is a value from a data hierarchy for the kth dimension, then the cell is called a body cell. That is, the cell has not undergone a previous projection and thus has all of its original dimensions.

If there is exactly one k that is an element of the set that includes 1 through n (i.e., k∈[1, n]) for which vk is “−” or negative, then the cell is called a total cell of (n−1)th order. That is, the cell has previously undergone one projection and its original dimensions have been reduced by one.

If there are exactly two values of k that are elements of the set that includes 1 through n (i.e., k∈[1, n]) for which vk is “−” or negative, then the cell is called a total cell of (n−2)th order. That is, the cell has previously undergone two projections and its original dimensions have been reduced by two.

If there are exactly n−1 values of k that are elements of the set that includes 1 through n (i.e., k∈[1, n]) for which vk is “−” or negative, then the cell is called a “total” cell of 1st order. That is, the cell has undergone a total projection and its original dimensions have been reduced to one remaining dimension.

If there are exactly n values of k that are elements of the set that includes 1 through n (i.e., k∈[1, n]) for which vk is “−” or negative, then the cell is called a total cell of 0th order, or a “global” total cell. That is, the cell has undergone a global projection and all of its original dimensions eliminated through projections.

All cells have a set of dimensions consisting of identical dimensions.

Inner-Cube Operations

Each inner cube performs operations that include: position addition; cube projection; cube roll-up; and cube merge.

A. Position Addition to Inner Cube

For each incoming position P consisting of a measures object (MP) and a set of coordinates (SP) (i.e., P={SP, MP}), and for each inner-cube cell C consisting of a measures object (MC) and a set of coordinates (SC) (i.e., C={SC, MC}) such that ∀k, k∈[1, n], a mapping operation for mapping coordinates and measures of the position P to an inner-cube cell C is given by:


C→SC→vk={P→SP→vk|“−”}, set C→MC+=P→MP.  Equation 1

In other words, in the mapping operation of Equation 1, for each value vk that belongs to a set of coordinates SC that belongs to a cell C, and for a corresponding value vk that belongs to a set of coordinates SP that belongs to a position P, measures that belong to the position P (MP) are mapped and added to measures that belong to the cell C (MC). This mapping operation takes place for all cells of the inner cube.

B. Inner-Cube Projections

A projection is an operation to collapse or remove a dimension of a cell of an inner cube by projecting that dimension onto other dimension(s) (i.e., the remaining dimension(s)) of the inner cube. In a projection according to the present invention, IN={CN} denotes an N-dimensional inner cube as a collection of N-dimensional cells CN. A “roll-up” operation of the inner cube projects the inner cube IN onto an (N−1)-dimensional cube IN−1J, where the dimension J is removed from the set of coordinates. The projection is executed as follows:

For each N-dimensional cell CN that is an element of the inner cube IN (i.e., CN∈IN), and ∀k, k∈[1, n], k≠J, every cell C′ of is found such that


IN−1J→C′→SC→vk=IN→C→SC→vk,   Equation 2

and the following mapping operation is set:


IN−1J→C′→MC=fJOC,μ(IN−1J→C′→MC, IN→C→MC),  Equation 3

where fJOC,μ( . . . ) is a J-dependent aggregation function. The aggregation function also depends on the context determined by the cell of the outer cube to which this inner cube belongs, and the measure currently being calculated. That is, the inner cube IN−1J is formed by collapsing or removing the dimension J by projection onto the remaining dimensions of the inner cube IN according to the J-dependent aggregation function fJOC,μ( . . . ).

C. Inner-Cube Roll-Up

FIG. 14 schematically depicts a structure of data hierarchy of a cube. A roll-up is a total projection of a dimension for a level of a data hierarchy. If nodes for dimension j are drawn from level z, i.e, ∀IN→C, IN→C→SC→vj∈Θjz, where Θjz is a set of nodes from a data hierarchy of dimension j at level z, then an inner-cube roll-up from level z to level z−1 is executed as follows:

Let IZJ denote an inner cube in which a set of values for the Jth dimension is drawn from a level Z, and let IZ−1J denote an inner cube in which a set of values for the Jth dimension is drawn from a level Z−1. Then, for each cell C∈IzJ, the cell C′ of cube IZ−1J (for which a value IZ−1J→C′→SC→vJ is the parent of a value IZJ→C→SC→v′J) is found such that


IZ−1J→C′→MC=fZJOC,μ(IZ−1J→C′→MC, IZJ→C→MC),  Equation 4

where fZJOC,μ( . . . ) is a J-dependent and Z-dependent aggregation function, OC refers to the outer cube, and μ refers to an aggregation methodology. Notice that the aggregation function depends on the context determined by the cell of the outer cube to which this inner cube belongs, as well as the measure currently being calculated. Also notice that a projection eliminating the dimension J (total projection) is equivalent to a roll-up for dimension J.

D. Inner-Cube Merge

In a merge operation in which an inner cube IN is merged with an inner cube I′N, for each cell C of the inner cube IN and each cell C′ of the inner cube I′N, and ∀k, k∈[1, n], then


IN→C→SC→vk=I′N→C′→SC→vk and I′N→C′→MC+=IN→C→MC.  Equation 5

Note that a merge operation may be performed only on cubes with identical sets of dimensions at identical hierarchy levels.

Outer-Cube Structure

Similar to the discussion above in connection with inner cubes, the term “position” (P) refers to an object consisting of a measure object (M) and a set of coordinates (S). That is P={S, M}. P corresponds to original information (“position information”) from which a cell is constructed at a leaf level of a data hierarchy. Position information is added (mapped) to each cell of a multi-dimensional cube. According to a preferred embodiment, P represents information of a risk position of a portfolio of a financial institution.

For an n-dimensional cube, S is given by S={v1, v2, v3, . . . , vn}. For all k where k is an element of a set that includes 1 through n (i.e., ∀k, k∈[1, n]), vk is a value from a data hierarchy for the kth dimension. M refers to a scalar of desired measures and defines a summation operator.

The term “cell” (C) refers to an object consisting of a measure object (I) and a set of coordinates (S). That is, C={S, I}. For a n-dimensional cube, S is given by S={v1, v2, v3, . . . , vn}. I represents an inner cube whose set of dimensions may be different from the set of dimensions for I's corresponding outer cube.

If, for all k where k is an element of a set that includes 1 through n (i.e., ⇑k, k∈[1, n]), vk is a value from a data hierarchy for the kth dimension, then the cell is called a body cell. That is, the cell has not undergone a previous projection and thus has all of its original dimensions.

If there is exactly one k that is an element of the set that includes 1 through n (i.e., k∈[1, n]) for which vk is “−” or negative, then the cell is called a total cell of (n−1)th order. That is, the cell has previously undergone one projection and its original dimensions have been reduced by one.

If there are exactly two values of k that are elements of the set that includes 1 through n (i.e., k∈[1, n]) for which vk is “−” or negative, then the cell is called a total cell of (n−2)th order. That is, the cell has previously undergone two projections and its original dimensions have been reduced by two.

If there are exactly n−1 values of k that are elements of the set that includes 1 through n (i.e., k∈[1, n]) for which vk is “−” or negative, then the cell is called a “total” cell of order. That is, the cell has undergone a total projection and its original dimensions have been reduced to one remaining dimension.

If there are exactly n values of k that are elements of the set that includes 1 through n (i.e., k∈[1, n]) for which vk is “−” or negative, then the cell is called a total cell of 0th order, or a “global” total cell. That is, the cell has undergone a global projection and all of its original dimensions eliminated through projections.

All cells have a set of dimensions consisting of identical dimensions.

Outer-Cube Operations

Each outer cube performs operations that include: position addition; cube projection; cube roll-up; and calculation of measures.

A. Position Addition to Outer Cube

For each incoming position P consisting of measures (MP) and a set of coordinates (SP) (i.e., P={SP, MP}), and for each outer-cube cell C consisting of an inner cube (IC) and a set of coordinates (SC) (i.e., C={SC, IC}) such that ∀k, k∈[1, n], ∀m, m ∈[1, j], a mapping operation for mapping coordinates and measures of the position P to a cell C′ of the inner cube of the cell C is given by


C→SC→vk={P→SP→vk|“−”} and C→IC→C′→SC→vm={P→SP→vm|“−”}, set


C→IC→C′→MC′+=P→MP.  Equation 6

In other words, in the mapping operation of Equation 6, for a value vk that belongs to dimension k of a set of coordinates SC that belongs to a cell C, and for a corresponding value vk that belongs to dimension k of a set of coordinates SP that belongs to a position P, and for a value vm that belongs to dimension m of a set of coordinates SC. that belongs to a cell C′ of the inner cube IC of the cell C, and for a corresponding value vk that belongs to dimension m of a set of coordinates SP that belongs to a position P, measures that belong to the position P (MP) are mapped and added to measures that belong to the cell C′ of the inner cube of the cell C (MC′). This mapping operation is similar to what takes place when adding a position to an inner cube, as discussed above in the section entitled “Position Addition to Inner Cube,” and takes place for all inner cubes IC of the cell C.

B. Outer-Cube Projections

In a projection according to the present invention, ON={CN} denotes an N-dimensional outer cube as a collection of N-dimensional cells CN. A “roll-up” operation of the outer cube projects the outer cube ON onto an (N−1)-dimensional cube ON−1J, where the dimension J is removed from the set of coordinates. The projection is executed as follows:

For each N-dimensional cell CN that is an element of the outer cube ON (i.e., CN∈ON), and ∀k, k∈[1, n], k≠J, every cell C′ of ON−1J is found such that


ON−1J→C′→SC→vk=ON→C→SC→vk.  Equation 7

Then, an inner cube ONJ→C→IC is merged with an inner cube ON−1J→C′→IC as described above in the section entitled “Inner-Cube Merge.”

C. Outer-Cube Roll-Up

If nodes for dimension j are drawn from level z, i.e, ∀ON→C ON→C→SC→vJ∈Θjz, where Θjz is a set of nodes from a data hierarchy of dimension j at level z, then an outer-cube roll-up from level z to level z−1 is executed as follows:

Let OZJ denote an outer cube in which a set of values for the Jth dimension is drawn from a level Z, and let OZ−1J denote an outer cube in which a set of values for the Jth dimension is drawn from a level Z−1. Then, for each cell C∈OZJ, the cell C′ of the outer cube OZ−1J (for which a value OZ−1J→C′→SC→vJ is the parent of a value OZJ→C→SC→v′J) is found, and an inner cube ONJ→C→IC is merged with an inner cube ON−1J→C′→IC as described above in the section entitled “Inner-Cube Merge.”

D. Calculation of Measures

For each measure μ of every outer-cube cell C, an inner cube C→MNC of the cell is projected onto a zero-dimensional cube C→MOC,μ, such that


μ=fμ(C→MOC,μ),  Equation 8

where fμ( . . . ) is an aggregation function that may be as simple as a summation operation or as complex as a derivative security-valuation model.

EXAMPLE

The following example shows how the inventive data analysis method for analyzing risk positions, as described above, is applied to the portfolio of positions listed in Table 1.

The positions in Table 1 are organized as a 2D multi-layered cube with the dimensions Legal Entity and Currency, as schematically shown in FIG. 15. The inner cubes are 1D cubes with the dimension Issuer and two measures: MTM and Exposure. As discussed above, MTM is aggregated by algebraic summation, and Exposure is aggregated by netting for each Issuer separately and then grossing between all Issuers. With this arrangement, cells with inner cubes C1 through C6 in FIG. 15 hold information as shown in Tables 10 through 15, respectively.

TABLE 10 CELL WITH INNER CUBE C1 Legal Entity Currency Issuer MTM Exposure FSA USD GE 250 20 FSA USD GM 450 30 FSA USD IBM −500 −80

TABLE 11 CELL WITH INNER CUBE C2 Legal Entity Currency Issuer MTM Exposure FRB USD GM −200 −20 FRB USD GM 150 10

TABLE 12 CELL WITH INNER CUBE C3 Legal Entity Currency Issuer MTM Exposure FSA GBP GE −300 −10 FSA GBP IBM 100 10

TABLE 13 CELL WITH INNER CUBE C4 Legal Entity Currency Issuer MTM Exposure FRB GBP GM 300 20 FRB GBP GM −300 −20

TABLE 14 CELL WITH INNER CUBE C5 Legal Entity Currency Issuer MTM Exposure FSA JPY IBM 450 30

TABLE 15 CELL WITH INNER CUBE C6 Legal Entity Currency Issuer MTM Exposure FRB JPY GM 600 −50

For a query to calculate MTM and Exposure by Legal Entity, analysis of the portfolio of positions listed in Table 1 proceeds as follows:

First, the 2D cube of FIG. 15 is projected onto the dimension Legal Entity, such that a 1D cube 160 results, as schematically depicted in FIG. 16. In FIG. 16, the cell with the inner cube C-FSA is the result of projecting the cell with the inner cube C1, the cell with the inner cube C3, and the cell with the inner cube C5 onto the dimension (Legal Entity) FSA; and the cell with the inner cube C-FRB is the result of projecting the cell with the inner cube C2, the cell with the inner cube C4, and the cell with the inner cube C6 onto the dimension (Legal Entity) FRB. That is, the inner cube of the cell C-FSA is an algebraic aggregation of the inner cube of the cell C1, the inner cube of the cell C3, and the inner cube of the cell C5, with the aggregation results shown in Table 16; and the inner cube of the cell C-FRB is an algebraic aggregation of the inner cube of the cell C2, the inner cube of the cell C4, and the inner cube of the cell C6, with the aggregation results shown in Table 17.

TABLE 16 C-FSA Legal Entity Issuer MTM Exposure FSA GE −50 10 FSA GM 450 30 FSA IBM −50 −40

TABLE 17 C-FRB Legal Entity Issuer MTM Exposure FRB GM 550 −60

Next, the MTM for each Legal Entity is calculated by algebraically summing the MTMs for all issuers. The Exposure for each Legal Entity is calculated by netting the Exposures for each Issuer separately (already done in Table 15) and then grossing between all Issuers. This yields the results shown in Table 18. The results are the same as those computed in the conventional manner, shown in Table 5.

TABLE 18 QUERY RESULTS Legal Entity MTM Exposure FRB 550 60 FSA 450 80

FIG. 17 schematically depicts further aggregation of the 1D multi-layered cube 160 into a multi-layered C-Corp cube of zero dimensions. To obtain the cell C-Corp of the resulting cube, the inner cube of the cell C-FSA of the 1D multi-layered cube 160 and the inner cube of the cell C-FRB of the 1D multi-layered cube 160 are obtained as described above, and an algebraic aggregation of the inner cube of the cell C-FSA cube and the inner cube of the cell C-FRB cube is performed, which yields the results listed in Table 19.

TABLE 19 AGGREGATION OF C-FSA AND C-FRB BY ISSUER Issuer MTM Exposure GE −50 10 GM 1000 −30 IBM 50 −40

Then, the MTMs are algebraically summed, and the Exposures are grossed. Table 20 lists the results of these operations.

TABLE 20 RESULTS FOR C-CORP C-Corp MTM = 1000 Exposure = 80

The results in Table 20 are the same as those in Table 7 but were obtained in a generic manner. Through the use of multi-layered and multi-dimensional cubes, context independent and heterogeneous aggregations are possible. Whereas conventional aggregation schemes result in the loss of information as dimensions are eliminated by projections, the data analysis method of the present invention preserves all the original information so that it is possible to obtain the results in Table 20 from the data in Table 19 without having to go back to the original information in Table 1 to perform calculations on data that was lost (eliminated) due to projections.

While the present invention has been described with respect to what is presently considered to be the preferred embodiment(s), it is to be understood that the invention is not limited to the disclosed embodiment(s). To the contrary, the invention is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims. The scope of the following claims is to be accorded the broadest interpretation so as to encompass all such modifications and equivalent structures and functions.

For example, although VaR is identified as a measure of risk used by financial institutions for quantitative assessment and comparison purposes, the present invention is applicable to other non-linear measures of risk assessment and management.

As will be appreciated, the inventive methods may be embodied on computer-executable code that is stored on a computer-readable medium, for example, a floppy disk, a hard drive, removable media, an optical memory, a magneto-optical memory, a RAM, a ROM, a flash memory, so-called “memory sticks,” and the like.

Claims

1. A method of representing a portfolio of financial positions on which a risk analysis is to be performed, comprising the steps of:

constructing an outer cube representing the portfolio of financial positions as a multi-layered multi-dimensional cube that includes cells and dimensions; and
constructing each cell of the plurality of cells to include a set of coordinates and an inner cube, wherein the inner cube is a multi-dimensional cube that includes cells and dimensions, wherein the dimensions of the outer cube include information relating to a context of the risk analysis, wherein the dimensions of the inner cube include all dimensions required to perform an aggregation operation on the portfolio of financial positions, wherein each cell of the inner cube includes a set of measures, which includes at least one scalar measure and at least one vector measure, and wherein the aggregation operation is performed on the set of measures according to the dimensions of the inner cube and according to the context of the risk analysis included in the dimensions of the outer cube.

2. A method according to claim 1, wherein each cell of the inner cube includes a sub-inner cube that is a multi-dimensional cube that includes cells and dimensions.

3. A method according to claim 1, wherein the dimensions of the inner cube is different from the dimensions of the outer cube.

4. A method according to claim I, wherein each position in the portfolio of financial positions is an object that includes a set of coordinates S and a measures object M.

5. A method according to claim 5, wherein M includes a set of desired measures and defines the aggregation operation.

6. A programmable computer for use in performing a risk analysis on a portfolio of financial positions, comprising:

at least one memory including at least one region for storing computer executable program code; and
a processor for executing the program code stored in the at least one memory, wherein the program code includes:
code for constructing an outer cube representing the portfolio of financial positions as a multi-layered multi-dimensional cube that includes cells and dimensions; and
code for constructing each cell of the plurality of cells to include a set of coordinates and an inner cube, wherein the inner cube is a multi-dimensional cube that includes cells and dimensions, wherein the dimensions of the outer cube include information relating to a context of the risk analysis, wherein the dimensions of the inner cube include all dimensions required to perform an aggregation operation on the portfolio of financial positions, wherein each cell of the inner cube includes a set of measures, which includes at least one scalar measure and at least one vector measure, and wherein the aggregation operation is performed on the set of measures according to the dimensions of the inner cube and according to the context of the risk analysis included in the dimensions of the outer cube.

7. A computer-readable storage medium storing a computer program for executing a method of representing a portfolio of financial positions on which a risk analysis is to be performed, wherein the computer program comprises:

code for constructing an outer cube representing the portfolio of financial positions as a multi-layered multi-dimensional cube that includes cells and dimensions; and
code for constructing each cell of the plurality of cells to include a set of coordinates and an inner cube, wherein the inner cube is a multi-dimensional cube that includes cells and dimensions, wherein the dimensions of the outer cube include information relating to a context of the risk analysis, wherein the dimensions of the inner cube include all dimensions required to perform an aggregation operation on the portfolio of financial positions, wherein each cell of the inner cube includes a set of measures, which includes at least one scalar measure and at least one vector measure, and wherein the aggregation operation is performed on the set of measures according to the dimensions of the inner cube and according to the context of the risk analysis included in the dimensions of the outer cube.

8. A method of performing risk analysis on a portfolio of financial positions, comprising the steps of:

constructing an outer cube representing the portfolio of financial positions as a multi-layered multi-dimensional cube that includes cells and dimensions;
constructing each cell of the plurality of cells to include a set of coordinates and an inner cube, wherein the inner cube is a multi-dimensional cube that includes cells and dimensions, wherein the dimensions of the outer cube include information relating to a context of the risk analysis, wherein the dimensions of the inner cube include all dimensions required to perform an aggregation operation on the portfolio of financial positions, and wherein each cell of the inner cube includes a set of measures, which includes at least one scalar measure and at least one vector measure;
performing an aggregation operation on the set of measures according to the dimensions of the inner cube and according to the context of the risk analysis included in the dimensions of the outer cube.

9. A method according to claim 8, wherein each cell of the inner cube includes a sub-inner cube that is a multi-dimensional cube that includes cells and dimensions.

10. A method according to claim 8, wherein the dimensions of the inner cube is different from the dimensions of the outer cube.

11. A method according to claim 8, wherein each position in the portfolio of financial positions is an object that includes a set of coordinates S and a measures object M.

12. A method according to claim 11, wherein M includes a set of desired measures and defines the aggregation operation.

13. A programmable computer for use in performing a risk analysis on a portfolio of financial positions, comprising:

at least one memory including at least one region for storing computer executable program code; and
a processor for executing the program code stored in the at least one memory, wherein the program code includes: code for constructing an outer cube representing the portfolio of financial positions as a multi-layered multi-dimensional cube that includes cells and dimensions; code for constructing each cell of the plurality of cells to include a set of coordinates and an inner cube, wherein the inner cube is a multi-dimensional cube that includes cells and dimensions, wherein the dimensions of the outer cube include information relating to a context of the risk analysis, wherein the dimensions of the inner cube include all dimensions required to perform an aggregation operation on the portfolio of financial positions, and wherein each cell of the inner cube includes a set of measures, which includes at least one scalar measure and at least one vector measure; code for performing an aggregation operation on the set of measures according to the dimensions of the inner cube and according to the context of the risk analysis included in the dimensions of the outer cube.

14. A computer-readable storage medium storing a computer program for executing a method of performing risking analysis on a portfolio of financial positions, wherein the computer program comprises:

code for constructing an outer cube representing the portfolio of financial positions as a multi-layered multi-dimensional cube that includes cells and dimensions;
code for constructing each cell of the plurality of cells to include a set of coordinates and an inner cube, wherein the inner cube is a multi-dimensional cube that includes cells and dimensions, wherein the dimensions of the outer cube include information relating to a context of the risk analysis, wherein the dimensions of the inner cube include all dimensions required to perform an aggregation operation on the portfolio of financial positions, and wherein each cell of the inner cube includes a set of measures, which includes at least one scalar measure and at least one vector measure;
code for performing an aggregation operation on the set of measures according to the dimensions of the inner cube and according to the context of the risk analysis included in the dimensions of the outer cube.
Patent History
Publication number: 20100235300
Type: Application
Filed: Apr 6, 2010
Publication Date: Sep 16, 2010
Inventor: Vincent Feingold (Haledon, NJ)
Application Number: 12/755,102
Classifications
Current U.S. Class: 705/36.0R; Reporting, Knowledge Discovery (kd) Systems (707/603); Information Processing Systems, E.g., Multimedia Systems, Etc. (epo) (707/E17.009)
International Classification: G06Q 40/00 (20060101); G06F 17/30 (20060101);