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:
- No one will believe you
- They can’t be reproduced
- They always happen when you’re about to go on weekend
As a Murex consultant:
- No one will believe you
- Your bug will tank in severity and priority
- 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:
