Market data – technically what can be done

Using Gogond’s question about market data import/export : I’ll give today an overview of all interfaces (well, all might be oversell as there are quite a few, I could have written most of them but that doesn’t sound as good as all).

The first one and probably the most use:

I. The Universal Interface

…. your hands. Sorry about that! But indeed manual action on market data is actually quite useful and probably your first stop. All market data can be copied/pasted from/to Excel. Everyone knows how to use it.

If one complains that not all market data is in the same place or using the same format than their spreadsheet, you can then use the market data viewer. You need to define a loader (market data loader to be exact) which tells Murex which query you want to run : Fx vol, rate curves, etc… You can then look at your market data from a viewer point of view. Very useful for looking at all rate curves at once for example. Even better, you can still copy/paste making it a very nifty tool.

I would also add that in pricing (eTradepad) or simulation, you can also bring viewers or popups of market data and modify them live to perform what-if scenarios.

So don’t discount the manual action as it is very simple to import/export market data manually and often people want a visual check at the same time. Two birds with one stone!


Or Market Data Contribution Service. MDCS is basically a memory service (often called the cache) which holds XML representations of market data or fixing data. MDCS is used mostly for realtime, you can load into it XMLs (usually called MDML for market data) using either RTBS (real time interface to Reuters, Bloomberg or any other provider), your own XMLs (Murex provides a series of scripts to query or upload into MDCS) or even Murex DB (you can export Murex market data into MDCS).

You can define multiple folders in MDCS so you can end up with different rates for a same instrument across these different folders. These folders are called users but I found the name a bit misleading as its main purpose is to let you segregate your cache data.

The cache is also actively retrieved from sessions (using activity feeders) to give live rates. The advantage of this method is that sessions are notified when new rates are available and you don’t need to save this data in DB, you can simply let the activity feeders push or retrieve that data to your session.

While one can also export data from the DB and then download it from the cache, that would not be the most efficient way to go about it as there is a much better solution:


Or Market Data Repository Service.  Interestingly, MDRS is a pure interface, it does not hold any data into memory like MDCS so the label repository is a bit misleading.

MDRS lets you query or update the Murex DB directly for market data in a very similar manner to what you would do when querying or updating the cache.

Note that for both MDCS and MDRS you can query on stored data (like market rates, correlation, etc…) but also on calculated data such a ZC rates, or total vol (if you upload spreads). For calculated data it is limited though, you will not get any interpolation for instance.

So if you didn’t find what you were looking for, hopefully the last one will be of some help

IV. Miscellaneous

And then you have a fair bit of old, not so used anymore interfaces some of them are being retired or are clearly in End of life mode meaning that Murex will not even provide support for them.

Among these you find the good old ascii import via reports, this was the historical import way (and for a long time the only automatic one).

You will get also the menu item Market data import/export. It has the advantage to be graphical compared to MDRS but the data you can get from it is limited and except if advised otherwise by Murex people I would strongly recommend to skip it and stick to MDCS/MDRS.

And one nifty command I really like is the export daily discount factors. You will find it at curve level and to my knowledge it is only available from the GUI (you can script it with a macro though). It basically dumps into a file all daily discount factors for a given curve. In a way it is more reliable than the previous method which consisted in pricing a trade with daily cash flows, make it discounting on the desired curve and then copy all the discount factors from the evaluation flows.

I will stop there for my Miscellaneous bag as I feel I covered the main ones, you have of course processing script to copy data from one data (or desk) to another but that’s no longer really an interface. Of course, if you are outraged that I forgot your favorite interface or anything, feel free to comment and I’ll adjust!

13 thoughts on “Market data – technically what can be done”

  1. this forum is the best ever , thank you so much for all this explanation ..

    1. Hi Gogond, I’m not familiar with MIFID and MIFID II reporting requirement. Can you detail what is tricky about them?

  2. Ok , I will change the question and I will ask about wofklow configuration , like the steps to make change on workflow , and how many ? Many thanks

    1. Hi Gogong,

      It is actually not a simple question. Worflows can indeed be changed to modify a task, add something or change arrows. All it requires is to stop the concerned task(s), change what you need to change, save and restart the task(s). But you need indeed to be careful that your workflows is consistent (contracts, documents, etc…) don’t get stuck in one place and that it interacts properly with other workflows. If you have a more precise question, let me know

  3. Thank you for your reply , I want to know how to setup a pretrade workflow and how to make it consistent as mentioned above ?

    1. Pretrade is actually simpler. It applies to trade ticket population before the trade is actually saved in the database. So you don’t have anything such as deliverable workflow or document as the trade is not yet saved and did not generate any of these.
      To configure pretrade, you need to create a workflow sheet with different tasks (usually completion, compliance and pricing will be your top 3). You then assign a workflow to a product (usually MXpress comes preconfigured with pretty solid examples, one for single trades and per family type (IRD, FXD, EQD), one for packages. And then you assign a formula to each task in your workflow.

      Best of all, you can turn on formula debugger in Murex when doing pricing (Help-Monitor-Formula debugger) and it will show you all the formula executed and how they are resolved. This is extremely handy when you need to understand what is happening. Hum.. probably should write a post about that 🙂

  4. You are always innovative , thank you so much for the help that you are providing , we’ll need a post about it 🙂 merci in French

  5. Very interesting post and as always, well structured.

    What are the solutions if we want to download something like 300 days of IR curves data? ( seems to me that Market data viewer is limited to one day, same goes for MDML)

    1. Actually MDRS should be able to retrieve multiple days as it can update multiple in one go. If not, having a small script to generate all the XML requests you need for the different dates should actually be quite easy and then just need a shell script to load them all.

  6. Hello Manu,
    sorry for the delay, thank you for your answer
    Indeed I heard that building a script to generate the XML requests was the correct approach.

    Thanks ! 🙂

  7. Hi Manu

    Does MDCS/MDRS support message queues like IBM MQ in order to upload our own market data xml?


    1. Hi,

      Not that I know of. For MDCS, you need to get the data in the cache server and the java process is the only one I know of.
      Same for MDRS, you need a java process to get it uploaded in the DB.


Comments are closed.