Realtime market data – Is there a too much?

When one think about realtime market data, you can think about spot rates, security prices, swap points, market quotes, etc… But there are couple of things to be aware of when you work with them.

Let’s start with swap points. Swap points are effectively a forward FX rate such as swap points = FX Forward – Fx spot.  In Murex, you can use swap points directly into the curve (and then there is no issue) but you can also use swap points to deduce a zero coupon rate and then deduce a deposit rate.

For instance, if you consider: Fx Forward = Fx spot + Swap points and Fx Forward = Spot * Df(USD)/Df(XXX) (XXX being another currency, note that the ratio of discount factors might be inverted depending on the quotation of the pair). As such, you end up with

Fx spot + Swap points = spot*Df(USD)/Df(XXX) and then Df(XXX) = Fx spot * Df(USD) / (Fx spot + Swap points).

So if you have Spot, the USD rates and the swap points, you can then deduce the currency discount factor. The problem is that you are feeding all parameters at the same time and depending on your refresh cycle you might end up computing the swap points using an old fx spot (or an old USD rate) and because you are not storing the swap points, the swap points value recomputed by Murex is then different to the one you imported initially. Most of the time it is fine as all the market data is refreshed every x seconds, so even if you don’t hit the exact initial swap point value, you will be very close.

The problem is actually more vicious when you start combining feeding market quotes from multiple sources. I have seen it before and people don’t always realize that it can cause errors:

To feed a market quote in a curve, you can use the market rates sheet, the rate curve directly and the swap points. While I would advise against using the rate curve directly through realtime (rtcu node), you need to decide for each instrument/pillar if you will be using swap points OR market rates sheet. You cannot have both otherwise they would be superseding each other and results could sometimes become inconsistent as Murex would read the lastest updated one, while you expect a specific source.

I know in the past, we had a tough time trying to understand why 2 refreshes of market data would cause the market data swap points to be different even if the cache was not changing.

Holidays coming up

Some of us are lucky enough to get some holidays soon. During that time, I’ll still post to the blog but only once a week compared to twice a week at the moment (posts will be on Tuesdays). Again if you have some topic you’d like me to cover, let me know.

Otherwise an article from 2 weeks ago that I forgot to post before. This topic is something I hear more and more about, so a short but informative article.

Business wire article about Murex collateral management

Fx volatility part II

Alright, time to go on about FX volatility. Some of you might have been waiting all week long for this post, while others already knowing it all might have to wait another week for another topic.

While last week we covered ATM and smile volatility, we are going to cover more advanced functions for FX volatility:

Cut-off spread

Cut-off spread is a spread added to the option volatility depending on which cut-off the option is on. One could also choose to have a time ladder for the spread (with a higher spread on the shorter term and smaller spread on the longer term for example). The idea behind the cut-off spread is to say that an option with NY cut should be worth a bit more than an option with TKY cut. You get indeed couple of hours more.
While Murex does not account for time when computing t for option valuation, the idea is then to increase the volatility (or decrease) to represent the difference in premium.

Short date model

The idea behind this is to say that each day is weighted differently for volatility. For instance, weekends could have a lower weight (one would argue that it could actually be 0), Fridays are usually quieter so you can define lower weight also for Fridays and Mondays might have a bit higher weight. You define what weight you want for each day and you see directly the impact in terms of daily volatility and interpolated volatility.

More importantly, you can define specific days (like fed announcements, US holidays) to have a very different weight to represent the special weight of such a day.

Short date model has a larger impact on the very short term (<3m), in Murex it goes up to 1 year but on the later months, the impact is minimal.

Smile dynamics

This could be input in the system or it can be computed using Tremor. The idea behind smile dynamics is to define the smile convexity compared to spot. So you define how much your RR and FLY (if this means nothing to you, you should read FX volatility part 1) will move by when the spot moves.

I haven’t seen it used by many people but it is there and ready to use.

I think that’s about it for extra functions in regards for FX volatility. If I forgot one you’d like me to cover, let me know!

Why I love working with Murex

There is one great thing about working on Murex: there is rarely 1 answer to a problem. But usually you can sometimes find a better solution:

Someone asked me to input a large number of SCFs (>300) with all the information in Excel. My first thought was: EVS task and I send either a large XML or multiple.

