Loading...
Frequently Asked Questions
Home / FAQs

General

Open Source Risk Engine (ORE) ia an Open Source Software project, designed for contemporary pricing and risk analytics of traded financial products. It aims at establishing a transparent peer-reviewed framework that can serve as benchmarking, validation, training, teaching reference, as well as extensible foundation for in-house and vendor solutions. ORE is provided under the Modified BSD license.

QuantLib is the open source library for quantitative finance, see www.quantlib.org. ORE uses QuantLib heavily.

Yes, a user guide is available here for download on opensourcerisk.org.

Not yet, please feel free to contribute your experience with ORE in the form of a tutorial.

Not yet, but we are working on an ORE book for that purpose.

ORE is written in C++. ORE consists of three libraries (QuantExt, OREData and OREAnalytics) and a command line application that demonstrates how ORE’s functionality can be used. QuantExt uses C++98 in line with QuantLib and to facilitate migrating code from QuantExt to QuantLib over time. The Data and Analytics libraries use C++11 for convenience.

That’s a good idea. We will add to opensourcerisk.org as we become aware of institutions using it (and when the institutions agree to publishing this).

Yes, the ORE framework is used in production. We have started a case studies page on opensourcerisk.org to list cases we are aware of and that we are allowed to post.

We have created a forum page on opensourcerisk.org to enable exchange between users and developers from day one. You can also subscribe there to get notified when there are updates in the forum, or just go there and browse the forum entries.

Certainly, we would encourage people to talk about ORE publicly and help promoting the idea. Members of the project sponsor are doing this already and will continue to do so.

It is open source, so your IT can scan it for any malware, and your model validation can check down to the last line of code. Whether it is secure in the sense of ‘correct implementation of methods’ – this is at least partially ensured by the unit test suites in ORE and should be further confirmed over time by peer review. In the end, you will have to judge, and fortunately this is possible, because it isn’t a black box but open source.

Good point. ORE has not bee designed from scratch at the drawing board. OREs architecture grew out of years of industry experience the Quaternion team has as users, developers and consultants. We are confident that the current software design is robust. However the great thing about Open Source is “using the wisdom of crowds” to get feedback and improve on the original. Hence we can not exclude that the “API” will keep changing over the first releases. Please get involved and if necessary help us make it converge quickly!

It is a culmination of years of experience (approximately ~10 person years joint coding effort – real blood, sweat and tears!) and the desire to ‘leave something behind’ that is tangible and hopefully useful. We think that ORE will further strengthen Quaternion’s position as a global risk analytics provider. Finally, we also offer our consulting and development services around ORE itself, as well as our licensed extensions of ORE.

ORE is an application that provides a Monte Carlo simulation framework for contemporary risk analytics and value adjustments, simple interfaces (for trade data, market data and system configuration), simple launchers and result visualisation (with Jupyter, Excel, LibreOffice), unit tests and various examples. The first release covers ‘plain vanilla’ interest rate and foreign exchange derivatives.

ORE is unique in that that it is based on the wealth of methods provided by QuantLib, a peer reviewed pricing library that has evolved over 15 years. We try to avoid reinventing the wheel where possible. ORE is written in C++ with both model validation and production environemts in mind. ORE comes with a user guide, tests and examples, and the sponsor is committed to grow ORE quickly into Inflation, Credit, Equity and Commodity space.

We are convinced that ORE can be adapted and integrated by experienced professionals. Of course, Quaternion can assist and are able to accelerate implementation and adaptation timelines.


Getting Started

Open Source Risk Engine’s code is hosted on github. You can either fetch the repository using git from https://github.com/OpenSourceRisk/Engine or download a release archive from https://github.com/OpenSourceRiskEngine/releases

Most likely yes – follow the instructions in “Where can I get it?” and fetch the latest ORE release. It comes with ORE executables for several platforms including Windows, Linux and Mac OS X.

ORE works on Windows, Linux, Mac OS X and possibly other Unix flavours (we have tested it with the former three). The ORE releases come with executables for these platforms so that you do not need to go through the building of ORE in order to get started. If you want to build ORE from sources, then the user guide’s section 3 provides the step-by-step guidance and tells you what is required.

Please check out our user guide. This explains in section 3 how ORE is installed on Windows and Unix (Mac/Linux).

Please check out our user guide. This explains in section 3 how ORE is installed on Windows and Unix (Mac/Linux).

To get started you do not need to have any programming knowledge. Head to our download page at https://github.com/OpenSourceRisk/Engine/releases and fetch the latest release archive. It contains the ORE executable for several platforms, ready to run. ORE’s user guide explains the first steps and provides a number of examples that illustrate how ORE can be used. Modify these examples to create your own.

