OpenGamma Platform

There's never a dearth of drinking opportunities in London in December, but we really can't let that stop us from offering up one more to make sure your liver is well and truly prepared for the obligatory January detox! Join us for the last ... [More] OpenGamma OpenPub of the year at The Audley in Mayfair (43 Mount Street, London W1K 2RX) on Thursday 6th December from 6 pm onwards. Some of you may know this already, but The Audley is actually where Jim, Elaine and I had our very first planning meetings to define what was to become OpenGamma. When we all worked together at Vega, we worked in the only non-red building on Mount Street, and were going to the Audley before Mount Street became "the new Bond Street". When we started planning this little endeavor, we couldn't think of a better place to meet up! Although our London meetups usually take place at our offices in Southwark, it seemed apt that we go 'back to our roots' to wrap up the year with you all in the West End (easily accessible by Central or Jubilee lines) for those of you who can't brave going sarf of the river. We'll be sharing some of the exciting plans we have for 2013, and showcasing the new 1.2 release of the OpenGamma Platform. Join us for a pint (or two), meet the team, ask any questions you may have, or simply try to overcome the dark and drizzly London December atmosphere! As always, the drinks are on us! Simply register on Eventbrite so that we have an idea of who's coming, and how big an area to reserve. [Less]

CME is launching a new futures contract with the swap as underlying, called Deliverable Interest Rate Swap Futures, in December. Several other swap-related futures have been launched in the past on CME and Liffe without much success. The reason for ... [More] the previous lack of success has probably been the instrument description and settlement method. The futures were based on a fixed rate (4% for CME and 6% for Liffe) and the futures were settled in cash, with an internal rate of return cash-settle like formula for CME and a zero-curve cash-settle like formula for Liffe. The new proposal by CME differs from the previous contracts in its description and settlement features. The main difference is that the new contract is settled physically into an OTC swap cleared by the CME. After settlement, there will be no difference between a standard OTC swap and the one resulting from the future's settlement. Before settlement, the trades will be margined and netted like any other futures contract. The reference rate for the swaps will be selected for each contract at the time of the first trade. The rates will be in line with the then-market rather than an artificially selected rate (such as previous offers). On that front, the CBOT and Eurex should perhaps think about reviewing the reference rates for the bond futures. The current reference rates (6% for most of the contracts), well above the current rate level, render the basket delivery feature meaningless; only the shortest maturity can really be the cheapest-to-deliver. Liffe has changed the Gilt futures reference rates to 4% or 3% last year. Like any other futures contract, the Deliverable Interest Rate Swap Futures will be subject to a daily margining process. And like any other futures contract, these futures are not forwards: a so-called convexity adjustment is required for the pricing. At OpenGamma we've analysed the new contract and published the results of our analysis in a Quantitative Research paper in September, including a pricing formula in Gaussian HJM models and some numerical examples. Obviously to obtain the numerical results for the note, we implemented the instruments and the pricing method in our OG-Analytics library (look for class names starting with DeliverableSwapFutures, available in the upcoming 1.2 release). Both the research note and the code are available open source, as always. The Pricing Formula: Summary of the Results The pricing formula is similar to the one for bond futures, although simpler, as there is no delivery option to consider. For that reason, the formula is valid for any multi-factor Gaussian HJM model, and not only for the separable one-factor ones. The futures behave roughly like swaps except for the discounting from settlement date. For futures with very short time to settlement the impact is small. For longer time to settlement, the impact can be large. For a 9 months to settlement future on a two-year swap, the difference in PV01 between the underlying swap and the future can be up to 50%. We've also looked at hedging swaps with futures. As an example, we found that the best hedge for a 100m 30-year receiver swap starting six months forward is 987 30-year futures contracts and a 103.7m six months receiver OIS. Download Deliverable Interest Rate Swap Futures: Pricing in Gaussian HJM Model (PDF) Further reading: Risk magazine has written on CME and the new swap futures extensively in the past month. [Less]

