Uncategorized

Dealing with angry users

This is actually quite an important topic, especially when one is more junior. Indeed, the business often relies a lot on Murex and it is a major source of revenue for the bank.

So when something goes wrong and given the high stress levels it gets sometimes quite violent. The first times, it’s a bit surprising but then you get used to and start to learn how to deal with it.  If you’re in a rush, you can simply read the last paragraph 🙂

In this line of work, you will one day or another be exposed to this sort of behaviour and you can choose how to react to it. As I can’t speak for you (well I can, but that would be a wild guess), I’ll share as to how I see things.

My state of mind starts as: we’re in all of this together. There is a problem, the enduser is frustrated: what can we do to solve the issue. I’m setting my mind into assistance/problem solving. At first, there is no point being in taking any side, you need fact, you want to solve issue. If one is angry, frustrated, etc… I don’t mind so long it does not impede solving the issue. I had a colleague once standing a full hour of complaint about Murex from one person, I think the only positive outcome from this was that the trader could vent all his frustration (in this case he was actually quite right to be). But that did not help a bit into improving the situation.

As we covered in an earlier post, you need to work out your problem solving skills and depending on the criticality, raise the issue higher.

When people are so angry, they stop making sense, I calmly explain that I just want to solve their issues and I need their help. It works 99% of the time. Once, I had a guy that told me there was no point, all was bad, etc… I asked what help I could provide. He replied none. I then left. Talked with other people and they actually brought him back to reason. We could then work it out.
Most of the time, you need information to do problem solving. Without it, you cannot do anything so make it work your way.

They usually just want a solution that works. Myself, if I know some solutions which are quick to test with limited impacts on other parts of the system. I suggest we try them first. If the solutions are more complicated or harder to find, I then ask for some time. Some people prefer to work it out and fully test it out before giving an answer, I’m not the patient type and explain that we’ll try some solutions. If they prefer I can do it offline and come back with the results. People in this line of work tend to be quite smart and quick thinkers, so leave them the choice (you work on their PC or on your own), they’ll appreciate being involved.

In short, be constructive and keep your eyes on the prize (the solution).  You’re bound to face one day someone with whom it won’t work. Forget the constructive part with him, work with someone else. As we say in french: “Le con ne perd jamais son temps, il perd celui des autres.”

Friday funnies

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!

Info, Tips

Volatility … going the distance

Today I’ll cover a bit about volatility and the different topics relating to it. If there’s one topic, you want me to dive into, let me know and I can then make a full post on it.

  1. What’s volatility?

Volatility is a measure of price variation over time. The higher the volatility the more likely the price will vary (either up or down). Volatility can be measured historically by computing the standard deviation of the prices. Or it can be measured implied, that is to say by solving for the volatility of a quoted option.

2.  Smile

When the volatility is solely time bound, we’re calling it the at-the-money volatility (or ATM vol if you prefer shortcuts). But often you’ll consider that volatility is not a constant for different strikes and it will change as you step away from the at the money point. Usually volatility increases as you move away from the central point effectively giving you a smile shaped curve. The driver behind this is that options further from the ATM point have effectively a higher price than if they were using the ATM vol point.

3. Interpolating and shaping the smile

When working with smile curves, you need to decide for an interpolation method. You can choose between parametric and geometric. Geometric interpolations take into account the pillars that you have provided to interpolate in between. Parametric requires for some parameters to be provided (correlation between spot and vol, shape of RR, etc..). SABR is getting used more and more for IRD products and traders start also to monitor the sensitivity of their positions to the SABR parameters.

4. Dynamic smile

It means that the smile is not a constant when spot rate is changing. So in terms of total vol, it is like defining a convexity to the volatility (smile being your first level). Murex can produce such effects when calibrating Tremor.

5. Short date model

Very popular in FX world, the idea is that you can attribute certain weights to specific days: Fridays are less volatile than the rest of the week, Weekends have a very low weight, Mondays are a bit higher, etc but also to specific events (Fed announcement, Big numbers publication, etc…) The short date model has really an impact on the shorter dates (the shorter the bigger), so while it goes up to 1 year, it is effectively really important up to 3 months.

6. Cut-off spreads

This one is more a workaround than a real need on the market. One should consider that an option with  a Sydney 5pm cut has less time to mature than an option NYC 5pm. So the idea is that the NYC option should have a higher price. Ideally, one would increase the time value of that option (and t would then be able to cater for fractions of days). As this is not currently possible in the system, the volatility is effectively increased to mimic the increased price for later cuts.

That’s all that comes to mind right now but I’m sure I’ve forgotten a lot about it. Volatility is a rich topic and I just wanted to give her a flavor of the different functions which are attached to it.

Comments, requests below!

Uncategorized

XML Macros

9 Comments

If you’ve never heard of them, that’s probably for the best but they’re always worth discussing.

Most actions in the system that needs automation can be done through processing script (changing the date, running a report, checking DB results, etc…) or through the workflow or specific interface (importing trades, market data, etc…). But in some cases, you might need a function in the system to do something automatically and it is not automated at all.

It usually ends up in a meeting where people look for solution till someone mentions: XML Macros.

What are XML macros? XML macros allow to automate a certain path in the application as if someone was entering all the relevant information and clicking on the appropriate fields. Recording your macro generates an XML file that you can then load via a script (on paper sounds perfect for automation).
The extra bonuses of XML Macros are that you can modify the XML yourself (for instance, username/password groups or any other typed fields) very easily AND that they can open up a session up exactly at their very end. (For instance, choosing a portfolio and loading the simulation).

On paper, looks great and feels like a bulletproof solution. Unfortunately, I tend to run away when they’re mentioned for quite a few reasons:
– They each have their own JVM. So if you plan to use them to ease the user access into the system, the user machine might end up out of memory as each session will eat up 250-500 Mo (depends a bit as to what the user is doing)
– They’re completely dependent on path built: if the path changes for whatever reason (change of version, change of configuration), the macro will need to get rewritten to adapt to the new version
– If username/password changes, one needs to look into it as well and update them.

Automation is often a set and forget solution, but in the case of XML macros, at each change (and on a regular basis) they need to be checked as they might stop working.
If automation is absolutely required and XML macro is the only solution, you need to consider an extra check post the XML macro run to ensure that the job was done properly (usually a good old DB check processing script is perfect).

If you have stories or tips about using them, feel free to share below!

Tips

RQWHERE

RQWHERE is probably the most useful function filter in Murex. It basically lets you filter based on SQL statements. This gives you complete freedom as to what criteria you want to use in order to choose a certain results population.

RQWHERE is also a pain in the neck to use the first times (and the times after!) as it is purely based on the datamodel (which as we discussed before is not documented). Based on the datamodel means that you need to understand how the data is structured and how the different tables are related together. It also means that if the datamodel changes, the filter will need to be adapted.

So if you tick the following boxes:
– Know how to make simple SQL statements
– Know how the data you need is organized
– Can’t make the filter you need with existing functionalities

RQWHERE is for you!

Basically RQWHERE calls for 2 arguments, the first one being a string and the actual select statement you wish to use and the second one being also a string but which I’ve never ever used. If someone recommends it, feel free to comment below 🙂

The way you structure your select statement is a bit up to you and while I can’t help you with it (your prefered Murex consultant can and will though 🙂 ) there is one very neat thing that can take your filter from being good to being very good: parser functions.

Indeed, you can enrich your string statement with interactive variables or parser functions. This means that the filter can prompt the enduser for a string/number/date prior to being executed which will then be used when building the string that will be sent to the function.

