Murex assistance or handover, how much information does one need?

I had that conversation last week: in order to provide Murex assistance, how much information is required?

Murex consultants (from Murex) providing support usually don’t need design documents, they can be useful sometimes but most of the time they will intervene on single specific problems. Access to an environment is ample information and they will dig in to retrieve whatever information is necessary. If you ask them as to why a crash is occurring, a task stopped working or a formula is not triggered, they do not need to look at the full picture. They can only focus on the single issue and all the information will be at hand (remember that Murex gives usually easy access to all the information used to produce a result: rate curve will give all pricing details, formula debugger will show code execution as well as variable values.

The other reason is that usually Murex consultants are supporting multiple customers and reading through the design document would take a significant amount of time while yielding no direct advantage to answer questions.

On the other hand, internal support team members  need to read the design documents if they haven’t been involved in the project. The design document will effectively describe the big picture and explain how everything fit together.

But thinking it over about the time I was supporting different customers at Murex, we would either ask the customers when something seemed not right. Sometimes it would indeed be a design decision and it would not make sense to go against it.
An example: few weeks ago I wrote about rate propagation and basically KMQA/IS is the most logical choice. But you will find customers using KZQC, especially in the Fx world, and this is perfectly normal.

Of course, there is a real added value for the Murex consultants to know about the design choices. This knowledge could come from reading the design document or more often from frequent support and proximity to the customer. And I was indeed more efficient in my efforts when I clearly knew why such a configuration was selected.

Does this mean that Murex consultants should read and go through design documents? I don’t think so, except if they are supporting only that customer (or very few customers). Their job is to provide information about the software, help you get most of it and solve your issues. But the internal support team can provide them assistance and guidance as to why a solution would not be suitable in the customer’s context. Good support is always at the encounter of Murex knowledge and customer configuration knowledge.

Murex interview – What NOT to do

During my time at Murex, I had to recruit quite a few people and I faced different profiles, so have a read, smile and relax. For an interview you need to be prepared and at your best. So here are some pitfalls you can easily dodge.

Murex Interview – The Test

There is a test! Yes, it’s best to revisit your finance/programming/math lessons so everything is fresh and handy in your mind. You have 1 hour to do your best.

I think I have to give the golden crown to one candidate (to whom I already told there was a test): he came in, sat in the room and I left him to work on his test. 10 minutes later, he came out, handed me back the test (nothing written on it, not even his name, perfect to give to the next candidate). “I don’t think I’m suited for this role”. At least he was honest.

Second place goes to someone we ended recruiting because that person is actually really good. But when asked to give a simple definition, there was actually a fair bit of writing. 1 page! In small characters when 1 sentence could have sufficed. Know that we discuss with you the answers you give and we can easily tell if you understand or not

Last place goes to the bullshitter. Answers were very generic and could not make much sense out of them. When asking him for more details, he told us that he did not believe that it was so important to know things in details, you can always talk your way out. Well, he managed to talk his way out of the interview.

Murex interview – Presentation

Job interview is a two way street, you discover the company and people who are looking to recruit BUT they also discover you and who you are.

Once we had this candidate who was just looking at the table, did not even look at one of us once. And his answers were short when not single worded. Not matter what we tried to get him to relax, we failed miserably and we could not get him to open up. As many Murex roles are customer facing, being comfortable talking to people is important!

When you present yourself, it’s important to explain why Murex is of interest to you and especially on the longer run. Some people (yes it happened more than once) were upfront enough to mention that they were looking at Murex just as a stepping stone in their career. Definitely not a smart move!

Murex interview – The good surprises

But sometimes you get good surprises. The feeling (usually straight away) that you found a gem, someone that would fit perfectly the bill. And the interview/test will effectively confirm it.
I often pondered if it was simply the first impression that decided how an interview would go but I do believe that the Murex test makes things actually fairer. Someone with very good presentation but lacking knowledge would effectively be at a disadvantage after the test. Someone not so good at presenting can gain some confidence and feel more on familiar ground thanks to the test.
After that if you’re not good at presenting and don’t know much, maybe it’s better not to take the interview!



Secdata, bonddata are two very useful functions in Murex for retrieving security data, date of next coupons, yield to price conversion, etc… The problem is that they’re not always easy to use. So get your documentation nearby as you’ll need it with these functions.

How to use them?

They basically require 3 inputs: (string,date,string). The first string is the description of the security you wish to use: Market and security label most of the time and you need to add the expiry label for futures. You need to separate the market and the security with a comma in the string.

For instance “Market,Label” works, “Market”,”Label” would basically make Murex believe that you’re trying to input “Label” into the date field.

So usually TP_SECMKT+’,’+INSTRUMENT would give you the right argument for the first string.

For the date, that should be no problem! 🙂

For the third one, refer to the documentation and you should be all set.

Alright, so now you have a working secdata (or bonddata) function and it all seems good. Unfortunately it is not so simple and here’s the SECDATA pitfall:

If you call SECDATA or BONDDATA while parsing non security instrument, it will return an error message with something such as XXXX security not found (where XXXX is the label of your instrument). This is especially the case where you have swaps, deposits, anything basically that is not security related.

If you try to use an IIF statement to avoid the problem, the error message will pop up anyway: IIF(TRN_GRP==’BOND’,SECDATA function,0). The reason is that Murex evaluates all arguments of an IIF statement even if the boolean is false.

So, are you doomed with error messages? No! You just need to create another horizontal field which will become the first string argument:


And then you use the IIF statement again (especially if you need to return something specific when it’s not a security):

IIF(TRN_GRP==’BOND’,SECDATA(H_SECURITY,date,desired functionality),0)

So that’s how you can call upon SECDATA and BONDDATA when loading a portfolio not entirely made up of securities. This being said, I would recommend to look at already existing fields in the dynamic table to see if you can do without SECDATA or BONDDATA. Accruals being negative to see if the bond is in ex-div, MP_UPPRC for the current price, etc…

If you faced other problems or if you want to share any other trick with these 2 functions, feel free to!

Rtimport – An anonymous interview

This Friday, we have a special guest Mr D. He preferred to keep his identity secret given the very sensitive information he will share with us today.

Murex Experts: Dear Mr D, first of all thank your for your time today. To present you, you’re one of the fathers of good old rtimport. Tell us a bit about yourself.
Mr.D My model has long been Stewie Griffin, the crazy baby who wants to destroy the world with one of his weird and deadly weapons. When I realized Stewie didn’t actually exist, I had to turn to something more reasonable. Still, rtimport wasn’t a bad finding. Something that can turn your P&L to dust without you or anyone else actuallt able to figure out why. Scary, no?

M.E.: How did you end up being the father of rtimport?
Mr.D To tell you the truth, I’m not its biological father, I found it alone and helped it find its true potential.

M.E.: Rtimport crossed a millennium and was probably the last program using the old technology/layout (if we except MReport/Union viewer in Murex). How do you explain its longevity?
Mr.D You know, rtimport is a bit like a kid’s treasure you put in a box and bury under the big tree in your grandfather’s house’s garden. Once it’s there, it doesn’t make any noise, grass grows back, and everyone forgets it, or how to open the box and what was so precious in there. I guess some rtimports might still work here and there. None knows there are there, but they are and still feed SHMs with all sort of rates.

M.E.: You do remind us of painful memories when the only person who had the slightest clue about rtimport is away and something needs to be changed/fixed.
Mr.D Yes, remember the reference to Stewie Griffin, I’ve been doing my part, one small step at the time

M.E.: The way of executing formula (line by line) is actually quite unique in the Murex world, how did you come out with this idea
Mr. D
Actually, it came from a grand idea that was always supposed to work but never actually fully worked. You remember how security prices and future contract prices were subscribed from a Cartesian product on SE_ROOT_DBF and MPX_PRIC_DBF ? If you hadn’t created a row in MPX_PRIC by inputting a first price for the stock or the new future contract first, rtimport wouldn’t try to subscribe any RIC. But if you did so, it would be able to rebuild the memory table on the spot and subscribe the new security without a restart. That was the beauty of the line by line.

M.E.: Hummm, sure. I think I’m not the only one who sweated a fair bit on the tool, was it always the initial design to have preloaded tables/unions, temporary tables, links and then extended links?
Mr. D
Yes, any issue with that ? I particularly liked the temporary table thing. Not actually useful if you are on a proper database (it was an inheritance from the codebase years), it was a bit like there three of four stones on the top of each other you sometimes see on Italian highways. Useless, costly, not even nice, but all that remains from an ancient temple for a long forgotten goddess. Now, don’t tell me you were actually using extended links ?? they were used in the default configuration, but we never expected anyone to ever open them ?

M.E.: Of course, giving access to something that you don’t know fits completely with your secret evil scheme of taking over the world. Moving on. Anything funny or easter egg in rtimport that you can share with us?
Mr. D 
With the display, it would have been hard to build a flight simulator or even a pacman in rtimport. There is something I never understood about it though. You remember how, if swaps were not contributed properly, you had to manually reindex RT_LNGN_DBF ? Well I never got why this table in particular, and why index would get broken by the first swap subscription. I think we never found out.
Oh, now that you mention it, there was something meant to be nice in rtimport. Remember the yellow and blue colors in the series screen to show whether your option was deep in or out of the money ? well it was supposed to work with real time, thus turning your series screen in a Honolulu beach screensaver … but none ever felt the poetry there and always focus on how slow the screen was. We live in such a superficial world.

M.E.: Poetry coming from an evil (I mean it in a good way) genius, we did not expect that! Next question: How did you feel when RTBS came out to replace your baby? Betrayed? Relieved?
First of all, thank you for your nice words. Back to your question rtimport has well past majority now, we still talk to each other but it doesn’t need me any more. If it decided to retire and pass it to its own children, I’m only a happy grandfather.

M.E.: Sounds like to us that you’re denying biological fatherhood but still cared for it for a while. Are you trying to dodge parental pension payments? More seriously and this would be our last question for today.
Was it considered at one stage to upgrade rtimport to get a GUI upgrade or you a firm believer that X windows is the way of the future?
Mr.D Rtimport was never a tool for the future, it was always the good old chap you have here and won’t let you down, but as far as I can remember, it was always to be replaced by something more strategic, but if you ask, I’ve been told that George RR Martin wrote the whole Game of Thrones series on a DOS version of WordPress, so X windows isn’t that bad after all !

M.E.: Thank you Mr.D for all these insights and we bid you good luck in your taking over the world thing.

Exporting a browse screen – The best way

Murex has many browse screens: trade query, accounting journal, payment query, etc… And associated with these screens comes the question: how do I get that information outside Murex?

There are multiple ways of doing it but there is a first question to answer: what do you need it for?

Exporting a browse screen on a regular basis

If you indeed after a browse screen exported on a regular basis, a report is probably the better solution for you. You have multiple options:

  • Rebuilding the browse in a viewer and making a dynamic table on it (I would not recommend that solution expect if you have another use for the viewer).
  • Re-selecting the fields you need from a standard TRNRP_PL (or whichever appropriate) dynamic table. This is good if you’re after some calculated fields which are not always available in the browse directly (How many times did I get the request to have PL figures along with the trade query)
  • Building the report using a copy creation of the table your browse is based on. It might not work in every case but for trade query it does work fine. Just reselect the fields you need from the table and/or the related tables and you’re all set

Reports can be automated during EOD and produce data automatically.

Exporting a browse screen on an adhoc basis

This one is probably where I can help you most.

There are 2 main ways of doing it. The first one is to use the classic windows shortcuts: Ctrl-A (select All), Ctrl-C (Copy) and then Ctrl-v (Paste) into excel/word. Good old classic. Never disappoints and always work.

The classic way is great especially if you have a limited amount of data to copy. It gets trickier when you start to have multiple pages (usually more than 300 lines). More Murex proficient people will tell you to use Ctrl-Shift-C and voila, all columns copied regardless of the number of pages. While it does work, be very careful.
One evening, I was leaving a customer site a bit late and could see someone still at his desk. That person needed to export that data and used Ctrl-Shift-C and the pop up window Copying was still there. The problem of Ctrl-Shift-C is that it loads all the data from the server to your computer clipboard. If the amount of data is too large for your memory, the java process might run out of memory and while you believe something is still happening, it is in complete limbo. And you don’t want to waste your evening because of that!

So here’s the better solution when the amount of data is large: File-Export… The export data lets you export all data to a file (on your computer). You can choose to export all pages and it will do it by itself leaving you with a csv file in your client directory.

Somehow, while this function is much more reliable than Ctrl-Shift-C, it is quite unknown. Maybe because nowadays everyone copies/pastes everything!

The devil is in the details

Whoever worked for some time with Murex must have heard that sentence at least once : “The devil is in the details”. So as we’re Friday and try to relax before the weekend, let’s put it under the spotlight and have a good laugh at its expenses.

The devil is in the details – What does it mean?

The idea behind that sentence is to say that details are important. In practice, people tend to use it to escape answering a question or request.
Let’s take an example of a request (note the 4 first words from the request, they set a mood):

– It must be easy to have a full explanation of my PL

Either you go with yes and you’re in for many iterations because PL explanation is never simple especially when the portfolio contains different types of trades. Top that with choosing the right time to close the portfolio and the market data and you realize it is nowhere near easy.

If you reply: “Must be, but the devil is in the details”. You more or less killed the request. The requester will then need to detail exactly what he wants and you’re more or less letting him figure out what is the next step. It’s a good silver bullet (especially on Friday afternoon) but should be used with parsimony.

The devil is in the details – The machine gun

The problem is that some people overuse it to the point that they dodge all questions.
In a 1 hour meeting, I’ve once heard it 4 times! That’s a lot. To the person’s defense, they were the wrong person asked. But the other party got annoyed as they could not get anything out from them and I believe that the meeting could have been much more productive by answering differently.

The constructive method

Instead of using that sentence, the best is to offer a path to solution. If you’re the wrong person asked and don’t know all the details, just point it out and propose to get in touch or to gather the information from them.
Similarly to the question about PL explanation, I would rather start asking about the details: “Do you just have this type of product in your portfolio?” or “What effects you’re after in your explanation?” Of course, experience is then needed to be able to drill into it.

I think it is better to show people that their request is not simple after all and they need to refine their requirements. As Murex expert, people need to see you as a solution provider.
And sometimes I even go faster where I actually accept the request but based on my knowledge I tend to know quite well what they want. If you can then deliver 95-100% of the request, you’re on your way to build yourself a good rep.

Historical data, how to copy them

I often had to use this method to copy fixings data from one environment to another (Especially inflation data). So here’s how I am copying historical data from one place to another.

What is an historical data file?

Historical data files store the past fixings. Through the GUI, they’re attached to indexes under the name archiving group. One historical data file might contain multiple indices: different currencies (rates), different frequencies (rates), different publication time (FX), etc…

To identify the one that contains the data you need, best is to use DBX Request (search the blog for earlier posts 🙂 ) with a trigger on HBS, You will get something like BXXXXXX_HBS. The XXXX is the historical data file number you need to use, it is unique for each archiving group and if you create the same archiving group in 2 different environments, nothing guarantees that you end up with the same number.

How is the historical data structured?

You have a header and a body. Header file sits as HXXXXXX_H1S (or H2S) and the body is BXXXXXX_HBS. Header determines how is the unique ID for the body assigned: what currency, what frequency. The body has the following info: unique ID, date, rate and effective date (if used). So if you retrieve the unique ID you need (for instance EUR 6M index) from the header, you can then simply retrieve the rows you need from the body (or update them).

How to copy the historical data?

If you understood the above, it becomes then quite simple! Find the historical file you need to copy from and the one you need to copy to. Simply insert the lines from the source into the destination (if you’re copying the whole table, a simple sp_rename on the table does the trick). Once copied, update the unique ID in the body table to match the ID you have in the header. And that’s it.

If you need to do it cross environments, you can use the transfer from RDB to DBF to dump the table onto unix. Copy the file into the destination environment and DBF to RDB to re-upload the table.

There are of course other ways to do it (such as using MDRS) but I tend it to find them more cumbersome and not at all as efficient. This method is fast and easy to repeat. The only downside is that it is hard to completely automate given the uniqueness of the archiving file ID.

If anyone else has a better method (or recommendations), feel more than welcome to share!

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 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!