Luckily for me, it was a bit late so I thought I would do it the next day (this post is not about pushing back all your work to tomorrow, seriously!). Before going to work I then thought that Murex has some looping functionality in the code and I could build a lookup table with all the counterparts and currencies to input (amount was irrelevant).

Then  a macro would read the lookup table and insert a new SCF leg for each record changing the currency and counterpart.

Was quite happy with myself (better solution yeah!). And then opening eTradepad, something clicked in my head: while having SCFs as a line in ePad, I could as well have all the SCFs I needed in a single notepad and paste the list of counterparts and currencies.

Then a quick select all and capture trade : boom! All trades are booked and effort required was <5 minutes.

Basically I went through 3 levels before finding the best solution (if you can think of a better solution, you deserve praise!). Of course, if it happens before you start implementing a lesser solution, it’s perfect but sometimes it unfortunately comes AFTER you built the solution. Then it is quite frustrating.

And that’s the beauty of working with Murex, as there is rarely 1 single solution, you need sometimes to think differently in order to perceive the other solutions.

What about you? Ever experienced this feeling of breakthrough and finding other solutions? Feel free to share below!

Forex volatility

Last week, we looked into rates volatility, this time let’s dig into FX volatility.

Forex volatility – ATM volatility

This one is actually quite simple, you simply have a volatility for each pillar and each currency pair. As per other volatilities, you can link them together with spread and factor. The pillar set tends to be common across multiple currency pairs and is defined under the volatility groups.

But to make this paragraph more interesting, you can define a pair as not liquid and define a split currency. For instance if you’re heavy into TRY/ZAR (yep pretty extreme), you’ll be struggling to come up with a volatility curve for it. You can define volatility for USD/TRY and USD/ZAR. By also providing correlation (it can have different values depending on pillars), Murex can then compute TRY/ZAR volatility. (cross effect). While quite handy, providing correlation is also quite difficult as a task.

It is getting more frequent for rates, but for FX you usually interpolate on variance rather than volatility (vvt interpolation)

Forex volatility – Smile volatility

Smile for FX volatility is usually defined on a delta ladder. Usually you have a 10, 25%, 75 and 90 pillars.  Call 10, call 25, put 25 and put 10. A call with 90% delta has the same volatility than a 10% put.

But more interestingly, the smile is usually quoted in Risk Reversal and Strangle (or fly)

RR25 = Delta call 25 – Delta  put 25

(so effectively that’s the difference between call and put for a given delta level)

STR25 or FLY25: (Delta call 25 + Delta put 25) /2

You can easily switch from one to another within Murex or even display a smile with 5% delta increment in case you need a better view of the volatility (Murex can also display corresponding strikes)

Interpolation can be any of the usual: linear, spline, polynomial, etc…

 

I realize that I still have a fair bit to talk about in regards to Fx volatilities: Cut off spreads, smile dynamics, short date smile… So I’ll split this post in 2 with the part 2 next Tuesday!

Friday quizz!

How well do you know Murex and its history? It’s time to find out!

Murex history

  1.  What was the first product made by the founders of Murex which triggered the creation of Murex?
  2. What was the previous version before the “java” version?
  3. When did commodities merge into MxG2000?

Murex Front

4.  What functionality lets me, in a rate product, see/build the payout graphically?
5.  What vol nature is most appropriate for caps?
6.  What is the simulation functionality you lose with User definable simulation?

Murex Processing

7.  What function to use to check PL and accruals by leg?
8.  How are counterparties SWIFT details saved in Murex?
9.  How many trade validation status can Murex have?

Bonus question (to make it to 10 questions)

10.  Which file on the application directory stores the fileserver port?

 

 

Answers

  1. A Black-Scholes pricer!
  2. 117.5
  3. With the 2.11 version (called for a short moment 3.1). About 2005
  4. Linear payoff builder
  5. Trick question (check the previous post) but lognormal, normal, yield all good answers
  6. No new trade refresh (even if you pick a portfolio, or any very general criteria)
  7. View PL (accounting breakdown)
  8. UDF of course!
  9. No limit, go crazy and then back to reason with just a couple
  10. mxg2000settings.sh (yes still call like that today!)

If you have your own quizz questions feel free to post here or in the forum!

 

Rates volatility

Following the request from last week, let’s discuss this week about IRO volatility.

While the later can encompass many different volatilities: bond vol, future vol, etc… I will focus on 2 for today: cap/floors and swaptions.

