Tag Archives: experience

Reconciliation or rec – what should I do for my trades

Whenever migrating or updating, one task will consume a fair bit of manpower: reconciliation.

When doing trade reconciliation, the following is to be checked:

– Financial trade details reconciliation. This is usually the first one as it will be used afterwards as the key for reconciliation. In that task, you ensure that trade numbers, deal type, price/rate, portfolio, etc… all the data considered financial is correct.

– Cash flow/P&L/Sensitivities. You normally need to rec all 3. In my experience, it tends to be better to start with P&L (less figures to check, 1 trade 1 number). Then move on to Cash flows, depending on the DB side, you sometimes need a very good tool capable of handling loads and loads of lines. Finally sensitivities. For that one, I would recommend against trade by trade reconciliation. It is too demanding, use a top down approach.

– Non financial reconciliation. This one is a bit up to you. If you have some reports which extract that data, this reconciliation could be considered done. If you do not reconcile it (or even fully) this is the kind of data that can be easily updated post go live.

Reconciliation is a very heavy task. It is demanding in manpower and you need people comfortable with the both applications (the old and new ones). It is as essential to have a good tool capable of assigning defects to trades matching a certain pattern and to re-apply the root causes when performing another rec.

While I don’t think anyone really enjoys doing reconciliation and browsing through lines and lines of breaks, it is an excellent exercise. I often included more junior people to the task as it gave them a chance to go through the different screen, understand how different figures are being calculated. Of course, you cannot leave them alone to do it but they can contribute to the effort and afterwards they will have built a good understanding of the issues and the application which is perfect if they need to support it going forwards.

Feel free to share your tips and bits about reconciliation!

Naughty naughty spreads

It happened to me (again!) yesterday. The curve spreads are naughty naught critters!

Let’s explain:

In some cases, the curve spread indicator (the small 1 or 2 on the left of the market quote) is sometimes bugged and does not work properly. Usually nothing to worry about as it is quite easy to see if there are spreads or not (just need to play with the combo box on the far right).

Unfortunately when you’re working on a new environment or with rates which source is not clear to you, they’re not always your first target.

So what happened? (I know this story is more thrilling than a Stephen King book (yep, just compared myself to Stephen King just like that))

Basically a curve was not calibrating and I followed my previous post steps to understand what was going on. Removing curve spreads, reducing the number of instruments (the quotes were ok). Finally it was calibrating to a crazy rate (-50%). Could not understand why, market quote was correct. Tried to overtype the zero rate and got a crazy market quote.

As the instrument had the market quote as a margin on the secondary I was suspecting that something was amiss there. The pricing maybe was reading incorrectly the margin. Started to look at other curves to see if the problem was there as well, but everything was ok.

So went back to my curve and somehow (imagine a spot light above my head) started to check my curve spreads! Et voila, eureka moment, there were convexity spreads (in the range of -50%). Zeroing them brought everything back inline, the curve calibrated ok, problem solved.

As usual with these kinds of problems, even if you’re proud to have solve the issue, you always feel bad not to have checked the guilty part first!

What about you dear reader? Any similar experience?

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.

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.

Leaving Murex… Things to consider

Leaving Murex, that’s often a topic that comes back at the coffee machine. I think it is in people’s nature to consider all options and ensure that they always keep doors open. But some are more willing to jump ship, I think it is important to know why you want to leave and consider what your next work place could bring you.

1. Money and work conditions

This is maybe the least relevant. Murex offers great salaries and working conditions (paid leave or other benefits). Usually people do not want to leave as they believe they won’t get as much elsewhere. Except if they decide to go for contracting jobs, which sacrifice job stability for higher incomes.

2. Career potential

This one is already a little more relevant. Murex offers great career prospective but as the company is relatively flat in structure, people can hit a cap with little perspective of going further up. Mostly career driven people tend to use Murex as a stepping stone and would not stay for long in the company.

3. Challenge

This might happen actually, after a long time in a company, things become routine. As discussed in a previous post, Murex people enjoy being challenged. In a way, we could call this one intellectual boredom. I think it is actually a frequent cause for departure where people need the thrill of discovering something new.

4. Bad atmosphere

Because of Murex quite lengthy recruitment process, I think it is quite hard to get to a point where the atmosphere within a team or with one’s boss is too hard to bear. If it does happen, it’s best to tackle the problem directly and see what can be done to improve the situation.And if it can’t be done, I’d advise at changing team rather than changing company.

This should sum up the reasons that would push one to leave. Note that many Murexians are actually quite pessimistic about their chances of finding a job elsewhere. Given that most are actually quite brilliant and highly capable, that’s a bit sad.

When it comes to opportunities they have usually 3 main destinations:

A. Customer side (Banks, funds, …)

