Tag Archives: retrospective

Friday funnies

Murex error messages through the ages

Today, when you have a crash, the message is pretty standard and very intelligible but it was not always like that let’s review what they were.

Murex error messages : the X-windows era

Time: time before 2000/2001

At the time of X windows, there was no error message as such. If a session was crashing, basically the process would stop straight away on the server side and the window would simply disappear on the client side. Did you really have a crash? Or did you close it by mistake? You can never be sure and it was always confusing. Probably the best time for supporting customers 🙂

Murex error messages : Fatal error

Time: from 2000/2001 to ca 2005

When Murex released the Mxg2000 version, the software architecture changed. On the client side, you had a thin client running. As such, if the process crashed on the server side, you then had to display something on the screen. So they settled for probably the largest error message possible: Fatal error for session detected for process XXX. Session will now close (I’m not completely sure I nailed it exactly as it’s been some times!). All I remember is that the error could span on your whole screen especially if you were just using a 15′ screen.

Murex error messages : Maybe?

Time from ca2005 to ca2009

Alright, to be fair this was the error message that motivated me to write this post: The error message ended in Service is maybe dead. Technically it was correct: the client could not connect anymore to the server process. So maybe it was dead.

Problem is that for end users the results was the same: close and restart a new session. And if you had few crashes in a row, you would wonder if Murex was mocking you. Yeah maybe it was 🙂

Murex error messages : Modern times

Time from ca2009 to now

Sadly (for this post I mean), Murex is crashing less and less and we probably reached the most clear and intuitive message to date: “Process is not valid anymore. Session will now close.” It’s not too long it’s concise. Unfortunately you can get access to the java stack that many people still like to sent but as the crash occurred on the server side, the java stack just shows that the client cannot connect anymore.
Anyway, after few iterations, the message is now crystal clear!

Dear reader, my memory is not what it used to be. So if you see an error (haha) or something missing, please let me know and I’ll correct it.

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.

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?