For example, you want to retrieve with a number higher than x. Your first argument will be something like “[start of your statement] where NUMBER>”+<interactive numeral variable>+”[end of your statement”. If you’re using strings or dates make sure that you use single and double quotes correctly: “[start of your statement] where STRING='”+<interactive string variable>+”‘[end of your statement]” (yes that STRING=<single quote> <double quote>). The built statement string will then be  “[start of your statement] where STRING='<input variable>’ [end of your statement]”. A perfectly built RQWHERE!

How to debug RQWHERE?

Sometimes your RQWHERE will not work as expected. Either it will return nothing with no error or sometimes it will spam errors. If the later, Murex will show you the statements which are failing and you can fix your RQWHERE by looking at the final result.
If there is no error, then turn on a DB trace (on screen or in logs) and check the built SQL statement if it is the one you want or not.

Questions, comments, feel free!

Friday funnies

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!

Info

Version releases, upgrades and all that jazz

Murex release policy is actually quite simple:

Major versions : 3.1.x are released once/twice a year. They contain new developments, data model changes, etc…

Minor versions: 3.1.99.x are released much more frequently. They do not contain new developments or data model changes only bug fixes.

The idea behind is that minor versions can be quickly deployed or even put in a separate launcher running in production in order to address issues. There is usually no problem having 2 different minor versions pointing to the same database and being in used at the same time. But as always, check with your Murex consultant if it is all good.

Major versions are a bit more work and contains more novelties. Frequent upgrades to major versions is strongly recommended so that the gap between production version and latest Murex version remains small. It translates into a shorter turnaround between official release and production.

The other healthy habit is to have a test environment running a build version. Of course, no one can use a build version to use in production but it can be useful to test new features and work with endusers. Endusers only really care about the version that they have in production. So the focus on time to market is quite important.
Let’s take for example the need from an enduser for a new development. First steps consist in clarifying the requirements and getting clean specs. Then one needs to liaise with Murex to get a projected timeframe. It is usually best to get commitment as to which version the development will be available. Testing on the build prior to the release is highly recommended in case something is not right, not as expected as the timeframe between 2 major releases is actually quite long.
Once the development is all good and the official release received, then the non regression testing starts and finally deployment to production.

End to end, this can mean 18 months, so it is important to nail it the first time and ensure that there is no extra delay. Also, back what was said above, if endusers can see a test version with the development, it brings them confidence that they haven’t been forgotten and things are moving their way.

 

Experiences, comments? Feel free to share!

Info, Tips

Murex documentation

5 Comments

This very topic is the reason why I started this blog.

Asking for Murex documentation is maybe the number one request, coming from consultants, customers or even internally.

Don’t be fooled, while Murex is a great system it is also complex. The system has loads of configuration options to cater for the numerous market conventions found across the globe. Luckily, as part of the project process, most configurations are already preset or adjusted to answer the requirements.

So let’s address this question that I’ve heard so many times: Can you send me Murex documentation? Or in shortened form: mx doc? k thx bi.

All customers or people in contract with Murex, can access Murex documentation. It is deployed similarly to the application and if properly setup can be accessed with F1 while logged in. It happens sometimes that you’ll have a shortcut on your desk to open it.

The Murex documentation is within a proprietary system and is strongly protected. Don’t expect to print it all out! Most of the time, the documentation is read on the screen with no other support. You have categories, search functions. With a little bit of effort, you should be able to find the information you need.

If the documentation made massive progress over the years and often encompass a lot of information, new or little used functionalities are sometimes undocumented… What to do then?

Ask your preferred Murex contact! He will try to source the information and deliver it to you.

If you do not work for a customer, integrator or Murex directly, then you simply cannot access any Murex documentation. Murex is very protective of its IP and it applies to documentation as well.

To summarize:

“- Hi, Hi need Murex doc asap!

– Press F1 (smart ass reply, often adapted to the question above)”

 

“- Hi, I can’t find a doc about defining a 4 dimension GMP structure. Can you help?

– Let me come back to you” (and you’ll get the info, example or apologies if this is not possible)