A former weapons and space systems package wins favor as a derivatives modeling tool.

Peter P. Carr
Assistant professor of finance , Cornell University

Who says swords can't be turned into plowshares? Here is a flexible, easy-to-use pro- gramming environment that was originally developed for engineers and scientists which is now winning friends in finance. Created by the Massachusetts-based MathWorks Co., this package has proved popular for over a decade in the defense industry as a modeling tool for weapons and space systems. With the recent migration to Wall Street by many scientists from the academies and from the military industrial complex, MATLAB has gained a following on trading floors and in research departments at major banks. One key to its growing ubiquity: non-programmers find it relatively easy to learn. This software has also become widely accepted as a teaching tool in many graduate finance programs; when these students find jobs in finance, they take their MATLAB skills with them.

Sophisticated graphics and an open-ended design make the program well adapted to analyzing new, complex derivatives and for testing new models. To facilitate these tasks, MATLAB offers the Financial Toolbox, giving end-users a selection of time-saving, pre-coded functions that can be used within custom programs. Toolbox applications include securities pricing, interest and yield calculations, portfolio optimization, and derivatives analysis.

About a year ago I was introduced to this software by a very bright MBA student, who insisted we use it for an independent studies project. At first I resisted the suggestion. I did not relish the prospect of getting up to speed on yet another late-generation programming language. But I must admit, I was also intrigued-I had noticed that MATLAB was becoming widely used at Cornell. I figured it wouldn't hurt to check it out. In addition, I had noticed that I was spending more and more of my research time resolving thorny numerical issues, rather than concentrating on the more important issues of finance. Like many people I know, I have been disappointed by the numerical aspects of symbolic packages such as Mathematica. Since MATLAB was developed by experts in numerical analysis, I was hoping the program would free me from reinventing the wheel every time I needed to invert a matrix or find its eigenvalues. I was not disappointed.

In the space of about one month, we designed a graphical options pricing system which we feel rivals commercially available packages for ease of use. We used MATLAB for Windows on two platforms, a Pentium 90 mhz machine and an IBM Thinkpad 386/7. This highlights one of the biggest selling points of MATLAB, namely its portability across platforms. Indeed, we plan to make our software available over the World Wide Web, using a Power Mac as the server.

Like most late generation languages, MATLAB offers faster development speed compared to more mundane languages such as C. While computation time was a bit of a problem for the 3D graphics displays on the Thinkpad, it was simply not an issue on the Pentium machine. I anticipate that as computing technology continues to accelerate, the rapid development time and transparency of the code will make the computational disadvantage we experienced a minor irritant.

MATLAB has a wide assortment of tools that are useful in modeling financial derivatives. We implemented several standard valuation technologies such as closed form solutions, binomial model values, finite differences, and Monte Carlo simulation. With respect to the latter technique, SIMULINK shows great promise as a quick way to structure financial derivatives to meet certain pre-ordained objectives. We also successfully implemented some promising new valuation and hedging techniques based on the method of lines and put/call symmetry. Implying out parameters such as volatility was a snap, as was generating 2 and 3D graphics in real time.

There are a wide assortment of books available on using MATLAB in specialized situations. In addition, the staff at The MathWorks are very knowledgeable about finance, and seem eager to integrate MATLAB into existing technologies. I'm glad I took the time to learn how to use MATLAB, and I'm sure others are as well. When you need to know a number in a hurry, MATLAB stands out as an excellent choice.

Alexander Eydeland
Vice president, Structured Products Group, Fuji Capital Markets Corp.

I have been using MATLAB for almost ten years, and I am still impressed by how powerful it is. MATLAB is more than just a software package-it is a friendly and flexible development environment designed to facilitate solving complex computational problems and building numerical models. MATLAB consists of a core set of mathematical functions and a constantly growing number of add-on Toolboxes. The core set includes a great variety of mathematical algorithms, including linear algebra routines, polynomial and spline interpolation, root finding, powerful graphics, etc. The Toolboxes supplement these core routines to satisfy the particular needs of MATLAB users. Of interest for financial applications are the Optimization, Statistics, and Neural Network Toolboxes, and the recently created Financial Toolbox.

