Tag Archives: documentation

How to learn Murex

This is a question I often heard: do Murex provide trainings? Who can teach me Murex or more generally how do I increase my Murex knowledge. So how to learn Murex? Sadly there are not thousand ways and they all involve work!

1- How to learn Murex – Trainings

This one is believed by many to be the silver bullet. Some trainings and the lack of Murex knowledge goes away (would make a nice ad spot). In my opinion, trainings are very limited in the knowledge they bring. They’re great to give a headstart on a completely new domain but they won’t be enough to go into details and built a long lasting knowledge. The other advantage of trainings is that it motivates people showing that you’re investing into them. 2/5

2- How to learn Murex – Workshops

The extension of the first one and the next step. It is much more useful especially when the workshop is done to yield concrete results. The attendees come with a problem/a request to solve and the workshop shows how to attend to it. The number of attendees is then very limited as it must be very hands on. 4/5

3- How to learn Murex – Documentation

So many people asking for documentation! Unfortunately, the documentation is an assistance once you know what you want/need to do. Without that information in the first place, the documentation will just describe what are the different screens without giving you a real opportunity to play with them. 1/5 (this note does not mean that documentation is not useful, quite the contrary. But its objective is not to teach you how to use Murex but how do some functions work).

4- How to learn Murex – Playing with the system

This one depends a bit on people and how much they know how the business works. Playing with the system when you try to do something along with the documentation and/or someone to bounce questions is probably one of the best way to learn about the system. If you’re brand new to Murex or to a module, it gets much harder to learn about it. 3/5 if new, 5/5 if you know what you need to do.

4- How to learn Murex – Production/Project issues

The best way to learn the system. Limited time, pressure to deliver adds to the stress of learning faster and getting results. Ideally, you can combine this with the one above once things calm down or you have a bit more time. The knowledge you gain this way is a mix of Murex and business and will be long lasting. 5/5

 

There is no silver bullet to learn about Murex. There is a learning curve, it is quite steep and you can’t learn about it alone. You need access to the system, you need to know what to do with it otherwise it’s a bit like playing with excel and trying out the different menus. So if you want to learn, get involved in issues, projects and work hard solving these. This will help you on the learning curve and take you to the next level!

 

 

Rate propagation – Curve relationships

When working on Murex rate curves, one quickly faces the problem of curve relationships and what is called as rate propagation. Once understood, it seems very simple. But before you get to that “Eureka” point, it might be confusing. So let’s dig into it and hopefully bring you some “Eureka” moment!

First of all, rate propagation only makes sense when you are working with multiple curves in the same currency. The rate propagation determines how are the other curves going to move when one curve moves. The setting sits under the rates general settings and can take 3 different values:

– Keep market quotes constant (KMQC)
– Keep zero rates constant (KZCC)
– Keep market quotes constant/Impact sensitivities

The first one and the 3rd one have the same results when perturbing one curve but the 3rd one tries to show the sensitivities due to other curves perturbation. Effectively you should hesitate between the second and the third one, as the first one does not show you the right sensitivities.

In the mode KMQC, the rate curves are recalibrated after each perturbation. Let’s take the following example:

USD DISC
USD 3M
USD 6M

USD DISC has no dependency on other curves. It can self calibrate.
USD 3M depends on USD DISC to calibrate its swap pillars as they are estimated on USD 3M but discounted on USD DISC. USD 6M depends on the 2 other curves as it contains basis swaps estimated on both 3M and 6M curves and discounted on DISC curve.

Rate propagation mode : KZCC

In the mode KZCC, you basically assumes that if any rate changes, then the zero rates of the other curves do not change. So if your USD DISC curve changes, then the zero coupon rates of both USD 3M and USD 6M will remain the same. It means that the market rates of the USD 3M and 6M curves will change. Your ZC rate for the curves does not change, so the estimated rates will remain the same. But your discounting rate has changed (USD DISC has changed), so you need to change the fixed leg rate (aka your market quote) or your margin (basis swap market quotes) so that the NPV of the swaps remains 0.

Rate propagation mode : KMQC

