Monthly Archives: February 2015

Info

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!

Tips

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?

 

Friday funnies

The 5 skills for a Murex consultant

This Friday, I’d like to focus a bit as to which skills one would need to be a good Murex consultant. If you already are one, do you agree? If you plan to become one, check if you fit!

1. Curious

This would be my number 1. There are lots of things to learn and discover, especially when you start at Murex: 2 months of pure training and then 18 months of being closely mentored. During that time, you need to discover the software, understand how it works. You need to reinforce your financial and bank knowledge: how is a bank organized, the differences between actual finance and what you studied at school. As such, if you’re not curious, it will be tough and unmotivating to get through all this without a very keen curiosity.

2. Logical

Skill number 2. All the work is around the software and it behaves (or should behave) very logically. As such, being logical is essential. It is also a solid base when facing new problems as to how you would approach them and solve them. Finally, Murex consultants are often exposed to programming languages and logic is essential to move on quickly.

3. Responsible

Delivering quality work on time is a major strength of Murex. People are dedicated in ensuring the best possible Murex experience. As such, it is demanding because your mind is always thinking about work and ensuring all is fine. It is not a job you simply switch off as soon as you leave the office.

 4. Love being challenged

Often you will be assigned tasks which will not be easy to complete. But that’s the spirit, you need to push yourself in order to get better. And the best is that everyone around is willing to help to ensure that you can complete your challenge. Everyday, you are facing new problems sometimes with a huge pressure behind them.  So if you don’t like challenges, this is not the right job for you.

5. Technophile ~ Geek

Not everyone is a complete geek at Murex (actually just a little few) but everyone’s got a geeky side. This is maybe because we’re sitting in front of computers all day long discussing about software and hardware. I don’t know, but that’s for sure a common characteristic among people which helps strengthen relationships within the offices.

So here are my top 5 skills that I’d put as recommended to work at Murex. Would you agree? Did I miss something?

Tips

Reconciliation, how to get it right

Reconciliation is the bane of upgrades and migrations. It’s hard work where one needs to go down into details, find patterns and then find solutions. Plus you always have the stress that something new will emerge.

I can’t cover all types of reconciliation, I will focus (at least in this post) on trade reconciliation between 2 versions of Murex (be it upgrade or migration).

To get valuation (risk and PL) for transactions, you need to have static data and market data. Static data is usually very stable and I would recommend not to do any reconciliation on it. If it breaks on an instrument, it will show clearly into the reconciliation report and you can focus on it straight away.

Market data is a different story. It is usually very easy and quick to check: open both environments and check the calibrated values for curves (rates, commodities). For volatility, if you’re using a volX, check that the calibrated values are identical. Check that normal/lognormal and price vols match if you do input your volatility in one nature but consume volatility of a different nature in your models.

When rate curves are not returning the same values when calibrating, you will have a total break on all deals using that curve. Usually the difference is actually quite small (lower than .0001) so with a correct tolerance level in your checks, you should match results easily.

You can then move to trade reconciliation once the market data is ok. To do so, the usual practice is to run dynamic tables on the trade sets (of different types: PL, Cash and sensitivities), put in exclusion criteria less than $100 ignored, .01% ignored. Run the tables on both environments and then using sql compare both results and output breaks into a table.
There are quite a few solutions to do this job but it is actually quite straight forward up to this stage.

Now you have a long list of breaks (and missing entries!) that you need to reconcile. There is no shortcut and you need to get moving. I usually break down by deal type and instrument when relevant. Start then with the largest breaks and try to understand why the 2 are different (market data, change in customization, improved behavior, etc…). The important bit is to find the root cause and with experience you find it more easily.

Then you check if your root cause applies to other trades (usually it does). If it’s an isolated issue, bad luck, move on to the next trade. If it is not and other trades in your list seems to have the same issue, you need to establish a rule. That rule will flag all trades with the criteria to that root cause. There a good knowledge of SQL (and Murex data structure) often helps, if you don’t/can’t, 2 options:

– Write down the root cause of the issue and move on to another trade. Once you have enough root causes, check with someone more knowledgeable to teach you how to build your rule.
– Run a dynamic table outputting the data you believe isolate reconciliation breaking trades from others. In this later case, you might waste a significant amount of time building that dynamic table and it might not even work.

Finally comes the solving/accepting part. Some issues have to be accepted as they’re enhancements or correction. Some others are regressions or changes of behavior that will require correction. Sometimes a simple configuration change can fix these issues. Otherwise, you might need Murex help to figure it out.

The important part is to automate it as much as possible and end up with rules that you can re-use in the next reconciliation re-run. Ideally, the solutions can also be automated and make your reconciliation go smoother.

Now, maybe the most important bit: never underestimate reconciliation. It is a difficult task especially if you want it done well. It is hard to estimate how long it will take and the criteria, in my experience, to take into account: time difference between the 2 Murex versions, complexity of deals, exotic and yield based bonds (lasting scars from these).

Friday funnies, Info

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

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?

Tips

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!

Friday funnies

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

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?