To Wall Street (with love), From the Military Industrial Complex
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
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
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.
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
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
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
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
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
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
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: firstname.lastname@example.org
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
"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
"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."
- 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
- Database currently uses flat file format
- Interface with other programs
- Non-availability of source code
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.
SYSTEMS: Managing The Data Integration Nightmare
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
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
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
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
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
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
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
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