Tag Archives: how to

Tips

Reconciliation or rec – what should I do for my trades

Whenever migrating or updating, one task will consume a fair bit of manpower: reconciliation.

When doing trade reconciliation, the following is to be checked:

– Financial trade details reconciliation. This is usually the first one as it will be used afterwards as the key for reconciliation. In that task, you ensure that trade numbers, deal type, price/rate, portfolio, etc… all the data considered financial is correct.

– Cash flow/P&L/Sensitivities. You normally need to rec all 3. In my experience, it tends to be better to start with P&L (less figures to check, 1 trade 1 number). Then move on to Cash flows, depending on the DB side, you sometimes need a very good tool capable of handling loads and loads of lines. Finally sensitivities. For that one, I would recommend against trade by trade reconciliation. It is too demanding, use a top down approach.

– Non financial reconciliation. This one is a bit up to you. If you have some reports which extract that data, this reconciliation could be considered done. If you do not reconcile it (or even fully) this is the kind of data that can be easily updated post go live.

Reconciliation is a very heavy task. It is demanding in manpower and you need people comfortable with the both applications (the old and new ones). It is as essential to have a good tool capable of assigning defects to trades matching a certain pattern and to re-apply the root causes when performing another rec.

While I don’t think anyone really enjoys doing reconciliation and browsing through lines and lines of breaks, it is an excellent exercise. I often included more junior people to the task as it gave them a chance to go through the different screen, understand how different figures are being calculated. Of course, you cannot leave them alone to do it but they can contribute to the effort and afterwards they will have built a good understanding of the issues and the application which is perfect if they need to support it going forwards.

Feel free to share your tips and bits about reconciliation!

Tips

Exporting a browse screen – The best way

2 Comments

Murex has many browse screens: trade query, accounting journal, payment query, etc… And associated with these screens comes the question: how do I get that information outside Murex?

There are multiple ways of doing it but there is a first question to answer: what do you need it for?

Exporting a browse screen on a regular basis

If you indeed after a browse screen exported on a regular basis, a report is probably the better solution for you. You have multiple options:

  • Rebuilding the browse in a viewer and making a dynamic table on it (I would not recommend that solution expect if you have another use for the viewer).
  • Re-selecting the fields you need from a standard TRNRP_PL (or whichever appropriate) dynamic table. This is good if you’re after some calculated fields which are not always available in the browse directly (How many times did I get the request to have PL figures along with the trade query)
  • Building the report using a copy creation of the table your browse is based on. It might not work in every case but for trade query it does work fine. Just reselect the fields you need from the table and/or the related tables and you’re all set

Reports can be automated during EOD and produce data automatically.

Exporting a browse screen on an adhoc basis

This one is probably where I can help you most.

There are 2 main ways of doing it. The first one is to use the classic windows shortcuts: Ctrl-A (select All), Ctrl-C (Copy) and then Ctrl-v (Paste) into excel/word. Good old classic. Never disappoints and always work.

The classic way is great especially if you have a limited amount of data to copy. It gets trickier when you start to have multiple pages (usually more than 300 lines). More Murex proficient people will tell you to use Ctrl-Shift-C and voila, all columns copied regardless of the number of pages. While it does work, be very careful.
One evening, I was leaving a customer site a bit late and could see someone still at his desk. That person needed to export that data and used Ctrl-Shift-C and the pop up window Copying was still there. The problem of Ctrl-Shift-C is that it loads all the data from the server to your computer clipboard. If the amount of data is too large for your memory, the java process might run out of memory and while you believe something is still happening, it is in complete limbo. And you don’t want to waste your evening because of that!

So here’s the better solution when the amount of data is large: File-Export… The export data lets you export all data to a file (on your computer). You can choose to export all pages and it will do it by itself leaving you with a csv file in your client directory.

Somehow, while this function is much more reliable than Ctrl-Shift-C, it is quite unknown. Maybe because nowadays everyone copies/pastes everything!

Tips

eTradepad – 10 useful tricks

eTradepad is a great tool, it lets you price, build strategies, strip pricings, compare prices and save quotes for later use. The tool is very rich and there are few things to know about it if you want to maximize its usefulness. Here’s my 10 things to know about eTradepad for a better you!

1. Finding a field name in eTradepad

