To ask questions, feel free to use the forums, much easier if everything is in one spot!
Welcome to 2016, a very promising year for all your Murex experts out there!
Holidays time here! May your EOD and EOY run without a glitch!
Last post of the year, see you in 2016!
Hum, probably not the best title in the world. But that’s the truth: for any Murex support person, the formula debugger has become very hard to live without.
What is Formula debugger?
I’ll have to assume that you are from another planet . The formula debugger is THE tool to use whether you are actually working (so useful) or just pretending (looks very serious and on the scale of Lazy Fridays Hangover I am Coming to Work but I am Still Asleep (LFHICWISA), it scores a 9 (only beaten by the Excel screensaver)).
As the formula debugger name could have led you to believe: It is used to debug formula. When you turn it on, whenever you are using functions which calls the pretrade, you will see a pop up with all the formulas executed as well as their resolution.
How does it work?
To turn it on, it is very simple, from your enduser session, do Help-Monitor-Formula debugger. You will get a pop-up stating: Formula debugging is now on. (do the same steps to turn it off)
Now, very simply price a trade from ePad, or whatever you want to do, and a pop up will come up showing you the different formulas executed.
Even better (it’s like a double rainbow) if shows you the resolution of formulas. For example (first line is my formula, second one is the resolution details always starting with //)
IF fLFHICWISA>9. THEN sResults:=’Better than Excel Screensaver’
// IF 8.5>9. statement result is FALSE
You also get the content of the variables when they are assigned:
// legGetString(pointer,”Counterpart”) returned “HSBC”
And of course you also get the name of the formula being executed so you can check the formula you have been working on is properly being used by the pricing.
And the whole text is exportable to Notepad or you can also search through it.
Any more tips?
You are getting quite demanding, but I actually have 2 more things:
One is the obvious Clear button, to make sure that you only have as debugging output what you need to focus on (between 2 tests, just clear the window)
And the other one is to couple with the action button wf:XML refresh in the strategies/notpads (right click on the folder,Properties, Actions. Then you can add a button wf:XML refresh. Usually it is the last one in the list.
This button lets you reload all the changes you made in the formulas in a CONFIG session without having to exit eTradepad and re-enter.
Time for you to get cracking on new strategies and formulas!
Just to finish this week with a bit of lighter note: let’s talk about something actually quite painful in Murex: log files.
While you will be able to find everything you need as logs in Murex if someone helps you, to browse the logs for errors makes Indiana Jones job sort of trivial!
Indeed, Murex produces a lot of logs and unfortunately not always as detailed as you would have liked or sometimes not where you would expect. So here are few advice to get through them.
- Most logs are under the… logs directory. But not all of them! find and grep will quickly become your best buddies on Linux/Unix to find where are the files.
- And once you enter the logs directory, your first ls will bring out a massive list of log files. There are many of them and sometimes even in subdirectories. You could sneak in your porn folder in there, no one would ever be able to find it. Much safer than your accounting 2014 folder on your PC!
- To navigate through the logs folder, again find and grep (I mostly use grep myself but that’s just me) are your friends.
I would say that most of the time, you should only go through the logs to search for something specific. Mxmlexchange crashed? Perfect go and search files with mxml, that narrows the scope considerably. There is too much noise and so many different logs that you cannot ‘just look’ at the logs to see if all services are running ok. The best example is if you have garbage collector on java turned on to verbose, then you will get loads and loads of high quality log: GC [5K -> 2k] (about 2 million times). I am waiting for an answer if I can turn these off. They make reading mxmlexchange logs extremely painful. Again grep is your friend, remember that you can use the -v option to filter out data from a file. You can also do grep on grep : grep ‘text to search’ filename | grep -v ‘string to filter out’. Very very useful. If I ever find the grep author, I owe him a beer. (well, probably more a truck of beers, but we’ll start with one).
Logs of logs? Probably the best would be to have some logs of logs. You just extract the logs you actually need to check and make a new log file, that would be probably the best way. I am sometimes considering as a solution.
Of course, some of you would come back and reply ‘what about errors.log?’. An example of meta-log, some services also put their errors in errors.log. But not all of them and you still get a lot of noise (looking at you RTBS). I’d stick to my grep for now.
Just for fun, I am wondering if I should print out all the logs generated by Murex in one day to show people the amount of data it creates. Maybe I could turn it into some cool ASCII art or that would replace my stock of wood for winter… Not sure and as my emails say ‘Print responsibly”, I doubt I will actually do it!
Using Gogond’s question about market data import/export : I’ll give today an overview of all interfaces (well, all might be oversell as there are quite a few, I could have written most of them but that doesn’t sound as good as all).
The first one and probably the most use:
I. The Universal Interface
…. your hands. Sorry about that! But indeed manual action on market data is actually quite useful and probably your first stop. All market data can be copied/pasted from/to Excel. Everyone knows how to use it.
If one complains that not all market data is in the same place or using the same format than their spreadsheet, you can then use the market data viewer. You need to define a loader (market data loader to be exact) which tells Murex which query you want to run : Fx vol, rate curves, etc… You can then look at your market data from a viewer point of view. Very useful for looking at all rate curves at once for example. Even better, you can still copy/paste making it a very nifty tool.
I would also add that in pricing (eTradepad) or simulation, you can also bring viewers or popups of market data and modify them live to perform what-if scenarios.
So don’t discount the manual action as it is very simple to import/export market data manually and often people want a visual check at the same time. Two birds with one stone!
Or Market Data Contribution Service. MDCS is basically a memory service (often called the cache) which holds XML representations of market data or fixing data. MDCS is used mostly for realtime, you can load into it XMLs (usually called MDML for market data) using either RTBS (real time interface to Reuters, Bloomberg or any other provider), your own XMLs (Murex provides a series of scripts to query or upload into MDCS) or even Murex DB (you can export Murex market data into MDCS).
You can define multiple folders in MDCS so you can end up with different rates for a same instrument across these different folders. These folders are called users but I found the name a bit misleading as its main purpose is to let you segregate your cache data.
The cache is also actively retrieved from sessions (using activity feeders) to give live rates. The advantage of this method is that sessions are notified when new rates are available and you don’t need to save this data in DB, you can simply let the activity feeders push or retrieve that data to your session.
While one can also export data from the DB and then download it from the cache, that would not be the most efficient way to go about it as there is a much better solution:
Or Market Data Repository Service. Interestingly, MDRS is a pure interface, it does not hold any data into memory like MDCS so the label repository is a bit misleading.
MDRS lets you query or update the Murex DB directly for market data in a very similar manner to what you would do when querying or updating the cache.
Note that for both MDCS and MDRS you can query on stored data (like market rates, correlation, etc…) but also on calculated data such a ZC rates, or total vol (if you upload spreads). For calculated data it is limited though, you will not get any interpolation for instance.
So if you didn’t find what you were looking for, hopefully the last one will be of some help
And then you have a fair bit of old, not so used anymore interfaces some of them are being retired or are clearly in End of life mode meaning that Murex will not even provide support for them.
Among these you find the good old ascii import via reports, this was the historical import way (and for a long time the only automatic one).
You will get also the menu item Market data import/export. It has the advantage to be graphical compared to MDRS but the data you can get from it is limited and except if advised otherwise by Murex people I would strongly recommend to skip it and stick to MDCS/MDRS.
And one nifty command I really like is the export daily discount factors. You will find it at curve level and to my knowledge it is only available from the GUI (you can script it with a macro though). It basically dumps into a file all daily discount factors for a given curve. In a way it is more reliable than the previous method which consisted in pricing a trade with daily cash flows, make it discounting on the desired curve and then copy all the discount factors from the evaluation flows.
I will stop there for my Miscellaneous bag as I feel I covered the main ones, you have of course processing script to copy data from one data (or desk) to another but that’s no longer really an interface. Of course, if you are outraged that I forgot your favorite interface or anything, feel free to comment and I’ll adjust!
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)
Quite busy at the moment, running low on bullets and might have to revert back to chainsaw soon. We’re reaching a critical stage in the project and not so much time left.
So I’ll update the blog when I can till the project is finished (should not be much longer). Questions and so on should be fine to answer.
And yes, this is quite old school but good memories!
Thought about this one and follow up on some questions I answered, I thought it could be of interest to some of you.
Repos and Buy/Sell backs used to be quite difficult to work with, bugged till effectively Murex reworked them into what was called the “new module” (agreed it sounds a bit like the promised land!).
The repos (I use that word loosely to cover sec lending, BSB, repos, etc… too much typing otherwise) are first defined as a template (similar to generator): you define some basic rules knowing that what you don’t provide will be provided by either the bond you choose or by the currency you choose. For instance, if you don’t input a start delay, the bond settlement delay will apply instead (usually 3OD, so you will need to define the start delay as most repos are start 1OD or 0 day).
Once you’re done with the template, you can then start pricing them and inputting them, it is simple to use, got everything you need to have: sec for fee, haircuts, etc… It pretty much looks like a swap: physical on one leg (bond, security) and cash on the other leg.
Open repos? Not a worry, just enter open as the maturity and that’s it.
I know it sounds simple but it is actually. Very simple to use, pretty much like a walk in the park.
And finally repos need bulk event and bulk events Murex has: global reneg (rate changing) either as absolute or as variations (e.g. 25bp for all your repos), termination, increase/decrease nominals, etc… And all is integrated in the Murex workflows.
Again, I know sounds simple and it is (I guess they could put that in a brochure! )
But the best thing about repos is a much more recent new transaction type: the basket repo.
This transaction is incredibly flexible and opens the door to so many opportunities, well, I just hope your repo desk is big enough! The basket repo, as the term could suggest, mean that on the first leg you have a basket instead of 1 line. Best of all the basket can be made of bonds, equities, commodities or cash, completely flexible. Input is done through a viewer, price, yield, haircut and quantity can be input for each line and you can check the valuation versus the other leg of the repo. You can even copy paste directly from Excel.
The specific event called repo basket substitution basically lets you remodel the basket the way you want: you can change quantity, remove lines or add new lines. Of course you can also use the other repo events.
It is a great tool for collateral management or for triparty repos where you can import the actual position at the end of the day.
In summary, before, repos in Murex meant you like making your life a challenge. Nowadays, they are very simple, very easy to use with most if not all functions your repo desk will need.
Hum, this article definitely sounds like advertising, which in a way is true: I really like that module!
Shazmd asked a question through the forum about how to make a report giving out PL as of 3 dates.
There are couple of solutions to this question and which one you need to use is totally up to you 🙂
First thing to keep in mind is that when people mention reports it should not always equal datamart. For instance, simulation is a live report showing the risk and which could fetch data as of couple of days in the past.
Trade query is also in a way a report, with no calculated data. So it is important to understand what is the end user after so you give him/her the most appropriate solution.
- User definable P&L notepad
This first solution is probably the simplest and is perfect if the request is just a one off that would not repeat very frequently. User definable notepad is a dynamic table based on PL, there is just a direct menu to access it. So if you search for it (it is under middle office, P&L related procedure (or just type in the search notepad)) and get into it, Murex will ask you to choose a filter. Space bar on the default one. You then see a filter screen. You have 3 dates you can choose from (Inception means not calculated) and you can pick a portfolio or any other criteria. The data for the 3 dates will be computed when you validate the filter.
You then get a matrix will all the deals selected and the data you need. Just change the view to be what you need using Tools-View and choose the columns which make sense. You will see some fields available 3 times, they are the data computed as of the 3 different dates. Just change from description to field name. The field ending in 0 corresponds to the data for the first date selected, the one ending in 1 corresponds to the data for the 2nd date selected and the last one ending in 2 corresponds to the data for the 3rd date selected.
You can then copy paste (ctrl-shift-C to copy all lines) the results or export them from the file menu. You can then work out the data in Excel.
Datamart for 3 PL dates is the 2nd solution. It is easy to re-use and the format will be up to you.
First of all, you need to choose which engine to use for computing the data (note that it is using the same code underneath but there could be differences in usage). The first one is a dynamic table of type PL (TRNRP_PL). You need to define one and choose the fields you want. Remember that you can test a dynamic table to check if the content is ok. The dynamic table should produced only 1 set of PL result not 3.
Once you’re happy with the dynamic table, you need to wrap it so that it will produce data into the datamart. To do so (and in high speed): you will need to define a feeder and then inject that feeder into a batch of feeders. The feeder will go through creating a table in the datamart and attaching data to it (data coming from your dynamic table). When you define your batch of feeders make sure that you can have at least 1 set per date so that data in the datamart is historized.
Just run the batch of feeders as of the 3 dates you need to compute (you might need to amend the global filter within the batch of feeders to choose which date). Once your datamart is populated with the data (you can query it and check by SQL for example). You need to build an extraction to retrieve that data. The extraction will be an SQL piece of code which you can make fancy by letting the user choose the 3 dates he wants to query on (or you can hardcode it).
Finally, you need to format the output, csv file format requires no work, but if the user wants to look at the results on screen you’ll need to have a viewer with your field to be nicely formatted. I usually don’t recommend to format the excel file via the viewer as dates come back sometimes not as wanted, or fields formatting might require extra work.
And that’s it you’ve got a datamart with your 3 dates. The first time you will do it, you will get it wrong and it will take some time but once you start getting the hang of it, it becomes much much smoother.
And yes there is another option: simulation. Simulation is a live report showing live position, cash flow, PL, etc… In simulation, build a viewer to show your PL with as much breakdown as you would like.
You can then define a dynamic table based on that simulation view. Create a feeder and batch of feeder on top. Then compute the PL data as of the 2 days in the past you need. Simulation will always compute PL as of today.
Then back in your simulation view, you can add more of the same PL fields and right click on them, output settings and select stored data. You can then choose to retrieve the data from your datamart directly in simulation and display either the datamart number or the variation with the current data. You can also choose to retrieve based on a shifter (like the day before, 1 month before, first day of the month, etc…) and you can do it as many times as you like (and as you have data of course!).
In a nutshell, that’s how you can solve your problem of a report showing PL as of 3 dates. I am sure you will have tons more questions, feel free to experiment, check your environment for already existing examples and ask here if you’re stuck!