OpenGamma has just released a standalone Java library, ElSql (pronounced else-q-el). It provides a simple tool for managing SQL external to the application with a touch of DSL goodness. It is released under the Apache License v2 and intended for use ... [More] with Spring SqlParameterSource. ElSql - Managing SQL in Java OpenGamma is an open source company, and as such we occasionally provide additional tools and libraries of general use to the Java developer community. Previously, we have released RouteMap, a JavaScript library for mapping URLs to methods and Fudge, a Java library for binary messaging. In this case, it's a Java library for managing SQL. Managing SQL in Java can sometimes feel like a solved, or irrelevant, problem. The "cool" applications are all using NoSQL and avoiding SQL altogether (and facing different issues as a result). But, there is no doubt that a large body of applications still want and need the longevity and strengths of relational DBs. The need to interact between Java and a relational SQL database has driven developers to create many solutions. The most commonly used include JPA, Hibernate, Spring templates and raw JDBC. Chief amongst the interesting ones are the Object Relational Mappers. These try to bridge the difference between two models - object-based and set-based. In doing so, most end up adding in an additional complex abstraction. The mismatch between the two worlds has most famously been described as the Vietnam of Computer Science. At OpenGamma, we found that for most cases, the ORM added more complexity than it took away. As such, we chose to use Spring's JdbcTemplate to make calls using real SQL. SQL is a powerful language and it really needs to be used directly to get the most out of a relational database. But there is then the problem of managing the SQL, especially as we are a platform capable of running on multiple underlying databases. There are three basic approaches to consider: concatenate strings - "SELECT foo " + "FROM bar " + "WHERE ..." use a fluent API library - methods like select("foo").from("bar").where(..) read SQL from an external file, such as a properties file Externalizing SQL has key benefits for the administrators (DBAs) whose primary language is SQL, not Java. Having SQL in a form close to SQL allows them to understand what each query is doing and suggest changes more easily if necessary. Storing the SQL in strings, or fluent libraries, locks the SQL away from the DBAs making it harder to have discussions and more difficult to change. Thus, the ElSql library is an implementation providing support for externalizing SQL from the application. It is intended to work with Spring, especially theSqlParameterSource. Abstracting common problems in querying a database - DSL tags to the rescue But ElSql does just a little bit more than allow you to load SQL files from the class path. It also provides a small set of DSL tags that abstract some common problems in querying a database. The key problem areas it tackles are: SQL LIKE vs = for wildcards dynamic construction of WHERE/AND clauses where only some things are being searched for paging of results Here is an example elsql file: -- an example comment @NAME(SelectBlogs) @PAGING(:paging_offset,:paging_fetch) SELECT @INCLUDE(CommonFields) FROM blogs WHERE id = :id @AND(:date) date > :date @AND(:active) active = :active ORDER BY title, author @NAME(CommonFields) title, author, content The idea is to be a simple DSL that adds just enough tags to solve the most common problems, not all problems. Note that all tags apart from @NAME are optional, so it can be used for straight SQL. The file is structured into named blocks using the @NAME tag and significant whitespace indentation. The application, when it is ready to use some SQL, will load the named block and pass it, together with the Spring parameter structure, to the Spring JdbcTemplate. As well as supporting the limited set of tags, there is also the ability to specify the type of database being used. A plugin configuration class allows the generated SQL to differ slightly by database. For example, paging on SQL server needs a different mechanism to that on Postgres, or indeed older MySql versions. Thus, the @PAGING tag will wrap the block it refers to (significant whitespace indentation) in whatever the most appropriate paging technique is for the database, using the pageing_offset and paging_fetch variables passed in from the caller to choose the required page. However, at OpenGamma we knew that this minor amount of control per database wouldn't necessarily be enough for our needs, where we might want to truly customize the SQL per database. As such, when an elsql file is loaded, the library also checks for an override file for the configured database type. Any named block in the override file overrides the named block with the same name in the standard file. Thus, we can (and do) have dedicated SQL for the more unusual databases, yet re-use as much as we can via the tags. The final tag in the example is @AND. This only includes the block it refers to if the variable specified is present. So, if the parameters passed by the caller do not contain "date", then the whole date AND block will not be included. These three problems - wildcards, WHERE/AND and paging - were the three big issues we faced when building SQL dynamically. By abstracting them out into simple tags along with the SQL itself, we greatly simplified the platform. And by extracting the SQL from the application we now have a great file we can use to talk to DBAs. Summary ElSql is a library that allows SQL to be stored and managed external to the Java application. In addition it provides a deliberately limited DSL that can optionally be used within the external SQL to support some of the most common problems in writing cross-platform database code. See the project page on GitHub for more details and to fork it. Or download from maven com.opengamma/elsql. Let us know if you find it useful! [Less]