Rates volatility –  ATM volatility

Swaptions

The ATM volatility of swaptions is already 2 dimensions: option volatility and underlying (swap) maturity. It makes things a bit more complex than others when you throw in on top the smile structure. (more about that later)
The interesting bit about swaptions volatility is that you can choose to interpolate the underlying maturity. You can choose to interpolate based on time, but this might need to be corrected if you have an option on an amortizing swap for instance. As such you can choose to interpolate based on BPV where Murex computes the BPV of the reference swap of the vol group.

Caps/Floors

While cap/floor vols are defined on a selected index (and you link index vol) there is another thing about cap/floor vols: are they forward/forward or for the whole cap (what’s called par)? One thing to understand is that a cap or a floor is a series of options rather than a single one. For instance a cap on EURIBOR 3M means that every 3M you have an option on the EURIBOR 3M. So if you look at a 2Y cap on the EURIBOR 3M, you effectively have 8 options.

So when you choose vol nature forward/forward, Murex expects that you will provide caplet volatility for each pillar of the vol curve. Nature cap means that you provide a volatility that would be the same for each caplet. In the case of our 2Y EURIBOR 3M cap, this means that the 8 options would share the same volatility. Murex can also calibrate the forward/forward volatilities.

Calibrating the fwd/fwd volatilities mean that the 3m fwd/fwd vol is equal to the par vol 3m (as you have only 1 caplet in that case). Then for the 6m pillar, you know the total price of the cap as the 6m par vol could be applied to both caplets to drive the price. But you also have already found the 0m/3m caplet volatility. You can then backsolve the second caplet volatility so that the sum of the premium of each caplet using fwd/fwd vol is the same than the premium using par vol.

This mechanism is very important as in the pricer this will explain why you see 2 volatilities: one on the main pricer screen (par vol) and one (well, multiple) in the flows screen: fwd/fwd volatilities.

Rates volatility –  Volatility nature

Volatility nature has been for a long time lognormal for rates products. Unfortunately the models consuming lognormal volatility have one major flaw: they do not work with negative rates. And given the current rates state, this is quite a problem.

So 2 solutions emerged:

– Shifted lognormal: the idea behind this is to shift all your rates by a certain amount when using the model (ideally you ensure that your lower strikes of your smile are far off the 0% boundary). So for example you work as if your strike at 0% is a strike at 10%. The advantage of that method is that the work to move away from lognormal is light

– Normal volatility: this is actually quite different and there is a fair bit of work to adapt models to accept normal volatilities. Normalized volatility is a volatility that is not at all correlated to interest rates. Lognormal volatility (and vega by extension) actually changes quite significantly if rates are moving by a large amount in one direction. Normal volatility is very stable. It can also be applied to negative rates without any problem. While more work than shifted lognormal, one main advantage for traders is that when you’re hedged on normal vega, your hedge should prove very stable

Rates volatility –  Smile

Swaptions

You define a smile curve for each underlying swap maturity (I often see a fair bit of linking between maturities). The interpolation is often interesting for swaptions as you can fall between 4 points rather than 2.

Caps/Floors

The smile is defined for each index, pretty standard. You can (should?) do linking for less traded indices.

Rates volatility –  Smile dynamics

Alright, this is the interesting bit: smile dynamics.

The smile dynamics is how your smile moves when the rates are changing:

– Lognormal

Lognormal dynamics is basically no dynamics at all. Your curve does not change when the rates shift.

– Normal

Normal smile dynamics is that the corresponding lognormal volatilities do change when the rates change (the conversion from normal to lognormal does use the actual rates). So even if your smile is money based, your lognormal volatility can be different for an option at the money

– SABR

SABR is a parametric volatility calibration model. While SABR would deserve a post all for itself, in a nutshell, basically you can assume that the SABR parameters are constant when rates are changing and you can re-calibrate the volatility based on the new rates

 

More questions, something I need to dig further into? Let me know!

Open jukebox

Sometimes I know for like a week about what I will write the next time around but sometimes it is the other way around: I have no idea what to write about.
Most of the time it is because I already have a post about something I am working on and, as you know, Murex jobs are usually quite demanding and you have to be fully involved, I struggle to think about something else.

So, if you have any request for a topic that you would like me to cover, feel free to through the comments, the forums, whichever way you prefer! 🙂