Open Source Risk Engine (ORE) expects market data to be provided in a specific format as explained in the user guide. Any provider’s market data needs to be mapped to this format. Alternatively, you can extend ORE by adding a tailored market data loader which can absorb the provider’s data directly and load it into ORE.

Portfolio data is provided by the user. ORE expects a specific XML file representation of the trade data as explained in the user guide. ORE comes with its own XML trade data loader that directly maps to ORE’s internal representation of supported product types. In the ‘Examples’ section of the release, you will find various examples of such trade XML files covering all products that are currently handled in ORE.


Help

If you need help, consult with these FAQs first, then browse/search the user forum discussions and feel free to ask questions in the user forum. If you have found an issue you can log this in our issue tracker at https://github.com/OpenSourceRisk/Engine/issues.

You can log issues and bugs at https://github.com/OpenSourceRisk/Engine/issues. Moreover you can post any issue you find in the user forum at opensourcerisk.org.

Make sure “ore_examples_helper.py” in the Examples folder is referring to the right locations for ore.exe. This can be achieved by moving the executable into the “bin” directory as explained in the user guide. Alternativerly, one can edit “ore_examples_helper.py” to refer to the actual location of the executable.


Development

We appreciate any feedback you post in the user forum at openriskengine.org. If you want to contribute code changes and extensions, then please fork the ORE repository at https://github.com/OpenSourceRisk/Engine and start coding. Changes and additions can then be provided in the form of pull requests at https://github.com/OpenSourceRisk/Engine/pulls.

ORE is based on QuantLib and uses QuantLib style especially in its “QuantExt” library. Adding different simulation models starts there so that familiarity with QuantLib is an advantage. Further amendments are then also required in the data and analytics libraries closer to the application layer. The design of the latter two libraries is less QuantLib-style.

Yes, you can. However, our style is to (re-)write additional pricers in QuantLib style and place them in ORE’s QuantExt library.

Absolutely. ORE will initially provide one market simulation modelling approach per risk factor class, but we are very open to adding more alternatives. This is what the community needs for benchmarking in our opinion. We would suggest that you start with exploring the methodology (see user guide appendix) and then continue checking how this is implemented in the QuantExt, OREData and OREAnalytics libraries.

You can integrate ORE analytics in several ways: One is to map your market and trade data to the input file formats we have defined and that can be readily loaded into ORE; this means a classic interface/adapter development task that is typically moderate compared to the effort of getting and cleansing the data from the source systems. Thereafter you can run the ORE command line application for example in a series of batches to produce the desired analytics results. The resulting reports can be picked up from the file system, parsed and imported into the target system. Another approach would be tighter integration that uses ORE’s C++ API directly without using the ORE file formats or the command line application that comes with the ORE release.

The only element in QuantLib 1.8 that caused us some headache is the observer pattern. This works fine for day-one pricing, sensitivity calculation and stress testing, but causes performance issues when one updates thousands of market points repeatedly under thousands of Monte Carlo scenarios. We found several ways around it, two of which are implemented in ORE.  Search for key word ‘observationModel’ in the user guide. We would be interested in a forum discussion about these solutions.

Clean design, avoiding duplication, a comprehensive test suite, variety of example and demo cases are measures to continuously assure the quality of release. Peer review of the first release will further harden ORE. When we extend ORE, we will make sure that corresponding test cases are added to the test suites. Any contributions submitted by the community are carefully reviewed and may be discussed in the forum before being integrated into ORE. Also refer to the ORE contribution and governance page at openriskengine.org.


Features

ORE does not cover the entire range of QuantLib instruments. For example, Inflation Swaps and Credit Default Swaps are in QuantLib though not accessible via ORE yet. That will change with the next releases (see the roadmap).

Yes, all three libraries in ORE come with a unit test suite and documentation of the test cases.

In the first release basis spreads are deterministic, i.e. ORE simulates only one yield curve per currency. But ORE is open, and you are free to add simulation models to ORE that do simulate stochastic tenor or cross currency basis.

QuantLib can of course, but configurable sensitivity analysis and stress testing is not integrated into ORE yet. However, this is an important extension on the roadmap.

A basic version of MVA and dynamic initial margin (DIM) calculation is part of the release. KVA will probably be added once we have an implementation of SA-CCR.

Out of the box it runs on a single core only. However, the design of the central processing “loop” that produces the NPV cube was done with parallelisation in mind.

ORE is an open source project driven by the community. There is an outline roadmap but the best way to make a desired feature appear quickly is to contribute to its development.

The methods are correctly implemented to the best of our knowledge, and integrity/consistency is checked by the unit test suites in ORE. Moreover, the point of releasing ORE as open source is to encourage deep peer review to further harden the analytics. The question whether the ‘risk metrics are correct’ (adequate?) depends very much on the portfolio and risk management context, impossible to answer generally. In any case, we would like to make ORE grow and offer alternative approaches so that ORE analytics offering can be tailored to as many risk magement use cases as possible.