This is quite common especially if the person has been working with the bank for some time. Banks offer a wide range of job opportunities, along with long career opportunities. As the underlying knowledge is the same and as Murex consultants have very desirable knowledge for the bank, it is actually a great match.

B. Consulting firms

Second option is to capitalize on the Murex knowledge and move on to a consulting firm. More responsibilities, potentially more independence with a shot at being partner are the most frequent reasons for choosing that destination.

C. Other software firms

This is maybe one of the least obvious ones. I believe Murex is one of the best software vendors to work for. Going to another one only makes sense if it means a jump in career or if their software is very capable on a domain that is your passion/expertise. Otherwise the reasons that pushed you to leave Murex are likely to be even stronger there once the honeymoon period is over.

There are other destinations but they’re more on a case by case basis and very specific to people.

What about you? Did you leave Murex? Why? Where did you go? All comments and feedback welcome!

eTradepad – 10 useful tricks

eTradepad is a great tool, it lets you price, build strategies, strip pricings, compare prices and save quotes for later use. The tool is very rich and there are few things to know about it if you want to maximize its usefulness. Here’s my 10 things to know about eTradepad for a better you!

1. Finding a field name in eTradepad

Let’s start with the basics. When writing code, sometimes finding a field name is not obvious. Of course, one could always use the right click-Field-Plain name but you can’t copy it. So I prefer to use formula editor-customize on the field to have the field name and its string directly in the formula editor

2. Comment code

This is very very important: always comment your code. Especially when you put in a workaround or something not obvious. You could think that it will guarantee your job but it will effectively guarantee that you won’t remember your code in couple of months. And that if you go on holidays, people will need to get in touch with you to understand what is happening

3. Macros

You can create macro buttons in eTradepad. You basically attach some code to them and you can then add them at the bottom of your screen. Macros are very useful when the user wants to have some things changed all in one go

4. Workflow refresh

The button to have when doing pretrade workflow. (it sits at the very end of the list of action buttons: wkf: XML refresh). This button refreshes the pretrade code and applies it. So rather than starting a new session every time you need to try out some pretrade, use that button

5. Formula debugger

Hopefully everyone knows about it now but the formula debugger (Help-Monitor-Formula debugger) brings a popup with the executed formula as well as boolean statements and values loaded into variables.

6. Viewer

You can turn your etradepad into a viewer. The look would be like a pricing matrix. For example option maturity on the top, swap maturity on the left and premiums as the output. The development is relatively recent and can be triggered from the external settings of the notepad you’re in.

7. SCF … Don’t

SCFs are a no go in eTradepad. If you do need to use them, test, test, test and re-test. They are not all supposed to be used in the context of eTradepad. Choose an additional flow or any other solution instead of using them

8. Text area

With Mxpress, Murex did a great job at educating people to use the text area. It can give a nice text description of the payoff that the user is currently pricing. It can also be copied into the clipboard if the info needs to be sent to customers

9. Archiving

When awaiting for a customer answer or to share a pricing, Archiving is a great tool. It lets you save a pricing (either privately or publicly) so you can re-use it for later. It is much lighter than saving a dedicated notepad for each pricing you want to keep. In terms of maintenance, it is much easier to clean old archives as opposed to old notepads

10. Excel paste special

Really love this function. If you’ve got a correctly formatted excel (and preferably a notepad with horizontal display), you can paste from Excel into Murex creating new entries (aka new pricings). For that you need the action Paste Special and choose to create new lines. Very useful if sometimes you need to price a set of trades external to Murex.

What about you dear reader? Was this useful to you? Any other tricks to give away?


15 years in this industry – a Murex retrospective

Sometimes I look back at how things have changed since I started in this industry. It’s always interesting to see how things have changed as it can hint at to where things will head next. So join me on this Murex retrospective.

I started working for Murex in 2000: Matrix, internet bubble, Y2K bubble burst, Nirvana (hum, no, they were already gone). I was quite impressed with my mentor at the time as she knew everything about Murex and finance. Murex was about to release its first Java based version (the first of mxg2000 generation).

Banks were not expecting so much from vendors: they had the financial knowledge and all they expected was a software that could do what they wanted to do.

Over the years, this has changed quite a lot. They still have expertise domains but often will use vendors as a source of information as to what is being done on the market and what they should be doing. Let’s drill into some specifics:

Rate curves

Back in 2000, people were satisfied with 1 curve per currency without much focus being put on basis curves and risk.
Then came the USD basis curves and later the single currency basis curves with a major focus on OIS curves. Now you can add to the mix funding curves and from 1 to 2 curves per currency, you have now 5-6 curves for each currency.


Volatility also changed over the years. Started quite simply with an ATM curve and smile. But complexity started to kick in. Normal volatility came first as it offered a more stable measure of vega without any noise from prices. It accelerated when interest rates started to become negative and one had to use either shifted lognormal or normal models.
Then the volatility models became more popular and a must have: SABR for instance where traders start to measure their risk against the parameters.

