ALEXANDER TSIGUTKIN

Adapting Systems to Rapid Change

Alexander Tsigutkin, president of Axiom Software Laboratories, explains why static risk management systems don’t work.

In response to a rapidly changing global business environment, financial companies and energy trading firms are continually developing new financial products and new derivatives and entering into new types of transactions. New regulatory reporting requirements appear regularly, and these usually differ significantly from the company’s own rapidly evolving internal reporting requirements. On top of that, new systems are being developed and new trading systems are being acquired, with constant changes and enhancements to the existing systems.

A company’s technology infrastructure should be dynamic enough to support such rapid change. Systems are dynamic if they have the ability to adapt to changes - business changes as well as technological evolution -without lengthy programming and interfacing, using features that are built into the product. Most traditional systems, however, are too inflexible and static. They address changes pretty much on a case-by-case basis. As the new developments and new problems occur the technical team tries to patch together a solution.

Most traditional systems are mired down by a standard static data model. A data model is the structure capable of accommodating all fields of information related to trading systems. In a relational database, which is generally used in the industry to accommodate information storage, this table structure is difficult to change, because all of the decision-making mechanisms - the methodology, the risk engine, the risk applications - are hard-coded. Modification of a particular static data model would have to be reflected in all of the applications and in the risk engine. Another complication is that the bulk of these programs are written as linear applications. Although the applications might be object-oriented, they are still difficult to modify. Resources for IT also may be limited, and retaining the same application development group for the process of constantly enhancing the risk management system can become burdensome.

Another problematic issue with traditional systems involves performance. Trying to accumulate a large amount of information within the same data structure for long periods of time can cause performance problems. This is particularly troublesome in the risk management process overall, which relies heavily on historical information. Historical information, in this case, can mean history from market data or time series perspectives, or the history of one’s portfolio. Users must constantly back-test the risk results against real profits or losses. But in order to do that, one must have access to historical information dating as far back as a year, maybe several years.

Static systems also have a problem consolidating multiple sources of information, because one is only able to take into consideration common elements across all different sources. As a result, some of the specifics of the transactions must be disregarded. For example, a maturity date may be common for all elements, but collateral information for certain types of securities might be found in one source of data and missing from another source. The system would have to drop that information in order to organize information using common elements. But that doesn’t mean that collateral information is not important, or that it should not be taken into account by the standard model.

Static systems, moreover, take a long time to implement. One must create specialized mapping processes and specialized links from the front and back-office systems into that static data model ...a time-consuming effort. lt’s quite difficult to come up with a good one-size-fits-all standard. What happens in the end is that companies write specialized transformation codes just to corral current multiple sources of data for the institution.

Users of static systems often resort to feeding all enterprise data into a structure that is not necessarily able to accommodate the data. Inevitably, they are caught between Scylla and Charybdis. There are two choices: either drop the information that doesn’t fit, or try to modify the data model. And of course, both of those choices are a step back on the business side.

It is difficult to do any kind of research and development for new financial products and services in such an environment. R&D, from the financial perspective, occurs most often in the middle office, where there is a convergence of different risks within portfolios that cannot be seen from the individual desks. To make decisions about the efficiency of the portfolio, one must be able to aggregate information across different sources in a quick and flexible manner. If the middle-office database does not keep different sources of information well-organized, users won’t be able to attach analytics and get rolling with new product development, which is key in competitive markets.

A truly dynamic middle-office product requires a dynamic data model that is capable of dealing with all the changes on the data side that can occur. A flexible risk model is required to interact with the dynamic data model. This risk model has to be able to accept business rules from the users and be driven by risk parameters and risk assumptions, depending on the risk methodology that must be performed.

In addition, the user must be able to make use of constantly evolving financial engineering analytics such as pricing models and pricing engines. These dynamic applications should be able to display the results of user specifications and be flexible enough to reflect whatever changes have taken place or what ever new aggregations need to be performed. A dynamic risk management system will be up and running much faster and more effectively because it has the inherent ability to adapt to the institution’s risk management environment, as opposed to requiring adaptation of the environment to the risk system.

Reprinted with the permission from DERIVATIVES STRATEGY.