Category Archives: Info

Info

P&L, P&L Var what, how, when, where

11 Comments

Been quite busy recently (and I am still!), but as promised here are some good pointers to help you out (hopefully).

P&L , the recipe for success!

First step in this post is to ensure that everyone is aligned how P&L is computed in Murex.

P&L is simply the sum of Past Cash, Future Cash and Market value. Sounds easy! Past Cash can be a simple of the past cash (and that’s probably the best way to look at it) or you can have Murex compute a theoretical financing, where past cash is actually capitalized.

Future cash is usually short dated. You can look at them either as non discounted or discounted. In this case, it makes usually more sense to discount them (do you prefer 100 Euros today or in 1 year time?)

Market value is the value of the trade as of settlement date (theoretical settlement date). You can also look at the discounted market value which is back to today.

That’s how most people look into P&L, then you have further breakdown: realized/unrealized, revenue/capital. If you have questions let me know!

P&L Var … Where does my P&L come from

Alright, this is the best part of the PL tool in Murex. From simulation you can run the PL Var tool (it can also then be set in a dynamic table, but start with the simulation, easier to play with).
Normally you should have some default scenarios or you can also look at the doc (pretty good!) but let’s drill down into the available options:

  • Theoretical P&L Var. That’s the one most traders are after, it’s fast and usually a good tool. In order to estimate the P&L variation, you simply take the variation of market data multiplied by the sensitivity (you can also add second order effect which takes into convexity). Usually traders like this mode as they have direct control (hopefully!) over their sensitivities and if they lose or make money overnight, they want to be able to attribute it to market data variation.
  • Actual P&L Var. This one is accurate but much much slower. Basically Murex loads the portfolio as of the day before and replays all actions (that you choose as part of the PL var setup): not only market data but events also (trade insertion, trade modification, fixings, etc…). Depending on the order of the steps, you will get a slightly different attribution for every step (if you put spot variation before rate curve changes, etc…). You can also choose to reset the PL after each step but then the total of all steps will not be equal to the PL variation between yesterday and today. Finally, you have the last bit: Global other. This should be the last step in your scenarios. It is the difference between the the computed PL variation with the scenarios and the actual variation between the 2 dates.

The best part of the Theoretical P&L Var is that you can display the market data for the 2 dates, as well as the sensitivities and convexities. So everything is available and make it easy to “debug” any unexpected jump.

One last thing: test, test and retest the PL var, there are often exceptions, some cases are also complex (like your vol smile sensitive to the rate curve) and in case you are using the actual PL var, just ensure that your global other is always very small (unfortunately not always so easy)

Info

Complex trades – how to compute them

An interesting conversation I had, explaining people what are the different options when you start doing complex trades and how to be able to value them. So I feel like sharing to everyone.

The problem is that you’ll often need to price new exotic trades as quickly as possible and the question is how to best achieve it. So let’s go through the different options:

  • Use what you have (aka the BS answer (BS = Black Scholes!)). That might sound basic but it will give you a rough approximation (sometimes very rough) of the trade actual value. Far from ideal but if you do have a very limited amount of them, that could work and cost/effort is low
  • Use a proper model/payoff description with Murex. This is usually the best solution but compared to the previous one, there are some limitations: the payoff needs to be covered by Murex, the model needs to be available in your version and the payoff might need to be tested in your version. So it usually results in a longer time to market and a high cost. This is ideal for products you’ll have a bit of volume on and currently being used.
  • FleX. This assumes that you have your own model library and you also have the skills to plug it in into Murex. While there is some effort to achieve it and performance might come as an interesting question, this can be a very valid solution especially if you are looking at maintaining/expanding your model library. If you do not have such a library, the effort/cost might be a killer.
  • Other systems for low volume. There are systems which can return a price for more or less any product. Is the price very accurate? Is the model very efficient? Not really, they’re usually Monte Carlo based but these systems tend to be very good for very small volume and you also get a great time to market. Top that with the ease of importing trade valuation in Murex and have it flying through to report, accounting and you get a very solid solution. Of course, if the volume does increase then you should consider solution number 2 for these payoffs.

So as I had the discussion much before and recently, a mix of the solutions above is the best. Thinking about time to market is quite important and you can then integrate all that into Murex so that all your products are into the same system.

Info

Fx volatility part II

2 Comments

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!

Info

Murex user group

