Category Archives: Friday funnies

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.

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!

 

 

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?

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?

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!

End of day – The joy of night shifts!

The terror of everyone working in this industry: end of day and especially their crashes. Because end of days happen at nights, most of the time everything is automated. Reports, market data copy, accounting generation are all these lovely activities which happen during the night and which are supposed to be a well-oiled mechanic.

Murex has come a long way in terms of End of day issues (EOD for the acronym lovers). When I started, the big fear was the future rollout date as the system would often crash and one would need to sort it out manually, undo what was done and redo manually. Fortunately in 15 years,  if the EODs have become more complex due to stronger requirements, the system has proven to be also a lot more reliable and resilient.

I won’t cover how to debug these issues (that was another post earlier, the search function is your friend!), but the funny cases (well, looking at them now is funny) that I had encounter.

Calling my wife. A customer had my wife number (I had given it to them when my phone was broken) but few years after, they were still calling her for EOD issues. Quite a classic, when it’s 11pm and my wife is awoken with questions she can’t understand.

Missing cutoff times. Such a big stress the first times. GL entries need to be posted by 12am or… Your first times, guesses are that it is the end of the world, bank will go bust, another black Thursday will happen. So when an issue happens, massive panic and how to get everything rolling before the cutoff. Later you learn that the world will keep going if the data to the ledger is late. Not ideal, but not a cause for WW3.

Leveraging of someone’s visit. This happened actually quite a few times. When visiting a customer and the day is closing, I got a call from the office asking to help someone for a small problem. I then spent few hours (finishing just before midnight) to solve that “small” problem that was end of day related. Other variations include saying bye to everyone and being asked if I could help on this tiny matter.

This being said, that’s an aspect of the job I like (and I hate as well). You need to be always on your toes and it’s actually good fun to be at the customer that late: very few people in (and most lights turned off) and quite a relaxed atmosphere.

And you? How much did you enjoy your night shifts?

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!

Another Friday funny… Christmas style

It’s December 24, it’s 6.30pm, I’m going into the deli shop to buy the last things I need for our Christmas dinner.

Phone rings…

“Hi, we have a production DB issues, it says database is corrupt, reload a previous dump”

This is of course in production and talking a bit about the problem it is a deep DB issue and the dbas are on it but struggling.

Fortunately, I found the right team in Murex to help and they got a solution in their timezone much before their end of the afternoon.
But the dbas on the customer side had to work on 25 and 26 to get it all fixed and they did.

I think all Murex consultants have these horror stories when the last thing you need is a production issue and it does happen.

Since then, I have to admit that during each public holidays I’ve got that shiver down my spine when the phone rings!

Friday funny story

Working with financial markets means often stress and pressure to deliver under a short timeframe.

So trying to push some of the stories I’ve lived (hopefully funny for you too) to lighten the mood just before the weekend.

This story happened while working on a project. The character here is a brilliant person, very smart and quick to understand but even the best sometimes have their weaknesses.

So I get a call from that person asking me what happens when the trade number ID gets above 10,000 and given that the size of the field is 10 digits. So my first answer is 10,001 but I suspected that there was some confusion between 10 digits and 10 times 1,000. Anyway the person hangs up and 20 minutes later I get a call that the project is threatened.

Had to get there and explain everything even if I felt bad that a simple misthinking snowballed into something bigger. Anyway, better to laugh about it now!