QuantLib/FinancialVisualization

Design specification on building an open source infrastructure for financial visualization. Installation instructions for the demo are available

source code is located at [1]

Why open source?

The wish - If we keep this closed source, we can make a lot of money and get a competitive advantage

The reality - Closed source implementation commit a company to make massive investments to keep a system running which duplicated functionality found elsewhere, often very badly.

Always ask, are we in the ..... business? Most finance companies are in the algorithm business and not in the GUI infrastructure/computer language/database maintainence/programming tool business.

You close it, you maintain it.

The Pieces

• QuantLib - financial analysis
• VTK - 3-d graphical output
• Python TraitsUI - controller

• Nokia 800
• Wiimote

Other traps

• Letting infrastructure drive implementation rather than the other way around.
• Making the infrastructure too abstract

Design paradigm

Start with specific needs. Find open source packages that almost fit those needs. Modify the open source packages so that they do.

Example Applications

• Visualize volatility surface in conjunction with real data to see if how close the surface matches the data. Optimization will give you the closest parameter match, but without visualization techniques, you have no idea whether the match makes sense across the entire surface.

• Sanity checks. You've calculated the solution to a derivatives pricing problem. Does this solution make sense? Are there numerical issues (i.e. noisy output, singular points).

• Qualitative descriptions - How do you characterize the behavior of the derivative price or Greeks in words?

• Presentations to non-technical audiences. - Make points to people who are non-technical specialists.

Basic framework

• model, view, controller

• model - QuantLib
• view - Mayavi2 + can possibly add 2-d plots with Chaco
• controller - Enthought Traits for parameter controller. Wiimote (?!!!) for visualization.

Scripting language (Python) for rapid application development + C++ for building blocks

Why Python - Because there is already support for scientific computing via numpy and scipy.

Toy application

Calculate basket option values for min, max, average options while varying underlying. Use monte carlo for NPV calculations.

What's needed - Lot's of duct tape

Pieces already there

Python-SWIG

Connect QuantLib with python using SWIG wrapper generator

Connect QuantLib with MayaVi2

Both are Python applications. Right now uses python for surface rendering

Pieces being developed (duct tape)

Plotspace View

Problem - mayavi2 was built for CFD and medical imaging. These have homogenous scales. But finance has hetrogenous scales. Need an API for converting "plot coordinates" to "world coordinates"

Problem - Equations take a long time to calculate. Need to put computational infrastructure to support multi-threading

Status - Minimal implementation there.

Traits controller

Problem - Need to be able to edit the parameters of the model

Status - Try to figure out how to do this

Data Frame

Problem - VTK and visualization systems were designed to handle either arrays or unstructured 3-d data (imaging and CFD background). But financial data is usually multi-dimensional time indexed data with attributes associated with columns and with the data as a whole.

Solution - Implement something like R data.frames

Status - Basic implementation there. Right now road block is implementing database joins. (Simple, just need the time to do it).

Note - The data frame unifies some of the basic tools in finance - The spreadsheet and the database

QuantLib surface interface

Problem - Need standard interface to retrieve surface and volume data from QuantLib

Solution - Implement surface interface. Example of implementation of Surface interface would be time indexed curves.

Wiimote interface

Problem - Control view more naturally than with mouse

Solution - Use wiimote - This is actually straight foward. Wiimote uses bluetooth and protocol has been reverse engineered. Hardware is cheap. Map wiimote calls to mouse actions in controlling mayavi

Impedence mismatches

Classic problem with system integration are bad joints. Need to think about deep integration issues while we are in duct tape mode.

1) How do we integrate Traits event model with QuantLib event (observer model)?

2) How do we connect QuantLib arrays with numpy arrays?

3) What do we do about econometric time series analysis?

4) How do we connect the structured objects (i.e. surfaces) within QuantLib to the outside?

Why this needs to be open source

No proprietary information. No complete application. Just lots and lots of duct tape.

Danger of proliferation of API's and implementation. You close it, you maintain it.