Since MATLAB is an interpreted language, it can be easily learned. In just a few hours, new users here at Fuji Cap become familiar enough with MATLAB to solve large systems of equations or to plot three dimensional graphs. Writing code to solve a problem in MATLAB closely follows the way one would naturally derive a solution on paper; and, after the general steps are specified, MATLAB fills in the details. From its very first release, MATLAB has been designed to solve large scale problems efficiently-another feature that distinguishes it from its competitors.

Its flexibility, ease of use, and computational efficiency make MATLAB irreplaceable for specifying structured products and for prototyping and building complex pricing models. Be it a multi-index Monte Carlo algorithm, multi-dimensional lattice procedures, a fast Fourier transform, or an efficient PDE solver, MATLAB supplies all the necessary ingredients for quick implementation of your models.

MATLAB has proven extremely useful in prototyping our models. Before coding a model in C or C++, we implement it in MATLAB. Within a short period of time we know the particulars and subtleties of the model, allowing us to make production implementation faster and more efficiently than it otherwise would be.

Mostly, we use MATLAB for new model development. Before fleshing out generalized software, we test new procedures in MATLAB for building yield curves and pricing a great number of complex derivative products, including index principal swaps, callable swaps, captions, periodic structures, etc. MATLAB is particularly useful when pricing one-time-only structures, precisely because, in these instances, developing reliable models and generating prices quickly is more critical than producing code suitable for use in generalized applications.

MATLAB has exceptional graphics capabilities which are as easy to master as the rest of the package. Animation, 3D graphs, image manipulation, and graphical input can all be accessed with only a couple of lines of code. MATLAB also provides a powerful and easy to use GUI builder. Connecting with applications written in other languages is no problem.

From the start, MATLAB has been especially well received in universities, government labs, and research departments of big corporations. It has only recently been introduced to the financial world where, based on our experience at Fuji Capital Markets, I fully expect that it will enjoy similar success.

Dino de Angelis
Vice president, SAIG Trading roup Inc.

Developing business in complex derivatives requires significant investments in financial engineering talent - system tenders, quants and sales staff. Typically, traders and sales staff conceptualize and prototype their ideas in Excel spreadsheets and rudimentary C-programs which, as deals, are warehoused, managed, are subsequently turned over to professional programmers to be converted to production level programs and integrated into the firm's management system.

But there are limitations to this approach. As financial engineering grows in mathematical complexity, applications such as Excel are no longer adequate for rapidly prototyping and testing the required financial analysis. Fortunately, as engineers and applied scientists metamorphose into financial engineers, they bring with them well-tested computer applications and environments. The most widely known of such applications is the MathWork's MATLAB, a powerful and inexpensive analytical environment available for both Unix workstations and PCs.

Thanks to my background in engineering, I have been familiar with MATLAB for some time. MATLAB evolved as a tool among engineers to facilitate developing and running algorithms on very large sets of data. MATLAB has as its core a high level programming language and a powerful library of analytical tools which allow practitioners and academics to rapidly prototype and test sophisticated analytics.

By simplifying programming detail to allow emphasis on mathematics and by providing excellent graphics capabilities, MATLAB quickly became a standard among practitioners and academics. Programs were written and shared-much as happens in the finance and investment field with Excel spreadsheets. Specialized "Toolboxes" were then introduced, assembled by collecting programs from the most recognized theoreticians and practitioners in a specific field, and packaged for general use. Currently the MATLAB Toolboxes for Neural Networks, Fuzzy Logic, Differential Equations, and Optimization represent the state of art.

The MathWorks is now developing a Financial Toolbox using the same approach. Since business schools and financial firms are increasingly using MATLAB, this should provide good sources for such a Toolbox. At AIG Trading Group, MATLAB has been interfaced with Excel to form a powerful rapid prototyping facility to test products and pricing algorithms before employing the aid of professional programmers.

Often MATLAB is used on the AIG sales desk to test drive complex securities or give indicative process for one-off deals. For example, our sales desk programmed, in a matter of hours, a full Monte Carlo simulation driven by a lognormal structure of interest-rates model that examined the pricing of a path-dependent interest rate product. And they did this without having to call in systems and trading personnel.

MATLAB prototypes of pricing models can readily be used as templates/benchmark programs to assist in validating production level programming results. MATLAB has also been interfaced to FAME's time series database (via a well designed API) and is used to develop and backtest predictive (risk taking) models and analysis to support marketing.