Today a quick post about Murex user group (http://murexusers.org/). As I wrote before, I found it a great idea but it is mostly oriented jobs. Definitely go there and sign up to their linkedin group, if you haven’t already done so.

I tried to give here a higher focus onto expanding Murex knowledge, give new tracks for people to think about and hopefully raise Murex expertise across the board.

But if you believe I could something differently/better, etc… let me know, I’m a firm believer that one could always improve!

Info

Macro buttons – Coding your problems away

Macro buttons. As the name suggests, it is a macro embedded in a button. They’re one of Murex most powerful features as they expand what eTradepad can do by a massive factor. While I can’t give code here of what macros can be (ok I could do examples, but won’t anyway), I’ll describe usages and hopefully inspire you to start using them.

Macros are setup from pricing templates, that’s where you code them. They follow exactly the same code than eTradepad so you can first test your macros via etradepad. The trick with macros is that you usually want to have them triggered on request. To emulate a similar behavior in eTradepad, you can simply put a condition to execute the code if the comment field has a value of 1 (or Go, or Eureka or “Peter Piper picked a peck of pickled peppers” if you wish to see that the comment field is indeed limited in characters). And during the course of your code, you empty the field.

Assuming you can code and what I mentioned above is not complete Chinese to you (or Icelandic in case you’re fluent in Chinese), then your next question should be: but what can I do with macro buttons?

That’s a great question (and the part where I can’t give you code examples) but I can give you contexts as to where I saw them used:

  • Creating a series of transactions in eTradepad by reading a lookup table. Indeed you can easily insert legs via coding in eTradepad and if you find a way of populating a lookup table with the trade data, then you’re golden. This is especially useful when the users need to review/amend the trades before injecting them into Murex
  • Solve a strategy. That’s another good one. The trader defines its strategy (or uses an existing one) and when he needs the strategy to be priced a certain way, the macro can setup the global parameter, set some values and trigger the solver by changing the total value of the NPV.
  • Mirror transactions and perform variations. The mirror task in the workflow is usually the best when back-to-back or hard margin transactions are entered. But it gets harder and harder to configure once you start getting into non perfect back-to-back or when the user wishes to perform manually amendments to the copy. Macro can do that for you, they can copy the leg and do changes before letting the user change what he/she needs.

As you could read, the macros have a wide array of functionalities and they’re not restricted to being a combination of existing Murex buttons. They actually do much more than that. So let’s get coding some macros… Hum, maybe not, you won’t need to code a new one everyday but at least if one user comes to you with a request, they will be another weapon in your war against issues.

Info

Updating SSIs in bulk – How I did it

Practical case: today, someone asked me if I could help: some trades were imported and for these ones, everything has to be considered fine: even if SSIs are missing, future flows have to be ok and not appear as missing SSIs. New trades on the other hand (even if they are on the same counterpart) have to have proper SSIs or return a missing SSIs message.

Putting some dummy SSIs (catch’all) would not work as it would affect new trades as well. Even putting a validity up to yesterday would not work either as future payments from existing trades should not show any missing SSIs error.

So the only solution I thought of: specific SSIs for imported trades. I was not completely sure of the table holding SSIs (I had to confirm it), so I entered a trade with customized SSIs and I put in one of the fields a very specific string (if you’re curious ABCDE, yes I know, very very original). Then I searched through the DB trace file (see earlier posts for how to) to find the table.

The problem I then had was that the table had a field Trade number that was not in line with my trade number (even if I was sure it was the right trade). So I searched the trace file for the trade number that I did not know about and could find it within the transaction header of the transaction. So I then had everything: from my deal number to intermediary reference (in my case it was only 1 but there could have been multiple) to final data.

Turning that into a script was then a breeze (for people curious enough I’m using the same specific dummy SSIs for all the imported trades) and voila! you now have specific SSIs for all imported trades and new ones will fetch automatically from the SSIs assignments.

Is that a perfect solution? Of course not, you can have issues upon performing events but still, it a very valid one.

Info

Market data interface – How to get them in!

3 Comments

In this post, I won’t cover the different types of market data you can have in the system. Think about one and Murex will have it already either natively or through the user definable market data. Today, we’ll focus on Market data interface and the different means to load that data in!

Market data interface – The UIM

UIM does not stand for Ultimate Iron Man but Universal Input Method aka manual input (sounds less fancy that way). While many people would look down at the manual input, it is actually often relevant. If you’re considering a very small amount of data, that requires sanitization and is limited to a few times through the day, manual input is a good solution. Especially when you can set it up so all you need to do is copy/paste. I don’t say you should always push back on interfaces (well, actually I do) but you should actually consider it in many cases.

Market data interface – MDCS

Let’s dive into more acronyms (nothing to do with Marvel DC comics Series), MDCS stands for Market Data Contribution Service. This interface is mostly used for realtime market data feed.

How does it work? You have a service: RTBS (I’m running out of Superheroes jokes (already!)), export, direct publication which published data to a memory : MDCS (also called cache for aficionados). You can query the content of the cache either through XML request scripts or via the monitor.

The data is structured into multiple pages, with multiple nicknames.

From there, you can push that data either to database via a processing script. You can retrieve it via XML requests (note to all tinkerers: do not use that service as a way of distributing market data to all bank systems, you’ve been forewarned!) or have Murex sessions accessing it via activity feeders. Activity feeders give you the opportunity of choosing which type, page and nickname of market data can the session access.

So as you should have understood now: MDCS is the realtime service in Murex. And it is better used that way. For end of day, you should rather stick with the one after: MDRS.

In case of issue with realtime, you first need to check via monit or xml request scripts if the market data in the cache is properly updated. Which one to use should not even be a question as monit is easy and user friendly to use. If you can’t get the monit password, let the one with the password handle the issue!

If the data in the cache is properly updated. Your issue comes then from the activity feeders. You can restart them if required after trying with a new session (you should get an error message if the session can’t connect to them). If there is no error message, no realtime, check that you have indeed assigned an activity feeder to your session.

That’s the basic debugging of MDCS: check the cache, check the activity feeders and check the user settings.

Market data interface – MDRS

Market Data Repository Service. First of all, some good news! XML request scripts are almost identical to MDCS ones.

MDRS lets you retrieve and update the database directly via XML request scripts. It is effectively more efficient than MDCS-Processing script as you do everything in one go without having a stopover in the cache.

MDRS is actually pretty robust and never had too many problems with it especially if you read properly the documentation AND put the right tags in the right order. The usual trick with MDRS is to first query some market data to get the structure of the XML. And then add your Update command and modify the values as desired.

Again, Murex role is not to be the Market data repository for the whole bank. Murex primary role is to provide pricing, risk, processing services not centralize the bank market data.

Debugging MDRS is usually quite simple as you get an answer file and a log file whenever you kick in the XML script. Just fix as appropriate and you’ll be good to go!

 

That’s the 3 means of getting data in Murex, note that the services are always improved to cater for newer type of market data and especially when you’re working on new type of market data, you need to ensure that MDRS/MDCS properly support it. Otherwise, the UIM will always work!

Info

Murex assistance or handover, how much information does one need?

I had that conversation last week: in order to provide Murex assistance, how much information is required?

Murex consultants (from Murex) providing support usually don’t need design documents, they can be useful sometimes but most of the time they will intervene on single specific problems. Access to an environment is ample information and they will dig in to retrieve whatever information is necessary. If you ask them as to why a crash is occurring, a task stopped working or a formula is not triggered, they do not need to look at the full picture. They can only focus on the single issue and all the information will be at hand (remember that Murex gives usually easy access to all the information used to produce a result: rate curve will give all pricing details, formula debugger will show code execution as well as variable values.

The other reason is that usually Murex consultants are supporting multiple customers and reading through the design document would take a significant amount of time while yielding no direct advantage to answer questions.

On the other hand, internal support team members  need to read the design documents if they haven’t been involved in the project. The design document will effectively describe the big picture and explain how everything fit together.

But thinking it over about the time I was supporting different customers at Murex, we would either ask the customers when something seemed not right. Sometimes it would indeed be a design decision and it would not make sense to go against it.
An example: few weeks ago I wrote about rate propagation and basically KMQA/IS is the most logical choice. But you will find customers using KZQC, especially in the Fx world, and this is perfectly normal.

Of course, there is a real added value for the Murex consultants to know about the design choices. This knowledge could come from reading the design document or more often from frequent support and proximity to the customer. And I was indeed more efficient in my efforts when I clearly knew why such a configuration was selected.

Does this mean that Murex consultants should read and go through design documents? I don’t think so, except if they are supporting only that customer (or very few customers). Their job is to provide information about the software, help you get most of it and solve your issues. But the internal support team can provide them assistance and guidance as to why a solution would not be suitable in the customer’s context. Good support is always at the encounter of Murex knowledge and customer configuration knowledge.

Info, Tips

SECDATA, BONDDATA

6 Comments

Secdata, bonddata are two very useful functions in Murex for retrieving security data, date of next coupons, yield to price conversion, etc… The problem is that they’re not always easy to use. So get your documentation nearby as you’ll need it with these functions.

How to use them?

They basically require 3 inputs: (string,date,string). The first string is the description of the security you wish to use: Market and security label most of the time and you need to add the expiry label for futures. You need to separate the market and the security with a comma in the string.

For instance “Market,Label” works, “Market”,”Label” would basically make Murex believe that you’re trying to input “Label” into the date field.

So usually TP_SECMKT+’,’+INSTRUMENT would give you the right argument for the first string.

For the date, that should be no problem! 🙂

For the third one, refer to the documentation and you should be all set.

Alright, so now you have a working secdata (or bonddata) function and it all seems good. Unfortunately it is not so simple and here’s the SECDATA pitfall:

If you call SECDATA or BONDDATA while parsing non security instrument, it will return an error message with something such as XXXX security not found (where XXXX is the label of your instrument). This is especially the case where you have swaps, deposits, anything basically that is not security related.

If you try to use an IIF statement to avoid the problem, the error message will pop up anyway: IIF(TRN_GRP==’BOND’,SECDATA function,0). The reason is that Murex evaluates all arguments of an IIF statement even if the boolean is false.

So, are you doomed with error messages? No! You just need to create another horizontal field which will become the first string argument:

H_SECURITY –> IIF(TRN_GRP==’BOND’,TP_SECMKT+’,’+INSTRUMENT,”).

And then you use the IIF statement again (especially if you need to return something specific when it’s not a security):

IIF(TRN_GRP==’BOND’,SECDATA(H_SECURITY,date,desired functionality),0)

So that’s how you can call upon SECDATA and BONDDATA when loading a portfolio not entirely made up of securities. This being said, I would recommend to look at already existing fields in the dynamic table to see if you can do without SECDATA or BONDDATA. Accruals being negative to see if the bond is in ex-div, MP_UPPRC for the current price, etc…

If you faced other problems or if you want to share any other trick with these 2 functions, feel free to!

Info

Leaving Murex… Things to consider

Leaving Murex, that’s often a topic that comes back at the coffee machine. I think it is in people’s nature to consider all options and ensure that they always keep doors open. But some are more willing to jump ship, I think it is important to know why you want to leave and consider what your next work place could bring you.

1. Money and work conditions

This is maybe the least relevant. Murex offers great salaries and working conditions (paid leave or other benefits). Usually people do not want to leave as they believe they won’t get as much elsewhere. Except if they decide to go for contracting jobs, which sacrifice job stability for higher incomes.

2. Career potential

This one is already a little more relevant. Murex offers great career prospective but as the company is relatively flat in structure, people can hit a cap with little perspective of going further up. Mostly career driven people tend to use Murex as a stepping stone and would not stay for long in the company.

3. Challenge

This might happen actually, after a long time in a company, things become routine. As discussed in a previous post, Murex people enjoy being challenged. In a way, we could call this one intellectual boredom. I think it is actually a frequent cause for departure where people need the thrill of discovering something new.

4. Bad atmosphere

Because of Murex quite lengthy recruitment process, I think it is quite hard to get to a point where the atmosphere within a team or with one’s boss is too hard to bear. If it does happen, it’s best to tackle the problem directly and see what can be done to improve the situation.And if it can’t be done, I’d advise at changing team rather than changing company.

This should sum up the reasons that would push one to leave. Note that many Murexians are actually quite pessimistic about their chances of finding a job elsewhere. Given that most are actually quite brilliant and highly capable, that’s a bit sad.

When it comes to opportunities they have usually 3 main destinations:

A. Customer side (Banks, funds, …)

This is quite common especially if the person has been working with the bank for some time. Banks offer a wide range of job opportunities, along with long career opportunities. As the underlying knowledge is the same and as Murex consultants have very desirable knowledge for the bank, it is actually a great match.

B. Consulting firms

Second option is to capitalize on the Murex knowledge and move on to a consulting firm. More responsibilities, potentially more independence with a shot at being partner are the most frequent reasons for choosing that destination.

C. Other software firms

This is maybe one of the least obvious ones. I believe Murex is one of the best software vendors to work for. Going to another one only makes sense if it means a jump in career or if their software is very capable on a domain that is your passion/expertise. Otherwise the reasons that pushed you to leave Murex are likely to be even stronger there once the honeymoon period is over.

There are other destinations but they’re more on a case by case basis and very specific to people.

What about you? Did you leave Murex? Why? Where did you go? All comments and feedback welcome!