The first OpenGamma OpenPub in NYC was a smash hit - thanks to everyone who came along. We very much enjoyed meeting all of you and getting to know the New York fintech community. We'll be spending some time in the city over the next few weeks ... [More] , and so we decided to organize another OpenPub for those of you who missed the first one (or enjoyed it so much you'd like to join us again, or enjoyed it so much you don't remember the last one). Join us for a pint (or two) on Thursday 18th October from 6 pm onwards at The Wheeltapper (Fitzpatrick Grand Central, 141 E 44th St - we'll be outside in the heated and covered patio area; just keep going out back until you find us). If you work in finance, technology, or financial technology, we'd love to meet you. As always, beer's on us! While we've decided to go for a British theme where possible for our OpenPub nights (given our London roots), we've got a lot of fond (and hazy) memories of the Tapper. We also wanted to show all of our Midtown fans (or those of you who commute in or out of Grand Central) some love this time! So the Tapper, with its extensive variety of Irish beers on tap, it is! We'll be sharing some of the exciting plans we have for the OpenGamma Platform and the community at large. Come along to meet the team, meet other users, and ask any questions you may have! Simply register on Eventbrite so that we have an idea of who's coming (and how big an area to reserve). [Less]

As people have probably expected, the last few months have been pretty hectic here at OpenGamma Headquarters after the close of our Series C round of investment. First, I’d like everyone to welcome Hugh Stewart to the OpenGamma team as our new ... [More] global Head of Sales. Hugh brings a phenomenal background in front office and risk technology sales, having previously worked at Algorithmics, SunGard, GoldenSource, Misys, SmartStream, QuIC (acquired by Markit), and a number of risk consultancies. He’s only been on board for a couple of weeks, but he’s going to be at next week’s OpenPub in NYC, so if you’re in New York and fancy sharing a pint with him come on by! In addition, those of you who know me know that I’ve been clinging on to the dual-barrelled title of Chief Executive Officer and Chief Techology Officer. However, as the company’s grown, and I no longer work day-to-day on the technology direction of the company, this hasn’t really made a lot of sense. As such, I’ve promoted Jim Moores, who’s been previously our Head of Platform Development, to be OpenGamma’s new Chief Technology Officer. Jim’s been effectively our CTO for a while now, and will continue to guide the day-to-day technology strategy and development across all our lines of development. At the same time, I’ve promoted Elaine McLeod, previously our Head of Quantitative Development, to be OpenGamma’s Chief Quantitative Officer. Elaine has, since the company was founded, been instrumental in setting our quantitative direction and organizing both our research-oriented quantitative analysts and our quantitative developers. She will continue to be responsible for both day-to-day and strategic quantitative direction as the company continues to grow. I’ll still be involved in technology (as anybody who knows me can testify, I’ll be an engineer until my last breath), and will continue to focus on the product strategy and vision, but I can’t think of anyone better placed (including myself) to act as CTO and CQO than Jim and Elaine! [Less]