The changes also occurred in Murex when trying to cater for a demand of always more flexibility: workflows, viewers, eTradepad, system architecture.

What’s next?

Can we expect the same trend to keep going: an always more flexible software and an industry always more complex?

I’m not sure. In regards to the industry, the move towards clearing for derivatives might push the banks to investigate more complex products that would fall outside clearing. But would there be a market for them, especially if more and more derivatives are cleared and benefit from a better price?
Or would the market data and pricing models increase in complexity in order to offer a price that is always closer to where the market actually is?

Regarding the software, it could always offer more flexibility but with flexibility comes complexity. Software complexity has a cost in terms of upgrade, configuration and maintenance. So past a certain point, the benefits are basically not worth the cost. Have we reached that point yet, I’m not sure at all?

And you? What do you think about the future?
And how was your learning experience: daunting? Challenging? Or a walk in the park?

Murex bugs: Funny stories

For this Friday, I’ve decided to write about the bad and ugly: Murex bugs!

All software contains bugs (even good old Notepad). I won’t go into details about how to debug them or anything like that. Today, I’ll be interested more in the exotic ones. The ones that as a customer, you report knowing that:

  1. No one will believe you
  2. They can’t be reproduced
  3. They always happen when you’re about to go on weekend

As a Murex consultant:

  1. No one will believe you
  2. Your bug will tank in severity and priority
  3. You’re in for a debugging session

The problems with these bugs is that while rare they do happen and are hard to pinpoint.

I’ll start with my number one in weirdness:

Exotic Murex bug number 1: The 1 week curse of bermudan swaption.

At my desk and got a call: simulation is crashing for the IRO exotic book. Alright, usual checks and impossible to trace down what is causing the issue. On-site visit, can reproduce the crash and as all debugging methods failed, had to break down the portfolio till I isolated 1 deal. A simple bermudan swaption expiring in 2025 (at the time we we were in 2005? 2006?). Long story short: the root cause of the crash was the expiry date. If it was falling within 1 week in 2025 it was crashing! Any bermudan that would mature during that week would crash.

The problem was a memory corruption. It was not happening on every server OS. And in the end, a debug binary showed the developer where to fix his code.
Problem solved but when good luck explaining to a trader he should not have bermudan maturing during that week till it gets patched!

Number 2 in my experience of funny Murex bugs:

Exotic Murex bug number 2: Computer says no

When trying to open trade number 100, trade number 99 gets opened. Trade number 99 opens normally. The two trades were not linked (nice try for those who thought it could have been the case). Whatever we were doing, we could not get to open trade 100 from the browse. If we were querying trade 100 alone, then it would open fine.
All traces were showing that we were querying trade 99. I had given up when a PAC guy came up with an idea (bless him for being around that day!). The issue was the java version of the client being too old and a java bug was causing the focus to go on another trade.
Why was it happening only on that trade? I will never know but the problem did disappear with the correct java version.

Last one for today:

Exotic Murex bug number 3: When consolidated simulation is right and detailed wrong

When you start working on Murex, there are some Murexian laws you learn quickly one of them being that: Always trust the detailed simulation over the consolidated one.

We got a call from a trader complaining that his detailed simulation was wrong but the consolidated one was correct. Back to rule number 1 above, we did not believe him at all but we went to have a look with him.

And truth was: detailed was indeed incorrect and conso was right!

The issue was that the workflow was playing with the trades entered, somehow the trader was losing access rights to the transaction and were no longer loaded in a detailed simulation. But the warehouse was correctly aggregating the trade and showing the right position.

A quick fix in the workflow status and updating the existing trades fixed the issue and let us move on.


Just to keep things in perspective, such strange bugs occurs less than 1% of the time. That’s what keeps them exotic and every Murex expert after few years will always have couple of similar stories to tell.

And exotic or not remember, as any bug you need to:

Do your part: smash bugs!
Do your part: smash bugs!

Murex viewer – My 10 tips

Murex viewer, I still remember when it started being available in the very early production releases (2003 I think?). Concept seemed fantastic but it still needed to mature.

The concept is simple: rather than showing hardcoded/static screens to show results and/or to perform actions what about letting the users build their own and re-arrange them as wanted. The viewer was born with functions very similar to pivot tables. The source data being everything Murex static data and all computed data. Add filters, calculated fields, conditional formatting, linked views and you end up with a very rich environment.

Icing on the cake, Murex viewer comes with some preconfigured layouts simplifying everyone’s work as one only needs to modify as required. It is also a showcase of examples where one can see what can be done and how to try to harmonize the views together.