Let’s start with the basics. When writing code, sometimes finding a field name is not obvious. Of course, one could always use the right click-Field-Plain name but you can’t copy it. So I prefer to use formula editor-customize on the field to have the field name and its string directly in the formula editor

2. Comment code

This is very very important: always comment your code. Especially when you put in a workaround or something not obvious. You could think that it will guarantee your job but it will effectively guarantee that you won’t remember your code in couple of months. And that if you go on holidays, people will need to get in touch with you to understand what is happening

3. Macros

You can create macro buttons in eTradepad. You basically attach some code to them and you can then add them at the bottom of your screen. Macros are very useful when the user wants to have some things changed all in one go

4. Workflow refresh

The button to have when doing pretrade workflow. (it sits at the very end of the list of action buttons: wkf: XML refresh). This button refreshes the pretrade code and applies it. So rather than starting a new session every time you need to try out some pretrade, use that button

5. Formula debugger

Hopefully everyone knows about it now but the formula debugger (Help-Monitor-Formula debugger) brings a popup with the executed formula as well as boolean statements and values loaded into variables.

6. Viewer

You can turn your etradepad into a viewer. The look would be like a pricing matrix. For example option maturity on the top, swap maturity on the left and premiums as the output. The development is relatively recent and can be triggered from the external settings of the notepad you’re in.

7. SCF … Don’t

SCFs are a no go in eTradepad. If you do need to use them, test, test, test and re-test. They are not all supposed to be used in the context of eTradepad. Choose an additional flow or any other solution instead of using them

8. Text area

With Mxpress, Murex did a great job at educating people to use the text area. It can give a nice text description of the payoff that the user is currently pricing. It can also be copied into the clipboard if the info needs to be sent to customers

9. Archiving

When awaiting for a customer answer or to share a pricing, Archiving is a great tool. It lets you save a pricing (either privately or publicly) so you can re-use it for later. It is much lighter than saving a dedicated notepad for each pricing you want to keep. In terms of maintenance, it is much easier to clean old archives as opposed to old notepads

10. Excel paste special

Really love this function. If you’ve got a correctly formatted excel (and preferably a notepad with horizontal display), you can paste from Excel into Murex creating new entries (aka new pricings). For that you need the action Paste Special and choose to create new lines. Very useful if sometimes you need to price a set of trades external to Murex.

What about you dear reader? Was this useful to you? Any other tricks to give away?

 

Tips

Reconciliation, how to get it right

Reconciliation is the bane of upgrades and migrations. It’s hard work where one needs to go down into details, find patterns and then find solutions. Plus you always have the stress that something new will emerge.

I can’t cover all types of reconciliation, I will focus (at least in this post) on trade reconciliation between 2 versions of Murex (be it upgrade or migration).

To get valuation (risk and PL) for transactions, you need to have static data and market data. Static data is usually very stable and I would recommend not to do any reconciliation on it. If it breaks on an instrument, it will show clearly into the reconciliation report and you can focus on it straight away.

Market data is a different story. It is usually very easy and quick to check: open both environments and check the calibrated values for curves (rates, commodities). For volatility, if you’re using a volX, check that the calibrated values are identical. Check that normal/lognormal and price vols match if you do input your volatility in one nature but consume volatility of a different nature in your models.

When rate curves are not returning the same values when calibrating, you will have a total break on all deals using that curve. Usually the difference is actually quite small (lower than .0001) so with a correct tolerance level in your checks, you should match results easily.

You can then move to trade reconciliation once the market data is ok. To do so, the usual practice is to run dynamic tables on the trade sets (of different types: PL, Cash and sensitivities), put in exclusion criteria less than $100 ignored, .01% ignored. Run the tables on both environments and then using sql compare both results and output breaks into a table.
There are quite a few solutions to do this job but it is actually quite straight forward up to this stage.

Now you have a long list of breaks (and missing entries!) that you need to reconcile. There is no shortcut and you need to get moving. I usually break down by deal type and instrument when relevant. Start then with the largest breaks and try to understand why the 2 are different (market data, change in customization, improved behavior, etc…). The important bit is to find the root cause and with experience you find it more easily.

Then you check if your root cause applies to other trades (usually it does). If it’s an isolated issue, bad luck, move on to the next trade. If it is not and other trades in your list seems to have the same issue, you need to establish a rule. That rule will flag all trades with the criteria to that root cause. There a good knowledge of SQL (and Murex data structure) often helps, if you don’t/can’t, 2 options:

– Write down the root cause of the issue and move on to another trade. Once you have enough root causes, check with someone more knowledgeable to teach you how to build your rule.
– Run a dynamic table outputting the data you believe isolate reconciliation breaking trades from others. In this later case, you might waste a significant amount of time building that dynamic table and it might not even work.

Finally comes the solving/accepting part. Some issues have to be accepted as they’re enhancements or correction. Some others are regressions or changes of behavior that will require correction. Sometimes a simple configuration change can fix these issues. Otherwise, you might need Murex help to figure it out.

The important part is to automate it as much as possible and end up with rules that you can re-use in the next reconciliation re-run. Ideally, the solutions can also be automated and make your reconciliation go smoother.

Now, maybe the most important bit: never underestimate reconciliation. It is a difficult task especially if you want it done well. It is hard to estimate how long it will take and the criteria, in my experience, to take into account: time difference between the 2 Murex versions, complexity of deals, exotic and yield based bonds (lasting scars from these).

Tips

Spring cleaning, Purge the database

Spring cleaning, I know I’m a month early but purge is an important task and sometimes you need to make sure it is adapted to your environment and needs.

Purging the database will let you keep the database growth under control and ensure that you get the maximum performance out of the system. But there’s often a fear that purging will result in data loss and quickly you find yourself with massive retention periods, 7 years for trade,  2 years of daily market data and all logs.

The first to keep in mind: Murex is a production system for trading and processing, it is not a data repository system. You need to keep it running in top shape as to maximize the benefits you get from the system. If you need to retain some data stored in Murex, export and store it on your own system. It is much cheaper and more appropriate.
This might sound obvious but when talking about purge, regulation is often the first topic that comes and it blocks any further discussion as long as a solution for storing all the data to be purged has not been implemented.

Once everyone is convinced of the importance of the purge, there are multiple items to purge by importance:

– Documents and their entries (usually ranking at number 1 in DB usage)

– Market data (normally ranking at number 2)

– Trades

– Logs

– Static data

– The forgotten ones: view, layouts, filters

Documents

Purging Mxmlexchange is actually quite straight forward and is done through scripts provided by Murex. Just be very careful with the scripts and ensure that proper testing is done on test environments before deploying to production.

But if you test it properly and only purge the intermediate documents, it is quite straight forward without surprises

Market data