We've been baking our new web UI for a number of months now, and while we're not quite ready to roll it out just yet, we would like to share a few screenshots to give you an idea of what's coming. The following are a combination of Photoshop mockups ... [More] and live working implementations from various points over the last few months (mockups are marked as such). (The images open in a lightbox when clicked. If you want to see the full-size originals, particularly if you are using a smaller screen, we recommend opening the images in a new tab instead.) Here's our WebGL real-time surface gadget. It supports drag-rotation, zooming, slicing, smile projection and log/linear plots, with a range of other features being planned. Older browsers degrade to a basic Canvas implementation or a matrix. This screenshot shows off a number of new features. You can drag and drop gadgets into different panels in the UI. (These panels are also resizable.) Aggregate your portfolio with our multilevel portfolio aggregation menu. Flexible tabs implementation. If you feel the need to open a lot of gadgets in any panel, the inactive ones will shrink to a minimum size before exposing an overflow panel. Opening gadgets in new windows. All gadgets (surface, timeseries, curve etc..) are independent of any particular part of the UI. They can exist in the various GUI panels, inline, or be torn out into separate browser windows. Cell Selection. All grid data supports an Excel-type selection model. We are implementing copy and paste and have plans for a copy with functions feature so you can paste to OpenGamma's Excel client and have your data continue to tick. Our custom grid supports fixed columns on the left, and a fixed column header at the top. Column sets display the same analytics computed using different settings, viewed side by side at the same time. partial mockup The multi-tier market data selection allows snapshots to fill in gaps in live data. You can use multiple live data sources, and historical time series as snapshots. Valuation time (global), and portfolio version and correction times. The later two cascade unless overridden. partial mockup Inline gadgets. This is an example of a data gadget loaded inline. The curve gadget that supports zooming/panning and multiple curves. A multi-select menu in each gadget that allows you to choose from multiple data views per panel. mockup This is an older mockup. It shows some features we have yet to implement, such as the histogram gadget (1) and column hiding (2). mockup Another older mockup showing the column configuration panel. Other upcoming GUI features We have a few other features lined up that aren't yet included in the screenshots above, but that you can expect to see soon: Fully stateful URLs that can be passed to other users Preset layouts and custom resize preferences saved locally Contextual operations like delete and reorder Column resizing Keyboard shortcuts Screenshots can only tell you so much of course, and we're actively working on getting proper screencasts/videos online for you to view. If you've got any questions or would like to know more about any of the new features mentioned here, please let us know in the comments below. [Less]