MATLAB products exist for both Unix workstations and PC's running Windows or Apple operating systems. Furthermore, programs written in MATLAB are portable among these platforms and can be integrated via a API (C) and/ or DDE (windows).

The two biggest drawbacks of MATLAB are 1) that it does not handle multi-dimensional arrays easily (just as Excel does not handle 3-D spreadsheets easily) and 2) that the MATLAB programming language is interpretive instead of compiled (Note: MathWorks and/or a third party plans to release a com-piler/case tool which converts MATLAB code to C programs and executable code).

What's more, MATLAB's Financial Toolbox has yet to reach the fully developed status of MATLAB's other toolboxes. These drawbacks keep MATLAB from being the application of choice for production programming. However, MATLAB will surely develop into an indispensable tool among traders, sales staff, and quants. And I expect MathWorks will eventually develop a powerful spreadsheet interface (hopefully to Excel) and will also complete development of a Database Toolbox (Sybase, Oracle, FAME). This will put an impressive amount of analytical power in the hands of traders, sales staff, and quants who have the financial sophistication (but not the programming skills) to rapidly prototype and test drive their ideas.

MATLAB At A Glance

This interactive, extensible environment boasts a core of numerical algorithms which prove extremely dependable in engineering applications. It integrates matrix computation, numerical analysis, nonlinear model design, data analysis, and presentation graphics in a self-contained framework. Matrices can be real or complex and may contain a diversity of images, polynomials, time histories, multivariate statistics, and linear systems. The company claims that MATLAB can be deployed to create a complete analytic system at a fraction of the cost of customized solutions, without requiring knowledge of such difficult programming languages as C.

The Financial Toolbox At A Glance

Applications include fixed-income pricing, yield and sensitivity analysis; cash flow evaluation and accounting; prices, yields and sensitivities for such derivative structures as collars, hedges, straddles (including Black-Scholes modeling for European options and binomial/lattice modeling for American options); portfolio analysis tools, efficient frontier determinants, Sharpe ratio computations; date functions; graphic and cash formats. And when combined with the SIMULINK graphical interface, the Toolbox can also handle Monte Carlo analysis and other non-stochastic simulations. Time series features such as fuzzy logic and neural nets can be added at additional cost.

Price: MATLAB starts at $1,695.00, SIMULINK at $1,995.

Add ons: Financial Toolbox $895, Optimization Toolbox, $595, Statistics Toolbox, $395.

Where to get it: The Math Works, Inc., 24 Prime Park Way, Natick, MA 01760-1500 Tel: 508-653-1415 Fax: 508-653-2997 E-mail: info@mathworks.com Web: http://www.mathworks.com

Kicking MATLAB's Tires

After evaluating a MATLAB demo, Kathleen M. Splaine, managing director, Risk International Inc., conducted extensive discussions with half a dozen long-time users of this software. Her conclusion: MATLAB's Financial Toolbox has the potential to become a standard in the financial industry.

Here are some users' raves that she gathered:

"Anyone who is concerned about development costs will use the MATLAB/Financial Toolbox."

"In one day I wrote 875 lines of MATLAB which equates to 5000 lines of C code. I had a functioning GUI in one day. You can't do that with C."

"It provides a friendly environment for large scale calculations like nothing else."

"I can develop on Sun at the office and continue working on my Mac at home."

"The vast client base enables users to exchange code and models and collaborate easily with financial consulting/small research firms and academics across platforms."

"The new C Compiler is a dream come true."

Strengths

• 10 times faster development time using MATLAB than C
• follows intuitive logic, makes life much easier for programming
• can start with one toolbox and add others as needed
• can use existing C programs
• models and algorithms are constantly updated by leading researchers, academics and theoreticians
• an easy to use interpretive language for non-programmers
• multi-platform (UNIX, PC and others)
• great graphics - visualization tools 2D to 5D and movie animation
• 10-plus years algorithms tested and reliable
• special application toolboxes
• powerful, flexible, friendly
• number cruncher
• reliable
• price

Weaknesses

• Database currently uses flat file format
• Interface with other programs
• Non-availability of source code

Challenges

To make MATLAB an industry standard they need to get enough people on board to develop applications, as soon as possible. It needs a seamless integration with existing products. Last, but not least, to get the most power, they need to make the source code available.

