Tag Archives: how to

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!

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!

Tips

Debugging crashes

1 Comment

Alright, this post will be very much focused on how to debug issues and will be low level.

Murex does crash and number of times, working for Murex we did not get all the information we needed to pinpoint precisely the problem.

The system crashes… what to do?

The first thing is to gather information from the user encountering the crash and understand what was the user doing, if it happened regularly, etc… One important thing to check, if the crash is recent: was anything changed recently (change of configuration or setting for example).

The second step is to reproduce the crash on your side (hopefully without the user). If the crash is too random or cannot be reproduced at will, the best is then to gather the core files and share them with Murex to obtain more information as to what the session was doing at the time.

Assuming the crash can be reproduced, the next step is to narrow it down. This step will actually speed greatly the turnaround from Murex side on the problem. And it might also lead to a workaround to the crash. Depending as to where the crash is happening, there could be multiple way of proceeding. I’ll cover the most common case: crash happening while loading multiple transactions.

If you’re lucky, the transaction scan watching might give you the answer. Transaction scan watching basically logs in when a transaction is opened for valuation and then logs it out. So each transaction should appear an even number of times. If one does appear an odd amount of time (and it’s the last one on the list) you might then have a winner. To confirm that the transaction is indeed the culprit, just try your process (accounting entries generation, simulation) on that single trade and see if the crash occurs.

To use transaction scan watching, go to help-monitor, SPB Information and choose transaction scan watching (Zap). This will delete the existing log (transaction scan watching is only used for debugging, you do not endanger anything by zapping it out, except of course if someone else is doing debugging at the same time!). Then choose activate and run your process again. Once it crashes, with a new session choose Transaction scan watching (Display) to check the log.

If the transaction scan watching fails to focus on a single trade, it will give you trades which have already been processed and might also give you a trend: all IRS have passed, it failed while doing loans. Be careful with this info as the way of scanning transactions is not always clear.
Without the transaction scan watching, to narrow it down, you then need to break it down by portfolios or deal type (usually the knowledge of what was changed recently helps as you can focus on what you suspect being wrong first). Don’t hesitate to use filters on trades inserted today or which had events performed on them during the day.

Once you have the trade, check it out (check also the static data and market data it uses) to understand where is the issue coming from. If you can fix it, it’s a win .
If you can’t, you can then test that the issue occurs with a new trade for which you picked the same pattern. And in that case, congrats you’ve found the bug and can raise it as such.