Market data is made of 2 parts. The visible side of the iceberg where you purge market data for dates you no longer need (good practice tends to let people keep the month end only for older dates and daily market data for few months (1-3 depending on your aggressiveness). This can be done through the GUI if you want, quite straight forward.

But there’s also a second part of market data  purge which helps a lot: expired instruments (read Bonds and listed options mainly). By default, Murex automatically copies all market data entries from today to tomorrow as part of EOD. This automatic copy means you also have entries for expired listed options (ETOs), futures or bonds which keep being rolled. It might not sound like much but ETOs can quickly snowball especially if you trade very short dated ones such as intradays and overnight. Here, Murex can provide you with a script to clean them out. Symptom for this second one are tables such as MP*_GLOB and MP*_PRIC being large in size.

Trades

Trade purging makes sense especially when you do volume trading. The trade purging is done through the GUI (very important) and in such a fashion that all purged positions are getting aggregated to avoid any jump in cash balances.

The trade purge occurs in 2 steps: a logical one, where the trade is no longer read for reports and simulation but is still present in the database. All its contributions are stored and aggregated with other purged deals. It can be undone if required
The physical purge will effectively remove the trade from the system, you cannot anymore query it and it cannot be reversed.

Position and cash balances testing needs to be performed after each purge step. After the logical purge, it is the most important as Murex will no longer evaluate the trade but read directly its stored contribution. After the physical purge could almost be skipped as it does not affect anymore the aggregated results, it is simply removing the unused trade records.

Trade purging depends on the trade complexity, simple spot forwards can (and should) be purged much more aggressively than more structured deals

Logs and audit

Murex will give you the scripts for these, purge as requested and make a copy if you feel the need upfront. They don’t consume much space but clean logs make browsing through them a lot easier!

Static data

I am actually an advocate against purging static data. Murex often references static data under the purged deal contributions or in other places and removing them, will remove that link for Murex. One could always try to fix all the problems which ensure out of it but in my opinion, it is simply not worth it. The amount of problems generated (and which could come later during or after an upgrade) is not worth the small amount of DB it occupies.

Filter, layouts, views, etc…

These items should not be purged per se but should be kept under control. Restraining users from creating, duplicating is probably the way to go.
To clean them up would probably have not much of an impact on the database but you risk that an EOD report or a process would fail. Except if you have kept a very precise list of which items are used by what process (and if you did, kudos!), you probably have to leave them where they are or start a massive campaign identifying and decommissioning the unwanted ones.

 

In summary, if you concentrate on the top 4 items of this list, your DB should grow as expected when the hardware was planned with Murex and performances will remain optimal. Just keep an eye on the DB usage by table and if something grow too quickly, Murex will always be happy to sort you out!

If I forgot something or if you feel like to add something, please feel free to!

Tips

Murex viewer – My 10 tips

Murex viewer, I still remember when it started being available in the very early production releases (2003 I think?). Concept seemed fantastic but it still needed to mature.

The concept is simple: rather than showing hardcoded/static screens to show results and/or to perform actions what about letting the users build their own and re-arrange them as wanted. The viewer was born with functions very similar to pivot tables. The source data being everything Murex static data and all computed data. Add filters, calculated fields, conditional formatting, linked views and you end up with a very rich environment.

Icing on the cake, Murex viewer comes with some preconfigured layouts simplifying everyone’s work as one only needs to modify as required. It is also a showcase of examples where one can see what can be done and how to try to harmonize the views together.

But with such a powerful tool, you won’t master it on day 1 (not on day 2 either). So let me give you 10 tips to become a pro with the viewer:

  1. Use the search function! The size of the data dictionary is staggering. Worse, sometimes fields appear multiple times and do not always display the same value (reason is usually that some fields are asset specifics). Ctrl-F and F3 are your friends. And remember that the search function works only one column of the data dictionary at the time
  2. Don’t over commit. Often I got calls from support teams unable to achieve what they wanted in the Murex viewer. Some functions and/or data might not always be available. Except if you’re 100% sure it works, don’t promise you will deliver it to the enduser
  3. GMPs are your friends when you need external data! This ones always come sooner or later when the traders want to access extra data/inputs. For instance, they wish to set a date limit for short dated bonds. This date could be entered through GMPs (rather than hardcoded). Best of all, when using simulation, the GMPs will be available in the loaded market data for easy access/input
  4. Viewer is not eTradepad! Typical example of being carried away, the viewer is a tool for displaying data and not a calculation engine. It is easy to be mistaken when opening the formula editor as it looks like the eTradepad formula editor but they are different!
  5. Be careful with your colors. This might sound obvious but actually I tend to find it the hardest part of the Murex viewer. When I was preparing demos, I usually ended up spending more time on the colors to use rather than on the data itself.
  6. Endusers should not be able to modify views. This is actually quite important. One would believe that giving everyone the right to create their own would alleviate the support team workload. Quite the contrary. The number of views will grow out of control and supporting users using different views is a nightmare.
  7. An extension to the point above: Try to limit the number of views in the system. As much as possible try to rationalize the views. For support it is much easier when the number of views is low. For upgrades, it is also less work.
  8. Try to limit the number of views on screen. Murex has a client-server infrastructure and most calculations are done one the server side. But the rendering of the screen is done on the client side. If you start to have many views with a large amount of data, you might end up with the ugly out of memory java error.
  9. Item formulas are great but don’t abuse. Items formula lets you use calculated fields as line breakdowns. I often ended up using them when I needed to aggregate 2 different breakdown fields.
  10. New functions. That’s the best part about the viewer. Each new Murex release comes with new features be it graphical or within the viewer, always inquire about the novelties are they’re usually great eye candy!

So here are my 10 tips about the Murex viewer. What about you dear reader? Any other ones?

Info, Tips

Murex performance – the chicken and egg story

Murex performance is often in the spotlight: how quickly can Murex do XXX or create YYY. (Replace XXX and YYY with your choice of tasks)? The problem is that the list of requirements between 2 customers varies and results in very different timings.

So to take out the main question first (if you’re the sort to prefer short answer): Can you get good performances out of Murex? Absolutely!

How you’re going to achieve depends on few things (which makes answering the question how long does it take to do something impossible to answer):

  • Hardware is the first one to come to mind. With great hardware comes great performance. Well, not really, you also need to have it tuned right but yes it is a major factor
  • Requirements. This one tends to be overlooked: “I want to get real theta for my whole portfolio over the next 10 days, along with a spot shock and at any time rewrite the spot levels. And it needs to be fast!” (you have similar questions with trade input, reports, etc…). Of course, if you ask for time consuming tasks (or put it many consistency checks), you will slow down the processes.
  • Maintenance. If all works fine on day 1 but not 10 days later, clearly there’s some maintenance that was not done properly
  • Software. I put this one last as it is very rarely the software the issue. Very rarely (feels good to repeat it)

For most of this issues, the PAC team is the go-to team. They can size the hardware you need based on your system usage, advise you on maintenance procedures and debug if something runs too slow.

In general if you believe that a process is taking too long given the configuration (inserting a deal takes 5 minutes, report still running after 1h, etc…) you need to do the following.
If it is an isolated occurrence, it could well be a lock either at DB level or at system level. For locks at DB level (rare but it happens), check with your dbas, also check if no heavy process is currently running. For locks at software level, Murex has you covered with ipmonit. Login to ipmonit from the monit tool, and you can access a lock report showing you all the locks put in by the system (for example if someone is editing a trade, it is locked to avoid 2 modifications at the same time). Check the documentation for ipmonit as screenshots are very helpful when navigating the screens.

If it happens all the time, then it is unlikely to be a lock and you need to generate performance traces. The first ones are generated with /TIMER slash command. This slash command will generate mxtiming files into your log directory (you can put the slash command if required in the launchers for services). The mxtiming file will show the time spent on CPU and while waiting for the DB. If time spent on DB is too high, indexes could be missing on the tables. So you need to run a DB traces (shameless link to my older post for how to). These DB traces can be sent to Murex and they will give you the number of logically read on each table. A number too high indicates (likely) that a table is unindexed. Indexing that table should improve performance.

If the system is slow, the reason lies either in the hardware or the configuration. Rarely the problem is due to a bug.

There are also cases where Murex develops a new feature to speed up a process that is known to be always slow due to the sheer amount of computing/data crunching it requires. Parallelization or pre-crunching are the 2 big methods to do so. But this applies when you start to have a volume: inserting a single deal should always be fast!

Comments, experiences are welcome!

Info, Tips

Volatility … going the distance

Today I’ll cover a bit about volatility and the different topics relating to it. If there’s one topic, you want me to dive into, let me know and I can then make a full post on it.

  1. What’s volatility?

Volatility is a measure of price variation over time. The higher the volatility the more likely the price will vary (either up or down). Volatility can be measured historically by computing the standard deviation of the prices. Or it can be measured implied, that is to say by solving for the volatility of a quoted option.

2.  Smile

When the volatility is solely time bound, we’re calling it the at-the-money volatility (or ATM vol if you prefer shortcuts). But often you’ll consider that volatility is not a constant for different strikes and it will change as you step away from the at the money point. Usually volatility increases as you move away from the central point effectively giving you a smile shaped curve. The driver behind this is that options further from the ATM point have effectively a higher price than if they were using the ATM vol point.

3. Interpolating and shaping the smile

When working with smile curves, you need to decide for an interpolation method. You can choose between parametric and geometric. Geometric interpolations take into account the pillars that you have provided to interpolate in between. Parametric requires for some parameters to be provided (correlation between spot and vol, shape of RR, etc..). SABR is getting used more and more for IRD products and traders start also to monitor the sensitivity of their positions to the SABR parameters.

4. Dynamic smile

It means that the smile is not a constant when spot rate is changing. So in terms of total vol, it is like defining a convexity to the volatility (smile being your first level). Murex can produce such effects when calibrating Tremor.

5. Short date model

Very popular in FX world, the idea is that you can attribute certain weights to specific days: Fridays are less volatile than the rest of the week, Weekends have a very low weight, Mondays are a bit higher, etc but also to specific events (Fed announcement, Big numbers publication, etc…) The short date model has really an impact on the shorter dates (the shorter the bigger), so while it goes up to 1 year, it is effectively really important up to 3 months.

6. Cut-off spreads

This one is more a workaround than a real need on the market. One should consider that an option with  a Sydney 5pm cut has less time to mature than an option NYC 5pm. So the idea is that the NYC option should have a higher price. Ideally, one would increase the time value of that option (and t would then be able to cater for fractions of days). As this is not currently possible in the system, the volatility is effectively increased to mimic the increased price for later cuts.

That’s all that comes to mind right now but I’m sure I’ve forgotten a lot about it. Volatility is a rich topic and I just wanted to give her a flavor of the different functions which are attached to it.

Comments, requests below!

Tips

RQWHERE

RQWHERE is probably the most useful function filter in Murex. It basically lets you filter based on SQL statements. This gives you complete freedom as to what criteria you want to use in order to choose a certain results population.

RQWHERE is also a pain in the neck to use the first times (and the times after!) as it is purely based on the datamodel (which as we discussed before is not documented). Based on the datamodel means that you need to understand how the data is structured and how the different tables are related together. It also means that if the datamodel changes, the filter will need to be adapted.

So if you tick the following boxes:
– Know how to make simple SQL statements
– Know how the data you need is organized
– Can’t make the filter you need with existing functionalities

RQWHERE is for you!

Basically RQWHERE calls for 2 arguments, the first one being a string and the actual select statement you wish to use and the second one being also a string but which I’ve never ever used. If someone recommends it, feel free to comment below 🙂

The way you structure your select statement is a bit up to you and while I can’t help you with it (your prefered Murex consultant can and will though 🙂 ) there is one very neat thing that can take your filter from being good to being very good: parser functions.

Indeed, you can enrich your string statement with interactive variables or parser functions. This means that the filter can prompt the enduser for a string/number/date prior to being executed which will then be used when building the string that will be sent to the function.

For example, you want to retrieve with a number higher than x. Your first argument will be something like “[start of your statement] where NUMBER>”+<interactive numeral variable>+”[end of your statement”. If you’re using strings or dates make sure that you use single and double quotes correctly: “[start of your statement] where STRING='”+<interactive string variable>+”‘[end of your statement]” (yes that STRING=<single quote> <double quote>). The built statement string will then be  “[start of your statement] where STRING='<input variable>’ [end of your statement]”. A perfectly built RQWHERE!

How to debug RQWHERE?

Sometimes your RQWHERE will not work as expected. Either it will return nothing with no error or sometimes it will spam errors. If the later, Murex will show you the statements which are failing and you can fix your RQWHERE by looking at the final result.
If there is no error, then turn on a DB trace (on screen or in logs) and check the built SQL statement if it is the one you want or not.

Questions, comments, feel free!

Info, Tips

Murex documentation

5 Comments

This very topic is the reason why I started this blog.

Asking for Murex documentation is maybe the number one request, coming from consultants, customers or even internally.

Don’t be fooled, while Murex is a great system it is also complex. The system has loads of configuration options to cater for the numerous market conventions found across the globe. Luckily, as part of the project process, most configurations are already preset or adjusted to answer the requirements.

So let’s address this question that I’ve heard so many times: Can you send me Murex documentation? Or in shortened form: mx doc? k thx bi.

All customers or people in contract with Murex, can access Murex documentation. It is deployed similarly to the application and if properly setup can be accessed with F1 while logged in. It happens sometimes that you’ll have a shortcut on your desk to open it.

The Murex documentation is within a proprietary system and is strongly protected. Don’t expect to print it all out! Most of the time, the documentation is read on the screen with no other support. You have categories, search functions. With a little bit of effort, you should be able to find the information you need.

If the documentation made massive progress over the years and often encompass a lot of information, new or little used functionalities are sometimes undocumented… What to do then?

Ask your preferred Murex contact! He will try to source the information and deliver it to you.

If you do not work for a customer, integrator or Murex directly, then you simply cannot access any Murex documentation. Murex is very protective of its IP and it applies to documentation as well.

To summarize:

“- Hi, Hi need Murex doc asap!

– Press F1 (smart ass reply, often adapted to the question above)”

 

“- Hi, I can’t find a doc about defining a 4 dimension GMP structure. Can you help?

– Let me come back to you” (and you’ll get the info, example or apologies if this is not possible)