Kathleen M. Splaine is founder of Risk International Inc. which assists financial institutions with software selection. She was formerly managing director of Infinity in London and Renaissance in New York.

Three different approaches claim to help risk managers keep their data straight.

By Karen Spinner

The quest for the skills to analyze and monitor risk positions on a worldwide basis -and in real time-has become the Holy Grail for scores of multi-national banks and end-users. Many modern-day computer knights are finding the quest daunting. "Integrating company-wide data is an enormous task, and many firms underestimate it," explains Charles Wurtz, founder of Xticket Systems, which provides global securities firms with data-management software. "As a result, you hear risk managers complaining, 'If I knew just how difficult this was going to be, I never would have gotten started.'"

Underestimating the complexity and difficulty of assembling a centralized data warehouse can have such dire consequences in time and cost that firms have thrown in the towel way before the goal was achieved. Others have rushed the job or not fully completed the integration. As a result, they run the risk of making key business decisions based on incomplete reports.

Whether the user chooses a centralized data repository or a sophisticated network that can provide access to data situated in many different sites, there are avoidable pitfalls. Here follows the Seven Deadly Data Sins of integration:

1) Inadequate IT skills. "The knowledge and experience of your firm's Information Technology (IT) department will to a great extent determine how quickly and effectively you will be able to assemble the data you need to create a global 'data warehouse,'" says Andrew Aziz, a senior financial engineer at Toronto-based software vendor Algorithmics. "Unfortunately, IT departments are often so disorganized that they do not know how many data repositories their firms actually have, let alone exactly which information is lying within," Aziz argues. If this is the case, the services of an outside consultant or vendor may be necessary to do a thorough database inventory.

2) Excessive staff turnover. An important corollary to the "good IT staff" rule is the law that turnover breeds chaos. Unless your firm has a particularly disciplined IT department which emphasizes documentation of each new program and new database table, chances are the ravages of IT turnover have created a wide selection of "mystery packages" scattered throughout various departments. Explains Finn Christensen, a principal at New York-based Fusion Systems, a high-tech consultancy with an emphasis on financial institutions, "In many derivatives firms, there has been considerable pressure to bring new products to market. Thus systems will be written very quickly specifically for these new products, and before they can be integrated into a 'main' system, the guy who designed the stopgap program leaves the company. Because no one knows how the oddball program works-and no one has time to find out-this hastily designed, stand-alone system can run for years."

3) Multiple systems. Christensen explains that it is not unusual to see a bank with sixty or seventy separate systems worldwide. He notes that once the bank decides either to sell or use a new product-say, Collaterized Mortgage Obligations (CMOs)-its managers will run out and buy a system that can price and analyze the product. "These new systems usually run on different databases and different operating systems, but they very quickly become entrenched." And this leads to dependency; staffers cannot function without them. Even if some of these systems run on the same type of database, chances are that the data is formatted (see glossary) much differently.

4) Legacy systems. These systems-which are dependent on extremely outdated technology- present yet another source of hassles for any manager attempting to implement an automated, worldwide reporting scheme. Often, says Atul Jain, president of New York-based Tech Hackers, legacy systems operate via mainframe or some sort of non-relational database. "The only way to get data out of these systems," he says, "is to get the information dumped into an ASCII file."

5) Lack of common standards. One consequence of a multiplicity of systems and database platforms is the proliferation of codes and abbreviations for the same thing. For example, notes Christensen, the Swedish krona may be called "SKR" in one system and "SEK" in another. The culprit here, though, is not systems but rather a lack of common standards. With a data integration project, managers should define short codes and generic formats for currencies, counterparties, dates, etc., first, to "translate" existing data for storage in a historical database and, second, to prevent the need for translation in the future.

6) Interdepartmental feuding. Jain explains that conflicts of interest and lack of communication between departments can breed duplication of effort. He says, "Because systems development has been conducted independently by product groups, they may have already amassed considerable expertise. It is important to take advantage of this pre-existing knowledge of diverse technologies." One of the best ways of accomplishing this is to get department heads to confer and interact.

7) Assumption of superior local technology. According to Wurtz, many firms err by assuming that all local offices are playing on a level technological playing field. The solutions many managers dream up, he says, are based on the assumption that they can be implemented using rapid and efficient telecommunications or sophisticated hardware. But this high-end technology isn't always available throughout the organization. As a result, Wurtz suggests that any potential solution should be compatible with the "lowest common denominator" of technology and equipment.