Yes, normal and shifted lognormal volatilities are fully supported on the basis of the QuantLib framework.

Yes there is, you can find it on opensourcerisk.org. The roadmap outlines a future direction for ORE. Quaternion remains committed to showcasing the releases and sponsoring ORE’s developments. However, the order in which features are added is not yet fixed and depends, to a certain extent, on the feedback from the community after the first release.

ORE can ‘absorb’ most of the market data relevant for pricing IR/FX products and more, in anticipation of subsequent releases. For example, market data comprises yield curve data (Deposits, FRAs, Futures, Swaps, Tenor Basis Spreads, Cross Currency Basis Spreads), FX spot rates, FX forward rates, Cap/Floor and Swaption volatilities, as well as CDS data to build default curves, etc.  See the user guide for details.

The first release of ORE comes with a Cross Currency Linear Gauss Markov model that has one factor per currency and one factor per currency pair, i.e. 2*n-1 factors to simulate an n-currency market. The interest rate processes are normal, FX processes log-normal, tenor and cross currency basis is deterministic. The model is calibrated to yield curves in all currencies, Swaptions and FX options.

The product range of the first release is Interest Rate Swaps, Cross Currency Swaps, FX Forwards, Caps/Floors, Swaptions and FX Options.

We are planning a release frequency of three to six (closer to three) months for the first while, at least until we have covered the basic risk factor classes (IR, FX, Credit, Inflation, Equity, Commodity), related asset classes and analytics scope (Market Risk, P&L, SA-CCR, KVA), see roadmap at openriskengine.org. Thereafter it depends on the community’s interest/feedback and contributions. In any case we plan to provide ORE releases for each QuantLib release which tend to appear on average every six months.

Credit simulation is on the roadmap, and we expect to add this with an early release, second or third.

This certainly requires credit simulation which is indeed on the roadmap. With a conventional intensity (hazard rate) model that we have in mind first (Gaussian, Cox Ingersoll Ross, or Black Karasinski), this will provide some limited capability of wrong way risk analysis- limited, since such intensity models create only very limited default correlation. There are jumpy alternatives such as Peng Kou, but we do not see that as an early extension of ORE so far. We definitley welcome discussion on this subject in the forum.

Currently the focus is on pricing,  exposure simulation and XVA. Extension into these other areas you mention is indeed crucial to make ORE a comprehensive risk analytics platform. Therefore these areas are on our indicative roadmap.


Interfaces

The ORE release comes with a command line application and a few ‘launchers’ that kick off ORE processes and display results. These include Excel and LibreOffice spread sheets, as well as a Jupyter notebook demo. This does not include ‘deep’ integration into Excel yet where you can manipulate all ORE objects individually. However, this is a potential route for extensions, and using ORE’s API you are free to have a go at it.

Not out of the box. However, ORE comes with a market data loader that expects a certain market data file format as described in the user guide. To link into any specific data provider, you can either map the provider’s data to ORE’s market data input file format or extend ORE and add a custom market data loader that processes the provider’s input directly.

No, currently there is the C++ API and the application. However, like QuantLib one could export the ORE libraries using SWIG into Python.

ORE is open source and fully transparent, all C++ objects (e.g. representing trade,  market and configuration data) can be created and manipulated ‘directly’ within a C++ program without making use of ORE’s file-based interfaces. Likewise, all analytics can be called by a C++ program.

Not out of the box. However, ORE comes with its own XML trade data loader that directly maps to ORE’s internal representation of supported  product types (see user guide). To handle trade data that comes in FpML format, you could either map this to ORE’s xml format or develop a custom trade data loader that processes FpML directly.

We can imagine that users will also built ORE into cloud based commercial applications. The license explicitly permits that.


Relation to QuantLib

Not at all! ORE builds on the work of QuantLib. And we grateful for the enormous community effort and experience that went into QuantLib which has enabled ORE.

We have not built on QuantLibAdjoint yet. However, this is another potential route of extending ORE, as well as alternative ways for fast sensitivity calculation.

We have chosen to use QuantExt for two practical reasons. The first one is flexibility: we want to be able to add QuantLib extensions when required for ORE without being tied to the QuantLib release cycle and process of PR reviews. The second reason is that the extensions may be a bit specific around market simulation models so that it is not clear whether QuantLib is the right place. In any case, we are open to establish a process of migrating QuantExt content over time into QuantLib where it makes sense. We cannot even avoid that volunteers will copy code across (it is open source!). We will discuss that on the QuantLib mailing list.