In my last post I wrote about autogenerating JNI wrappers to native (typically Fortran-based) maths libraries. This post is an addendum to the series and it addresses the problem of capturing error/runtime logging produced by native code. In many ... [More] Fortran libraries some sort of logging is implemented so that messages about errors or state can be recorded for later inspection, or to act as a trace if something goes wrong. In Java, logging is also an important tool; at OpenGamma we use the slf4j interface to provide various levels of logging. As we started using the native wrappers more it became apparent that we really wanted the Fortran logs to go to the same slf4j stream as the Java logs such that we have a universal logger. Practically this means taking some of the techniques from the previous articles (here, here and here) and combining them with some slightly more involved JNI. How we do it To motivate the discussion, let's assume there is some Fortran routine called f_log that, when truncated, looks like: subroutine f_log(log_message) character*(*):: log_message !> Code that implements logging by writing "log_message" to some output stream goes here end subroutine f_log As we saw last time, we can override symbols in the native shared library by creating our own routine with the same prototype and putting it higher up in the link chain so it is used in preference to the shared library version. Normally we'd do something along the lines of: #define F_LOG_F77 F77_FUNC(f_log,F_LOG) #ifdef __cplusplus extern "C" #endif void F_LOG_F77(char * log_message) { // code to process message } However, we now have a problem. The char * log_message is of unknown length and not necessarily NUL terminated. This sort of information is not needed in Fortran because the dope vector associated with the character array can be queried by invoking the Fortran intrinsic len() function on the array and the length can be ascertained. In C, this is not possible as the dope vector struct is (usually) dereferenced to give the character pointer only. To get around this problem we have to buffer the call to our C function through a Fortran routine that will call len() on the character array. From this buffering routine we can then make a call to an appropriately designed C routine, as we now have enough information to do something useful with the message. In our example we'd do something like: subroutine f_log(log_message) character*(*):: log_message integer:: length length = len(log_message) f_log_buffered(log_message, length) end subroutine f_log A corresponding C routine to handle the message - now we know the amount of data - would look something like: #define F_LOG_BUFFERED_F77 F77_FUNC(f_log_buffered,F_LOG_BUFFERED) #ifdef __cplusplus extern "C" #endif void F_LOG_BUFFERED_F77(char * log_message, int * length) { // handle message } As in the previous articles, we cache the JavaVM pointer globally in the library and this is set through the JNI_OnLoad() function. This is so that when the thread that is running the native code reaches the logging routines, and its flow is intercepted, we can reattach it to the JavaVM to get access to the data "inside". As mentioned previously, at OpenGamma we use the slf4j interface for logging purposes. So to continue our example we'll write some Java code that has a static slf4j logger (aptly named "log") as a field in the class, and then statically initialise it via a LoggerFactory method. Fortran-C-JNI-Java Callback From C, the pattern for accessing the logger within this class is as follows: Find the Java class that contains the static logger (lookup OGNativeCodeWrapper) and point a native jclass type to it. Find the Java class for the slf4j API (lookup slf4j) and point a jclass type to it. Within the static logger class (OGNativeCodeWrapper) find the ID of the static field "log". Get the concrete logger object associated with the ID found in the above. This is a jobject type and is the instantiated concrete class that implements the slf4j API. From the logger object above, or for efficiency from the class pointer to the slf4j API, obtain the method ID for the logging methods required e.g. "error()", "warn()", "info()". From the char * log_message create a NUL terminated UTF8 string buffer (AND with 0x7F or replace non-UTF8 sequences with ? or similar). Call NewStringUTF() on the UTF8 string buffer to instantiate a Java string type suitable for the slf4j logger methods. Call CallVoidMethod() on the logger object with the methodID of the logging method and the Java string containing the message. As we are finished with the string buffer and the Java string, delete the local reference to the string and free() the buffer. To speed all this up we can actually cache a lot of this information at a global level in the C library. To ensure all the pointers of type fieldID, methodID and jclass are valid, we can write a C function that refreshes the cache when the static initialisation of the Java class is performed. In this way, should the class be garbage collected (invalidating the global pointers), the next instantiation of the class will refresh them to usable values. We therefore split the code as follows: Java C library code This works as the methodID in the logging class API is looked up in the vtable which cascades through to finding the equivalent methodID in the instantiated concrete class object on which the method is then called. Just for completeness, here is some output from a quick test wrapper we threw together to Netlib's SLATEC. We call the DERFC() function with x=28 which causes an underflow: (And yes, of course we autogenerate it all ;-)) [Less]

In this blog series, we’ll introduce you to various members of our team to give you a flavour of what happens behind the scenes at OpenGamma. A core part of our customer service methodology is the Technical Services Manager: a named contact and ... [More] product specialist who works with our clients from their initial investigation through to long-term support. The ultimate goal for our TSMs is being able to anticipate the needs of the end users at customer sites before they realise they have them (yes, we like challenges). Our newest TSM is Joan Puig, who joins us with a wealth of experience from both the trading floor and the quant side. He also completed a stint at NASA before realising that financial services is inherently a lot cooler than space tech. What's your background? For the past almost 6 years I worked at Banc Sabadell, one of the largest banks in Spain. My most recent position was a trader in the long-term interest rates team. However, more relevant is the position I held previously, as the Head of the Quantitative Tools team in charge of developing the bank’s in-house derivatives distribution platform. Our focus was helping the sales team in generating pre-trade ideas, pricing them, and generating term sheets for clients. After a trade was booked, it then was able to generate documents explaining the evolution of the product (fixings, barriers hit, corporate actions, and so on). The platform covered many of the major asset classes (interest rates, equities, inflation, foreign exchange, commodities and credit). While I am not an expert on every single asset class, I have a general knowledge of how the instruments are traded, market conventions and pricing issues as well as large scale integration with many other downstream systems (risk, compliance, back office, accounting, etc). Why did you decide to join OpenGamma? When working in the Interest Rates trading team, I realised how ineffective the tools that we were using were, and how they failed to provide us with the analytics we required in real time. During my search for a solution I came across OpenGamma, and it impressed me a lot. Because the platform is open source, I was able to review the code and in several instances, they had figured out a much better way of doing things than what I had come up with by myself. I see this as an opportunity to make a much-needed impact on the financial industry. What's your role going to be like? My primary role will be helping customers evaluate the OpenGamma Platform, understand their requirements, suggest ways to integrate the platform with their existing systems, ensure the key functionality they need gets implemented by our development team, and of course, help them bring the platform to production. ---- Please join us in welcoming Joan to OpenGamma and the London fintech community! To meet Joan and the rest of the OpenGamma team, join us at our next OpenHouse on September 20th. [Less]