In this mode, you assume that the market quotes remain the same when one curve is perturbed. So your ZC rates should be recomputed. Let’s see why! Using the same example as above and perturbing the USD DISC curve will yield the following:
– USD 3M ZC rates will change
– USD 6M ZC rates will change

When you’ve changed your USD DISC curve, the discounting rates will change. So in the case of your IRS in the 3M curve, the discounting rate will change, the fixed leg rate remains constant (Keep Market Quote Constant!), so your fixed leg has a different NPV. As such, you need to modify your estimation rate (USD 3m ZC) to reach a NPV of 0.
Similarly for the 6M curve, the 3M leg will have changed NPV, the 6M leg has different discounting rates, so you need to adjust the 6m estimation rates to keep a NPV of 0, so the 6M zero rates will change.

STOP there. There are more complexities that you can lay on top of these propagation modes but the above will always stay true: you need to maintain a NPV of 0 in every instrument in your curves and that’s the only way to do it.

1 more question:

I can’t reproduce the same behavior with manual shifting, why is it so?

What I wrote above is true and what should happen BUT sometimes the variation in values are actually quite small or 0. For instance, in KZCC, if your USD 3M curve is quite flat, then you won’t see much difference after the change in the discounting rates. Why? All flows fall on the same date for the fixed and floating leg. So you can sum both flows before applying the discount factor. If your estimation curve is flat, then prior to the shift of the discount rate, your sum of the 2 flows was already close to 0. As such, the impact of the discount factor is limited.

Rate relationships have changed a lot in the more recent versions with bugs and enhancements. So if there is something you can’t explain check with someone with more experience or a more recent version if you can.

Questions and comments are more than welcome!

Spring cleaning, Purge the database

Spring cleaning, I know I’m a month early but purge is an important task and sometimes you need to make sure it is adapted to your environment and needs.

Purging the database will let you keep the database growth under control and ensure that you get the maximum performance out of the system. But there’s often a fear that purging will result in data loss and quickly you find yourself with massive retention periods, 7 years for trade,  2 years of daily market data and all logs.

The first to keep in mind: Murex is a production system for trading and processing, it is not a data repository system. You need to keep it running in top shape as to maximize the benefits you get from the system. If you need to retain some data stored in Murex, export and store it on your own system. It is much cheaper and more appropriate.
This might sound obvious but when talking about purge, regulation is often the first topic that comes and it blocks any further discussion as long as a solution for storing all the data to be purged has not been implemented.

Once everyone is convinced of the importance of the purge, there are multiple items to purge by importance:

– Documents and their entries (usually ranking at number 1 in DB usage)

– Market data (normally ranking at number 2)

– Trades

– Logs

– Static data

– The forgotten ones: view, layouts, filters

Documents

Purging Mxmlexchange is actually quite straight forward and is done through scripts provided by Murex. Just be very careful with the scripts and ensure that proper testing is done on test environments before deploying to production.

But if you test it properly and only purge the intermediate documents, it is quite straight forward without surprises

Market data

