Rate curves

Today’s post is about rate curves, what they are, their purposes and where things are at the moment (Of writing this post)

  • What’s a rate curve?

The point of a rate curve is to produce discount factors (or discounting rates) in order to discount cash flows, estimate rates or capitalize a cash flow. In school, you tend to consider that there is an unique flat rate for all your discounting needs but in fact the rate is not constant over time and tend (it’s not a guarantee at all) to increase over time as your risk increases.

  • What’s inside a rate curve?

The main problem is that you need to find rates which are the best representation of where the risk free rates are sitting. So you’ll want to use the most liquid interbank instruments. For a standard curve, you’re usually looking at deposits on the short term, rate futures on the mid term and swaps on the longer term.

  • Is there more than one curve?

Sadly, yes. When I started people were using only one curve making risk management a hell lot easier. Then the cross currency basis curves appear. The expectation was that risk  is different for transactions which used more than a currency (FX deals and currency swaps for instance). So one would build a curve with liquid cross currency deals (today’s trend is swap points up to 1y, 18m and currency swaps on the longer run).
But it did not end there! Afterwards estimation curves were introduced as forecasting a 3m rate, 6m rate and 1m rate on the same curve was not returning correct results. Depending on the curve, the instruments are different but usually deposit for the first pillar as it also anchors properly the fixing rate for the day once published, futures or FRAs if available/liquid and basis swaps (also when available/liquid).
Finally, the curve that is maybe the most popular now: Overnight curve (Also called OIS Curve (for Overnight Index Swap). It is used for forecasting the overnight rate but also discounting many transactions (normally all collateralized ones, but I’ll detail that in another post). OIS curve is built using a depo for the O/N pillar and then either futures when available/liquid and OIS for the longer run.

While all these curves return a price which tends to be much closer to the market, they also make risk management a lot more complex especially as curves are related. So non rates traders are forced into this world and need to hedge their basis risk where before they were just looking at a single IR risk figure per currency.

Feel free to discuss further in the comments below or the forum, but it is a vast subject and worth actually multiple posts rather than just one.

Bank organization

This post is not really for you veterans out there but more for more junior readers for which there is a bit of mystery about how a bank works.

If we focus solely on the financial markets part of the bank, you have 4 big categories:

Front office: This team encompasses the traders, the quants (depending on how a bank is organized, you sometimes have FO quants effectively sitting with the traders and pure quants), sales, treasury and FO management.
Processing: This massive team (sometimes referred to as Back office) processes confirmations, accounting, payments, securities and cash nostros, …
Risk: They ensure that the risk held by Front Office is actually within limits and their job is to ensure that the bank is not too exposed. You will find here risk controllers.
IT: The role of IT is to ensure that all works as expected. They are also in charge of upgrades/migrations (with the help of the teams above).

Of course, you have some roles which actually sit in between 2 or 3 categories and within each categories you have roles which are very different. But the idea here is to draw attention that there are different needs and drivers between teams.

Murex consultants normally act as second level of support and are most often contacted by people from the IT category. It often happens that they find themselves on the front line especially on more complex or urgent issues.

At some later stage, I’ll try to detail a bit more within the different groups but if you’re impatient or got some questions, feel free to ask!

Debugging crashes

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.