In this page are listed a series of ideas for projects that we would like to develop as open source extensions of Fairmat. Realized or ongoing projects are listed here.

Whatever it is for an internship, for a thesis or for your own leisure and will to contribute.... How to begin working on these?

1) Get the required tools (depending on the project): Fairmat Academic, Visual Studio or MonoDevelop, etc.
2) Check out the available source and documentation from the github page and this website (see this page).
3) If you are interested in contributing to one of the projects listed below, want more information or want to propose your own project please contact us. Other ways to contact us are also listed here.
4) Get the code and start coding!

FpML (Financial Products Markup Language) Support

Summary: One of Fairmat goals (see our 2009 manifesto) is the lowering of every information barrier related to valuation and analysis of OTC products. The possibility of comunicating informatioon about structured products in a standard way is of drammatic importance. With Fairmat is already very easy to comunicate information about financial structures by sending our .fair models, but we would be able to do that also with the other solutions which implement the FpML standard (From  http://www.fpml.org/: FpML® (Financial products Markup Language) is the open source XML standard for electronic dealing and processing of OTC derivatives. It establishes the industry protocol for sharing information on, and dealing in, financial derivatives and structured products).

We would like to implement Import from FpML and Export to FpML capabilities in Fairmat: the standard is very big and Fairmat does not cover all the operations provided by it, for this reason we think that we can focus on supporting a subset of it.

There might be several approach to takle this project: an example sequence might be to first make a proof of concept converting fair files to fpml files and then heading to to using an API, which would need to be defined, to handle the import/export functionalities similarly a serializer/deserializer backend.

Difficulty: Medium.

Skills needed: C#.

Quantlib bindings

Summary:  is a very popular library for option pricing.  Fairmat uses quantlib for calendar processing. It would be interesting to develop a binding for more Quantlib functionalities.

The best strategy wold be to use the .NET port of quantlib called QLNET. It seems it was unmantained for a while but now is developed again.
The other option is to use the main library: Quantlib is written in C++: One option could be to use the CXXI framework  [http://tirania.org/blog/archive/2011/Dec-19.html] for generating a stub of the Quantlib classes and then write C# code for exposing functionalities to Fairmat (functions, pricing systems, etc...).

In any case, the result of this project would be a fully updated library for .net taking advantage of the work behind Quantalib.

Difficulty: Easy.

Skills needed: C# and C++.

Integration with scientific programming languages like Matlab/Octave, R and others.

Summary: The common way to add new functionality to Fairmat is through the plug-in system. But there cases in which the functionality is already available in other platforms (i.e. Legacy code). We want to simplify the effort of reusing code written in other languages within Fairmat scripts.
This can be done at many levels (in the worst case a plug-in can be written for wrapping the existing functionality). Differently, the goal of this project is to write a plug-in which can be able to re-use generic piece of codes written in the external language.
To give an idea we can focus on the following use case: we have a complicated function/payoff written in an external language (i.e. R)and we want to make it available to Fairmat users.

A rough series of steps in order to accomplish this task might be:

1. Create a subsystem which is able to run script instances of the external language.

2. Define a way to pass data from/to Fairmat to/from the external script.

3. Integrate with the API in order to allow Fairmat to see an external script as a Fairmat UI object (i.e. an external function script  must be seen as a user-defined or plug-in defined function).

Difficulty: Hard.

Skills needed: C#, C, interoperability, knownledge of the target language (Matlab/Octave, R...).

Integration with free market data providers

Summary: Fairmat is integrated with Bloomberg and several custom enterprise data provider (in line with enterprise customer needs). There are plans  to integrate Fairmat to other commercial market data providers, but aside those data providers, there are several providers which do not charge for all or part of their data. We would like to give Fairmat Academic users the possibility of connection to those marker data providers. For example:

- http://www.mercatoelettrico.org electricity prices and demand for the Italian market, delivered by FTP.
- Financial and physical Iberian electricity market (http://www.omip.pt/ and  http://www.mibel.com/).

but there are many others.

In Fairmat market data provider integration is performed trough the means of implementing a given interface, and by handling a subset of the possible requests made by the software.

During 2013, several free market providers have been implemented using a two levels architecture: the first level provides an API to access the service, the second level provides the required interfaces for use with Fairmat. The result of 2013 efforts can be seen here.

Difficulty: Easy.

Skills needed: C# and JSON/XML/CSV Processing.

New theoretical models for the underlying stochastic processes

Summary: Fairmat has been designed to separate financial contracts specification for the numerical implementation of pricing and assessment.  and for this reason we continue the integration of several competing models for each asset classes. Check out https://github.com/fairmat  for the current available models.  It’s usually not trivial to implement a new theoretical model and different strategy can be used. Usually there is already available a prototype or an implementation in a different language, hence usually the porting of a new model is subject to the following steps:

1. Porting in C#, using the Fairmat Math Libraries (see http://www.fairmat.com/assets/General/Numerical-API-Introduction.pdf), the theoretical model.
2. Testing and comparing results with the original implementation.
3. Integrate within the Fairmat Work-flow.

This is a list of models we plan to integrate, but we are open to the implementation of any model:

Inflation Market Models (IMMs) calibration

IMM is a specialization of the Jarrow-Yildirim model (see https://online.tugraz.at/tug_online/voe_main2.getVollText?pDocumentNr=218523&pCurrPk=60659).
The project will consist in task of providing  new calibration capabilities for the current implementation of the Jarrow-Yildirim model.

SABR

Theoretical model for modelling the volatility smile effect (See http://en.wikipedia.org/wiki/SABR_volatility_model).
For what concerns this model, we have a prototype in Matlab  hence we are seeking to port the code to C#.

Vanna-Volga

Model for pricing Forex exchange derivatives (see http://en.wikipedia.org/wiki/Vanna%E2%80%93Volga_pricing).

Cheyette Model

Alternative Short-rate interest model (see http://econstor.eu/bitstream/10419/43669/1/640785646.pdf).

Difficulty: Medium/Hard.

Skills needed: C#, Quantitative Finance, Operation Research, Numerical Calculus, Original language of the model.

Accelerated Simulation Techniques - Functional Quantization

We would like to include additional simulation back-end to improve the rate of convergente of Monte-Carlo simulation. One possible method is functional quantization (see  http://www.sciencedirect.com/science/article/pii/S0022123602000101 ) 

Difficulty: Hard.

Skills needed: Math, Numerical Calculus, Matlab/C#.

 PDE Option Pricing Back-end

Currently Fairmat have three different option pricing back-ends: Closed-Forms, Lattice and Simulation.   Within some classes of financial products there are advantages (in terms of computational speed / accuracy) in using PDEs solutions.

The project is very complex and may be executed in steps:

1)      Porting of some existing finite difference algorithms (Finite Differences / Radial Basis Functions)  in C#.

2)      Build a benchmark test case (for example a Forex option with an Arbitrary Barrier).

3)      Integration with the Farimat Back-end Framework.

Professor Alonso Pena is available to mentor a student who wants to start working on this subject.

Difficulty: Hard.

Skills needed: C#, Quantitative Finance, Numerical Calculus.

Stochastic processes simulation OpenCL back-end (continuation)

Summary: Expansion of the current implementation of this alternative simulation back-end for our stochastic processes simulator.
The implementation, currently, supports only Markov Based processes and allows the plugin to define the alpha and beta parts of the markov update, the data required and a post simulation operation over the data. Then during simulation an OpenCL kernel will be built from all these and the data uploaded to the GPU for the simulation.
The system is currently in an experimental status as some elements are still needed to make it usable, including:

1. Generation of pseudorandom casual numbers directly on the gpu (see this).

2. Optimization of the handling of data, in order to reduce the copy operations and transfer of data to the gpu.

3.  Handling more complex simulation styles like full simulations.

4. Handling problems arising from the nature of video cards: e.g. ram, core amount and feature set limitations.

Difficulty: Medium/Hard.

Skills needed: C#, OpenCL and knownledge of parallel algorithm programming.

OS X Native GUI

Summary: Currently our modeling GUI is written using the Windows.Forms (WF) toolkit, and is executed on OSX through the Windows.Forms mono project implementation.  The main problem of this approach is that WF implementation is bases on X11 and hence it is not well glued into the OSX user interface. We would like to porting a sub set of our modeling tools features to OSX using some native framework (either using Mono.Mac or the Mono/XWT frameworks). This would need to add the required interfaces in a special project done for this and defining also the API required to interact with the rest of the framework.

Difficulty: Hard.

Skills needed: Objective C, C# and knownledge of the OSX API (e.g. COCOA).