Monthly Archives: December 2014

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)

 

Friday funnies

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!

Tips

Database traces

Database tracing is very handy when you’re trying to grasp what is causing an error and you suspect something wrong in the configuration (an incorrectly setup security, market data, etc…) or you’re looking to build an SQL query and need to have a bit of a better understanding of the data model (note that I do not encourage you to use SQL, reporting and dynamic tables should be your first stop but sometimes it is not enough).

In Murex there are couple of database traces and some are more useful than others.

The first one I used is the one coming up through the GUI. Every request pops on the screen and by pressing escape gets executed. It’s simple to use, simple to turn on and don’t need to retrieve the file from the application server. Sadly, it sometimes causes crashes due to the popup windows interfering with the application or sometimes you simply have too many requests for it to be useful.
To turn it on, you need to go to Help-Monitor-DBX Info-Request . You can then enter criteria to filter the requests: From the action (update, delete, insert, select) to a string search (e.g. TRN_HDR or BOND001).
When I began in the Murex world, I loved that tool as it helped me put together the pieces of the puzzle.

The second one is to activate the traces dumped into a log file. To do so, go to Help-Monitor-DBX Info-RDB Statistics. You can choose what level of debugging you need. The basic one is good enough if you need to look at the queries executed. The full verbose (apart from the plan) one is necessary if you’re trying to track missing DB Indices or need to understand which requests are costing too much time. That trace will by default dump files into logs/mxsession/mx but the default path can be modified within the launcher.
One can also turn on that tracing with a slash command: /RDXSTATISTICS:<prefix>:<trace level>

You might end up using the information given from the traces for:

– Building a report

– Building a RQWHERE filter

– Narrowing down an issue

– Building a SQL procedure (useful when upgrading/reconciliation but always check with Murex if it’s all good)

DB traces are not the silver bullet and sometimes won’t give you the information you’re after. Also in case of investigating a crash, keep in mind that the last request might not be the one responsible for the crash and you might need to go back up in the logs to find the root cause.

 

If you have questions, funny stories or feel like it, please comment below!

News

Volatility news

I was starting typing a post about volatility (you’ve understood that it will come later) but getting some material I got into quite a few articles about the expected rise of volatility for 2015.

For instance CNBC  or here .

It’s important in our line of work to keep updated about these articles as they’re often going to translate into concerns or demands from customers. For instance, the interest rates going down led to requests for shifted lognormal volatilities and normal volatilities.

I’ll try to keep posting whenever I see some articles of interest and feel free to do so too!

Info

Funding curves

In the extension of the previous post, I’ll cover a bit the funding curves: what it means and how they’re being used.

  1. What are the funding curves?

A funding curve crystallizes the  funding spreads over the market rates for the bank. Usually you will find that these spreads are over the O/N rate and the funding curve is often in USD.

That curve represents the cost to the bank to fund their positions. When it needs to be expressed in different currencies the current approach is to ratio discount factors: Df(XXX funding curve)/Df(USD funding curve)=Df(XXX/USD basis curve)/Df(USD OIS curve). The assumption behind is that swap points are a constant.  So you end up with the discount factor you’re after (Df(XXX funding curve) as Df(XXX/USD basis curve)*Df(USD funding curve)/Df(USD OIS curve).

2.  How to set them up?

In Murex, this can be setup using the Automatic CSA curve setting. You’ll need to define a CSA category (such as No collateral) and attach the proper curve assignment to USD (assuming you’re using USD for funding).

3.  When are they used?

Trades can be collateralized or not. To be collateralized, they need to be covered by an agreement with your counterpart and in that case, any large market value for that transaction will trigger a margin call and thus limit the risk for both sides.
When the trades are not collateralized, this is when you want to use the funding curves as the bank is much more exposed and the returns expected are higher.

In terms of pricing, this also means that when trading with a non collateralized counterparty, the prices will be worse given the increased rates.

4.  Anything else? Risk management maybe?

This is where the funding desk comes into the picture. The role of that desk is to determine the funding spreads but also to manage the risk coming from these curves. For traders, they will also look at their portfolios as if all trades were fully collateralized BUT any trade with a counterparty with no agreement will effectively use the funding desk as an intermediary : the funding desk trades the same trade back to back, with the counterpart using the funding curves and with the trading desk using normal curves (OIS or basis curves).

In a nutshell, that’s what funding curves are about. As always, questions or comments are more than welcome!