1. System Interface Technology

Despite these obstacles, it is possible to assemble sufficient data from around the world to assess global risk and-in some cases-to actually do so in, yes, real time. One way to accomplish this task is the system interface technology or "feed me" approach (Chart #1).

To date this approach has gained wide acceptance. It is relatively simple: Data, in summarized form, is downloaded from local systems on a tiered basis. This information is then reformatted by some type of interface program, and it is subsequently uploaded into a centralized data warehouse.

One of the chief benefits of the "feed me" approach, according to Jain, is that the needs of risk management can be met while maintaining mission-critical legacy systems. This is important, he argues, because "It is often impossible to convert some older systems so they can operate using a standard relational database. It is usually possible, however, to get this data into a flat file, which can then be processed."

Secondly, the download approach preserves departmental autonomy and allows departments to continue using the same systems they are used to. "And," Jain explains, "it can avoid duplication of effort, which sometimes comes from overlaying 'local' systems with 'centralized' systems. Because the development of systems at most banks has been very decentralized, creating a be-all, end-all central system is sometimes counterintuitive."

In addition, the up-front investment for multi-tiered data feeds is relatively low. There are, however, some considerable drawbacks. First, this method works only for end-of-day batch processing. While for some smaller firms, this may be adequate, it is not optimal. Says Wurtz, "Multiple data feeds are better than nothing. But batch processing means that managers are reviewing reports that can be up to seventy-two hours out of date."

Furthermore, in institutions where there are many systems, this process can be quite complicated and time-consuming. It also may entail many data feeds, some of which must be modemed from place to place. If any one of these data transfers fail, the final batch reports become useless. Finally, these feeds must be constantly maintained. Says Aziz, "The quality of the IT department is critical in these cases."

2. Distributed Databases

Another method that is gaining popularity, particularly for those with a need for real time global risk management, is a distributed database with replication capabilities (Chart #2). Replication works as follows: When a trade is entered at a local site, one copy is made locally and another copy is sent to a replication server. The server stores the copy in a global database and then "replicates" the deal and distributes it to all the other local databases. This means that everyone, at all times, can access a complete, world-wide database. Once an item is "scanned," the worldwide inventory list is updated.

According to Wurtz, this sort of set-up acts as an effective inventory management system, quite similar to the bar codes used by retail outlets. It also enables you to create many copies of the same global database, which means that, should one go down, loss of data will be non-existent or minimal.

Replication is also useful for those firms which want to be able to "slice and dice" their portfolios down to a very precise level of detail. Patrick Suel, a product manager for California-based Infinity, makers of the object-oriented Montage software package, explains that while the "feed me" approach almost requires that data be "flattened" or "compressed," replication's advantage is that analysis can be conducted on a deal-by-deal basis when necessary.

If done effectively, replication also makes it possible to manage risk in real time. Says Wurtz, "When replication is working correctly, the global database reflects current inventory without being more than, say, a minute or two out of date." Of course, an efficient network is necessary for optimal efficiency.

At the same time, a distributed database with replication capabilities is very scaleable, which means it is sufficiently powerful to handle high-and increasing-trade volume. Wurtz explains, "In the equity business, which is where Xticket got its start, deal volume can be enormous even when the notional amount is by no means a staggering figure. We've found that replication is the best way available now to handle these huge volumes on a worldwide basis."

Of course, there are some drawbacks to replication, as well. First, explains Christensen, it is very easy for networks to become overloaded, delaying the creation of "replicant" trades for up to half a day! There is a problem with synchronization. He says, "If one deal is entered in Tokyo and another is entered in Stockholm, and both reside in a global database, which standard time do you use?" (Note: Wurtz says that Xticket has solved this problem by including a mechanism in the firm's system which tags all trades in the global database according to Greenwich Mean Time; deals in the local database, however, appear to users with local time stamps.)

Finally, this sort of technology does require a considerable up-front investment in technology hardware and software: the ultimate fill depending, of course, on system scale and parameters, which can only be calculated case-by-case.

3. The O.R.B. Approach

A third approach involves what are called cross-platform O.R.B.s (Object Request Brokers) (Chart #3). A very new technology, O.R.B.s allow objects-which are discrete programming units-to communicate with each other across geographies and platforms. This means that a user in, for example, London can access a program that physically resides in New York and utilize databases which may reside in other locations on machines running on different operating systems. Thus, information can be processed in real time without having to create a centralized data warehouse or converting the entire firm to a single operating system or database.

While O.R.B.s are an up-and-coming technology, there are already a number of O.R.B.s from well-regarded vendors vying for market share. These include Orbix from Dublin-based Iona, NEO (Network Enterprise Objects) from SunMicro - systems, and Powerbroker from Expersoft.

One of the most attractive features of O.R.B.s, notes Christensen, is that because they can communicate effectively across platforms, local offices can keep their favorite systems while simultaneously enjoying the benefits of worldwide integration. Further, O.R.B.s can balance computing load across an entire network and allocate the processing power of local machines to work on jobs that may have originated elsewhere. For example, if machines in the Singapore office are sitting idle while London has a huge report to run, the O.R.B.s can utilize the power of the Singapore machines, via a sophisticated network, to run London's report more quickly.

Perhaps the biggest drawback to the O.R.B. approach is that it remains an unknown quantity. While Chemical Bank is implementing Orbix on a trial basis, and it is an ill-kept industry secret that CIBC is experimenting with Powerbroker, no institution has yet to fully implement O.R.B.s on the global level. And because the technology is so new, it is very expensive.

How to Do It Right

No matter which method your firm finally decides to choose, there are a number of steps that everyone should take before embarking on the danger-fraught journey of data integration. First, get a commitment from top management. Because almost any global data- management scheme will require spending some serious money, it is important that top management supports the technology. Says Wurtz, "Generally speaking, the demand for risk management is at the board and CEO level, but it is important that senior management back up their request for this sort of reporting with a budget and a strong statement of support."

Second, establish firm-wide standards. While it may seem at first like a picayune detail, it is critical that top managers agree on a standard, global nomenclature for deal input. This nomenclature should include generic counterparty abbreviations, currency codes, dates, etc. Christensen explains that he recommends this step to clients in order to avoid the necessity of "data mapping," the confusing, arduous process of translating hundreds of symbols. In turn, Wurtz likens this step to requiring all air traffic controllers to speak English. "Yes," he says, "it may be inconvenient for some pilots to learn English, but without it, planes would be crashing every day."

Third, to avoid local "turf battles," it is important to involve departmental and regional managers in the planning process. Says Jain, "Risk management should work with the various departments to find a solution that is least disruptive for them rather than imposing a system which, from their perspective, contributes nothing to productivity."

Finally, document everything. Once a global system is in place for data integration, that system should be thoroughly documented. This will prevent the "guy-who-got-hit-by-a-bus" syndrome in which only a handful of people really know how the system works. If you follow these steps-and are blessed with a top-notch IT department-your transition to the world of global risk and data management will not be painless, but it will be smooth.

English Translations

Relational database: A collection of information stored within "tables," according to subject. The tables are joined by pieces of information, such as trade ticket number, that may appear in many tables, and are able to communicate with each other to create reports that include information from a variety of tables. Popular relational databases include those developed by Sybase, Oracle and Informix.

Schema: A guide to the tables and data elements that make up an entire database; very useful for combining data from a number of different sources. For example, a schema might state that the current foreign exchange trade table is called "FX_TRADE", and it includes the following fields: fx_date (i.e. trade date), fx_cpty (i.e. counterparty), etc.

Format: Data format refers to the order in which pieces of data, or "fields," must appear in a table or file (e.g. trade date after counterparty or trade date before counterparty) as well as what each field must consist of-how many letters, how many numbers, etc. Discrepancies in format are one of the biggest problems that crop up when transferring data from one database to another.

SQL: Sequential query language, the dialect through which the tables in a relational database can communicate. A typical SQL statement will take advantage of "joins" and select the data fields that should appear on-screen in any given report.

Distributed database: A collection of information stored in different locations that can still be accessed as though it were physically a single database. For example, some trades could reside in a database in London and some could reside in New York, but all these trades could appear on the same report. (Note: From an operations perspective, this would be considered one database.)

Flat file: An unformatted file containing raw data. Information from most relational databases can be "downloaded" into a flat file. Then this same file can then be "uploaded" into another database.