In this blog series, we will introduce you to various members of our team to give you a flavour of what happens behind the scenes at OpenGamma. One of the key items for our analytics library development has been functionality for credit-related ... [More] products. We know many of you have been waiting for credit derivatives coverage, but we wanted to ensure that we find the right person first. We are now pleased to announce that the newest member of our Quantitative Development team is Craig Mounfield, who has extensive experience in credit products, model validation and more. Craig holds a PhD in theoretical physics from the University of Cambridge, where he undertook research in the statistical mechanics of disordered systems. He is also the author of ‘Synthetic CDOs: Modelling, Valuation and Risk Management’ (Cambridge University Press, 2009). We asked Craig to give us a quick overview of his past experience and what his first projects at OpenGamma will be. What’s your background? For the last five years I worked as a Director at Barclays Capital. I was the Head of the Credit Derivative Model Validation team, and also worked in the VaR Analytics team developing new credit models for regulatory capital purposes. Most recently I worked as a credit correlation quant in the front office quant team. Before BarCap, I worked at Credit Suisse as the Head of Credit Derivative Model Validation. I’ve also held positions as Quantitative Risk Manager on the structured credit desk of a large multi-strategy hedge fund, and Head of the Financial Engineering and Research team at Misys, with responsibility for the on-going development of the counterparty credit risk exposure engine. Why did you decide to join OpenGamma? I was attracted to the company because of the opportunity to work at the cutting edge of technological innovation in the financial software industry. I also felt it was the ideal opportunity to apply my quantitative and market experience in a fast-moving start-up environment. What will you be working on over the next months? I will be initially responsible for implementing credit derivative functionality within the OpenGamma analytics library - credit curves, corporate bonds, CDS and more. In the medium to longer term the functionality will be extended to include more sophisticated credit modelling methodologies, such as CVA. ---- To meet the rest of our team, join us at the next OpenHouse (London) or OpenPub (NYC). [Less]

Dear NYC, We know we've neglected you. Not in the code-sense. Or the customer-sense. But in a sense that all our meet-ups have until now taken place in London. Things have been hectic on this side of the pond. We're sorry. We want to make it up ... [More] to you. In fact, we have a plan: Introducing the Inaugural OpenGamma OpenPub in NYC Join us for a pint (or two) at The Churchill (45 E 28th St) on Wednesday 29th August from 6 pm onwards (and don't worry if you can't make it right after work; OpenGamma drink-ups don't tend to end early). If you work in finance, technology, or financial technology, we'd love to meet you. We chose the Churchill for a few reasons: It's pretty much equal distance from Midtown and Downtown (and right at the corner of the 28th/Park stop on the 6); It's got Churchill's voice as the theme music in the toilets; Wifi, yo; Like much of OpenGamma, it's Bri'ish. We'll be sharing some of the exciting plans we have for the OpenGamma Platform and the community at large. Come along to meet the team and ask any questions you may have! The OpenGamma team will be represented by yours truly plus our NYC contingent - Glenn Florio (Head of Sales) and Andrew Broome (Technical Services Manager). And if we don't otherwise overload the Wifi, we just might be able to arrange a few ad-hoc demos while we're at it. Simply register on Eventbrite so that we have an idea of who's coming (and how big an area to reserve) - and most importantly, so that you'll get your free drinks tickets! (Don't worry, we won't spam you.) Londoners: come along to our next OpenHouse on 20th September instead. [Less]