Design specification on building an open source infrastructure for financial visualization. Installation instructions for the demo are available
source code is located at 
Why open source?[edit | edit 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[edit | edit source]
- QuantLib - financial analysis
- VTK - 3-d graphical output
- Python TraitsUI - controller
- Nokia 800
Other traps[edit | edit source]
- Letting infrastructure drive implementation rather than the other way around.
- Making the infrastructure too abstract
Design paradigm[edit | edit source]
Start with specific needs. Find open source packages that almost fit those needs. Modify the open source packages so that they do.
Example Applications[edit | edit source]
- 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[edit | edit source]
- 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[edit | edit source]
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[edit | edit source]
Pieces already there[edit | edit source]
Python-SWIG[edit | edit source]
Connect QuantLib with python using SWIG wrapper generator
Connect QuantLib with MayaVi2[edit | edit source]
Both are Python applications. Right now uses python for surface rendering
Pieces being developed (duct tape)[edit | edit source]
Plotspace View[edit | edit source]
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[edit | edit source]
Problem - Need to be able to edit the parameters of the model
Status - Try to figure out how to do this
Data Frame[edit | edit source]
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[edit | edit source]
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[edit | edit source]
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[edit | edit source]
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[edit | edit 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.