But with such a powerful tool, you won’t master it on day 1 (not on day 2 either). So let me give you 10 tips to become a pro with the viewer:

  1. Use the search function! The size of the data dictionary is staggering. Worse, sometimes fields appear multiple times and do not always display the same value (reason is usually that some fields are asset specifics). Ctrl-F and F3 are your friends. And remember that the search function works only one column of the data dictionary at the time
  2. Don’t over commit. Often I got calls from support teams unable to achieve what they wanted in the Murex viewer. Some functions and/or data might not always be available. Except if you’re 100% sure it works, don’t promise you will deliver it to the enduser
  3. GMPs are your friends when you need external data! This ones always come sooner or later when the traders want to access extra data/inputs. For instance, they wish to set a date limit for short dated bonds. This date could be entered through GMPs (rather than hardcoded). Best of all, when using simulation, the GMPs will be available in the loaded market data for easy access/input
  4. Viewer is not eTradepad! Typical example of being carried away, the viewer is a tool for displaying data and not a calculation engine. It is easy to be mistaken when opening the formula editor as it looks like the eTradepad formula editor but they are different!
  5. Be careful with your colors. This might sound obvious but actually I tend to find it the hardest part of the Murex viewer. When I was preparing demos, I usually ended up spending more time on the colors to use rather than on the data itself.
  6. Endusers should not be able to modify views. This is actually quite important. One would believe that giving everyone the right to create their own would alleviate the support team workload. Quite the contrary. The number of views will grow out of control and supporting users using different views is a nightmare.
  7. An extension to the point above: Try to limit the number of views in the system. As much as possible try to rationalize the views. For support it is much easier when the number of views is low. For upgrades, it is also less work.
  8. Try to limit the number of views on screen. Murex has a client-server infrastructure and most calculations are done one the server side. But the rendering of the screen is done on the client side. If you start to have many views with a large amount of data, you might end up with the ugly out of memory java error.
  9. Item formulas are great but don’t abuse. Items formula lets you use calculated fields as line breakdowns. I often ended up using them when I needed to aggregate 2 different breakdown fields.
  10. New functions. That’s the best part about the viewer. Each new Murex release comes with new features be it graphical or within the viewer, always inquire about the novelties are they’re usually great eye candy!

So here are my 10 tips about the Murex viewer. What about you dear reader? Any other ones?

Sybase vs Oracle

This is the question one often hears when the decision has been to go with Murex: Sybase vs Oracle. Which one is better? Which one do you recommend, etc…

To first repeat what has been said numerous times: Murex works very well with either and if you need to use one or another due to bank policy or any reason, you can’t get wrong. Murex will deliver results and everything will be A-OK.

But there are differences and both have pros and cons. Historically Murex only supported Sybase and many customers feel that they will get better support from Murex if they go with Sybase. Oracle is quite well known at Murex nowadays and there is no change in the quality of support regarding Oracle. PAC team especially is knowledgeable on both fronts and can provide configuration recommendations for both systems.

Even in performance, that’s not where the difference is really going to lay (many people would disagree here and give reason to go for one or another). I feel the difference is pretty in the actual usage of each: they each work slightly differently. Not from a Murex front end of course, to the end user, Sybase or Oracle does not make any difference, system looks the same, functions work the same way. It is really when you start using SQL where you can see differences.

I graduated from SQL school with Sybase as a teacher, so I do know more about Sybase than Oracle.
Sybase wise, identifiers are directly attributed (the good old M_IDENTITY). When writing SQL, no need to take care of that field, it handles itself. With Oracle, it’s a different story, one need to call the sequence (TABLENAME_DBFS) to retrieve the latest number in order to update it. A bit more painful.
SQL clients with Oracle are for some reason always more of a pain especially if you mix direct commands and stored procedures. I used SQL developer and not seing the results of my stored procedures is a pain. I also use a lot SQuirreL. The later works great for everything EXCEPT the initial connection to the Oracle servers. When the server is distant, the initial load of tables took couple of minutes (started at 15 minutes and went down to 2-3 minutes once the link to other offices got upgraded).  Oracle also was a pain with the username/password for each schema. Not too sure why it was like that but while in Sybase one can easily switch from one DB to another with the same user, the way it is configured to work with Murex Oracle forces to log out/log back in (or log in multiple times to each schema).
But I had my fair share of issues with Sybase. DB corruption happened quite a few times (I suspect it happens also with Oracle but I did not experience it firsthand). The worse DB corruption was when receiving a dump from a customer which contained a trigger (triggers are not your friends). That trigger was attached to a different user id which we did not have when we loaded the dump. So we had to reset the user id for that trigger before deleting it. When updating that user id, it caused a DB corruption which could only be solved when stopping/restarting the server. There were other cases but nothing repeating as easily as that one.

I’d be interested to hear from Oracle experts to give me all good sides of Oracle as from my point of view, I usually found Sybase easier to work with and often wasted few hours trying to adapt a stored procedure that I wrote in Sybase to work with Oracle. Usually PAC team were the ones able to set me straight and get the procedure up and running.