Market data is made of 2 parts. The visible side of the iceberg where you purge market data for dates you no longer need (good practice tends to let people keep the month end only for older dates and daily market data for few months (1-3 depending on your aggressiveness). This can be done through the GUI if you want, quite straight forward.

But there’s also a second part of market data  purge which helps a lot: expired instruments (read Bonds and listed options mainly). By default, Murex automatically copies all market data entries from today to tomorrow as part of EOD. This automatic copy means you also have entries for expired listed options (ETOs), futures or bonds which keep being rolled. It might not sound like much but ETOs can quickly snowball especially if you trade very short dated ones such as intradays and overnight. Here, Murex can provide you with a script to clean them out. Symptom for this second one are tables such as MP*_GLOB and MP*_PRIC being large in size.

Trades

Trade purging makes sense especially when you do volume trading. The trade purging is done through the GUI (very important) and in such a fashion that all purged positions are getting aggregated to avoid any jump in cash balances.

The trade purge occurs in 2 steps: a logical one, where the trade is no longer read for reports and simulation but is still present in the database. All its contributions are stored and aggregated with other purged deals. It can be undone if required
The physical purge will effectively remove the trade from the system, you cannot anymore query it and it cannot be reversed.

Position and cash balances testing needs to be performed after each purge step. After the logical purge, it is the most important as Murex will no longer evaluate the trade but read directly its stored contribution. After the physical purge could almost be skipped as it does not affect anymore the aggregated results, it is simply removing the unused trade records.

Trade purging depends on the trade complexity, simple spot forwards can (and should) be purged much more aggressively than more structured deals

Logs and audit

Murex will give you the scripts for these, purge as requested and make a copy if you feel the need upfront. They don’t consume much space but clean logs make browsing through them a lot easier!

Static data

I am actually an advocate against purging static data. Murex often references static data under the purged deal contributions or in other places and removing them, will remove that link for Murex. One could always try to fix all the problems which ensure out of it but in my opinion, it is simply not worth it. The amount of problems generated (and which could come later during or after an upgrade) is not worth the small amount of DB it occupies.

Filter, layouts, views, etc…

These items should not be purged per se but should be kept under control. Restraining users from creating, duplicating is probably the way to go.
To clean them up would probably have not much of an impact on the database but you risk that an EOD report or a process would fail. Except if you have kept a very precise list of which items are used by what process (and if you did, kudos!), you probably have to leave them where they are or start a massive campaign identifying and decommissioning the unwanted ones.

 

In summary, if you concentrate on the top 4 items of this list, your DB should grow as expected when the hardware was planned with Murex and performances will remain optimal. Just keep an eye on the DB usage by table and if something grow too quickly, Murex will always be happy to sort you out!

If I forgot something or if you feel like to add something, please feel free to!

Having fun with the system

For a lighter mood this Friday, let’s talk about the ways to have fun with the system. Murex is a complex system, not always easy to configure or to get familiar with.

But who says complex system also says lots of places to put this funny little touch that will bring a smile when spotted.

Here are a few I’ve encountered:

  • Classic but always good: the funny comment in code (pretrade or stored procedure for example). One of the best, was /* Added to please Ms Princess while it serves no purpose */ Had to tell that person that this code was going to prod and taking it off would probably be a good idea
  • UDF consistency rules messages: “Why did you forget to enter XXX” (this was when entering bonds). I could tell the person who wrote that bit must have been so frustrated that they had to vent some anger into the message. Had a smile on that one building back the story
  • Name of views and filters. One of my ex-colleagues was always putting insults into his filter labels (and normally was deleting them after use). Well, let’s say that some DBs still have these words on few places
  • Description fields. I have to admit that this one is best used on static data that only support people have accessed to, not everyone might agree on that one!
  • Documentation and label of objects used. Remembered that bond called NOTABOND, classic but gold 🙂

Did you encounter some too? Did you put some yourselves (voluntarily or not)?

Have a good weekend!

Murex documentation

This very topic is the reason why I started this blog.

Asking for Murex documentation is maybe the number one request, coming from consultants, customers or even internally.

Don’t be fooled, while Murex is a great system it is also complex. The system has loads of configuration options to cater for the numerous market conventions found across the globe. Luckily, as part of the project process, most configurations are already preset or adjusted to answer the requirements.

So let’s address this question that I’ve heard so many times: Can you send me Murex documentation? Or in shortened form: mx doc? k thx bi.

All customers or people in contract with Murex, can access Murex documentation. It is deployed similarly to the application and if properly setup can be accessed with F1 while logged in. It happens sometimes that you’ll have a shortcut on your desk to open it.

The Murex documentation is within a proprietary system and is strongly protected. Don’t expect to print it all out! Most of the time, the documentation is read on the screen with no other support. You have categories, search functions. With a little bit of effort, you should be able to find the information you need.

If the documentation made massive progress over the years and often encompass a lot of information, new or little used functionalities are sometimes undocumented… What to do then?

Ask your preferred Murex contact! He will try to source the information and deliver it to you.

If you do not work for a customer, integrator or Murex directly, then you simply cannot access any Murex documentation. Murex is very protective of its IP and it applies to documentation as well.

To summarize:

“- Hi, Hi need Murex doc asap!

– Press F1 (smart ass reply, often adapted to the question above)”

 

“- Hi, I can’t find a doc about defining a 4 dimension GMP structure. Can you help?

– Let me come back to you” (and you’ll get the info, example or apologies if this is not possible)